Évaluer la compétence IA d'un ingénieur nécessite d'aller au-delà de la familiarité avec les outils pour examiner les habitudes de travail : comment il oriente les modèles, relecte les résultats et réagit lorsque le modèle se trompe avec assurance. Un développeur ayant utilisé l'IA en production le montrera dans la façon dont il décrit les compromis, pas seulement dans les outils qu'il cite.
Pourquoi l'entretien classique est insuffisant
Demander « utilisez-vous Copilot ou Cursor ? » ne vous apprend presque rien. L'utilisation de ces outils est désormais quasi universelle. La question est de savoir comment un ingénieur les utilise, ce qu'il vérifie, et à quel moment il décide de ne plus s'y fier.
Un test de codage standard, réalisé seul et chronométré, offre également un signal limité. Les ingénieurs qui recourent à l'assistance de l'IA dans leur travail quotidien y feront naturellement appel lors d'un test. L'interdire revient à mesurer autre chose. L'autoriser sans un débriefing structuré ne permet pas de distinguer l'ingénieur du résultat produit.
Ce qu'il faut observer à la place
La façon dont ils décrivent un travail récent réalisé avec l'aide de l'IA. Demandez-leur de détailler quelque chose qu'ils ont construit avec l'aide de l'IA au cours du dernier mois. Écoutez : quel prompt ou quel contexte ils ont fourni au modèle, ce qui est revenu de manière incorrecte ou incomplète, ce qu'ils ont modifié, et comment ils ont décidé que le résultat était prêt à être mis en production. Les réponses vagues, ou celles qui traitent l'IA comme une boîte noire acceptée sans esprit critique, sont instructives.
La façon dont ils relisent le code généré par l'IA. Un exercice utile consiste à leur soumettre un court morceau de code qu'ils n'ont pas écrit, contenant quelques erreurs subtiles. Observez s'ils le lisent attentivement ou le parcourent en diagonale. Observez s'ils détectent des problèmes qui semblent plausibles mais sont incorrects. Cela recoupe les compétences classiques de relecture de code, mais est accentué par le fait que les résultats de l'IA tendent à échouer de manière particulière : hallucination confiante d'API, logique structurellement correcte mais comportementalement erronée, hypothèses de sécurité intégrées silencieusement.
La façon dont ils parlent du contexte. Les ingénieurs qui utilisent l'IA efficacement ont généralement une vision claire de ce qu'il faut inclure dans un prompt, de la quantité d'historique à fournir, et du moment où une conversation a suffisamment dérivé pour que repartir de zéro produise de meilleurs résultats. S'ils n'ont jamais réfléchi à l'ingénierie du contexte, c'est un signal. S'ils ont des opinions tranchées à ce sujet, c'en est également un, et cela mérite d'être approfondi.
La façon dont ils gèrent un cahier des charges incomplet. Donnez-leur un brief auquel il manque intentionnellement des détails. Posent-ils des questions de clarification, formulent-ils des hypothèses explicites et signalent-ils ce qu'ils souhaiteraient confirmer avant de générer quoi que ce soit de significatif ? Ou comblent-ils les lacunes silencieusement et livrent-ils avec assurance ? Les outils IA amplifient les bonnes comme les mauvaises habitudes face à l'ambiguïté.
Les cas où ils indiquent que le modèle s'est trompé. Posez directement la question : « parlez-moi d'un moment où le modèle vous a fourni quelque chose qui semblait correct et ne l'était pas. » S'ils ne se souviennent d'aucun exemple précis, c'est qu'ils n'utilisent pas l'IA de manière significative en production ou qu'ils ne relisent pas les résultats. Les deux aspects sont importants.
Les signaux peu significatifs
Connaître les outils qui existent n'est pas une preuve de compétence. Être capable de décrire ce qu'est un pipeline RAG ou un serveur MCP ne vous dit pas si quelqu'un est capable d'en construire ou d'en évaluer un. Les certifications et les formations dans ce domaine ont une valeur prédictive limitée ; le secteur a évolué plus vite que la plupart des programmes de formation.
Structurer le débriefing
Si vous autorisez l'utilisation de l'IA lors d'un exercice technique, prévoyez un débriefing de 20 minutes immédiatement après. Demandez-leur d'expliquer chaque partie de ce qui a été produit. Demandez ce que le modèle a mal fait et comment ils l'ont détecté. Demandez ce qu'ils auraient fait différemment avec plus de temps. Cette approche est plus utile que tout test à emporter qui arrive soigné et sans échange.
Pour en savoir plus sur ce qui a changé structurellement dans ce processus, consultez ce qui a remplacé le test de codage.
Ce que nous évaluons
Chez Miyagami, nous évaluons chaque ingénieur en deux temps. La première évaluation se déroule sans outils d'IA et porte sur les fondamentaux : débogage, priorisation et communication. La seconde donne aux candidats leurs outils d'IA habituels et observe ce qu'ils en font réellement : vérifient-ils les productions de l'IA avant de leur faire confiance, comment orchestrent-ils leurs outils, et gardent-ils la maîtrise d'un code qu'ils n'ont pas tapé eux-mêmes ? Le jugement selon le risque et l'effet de levier sont notés dans les deux évaluations. Ce que nous recherchons, et pourquoi, est détaillé dans notre processus de sélection.
Réponses courtes
Dois-je interdire les outils IA lors d'un entretien technique ?
Interdire les outils IA mesure une façon de travailler qui diffère de la plupart des environnements de production. Les autoriser avec un débriefing structuré fournit un signal plus utile : vous pouvez observer ce que l'ingénieur a accepté, ce qu'il a détecté et comment il explique le résultat.
Quelle est la question d'entretien la plus utile pour évaluer la compétence IA ?
Demandez à l'ingénieur de décrire un travail récent qu'il a réalisé avec l'aide de l'IA et les cas où le modèle s'est trompé. La qualité et la précision de la réponse vous en apprendront plus que n'importe quelle question sur la familiarité avec les outils.
La connaissance d'outils IA comme RAG ou les agents signale-t-elle une forte compétence IA ?
La connaissance conceptuelle est un signal faible en soi. L'élément le plus probant est de savoir si l'ingénieur peut décrire comment il a utilisé un outil en production, ce qui a mal fonctionné et comment il l'a détecté.
