Comment évaluer le vrai niveau des ingénieurs à l'ère de l'IA

Pour évaluer le vrai niveau d’un ingénieur quand l’IA peut fabriquer les bonnes réponses, autorisez l’IA pendant le test et notez la façon dont le candidat la pilote, la vérifie et la corrige. Confiez-lui une tâche de débogage et d’extension sur du code qu’il n’a pas écrit, puis appliquez une grille structurée qui valorise le raisonnement, la validation du résultat et l’arbitrage entre options plutôt que la simple justesse du code produit. Le goulot d’étranglement du métier s’est déplacé : écrire du code ne suffit plus, il faut le vérifier. Votre entretien doit donc mesurer la vérification.

Il est désormais impossible de distinguer les deux candidats sur la seule base de leur rendu. Le premier pilote un assistant IA avec discernement, repère ses erreurs et livre quelque chose de solide. Le second sollicite le même modèle, obtient du code qui a l’air de marcher, et ignore totalement qu’il est faux. Tous deux réussissent l’exercice à la maison. La différence n’apparaît que plus tard : en production, dans la file des revues de code, et dans la confiance que votre équipe perd au passage. C’est un problème de conception d’évaluation, et il se résout sans interdire l’IA ni jouer au détective. Pour la lame de fond qui se cache derrière, lisez la vue d’ensemble sur l’effondrement des diplômes.

Le problème de vivier dont les équipes de recrutement viennent d’hériter

Le vivier de candidats se remplit d’ingénieurs capables de livrer avec un assistant mais incapables de raisonner sans lui. La preuve la plus nette vient des établissements qui les forment : les taux d’échec explosent et le corps enseignant pointe publiquement la surdépendance à l’IA comme cause.

Au printemps 2026, le taux d’échec dans le cours CS 10 de l’UC Berkeley a atteint 35,3 %, contre moins de 10 % aux printemps 2024 et 2025, selon les notes rapportées par le Daily Californian. Le cours CS 61A a enregistré 10,6 % de mentions F et EECS 127 16,8 %. La moyenne du semestre est tombée autour d’un C+ (2,3 de GPA), bien en deçà de la fourchette de 2,8 à 3,3 préconisée par le département.

L’enseignant Dan Garcia attribue cet effondrement à une « hausse vertigineuse de la malhonnêteté académique » liée aux grands modèles de langage, citant près de 30 étudiants pris à tricher aux examens à la maison du seul cours CS 10. La professeure Gireeja Ranade observe des étudiants en difficulté sur les prérequis d’algèbre linéaire ; l’un d’eux a révélé que son cours d’algèbre linéaire appliquait une « politique internet et IA libres » pour les devoirs comme pour les examens. Depuis, plus de 1 300 enseignants de l’UC ont signé une pétition pour rétablir le SAT et l’ACT à l’entrée des filières STEM.

Ce cours d’algèbre linéaire en « IA libre » résume le problème à lui seul. L’IA n’a pas seulement aidé les étudiants à tricher à un examen d’informatique. Elle a masqué l’absence de fondamentaux un cran en amont, si bien qu’un étudiant peut valider un cours dont il n’a jamais réellement assimilé les prérequis. Quand cette personne arrive dans votre pipeline, la lacune est invisible sur le papier et ne refait surface que le jour où quelque chose casse et où l’assistant a tort.

Pourquoi interdire l’IA en entretien revient à mesurer le mauvais métier

Interdire l’IA pendant un entretien technique, c’est tester une façon de travailler qu’aucun ingénieur en poste n’utilise plus. C’est optimiser votre évaluation pour une compétence que le métier ne récompense plus isolément, et c’est de surcroît impossible à faire respecter.

L’IA est désormais tissée dans le quotidien du développement. Le State of Code Developer Survey 2026 de Sonar, fondé sur plus de 1 100 développeurs, conclut que 42 % du code livré est déjà généré ou assisté par l’IA, et table sur 65 % d’ici 2027. Chez Google, le PDG Sundar Pichai indiquait dans une mise à jour d’avril 2026 qu’environ 75 % du nouveau code est généré par l’IA puis relu par des ingénieurs, contre 50 % à l’automne précédent (d’après la couverture du programme interne par Exponent et Tekedia). Quand les trois quarts du nouveau code d’une organisation d’ingénierie de référence commencent par un assistant, un entretien qui interdit l’assistant mesure une fiction.

Les responsables techniques ressentent déjà cette rupture de mesure. Le AI Workforce Transformation Report 2025-2026 de Karat, fondé sur 400 dirigeants techniques aux États-Unis, en Inde et en Chine, révèle que 71 % estiment que l’IA complique l’évaluation des compétences techniques. Le même rapport note que les ingénieurs solides valent désormais trois fois ou plus leur rémunération totale, ce qui renchérit le coût d’un mauvais filtrage. La réponse du secteur penche vers l’autorisation de l’IA plutôt que vers son interdiction : selon l’analyse d’avril 2026 de l’IEEE-USA, environ 38 % des organisations autorisent désormais l’IA en entretien technique, l’adoption chez les employeurs new-yorkais avoisinant les 25 % et devant grimper vers 50 %. Canva, Rippling, Red Hat, Meta et Shopify l’autorisent déjà.

Pourquoi « démasquer le tricheur » est une course perdue d’avance

Chercher à prendre les candidats en flagrant délit d’IA, c’est un combat que vous continuerez de perdre. Les outils de détection sont à la traîne par rapport aux outils de triche, et l’écart se creuse : toute stratégie bâtie sur « interdire et démasquer » se périme dès sa mise en place.

Les chiffres sont sans appel. Selon Fabric, qui a analysé plus de 50 000 candidats, la triche par IA sur les exercices à la maison a plus que doublé, passant de 15 % en juin 2025 à 35 % en décembre 2025. Les outils modernes résolvent un exercice à la maison standard en moins de cinq minutes et affichent les réponses via des surimpressions GPU invisibles qui n’apparaissent jamais dans un partage d’écran. Fabric rapporte que 59 % des recruteurs soupçonnent déjà les candidats d’utiliser l’IA pendant les tests, et les dirigeants interrogés par Karat estiment que plus de la moitié des candidats utilisent l’IA même lorsqu’on le leur interdit. À plus long terme, Gartner prévoit que d’ici 2028, un profil de candidat sur quatre sera factice, construit à partir de texte, de voix ou de deepfakes synthétiques (cité par Fabric).

Vous ne gagnerez pas une course à l’affichage contre un logiciel qui se cache du partage d’écran. Alors cessez d’essayer. L’échec de la détection n’est pas un motif de désespoir ; c’est l’argument pour changer ce que vous mesurez. Si vous ne pouvez pas savoir de façon fiable si l’IA a été utilisée, concevez une évaluation où cela n’a pas d’importance, car bien utiliser l’IA est précisément ce que vous voulez observer.

Le vrai signal s’est déplacé de la génération vers la vérification

La compétence rare n’est plus de produire du code. C’est de juger si le code produit par un assistant est réellement correct, et de le corriger quand il ne l’est pas. Sonar le nomme sans détour : l’effet net de l’IA est un « goulot d’étranglement de vérification », pas un simple gain de productivité.

Les données qui sous-tendent cette formule donnent à réfléchir. Dans l’enquête de Sonar, 96 % des développeurs ne font pas pleinement confiance au code généré par l’IA, et pourtant seuls 48 % le vérifient systématiquement avant de le valider, tandis que 38 % jugent que relire du code IA demande plus d’effort que relire celui d’un humain. Et le coût de vérification ne disparaît pas non plus au passage de la QA. Le State of AI-Powered Engineering report 2026 de Lightrun constate que 43 % des modifications de code générées par l’IA nécessitent encore un débogage manuel en production après avoir franchi la QA et la préproduction (d’après VentureBeat).

Lisez ces deux constats ensemble. Une part importante et croissante du code est générée par l’IA, et une grande partie de ce code est subtilement fausse, d’une manière qui survit aux contrôles automatisés et atteint la production. L’ingénieur qui crée de la valeur dans ce monde est celui qui lit le résultat d’un œil critique, monte une reproduction minimale, consulte les logs et prouve un correctif plutôt que de faire confiance au modèle. C’est cette capacité que votre entretien doit faire ressortir. Si le goulot d’étranglement du métier est la vérification, l’évaluation doit mesurer la vérification.

Ce qu’il faut réellement mesurer : piloter, vérifier, corriger

Cessez de noter si le candidat a produit une fonction correcte. Commencez à noter la façon dont il pilote l’assistant, vérifie son résultat et se rattrape quand celui-ci se trompe. C’est le modèle que les programmes les plus avancés ont déjà adopté, et il se transpose proprement à une boucle de recrutement à l’échelle d’une startup.

Le pilote assisté par IA rapporté chez Google autorise un assistant approuvé pendant l’épreuve de code pour les postes juniors et intermédiaires aux États-Unis, et note « l’aisance avec l’IA, dont l’ingénierie de prompts, la validation du résultat et les compétences de débogage ». Point crucial : les candidats qui « s’appuient lourdement sur l’IA sans démontrer leur propre compréhension » reçoivent un retour négatif. Ce seul choix de conception résume toute la thèse : l’aisance rapporte des points, la dépendance en fait perdre. DoorDash est allé plus loin en remplaçant son épreuve de code classique par une session de travail assistée par IA de 60 minutes sur un projet réaliste, notée sur « l’usage des outils, l’approche du débogage, le jugement et la communication sous contraintes réelles ». L’équipe d’ingénierie de DoorDash le dit clairement : « les vrais facteurs de distinction sont la prise de décision, le raisonnement à l’échelle du système et le sens des responsabilités. »

Les guides d’entretien de programmes comme Formation et Sierra convergent vers le même vocabulaire de validation : les bons candidats « montent une reproduction minimale, lisent les logs et écrivent des vérifications ciblées pour prouver qu’un correctif fonctionne, plutôt que de faire aveuglément confiance au résultat de l’IA ». Deux formats de tâche font ressortir cela mieux que tout.

La tâche de débogage et d’extension sur du code qu’ils n’ont pas écrit

L’exercice le plus diagnostique de tous consiste à lire et corriger du code que le candidat n’a pas écrit. « Savez-vous lire le code de quelqu’un d’autre, trouver ce qui cloche et le corriger ? » est la question que la dépendance à l’IA ne peut pas truquer, parce que le travail relève de la vérification, pas de la génération. Confiez au candidat une petite base de code partiellement fonctionnelle avec une faille logique implantée, le genre de bug qui a l’air correct et passe un test naïf. Demandez-lui ensuite de le trouver, de le corriger et d’étendre le système avec une fonctionnalité réaliste.

L’IA est explicitement autorisée. Ce que vous observez, c’est comment il se repère dans du code inconnu, s’il reproduit le bug avant de le « corriger », s’il fait confiance à la première suggestion de l’assistant ou s’il la vérifie, et comment il réagit quand le modèle propose avec aplomb quelque chose de faux. Un candidat dépendant colle l’erreur dans un prompt et livre tout ce qui en sort. Un candidat à l’aise se sert de l’assistant pour aller plus vite tout en assumant chaque décision.

La conversation de conception système qui force les arbitrages

Associez la tâche de débogage à une discussion de conception système qui impose un raisonnement d’arbitrage explicite. Pas « concevez Twitter », mais une décision concrète et délimitée : comment mettriez-vous ceci en cache, où cela casse-t-il sous charge, à quoi renoncez-vous en choisissant l’option la plus simple ? L’IA sait esquisser un schéma d’architecture. Ce qu’elle ne sait pas faire, dans un échange en direct, c’est défendre un choix que vous remettez en question et l’ajuster quand vous ajoutez une contrainte. La conversation révèle si le raisonnement est celui du candidat ou celui du modèle.

La grille : cinq critères à noter

Gardez la grille courte, comportementale et orientée vers le jugement plutôt que vers le résultat. Notez chaque candidat sur les mêmes cinq critères pour que le signal reste comparable d’un bout à l’autre du pipeline.

1. Pilote bien l’IA. Des prompts clairs et ciblés ; sait quoi demander et pourquoi, au lieu de saisir tout le problème en croisant les doigts.
2. Vérifie le résultat. Reproduit, lit les logs, écrit des vérifications ciblées ; ne valide pas sur la foi.
3. Corrige les erreurs de l’IA. Repère la suggestion plausible mais fausse et explique pourquoi elle est fausse.
4. Raisonne sur les arbitrages. Défend ses décisions, pèse les alternatives, s’ajuste face à de nouvelles contraintes.
5. Communique et assume. Verbalise sa réflexion, gère le périmètre, prend la responsabilité du résultat.

Pourquoi les mises en situation battent les diplômes et LeetCode

Une mise en situation concrète figure parmi les signaux de recrutement les plus prédictifs jamais mesurés, et elle tient bon depuis 25 ans. La méta-analyse classique de Schmidt et Hunter (1998) en psychologie du personnel situe la validité des mises en situation autour de 0,54 et celle des entretiens structurés autour de 0,51, avec une combinaison aptitude mentale générale + mise en situation proche de 0,63. Une révision ultérieure par Roth, Bobko et McFarland (2005) ramène les mises en situation plus près de 0,33, ce qui reste très au-dessus des indicateurs faibles.

Les indicateurs faibles sont précisément ceux que l’IA fait voler en éclats. CV, années d’expérience et diplômes non vérifiés se situent en bas des tableaux de validité, et le signal du diplôme se dégrade en temps réel, comme le montrent les notes de Berkeley. Les casse-têtes d’algorithmes appris par cœur ne valent pas mieux : une épreuve LeetCode en direct est tout aussi falsifiable par l’IA et tout aussi peu signifiante qu’un exercice à la maison, et c’est pourquoi les filtrages façon LeetCode deviennent obsolètes. La leçon est constante, dans la recherche comme sur le marché. Observez la personne accomplir un travail réaliste et raisonner dessus. Ne confiez pas ce travail à un diplôme à votre place.

Il y a aussi un dividende d’équité. DoorDash rapporte que les formats assistés par IA permettent aux « ingénieurs aux parcours atypiques de vraiment briller », parce que l’assistant comble l’écart d’exécution et que l’épreuve mesure le jugement, lequel se transfère des maths, de la physique ou de l’auto-apprentissage. Autoriser l’IA n’est pas une concession faite aux tricheurs. Cela élargit le vivier à des gens qui raisonnent bien sans avoir suivi le parcours informatique standard.

Comment mettre cela en place dans votre propre pipeline

Pas besoin d’un service d’entretien externalisé ni d’un prestataire de surveillance pour ce dispositif. Il vous faut deux étapes, configurées une seule fois : un exercice de code avec IA autorisée bâti autour de la vérification, et un débrief en direct structuré avec une vraie grille. C’est précisément ce vide que Kit comble pour les équipes à l’échelle d’une startup. Pour le recrutement de profils débutants, le modèle Junior Engineer Pipeline fournit ces deux étapes déjà configurées.

Kit est un ATS pensé pour l’IA, avec un pipeline configurable par étapes, et deux types d’étapes existants épousent directement cette conception. L’étape exercice de code s’appuie sur un modèle GitHub : au lieu d’un énoncé « construisez X » à partir de zéro, vous provisionnez un modèle déboguez cette base de code / étendez ce système partiel, la forme de tâche qui récompense la vérification plutôt que la génération. Kit gère la création du dépôt, les instructions, la soumission automatique à l’échéance et l’archivage. Vos instructions peuvent le dire sans détour : « l’IA est autorisée ; nous vous demanderons de nous expliquer comment vous l’avez pilotée et vérifiée. » Ensuite, l’étape entretien en direct porte la grille, avec l’attribution des évaluateurs et une revue d’équipe structurée pour que les cinq critères soient notés de la même façon pour chaque candidat et restent comparables sur tout l’entonnoir de recrutement.

Une mise en garde honnête. Aucun outil, Kit compris, ne détecte de façon fiable l’usage de l’IA ; les données sur les surimpressions invisibles le démontrent. C’est précisément cette limite qui fait de la conception de la tâche et de la grille la bonne réponse, plutôt que de la détection. Le rôle de Kit est de rendre cette bonne conception facile à déployer et à standardiser, pas de jouer au chat et à la souris avec les outils de triche. Pour l’article compagnon sur l’exercice lui-même, voyez comment structurer des tests de code que les candidats ne détestent pas.

Le virage est simple à énoncer et plus difficile à éviter qu’il ne devrait l’être. Cessez d’interdire l’IA, parce que le métier s’en sert. Cessez de détecter l’IA, parce que vous ne gagnerez pas cette course. Concevez plutôt une évaluation où bien utiliser l’IA est la compétence visible : une tâche de débogage et d’extension sur du code inconnu, une conversation d’arbitrage que l’IA ne peut pas écrire à la place du candidat, et une grille qui note la façon dont il pilote, vérifie et corrige l’assistant. C’est ainsi que vous distinguez l’ingénieur qui commande l’IA de celui qui en est seulement dépendant, et c’est toute la différence entre une recrue qui livre et une qui engorge votre file de revues.

Foire aux questions

Faut-il laisser les candidats utiliser l’IA pendant un entretien de code ?

Oui, pour les épreuves où vous voulez mesurer leur façon de travailler. Le métier s’appuie massivement sur l’IA, avec 42 % du code livré déjà assisté par l’IA selon Sonar, donc une épreuve sans IA teste une façon de travailler que plus personne n’emploie. Limitez l’usage de l’IA à certaines épreuves : DoorDash, par exemple, l’autorise dans sa session de travail assistée par IA mais pas dans toutes les épreuves. Notez la façon dont le candidat pilote et vérifie l’assistant, pas s’il a produit seul une fonction correcte.

Comment repérer un candidat trop dépendant de l’IA ?

Vous ne le repérez pas par la surveillance, qui est une course perdue d’avance comme le montrent les données. Vous le faites ressortir par la conception de la tâche. Confiez-lui une tâche de débogage et d’extension sur du code inconnu avec une faille logique implantée, puis observez s’il vérifie le résultat de l’assistant ou s’il s’y fie aveuglément. La dépendance saute aux yeux dès l’instant où le modèle se trompe avec aplomb et où le candidat n’y voit que du feu.

Quel est le meilleur format d’entretien technique en 2026 ?

Une mise en situation de débogage et d’extension sur du code que le candidat n’a pas écrit, associée à une conversation de conception système délimitée, les deux avec IA autorisée et une grille valorisant le raisonnement plutôt que le résultat. Les mises en situation portent la plus forte validité prédictive de la littérature sur la sélection du personnel (autour de 0,33 à 0,54 selon Schmidt et Hunter), bien au-dessus des CV, des années d’expérience ou des casse-têtes d’algorithmes appris par cœur.

Autoriser l’IA désavantage-t-il les candidats aux parcours atypiques ?

C’est l’inverse. DoorDash rapporte que les formats assistés par IA permettent aux ingénieurs aux parcours atypiques de briller, parce que l’assistant comble l’écart d’exécution et que l’épreuve mesure le jugement, lequel se transfère de domaines comme les maths et la physique. Autoriser l’IA élargit le vivier aux bons raisonneurs qui n’ont pas suivi le parcours informatique standard.