L’IA générative a changé la valeur d’un test de code chronométré. Chez Anthropic, Felix Rieseberg, responsable technique, a abandonné les entretiens de codage classiques pour examiner des prototypes capables de révéler le jugement produit, l’empathie utilisateur et la capacité à transformer une idée en résultat concret. Son équipe a notamment vu deux ingénieurs relativement nouveaux construire en un week-end un prototype d’interface graphique pour Claude Code, dont la première version publique a été livrée environ huit jours plus tard.
Cette évolution ne signifie pas que les compétences techniques disparaissent. Elle impose de les évaluer autrement. La méthode la plus solide consiste à examiner le problème choisi, la manière dont l’IA est utilisée, la qualité du code produit, la capacité à vérifier ses résultats et la vitesse à laquelle un prototype devient utile.
Pourquoi le test de code classique mesure moins bien les compétences
Un exercice court mesure surtout la capacité à résoudre un problème artificiel dans un environnement contraint. Avec un assistant d’IA, il mesure aussi la capacité à formuler une demande, à corriger une réponse et à vérifier rapidement le résultat.
Felix Rieseberg estime que Claude réussit désormais des exercices courts en React et des questions en langage assembleur avec un niveau qui réduit la valeur discriminante de ces tests. Un candidat peut obtenir une solution fonctionnelle sans démontrer qu’il sait choisir une architecture, comprendre un besoin utilisateur ou maintenir un logiciel dans le temps.
L’évaluation doit donc quitter le seul terrain de la production de lignes de code. Elle doit observer le raisonnement qui précède le code et les contrôles qui suivent sa génération.
À retenir : l’IA ne rend pas les compétences techniques inutiles. Elle rend insuffisant un test qui ne vérifie que la capacité à écrire rapidement une solution isolée.
Un test traditionnel conserve toutefois une utilité dans certains cas. Il peut vérifier la compréhension d’un algorithme, la lecture d’un code existant ou la capacité à diagnostiquer un bug. Il devient problématique lorsqu’il est utilisé comme indicateur unique de la valeur d’un développeur.
La méthode 2023 : évaluer un prototype plutôt qu’une solution parfaite
La méthode la plus pertinente consiste à proposer un problème concret, limité et relié à un objectif métier. Le candidat doit produire un prototype fonctionnel, expliquer ses choix et montrer ce qu’il ferait pour transformer cette première version en produit fiable.
Le sujet doit tenir dans un périmètre réduit. Une fonctionnalité, un parcours utilisateur ou une automatisation ciblée suffit. L’objectif n’est pas de recréer une application complète, mais de rendre visible la qualité des décisions prises sous contrainte.
1. Partir d’un objectif métier
Le brief doit commencer par un résultat attendu, et non par une technologie imposée. Par exemple, « réduire le temps nécessaire pour rechercher une information dans un catalogue » donne davantage de matière à évaluer que « créer une application React avec une API REST ».
Un bon sujet contient quatre éléments :
- un utilisateur clairement identifié ;
- un problème observable ;
- une contrainte de temps ou de périmètre ;
- un résultat que le prototype doit rendre mesurable.
Cette formulation permet d’évaluer la capacité à distinguer une demande réelle d’une simple liste de fonctionnalités. Elle montre aussi si le candidat sait renoncer à des développements secondaires pour livrer une première version cohérente.
2. Fixer une durée courte mais réaliste
Le prototype doit être limité dans le temps. Le modèle cité par Rieseberg repose sur l’idée d’un travail concentré sur un week-end, suffisamment long pour produire une démonstration et suffisamment court pour empêcher la construction d’un projet disproportionné.
La durée doit être identique pour tous les candidats. Le recruteur doit préciser ce qui est autorisé : assistant d’IA, documentation en ligne, bibliothèques open source ou outils de génération de code. Une règle claire évite de confondre la performance technique avec la capacité à interpréter des consignes ambiguës.
3. Demander une démonstration exploitable
Un dépôt qui compile ne suffit pas. Le candidat doit fournir une démonstration du parcours principal, quelques instructions d’installation et une courte note expliquant les limites connues.
Le livrable peut comprendre :
- une interface ou une commande exécutable ;
- un jeu de données de démonstration ;
- des tests sur les fonctions critiques ;
- une note d’architecture ;
- une liste des décisions reportées.
La qualité du prototype se juge alors sur son utilité immédiate et sur la clarté de sa trajectoire de développement. Une solution simple, bien cadrée et vérifiable peut être supérieure à une application plus ambitieuse mais fragile.
Ce qu’il faut observer pendant l’utilisation de l’IA
L’outil d’IA n’est pas seulement un générateur de code. Il devient un environnement de travail dont il faut évaluer la maîtrise.
Le premier critère est la formulation du problème. Un candidat solide décrit les entrées, les sorties, les cas limites et les critères de réussite avant de demander une implémentation. Il ne délègue pas à l’IA une question qu’il n’a pas encore clarifiée.
Le deuxième critère est la décomposition. Une demande vague produit souvent une solution difficile à contrôler. Une démarche plus robuste consiste à séparer l’interface, la logique métier, la persistance, les tests et la gestion des erreurs.
Le troisième critère est la vérification. Le candidat doit être capable d’identifier une réponse plausible mais incorrecte, de reproduire un bug et de demander une correction précise.
Les signaux positifs
- Le candidat définit un résultat attendu avant de générer du code.
- Il fournit à l’IA un contexte technique précis.
- Il lit les fichiers produits au lieu de les accepter automatiquement.
- Il écrit ou exécute des tests sur les fonctions importantes.
- Il vérifie les entrées invalides et les erreurs réseau.
- Il explique les compromis entre rapidité, simplicité et robustesse.
- Il sait supprimer une fonctionnalité qui détourne le prototype de son objectif.
Les signaux faibles
- Le candidat empile des bibliothèques sans expliquer leur rôle.
- Il corrige les erreurs au hasard jusqu’à obtenir un résultat visuel.
- Il ne peut pas décrire le fonctionnement des fonctions générées.
- Il ignore les risques liés aux données, aux permissions ou aux secrets.
- Il confond une interface réussie avec un produit terminé.
L’évaluation ne doit pas pénaliser l’usage de l’IA. Elle doit distinguer un usage contrôlé d’une délégation aveugle. La question utile n’est pas « combien de code a été écrit par l’IA ? », mais « quelles décisions le candidat est-il capable de défendre et de vérifier ? ».
Une grille d’évaluation centrée sur la valeur produite
Une grille commune réduit les biais entre évaluateurs. Elle doit donner davantage de poids au problème traité et à la fiabilité de la solution qu’au volume de code livré.
| Critère | Ce qui est évalué | Indice concret |
|---|---|---|
| Compréhension du besoin | Capacité à reformuler le problème | Objectif utilisateur explicite |
| Choix du périmètre | Aptitude à prioriser | Une fonctionnalité principale terminée |
| Usage de l’IA | Qualité des demandes et des contrôles | Prompts contextualisés, corrections vérifiées |
| Qualité technique | Lisibilité, structure et maintenabilité | Code organisé, dépendances justifiées |
| Fiabilité | Gestion des erreurs et tests | Cas limites couverts |
| Expérience utilisateur | Cohérence du parcours principal | Démonstration compréhensible |
| Jugement produit | Pertinence des arbitrages | Fonctionnalités secondaires écartées |
| Communication | Capacité à expliquer le travail | README et présentation structurés |
Une pondération simple peut attribuer 20 % à la compréhension du besoin, 15 % au périmètre, 20 % à la qualité technique, 15 % à la fiabilité, 15 % à l’expérience utilisateur et 15 % à la communication. Cette répartition fait du prototype un objet d’évaluation complet, sans réduire la technique à un critère secondaire.
Les évaluateurs doivent noter séparément le résultat obtenu et le raisonnement observé. Un prototype imparfait peut révéler une excellente méthode si les limites sont identifiées avec précision. À l’inverse, une démonstration très aboutie peut masquer une architecture impossible à maintenir.
Comparer plusieurs formats de test sans recréer un examen artificiel
Aucune méthode ne convient à tous les postes. Le choix dépend du niveau d’autonomie attendu et du type de logiciel construit.
| Format | Durée indicative | Compétence principale observée | Livrable |
|---|---|---|---|
| Exercice algorithmique | 45 à 90 minutes | Raisonnement formel | Solution commentée |
| Correction d’un dépôt existant | 60 à 120 minutes | Diagnostic et maintenance | Correctif testé |
| Prototype orienté produit | Un week-end | Priorisation et exécution | Démonstration fonctionnelle |
| Revue d’architecture | 45 à 60 minutes | Conception et compromis | Schéma expliqué |
| Présentation d’un projet personnel | 30 à 45 minutes | Ownership et communication | Démonstration et retour critique |
L’exercice algorithmique conserve une place pour les postes qui exigent une forte maîtrise des structures de données ou de la complexité. Il ne devrait cependant pas remplacer une évaluation du travail quotidien, surtout lorsque le poste implique des interfaces, des intégrations, du débogage ou des arbitrages produit.
La correction d’un dépôt existant est souvent plus proche de la réalité professionnelle. Elle permet d’observer la lecture d’un système imparfait, la recherche de la cause d’un problème et la capacité à limiter le risque d’une modification.
Le prototype orienté produit est adapté aux postes où l’initiative compte. Il révèle si le candidat sait passer d’une idée à une démonstration sans attendre un cahier des charges complet.
Le prototype Anthropic comme modèle d’évaluation
L’exemple cité par Felix Rieseberg illustre précisément ce que le test de prototype peut révéler. Anthony Morris et Alice Zhao, deux ingénieurs relativement nouveaux, ont construit en un week-end une interface graphique pour Claude Code, alors que l’outil était principalement utilisé en ligne de commande. La première version publique a suivi environ huit jours plus tard.
Rieseberg présente cet exemple comme une démonstration de l’intérêt d’un regard neuf. Des utilisateurs habitués à un outil peuvent accepter ses limites comme normales. Des personnes arrivées plus récemment peuvent repérer une friction que les utilisateurs historiques ne voient plus.
Cette observation doit être transposée avec prudence dans un processus de recrutement. Il ne suffit pas de demander une idée originale. Il faut vérifier si elle répond à un besoin réel, si le candidat a compris les utilisateurs et si le prototype permet de tester l’hypothèse principale.
Les questions à poser après la démonstration
- Quel problème avez-vous choisi de résoudre ?
- Pour quel utilisateur ce problème est-il prioritaire ?
- Quelle hypothèse votre prototype permet-il de tester ?
- Quelle réponse de l’IA avez-vous dû corriger ?
- Quelle partie du code vous inspire le moins confiance ?
- Que supprimeriez-vous si le délai était réduit de moitié ?
- Quel test ajouteriez-vous avant une mise en production ?
- Quelle mesure indiquerait que la fonctionnalité fonctionne réellement ?
Ces questions déplacent l’entretien du récit vers la preuve. Elles permettent aussi de détecter un travail entièrement produit par l’IA sans compréhension suffisante de l’architecture ou des risques.
À retenir : le prototype ne remplace pas l’entretien technique, il transforme son centre de gravité. L’échange porte moins sur la récitation d’une solution que sur les décisions prises pour rendre cette solution utile et fiable.
Les limites à corriger avant d’adopter cette méthode
Un prototype peut favoriser les candidats qui disposent de davantage de temps, d’équipement ou d’expérience avec les outils d’IA. Pour rester équitable, l’entreprise doit définir la durée, les outils autorisés et les critères avant de lancer l’évaluation.
Le sujet doit également éviter le travail gratuit. Un exercice destiné à un recrutement doit rester fictif ou suffisamment générique pour ne pas produire une fonctionnalité directement exploitable par l’entreprise sans rémunération.
La protection des données est un autre point essentiel. Le candidat ne doit pas envoyer de code confidentiel, de données personnelles ou de secrets d’infrastructure dans un assistant externe. Le brief doit préciser les données disponibles et les informations interdites.
Enfin, l’évaluation par prototype peut survaloriser la présentation. Une interface séduisante ne garantit ni la solidité du code ni la capacité à maintenir le système. La grille doit donc distinguer l’expérience utilisateur, la fiabilité et la qualité de conception.
Pour limiter les biais, plusieurs évaluateurs doivent examiner le même livrable avec une grille identique. Les notes doivent s’appuyer sur des éléments observables : tests exécutés, choix expliqués, erreurs corrigées et limites reconnues.
Notre avis : remplacer le test unique par une preuve de travail contrôlée
Le test de code chronométré ne devrait plus décider seul de la compétence d’un développeur. L’IA a abaissé le coût de production d’une première solution, ce qui rend plus précieuses la définition du problème, la priorisation, la vérification et la capacité à relier le code à un résultat utilisateur.
La méthode la plus convaincante combine un court exercice de diagnostic, un prototype limité et un entretien de revue. Elle conserve une vérification technique tout en observant le travail qui ressemble réellement à celui d’une équipe produit.
L’exemple d’Anthropic montre pourquoi les organisations peuvent s’intéresser aux prototypes : deux ingénieurs relativement nouveaux ont transformé en un week-end une idée d’interface en démonstration, puis en première version publique environ huit jours plus tard. La leçon n’est pas que l’ancienneté ne compte plus. Elle est que l’initiative, le regard utilisateur et la vitesse d’apprentissage deviennent visibles lorsque l’évaluation porte sur un résultat concret.
Dans les six prochains mois, les processus les plus crédibles seront probablement ceux qui demanderont moins de récitation et davantage de preuves : un problème bien choisi, une solution testable, un usage maîtrisé de l’IA et une explication honnête des limites. La question décisive ne sera plus seulement de savoir si un candidat sait coder, mais quel problème il choisit de résoudre et comment il démontre que sa solution mérite d’être utilisée.