En bref
Le test technique de recrutement ne mesure plus ce qu'il prétend mesurer. C'est le constat du benchmark TPC sur la maîtrise de l'IA en entretien. Il documente 18 entreprises, dont Doctolib, Alan, Canva et Coinbase.
Un modèle résout un exercice d'algorithmie en quelques secondes. Le rendu d'un take-home ne dit plus si le candidat a pensé son cas ou l'a délégué. Résultat : vous ne départagez plus les candidats. Et vous ne voyez pas comment ils travaillent avec l'IA, alors que le poste l'exige.
Ce playbook répond à une question : comment tester un candidat quand l'IA fait partie du métier ?
La réponse tient en quatre étapes :
- Poser la règle sur l'IA avant chaque épreuve.
- Définir ce que chaque épreuve mesure : hard skills, jugement ou maîtrise de l'IA.
- Adapter ou créer les épreuves, métier par métier.
- Noter avec une scorecard calibrée selon le niveau du poste.
Par Mathias Frachon, cofondateur de TPC · Temps de lecture : 25 min
Sommaire13 sections
- 1.Pourquoi les tests techniques ne mesurent plus rien à l'ère de l'IA ?
- 2.Faut-il autoriser l'IA pendant un test technique ?
- 3.Qu'est-ce que la maîtrise de l'IA chez un candidat ?
- 4.Comment adapter les tests techniques que vous avez déjà ?
- 5.Comment créer une épreuve dédiée à l'IA ?
- 6.Quel test technique choisir selon le métier ?
- 7.Comment noter un test technique : la scorecard TPC
- 8.Quelles questions poser en entretien technique sur l'IA ?
- 9.Quels outils pour un test technique avec IA ?
- 10.Comment redesigner son process de recrutement tech ?
- 11.Ce qui va départager les candidats demain
- 12.FAQ : test technique et IA
- 13.Replays et ressources
1. Pourquoi les tests techniques ne mesurent plus rien à l'ère de l'IA ?
Un test technique de recrutement est une épreuve qui observe une compétence, au lieu de l'entendre décrite. Il complète le CV et l'entretien, qui restent déclaratifs. Trois familles d'épreuves coexistent souvent dans un même process :
- les tests de hard skills : écrire du code, modéliser des données, produire une maquette, rédiger une spécification
- les tests d'aptitudes : raisonnement logique, personnalité, des tendances générales plutôt que la maîtrise d'un métier
- les mises en situation : étude de cas, revue de code, arbitrage produit, qui mesurent le jugement en contexte
Ce playbook porte sur les deux familles que l'IA bouleverse : les hard skills et les mises en situation.
Un test technique sert à vérifier deux choses. Les hard skills du métier : un développeur sait développer, un designer sait designer. Et le jugement : la capacité à prendre du recul et à arbitrer. C'est ce second bloc qui distingue un junior d'un confirmé ou d'un senior.
L'IA brouille la mesure des deux à la fois. Un énoncé d'école est résolu par un modèle en quelques secondes. Le rendu ne dit plus rien des hard skills. Le chemin de pensée est invisible, donc le jugement aussi. Et l'usage de l'IA lui-même n'est pas observé.
Le problème existait avant l'IA
Les exercices d'algorithmie façon LeetCode étaient déjà mal perçus par les candidats. Ils les jugeaient décorrélés de leur travail. Loïc Michard, CEO France de CoderPad, rappelle un effet connu. Sur ces tests, les juniors sortis d'école battaient souvent les seniors, parce que la théorie était plus fraîche.
"Maintenant j'ai un outil où si je lui donne le problème, il va me le résoudre en littéralement deux secondes."
Résultat décrit par CoderPad : les entreprises qui gardent ces tests n'arrivent plus à départager les candidats. Tout le monde résout l'exercice.
Le même phénomène touche le CV
Les candidats réécrivent leur CV avec l'IA pour coller à la fiche de poste. Les recruteurs branchent ensuite une IA pour les trier. Loïc Michard observe que ces outils ont tendance à préférer les CV rédigés par une IA. Le filtre sélectionne alors la forme, pas le profil.
Ce que Coinbase a mesuré
Coinbase a documenté le problème avec des chiffres. En un an, la part de code généré par IA dans sa codebase est passée de 5,7 % à plus de la moitié. L'entreprise s'est donc demandé s'il fallait encore faire coder de mémoire pendant 45 minutes.
Deux défauts de l'ancien dispositif sont publiés :
- des candidats récitaient les bons patterns et passaient, sans montrer le jugement attendu, quand d'autres, solides, échouaient sur de la mémorisation
- une analyse interne a mesuré 84 % de corrélation entre deux rounds distincts : deux entretiens coûteux produisaient presque le même signal
"On ne peut pas recruter des ingénieurs pour travailler avec l'IA si on continue de les sélectionner sur leur capacité à travailler sans elle."
La mauvaise réponse : chasser la triche
Le réflexe le plus courant consiste à traiter l'IA comme de la triche, et à tenter de la détecter. Pour Loïc Michard, c'est la mauvaise façon de résoudre le problème. L'IA fait partie de l'outillage quotidien, comme un IDE. L'interdire partout donne au candidat le sentiment d'être diminué, et vous mesurez quelqu'un d'autre que celui que vous allez recruter.
La bonne réponse se joue en amont. Avant d'évaluer l'IA, posez-vous une question à chaque étape du process : qu'est-ce que je cherche à mesurer ici ? Les hard skills, le jugement, la maîtrise de l'IA, ou plusieurs à la fois ? La réponse décide de la place de l'IA dans l'épreuve.
À faire cette semaineFaites passer votre test actuel à un modèle et chronométrez. Sous deux minutes, votre énoncé ne mesure plus rien. Le réécrire coûte moins cher que de surveiller son interdiction.
2. Faut-il autoriser l'IA pendant un test technique ?
Aucune des 18 entreprises du benchmark n'interdit l'IA sur l'ensemble de son process. La question n'est donc plus "pour ou contre". Elle est : quelle règle, à quelle étape, annoncée comment. Trois postures se dégagent.
| Posture | La règle | Pourquoi | Qui l'applique |
|---|---|---|---|
| Imposer l'IA | Ne pas l'utiliser devient un signal négatif. | Si l'IA fait partie du métier, la refuser revient à mesurer quelqu'un d'autre. | Fleet, DirectLayer, Streem Energy, Coinbase, Mozza, Canva, Shopify, Zapier, CoderPad |
| Décider au cas par cas | La règle change selon l'étape ou l'exercice, et s'annonce avant. | Chaque épreuve dit ce qu'elle mesure, et la règle suit. Posture la plus répandue. | Mirakl, Algolia, Datadog, Doctolib, Alan, Everping (règle écrite). Stripe, Qantev, PayPlug, Galigeo (pas encore de règle écrite) |
| Interdire l'IA | L'épreuve se passe sans outil. | Vérifier un hard skill précis, ou contrôler qu'un rendu fait avec l'IA est compris. | Jamais sur tout le process. Sur une étape : Doctolib, Mirakl, Datadog |
Le cas par cas n'existe que s'il est écrit
Sans règle posée, chaque évaluateur décide seul. Il note donc au feeling. Stripe illustre ce flottement : la maîtrise de l'IA est devenue un critère formel de sa rubrique, mais la politique d'entretien n'est pas tranchée.
"Est-ce qu'on doit aller jusqu'au bout d'embrasser cette tendance et leur dire : vous pouvez utiliser l'IA, on met ça comme baseline pour tout le monde ? Ou au contraire on essaye de détecter ? On a encore tous ces questionnements-là."
Interdire a du sens, sur une étape, et en le justifiant
Loïc Michard défend une étape sans IA, à condition d'expliquer pourquoi. Par exemple un petit bout de code avec deux boucles et un if. L'objectif est de vérifier les fondamentaux avant d'utiliser les outils. Selon lui, ce filtre simple écarte plus de candidats qu'on ne le pense.
"Le fait de l'expliciter et d'avoir une partie de son process qui est dédiée à ça permet aussi au candidat de se mettre dans une posture d'honnêteté. Et souvent, ça pose beaucoup moins de problèmes de triche."
Quatre façons d'écrire la règle, observées dans le benchmark
- Mirakl : une règle par type d'épreuve. La page publique d'octobre 2025 distingue quatre situations. En entretien, le candidat répond avec ses connaissances et ne lit pas de réponses générées. Sur le take-home et l'étude de cas, l'IA est autorisée, mais la restitution doit montrer la réflexion. En technique en direct, l'IA n'est généralement pas autorisée. Quand elle l'est, le candidat doit expliquer ses prompts, ses décisions et ses arbitrages.
- Algolia : des exemples plutôt que des interdits. Un tableau oppose, pour six types d'exercice, ce qui est encouragé à ce qui ne l'est pas. Huit exemples de prompts autorisés montrent où est la limite. Une clause règle la triche sans la détecter : en cas de doute, l'entreprise demandera d'autres preuves de travail original.
- Datadog : une politique datée, étape par étape. La page porte une date de mise à jour (13 mai 2026). Le candidat est prévenu du type d'entretien qu'il va passer. Le partage suit la frontière du contrôle : l'IA passe là où l'entreprise peut interroger le candidat sur son travail.
- Doctolib : une règle qui engage les deux côtés. Avant de dire ce qu'elle interdit au candidat, l'entreprise publie ce qu'elle s'interdit. Pas d'IA pour donner un avis sur un candidat, décider d'un rejet, ou noter un CV. La page cite l'AI Act et le RGPD, et reconnaît l'accessibilité comme usage légitime, par exemple pour compenser une dyslexie.
"Nous considérons l'IA comme une compétence, pas comme un raccourci. Chez Doctolib, ce sont des personnes qui prennent les décisions de recrutement, pas l'IA."
"Nous vous recrutons vous, pas votre modèle de langage. Ne rendez pas du code ou des réponses générées comme étant les vôtres. Si votre travail est assisté par l'IA, dites-le."
La déclaration d'usage : ce que le candidat écrit avec son rendu
Doctolib fournit le format mot pour mot. Une note en tête ou en fin de rendu précise l'outil, son usage, et que l'analyse reste personnelle. Pour le code, la convention descend jusqu'au commentaire : marquer les extraits générés avec le prompt utilisé, vérifier la licence, être prêt à dérouler ses choix.
Mirakl attend que le candidat sache dire quatre choses : ce que l'outil a produit, ce qu'il a conservé, ce qu'il a modifié, et ce qu'il a décidé lui-même.
Modèle de demi-page à envoyer avec l'invitation (proposition TPC)
| Épreuve | Ce que le candidat peut faire avec l'IA | Ce qui est demandé sans outil | Ce qu'il devra expliquer |
|---|---|---|---|
| Premier entretien | Se préparer, s'entraîner avec un modèle | Répondre avec ses mots, sans lire de réponse générée | Ses usages réels de l'IA, avec des exemples |
| Take-home | Tout utiliser, en le déclarant | Rien | Ce que l'IA a produit, gardé, modifié, et ce qu'il a décidé |
| Live coding fondamentaux | Rien | Un exercice court sur les bases | Son raisonnement à voix haute |
| Live avec IA | L'outil fourni ou le sien, annoncé avant | Rien | Pourquoi tel outil, pourquoi telle délégation |
Datez la page et rappelez au candidat l'étape où il se trouve. Ces deux gestes ne coûtent rien et suppriment la part de devinette qui fausse le signal.
À retenirÉcrivez ce que vous vous interdisez de faire avec l'IA avant d'écrire ce que vous interdisez au candidat. Cela prend dix minutes, et c'est ce qui rend la règle acceptable.
3. Qu'est-ce que la maîtrise de l'IA chez un candidat ?
La maîtrise de l'IA n'est pas une compétence à part. Ce sont cinq compétences qui se greffent sur le métier. Deux prolongent les hard skills : déléguer et cadrer, le côté builder. Deux prolongent le jugement : juger la sortie et orchestrer, le côté orchestrateur. La cinquième, le coût, se maîtrise à part.
Pourquoi les métiers ont changé
Loïc Michard part d'un constat sur l'organisation des équipes. Elles étaient construites autour d'une contrainte : écrire le code prend du temps. D'où l'importance des sprints, des roadmaps et de la planification. Cette contrainte se réduit au minimum. Un PM ou un designer peut prototyper en direct pendant un call client.
Les rôles produit, design et tech se rapprochent sans fusionner. Le développeur doit avoir de l'ownership sur le problème, pas seulement sur l'implémentation. Et le temps libéré va vers le "vrai engineering" : tests, documentation, infrastructure. L'Observatoire TPC des organisations à l'ère de l'IA documente ce changement dans 31 entreprises.
"En fait, tout le monde devient un builder. Sauf qu'ils vont builder différemment."
Trois traits à chercher, quel que soit le rôle
Loïc Michard reprend un cadre théorisé par Notion :
- les capacités : les hard skills, l'expertise métier, ce qu'on testait déjà
- le taste : le jugement, voir quand l'IA part dans la mauvaise direction et la ramener
- l'agency : la curiosité et l'énergie pour essayer de nouveaux outils
L'agency compte parce que les outils changent tous les mois. Tester une compétence IA précise à un instant T, c'est tester quelque chose qui sera obsolète dans un mois. Mieux vaut tester la capacité à bouger.
Les cinq compétences, et comment elles se voient
| Compétence | Ce que fait le candidat | Ce qu'on observe | Exemple du benchmark |
|---|---|---|---|
| Déléguer | Décide ce qu'il confie à l'IA et ce qu'il garde | Quelle tâche, quelle taille, quel modèle, et pourquoi | Fleet, Shopify |
| Cadrer | Configure l'agent et valide son plan avant de le laisser exécuter | Qualification du besoin, contexte donné, limites posées, plan relu | Streem Energy, Canva, Qantev |
| Juger la sortie | Attrape l'erreur plausible et assume ce qui part | Contrôle par tests, CI et revue. Capacité à refaire sans IA | Alan, Doctolib, Mirakl, Galigeo |
| Orchestrer | Fait travailler des agents et une équipe vers un résultat | Agents en chaîne, points de casse anticipés, gouvernance | DirectLayer, PayPlug, Zapier |
| Maîtriser les coûts | Arbitre le coût de chaque appel contre ce qu'il rapporte | Coût par appel ou par utilisateur, plafonds, choix du modèle | Aucun cas testé en entretien à ce jour |
Déléguer : la réflexion ou l'exécution ?
Chez Fleet, l'IA est attendue sur le take-home, mais c'est l'oral qui est noté. Il sépare vite deux profils. Celui qui a délégué l'exécution après avoir pensé son cas. Et celui qui a délégué la réflexion, et découvre en direct ce que l'IA a voulu dire.
"Un candidat qui staffe l'IA avec ses propres idées, il lui soumet son raisonnement, la challenge, itère, parlera toujours mieux de son cas qu'un candidat qui lui a simplement délégué la réflexion."
Cadrer : la compétence qui se redéfinit le plus vite
On parlait de prompt engineering. On parle désormais de qualification du besoin, de configuration de l'agent, de context engineering, et de validation du plan avant exécution. Loïc Michard regarde déjà beaucoup moins la façon de prompter.
"La façon dont ils promptent, par exemple, ça, on regarde beaucoup moins maintenant. Le prompt engineering, c'est beaucoup moins utile vu la capacité des modèles."
Juger la sortie : la compétence la plus rare
Elle ne s'observe qu'en situation, sur une sortie imparfaite qu'on n'a pas annoncée comme telle. Chez Alan, un modèle interrogé sur un faux problème a tendance à l'inventer. Le bon candidat cherche d'abord lui-même, puis décrit précisément à l'IA ce qui ne va pas.
"Avec l'IA, on peut déléguer le travail, pas la responsabilité."
Orchestrer : du contributeur individuel au dirigeant
Pour un profil opérationnel, orchestrer veut dire faire travailler des agents en chaîne et savoir où le relais casse. Pour un leader, c'est déployer, piloter et gouverner l'IA à l'échelle de l'organisation. Zapier fixe une barre plus haute aux managers : être à l'aise seul ne suffit pas si l'équipe travaille à l'ancienne.
Maîtriser les coûts : le critère qui arrive
Le coût d'usage des modèles, compté en tokens, devient un poste de budget à part entière. Aucune entreprise du benchmark ne le teste encore en entretien. Fleet le pilote déjà en interne : son budget tokens mensuel est suivi comme un plan de recrutement.
La narration, condition des cinq autres
Un candidat qui travaille avec l'IA en silence ne laisse rien à noter. Il doit expliquer ses choix d'usage et sa façon d'évaluer ce que produit l'IA. Prévenez-le : verbaliser fait partie de l'épreuve.
Quelles compétences prioriser selon le métier
| Métier | Compétences prioritaires |
|---|---|
| Tech | Déléguer, cadrer, juger la sortie, orchestrer |
| Product | Déléguer, cadrer, juger la sortie, orchestrer |
| Design | Déléguer, cadrer, juger la sortie, orchestrer |
| Direction et management | Juger la sortie, orchestrer, maîtriser les coûts |
Pour les postes de direction, l'effort porte sur le côté orchestrateur : arbitrer, changer la façon dont l'équipe livre, piloter le coût d'usage.
5. Comment créer une épreuve dédiée à l'IA ?
Quand adapter ne suffit pas, quatre formats d'épreuve reviennent dans le benchmark. Aucun n'exige une plateforme payante, sauf l'environnement contrôlé. Le choix dépend de la compétence que vous voulez voir.
| Format | Le principe | Ce qu'il mesure | Coût | Risque principal | Qui |
|---|---|---|---|---|---|
| A. Live sur repo vide | Le candidat part de zéro avec ses propres outils | Déléguer et cadrer | Nul : un repo et un partage d'écran | Difficile à standardiser entre évaluateurs | Shopify, CoderPad |
| B. Live sur code existant, IA fournie | Codebase multi-fichiers inconnue, IA de l'entreprise | Juger la sortie | Élevé : plateforme et codebase à maintenir | Peu accessible sous 50 personnes | Alan, Coinbase |
| C. Énoncé métier trop large pour un prompt | Problème ambigu, impossible à résoudre d'une requête | Cadrer | Faible : du temps de conception | Un énoncé trop ouvert devient incomparable | Canva, Streem Energy, Qantev, Galigeo, Fleet, Stripe, CoderPad |
| D. Revue de PR d'un agent | Décider si on approuverait un diff avec un défaut plausible | Juger la sortie, à l'état pur | Faible : un diff de votre historique | Les modèles récents corrigent beaucoup du premier coup | Alan |
Canva : le round où l'IA est obligatoire
Canva a supprimé son round "Computer Science Fundamentals". Algorithmes et structures de données, code écrit à la main. Un modèle résolvait ses questions en quelques secondes, sans même être relancé. Il est remplacé par un round "AI-Assisted Coding" où le candidat doit utiliser Copilot, Cursor ou Claude.
L'énoncé est réécrit pour ne pas tenir dans un prompt. Exemple : gérer les décollages et atterrissages d'un aéroport saturé. Des contraintes s'ajoutent : pistes occupées, priorités, retards. Donné tel quel à un modèle, l'énoncé produit un résultat plausible mais faux. Le candidat doit découper, faire avancer l'IA morceau par morceau, et juger chaque sortie.
Après chaque génération, l'interviewer pose toujours la même question : qu'est-ce que fait ce code ? Elle vérifie en plus une compétence de fond. Ce candidat saura-t-il relire des PR une fois en poste ?
Cinq critères sont publiés. Le candidat sait-il quand mobiliser l'IA ? Décompose-t-il l'ambiguïté ? Décide-t-il sainement ? Identifie-t-il les problèmes du code généré ? Atteint-il un niveau de production ? Le candidat est prévenu en amont et invité à s'entraîner.
"Les candidats avec peu d'expérience de l'IA ont souvent échoué, non parce qu'ils ne savaient pas coder, mais parce qu'ils manquaient du jugement nécessaire pour guider l'IA."
Shopify : un repo vide, cinq minutes avant
Le candidat reçoit une invitation à un dépôt GitHub vide cinq minutes avant le début. Il vient avec son IDE et ses outils d'IA. Le problème démarre simple et s'enrichit en route : cache LRU, navigation de robots, commande tail. La difficulté porte sur le design. Deux rounds sur quatre se jouent ainsi.
L'imperfection du modèle fait partie du dispositif. Des candidats ont réussi sans écrire une ligne à la main, en dirigeant clairement. Format reconstitué depuis des retours de candidats, non publié par l'entreprise.
"Nous aimons utiliser l'IA pendant les entretiens parce qu'elle produit parfois du déchet pur, ce qui nous permet d'observer comment les candidats réagissent face à du code imparfait."
Streem Energy : concevoir au tableau, puis faire exécuter
Le test part d'un problème métier posé avec tout son contexte. Le candidat conçoit d'abord une solution au tableau, sans machine. Si elle ne répond pas au problème, elle est challengée et il recommence. Il définit ensuite l'architecture que l'agent va exécuter, en spec driven development.
Il est évalué en bonne partie sur cette interaction avec l'agent, pas seulement sur ce que l'agent produit. Le dispositif sépare deux moments que la plupart des tests confondent. On sait si le candidat sait ce qu'il demande, avant de savoir s'il sait le faire faire.
L'épreuve est placée en deuxième round, parce qu'elle filtre beaucoup. Les postes qui travailleront sur les pipelines IA passent une étape de plus : coder directement un agent.
"Tout cela est très nouveau, donc on expérimente jusqu'à trouver le bon équilibre."
CoderPad : une consigne d'une phrase, trente minutes
Loïc Michard a détaillé en live un entretien réel mené pour CoderPad. La consigne tient en une phrase, volontairement vague : "build me an AI interviewer". Les dix premières minutes servent à qualifier le besoin avec l'interviewer. Les vingt suivantes à construire avec l'IA.
Beaucoup de candidats partent directement dans l'implémentation. D'autres demandent pourquoi et cherchent le vrai problème. Le candidat pris en exemple a construit seulement le cœur du prototype. Une fiche de poste, un chatbot qui pose des questions, et la possibilité de tester l'expérience.
La note porte sur les raccourcis choisis :
- la fiche de poste collée dans un simple fichier texte, au lieu de coder un écran d'import
- seule la partie qui permet de tester le chatbot est construite
- pas de tableau de bord recruteur, que beaucoup construisent et qui ne prouve rien sur la valeur du prototype
"C'est ça le taste, c'est ça la capacité en fait à prendre les bons raccourcis et les bonnes décisions."
Deux formats plus avancés, décrits par CoderPad
Le "read and extend". On part d'une codebase complète. Le candidat la lit et l'explique d'abord sans IA. Il utilise ensuite l'IA pour ajouter des fonctionnalités, puis challenge le résultat. C'est souvent la première étape des entreprises qui quittent l'entretien à l'ancienne. On observe des réflexes simples, comme ouvrir le fichier des dépendances pour comprendre le projet.
Le multi-agents. Décrit comme la pratique des laboratoires d'IA, type OpenAI. Le candidat a vingt minutes et cinq choses à faire. Il doit lancer des agents en parallèle, passer de l'un à l'autre et fusionner leur travail. Si les fonctionnalités entrent en conflit, on voit sa gestion des worktrees. La compréhension du code passe au second plan : on mesure l'orchestration.
Qantev : l'épreuve créée en cours de recrutement
Chez Qantev, environ 40 personnes, le test n'existait pas au début du recrutement d'un lead IA. Un finaliste n'avait montré aucune initiative pour se documenter sur l'IA entre deux entretiens. Ce signal a conduit à créer l'exercice manquant, plutôt qu'à écarter le candidat.
L'exercice compte cinq questions, écrites par l'équipe IA et non par les recruteurs. Quatre vérifient des connaissances. La cinquième mesure un jugement. Un système bloque dix minutes une transaction suspecte et envoie un SMS de vérification. Quelle métrique pilote le seuil ? Le rappel, parce qu'une fraude manquée coûte plus qu'un blocage de dix minutes.
Limite : les questions de connaissance annoncées à l'avance se préparent en trente minutes avec un modèle. Seul le cas fraude résiste.
Ce qu'Alan prépare : l'orchestration après le cadrage
Alan mène déjà un entretien d'architecture, ou feature design interview, sans écrire de code. Une brique va s'ajouter. Une fois le problème cadré avec le candidat, celui-ci orchestrera des IA pour atteindre un résultat presque prêt pour la production.
Repère éditeur, hors des 18 casHackerRank propose de faire construire le candidat avec l'IA, puis de changer une exigence en cours de route. On observe comment il réoriente l'outil. Source : HackerRank, "How to Interview Engineers Who Use AI Coding Assistants", 29 juillet 2026.
6. Quel test technique choisir selon le métier ?
Voici une bibliothèque d'épreuves, une par étape et par métier. C'est une proposition TPC construite à partir du benchmark. Chaque ligne donne la consigne, la durée, les bons signaux et les red flags. Personnalisez l'énoncé avec votre stack et vos vrais problèmes : plus l'épreuve ressemble au premier jour, meilleur est le signal.
Pour structurer l'ensemble de l'entretien d'un développeur, voir notre guide d'entretien pour recruter des devs.
Engineering : test technique développeur backend
| Étape | Épreuve | Durée | Consigne | Bons signaux | Red flags |
|---|---|---|---|---|---|
| Screening | La pente, pas la photo | 20 min | "Montre-moi ton setup actuel, puis dis-moi ce que tu as essayé et abandonné ces six mois. Pourquoi ?" | Un outil abandonné et sa raison technique. Sait où ça casse | Récite des noms d'outils. Aucun abandon à citer |
| Take-home | Take-home et revue des décisions | 3 jours + 45 min | Un morceau réel du produit. IA autorisée, trace des échanges jointe au code. La revue orale compte plus que le rendu | Reformulations dans la trace. Sait dire quel code généré il a réécrit. Tests sur les cas manqués par l'IA | Rendu impeccable sans trace. Ne sait pas expliquer une ligne |
| Live | Énoncé trop large pour un prompt | 75 min | "Construis un système de gestion des créneaux de livraison sur une flotte saturée." Outils annoncés en amont. Réduire le scope est un bon signe | Questions de cadrage avant de coder. Garde la main sur l'architecture. Corrige une erreur générée | Prompte et accepte. Se noie en voulant tout livrer |
| Références | L'impact au-delà de lui | 20 min | "Quelqu'un d'autre utilisait-il ce qu'il avait construit ? Est-ce que ça tourne encore ?" | Un outil interne encore utilisé après son départ | Productivité strictement personnelle |
Engineering : fullstack et frontend
| Étape | Épreuve | Durée | Consigne | Bons signaux | Red flags |
|---|---|---|---|---|---|
| Screening fullstack | Le cas où l'IA a été moins bonne | 20 min | "Un cas où l'IA a été moins intéressante que ce que tu aurais produit toi-même." | Un cas précis, avec la raison. Distingue coder avec des agents et construire des systèmes d'agents | Ne voit aucune limite. Réponse générique sur les hallucinations |
| Take-home fullstack | Cas de logique métier envoyé en amont | 48 h | Un cas concret tiré du produit, pas du LeetCode. La discussion porte sur les arbitrages | S'est approprié le sujet. Sait ce qu'il a délégué et gardé | Récite un rendu qu'il ne peut pas défendre |
| Live fullstack | Un énoncé, une barre mobile | 45 min | Un exercice simple sur l'intitulé, itératif, le même pour tous les niveaux. La séniorité se lit à la distance parcourue | Extrait les règles par des questions. MVP d'abord. Verbalise ses arbitrages | Se lance sans clarifier. Silence prolongé |
| Take-home frontend | Composant et cas limites | 2 jours | Un composant d'interface réel, avec ses états limites, construit contre des cas de test | A rattrapé les manques d'accessibilité du code généré. États d'erreur et de vide traités | Rendu léché, cas limites absents |
| Live frontend | Debugging d'un repo inconnu | 60 min | "Voici un dépôt inconnu et le brouillon de PR d'un collègue. Relisez-le et améliorez-le." | Lit avant d'écrire. Formule une hypothèse puis la teste | Réécrit tout au lieu de comprendre. Fait tourner l'agent en rond |
Product : cas pratique et étude de cas product manager
| Étape | Épreuve | Durée | Consigne | Bons signaux | Red flags |
|---|---|---|---|---|---|
| Screening | L'insight inaccessible | 20 min | "Quel signal utilisateur es-tu allé chercher grâce à l'IA, que tu n'atteignais pas avant ? Et un cas où elle a été moins bonne que toi ?" | Un exemple concret et ce qui en est sorti. Décrit un process de spec réutilisable | "Je résume mes interviews." Avant et après se ressemblent |
| Étude de cas | Le jeu d'évaluation avant le modèle | 48 h | "Un client veut un assistant de facturation. Avant de parler modèle ou prompt : décrivez le jeu d'évaluation, les modes d'échec, et le plan de retour arrière." | Commence par comment on saura que c'est cassé. Prévoit le rollback | Commence par le choix du modèle. Critères de succès flous |
| Live | Cadrer, construire, défendre | 120 min | On définit le produit ensemble, le candidat prototype, puis défend ses arbitrages face à une contrainte ajoutée en route | Négocie le périmètre avant de lancer l'outil. Assume ce qu'il a sacrifié | Livre une maquette qu'il ne peut pas justifier. Délègue la décision produit au modèle |
| Références | Ce qui a changé dans la squad | 20 min | "Son arrivée a-t-elle changé la façon de spécifier ou de livrer ?" | Un rituel ou un format que l'équipe a gardé | Aucun changement visible |
Le jeu d'évaluation vient de DirectLayer, qui interroge ses candidats sur la façon de tester un modèle. Pour un PM, la transposition est directe. Avant de parler prompt, comment saura-t-on qu'une fonctionnalité IA est cassée, et comment revenir en arrière ?
Design : test product designer
| Étape | Épreuve | Durée | Consigne | Bons signaux | Red flags |
|---|---|---|---|---|---|
| Screening | Le tri, pas la génération | 20 min | "Comment tries-tu ce que l'IA te sort ? Montre-moi une piste que tu as jetée, et pourquoi." | Critère de tri explicite. Rejet argumenté | Garde la première proposition. Parle volume plutôt que qualité |
| Cas pratique | Variantes et arbitrage | 2 jours | Un brief ambigu. Plusieurs directions, puis une recommandation argumentée. On veut voir ce qui a été écarté | Montre les pistes jetées. Recommandation tranchée | Trois variantes cosmétiques du même parti pris |
| Live | Prototype défendu, ou whiteboard | 90 min | Whiteboard si le doute porte sur le problem solving, prototype s'il porte sur le craft | Reformule le brief. Absorbe une contrainte ajoutée. Facilite la discussion avec un PM ou un dev | Bloque quand la contrainte arrive |
| Références | Adoption du système | 20 min | "Ses composants ou conventions ont-ils été repris ?" | Système repris par d'autres | Livrables isolés |
Chez Everping, le dealbreaker annoncé pour un product designer est le profil brouillon. Celui qui ne sait pas produire des spécifications exploitables par les développeurs.
Côté candidat, notre guide pour réussir son test Product Design détaille ce que les équipes attendent.
Data : analyste, data scientist, ML
| Étape | Épreuve | Durée | Consigne | Bons signaux | Red flags |
|---|---|---|---|---|---|
| Screening | Où il refuse l'IA | 20 min | "Sur quelle partie de ton travail refuses-tu de laisser l'IA décider, et pourquoi ?" | Nomme une zone précise. Parle reproductibilité et fiabilité | Ne voit aucune limite |
| Take-home | Pipeline avec validation | 3 jours | Une analyse sur un jeu de données fourni. La validation compte autant que le résultat | Validation embarquée. Documente ce qu'il n'a pas pu vérifier | Résultat sans contrôle. Notebook généré d'un bloc |
| Live | Lecture de données et analyse piégée | 60 min | D'abord lire un jeu de données. Puis défendre ou démolir une analyse produite par un modèle, qui contient une erreur méthodologique plausible | Attrape l'erreur sans aide. Interroge la métrique avant les chiffres | Valide parce que la sortie a l'air propre |
| Références | Fiabilité dans le temps | 20 min | "Ses analyses tenaient-elles ? A-t-il déjà remonté une erreur de lui-même ?" | A signalé ses propres erreurs | Rendus rapides mais reprises fréquentes |
Galigeo, une PME de 20 personnes, a redéfini le niveau de Python attendu pour un profil data. Le test ne coûte rien : un SQL basique mais réel, un jeu de données à lire, quinze minutes avec le CEO.
"Il faut qu'il y ait un niveau de Python suffisant pour savoir juger si la réponse de Claude est pertinente."
Leaders : Head of, Engineering Manager, CTO
| Étape | Épreuve | Durée | Consigne | Bons signaux | Red flags |
|---|---|---|---|---|---|
| Screening | L'équipe, pas lui | 25 min | "Pas ton usage personnel : comment ton équipe travaille différemment aujourd'hui, et qu'as-tu fait pour ça ?" | Un changement de process d'équipe. Sait nommer qui n'a pas suivi | "J'ai donné les licences." Fluent lui-même, équipe inchangée |
| Cas | Projection à 1 mois et 3 mois | 48 h | "Votre plan à un mois puis à trois mois sur ce périmètre, avec ce que vous mesurez et dans quel ordre." | Mesure autre chose que l'usage des licences. Prévoit les résistances | Plan de formation générique. Aucune métrique |
| Live | Gouvernance en trois temps | 60 min | "Qui a décidé ça, comment vous mesurez que ça marche, et qu'est-ce qui a foiré au début ?" | Répond aux trois temps, avec des exemples vérifiables. Assume un échec | Discours générique, aucun exemple vérifiable |
| Références | Obligatoires à ce niveau | 30 min | Deux références dont un ancien membre de son équipe. Le changement a-t-il tenu après son départ ? | Le changement a survécu. Des gens ont progressé grâce à lui | Tout est retombé. Adhésion de façade |
Et en ESN ?
La question est revenue dans les deux lives. Pour Loïc Michard, une grande partie des clients français de CoderPad sont des ESN. Le format le plus juste simule une mission : une codebase inconnue, une techno parfois non maîtrisée, un bug à corriger ou une fonctionnalité à créer. Il peut se jouer dès le test automatisé.
On peut aller plus loin : trois "clients" en parallèle, avec trois codebases différentes. Commencer par une consigne vague teste aussi une compétence clé du consultant : clarifier le besoin d'un client avant d'exécuter.
7. Comment noter un test technique : la scorecard TPC
La barre se fixe selon le périmètre sur lequel le candidat utilisera l'IA, pas selon un niveau abstrait. Un junior l'utilise sur ses tâches. Un leader IA porte la bascule de toute l'organisation. La scorecard TPC découpe chaque compétence en un plancher et quatre niveaux.
Les quatre niveaux, et le plancher
| Niveau | Périmètre | Ce qu'on attend |
|---|---|---|
| Plancher | Quel que soit le poste | En dessous, le candidat ne passe pas |
| Junior | "Sur mes tâches" | L'IA dans son travail quotidien, avec la prudence de qui apprend encore le métier |
| Confirmé | "Sur mon périmètre" | Une méthode répétable, vérifiée, dont il connaît les limites |
| Senior | "Pour l'équipe et le produit" | Construit ce dont d'autres se servent |
| Leader IA | "Pour l'organisation" | Porte la bascule IA de l'organisation |
La grille complète, compétence par compétence
| Compétence | Plancher | Junior | Confirmé | Senior | Leader IA |
|---|---|---|---|---|---|
| Déléguer | Usage ponctuel et sans logique. Ne sait nommer aucune tâche où l'IA ne doit pas intervenir | Confie des sous-tâches bornées : une fonction, une requête SQL, un brouillon. Garde ce qu'il ne saurait pas vérifier | Confie des tâches entières : une fonctionnalité, une analyse, une maquette. Sait dire ce qu'il a abandonné, et pourquoi | Laisse des agents mener des chantiers entiers, décide lesquels gardent une validation humaine, sait mesurer le gain | Décide quelles tâches et quels rôles basculent vers l'IA, et ce que ça change pour les recrutements |
| Cadrer | Envoie une demande d'une ligne et laisse l'outil exécuter sans regarder | Clarifie le besoin. Donne objectif, contraintes et résultat attendu. Lit le plan avant de le lancer | Configure son agent : fichier d'instructions, conventions, commandes autorisées, skills | Tient à jour la configuration partagée par les agents de l'équipe, et les actions qui exigent une validation humaine | Décide quelles données et quels systèmes l'IA peut lire ou modifier |
| Juger la sortie | Ne questionne jamais ce que l'IA propose. Ne connaît pas les limites de ses outils | Relit avant d'utiliser, repère une erreur grossière, lance les tests, peut refaire sans IA | Attrape l'erreur plausible. Fait écrire les tests, ne fusionne qu'après CI verte et revue | Pose les garde-fous de l'équipe. Sur un produit IA, teste automatiquement les réponses à chaque changement de modèle | Définit ce que l'organisation laisse partir sans relecture humaine, et qui en répond |
| Orchestrer | N'a jamais confié plus qu'une question isolée. Ne sait pas ce qu'un agent ferait de plus | Fait travailler un agent existant sur une tâche de son périmètre | Enchaîne plusieurs agents, l'un qui produit, l'autre qui relit. Sait où le relais casse | Construit un process agentique branché aux systèmes (API, bases, serveurs MCP), avec droits limités et traces. Il tourne pour d'autres | Dessine l'organisation entre humains et agents : qui décide, qui valide, qui maintient |
| Maîtriser les coûts | Non exigé | Non exigé | Non exigé | Chiffre le coût par appel ou par utilisateur, choisit le modèle selon la tâche, pose plafonds et alertes | Pilote le budget tokens comme un poste de budget, arbitre entre construire, acheter et recruter |
L'échelle de notation, pour chaque compétence
| Note | Libellé | Règle |
|---|---|---|
| 1 | Sous le plancher | Correspond à la colonne Plancher. Écarté, quel que soit le poste |
| 2 | Pas encore au niveau | Mieux que le plancher, mais pas ce que décrit la colonne du poste |
| 3 | Au niveau | Fait ce que décrit la colonne du poste, avec un exemple concret |
| 4 | Au-dessus du niveau | Fait aussi ce que décrit la colonne suivante. Pour un poste Leader IA, la note s'arrête à 3 |
Le plancher est éliminatoire dans une entreprise qui utilise l'IA au quotidien. Il décrit un usage ponctuel, pour une recherche ici ou là, sans relecture ni remise en question.
La référence publique : la rubrique Zapier
Zapier est la seule entreprise du benchmark à avoir publié sa grille. Elle définit quatre niveaux : Unacceptable, Capable, Adoptive, Transformative. Ils s'évaluent sur quatre critères : le mindset, la stratégie, ce que le candidat sait construire, et la responsabilité. Elle est déclinée pour 12 métiers et appliquée à quatre moments du process.
Deux chiffres comptent. Moins de 5 % des candidats atteignent le niveau le plus haut. Et entre la V1 de mai 2025 et la V2 de mars 2026, le plancher a été relevé : ce qui suffisait en V1 est classé Unacceptable en V2.
Une grille sans test, c'est possible, et souvent un bon début
DirectLayer, moins de 10 personnes, note trois dimensions sur 10. Leur ordre est le message : l'IA mise en production et la capacité à la tester, puis le sens du produit, puis les bases techniques. Une question pivot tranche le niveau : as-tu construit toi-même un agent autonome en production, ou surveillais-tu des agents construits ailleurs ?
Ce cas montre aussi qu'un critère placé trop haut a un coût chiffrable. En passant de "avoir construit des agents autonomes" à "avoir mis une application d'IA en production", la fourchette de salaire est passée de 85-100k à 70-85k.
Séparer la méthode du résultat
Loïc Michard insiste sur un point. Qu'on note de façon automatique ou humaine, il faut séparer ce que le candidat a produit de sa méthode. C'est la méthode qui compte de plus en plus. Et comme l'IA est stochastique, les grilles doivent être détaillées et aussi déterministes que possible.
Alan a fait un choix différent sur un point. La notation se fait en quatre crans, du refus net au oui franc. Les consignes y sont volontairement peu précises, pour que les évaluateurs gardent leur esprit critique. Ce choix tient parce que 25 évaluateurs sont formés et calibrés entre eux.
À faire avant le prochain entretienN'écrivez pas toute la grille. Écrivez une seule ligne, celle du niveau attendu pour un seul métier, et appliquez-la sur vos trois prochains entretiens.
8. Quelles questions poser en entretien technique sur l'IA ?
Une bonne question de recrutement sur l'IA oblige au concret et ne se récite pas. Les 13 questions ci-dessous viennent du benchmark. Chacune a trois paliers de réponse : faible, correcte, forte. Les questions marquées "observation" ne se posent pas : elles se notent pendant l'exercice.
| # | Compétence | Question | Réponse faible | Réponse correcte | Réponse forte | Source |
|---|---|---|---|---|---|---|
| 1 | Déléguer | "Montre-moi ton setup actuel, puis dis-moi ce que tu as essayé et abandonné ces six mois, et pourquoi." | Une liste d'outils, sans abandon ni raison | Un outil abandonné et sa raison technique. L'endroit où ça casse | L'abandon s'appuie sur un constat, et il a changé ce qu'il confie à l'IA | Zapier |
| 2 | Déléguer | "Tu codes avec l'IA au quotidien ? Depuis quand, sur quels outils, sur quoi précisément, pas juste "j'utilise Cursor"." | "J'utilise Cursor", sans date ni tâche | Une date, des outils nommés, des tâches précises, donnés d'emblée | Les tâches qu'il garde pour lui, et pourquoi | Mozza |
| 3 | Cadrer | "Raconte-moi un cas d'usage que tu as trouvé toi-même : ce que tu as demandé, obtenu, changé." | Des mots-clés, sans demande ni résultat | Le détail de la demande, du résultat, et de la correction | Ce qu'il a changé dans la configuration de son agent pour ne plus corriger la même chose | Stripe |
| 4 | Cadrer | "Sur la dernière tâche confiée à un agent : quel plan t'a-t-il proposé, et qu'as-tu changé avant de le laisser exécuter ?" | N'a pas lu le plan | Un plan relu, une étape corrigée ou retirée, et la raison | Ce qu'il a ajouté aux instructions ou aux skills pour que le plan suivant parte juste | TPC |
| 5 | Juger la sortie | "Donne-moi un cas où l'IA a été moins bonne que ce que tu aurais produit toi-même." | Aucun cas, ou "parfois elle se trompe" | Un cas précis, la raison, l'endroit où il reprend la main | Ce qu'il a mis en place pour attraper cette erreur la fois suivante | Stripe |
| 6 | Juger la sortie (observation) | Pendant l'exercice : le candidat questionne-t-il ce que l'IA lui propose ? | Applique tel quel, même si l'exercice finit juste | Cherche d'abord lui-même, puis décrit précisément à l'IA ce qui ne va pas | Repère que l'IA confirme ce qu'on lui suggère, et formule ses questions pour l'éviter | Alan |
| 7 | Juger la sortie (observation) | Pendant l'exercice : quand une piste ne mène nulle part, repart-il de zéro ? | S'enfonce dans l'impasse, parce qu'il y a déjà passé du temps | Abandonne la piste et explique pourquoi | Teste d'emblée plusieurs pistes courtes, puis garde la meilleure | CoderPad |
| 8 | Juger la sortie | "Avant de fusionner du code produit par un agent, qu'est-ce qui doit passer ?" | Une relecture rapide, ça part si ça compile | Des tests, la CI au vert, une revue humaine | Les tests qu'il fait écrire avant le code, et les règles posées pour l'équipe | TPC |
| 9 | Orchestrer | "As-tu construit toi-même un agent autonome en production, ou surveillais-tu des agents construits ailleurs ?" | Réponse floue, sans exemple | Un rôle clair, avec un exemple | Un agent construit par lui, utilisé par d'autres, et sa façon de le tester | DirectLayer |
| 10 | Orchestrer | "Donne un exemple de régression que ton éval a attrapée." | Pas d'éval, ou une éval décrite en général | Une régression précise | Ce qu'il a ajouté au jeu de cas de référence après coup | DirectLayer |
| 11 | Orchestrer | "Claude Code et le code review automatisé en prod : qui a décidé ça, comment vous mesurez que ça marche, qu'est-ce qui a foiré au début ?" | Discours générique, sans exemple vérifiable | Des exemples vérifiables à l'échelle de l'équipe | Ce qui a raté, ce qui a été corrigé, et l'effet mesuré | PayPlug |
| 12 | Orchestrer | En références : "Quelqu'un utilisait-il ce qu'il avait construit ? Est-ce que ça tourne encore ?" | Rien n'a servi à d'autres | Un outil ou une convention encore utilisés après son départ | Un outil repris et maintenu par l'équipe | TPC |
| 13 | Coût (senior et leader) | "Sur un usage de l'IA que tu as mis en place : combien ça coûte, et comment as-tu arbitré entre qualité et coût ?" | Ne connaît pas le coût | Un ordre de grandeur et un arbitrage assumé | Un coût par appel ou par utilisateur, et le plafond ou changement de modèle décidé | TPC |
Comment écouter les réponses
- Mots-clés = red flag. Une liste d'outils ne prouve aucun usage.
- Chiffres, loupés, corrections = bon signe. Le candidat a mis les mains dedans et connaît les limites.
- Regardez la pente, pas la photo. Ce qu'il a essayé puis abandonné dit où il sera dans six mois.
- Le "comment" vaut plus que le "quoi". Un candidat qui fait améliorer son prompt par l'IA n'est ni bon ni mauvais. Tout dépend de la justification, par exemple vérifier qu'il n'a oublié aucune contrainte.
La question la plus rentableLa question à l'envers de Stripe : un cas où l'IA a fait moins bien que vous. Une phrase, aucun outil, et elle ne se récite pas.
9. Quels outils pour un test technique avec IA ?
Vous pouvez tester la maîtrise de l'IA sans aucun outil payant. Un repo vide et un partage d'écran suffisent pour le format de Shopify. Les plateformes servent surtout à trois choses : mettre tous les candidats à équipement égal, voir ce qu'ils demandent à l'IA, et noter des épreuves ouvertes à grande échelle.
Où en est le marché
CoderPad revendique plus de 3 000 clients. Environ un sur cinq a mis l'IA au centre de ses entretiens techniques, contre un sur six auparavant. Chez ses plus gros clients, grandes plateformes tech et laboratoires d'IA, la proportion monte à un sur trois. Loïc Michard ajoute que les entreprises qui adoptent ce modèle ne reviennent pas en arrière : les signaux sont meilleurs.
Les données marché de CoderPad, surtout américaines, décrivent aussi un effet rebond. L'IA rend un développeur plus efficace, donc plus rentable à recruter. Le nombre de postes ouverts augmente plutôt qu'il ne baisse. La croissance est plus forte sur les postes liés à l'IA, et leur rémunération progresse aussi, y compris hors de la tech.
Le biais d'équipement
Demander au candidat de partager son écran avec ses propres outils pose deux problèmes. Le setup prend cinq à dix minutes. Et un candidat avec un abonnement premium part avec un avantage sur un autre. C'est la logique d'Alan : fournir l'assistant dans l'environnement de test, pour comparer les candidats à équipement égal.
Le choix du modèle change l'entretien
Un retour du chat du live : la plupart des candidats choisissent les modèles les plus puissants, donc les plus lents. Loïc Michard recommande un modèle rapide en entretien. Un résultat final un peu moins abouti compte peu. Il préfère que le candidat itère davantage.
Attendre n'est pas neutre pour autant. Ce que le candidat fait pendant que l'agent travaille est un signal. Lancer plusieurs tâches en parallèle devient aussi plus naturel : c'est déjà comme ça qu'on travaille au quotidien.
"Je m'en fiche du résultat. Je préfère que le candidat itère plus et donc que ça soit plus rapide."
Ce que permettent les plateformes
| Besoin | CoderPad (décrit en live) | HackerRank (repère éditeur) |
|---|---|---|
| Environnement partagé | IDE partagé par un lien, base Visual Studio, code, app et terminal dans une seule fenêtre | Environnement d'entretien assisté par IA |
| Modèles disponibles | Les principaux modèles et agents, sans abonnement du candidat | Assistant IA intégré |
| Contrôle de l'IA | Autorisée ou non selon l'épreuve | Coupable question par question |
| Visibilité sur l'usage | Toute la session est enregistrée, et l'usage de l'IA peut être catégorisé | Échanges avec l'assistant visibles en direct, transcription complète après l'entretien |
| Bibliothèque | Tests existants, personnalisables, et bibliothèque interne partagée par les recruteurs | 26 dépôts de code et 268 tâches annoncés, import de ses propres dépôts |
| Essai | Free trial de deux semaines pour les entreprises, sandbox pour les candidats | Non documenté ici |
Ces informations viennent des éditeurs eux-mêmes. Elles décrivent des capacités produit, pas des pratiques observées en entreprise.
Ce que l'IA débloque pour les tests asynchrones
Avant l'IA, un test à la maison était doublement contraint. Il devait durer entre trente minutes et une heure. Et il devait être noté automatiquement, donc par des tests unitaires déterministes. D'où des exercices artificiels, sur un seul fichier.
Deux contraintes sautent. En une heure avec des agents, un candidat va beaucoup plus loin. Et la notation peut s'appuyer sur l'IA pour évaluer un problème ouvert : jusqu'où il est allé, et si son prototype est testable. Le réalisme devient possible dès le screening, sans temps humain.
S'entraîner, côté candidat
La meilleure préparation est de construire. Prendre un IDE, un agent, et créer des applications. Plus l'épreuve est réaliste, moins on peut faire semblant.
Pour les développeurs, le playbook pour réussir ses entretiens tech rassemble les conseils de CTO.
"Le meilleur bachotage, c'est de pas bachoter et de juste créer des apps et créer des choses."
10. Comment redesigner son process de recrutement tech ?
Dix règles résument ce qui marche dans le benchmark et dans les deux lives. Les cinq premières viennent de Loïc Michard. Les suivantes des entreprises observées.
- Viser le réalisme. Personnalisez l'épreuve avec votre stack, vos problèmes et vos applications internes. Plus elle ressemble au premier jour, meilleur est le signal. Le candidat se projette aussi mieux dans le poste.
- Designer pour le jugement. Dès qu'une épreuve attend une solution unique, un modèle la trouve instantanément. Le signal ne vaut plus rien. Laissez de la place aux arbitrages.
- Laisser le choix de l'outil, ou fournir le même à tous. Les outils changent chaque semaine. Le candidat doit travailler avec ce qu'il maîtrise, sans qu'un abonnement fasse la différence.
- Séparer la méthode du résultat. Notez les deux séparément, avec une grille détaillée. La méthode pèse de plus en plus lourd.
- Boucler la boucle. Comparez ce que vous avez mesuré en entretien avec la performance réelle des recrues. Coinbase envoie des enquêtes à 45 et 90 jours pour vérifier que chaque recrue tient son niveau.
- Annoncer la règle avant chaque épreuve. IA autorisée, interdite ou attendue : le candidat le sait avant de commencer. Tous partent sur le même pied, et vous notez de façon comparable.
- Dire ce que chaque round mesure. Hard skills, jugement, maîtrise de l'IA, ou plusieurs ? La réponse décide de la règle sur l'IA, pas l'inverse.
- Garder le nombre de rounds constant. Avant d'ajouter une épreuve IA, demandez quel round elle remplace. Si personne ne sait répondre, le signal recherché n'est pas assez clair.
- Une méthode par compétence, la même pour tous. Une fois la règle posée, choisissez comment vous évaluez chaque compétence. Puis ne changez pas d'un candidat à l'autre.
- Réviser au moins tous les six mois. Coinbase révise son dispositif chaque trimestre. Un groupe d'ingénieurs, de hiring managers et de recruteurs retire les questions qui ne produisent plus de signal.
"Il faut toujours remettre en question son process du fait de tous ces outils qui vont vite. On navigue à vue sur beaucoup de sujets."
Deux conseils de plus, pour les petites équipes
- Confiez la rédaction à l'équipe concernée. Chez Qantev, l'équipe IA écrit elle-même les questions. Une équipe recrutement seule ne sait pas quoi demander sur l'IA.
- Quand un doute reste, ajoutez l'étape qui manque. Ne tranchez pas à l'intuition. Qantev a créé son exercice en réaction à un signal que son process ne savait pas lire.
Sans référent technique en interne
Une jeune entreprise recrute souvent son premier profil sur un métier que personne ne maîtrise en interne. Le test reste possible, avec quatre précautions.
- Fixer trois à cinq critères avant de voir les candidats. Pas après le premier entretien, quand le premier profil rencontré devient la référence.
- Écrire des exemples de bonnes et de mauvaises réponses. Un évaluateur non spécialiste peut alors noter de façon cohérente. Les trois paliers des 13 questions de la section 8 servent exactement à ça.
- Faire passer l'épreuve à un pair avant de l'ouvrir. Vous vérifiez sa durée et sa clarté. Faites-la aussi passer à un modèle : s'il la résout seul, elle ne départage personne.
- Faire relire la grille par un regard extérieur. Un professionnel du métier, sur la grille et sur les deux ou trois derniers candidats, suffit souvent à sécuriser la décision. C'est le rôle d'un rendez-vous TPC Advisory.
Soigner l'expérience candidat
Un test technique est aussi un moment de marque employeur. Annoncez sa durée, son format, la règle sur l'IA et ce qui sera évalué. Donnez un retour à chaque candidat, même court. Les profils les plus sollicités quittent vite un process opaque ou disproportionné.
11. Ce qui va départager les candidats demain
La barre monte vite. Ce qui est "confirmé" aujourd'hui sera probablement le plancher dans six mois. Trois choses vont départager les candidats : le jugement, l'initiative et la maîtrise du coût.
Les critères existants changent d'objet
Toute la littérature publique parle d'ajouter un critère "maîtrise de l'IA". Plusieurs entreprises ont fait autre chose : elles ont redéfini un critère qui ne départageait plus.
- Galigeo : le niveau de Python attendu porte désormais sur la capacité à juger une sortie.
- Fleet : le signal s'inverse. Un rendu fait entièrement à la main devient suspect.
- Canva : le round d'algorithmie est remplacé par un round où l'IA est obligatoire.
- Coinbase : toute la boucle est refondue, sans un round de plus.
Dans les quatre cas, le critère passe de la production au jugement.
On mesure le builder, beaucoup moins l'orchestrateur
Déléguer, cadrer et juger la sortie s'observent en situation. Orchestrer s'évalue presque uniquement au déclaratif. Aucune épreuve du benchmark ne fait piloter plusieurs agents pendant l'entretien. Le multi-agents décrit par CoderPad reste réservé aux entreprises les plus avancées. Si vous recrutez un senior, votre process voit probablement la moitié de ce qui compte.
L'initiative, le critère qui manque le plus
Les dirigeants interrogés par TPC décrivent le même symptôme. Des profils qui présentent bien en entretien, et n'ont pas le niveau annoncé en poste. Le vocabulaire revient sans concertation : manque de proactivité, incapacité à décider sans qu'on le demande. Quand l'IA exécute, ce qui manque, c'est de savoir quoi faire.
L'initiative, concrètement : repérer les gains de temps possibles, au-delà de son propre poste. Voir qu'une équipe voisine perd du temps sur une tâche répétitive, et proposer un outil ou un agent.
Le coût, le critère qui arrive
Beaucoup d'entreprises se sont ruées sur l'IA sans regarder la facture. L'ère du "token maxing" touche à sa fin. Les tokens deviennent une ligne de budget à part entière. Un leader devra auditer ses agents : celui-ci fait gagner du temps, mais son coût par appel justifie-t-il de le garder ?
Qui est vraiment exposé ?
Interrogé en live sur les juniors, Loïc Michard observe plutôt une hausse moyenne du recrutement de juniors chez les clients de CoderPad. Leur fraîcheur sur les nouveaux outils compense un manque d'expertise et de taste, qui s'apprend. L'onboarding devient critique.
Pour lui, la population la plus exposée n'est pas définie par la séniorité. C'est celle qui situe encore la valeur de son travail dans l'écriture du code.
"Soit j'écris du code et le LLM peut le faire mieux que moi. Ou soit je suis juste un proxy entre un PM qui m'envoie une spec et le LLM."
Il termine sur un point d'attention pour les employeurs : rester réaliste sur les objectifs, pour éviter la fatigue liée à l'IA. L'outil doit permettre de résoudre plus de problèmes, pas d'épuiser les équipes.
À retenirÉvaluer la maîtrise de l'IA ne revient pas à créer une compétence à part. Les métiers ont changé. On ne peut donc plus les évaluer comme il y a dix ans.
12. FAQ : test technique et IA
Faut-il autoriser l'IA pendant un test technique ?
Oui sur la plupart des épreuves, non sur une étape ciblée, et toujours en l'annonçant avant. Aucune des 18 entreprises du benchmark ne l'interdit sur tout son process. L'interdire partout revient à mesurer quelqu'un d'autre que celui que vous recrutez. Une étape sans IA reste utile pour vérifier les fondamentaux, à condition d'expliquer pourquoi.
Comment savoir si un candidat a triché avec l'IA ?
Ne cherchez pas à détecter l'IA : vérifiez la compréhension. Annoncez la règle, demandez une déclaration d'usage, puis interrogez le candidat sur son travail. Doctolib se réserve un exercice en direct sans outil pour vérifier un take-home. Algolia annonce qu'en cas de doute, elle demandera d'autres preuves de travail original.
Le take-home a-t-il encore un sens avec l'IA ?
Oui, s'il nourrit un oral. Un take-home qu'un prompt résout ne mesure plus rien. Fleet, Doctolib et Everping l'ont gardé en notant la restitution plutôt que le rendu. La troisième question précise suffit à séparer celui qui a pensé son cas de celui qui l'a délégué.
Faut-il encore faire du live coding en entretien ?
Oui, mais plus sur un exercice d'algorithmie qu'un modèle résout en deux secondes. Trois options marchent : un énoncé trop large pour un prompt (Canva), un repo vide qui s'enrichit (Shopify), ou du code existant avec un bug caché (Alan). Un court exercice de fondamentaux sans IA peut compléter.
Comment évaluer un développeur qui code avec Copilot ou Claude ?
Regardez comment il dirige l'outil, pas s'il l'utilise. Les signaux : il clarifie le besoin avant de lancer l'agent, relit le plan, questionne les propositions, et sait dire ce que fait le code généré. Chez Canva, l'interviewer demande après chaque génération : qu'est-ce que fait ce code ?
Quel cas pratique donner à un product manager en 2026 ?
Un cas qui commence par la mesure, pas par le modèle. Exemple : un client veut un assistant de facturation. Avant de parler prompt, le PM décrit le jeu d'évaluation, les modes d'échec et le plan de retour arrière. En live, faites-lui cadrer, prototyper, puis défendre ses arbitrages face à une contrainte ajoutée.
Comment tester un product designer avec l'IA ?
Testez le tri, pas la génération. Demandez une piste jetée et la raison. En cas pratique, un brief ambigu, plusieurs directions et une recommandation tranchée. Chez Everping, le cas est défendu sur place devant l'équipe, avec une justification de l'usage de l'IA.
Quelle question poser en premier entretien sur l'usage de l'IA ?
Une question qui interdit la réponse toute faite. Celle de Mozza : "Tu codes avec l'IA au quotidien ? Depuis quand, sur quels outils, sur quoi précisément, pas juste "j'utilise Cursor"." Ou celle de Stripe : un cas où l'IA a fait moins bien que vous.
Une petite entreprise sans budget peut-elle tester la maîtrise de l'IA ?
Oui. Galigeo, 20 personnes, le fait avec un test SQL réel, un jeu de données à lire et quinze minutes avec le CEO. Everping, 40 personnes, avec une phrase dans le brief et une restitution orale. Un repo vide et un partage d'écran suffisent pour un live.
Comment évaluer la maîtrise de l'IA d'un CTO ou d'un manager ?
Sur la gouvernance, pas sur la pratique personnelle. Demandez qui a décidé d'un dispositif IA, comment il est mesuré, et ce qui a raté au début. Le red flag est un discours générique sans exemple vérifiable. En références, vérifiez que le changement a tenu après son départ.
Le prompt engineering est-il encore un critère ?
De moins en moins. Loïc Michard regarde beaucoup moins la façon de prompter, vu la capacité des modèles. Ce qui compte : qualifier le besoin, configurer l'agent, lui donner le bon contexte et valider son plan.
Comment tester les capacités de refactoring ?
Le format est encore rare en entretien. Loïc Michard suggère une piste : donner une codebase existante et demander une migration, par exemple du backend vers Rust. On observe ce que le candidat vérifie pour s'assurer que rien ne casse.
Combien de temps doit durer un test technique de recrutement ?
Le moins longtemps possible pour produire un signal évaluable. En asynchrone, CoderPad vise entre trente minutes et une heure : au-delà, l'épreuve mesure la disponibilité du candidat. En direct, les formats du benchmark durent de 30 minutes (CoderPad) à 45 minutes (Alan). Pour un take-home, distinguez le délai de rendu du temps de travail réellement demandé.
À quel moment du process placer le test technique ?
Assez tôt pour éviter de dépenser des entretiens de fit sur de mauvais profils. Streem Energy place son épreuve IA en deuxième round, juste après le screening, parce que c'est elle qui filtre le plus. La question qui tranche le niveau peut même se poser dès le premier entretien, comme chez DirectLayer et Mozza.
Comment éviter qu'un test technique devienne du travail gratuit ?
Inspirez-vous de vos vrais problèmes, sans demander un livrable exploitable. Un diff déjà fusionné de votre historique suffit pour une revue de code. Un problème déjà résolu, ou un cas métier fictif comme l'aéroport saturé de Canva, garde le réalisme sans produire de valeur pour l'entreprise.
Comment garantir l'équité entre les candidats ?
Mêmes consignes, même règle sur l'IA, même grille. Fournissez l'outil dans l'environnement de test, comme Alan, pour qu'un abonnement premium ne fasse pas la différence. Et prévoyez des aménagements : Doctolib cite explicitement la compensation d'un trouble comme la dyslexie parmi les usages légitimes de l'IA.
Faut-il donner un retour au candidat après un test technique ?
Oui, court et appuyé sur les critères annoncés. Avec la scorecard, le retour devient factuel : la compétence, le niveau atteint, et l'exemple qui l'a montré. Évitez les commentaires vagues sur le potentiel.
13. Replays et ressources
Les replays
L'entretien tech à l'ère de l'IA, avec Loïc Michard (CoderPad)
Contexte marché, démos d'entretiens live et asynchrones, Q&A
Évaluer la maîtrise de l'IA en entretien, avec Juliette Demain (TPC)
Les 5 compétences, les cas du benchmark et la scorecard TPC
Tech @ Alan : entretien Software Engineer en live
L'exercice Keyfinder
Podcast Reshape TPC, épisode Fleet
Le take-home noté à l'oral
Podcast Reshape TPC, épisode Stripe
La maîtrise de l'IA comme critère de rubrique
Le benchmark complet
Les 18 fiches entreprises, la scorecard détaillée et les 13 questions sont dans le benchmark TPC sur la maîtrise de l'IA en entretien.
D'autres méthodes pour cadrer, sourcer et évaluer sont réunies dans la boîte à outils du recruteur.
Besoin d'un regard extérieur sur votre process ?
TPC Advisory propose un rendez-vous de 30 minutes avec un consultant TPC. Pour revoir votre scorecard, votre process d'entretien ou la place de l'IA dans vos tests.
Sources publiques citées
- Coinbase, "Interviewing Engineers in the AI Era", 13 juillet 2026
- Canva Engineering, "Yes, You Can Use AI in Our Interviews", 11 juin 2025
- Canva Engineering, "AI Interview Success", 20 octobre 2025
- Zapier, "Raising the AI fluency bar for every hire", V2, 31 mars 2026
- Doctolib Careers, "AI usage for candidates", 24 novembre 2025
- Mirakl, "AI Guidelines for Candidates and Interviews", octobre 2025
- Algolia, "AI guidelines for candidates", 5 novembre 2025
- Datadog, "Interviewing at Datadog: AI Guidelines", 13 mai 2026
- The Pragmatic Engineer, entretien Farhan Thawar (Shopify), 2 juillet 2025
- HackerRank, "How to Interview Engineers Who Use AI Coding Assistants", 29 juillet 2026
- HackerRank, "AI-Assisted Interviews", documentation produit
4. Comment adapter les tests techniques que vous avez déjà ?
La voie la plus efficiente consiste à adapter votre process existant, pas à empiler des épreuves. Coinbase a refondu toute sa boucle en un an sans ajouter un seul round. Chaque nouveau signal remplace un round existant ou capte ce que la boucle ne mesurait pas.
Le premier entretien : arrêter les questions sur le tooling
"Tu utilises l'IA ?" Tout le monde répond oui. "J'utilise Cursor depuis deux ans et demi" ne vous apprend rien non plus. Mozza a réécrit sa question de screening pour que la réponse toute faite ne tienne pas dix secondes.
C'est la dernière incise qui fait le travail : nommer son outil ne suffit plus. Mozza ajoute un gate : avoir déjà livré une fonctionnalité IA en production pour un client. Pas seulement sur ses projets personnels.
Ce que vous cherchez, c'est une histoire. Un outil essayé, ce qu'il a rapporté, l'endroit où il a cassé, ce qui a été corrigé. Une suite de mots-clés est un red flag. Des chiffres, des loupés et des pistes d'amélioration sont un bon signe.
Le take-home : il n'est pas mort, il a changé de fonction
Un take-home dont l'énoncé se résout en un prompt est mort. Celui qui alimente un oral reste très utile. Trois entreprises du benchmark l'ont gardé, à trois échelles différentes.
Le patron est le même dans les trois cas. Le rendu asynchrone devient le support d'un oral où le candidat justifie ses choix, y compris ceux qu'il a délégués.
À reprendre tel quelPrévenez le candidat, dans le brief, que l'oral portera sur ses choix et non sur le document. Cela ne coûte rien et déplace la note du rendu vers le raisonnement.
Le live coding algorithmique : réécrire l'énoncé, pas interdire l'outil
Deux options existent. Remplacer l'énoncé par un problème trop large pour une seule requête, comme Canva. Ou partir d'un dépôt vide, comme Shopify. Les deux sont détaillés dans la partie suivante.
La revue de code : juger un travail qu'on n'a pas produit
On donne au candidat une pull request produite par un agent ou un collègue. Elle contient un défaut plausible qu'on ne signale pas. Il doit décider s'il l'approuverait. Le coût est faible : un diff de votre historique suffit. La condition : un défaut réaliste, sinon le test ne mesure rien.
L'exercice sur code existant : Keyfinder chez Alan
Alan a ajouté un assistant IA dans l'éditeur de code de l'entretien. Il voit le code du candidat. Le candidat s'en sert ou non, et sa façon de l'utiliser compte dans la note.
L'exercice s'appelle Keyfinder et dure 45 minutes. Le candidat reçoit du code existant qui corrige des typos. Il contient un bug caché qu'on ne lui signale pas. L'assistant est présenté comme une aide possible, au même titre que Google ou Stack Overflow. L'interviewer freine toute optimisation trop précoce.
Le même exercice et la même grille servent à tous les niveaux, y compris pour un manager. Deux choses révèlent le niveau : le nombre de fois où il faut guider la personne, et sa capacité à challenger l'approche. Alan a formé 25 évaluateurs pour que tous notent de la même façon.
L'exercice est aussi adapté aux problèmes réels d'Alan. Les candidats disent mieux comprendre l'entreprise et se projettent plus facilement dans le poste.
Le cas stratégique : la gouvernance, pas la pratique personnelle
Sur un poste de direction technique, PayPlug note à part, sur 10 points, le pilotage de l'IA dans les équipes de développement. Le red flag est nommé : un discours IA générique, sans exemple vérifiable. La question force le candidat à revenir à une décision précise.
Les trois temps disent tout. Qui pilotait. S'il mesure. Et s'il est assez honnête pour raconter ce qui a cassé, puis ce qui a été corrigé.
Les références : ce qui tient après le départ
En prise de référence, posez une question simple à l'ancien employeur. Ce que le candidat a mis en place est-il encore utilisé ? Apporte-t-il toujours un résultat ? Un système qui survit au départ de son auteur est la meilleure preuve d'orchestration.