Un marteau nommé Claude Code : choisissez bien vos clous

• AI/LLM

Loi de l’instrument : chacun son tropisme

On doit à A. Maslow (celui-là même) la formulation de ce biais cognitif :

Si le seul outil dont vous disposez est un marteau, il est tentant de tout traiter comme s’il s’agissait d’un clou.

C’est la Loi de l’instrument, et elle fait des ravages dans notre métier :

• Je suis un développeur front-end, donc toute la logique de mes applications est mise en œuvre côté front, sur le navigateur. C’est comme ça qu’on m’a montré dans le bootcamp. Le back-end ? Vous voulez dire le code qui permet de parler à la base de données ? (D’ailleurs, je suis venu au développement par le Front, ce qui me vaut d’éternelles railleries de la part d’amis proches. C’est mon péché originel, ma croix en tant que développeur).

• Moi, mon truc, c’est le domaine, la modélisation, le DDD. Par contre, le SQL, pas trop trop. Alors pour mes relations 1–1, j’interroge la base de données une première fois, ça me donne la clé étrangère, et puis je lance une seconde requête. Pour les relations 1–N, je vous laisse deviner comment je fais. Les jointures ? À la main, mon cousin, dans le domaine (c’est du vécu, bien évidemment, je n’aurais pas inventé ça tout seul).

• Moi, au contraire, je pense SQL, je vis SQL, je suis SQL. SQL is everything. Mon chien s’appelle Sequel. Le domaine ? Pas de problème, je m’en charge : des procédures stockées et des triggers. C’est pratique : tout se passe dans la base de données. Couplage ? Qué couplage ?

Et, bien sûr, aujourd’hui : « pourquoi tu fais ça à la main, fais-le avec l’IA ! » La Loi de l’instrument connaît un regain sans précédent du fait des LLM. Claude Code et Codex sont nos nouveaux marteaux.

TDD x LLM

À ce stade, coupons court à toute incompréhension : dire cela, ce n’est absolument pas refuser les LLM, mais plutôt proposer de les utiliser à bon escient. Le marteau n’est pas le problème. Refuser le LLM par principe serait d’ailleurs un tropisme de plus — un autre marteau.

Prenons pour exemple le cœur du réacteur, le domaine. Il concentre les règles de gestion propres au métier, ce qui en fait souvent un lieu critique, qui ne tolère pas l’erreur. Quand vous implémentez un algorithme d’exécution d’ordres sur les marchés, l’erreur se chiffre en centaines de milliers d’euros.

On développe souvent le domaine en TDD (Test-Driven Development). L’idée qu’un LLM fasse du TDD est séduisante, dans la mesure où chaque étape demande d’écrire du code avec des contraintes bien distinctes des autres étapes. Il y a matière à spécialiser plusieurs agents :

• Agent « Red » : écrire un unique test, sans souci de l’implémentation (mis à part la signature de la fonction), et vérifier qu’il échoue ;
• Agent « Green » : faire passer le test au plus vite, en prenant volontairement certains raccourcis ;
• Agent « Refactor » : améliorer le code sans rien ajouter à la fonctionnalité.

Vous créerez aussi probablement un skill pour donner le focus en alternance à chaque agent et assurer le bon développement du domaine en articulant bien triangulation et généralisation.

Tout cela, vous pouvez le faire. Ce n’est peut-être pas pour autant qu’il faut le faire.

Le coût de l’erreur

• Une fois le test écrit, l’implémentation est facile, car les tests offrent un feedback binaire (ils passent ou ne passent pas) — ça, tout LLM peut le faire. Le plus difficile et le plus critique, c’est bien d’écrire le prochain test, car les tests spécifient le comportement attendu. Garbage in, garbage out. Le danger est qu’un LLM vous donne rapidement l’impression que tout va bien — tous les tests passent — alors que le comportement implémenté n’est pas le bon !

• Nous savons aussi que, la fatigue et la confiance aidant, nous avons tendance à relire en diagonale. C’est une mauvaise idée en général, mais a fortiori quand il s’agit du domaine. Plus le sujet est critique, plus il mérite notre attention.

• Enfin, sujet plus large, développer nous-mêmes certaines portions de la codebase, sans recourir aux LLM, est nécessaire pour entretenir nos compétences. La pratique reste indispensable pour comprendre certaines finesses du métier, qui vous permettront ensuite de mieux contredire le LLM (en clair : d’être de meilleurs reviewers).

Le boilerplate, le glue code, le script jetable, le test de bout en bout qu’on jettera demain… Ces typologies de développement sont de parfaits cas d’usage pour des LLM. Mais déléguer le cœur de métier à une IA revient à externaliser la connaissance la plus stratégique de l’entreprise et perdre la capacité interne de contredire la machine. Par conséquent, si vous tenez absolument à utiliser un LLM pour développer le domaine, déléguez le Green et le Refactor, mais, s’il vous plaît, pas le Red !

Plus généralement, le remède universel contre la loi de l’instrument, c’est la formation. Évitez les angles morts, comme pour les concours : il n’est pas nécessaire d’être excellent sur quoi que ce soit, en revanche ne faites aucune impasse. Maîtrisez votre architecture et vos outils de A à Z.