L'IA a transformé le quotidien des data analysts. En 2026, ChatGPT, GitHub Copilot et les assistants SQL intégrés aux outils BI sont utilisés par une majorité de professionnels de la data. Et les recruteurs l'ont bien compris : les entretiens SQL évoluent pour tester une nouvelle compétence — votre capacité à travailler avec l'IA, pas malgré elle.
Thomas Leroy fait le point sur ce qui change dans les entretiens SQL en 2026, ce que les recruteurs évaluent réellement, et comment vous préparer.
📌 Ce qu'il faut retenir
- Les entretiens SQL évoluent : certaines entreprises testent maintenant votre capacité à travailler avec l'IA, pas uniquement sans elle
- La compétence clé est la lecture et la vérification du SQL généré — identifier les erreurs subtiles que l'IA produit régulièrement
- Le prompting efficace (formuler des demandes précises avec schéma et contexte métier) devient une compétence évaluée à part entière
- Les fondamentaux SQL restent indispensables : sans comprendre les JOINs, GROUP BY et les window functions, impossible de superviser l'IA
Ce qui a changé dans les entretiens SQL
L'ancien format (avant 2024)
L'entretien SQL classique testait :
- Votre connaissance de la syntaxe
- Votre capacité à écrire des requêtes de mémoire
- Votre vitesse d'écriture sous pression
- La correction syntaxique de votre code
Le nouveau format (2025-2026)
De plus en plus d'entreprises adoptent de nouveaux formats :
Format 1 : « Voici du SQL généré par IA, corrigez-le »
On vous donne une requête SQL générée par un LLM et on vous demande d'identifier les erreurs, les problèmes de performance ou les résultats incorrects.
Format 2 : « Utilisez l'IA comme outil, résolvez le problème »
On vous autorise (voire encourage) à utiliser ChatGPT ou Copilot pendant l'entretien. Ce qui est évalué : votre capacité à formuler les bons prompts, vérifier les résultats et itérer.
Format 3 : « L'IA a produit ce résultat, expliquez-le au métier »
On vous donne le SQL et le résultat. Vous devez expliquer ce que la requête fait, si le résultat est correct, et comment le présenter à un stakeholder non-technique.
Format 4 : Entretien classique (toujours majoritaire)
La majorité des entreprises utilisent encore le format classique. Mais même dans ce cas, la compréhension du SQL est plus valorisée que la mémorisation.
Exemples concrets d'entreprises adoptant ces nouveaux formats
Marie-Claire, data analyst chez Spotify, témoigne : « Notre processus de recrutement inclut maintenant un test où les candidats doivent corriger du SQL généré par ChatGPT pour analyser les données d'écoute. C'est exactement ce qu'ils feront en poste. »
Chez Meta, l'équipe Analytics teste désormais les candidats sur leur capacité à utiliser l'IA pour générer des requêtes complexes sur les métriques utilisateur, puis à vérifier et optimiser le code produit.
Les compétences IA évaluées en entretien SQL
1. Lire et comprendre du SQL complexe
C'est la compétence #1. Si l'IA écrit le SQL, vous devez être capable de le lire, comprendre et valider.
Exemple : on vous montre cette requête générée par un LLM.
WITH ranked AS (
SELECT
customer_id,
order_date,
amount,
ROW_NUMBER() OVER (
PARTITION BY customer_id
ORDER BY order_date DESC
) AS rn
FROM orders
WHERE status = 'completed'
)
SELECT
customer_id,
order_date AS last_order_date,
amount AS last_order_amount
FROM ranked
WHERE rn = 1;
Questions qu'on peut vous poser :
- « Que fait cette requête ? » → Dernier achat de chaque client
- « Y a-t-il un problème ? » → Si deux commandes ont la même date, ROW_NUMBER en choisit une arbitrairement. Faut-il la plus récente par heure ? La plus grosse ?
- « Comment l'amélioreriez-vous ? » → Ajouter une colonne de départage, ou utiliser RANK si on veut les deux
### 2. Identifier les erreurs subtiles
L'IA fait des erreurs que les débutants ne voient pas. Les recruteurs adorent ces pièges :
<div class="callout callout-warning">
<p class="callout-title">⚠️ Attention</p>
<p><strong>LEFT JOIN transformé en INNER JOIN par un WHERE</strong></p>
<p>L'IA génère souvent ceci :</p>
```sql
SELECT c.name, o.total
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id
WHERE o.status = 'completed';
<p>Le <code>WHERE o.status = 'completed'</code> élimine les clients sans commande (car <code>o.status</code> est NULL pour eux). La condition devrait être dans le ON : <code>ON c.id = o.customer_id AND o.status = 'completed'</code>.</p>
</div>
<div class="callout callout-warning">
<p class="callout-title">⚠️ Attention</p>
<p><strong>Agrégation incorrecte avec JOIN multiple (COUNT mal placé)</strong></p>
```sql
SELECT
c.name,
COUNT(*) AS nb_orders,
SUM(p.amount) AS total_payments
FROM customers c
INNER JOIN orders o ON c.id = o.customer_id
INNER JOIN payments p ON o.id = p.order_id
GROUP BY c.name;
Si une commande a plusieurs paiements, COUNT(*) compte les paiements, pas les commandes. Il faudrait COUNT(DISTINCT o.id).