Comment savoir qui réfléchit vraiment ?

En ce moment, dans ton équipe, il y a au moins un ingénieur qui livre du travail qu’il serait incapable de reproduire sur un tableau blanc.

Le code compile. Les tests passent. La PR est impeccable. Mais le raisonnement n’était pas le sien au départ, et il ne le sait pas. De l’intérieur, emprunter une pensée donne exactement la même impression que d’en avoir une.

Tu le découvriras la prochaine fois que quelqu’un posera la question du cache. Le schéma d’architecture est à l’écran, la conception a l’air propre, et un staff engineer se penche en avant :

Explique-moi pourquoi tu as écarté un write-through cache ici. Que se passe-t-il quand ce nœud précis redémarre sous charge ?

La pause qui suit devrait être une pause de récupération : l’ingénieur fouille son propre modèle mental pour retrouver la contrainte qu’il avait envisagée, l’alternative qu’il avait pesée, l’effet de second ordre qu’il suivait quand il a tranché.

Aujourd’hui, la pause est un vide.

La friction portait la charge

Ce n’est pas une oraison funèbre pour le bon vieux temps où on fouillait Stack Overflow.

L’IA est un formidable multiplicateur. C’est un relecteur de minuit infatigable qui lira ta conception à 1 h du matin sans se plaindre. C’est un partenaire d’entraînement qui tiendra un contre-argument assez longtemps pour que tu montes une vraie défense. Il te signale le point que tu avais survolé. Les ingénieurs qui s’en servent bien sont, selon n’importe quelle mesure honnête, plus affûtés qu’il y a deux ans. Je m’en sers. Tu t’en sers. Ce texte serait une imposture s’il prétendait le contraire.

Mais on a commis une erreur de catégorie, sans bruit. On a cru que la friction du métier n’était qu’une limite de vitesse. Ce n’était pas ça.

La friction ne se contentait pas de nous ralentir, elle portait la charge. C’était une carte topographique en temps réel qui te disait où se cachaient les vrais problèmes. On a supprimé la friction à force d’optimiser, et on a effacé la carte avec.

Quand un problème était vraiment dur, tu passais trois heures à fixer un mur, à transpirer devant un tableau blanc et à douter de ton choix de carrière. La friction était une boussole. Cette même friction qui rendait le travail pénible t’obligeait à construire le modèle dans ta tête : la sémantique du write-through, les modes de défaillance, la fenêtre de lecture après écriture. Tu gardais tout ça dans ton crâne jusqu’à pouvoir défendre la conception sans le document sous les yeux.

Le modèle hallucine en douze secondes un document d’architecture parfaitement formaté, à la syntaxe suave. Tu n’as pas de friction. Tu as une giclée de dopamine et un mensonge. Tu as la réponse. Tu n’as pas le muscle.

L’axe brisé

Une organisation d’ingénierie, c’est un problème d’échantillonnage. Tu ne peux pas regarder chaque frappe au clavier, alors tu lis les artefacts et tu en déduis la réflexion. Pull requests, design docs, postmortems, de temps en temps une revue d’incident. Ce sont les instruments d’échantillonnage. Les évaluations de performance, la calibration, les barèmes de promotion et les entretiens d’embauche reposent tous sur l’hypothèse que l’artefact et la réflexion viennent du même endroit.

L’IA a cassé l’axe qui reliait ces deux roues.

Le résultat dépend désormais de trois variables, l’ingénieur, le modèle et le prompt, et les artefacts te parlent des trois en vrac, sans aucun moyen de séparer le signal. Une PR soignée est compatible avec un ingénieur réfléchi, un ingénieur qui ne l’est pas, ou un onglet laissé ouvert dans le train. L’artefact arrive toujours à l’heure. Il ne porte simplement plus le signal pour lequel tu le lisais.

Ça compte surtout pour les ingénieurs que tu essaies de faire grandir. Un senior qui produit une sortie d’IA fluide est, au pire, démultiplié. Le muscle est déjà construit, le modèle ne fait que conduire le clavier. Un junior qui produit la même sortie la produit sans jamais construire le muscle que ce travail devait construire. Il livre le write-through cache sans jamais modéliser ce qui se passe quand le nœud tombe. Il livre le read replica pour l’analytique sans jamais s’être arrêté sur la fenêtre de cohérence. L’artefact est correct. L’intuition d’architecture qui devait pousser dessous n’est jamais venue.

Le paradoxe METR

Voici un chiffre qui devrait sauter aux yeux des dirigeants de l’ingénierie. METR a mené une étude rigoureuse en 2025. Des développeurs expérimentés qui utilisaient une assistance IA ont terminé leurs tâches 19 % plus lentement que sans, tout en croyant aller 20 % plus vite.¹ Les juniors sur du code qu’ils ne connaissent pas, dans un travail distinct de McKinsey, vont dans l’autre sens : 26 à 39 % plus vite.²

Le gradient va dans le mauvais sens pour un organigramme. Pourquoi les juniors ressemblent-ils à des ingénieurs 10x alors que les seniors ont l’air stables ?

Les seniors ne sont pas moins bons avec l’IA. Le travail que l’IA aide à faire n’est pas celui qu’ils faisaient. Leur goulot d’étranglement n’a jamais été de taper, c’était de décider quoi taper. Les juniors paraissent rapides parce que leur goulot d’étranglement, c’était la frappe, et maintenant la frappe est gratuite. La fonction de production ne s’est pas seulement améliorée, elle a changé de place. Elle a quitté l’artefact. Les juniors produisent une sortie qui a l’air senior. Ils ne construisent pas, selon le moindre signal mesurable, un jugement de senior.

Les juniors ferment des tickets si vite que le tableau Jira ressemble à une machine à sous qui crache les pièces. Le tableau de bord dit qu’ils vont 39 % plus vite. Le tableau de bord est ravi. Le tableau de bord, lui, n’aura pas à maintenir la machine à états qu’ils viennent d’inventer.

Trois choses qui déraillent dans ta tête

Trois mécanismes psychologiques se déclenchent en même temps quand tu lis une sortie d’IA fluide et que tu la prends pour ta propre pensée. Ils sont documentés, vieux de plusieurs décennies, et n’ont pas pris une ride.

L’illusion de fluidité. On juge à quel point on comprend une chose à la facilité avec laquelle elle nous vient à l’esprit.³ La sortie d’une IA est d’une facilité maximale. Soignée, assurée, structurée exactement au niveau que tu peux absorber. La lire donne la douce sensation de comprendre, sans le travail qui produit d’habitude cette sensation.

La chaleur de la compréhension, c’est le bug.

Le signal d’effort perdu. Pendant la plus grande partie de ta carrière, c’était dur servait d’indicateur fiable de je fais un vrai travail de réflexion. La friction faisait l’étalonnage à ta place. Avec le modèle dans la boucle, la réflexion est déléguée mais l’indicateur n’est pas réétalonné. Tu livres, ça t’a paru facile, tu en conclus que c’était simple, alors que ça veut peut-être dire que tu n’as pas réfléchi.

La dérive d’attribution. La recherche sur le contrôle de la source a quarante ans. On ne sait pas distinguer de façon fiable les idées qu’on a produites de celles qu’on nous a soufflées.⁴ D’ici jeudi, la dérive est complète. L’ingénieur regarde un bloc de regex de 400 lignes qu’il a « fait en binôme » avec le modèle et pense sincèrement : Ah oui, je me souviens d’avoir méticuleusement façonné ce negative lookbehind. Non. Tu as demandé à la zone de saisie de faire disparaître les caractères gênants et tu as accepté le premier extrait qui ne plantait pas.

La question du cache tombe en plein là-dedans. L’ingénieur a écrit la couche write-through avec un modèle dans la boucle. Ça lui a paru facile. Le code compile. Les tests passent. Mais il ne s’est jamais arrêté sur ce qu’il advient de l’écriture en vol quand le nœud tombe. Il ne s’est jamais arrêté sur ce que voit la base de données quand le cache revient en rafale, ni sur ce que renvoie le chemin de lecture pendant le préchauffage. Il n’a aucun modèle mental où aller chercher quand on lui pose la question. Le code n’a rien de faux. Il n’y a rien dans la tête de l’ingénieur.

L’introspection ne marche plus

L’effet combiné est la partie qui devrait te priver de sommeil.

L’ingénieur qui a basculé de la prolongation à la substitution ne ment pas quand il dit qu’il a mûrement réfléchi. Il s’est senti à l’aise. Le travail lui a paru facile, comme paraît facile un travail qu’on comprend bien. Il se souvient du raisonnement comme du sien.

Le rapport introspectif n’est pas fiable. L’artefact n’est pas fiable.

Reste ce qu’il sait faire, à froid, quand tu le lui demandes.

Le scepticisme n’est pas de la défiance envers l’IA

Le scepticisme, ici, n’est pas de la défiance envers l’IA. C’est de la défiance envers le signal de fluidité. C’est la discipline qui sépare je peux lire ça et j’ai l’impression de comprendre de je peux produire ça à partir de rien demain matin. Les deux revenaient à peu près au même. Ce n’est plus le cas.

C’est le geste qui doit venir en premier, dans la tête de l’ingénieur, avant qu’un manager puisse en faire quoi que ce soit d’utile. Si l’ingénieur ne peut pas se l’appliquer à lui-même, aucun processus de revue ne le sauvera.

À quoi ressemble le scepticisme, appliqué à toi-même

La reproduction à froid. Ferme l’ordinateur. Va au tableau blanc. Reproduis la conception de mémoire, avec les alternatives que tu as écartées. La pause avant de commencer, c’est ta donnée.
L’auto-questionnement contradictoire. Prends l’hypothèse qui te met le moins à l’aise et essaie de la casser sans relancer de prompt. Si ton premier réflexe est d’ouvrir le chat, tu as ta réponse.
Le test du 10x. Qu’est-ce qui changerait si l’hypothèse de charge était multipliée par 10 ? Si ta réponse est je demanderais au modèle, c’est le modèle qui possède la conception, pas toi.

Et puis il y a la version de la question du cache que tu te poses à toi-même, dans ta tête, assis dans ta cuisine tard le soir :

Explique-moi pourquoi j’ai écarté une file de messages ici. Attends. Est-ce que je l’ai vraiment écartée ? Ou est-ce que le modèle ne l’a simplement pas mentionnée ? Attends, est-ce que je suis le modèle ?

Une fois par semaine, note les décisions que tu as prises en trois colonnes : les tiennes, celles du modèle, et celles que tu n’arrives pas à séparer. La troisième colonne est la plus intéressante. Elle ne devrait pas être la plus grande.

La version du manager

Le travail du responsable d’ingénierie n’est plus de suivre la vélocité. C’est de sonder la profondeur.

La revue par la conversation est l’instrument qui manque. La donnée dont l’organisation a vraiment besoin, trois moments par trimestre où cet ingénieur a défendu une décision non triviale face à des questions en direct, n’est dans l’agenda de personne, dans aucun modèle d’évaluation, dans aucun tableau de bord. Elle n’existe que dans la salle, et seulement si quelqu’un dans la salle a pensé à demander.

L’échange à guetter :

« Explique-moi pourquoi tu as choisi cette stratégie d’indexation de base de données précisément. »

Silence.

« D’accord, explique-moi ce qu’est un index. »

Silence plus long.

Si un ingénieur ne sait pas défendre la conception ordinateur fermé, c’est qu’il ne l’a pas écrite.

L’embauche a changé

La troisième surface touchée, c’est l’embauche, et c’est là que les conséquences arrivent le plus vite.

Je pars du principe que chaque candidat utilise l’IA. Le CV est superbe, le test à la maison est propre, et plus rien de tout ça n’est un signal. J’ai arrêté de chercher la syntaxe parfaite ou le talent de débogage : le modèle sait faire les deux, et le candidat sait que je le sais.

Ce que je sonde maintenant, c’est la prise de décision en avance sur le modèle. Le candidat à qui on demande de concevoir quelque chose et qui dit « j’ai besoin de ça, mais je sais que ça va arriver, et si le trafic double, ça casse là, donc je ferais plutôt ça » est celui qui a construit le muscle. Le candidat qui reproduit une conception propre mais ne sait pas me dire ce qui casse à 10x est celui que le modèle a porté à travers le test à la maison.

L’autre chose que je sonde, c’est la partie du système que le modèle ne voit pas. Le cluster à mise à l’échelle horizontale derrière le service. Le cache qui vit dans le dépôt d’une autre équipe. Le consommateur en aval qui avalera sans rien dire un événement mal formé pendant six semaines avant d’alerter quelqu’un. Le modèle est brillant à l’intérieur de la base de code qu’il a sous les yeux. Il est aveugle au système qui l’entoure. Le candidat qui n’a jamais travaillé qu’en binôme avec le modèle aussi.

On ne peut pas faire semblant : ils utiliseront l’IA. L’entretien ne consiste plus à savoir s’ils savent produire une fonction. Il s’agit de savoir s’ils savent tenir le système dans leur tête.

Le problème à trois ans

Si le système ne peut pas le voir, il ne peut pas le noter. S’il ne peut pas le noter, il ne peut pas promouvoir là-dessus. S’il ne peut pas promouvoir là-dessus, il cesse de le sélectionner.

Alors on promouvra sur la vélocité. On construira toute une génération de staff engineers capables de tout livrer et de ne rien défendre. Les burndown charts seront magnifiques. Les burndown charts seront la seule chose qui ne sera pas en feu.

Les ingénieurs seniors capables de défendre une conception sous les questions n’auront pas disparu : on ne les aura jamais embauchés. Leurs successeurs ont la même tête sur le tableau de bord. Ils ne savent juste pas répondre à la question.

Retourne ça contre ce texte

Tu hoches la tête. L’argument te semble juste. La logique s’est mise en place d’un clic.

Mais rappelle-toi le bug : la chaleur n’est pas une preuve que l’argument est juste.

Ce texte est parti d’un désaccord avec AI should elevate your thinking, not replace it de Koshy John, qui défend la version « vertu personnelle » de cet argument. Il a presque raison. Des passages de cet essai ont été brainstormés avec un modèle. Certaines tournures sont venues trop facilement. Il y a ici des phrases que j’aurais du mal, interrogé à froid demain, à reproduire sous la même forme.

Suis-je un génie pour avoir formulé ça, ou est-ce que j’ai juste appuyé sur Régénérer jusqu’à ce que le robot sonne assez cynique ?

Demain matin, ferme ton ordinateur et essaie de reproduire cette thèse de mémoire. Repasse les trois variables qui ont cassé l’axe. Repasse la différence entre l’argument de Koshy John et celui-ci.

Si tu n’y arrives pas, tu ne l’as pas pensé. Tu l’as juste lu.

Le cache, pourtant

Dans trois ans, nos tableaux de bord d’ingénierie seront tout verts. La vélocité sera au plafond. L’organisation aura l’air irréprochable sur le papier.

Le cache, pourtant, sera en feu.

METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, July 2025. ↩
McKinsey, Unleashing developer productivity with generative AI, 2023. Rapporte des gains d’exécution de tâches pour les développeurs moins expérimentés dans une fourchette d’environ 26–39 %, selon le type de tâche. ↩
Voir Rozenblit, L. & Keil, F., The misunderstood limits of folk science: an illusion of explanatory depth, Cognitive Science, 2002. L’effet de fluidité comme indicateur de compréhension se retrouve de façon solide dans des décennies de travaux. ↩
Johnson, M. K., Hashtroudi, S. & Lindsay, D. S., Source monitoring, Psychological Bulletin, 1993. La synthèse fondatrice. Le résultat a été reproduit et étendu ces dernières années aux contextes de co-écriture humain/IA. ↩