Blog de Paul Jorion

Illustration par ChatGPT

L’aptitude à la logique prévaut aujourd’hui sur la connaissance des mots clés des langages informatiques (mémoire) – mais celle-ci n’est pas testée chez les candidats

Un paradoxe traverse aujourd’hui le recrutement informatique. Les grands modèles de langage ont rendu triviale la restitution des syntaxes, des signatures d’API, des noms de fonctions, bref de tout ce que l’on appelait autrefois « connaître un langage ». Demander à un candidat de réciter la différence entre let et const, de se souvenir de l’ordre des arguments de array_map en PHP, ou de retrouver de tête la syntaxe d’une jointure SQL exotique, c’est tester une compétence que n’importe quel IDE moderne couplé à un LLM exécute en quelques secondes.

Et pourtant, c’est exactement ce que continuent à tester les entretiens techniques. HackerRank, Codingame, questions pièges sur les subtilités du typage JavaScript, QCM sur les particularités de Symfony ou de Spring : l’industrie sélectionne sur la mémoire lexicale au moment précis où cette mémoire devient la partie la plus délégable du métier.

Ce que Jorion et Delbos nous ont appris

Paul Jorion et Geneviève Delbos ont établi de longue date une distinction qui éclaire ici la situation : la connaissance ne se transmet pas ; seul le travail se transmet (La transmission des savoirs – 1984). On ne donne pas à un apprenti la compétence de son maître en lui récitant ce que le maître sait – on la lui transmet en le faisant participer au travail, c’est-à-dire à l’effort de structuration d’un réel résistant.

Cette distinction, qui paraissait il y a encore dix ans une finesse philosophique parmi d’autres, devient aujourd’hui une ligne de partage opérationnelle. La mémoire lexicale – les mots clés, les API, les syntaxes – appartient à la connaissance : elle est transmissible par simple énumération, donc restituable par une machine statistique. Le travail, lui, reste irréductible : structurer un problème mal posé, articuler des contraintes contradictoires, reconnaître les causes sous les symptômes – cela ne se récite pas, cela s’exerce.

Le recrutement informatique, en continuant à tester la connaissance lexicale, teste ce que la machine restitue aussi bien que l’homme, et laisse intouché ce qui distingue encore l’un de l’autre.

Ce qui reste irréductible

Ce que les LLM ne font pas – ou font mal, ou font en hallucinant – c’est la structuration logique d’un problème mal posé. Un client arrive avec une demande floue, un système existant mal documenté, des contraintes contradictoires : performance et lisibilité, évolutivité et délai court, sécurité et ergonomie. Le travail du développeur senior consiste alors à identifier les causes réelles derrière les symptômes énoncés, à distinguer ce qui relève de la structure et ce qui relève de l’accident, à décomposer le problème en sous-problèmes dont chacun admet une solution, et à articuler ces solutions en un ensemble cohérent.

Cela, c’est de la logique au sens aristotélicien : reconnaître les causes : matérielle, formelle, efficiente, finale – d’une situation avant de prétendre la résoudre. Et cela, précisément, aucun test de recrutement standard ne le mesure.

Le paradoxe du filtrage

Le filtrage actuel produit une double erreur symétrique. D’un côté, il laisse passer – et parfois valorise – des candidats rapides à réciter, capables de résoudre un exercice LeetCode en douze minutes, mais incapables de tenir une conversation de conception architecturale sans perdre le fil des dépendances logiques. De l’autre, il exclut des profils dont la valeur ajoutée, à l’ère des LLM, serait précisément maximale : ceux qui savent penser un système, articuler des contraintes, poser les bonnes questions avant d’écrire la première ligne de code.

L’ironie est que ces profils logiciens sont ceux qui tirent le meilleur parti des LLM. Non pas parce qu’ils les utilisent davantage, mais parce qu’ils savent exactement quoi leur demander. Un LLM est une machine à exécuter des spécifications ; encore faut-il savoir spécifier. La spécification, c’est du travail au sens de Jorion et Delbos – c’est l’effort de mise en forme logique d’un réel, pas la restitution d’un lexique.

Ce que cela signifie pour l’entreprise

Continuer à recruter sur la mémoire lexicale en 2026, c’est importer dans l’équipe la compétence que la machine fait le mieux, et se priver de celle qu’elle ne fait pas. C’est acheter des exécutants là où les exécutants sont devenus la ressource la moins rare, et laisser à la concurrence les concepteurs, qui eux restent rares.

Le test qui manque est simple dans son principe, difficile à standardiser dans sa mise en œuvre : présenter au candidat un problème réel, ambigu, sous-spécifié, et observer non pas ce qu’il code, mais comment il interroge le problème. Quelles hypothèses explicite-t-il ? Quelles questions pose-t-il avant d’écrire ? Quelles alternatives envisage-t-il ? Comment justifie-t-il un choix contre un autre ?

C’est un entretien de philosophie appliquée, bien plus que de technique. Et c’est pour cela qu’il n’a pas lieu : il est coûteux, il demande des évaluateurs eux-mêmes logiciens, et il ne produit pas de score facilement comparable entre candidats. La facilité administrative l’emporte sur la pertinence fonctionnelle.

Conclusion

L’industrie informatique a construit, sur plusieurs décennies, un système de filtrage calibré pour une époque où la mémoire des syntaxes était la ressource rare. Cette époque est terminée. La ressource rare est devenue la capacité à structurer un problème – autrement dit, pour reprendre la formule de Jorion et Delbos, non pas la connaissance qu’on récite mais le travail qu’on transmet.

Tant que ce déplacement ne sera pas acté dans les grilles de recrutement, les entreprises continueront à s’étonner que leurs équipes produisent vite du code qui, pris ensemble, ne tient pas debout. Elles auront recruté sur le symptôme au lieu de recruter sur la cause.