Test technique développeur : comment évaluer un ingénieur quand l'IA écrit le code en 2026 ?

Un candidat peut générer en quelques secondes une solution testée et commentée avec GitHub Copilot, Cursor ou Claude Code. Le test technique développeur que vous utilisez depuis des années n'est pas devenu inutile, mais il ne mesure plus toujours ce que vous croyez. Un exercice d'algorithmique à distance, sur une question connue, mesure désormais autant l'outillage du candidat que sa compétence.

La réponse courte : arrêtez de chercher à savoir si le candidat a utilisé l'IA, cherchez à savoir s'il sait quand elle se trompe. Concrètement : des épreuves qui montrent les décisions plutôt que le code final, une règle d'usage de l'IA fixée épreuve par épreuve et remise au candidat, une notation ancrée sur des comportements observables.

Ce qu'il faut retenir

• Avec une aide IA cachée, des candidats ont réussi 73 % des entretiens sur des questions LeetCode connues, sans qu'aucun intervieweur ne s'en aperçoive.
• Générer du code n'est plus la compétence rare : comprendre, débugger, concevoir et juger le sont.
• Autoriser ou interdire l'IA se décide épreuve par épreuve, et le candidat doit connaître la règle avant de commencer.
• La revue d'une pull request générée par IA observe directement le tri qu'un ingénieur fera chaque jour.
• Un processus technique tient en deux heures pour un junior et en quatre heures trente au plus pour un Staff Engineer.
• La subjectivité se réduit par la structure : grille ancrée, notes écrites avant le débrief, débrief cadré.

Un test technique développeur mesure-t-il encore quelque chose avec l'IA ?

Oui, mais pas toujours ce qu'il prétend mesurer. Un test observe un comportement dans des conditions données, et l'on suppose que ce comportement prédit le travail futur. Cette supposition tenait tant que produire du code correct demandait de le comprendre.

Le constat le plus net vient d'une expérience d'interviewing.io, plateforme américaine d'entretiens d'entraînement, publiée début 2024. Des candidats ont utilisé ChatGPT en cachette pendant 32 entretiens de code. Ils ont réussi 73 % des entretiens sur des questions LeetCode reprises telles quelles, 67 % sur des questions modifiées, et 25 % sur des questions conçues sur mesure, contre 53 % pour le groupe témoin. Aucun intervieweur n'a rien soupçonné. L'échantillon est petit, mais le sens est clair : c'est la nature de la question qui protège un test, pas la surveillance.

Second constat, moins commenté : l'IA est la plus forte sur les tâches petites et fermées. Des développeurs équipés de Copilot ont écrit un serveur HTTP 55,8 % plus vite qu'un groupe témoin, selon l'étude de Peng et al.. Sur 246 tickets réels de dépôts open source matures, des développeurs expérimentés ont été 19 % plus lents avec l'IA, en croyant avoir gagné 20 %, d'après METR en juillet 2025. METR a depuis jugé ses nouvelles mesures peu fiables et estime probable que l'accélération ait augmenté, sans pouvoir la chiffrer.

La plupart des exercices de recrutement ressemblent au premier cas, la plupart des postes au second. Vos tests mesurent l'IA là où elle est la plus forte, et le candidat là où il compte le moins.

S'y ajoute un biais plus ancien : dans un essai randomisé présenté à ESEC/FSE 2020, la performance d'étudiants au tableau a été divisée par plus de deux sous le regard d'un intervieweur. Un exercice chronométré mesure aussi la tolérance au stress.

Quelles compétences un test technique doit-il isoler ?

Au moins cinq, que les assistants de code ont décorrélées. On peut désormais générer beaucoup sans comprendre, et un excellent ingénieur peut produire peu en direct parce qu'il vérifie.

Générer est devenu la compétence la moins rare. Dans l'enquête Stack Overflow 2025, 84 % des développeurs utilisent ou prévoient d'utiliser l'IA, mais seuls 33 % font confiance à ses réponses, et 66 % citent comme première frustration des solutions « presque justes ». Le travail se déplace vers la vérification. Le rapport DORA 2025 de Google Cloud le résume : l'IA amplifie ce qui existe déjà, avec plus de débit mais moins de stabilité quand les garde-fous manquent.

Le jugement est donc le goulot : chaque ingénieur recruté va accepter ou refuser des dizaines de propositions de code par jour. Concrètement, remplacez « Implémentez une LRU cache » par « Voici une LRU cache générée : où casse-t-elle sous concurrence ? », et « Comment concevriez-vous Twitter ? » par « Votre file de messages sature à 18 h chaque jour : que regardez-vous d'abord ? ».

Les critères plus larges (livraison, compréhension produit, écrit) sont traités dans notre article sur l'évaluation des compétences professionnelles d'un profil tech.

Live coding ou take-home : quel format de test technique garder ?

Aucun format n'est bon en soi : chacun mesure surtout une compétence et en rate d'autres. La bonne question est de savoir si votre processus couvre les compétences du poste sans en mesurer une trois fois.

C'est une synthèse de praticiens, pas une mesure. Algorithmique plus take-home mesure deux fois la génération, la compétence que l'IA rend la moins rare.

Le live coding, à condition de changer d'objet

L'algorithmique en direct reste utile pour vérifier les bases d'un junior, si le problème est original et l'épreuve vérifiable. Le pair programming dans une base de code réelle, écran partagé, reste robuste parce que l'évaluateur voit le processus. Il exige une grille, sinon deux évaluateurs ne notent pas la même chose.

Le take-home, seulement s'il remplace un entretien

C'est le format le plus fragilisé : un artefact dont vous ignorez l'auteur réel et le temps passé, souvent 3 à 8 heures. Il reste défendable à trois conditions : deux heures maximum, IA explicitement autorisée, soutenance où le candidat modifie son code en direct. Au-delà, rémunérez-le ou supprimez-le.

Le projet passé, le plus sous-utilisé

Bien mené, il distingue la personne qui a décidé de celle qui a assisté. Creusez trois niveaux sous chaque affirmation : pourquoi, qu'avez-vous écarté, que feriez-vous autrement.

Faut-il autoriser Copilot, Cursor ou ChatGPT pendant un entretien technique ?

Cela dépend de l'épreuve, pas du processus entier. Des entreprises ont publié des choix opposés : Canva attend de ses candidats qu'ils utilisent leurs assistants, sur des sujets plus ambigus qui remplacent l'algorithmique, tandis qu'Anthropic interdit l'IA en entretien direct sauf indication contraire, selon Fortune. Chacun mesure autre chose.

Quatre régimes existent. IA interdite : mesure les fondamentaux, à condition que l'interdiction soit vérifiable. Autorisée et déclarée : écran partagé, le candidat commente ce qu'il demande et garde, ce qui montre sa manière réelle de travailler. Imposée : l'épreuve ne se résout pas en une requête, on mesure le pilotage de l'outil. Outil fourni : même environnement pour tous, ce qui corrige l'inégalité d'outillage.

Côté droit, l'article L1221-8 du Code du travail impose d'informer le candidat des méthodes d'évaluation avant leur mise en œuvre, et l'article L1221-9 interdit de collecter une information par un dispositif non annoncé. Envoyer votre politique IA au moins 48 heures avant les épreuves n'est donc pas qu'une courtoisie, et un logiciel anti-triche non annoncé pose une question de conformité. Si c'est vous qui notez avec une IA, le règlement européen sur l'IA classe ces systèmes à haut risque. Faites valider ces points par votre juriste.

Quelles épreuves montrent comment un développeur décide ?

Celles qui rendent visibles les choix et les renoncements, parce qu'un code qui fonctionne ne dit plus qui l'a pensé. Ces trois formats appliquent des principes établis à des formats récents : leur validité prédictive propre n'a pas encore été mesurée, c'est une pratique professionnelle à suivre chez vous.

Revue d'une pull request générée par IA (60 minutes)

Le format le plus différenciant. Le candidat reçoit une PR Python d'environ 40 lignes, présentée comme produite avec un assistant : un gestionnaire de webhooks de paiement. Elle contient des défauts plantés, dont quatre critiques : signature calculée sur un JSON re-sérialisé plutôt que sur le corps brut, secret de repli codé en dur, idempotence non atomique qui permet un double crédit, toute exception renvoyée en 200, d'où un paiement perdu sans alerte. S'y ajoute un piège : renvoyer 200 pour un doublon est correct.

On note la priorisation, la décision de fusion et la vérification des suggestions de l'assistant, plus que l'exhaustivité. Le protocole complet, barème sur 20 et seuils par niveau compris, est dans le livre blanc et ses outils en PDF.

Incident puis arbitrage (75 à 90 minutes)

Pour un senior et au-delà. Un service de commandes sature après un déploiement : un appel HTTP dans une transaction épuise le pool de connexions. Le candidat diagnostique, écarte deux fausses pistes, stabilise, puis arbitre entre plusieurs architectures.

Conception à contraintes changeantes (60 minutes)

Un system design classique se récite, et l'IA le produit très bien. Le remède : changer les contraintes en cours d'épreuve. Un suivi de 300 machines industrielles, puis un client 2 000 fois plus gros, des données à garder dans ses locaux, deux ingénieurs seulement pour exploiter. On observe ce que le candidat recalcule, défait et abandonne.

Comment repérer un développeur qui dépend trop de l'IA ?

En regardant le processus, pas le résultat. L'usage pertinent délègue ce qu'il maîtrise et vérifie ce qu'il garde. La dépendance accepte le plausible et relance l'outil au lieu de lire l'erreur. Le manque de maîtrise ne sait pas expliquer le code accepté.

La recherche confirme que ces usages se distinguent. Dans une étude randomisée d'Anthropic de janvier 2026, 52 ingénieurs majoritairement juniors apprenant une bibliothèque ont obtenu 50 % au quiz final avec l'IA, contre 67 % sans. Ceux qui déléguaient toute la tâche obtenaient moins de 40 %, ceux qui interrogeaient l'IA pour comprendre 65 % et plus. Les effectifs sont petits : c'est une direction, pas une norme.

La relance la plus utile : « Qu'a proposé l'assistant que vous avez refusé, et pourquoi ? » Aucun refus en vingt-cinq minutes est un signal. Pratique émergente, encore peu documentée : insérer dix minutes sans outil au milieu de l'épreuve (« que renvoie cette fonction pour une entrée vide ? »). Le contraste sépare dépendance et manque de maîtrise, à condition de l'annoncer et de ne pas en faire une épreuve de vitesse.

Combien de temps doit durer un processus d'évaluation technique ?

Deux heures à deux heures trente pour un junior, quatre heures à quatre heures trente pour un Staff Engineer ou un Tech Lead, tous rendez-vous techniques compris. Au-delà, vous perdez les candidats qui ont d'autres processus en cours. C'est un consensus de praticiens, pas une norme mesurée.

La séniorité change ce qu'il faut prouver : un junior, qu'il comprend ce qu'il produit ; un Staff Engineer, qu'il fait converger plusieurs équipes ; un Lead Tech, qu'il fait progresser la sienne. Évaluez le niveau démontré, pas l'ancienneté, et tranchez le besoin en amont avec notre article sur le choix entre un junior et un senior en tech.

Trois règles gardent le processus court. Une épreuve, une compétence principale. Toutes les épreuves sur une demi-journée, décision sous cinq jours ouvrés. Un critère d'arrêt écrit par épreuve, qui évite trois épreuves de plus à un candidat déjà écarté.

Cas illustratif (fictif) : une scale-up SaaS de 45 ingénieurs recrute des développeurs confirmés. Son processus demande 10 à 12 heures sur trois semaines et mesure trois fois la génération, jamais la revue, alors que le poste consiste surtout à relire du code produit avec Cursor. Nouveau processus : projet passé, revue de PR générée, pair programming dans le monolithe, rencontre équipe. Total : 3 h 15 sur une demi-journée.

L'enchaînement complet, motivation comprise, est décrit dans le process de recrutement de vos futurs développeurs en startup, et un processus court aide aussi à attirer les bons développeurs.

Comment noter un test technique sans se fier à l'impression ?

En structurant la notation autant que l'épreuve. En 2022, Sackett et ses coauteurs ont réexaminé les méta-analyses sur les méthodes de sélection : l'entretien structuré arrive en tête, avec une validité moyenne de 0,42, devant les mises en situation de travail (0,33). C'est établi, et cela laisse une large incertitude : acceptez-la plutôt que d'empiler les épreuves.

Quatre règles suffisent :

1. Ancrer sur des comportements : « prédit le comportement du code avant de l'exécuter » s'observe, « bonne compréhension » non.
2. Une échelle de 1 à 4, sans milieu, plus une case « pas observé ».
3. Des notes individuelles écrites avant le débrief : le premier qui parle ancre les autres.
4. Un évaluateur principal par compétence, pour éviter la note globale d'impression.

Au débrief, le moins expérimenté parle en premier, et la question réflexe est « quel fait vous fait dire cela ? ». Avant d'utiliser un protocole, faites-le noter à blanc par les futurs évaluateurs : les écarts révèlent les critères mal compris. La même discipline vaut pour recruter un Engineering Manager.

Ne misez pas sur la détection : dans l'expérience d'interviewing.io, des intervieweurs aguerris n'ont repéré aucun candidat aidé en secret. Une PR discutée ou un incident raisonné à voix haute ne s'externalisent pas facilement. Investissez dans l'épreuve plutôt que dans la surveillance, et comparez à six mois le devenir des recrutés avec leurs notes. Auditer ces épreuves pour des équipes produit et SaaS fait partie du quotidien de notre pôle Business & Solutions Tech.

FAQ

Quel test technique faire passer à un développeur junior ?

Un temps court sans IA, 20 à 30 minutes sur un problème original, puis un pair programming avec IA autorisée et déclarée. L'objectif est de vérifier qu'il comprend ce qu'il produit, le risque principal à ce niveau étant la dépendance à l'outil. Comptez deux heures à deux heures trente d'épreuves au total.

Le take-home est-il encore pertinent pour évaluer un développeur ?

Seulement sous conditions : deux heures maximum, IA explicitement autorisée, et une soutenance où le candidat modifie son code en direct. Il doit remplacer un entretien, pas s'y ajouter. Au-delà de deux heures, rémunérez-le ou supprimez-le.

Peut-on utiliser un logiciel anti-triche pendant un test technique ?

En France, le Code du travail impose d'informer le candidat des méthodes d'évaluation avant leur mise en œuvre et interdit de collecter une information par un dispositif non annoncé. Un outil de surveillance doit donc être annoncé et validé juridiquement. Un outil qui analyse les expressions du visage mérite un examen particulier : la reconnaissance des émotions au travail est interdite par le règlement européen sur l'IA depuis février 2025.

Faut-il annoncer au candidat les règles d'usage de l'IA pendant le test ?

Oui, par écrit, au moins 48 heures avant la première épreuve. Indiquez pour chaque épreuve sa durée et si l'IA est interdite, autorisée ou fournie. Précisez ce qu'« autorisé » veut dire : un usage intensif n'est pas pénalisé, ne pas savoir expliquer un code accepté l'est.

Comment évaluer un senior ou un Staff Engineer en entretien technique ?

Privilégiez les épreuves qui révèlent le jugement : un incident suivi d'un arbitrage d'architecture, une conception dont les contraintes changent, une discussion approfondie d'un projet passé. À ce niveau, la capacité à nommer ses renoncements compte davantage que la vitesse d'écriture. Un exercice d'algorithmique y produit surtout des faux négatifs.

Peut-on noter les candidats avec un outil d'IA ?

Le règlement européen sur l'IA classe à haut risque les systèmes destinés à évaluer des candidats, ce qui impose supervision humaine, information des candidats et conservation des journaux. Le règlement « Digital Omnibus » de juillet 2026 reporte ces obligations au 2 décembre 2027, selon les analyses d'avocats, sans les supprimer. Faites valider votre situation par un juriste.