Recrutement Technique à l'Ère de l'IA : ce que j'évalue a changé

Pendant des années, ma méthode de recrutement technique préférée a été la code review en live. Je sélectionnais dans la codebase des merge-requests passées — discutables, imparfaites, avec des problèmes de conception, des implémentations douteuses — des merge-requests sur lesquelles on peut débattre. Parfois, j’accompagnais cette revue d’une session de live coding via CodeSandbox ou équivalent, où l’on réimplémentait ensemble une boucle, une fonction, un petit module.

Cette approche présentait d’énormes avantages :

• Elle dispensait du test technique à faire à la maison. Pas de week-end sacrifié sur un exercice artificiel. Le candidat arrivait les mains dans les poches.
• Elle donnait une lecture précise du niveau du candidat. Non seulement sur ce qu’il voyait ou ne voyait pas dans le code, mais sur sa façon d’aborder le problème. Par exemple, beaucoup de candidats ne scrollent pas en bas de la merge-request, ou n’ouvrent pas l’arbre de navigation dans GitHub. Personnellement, je le fais systématiquement — je commence par chercher the big picture, le fichier important n’est peut-être pas le premier dans la MR. On évalue donc aussi un sens de l’analyse, une forme de rigueur exploratoire.
• Elle permettait de s’aligner sur les valeurs. Je montrais du vrai code, le code sur lequel le candidat allait intervenir. Je pense que c’est essentiel que le candidat sache où il met les pieds. J’ai parfois travaillé sur des projets très endettés techniquement, avec une couverture de tests quasi nulle. Ce genre de situation peut être un no-go pour certains développeurs, et c’est compréhensible. Mais il faut le découvrir avant de signer.
• C’était un exercice de communication. Et la communication dans une équipe de développement, c’est un savoir-être sous-évalué. J’ai vu des candidats paralysés par la peur, malgré tous mes efforts pour détendre l’atmosphère. J’en ai vu d’autres extrêmement critiques sur le code — ce que je peux bien sûr accepter, voire encourager — mais sur la communication, la forme compte autant que le fond.

Bien. C’était avant l’IA.

Notre métier a changé. Du tout au tout.

En avril 2025, Tobi Lütke, CEO de Shopify, a envoyé un mémo interne qui a fait le tour de la tech : « Reflexive AI usage is now a baseline expectation of everyone at Shopify. » Plus radical encore : avant de demander un recrutement supplémentaire, chaque manager doit prouver que le travail ne peut pas être accompli par l’IA. L’utilisation de l’IA est devenue un critère d’évaluation de la performance, pour tous les employés, sans exception.

Les données du terrain confirment cette bascule. Le Developer Skills Report 2025 de HackerRank rapporte que 97% des développeurs intègrent l’IA dans leur workflow, avec en moyenne un tiers du code produit par des assistants IA. 61% utilisent deux outils IA ou plus au quotidien. Côté recruteurs, 71% des hiring managers déclarent que l’IA rend les compétences techniques plus difficiles à évaluer.

La conséquence directe : les tests techniques traditionnels sont en crise. Un candidat peut coller un énoncé dans un assistant IA et obtenir une solution fonctionnelle en quelques secondes. Distinguer celui qui comprend les concepts de celui qui relaie du code généré devient quasi impossible dans un format classique.

Meta ouvre la voie

Le signal le plus fort de 2025 est venu de Meta, qui a introduit un entretien de coding assisté par IA lors de ses onsites. Le format : 60 minutes sur CoderPad, avec accès à GPT-4o, Claude Sonnet, Gemini 2.5 Pro ou Llama 4 au choix du candidat. Le problème n’est plus un exercice algorithmique isolé mais un projet multi-fichiers sur lequel le candidat doit itérer. Le principe directeur : utiliser l’IA pour des sous-tâches bien définies, pas pour résoudre le problème de bout en bout. Démontrer une relecture critique de chaque output.

Ce format devrait être étendu à tous les postes back-end et ops en 2026.

Kent Beck et la question du goût

Kent Beck, dans son Substack Tidy First?, trace une distinction essentielle entre le vibe coding et l’augmented coding :

In vibe coding you don’t care about the code, just the behavior of the system. In augmented coding you care about the code, its complexity, the tests, & their coverage.

Beck défend l’idée que le yak shaving — ces tâches fastidieuses de préparation — disparaît grâce à l’IA. Le programmeur se recentre sur les décisions conséquentes : l’architecture, le design, la simplicité. Et surtout, le goût. « When anyone can build anything, knowing what’s worth building becomes the skill. »

C’est exactement cette intuition qui guide ma réflexion sur le recrutement.

Ce que j’évalue maintenant

La capacité à prompter

Il y a quelques patterns à connaître absolument :

• Few-shot prompting : fournir des exemples dans le prompt pour guider le modèle vers le format ou le raisonnement attendu.
• Chain of Thought : demander au modèle de raisonner étape par étape, ce qui améliore significativement la qualité des réponses sur les problèmes complexes.
• Iterative Refinement : ne pas attendre la réponse parfaite du premier coup, mais raffiner progressivement en donnant du feedback au modèle.

Un candidat qui connaît et applique ces patterns ne travaille pas de la même façon que celui qui envoie un prompt d’une ligne et espère un résultat magique.

La capacité à lire et à amender un PRD

Un Product Requirements Document bien rédigé est devenu le levier de productivité principal. Est-ce que le nouveau test technique ne serait pas, à partir d’une spec produit, de générer un PRD actionnable ? Le candidat reçoit une spécification floue, volontairement incomplète, et doit produire un document structuré qui pourrait être consommé par un agent IA ou un développeur junior.

Ce test évalue bien plus que la rédaction : il évalue la capacité à poser les bonnes questions, à identifier les zones d’ombre, à anticiper les cas limites — bref, à penser le problème avant de coder.

L’utilisation des outils IA en contexte réel

Faut-il donner accès à Claude Code lors d’un test technique ? Je pense que c’est indispensable. Évaluer un développeur sans ses outils en 2026, c’est comme évaluer un menuisier sans ses machines.

Ce que je veux observer :

• Les réflexes d’exploration. Le candidat lance-t-il des prompts d’audit préparatoire avant de coder ? Utilise-t-il le mode plan ? Cherche-t-il à comprendre la codebase avant de produire du code ?
• La navigation dans l’outil. Connaît-il les slash commands, les skills, les raccourcis ? Sait-il basculer entre les modes, lancer un agent en arrière-plan, utiliser /compact pour gérer le contexte ?
• La rigueur du workflow. Demande-t-il des tests ? De la documentation ? Précise-t-il les contraintes (pas de dépendance supplémentaire, respecter les patterns existants) ? Ou se contente-t-il de vibe coder et d’espérer que ça tienne ?

Est-ce que je vais continuer les code reviews ?

Je ne sais pas. L’implémentation du code est devenue un problème marginal. Ce que je cherche à évaluer, c’est la capacité d’un candidat à concevoir et à faire vivre un projet.

Vibe coder une feature, presque tout le monde peut le faire aujourd’hui. Mais chercher dans le code — avec l’aide de Claude ou équivalent — les modules existants, les services partagés, les tests implémentés, les patterns utilisés, afin de faire une greffe solide et précise en limitant au maximum le code produit… c’est ça qu’on cherche à évaluer.

Donc oui, je vais probablement continuer à donner accès à une codebase, sur des services peu confidentiels, et demander d’implémenter une feature. Mais ce que je noterai, c’est comment le candidat utilise Claude. Les réflexes qu’il a à aller observer les fichiers de configuration, à lancer des prompts d’audit, à activer le mode plan, à générer un PRD, à préciser qu’il veut des tests, de la doc, à vérifier que le code produit s’intègre dans l’existant plutôt que de réinventer la roue.

La code review reste un excellent exercice. Mais ce qu’on review a changé. On ne review plus du code écrit par un humain. On review du code piloté par un humain et produit par une machine. Et la qualité du pilotage, c’est tout ce qui fait la différence.

Lectures complémentaires

1. Shopify, Reflexive AI usage is now a baseline expectation

Using AI effectively is now a fundamental expectation of everyone at Shopify.

Le mémo de Tobi Lütke (avril 2025) qui a fait basculer le débat. L’IA n’est plus un bonus, c’est un prérequis. Les questions sur l’utilisation de l’IA sont intégrées aux évaluations de performance.

2. HackerRank, Developer Skills Report 2025

97% des développeurs utilisent l’IA dans leur workflow. Un tiers du code est généré par IA. Le rapport documente l’impact sur les pratiques de recrutement et les compétences recherchées.

3. Meta, AI-Assisted Coding Interview

Le format détaillé de l’entretien technique assisté par IA chez Meta : 60 minutes, projet multi-fichiers, accès aux LLMs de son choix. Un signal fort sur la direction que prend l’industrie.

4. Kent Beck, Augmented Coding: Beyond the Vibes

In vibe coding you don’t care about the code, just the behavior of the system. In augmented coding you care about the code, its complexity, the tests, & their coverage.

La distinction fondamentale entre vibe coding et augmented coding, et pourquoi le goût et le design restent au coeur du métier.

5. Karat, Engineering Interview Trends in 2026

71% des leaders tech estiment que l’IA rend les compétences techniques plus difficiles à évaluer. Le rapport détaille les nouvelles approches d’entretien adoptées par les entreprises.