Le code livré laisse une part de la compétence à vérifier
Supposons qu’un candidat vous présente un programme développé avec une assistance d’intelligence artificielle (IA), dont les tests passent. Vous devez décider s’il pourra prendre en charge ce code sur le poste ouvert. Nous proposons d’examiner ce qu’il sait diagnostiquer, corriger et expliquer, puis de relier ses réponses à une responsabilité attendue. Si ses réponses montrent qu’il peut assumer cette responsabilité, poursuivez l’évaluation avec les autres éléments du recrutement. Si un point reste incertain, vérifiez-le dans un exercice ciblé. Une exigence indispensable non satisfaite peut justifier de ne pas retenir le candidat, à condition que les conditions d’observation permettent ce jugement.
La réussite du programme et la compréhension du code par son auteur méritent un examen distinct. Dans une étude soumise en avril 2025, Yangtian Zi et ses collègues ont demandé à 32 étudiants débutants de prédire le comportement de code généré. Les étudiants ont réussi 52 des 160 tâches de compréhension examinées, soit 32,5 %. Ce résultat concerne ces étudiants et ces tâches, pas la proportion de développeurs professionnels qui comprendraient leur code.
L’assistance ne conduit toutefois pas systématiquement à une baisse de performance. Dans une expérience pédagogique publiée en 2023, Majeed Kazemitabaar et ses collègues ont étudié 69 novices âgés de 10 à 17 ans. L’accès à Codex améliorait la production pendant l’entraînement, sans diminution de performance observée lors des tâches de modification manuelle suivantes. Ces résultats différents invitent à regarder ce que le candidat démontre dans votre exercice, plutôt qu’à accepter ou rejeter son travail au seul motif qu’il utilise une IA.
L’enjeu pour vous est d’éviter une décision dont la justification dépasserait les observations disponibles. Un résultat correct laisse encore ouverte la question de la responsabilité que le candidat pourra assumer lorsque le comportement attendu change ou qu’un défaut apparaît.
Les règles de l’exercice donnent leur sens aux observations
Commencez par nommer ce que le développeur devra savoir faire dès son arrivée. Devra-t-il corriger un défaut avec les outils habituels de l’équipe, vérifier une proposition de l’assistant ou intervenir sans assistance sur une partie du code ? Ces attentes conduisent à des observations différentes. Choisissez une tâche représentative et annoncez le comportement attendu avant de juger la solution.
Le U.S. Office of Personnel Management (OPM) décrit les échantillons de travail comme des tâches similaires à celles du poste, adaptées aux compétences attendues à l’entrée. Sa recommandation distingue ces compétences de celles qui seront acquises après sélection. Si vous prévoyez de former le développeur à une bibliothèque, un échec sur cette bibliothèque inconnue ne devrait donc pas devenir à lui seul un motif de rejet. Cette recommandation américaine éclaire la conception de l’exercice, sans constituer une obligation française.
Nous proposons de fixer à l’avance les outils, l’assistance, la documentation, la durée et les relances autorisées. L’OPM recommande, pour les entretiens structurés, des questions identiques et une même échelle d’évaluation. Appliquée à votre exercice, cette logique conduit à définir les éléments attendus dans les réponses avant de rencontrer les candidats. Elle ne rend pas leurs conditions parfaitement équivalentes et ne valide pas votre barème.
Rendez également visibles les interventions : quelle proposition vient de l’assistant, quelle modification le candidat décide de conserver et quel indice l’évaluateur lui fournit. Une solution trouvée après une indication précise ne renseigne pas sur un diagnostic mené sans cette aide. La familiarité avec un assistant peut compter si le poste l’exige, mais elle ne doit pas remplacer la vérification de la compréhension du code.
Si l’autonomie sans IA est indispensable, prévoyez une séquence distincte, annoncée comme telle. Un exercice assisté ne permet pas, à lui seul, de conclure sur cette exigence. À l’inverse, lorsque le travail attendu utilise une assistance, observez aussi la manière dont le candidat vérifie les propositions de l’assistant.
Le diagnostic relie un symptôme à une hypothèse vérifiable
Prenons un cas explicitement hypothétique : une fonction doit sélectionner les commandes dont le montant atteint ou dépasse un seuil, mais une commande située exactement au seuil manque dans le résultat. Demandez au candidat de reproduire ce défaut et de préciser la sortie attendue. Vous cherchez d’abord à savoir s’il examine le même problème que vous.
Faites ensuite formuler une hypothèse sur la cause et proposer une vérification capable de la distinguer d’une autre. Le candidat peut soupçonner une condition de comparaison trop restrictive ou une commande absente des données reçues par la fonction. Examiner l’entrée, puis exécuter la fonction sur une commande connue située au seuil, permettrait de départager ces hypothèses. La démarche proposée porte sur une observation vérifiable, au-delà du nom d’un défaut possible.
Si l’assistant suggère la bonne cause, demandez au candidat de montrer où elle apparaît dans le code et quel résultat confirmerait son hypothèse. Ce qui vous renseigne est le lien qu’il établit entre l’entrée, l’instruction examinée et la sortie. Répéter la suggestion ne rend pas ce lien observable. Si sa réponse reste trop générale, demandez cette vérification avant de conclure à une incapacité : il vous manque encore un élément pour interpréter son raisonnement.
La correction doit être accompagnée de vérifications
Dans ce même exemple hypothétique, remplacer une comparaison stricte par une comparaison inclusive peut résoudre le défaut montré. Demandez au candidat pourquoi cette modification correspond à la règle attendue. Une correction techniquement simple peut être pertinente si elle traite la cause identifiée, sans nécessiter une réécriture plus étendue.
Examinez ensuite les vérifications qu’il apporte. La commande située au seuil doit être retenue, celle qui reste en dessous doit être exclue et celle qui le dépasse doit toujours être retenue. Vérifier également une entrée vide peut avoir un intérêt si le comportement de la fonction dans ce cas fait partie des attentes. Ces cas sont des propositions pour cet exemple, pas une liste universelle de tests à imposer.
Si seul le cas initial fonctionne, l’incertitude porte sur les autres comportements attendus. Demandez une vérification complémentaire précise, puis regardez si le candidat sait expliquer ce qu’elle établit. La réussite des tests examinés confirme ces résultats dans les conditions testées. Elle ne garantit ni la fiabilité en production ni la maîtrise de tous les problèmes du poste.
L’explication se confronte aux choix visibles dans le code
Faites expliquer au candidat comment sa modification agit, puis changez une contrainte pertinente. Dans notre exemple, supposez que la règle métier exige désormais d’exclure les commandes situées exactement au seuil. Demandez ce qui doit changer dans le code et dans les résultats attendus. Une réponse cohérente relie la nouvelle règle à la comparaison choisie et aux vérifications à actualiser.
Vous pouvez ainsi examiner l’accord entre son explication et les effets du code. S’il annonce un résultat que la fonction ne produit pas, faites préciser le raisonnement et vérifier la sortie. Cette contradiction désigne un point à approfondir. S’il identifie correctement la limite de sa correction, cette réponse nourrit l’évaluation de la tâche, sans démontrer à elle seule son aptitude au poste.
L’aisance orale mérite une lecture prudente. Dans une étude publiée en 2020 auprès de 48 étudiants en informatique, Mahnaz Behroozi et ses collègues ont observé une performance plus faible, ainsi qu’un stress et une charge cognitive plus élevés, en présence d’un intervieweur que dans la condition privée. Ce résultat concerne un exercice au tableau blanc. Il ne mesure pas l’effet de votre entretien assisté par IA.
Nous proposons de laisser un temps de réflexion, puis de demander une explication appuyée sur le code et les résultats observés, afin de ne pas faire de la verbalisation immédiate le seul objet de l’évaluation. Cette adaptation reste à éprouver. Une explication fluide sans vérification ne doit pas dispenser de la preuve technique attendue, tandis qu’une hésitation orale appelle un examen de ce que le candidat parvient effectivement à montrer.
La décision dépend de ce qui reste à vérifier au regard des exigences du poste
Revenez à la responsabilité définie avant l’exercice. Si la tâche est représentative, que les aides reçues sont identifiables et que les réponses étayent votre jugement sur la capacité du candidat à satisfaire l’exigence examinée, utilisez ces observations avec les autres éléments du recrutement. Lorsque l’incertitude est précise, organisez la vérification qui pourrait changer votre jugement. Si une exigence indispensable reste non satisfaite dans des conditions qui permettent d’interpréter les observations, vous pouvez ne pas retenir le candidat pour ce poste.
Si le poste exige une autonomie sans assistance et que celle du candidat n’a pas encore été vérifiée, suspendez votre conclusion sur cette autonomie. Un changement du niveau de responsabilité attendu peut aussi modifier votre décision : savoir corriger la fonction examinée ne suffit pas à établir la capacité à prendre en charge un ensemble plus large de code.
Dans leur analyse publiée en ligne en mai 2023, Paul R. Sackett et ses collègues soulignent que la validité des outils de sélection varie entre contextes. Une moyenne issue de la recherche ne donne pas automatiquement la valeur d’un exercice local. Nous proposons ici une démarche d’observation, dont la capacité à prédire la performance après embauche n’est pas établie. Si la capacité du candidat à satisfaire une exigence du poste reste incertaine, votre prochaine étape doit permettre de la vérifier, sans attribuer à l’exercice une portée que les observations ne permettent pas d’établir.
Sources
U.S. Office of Personnel Management : Work Samples and Simulations
