Évaluations techniques résistantes à l'IA : comment Anthropic a repensé ses tests de recrutement

#Le contexte : un test technique devenu obsolète

L'équipe d'ingénierie performance d'Anthropic utilise un test technique en take-home pour recruter ses ingénieurs. Le principe est classique : un exercice à faire chez soi, en conditions libres, qui simule le travail réel.

Leur test original fonctionnait très bien. Plus de 1 000 candidats l'ont passé. Des dizaines ont été embauchés grâce à lui — y compris des ingénieurs qui ont ensuite monté le cluster Trainium d'Anthropic et livré chaque modèle depuis Claude 3 Opus.

Le problème ? Chaque nouveau modèle Claude rendait le test un peu plus facile à résoudre par une IA. Jusqu'au jour où Claude Opus 4.5 a obtenu un meilleur score que n'importe quel candidat humain, dans le temps imparti de 2 heures.

L'équipe a dû se poser une question fondamentale : comment concevoir un test technique qui reste pertinent quand l'IA sait le résoudre ?

#Le test original : un simulateur d'accélérateur

Pour comprendre le défi, il faut d'abord comprendre le test. L'exercice demandait aux candidats d'optimiser du code Python sur un simulateur de processeur qui ressemblait à un TPU (Tensor Processing Unit, le type de puce utilisé pour entraîner des modèles d'IA).

Concrètement, le candidat devait :

1. Implémenter un parcours d'arbre parallèle (volontairement éloigné du deep learning)
2. Optimiser les performances en utilisant le parallélisme multicœur
3. En option, aller plus loin avec la vectorisation SIMD ou le packing d'instructions VLIW
4. Construire ses propres outils de débogage avec des traces de performance Perfetto

Le test avait été pensé selon quatre principes :

• Représentatif du travail réel d'un ingénieur performance
• Signal élevé avec plusieurs axes d'évaluation (optimisation, debugging, outillage)
• Pas de connaissances niche requises — un bon ingénieur pouvait réussir sans expertise TPU
• Engageant pour que les candidats restent motivés

#L'escalade : comment chaque modèle a battu le test

L'équipe testait chaque nouveau modèle Claude sur leur évaluation. Voici comment la situation a dégénéré.

#Claude Opus 4

Premier signal d'alerte. Opus 4 a surpassé la majorité des candidats humains dans la limite de 4 heures. La qualité de sa solution dépassait ce qu'on attendait d'un humain moyen.

L'équipe a réagi en retirant la partie multicœur (déjà résolue par le modèle) et en nettoyant le code de départ pour proposer une version 2 du test avec des fonctionnalités machine supplémentaires.

#Claude Opus 4.5

Là, ça a basculé. En moins d'une heure sur les deux allouées, Opus 4.5 avait résolu les goulots d'étranglement initiaux. Il enchaînait ensuite avec des micro-optimisations automatiques. Quand on le guidait vers des comptages de cycles atteignables, il trouvait des astuces non évidentes pour contourner les limitations de bande passante mémoire.

Résultat : dans le temps imparti de 2 heures, Opus 4.5 a battu le meilleur score humain jamais enregistré.

#La progression en chiffres

Plus le nombre de cycles est bas, meilleure est la performance. En quelques mois, le modèle est passé de 2164 à 1363 cycles — une amélioration de 37%.

#Pourquoi les solutions évidentes ne marchent pas

Face à ce problème, les premières idées qui viennent à l'esprit semblent logiques. Mais elles échouent toutes.

#Réduire le temps imparti

L'intuition : si on donne moins de temps, l'humain qui connaît bien le sujet sera plus rapide que l'IA. En pratique, c'est l'inverse. Claude travaille plus vite que les humains dans des fenêtres de temps courtes. Réduire le temps avantage le modèle.

#Augmenter la difficulté

Monter le niveau semble logique, mais ça crée un double problème : le test devient injouable pour la plupart des candidats humains, tout en restant accessible au modèle (qui a vu des millions d'exemples d'optimisation).

#Rester dans le même domaine

Le cœur du problème : les exercices d'optimisation de code sont abondamment documentés sur internet. Les modèles de langage ont été entraînés sur cette littérature. Tant que le test ressemble à un problème connu, le modèle a un avantage structurel.

#Les tentatives de refonte

#Tentative 1 : transposition de données

L'équipe a conçu un nouveau problème basé sur une vraie optimisation de kernel — la transposition de registres TPU avec gestion des conflits de banques mémoire.

Le résultat ? Claude a trouvé une optimisation à laquelle le concepteur n'avait pas pensé : transposer le calcul plutôt que les données. Quand l'équipe a corrigé cette faille, la fonctionnalité "ultrathink" de Claude (qui donne au modèle un budget de réflexion étendu) a quand même résolu le problème.

Pourquoi ça n'a pas marché : des ingénieurs sur différentes plateformes ont documenté des solutions similaires. Claude avait suffisamment de données d'entraînement dans ce domaine.

#Tentative 2 : puzzles à la Zachtronics

L'idée gagnante est venue d'un univers inattendu : les jeux vidéo de puzzle de programmation. Les jeux Zachtronics (TIS-100, Shenzhen I/O) proposent de résoudre des problèmes avec des jeux d'instructions minuscules et très contraints.

L'équipe a adapté ce concept :

• Des jeux d'instructions fortement contraints avec un nombre minimal d'opérations
• Aucun outil de visualisation fourni — le choix de construire ses propres outils de débogage fait partie de l'évaluation
• Des sous-problèmes indépendants pour réduire la variance et avoir plus de signal

#Le dilemme fondamental : réalisme versus résistance

L'article d'Anthropic met le doigt sur une tension profonde dans la conception d'évaluations techniques.

Le test original fonctionnait parce qu'il ressemblait au travail réel. Les candidats qui réussissaient étaient effectivement de bons ingénieurs performance. Mais justement parce qu'il ressemblait au travail réel, Claude pouvait le résoudre — le modèle a été entraîné sur exactement ce type de problèmes.

Le nouveau test résiste à l'IA parce qu'il s'éloigne des problèmes connus. Mais en s'éloignant du travail quotidien, on prend le risque de mesurer autre chose que la compétence visée.

C'est le compromis central :

• Plus réaliste = plus vulnérable aux modèles (qui ont vu ces problèmes en entraînement)
• Plus résistant = potentiellement moins représentatif du travail réel

L'approche Zachtronics tente de concilier les deux : les compétences testées (raisonnement, optimisation, construction d'outils) restent pertinentes, même si le contexte est inhabituel.

#Ce qui fonctionne (et ce qui ne fonctionne pas)

#Le choix de ne pas interdire l'IA

Un détail important : Anthropic a choisi de ne pas interdire l'utilisation d'outils IA pendant le test.

Le raisonnement est pragmatique. Dans le travail quotidien, les ingénieurs utilisent des assistants IA. Un bon test devrait refléter la réalité du métier. Plutôt que d'interdire les outils (ce qui est de toute façon difficile à vérifier), l'équipe a conçu un test où utiliser l'IA ne suffit pas à obtenir un bon score.

Les problèmes à horizon long — ceux qui nécessitent un raisonnement soutenu sur plusieurs heures — restent hors de portée des modèles actuels. Un candidat peut utiliser Claude comme assistant, mais devra démontrer ses propres compétences sur les aspects que l'IA ne résout pas encore.

#Ce que ça signifie pour les développeurs

Même si tu ne recrutes pas d'ingénieurs performance chez Anthropic, cette histoire contient des enseignements utiles.

Pour les recruteurs : si ton test technique peut être résolu par un modèle de langage en copiant-collant le sujet, il est probablement temps de le repenser. Les exercices algorithmiques classiques (LeetCode, HackerRank) sont les premiers à tomber.

Pour les candidats : les compétences qui restent valorisées sont celles que l'IA ne maîtrise pas encore — le jugement, la conception d'outils, le raisonnement sur des problèmes inédits, et la capacité à travailler sur des horizons longs.

Pour les développeurs : la valeur humaine se déplace. Comme le résume l'équipe d'Anthropic, le travail quotidien de leurs ingénieurs performance ressemble désormais davantage à du debugging difficile, de la conception système, de l'analyse de performance, et de la vérification de correction — des tâches qui demandent jugement et contexte, pas juste de l'optimisation mécanique.

#Récapitulatif

L'expérience d'Anthropic montre que concevoir des évaluations à l'épreuve de l'IA est un défi en mouvement. Chaque avancée du modèle rend obsolète une partie des tests existants.

Les pistes qui fonctionnent aujourd'hui :

• Sortir de la distribution : des problèmes originaux que le modèle n'a pas vus en entraînement
• Évaluer le jugement : les décisions de conception et de priorisation, pas juste la capacité à coder
• Miser sur l'horizon long : les tâches qui demandent un raisonnement soutenu sur plusieurs heures
• Accepter l'IA comme outil : concevoir des tests où l'assistance IA est utile mais insuffisante

La question n'est plus "comment empêcher les candidats d'utiliser l'IA ?" mais plutôt "comment évaluer ce que l'IA ne sait pas encore faire ?"

Et cette question-là, pour l'instant, il n'y a que des humains pour y répondre.