Test Tech Lead sans Internet : que mesure-t-on ?

Un test fermé peut donner l’apparence d’une mesure précise tout en évaluant surtout la restitution d’un référentiel composite. Lorsque l’IA peut fabriquer ce référentiel, produire la réponse attendue et lui attribuer ensuite 100/100, la question n’est plus seulement de savoir si le candidat connaît la technique. Il faut demander ce que le dispositif mesure réellement.

Résumé

Cette étude exploratoire part d’un cas de recrutement anonymisé pour un poste de Tech Lead : une épreuve écrite fortement contrainte, sans Internet, sans documentation et sans intelligence artificielle, combinant architecture, revue de code, fiabilité transactionnelle, incident de production, stratégie technique, indicateurs de pilotage et gouvernance de l’IA.

Nous avons d’abord replacé cette configuration parmi 26 familles publiques d’évaluations techniques et confronté son principe aux travaux sur l’analyse de poste, les échantillons de travail, le stress en entretien, la recherche d’information des développeurs et la notation par grands modèles de langage. Nous avons ensuite demandé à une IA de produire deux tests de 120 minutes : l’un à partir du seul intitulé « Tech Lead », l’autre à partir d’une fiche de poste fictive détaillée. Trois modèles ont passé les deux tests comme candidats. Les six copies anonymisées ont été corrigées séparément par trois modèles, soit 18 évaluations.

Selon le modèle, les copies ont été produites en moins de deux minutes à environ trois minutes et demie, pour environ 2 000 à 4 500 mots chacune. Les meilleurs résultats ont saturé les barèmes à 100/100. À l’inverse, une même copie a reçu de 72,5 à 93/100 selon le correcteur, soit 20,5 points d’écart et un changement de verdict professionnel. Dans ce pilote, la fiche de poste a réduit les hypothèses hors périmètre, mais a rendu l’épreuve plus longue et n’a pas supprimé les critères non sourcés, les solutions privilégiées ni les seuils non calibrés.

Notre conclusion n’est pas que l’IA serait « un meilleur Tech Lead » qu’un humain, ni que tout test fermé serait inutile. Elle est plus circonscrite : une épreuve composite, encyclopédique et privée des outils du travail réel risque de mesurer la mémoire disponible, la vitesse de rédaction et la conformité au langage du corrigé davantage que le jugement professionnel. Pour rester défendable, une évaluation senior doit partir des tâches du poste, limiter le nombre de compétences observées, autoriser les ressources réellement utilisées, accepter plusieurs solutions démontrées et compléter l’écrit par une défense interactive.

Les résultats en un coup d’œil

2 tests générés : l’un à partir du seul intitulé, l’autre à partir d’une fiche de poste fictive détaillée ;
3 modèles candidats, soit 6 copies principales ;
3 modèles correcteurs, soit 18 évaluations ;
environ 2 000 à 4 500 mots produits par copie en moins de quatre minutes ;
20,5 points d’écart au maximum pour une même copie selon le correcteur ;
aucune comparaison humaine directe : les résultats décrivent un pilote automatisé, pas la supériorité d’une IA sur un professionnel.

1. Le paradoxe du métier

Le développement logiciel s’est simplifié et complexifié en même temps.

Les langages, frameworks, services cloud et bibliothèques ont élevé le niveau d’abstraction. Il est devenu possible de livrer rapidement ce qui aurait exigé autrefois beaucoup de code bas niveau. Mais cette simplification locale a produit une complexité systémique : bases de données, autorisations, API, files de messages, cloud, observabilité, sécurité, coûts, conformité, expérience utilisateur et, désormais, assistants d’IA.

Le développeur n’a donc pas simplement « moins besoin de connaître la syntaxe ». Il doit comprendre davantage de frontières, de contrats et de modes d’échec. Son travail s’est déplacé du seul comment coder vers le quoi assembler, pourquoi, avec quelles garanties et comment le vérifier.

Cette évolution transforme aussi l’accès au savoir : livres et manuels locaux hier, moteurs de recherche et communautés ensuite, documentation synthétisée et assistants intégrés aujourd’hui. Chercher, filtrer, contextualiser et vérifier l’information ne constitue pas un contournement du métier. C’est une partie du métier. Une étude de 2025 sur la recherche d’information en développement logiciel décrit précisément l’intégration croissante des assistants d’IA à cette activité, tout en soulignant que les connaissances fondamentales restent nécessaires pour contrôler leurs réponses (Al Haque et al., 2025).

C’est ici que naît le problème : si le travail réel repose sur la navigation dans un système, la consultation de références, le dialogue avec l’équipe et la validation d’hypothèses, que mesure une épreuve senior qui retire tous ces appuis et demande une couverture encyclopédique en quelques dizaines de minutes ?

2. Le cas qui a déclenché l’étude

Le point de départ est une expérience réelle de recrutement rapportée par l’auteur. Pour protéger toutes les parties, l’entreprise, le secteur précis, les applications, le code, les pondérations détaillées et les formulations originales ne sont ni publiés ni attribués. Les scénarios utilisés ensuite ont été reconstruits dans des contextes fictifs. Le témoignage sert à formuler la question ; les résultats chiffrés de l’article proviennent du protocole expérimental conservé.

Le fait pertinent n’est pas l’identité de l’organisation. C’est la configuration du test : une durée très inférieure à celle de notre protocole expérimental, une réponse écrite et l’interdiction des ressources externes. L’épreuve réunissait plusieurs familles de questions : concevoir une architecture, revoir un flux backend critique, hiérarchiser des anomalies, répondre chronologiquement à un incident, proposer une stratégie d’évolution logicielle, définir des priorités et des indicateurs, puis encadrer l’usage de l’IA.

Chaque thème peut être utile dans certains postes. Leur addition pose cependant trois questions :

ces compétences correspondent-elles toutes aux tâches réelles de ce poste précis ?
peuvent-elles être observées sérieusement dans le temps disponible ?
leur restitution sans documentation ressemble-t-elle au travail quotidien d’un Tech Lead ?

L’étude ne cherche donc pas à noter l’entreprise ni à reconstituer son test. Elle utilise ce cas comme signal initial pour examiner une catégorie plus générale de dispositifs.

3. Ce que la littérature permet déjà d’établir

3.1 Un test doit partir du travail, pas du titre

L’U.S. Office of Personnel Management rappelle qu’une analyse de poste sert à identifier les tâches et les compétences nécessaires, puis à démontrer leur lien avec la procédure de sélection (OPM, Job Analysis). Son guide de conception recommande plusieurs méthodes complémentaires, une procédure standardisée et des preuves de validité montrant que les personnes bien classées par l’instrument réussissent effectivement mieux dans le poste (OPM, Designing an Assessment Strategy).

Un échantillon de travail n’est pas seulement un exercice « qui a l’air professionnel ». Il doit faire accomplir une tâche identique ou très proche de celle du poste, dans un environnement que l’on cherche à reproduire aussi fidèlement que possible (OPM, Work Samples and Simulations). Si les ressources habituelles sont présentes au travail mais interdites dans le test, le dispositif modifie déjà la compétence observée.

Le titre « Tech Lead » ne résout pas ce problème. Selon l’entreprise, il peut désigner une développeuse très expérimentée, un responsable d’architecture locale, un facilitateur technique, un manager de proximité ou une combinaison de ces rôles. SFIA décrit des niveaux de responsabilité et des compétences adaptables au contexte ; il ne fournit pas un corrigé universel du titre. À son niveau 6, le cadre insiste sur l’influence, la responsabilité, la décision, la collaboration, le risque et la communication, au-delà de la seule connaissance technique (SFIA 9, Level 6). Les recherches sur le leadership logiciel vont dans le même sens : la diffusion de l’information par les responsables techniques est associée à la productivité et à la qualité, tandis que certaines activités de leadership peuvent être partagées par l’équipe plutôt que détenues par un seul titre (Ehrlich & Cataldo, 2014 ; Gren & Ralph, 2022).

3.2 Retirer les outils change la tâche

Dans un essai contrôlé auprès de 48 étudiants, Behroozi et ses collègues ont observé qu’une résolution technique sous observation réduisait fortement la performance et augmentait stress et charge cognitive. Le retrait de l’IDE, de l’autocomplétion et de la recherche déplaçait également l’effort vers le rappel de détails syntaxiques (Behroozi et al., 2020).

Cette étude est limitée : petit échantillon, population étudiante, un exercice et un format whiteboard. Elle ne prouve pas que tous les entretiens réduisent toute performance. Elle montre en revanche qu’il serait imprudent de traiter les conditions de passation comme nécessairement neutres.

Les processus publics des entreprises confirment d’ailleurs qu’une politique ouverte est possible. GitLab décrit un exercice de revue et d’amélioration d’une merge request préparé à l’avance, suivi d’un échange collaboratif, et indique encourager l’usage de l’IA. Ce choix n’est pas une preuve de supériorité du format. Il montre seulement qu’autoriser l’outil peut faire partie du dispositif lorsque l’entreprise veut observer son usage plutôt que son absence.

3.3 L’IA intervient déjà avant la décision finale

À partir d’entretiens avec 22 professionnels du recrutement, Surati, Bellini et Black décrivent comment l’IA générative influence les qualifications, les questions et les rubriques utilisées dans les processus de recrutement. L’enjeu n’est pas seulement une décision finale automatisée : l’IA peut devenir l’architecte discret du cadre à travers lequel les candidatures seront ensuite jugées (Surati, Bellini & Black, 2026).

Cela change la nature du risque. Une erreur dans une réponse d’IA est visible. Une hypothèse introduite dans un barème peut, elle, prendre l’apparence d’un standard professionnel puis se répéter dans toutes les corrections.

La notation par LLM n’est pas nécessairement inutilisable. Stockdale, Hickman et Liu montrent, sur deux jeux de données d’entretiens, que certains ensembles de modèles récents, guidés par une description détaillée du construit, peuvent produire des propriétés psychométriques comparables à celles de notateurs humains isolés ou de modèles supervisés. Mais leurs résultats montrent aussi que le modèle, le prompt, les paramètres et le nombre de notateurs influencent les scores ; les auteurs appellent à la prudence pour les évaluations à fort enjeu (Stockdale, Hickman & Liu, 2026).

Autrement dit, la bonne question n’est ni « l’IA peut-elle corriger ? » ni « faut-il interdire l’IA ? ». Elle est : quel construit est évalué, par quel dispositif, avec quelle stabilité et quelle validation ?

4. Notre protocole exploratoire

Nous avons organisé le travail en quatre blocs.

4.1 Une cartographie des formats existants

Nous avons documenté 26 familles d’épreuves : questionnaire, exercice algorithmique, débogage, revue de code, extension d’un dépôt, conception d’API, system design, réponse à incident, jugement situationnel, pair programming, entretien structuré, étude de cas, projet à domicile, période d’essai rémunérée, entre autres. Ce nombre est notre inventaire analytique, pas une taxonomie officielle.

Nous avons également séparé ce que le terme « test technique » mélange souvent : le type d’exercice, la durée, l’interaction, l’environnement, les ressources autorisées, la méthode de notation et la place du test dans l’ensemble du recrutement.

La revue exploratoire structurée a privilégié les recherches empiriques, les documents institutionnels et les processus publics. Dans le corpus examiné, nous n’avons trouvé aucune validation publiée établissant qu’un examen composite très court, sans documentation, couvrant architecture, code review, incident, leadership et gouvernance de l’IA prédit la performance d’un Tech Lead. Une absence de preuve n’est pas une preuve d’inefficacité ; elle signifie seulement que notre corpus ne permet pas de présenter ce format comme scientifiquement validé.

4.2 Deux conditions de génération

Un même modèle a produit deux tests de 120 minutes dans des conversations distinctes :

condition A — intitulé seul : créer un test pour un « Tech Lead », sans description de stack, d’équipe, de responsabilités ni de contexte ;
condition B — poste défini : créer un test pour un Tech Lead d’une entreprise fictive de réservation B2B, avec six composants, une équipe en croissance, des responsabilités et des frontières de rôle explicites, ainsi que les outils autorisés dans le travail réel.

La durée expérimentale de 120 minutes est volontaire. Elle ne reproduit pas la durée exacte du témoignage, renforce son anonymisation et donne au dispositif une condition plus favorable que le cas de départ.

Chaque réponse initiale a ensuite fait l’objet de cinq relances identiques portant sur les sources, les nombres imposés, les solutions alternatives, les critères obligatoires et la faisabilité.

4.3 Trois modèles candidats, trois modèles correcteurs

Trois modèles déclarés lors des passations — GPT-5.6 Sol, Gemini 3.1 Pro et Claude Sonnet 5 en raisonnement moyen — ont chacun passé A et B comme candidats Tech Lead, dans une conversation séparée et sans Web. Six copies ont été anonymisées : A17, A42, A83, B19, B46 et B88.

Les mêmes modèles ont ensuite corrigé les six copies avec les barèmes initiaux, sans connaître l’identité du modèle candidat. Nous avons ainsi obtenu 18 évaluations automatisées.

Les temps de génération sont des temps observés et rapportés lors des passations, non des mesures instrumentées à la milliseconde : moins de deux minutes pour Gemini, deux à trois minutes pour Claude, environ trois minutes vingt à trois minutes trente pour GPT.

Pour rendre cette première comparaison homogène, les outils externes ont été fermés aux modèles candidats, y compris dans B où le sujet prévoyait normalement leur usage. Cette déviation volontaire permet de comparer les productions autonomes, mais elle signifie que la passation de B ne reproduit pas entièrement sa propre politique de ressources.

4.4 Une cartographie du parcours humain

Enfin, nous avons relié les thèmes demandés à des cours, référentiels et certifications représentatifs. Le but n’était pas de prescrire une collection de badges, mais d’estimer la largeur du corpus qu’un humain devrait acquérir pour répondre exhaustivement sans ressources.

5. Ce que le générateur a produit

5.1 Avec un titre seul, le modèle invente le poste

Dans A, le modèle transforme « Tech Lead » en un rôle précis : SaaS B2B, backend transactionnel, paiements, production, croissance rapide et équipe de huit développeurs. Il attribue ensuite des points à l’idempotence, à l’Outbox transactionnelle, au monolithe modulaire, au Strangler Pattern, aux états de paiement, aux SLO et aux tests de caractérisation.

Ces sujets sont techniquement pertinents. Mais ils ne proviennent d’aucune description de poste. Le modèle a choisi un métier, puis a noté les candidats comme si ce choix était une définition préalable.

Il a aussi associé des plages numériques à des étiquettes telles que « bon Tech Lead » ou « Staff-like », sans données de calibration reliant ces scores à une performance réelle.

5.2 La fiche de poste améliore la cible, pas automatiquement la mesure

Dans B, le test reprend beaucoup mieux le produit fictif, PostgreSQL, les problèmes de réservation et de notification, la croissance de l’équipe, la documentation des décisions et la collaboration avec produit et plateforme. Les outils réels — documentation, Web et assistant approuvé — sont autorisés.

La fiche de poste réduit donc nettement l’invention et le dépassement du rôle. Mais B devient aussi plus lourd : son sujet contient environ 63 % de mots de plus que A et comporte six parties, avec plusieurs recouvrements entre concurrence, idempotence, notification, incident et tests.

Dans ce pilote, le contexte a amélioré l’adéquation de contenu. Il n’a pas créé de sources, validé les pondérations, calibré les seuils ni garanti la faisabilité.

5.3 La contestation modifie profondément le corrigé

Dans les deux conditions, les relances obligent le modèle à reconnaître que plusieurs nombres, poids, classifications et solutions « attendues » résultent de choix de conception, non de normes professionnelles.

Il admet notamment qu’une clé d’idempotence, une Outbox, une contrainte d’exclusion ou un monolithe modulaire peuvent être de bonnes solutions sans être les seules. Les corrigés révisés se déplacent alors des noms de patterns vers les propriétés : protéger un invariant, traiter une panne partielle, rendre un rejeu sûr, expliciter un compromis, limiter l’impact d’un incident.

C’est un résultat important : le premier barème paraît normatif ; la contestation révèle qu’il était en partie conventionnel. Une personne non experte utilisant le corrigé initial aurait peu de moyens de détecter cette différence.

6. Six copies produites en quelques minutes

Modèle candidat	Test A	Test B	Volume total	Temps rapporté par copie
GPT-5.6 Sol	3 110 mots	4 521 mots	7 631 mots	≈ 3 min 20 à 3 min 30
Claude Sonnet 5 Moyen	3 473 mots	2 833 mots	6 306 mots	2 à 3 min
Gemini 3.1 Pro	1 984 mots	2 417 mots	4 401 mots	moins de 2 min

Les six copies mobilisent architecture, concurrence SQL, idempotence, cohérence éventuelle, observabilité, réponse à incident, stratégie de tests et leadership. Les meilleures décrivent les mécanismes avec suffisamment de précision pour saturer le barème.

Ce résultat ne signifie pas que les modèles possèdent une expérience de production. Ils n’ont subi aucun incident, porté aucune astreinte et assumé aucune conséquence financière. Ils produisent une synthèse linguistique extrêmement rapide d’un corpus auquel ils ont été exposés pendant leur entraînement.

Mais pour le recrutement, le problème demeure : si le test récompense principalement la couverture encyclopédique, l’outil dispose d’un avantage structurel que l’épreuve interdit au candidat humain.

7. Une même copie, plusieurs niveaux professionnels

Voici la matrice complète des corrections croisées :

Copie	Modèle candidat révélé après correction	Test	Correcteur GPT	Correcteur Gemini	Correcteur Claude	Étendue
A17	Gemini	A	80	96	85	16
A42	GPT	A	100	100	100	0
A83	Claude	A	94	98	97	4
B19	Claude	B	84	95	94	11
B46	Gemini	B	72,5	93	86	20,5
B88	GPT	B	100	100	100	0
Moyenne du correcteur			88,42	97,00	93,67

Trois observations ressortent.

Premièrement, le changement de correcteur modifie parfois la catégorie professionnelle. A17 passe de « bon Tech Lead » à « excellent/Staff-like » ; B19 et B46 passent d’un résultat intermédiaire à « très solide » selon la grille utilisée. La copie, elle, ne change pas.

Deuxièmement, les copies GPT restent à 100 avec les trois correcteurs. Cela peut refléter leur qualité et leur complétude ; cela peut aussi traduire un effet plafond du barème. Lorsqu’un instrument attribue le maximum à plusieurs sorties, il ne peut plus distinguer les performances au sommet.

Troisièmement, l’hypothèse d’un favoritisme automatique envers sa propre famille de modèle n’est pas confirmée comme règle générale. Claude ne favorise pas ses propres copies. Gemini valorise beaucoup plus les copies Gemini, mais il est aussi globalement plus généreux. Le résultat robuste n’est donc pas « chaque IA préfère ses réponses ». Il est plus simple : le verdict dépend sensiblement du correcteur et de sa configuration.

Cette dispersion ne démontre pas que des évaluateurs humains formés seraient nécessairement plus stables : aucune correction humaine comparable n’a été recueillie. Elle établit seulement que, dans notre configuration, une note automatisée unique ne peut pas être traitée comme un verdict invariant.

Une copie illustre particulièrement la fermeture du référentiel. Plusieurs candidats perdent des points pour ne pas avoir nommé explicitement le « monolithe modulaire », même lorsqu’ils proposent une évolution incrémentale défendable. Les correcteurs reconnaissent ensuite que ce critère est contestable. La grille a transformé une solution utile en mot de passe.

8. Le test mobilise au moins neuf domaines

Ce regroupement est lui aussi analytique. Il sert à mesurer la largeur du corpus demandé ; il ne prétend pas définir neuf métiers étanches ni le profil universel d’un Tech Lead.

Domaine	Exemples d’attendus	Formation structurée estimée	Parcours représentatif
Architecture logicielle	modularisation, évolution, découpage, ADR	60–100 h	iSAQB CPSA-F puis pratique multi-systèmes
Systèmes distribués et paiements	Outbox, saga, retries, statut incertain, réconciliation	120–200 h	cours de systèmes distribués + expérience transactionnelle
Bases de données	isolation, verrouillage, contraintes, pools, deadlocks	80–140 h	cours avancé de bases de données + PostgreSQL réel
Sécurité applicative	injection, autorisation, multi-tenant, logs sensibles	100–180 h	OWASP/PortSwigger ; CSSLP pour une spécialisation forte
Cloud et déploiement	scalabilité, isolation, canary, rollback, coûts	120–200 h	certification cloud avancée ou expérience équivalente
SRE et incidents	SLI/SLO, tracing, Incident Commander, mitigation	100–160 h	corpus Google SRE + incidents et exercices réels
Tests et fiabilité	concurrence réelle, panne, retry, stratégie par risque	60–100 h	ISTQB ou équivalent + automatisation en production
Leadership et produit	priorisation, KPI, dette, revue, autonomie, communication	60–100 h	pratique d’équipe, mentorat et formation au leadership
Gouvernance de l’IA	confidentialité, validation, traçabilité, systèmes critiques	40–80 h	NIST AI RMF, OWASP GenAI, ISO/IEC 42001 selon le rôle

L’addition brute de ces plages donne 740 à 1 260 heures. Après retrait d’environ 20 % pour les contenus qui se recouvrent entre architecture, cloud, sécurité, SRE et tests, notre estimation analytique devient 600 à 1 000 heures de formalisation spécialisée, en plus d’un socle informatique, et quatre à sept années de pratique pertinente. Pour une personne déjà développeuse senior, le seul volume de formation correspond à environ 14 à 23 mois à dix heures par semaine.

Ces chiffres ne sont ni des durées officielles ni une estimation individuelle validée : les plages par domaine sont notre codage du corpus de cours, de certifications et de compétences mobilisées. Leur fonction est de rendre visible l’ordre de grandeur et le chevauchement des matières. Quelques repères officiels montrent néanmoins l’échelle : le CPSA-F recommande au moins 18 mois d’expérience pratique ; le niveau avancé iSAQB demande trois ans et la participation à au moins deux systèmes ; AWS recommande deux années ou plus avant Solutions Architect Professional ; Google Cloud recommande trois ans d’expérience dans l’industrie, dont un an sur des systèmes de production Google Cloud ; ISC2 exige quatre ans d’expérience pour CSSLP.

Le point n’est pas qu’un Tech Lead devrait posséder tous ces diplômes. C’est exactement l’inverse : nous n’avons identifié aucune certification unique couvrant cet ensemble, parce que l’épreuve juxtapose plusieurs spécialités.

9. Que mesure alors ce type de test ?

Il mesure certaines connaissances utiles. Repérer une race condition, protéger un paiement contre les doubles traitements ou restaurer un service avant une longue investigation sont de vrais signaux.

Mais il mesure simultanément autre chose :

la disponibilité immédiate d’un grand nombre de patterns en mémoire ;
la capacité à deviner les solutions privilégiées par le correcteur ;
la vitesse de lecture, de structuration et de rédaction ;
la tolérance au stress et aux changements rapides de domaine ;
la propension à répondre affirmativement malgré les informations manquantes ;
l’exposition préalable à un corpus particulier de systèmes distribués, cloud et SRE.

Ces dimensions peuvent contaminer la mesure du jugement professionnel. Dans le travail réel, un bon Tech Lead peut dire : « il manque le contrat du fournisseur », « je veux vérifier la sémantique de cette API », « faisons intervenir la personne qui exploite la base » ou « plusieurs architectures sont possibles selon le volume et le budget ». Dans un barème fermé, cette prudence peut ressembler à une réponse incomplète.

L’IA, au contraire, excelle à parcourir rapidement l’espace des réponses plausibles et à produire le vocabulaire attendu. Elle peut obtenir 100/100 sans pouvoir assumer la décision. Dans notre protocole, le score renseigne donc directement sur la conformité de la copie au référentiel, pas sur l’expérience qui se trouverait derrière cette copie.

10. Ce que nous pouvons conclure — et ce que nous ne pouvons pas

Conclusions soutenues par ce pilote

Un intitulé seul permet au générateur d’inventer silencieusement le contexte, puis de transformer ses hypothèses en critères de recrutement.
Une fiche de poste précise améliore nettement l’adéquation du contenu et la politique d’outils.
Cette précision ne garantit ni sobriété, ni traçabilité, ni calibration, ni pluralité des solutions.
Les contestations documentées révèlent que plusieurs nombres et solutions présentés comme attendus sont des choix locaux.
Des modèles peuvent produire en quelques minutes des copies exhaustives qui saturent le barème.
Un changement de correcteur automatisé peut déplacer une même copie de 20,5 points et modifier son verdict professionnel.
Le test étudié mobilise un corpus composite appartenant à au moins neuf domaines.

Le 100/100 de certaines copies ne prouve pas que l’instrument serait invalide pour sélectionner des humains. Il montre un effet plafond dans cette simulation : le barème n’a plus distingué les meilleures sorties produites par les modèles.

Conclusions que cette étude ne permet pas

affirmer que toutes les entreprises utilisent l’IA pour créer leurs tests ;
attribuer l’origine du test vécu à une IA ;
conclure que tous les tests techniques sont invalides ;
prouver qu’un humain échouerait ou qu’une IA travaillerait mieux qu’un Tech Lead ;
estimer la performance professionnelle future à partir des scores obtenus ;
démontrer un biais universel d’auto-préférence entre modèles ;
présenter les 600 à 1 000 heures comme une mesure scientifique individuelle ;
généraliser à partir de six copies et de trois modèles.

L’étude est exploratoire. Elle produit des mécanismes, des écarts et des hypothèses testables ; elle ne fournit pas une loi universelle du recrutement technique.

11. Comment construire une évaluation plus défendable

11.1 Commencer par le poste réel

Décrire les tâches, le niveau d’autonomie, la maturité de l’équipe, la responsabilité de production et les frontières avec plateforme, sécurité, produit et management. Chaque exercice doit être relié à une tâche importante et réellement attendue dès l’entrée dans le poste.

11.2 Limiter le périmètre

Choisir deux ou trois compétences critiques, plutôt que neuf domaines en compétition pour quelques minutes. Les autres peuvent être observées dans un entretien structuré, une discussion de parcours ou une étape séparée.

11.3 Reproduire les outils du travail

Si l’équipe utilise documentation, Internet, IDE et assistant approuvé, le test devrait en principe les autoriser. L’évaluation peut alors porter sur la recherche, la sélection des sources, la vérification du code généré et la traçabilité des choix. Une interdiction ciblée reste possible si la mémorisation d’une connaissance précise est réellement critique dès le premier jour, mais cette nécessité doit être justifiée.

11.4 Noter des garanties, pas des mots-clés

La grille devrait demander : l’invariant est-il protégé ? Le rejeu est-il sûr ? Le statut incertain est-il traité ? La décision est-elle réversible ? Le compromis est-il explicité ? Elle ne devrait pas imposer « Outbox », « Strangler » ou « monolithe modulaire » lorsqu’un autre mécanisme obtient la même propriété.

11.5 Séparer erreurs bloquantes et complétude

Une faille d’autorisation, un double paiement possible ou une décision dangereuse en incident peut être bloquante. L’oubli d’un pattern secondaire ou d’un KPI parmi dix ne devrait pas nécessairement invalider le candidat. Cette distinction augmente la valeur professionnelle de la correction.

11.6 Ajouter une défense orale

Une copie assistée ou non par IA ne suffit plus. Un entretien court peut demander au candidat de défendre une hypothèse, modifier sa solution après une nouvelle contrainte, identifier ce qu’il vérifierait et expliquer les limites du code ou du schéma produit. C’est là que deviennent visibles la compréhension, l’adaptation et la responsabilité.

11.7 Utiliser plusieurs signaux et calibrer les évaluateurs

Échantillon de travail, entretien structuré, expérience passée et discussion technique ne mesurent pas exactement la même chose. Les combiner réduit le poids d’une seule performance. Les évaluateurs doivent également corriger quelques copies communes, discuter les divergences et suivre leur accord dans le temps. Un total sur 100 n’est pas une validation.

11.8 Si l’IA participe à la création, conserver une piste d’audit

Pour chaque critère obligatoire, documenter : la tâche réelle correspondante, la source ou l’expertise utilisée, les solutions alternatives acceptées, le mode d’observation, la pondération et la personne qui a validé le choix. Séparer autant que possible le modèle qui génère du contenu de celui qui le révise ou le note.

12. Limites méthodologiques et prochaine réplication

Le pilote comporte une seule génération A/B du test, six copies principales et trois correcteurs automatisés. Les modèles, versions, prompts et paramètres peuvent évoluer. Les temps ont été rapportés, pas instrumentés. Les outils ont été fermés pendant la simulation de B alors que le sujet les autorisait. Deux agents GPT partageaient techniquement un espace de fichiers avec d’autres documents, même si leur tâche interdisait de les lire et que leur audit déclaré ne signale aucun accès ; l’isolation n’était donc pas forensique. Les passations externes ont été réalisées dans des conversations distinctes, mais leurs journaux techniques ne sont pas disponibles.

Nous n’avons pas fait passer les épreuves à des candidats humains et avons finalement renoncé à demander à trois Tech Leads de corriger intégralement les six copies : la charge de lecture aurait dépassé plusieurs heures par évaluateur et reproduit le problème de surcharge étudié.

La prochaine réplication utile n’est pas nécessairement un corpus plus volumineux d’IA. Elle devrait comparer, sur un nombre restreint de scénarios critiques :

une condition fermée et une condition avec documentation/IA déclarée ;
une réponse de modèle et une réponse humaine ;
un barème par patterns et un barème par propriétés ;
une correction automatisée et deux corrections humaines indépendantes ;
le score écrit et la performance lors d’une défense orale adaptative.

Les critères importants seraient le temps, l’accord entre évaluateurs, la détection des risques critiques, la qualité des demandes de clarification et la capacité à réviser une décision.

Conclusion

Le problème des tests techniques à l’ère de l’IA ne se résume pas à la triche. Il concerne la définition même de la compétence.

Un test peut être détaillé, cohérent, chiffré et impressionnant tout en reposant sur un poste inventé, des solutions préférées et des seuils sans calibration. Une IA peut ensuite produire en quelques minutes la réponse qui épouse ce référentiel, puis un autre modèle peut lui attribuer une note très différente.

La leçon n’est pas de supprimer l’évaluation technique. Elle est de la rendre plus proche du travail que l’on prétend observer.

Le rôle d’un Tech Lead n’est pas de réciter neuf spécialités sans documentation. Il est de reconnaître le risque, obtenir l’information manquante, mobiliser les bonnes personnes, vérifier les solutions et prendre une décision dont il accepte la responsabilité.

Si le test retire précisément ces comportements, sa précision numérique ne compense pas sa perte de réalisme.

Références principales

Al Haque, M. et al. (2025). The Evolution of Information Seeking in Software Development. FSE Companion.
Behroozi, M. et al. (2020). Does Stress Impact Technical Interview Performance?. ESEC/FSE.
Ehrlich, K. & Cataldo, M. (2014). The Communication Patterns of Technical Leaders. CSCW.
Gren, L. & Ralph, P. (2022). What Makes Effective Leadership in Agile Software Development Teams?. ICSE.
Ko, A. J. et al. (2006). An Exploratory Study of How Developers Seek, Relate, and Collect Relevant Information.
Stockdale, K., Hickman, L. & Liu, S. (2026). Scoring Employment Interviews With Large Language Models. Journal of Applied Psychology.
Surati, S., Bellini, R. & Black, E. (2026). Resume-ing Control: (Mis)Perceptions of Agency Around GenAI Use in Recruiting Workflows. ACM FAccT.
U.S. OPM. Job Analysis.
U.S. OPM. Designing an Assessment Strategy.
U.S. OPM. Work Samples and Simulations.
SFIA 9. Levels of responsibility: Level 6 — Initiate, influence.
SIOP. Considerations and Recommendations for the Validation and Use of AI-Based Assessments for Employee Selection.

Disponibilité des matériaux

Le protocole, les deux sujets expérimentaux, leurs corrigés, les six copies anonymisées, les 18 corrections et le registre de littérature ont été conservés séparément. Ils ne sont pas intégrés à cet article en raison de leur volume. Leur publication en annexes devra faire l’objet d’un dernier contrôle d’anonymisation et de droits de reproduction.

Note de transparence

L’auteur a personnellement participé au recrutement ayant déclenché la question de recherche. Cette position peut influencer le choix du sujet et l’interprétation ; elle est donc déclarée explicitement. Le témoignage initial sert uniquement de point de départ et n’entre pas dans les résultats chiffrés du pilote.

L’IA a été utilisée comme objet d’étude, générateur de scénarios, candidat simulé, correcteur simulé et assistant de structuration documentaire. Les observations chiffrées proviennent des sorties conservées. Les affirmations centrales ont été distinguées des interprétations, les limites ont été explicitées et les références principales ont été vérifiées sur leurs pages éditoriales ou institutionnelles. L’auteur reste responsable de la sélection des données, de leur interprétation et du texte publié.