LLMs : vous voilà manager, que ça vous plaise ou non

• AI/LLM
• Artisanat/craft

Quelle époque, mes amis ! Avec les LLMs, le temps semble s’accélérer. Pas une semaine sans que ne pop un nouvel outil ou bien un nouveau modèle censé remiser les générations précédentes au placard.

Je ne saurais nier ma surprise à la vue d’un site corporate généré en quelques prompts – ce que d’aucuns appellent l’effet « whaou ». Ce segment de marché est un boulevard pour les modèles statistiques : aucune complexité métier, une refonte éditoriale ou graphique tous les 2 ans, autrement dit du code jetable. Ce qui vous coûtait autrefois 5 000 € vous coûte à présent moins de 500 €. Il serait dommage de ne pas en profiter.

Ainsi, « Coding is solved », a dit Boris Cherny, créateur de Claude Code. D’accord. Moi aussi, j’aime la provocation, donc passons. Il n’en demeure pas moins que, si vous construisez un logiciel fait pour durer, un SI assurantiel, par exemple, vous ne pouvez pas faire aveuglément confiance à votre LLM favori. La qualité de code reste un enjeu majeur, vous ne pouvez pas laisser la dette technique s’installer. Autrement dit, si l’implémentation devient un détail, le diable s’y trouve encore et toujours…

Pour ma part, bien que très impressionné par les nouvelles capacités qui s’offrent à nous, je constate qu’il faut du temps pour maîtriser ces outils, qui, en termes de tenue de route, se rapprochent franchement de la Formule 1. Plus concrètement, mon expérience avec les LLMs me rappelle le yoyo du manager débutant :

• Je délègue, mais je délègue trop et je me fais de belles frayeurs. Avec un LLM, cela signifie souvent que l’application est bien fonctionnelle, mais que l’implémentation n’a absolument rien à voir avec ce que vous aviez imaginé — vive le gros hack bien dégueulasse. Qu’il s’agisse d’humains ou d’IA, le sujet est le même : ce qui était évident pour vous ne l’était pas pour l’autre. Vous avez présumé de compétences qui n’étaient pas là et n’avez pas suffisamment explicité vos attentes.

• Ou bien je ne délègue pas assez, parce que je suis un peu/beaucoup control-freak, et l’on me fait gentiment passer le message qu’il serait bien de lâcher du lest. Là-dessus, un LLM vous donne généralement peu de feedback, c’est juste que vous n’exploitez pas toutes ses possibilités.

Idéalement, un équilibre s’établit avec chaque personne, car l’on n’interagit pas un expert comme avec un junior. Mais surtout, c’est une affaire de temps et d’apprentissage. Vous devez instruire votre LLM comme vous assureriez la formation d’un apprenti, ce que l’on appelle LLM harness. C’est donc pour moi, pour vous, pour nous tous, un apprentissage à réaliser. Il faut apprendre à déléguer, comment, à quel point, dans quelle temporalité.

La clé en la matière est peut-être justement la progressivité : lâcher prise graduellement. Cet apprentissage présente à mes yeux des similarités avec le Test-Driven Development, dont l’essence est de faire de très petites modifications (les fameux baby steps) pour sécuriser les acquis à chaque étape. Ce que l’on veut éviter à tout prix, c’est d’écrire beaucoup de code, de manière optimiste, pour réaliser à la fin que rien ne fonctionne. Le TDD évite une telle accumulation de bugs en allant fréquemment chercher du feedback.

Avec un LLM, c’est pareil. Vous pouvez effectivement lancer toute une orchestration d’agents collaborant les uns avec les autres. Sauf que, si vous ne prenez pas de précautions, vous risquez d’obtenir un résultat désastreux et d’en conclure que ces outils ne fonctionnent pas. Mieux vaut démarrer par des tâches simples, unitaires, qui seront l’occasion pour vous et le LLM de documenter la codebase (fichiers CLAUDE.md) et de l’instruire sur la façon de procéder (SKILL.md). Ensuite seulement, vous pouvez commencer à assembler les pièces du puzzle en parallélisant les tâches avec plusieurs agents concourant, tous ensemble, à l’élaboration d’une fonctionnalité.

Utiliser un LLM nous met donc en position de manager, et diriger une équipe, quelle qu’elle soit, cela s’apprend. Le lâcher-prise fait partie de l’équation et c’est un curseur : à chacun de le mettre là où bon lui semble. Pour ma part, étant très attaché à la qualité de code, et ce d’autant plus que je travaille dans un environnement que je connais sur le bout des doigts, je tiens (encore) à relire chaque ligne ainsi produite. Je passe beaucoup de temps à cadrer Claude Code en amont afin de rendre son action aussi déterministe que possible. Développer reste donc une activité laborieuse, ou, pour le formuler différemment, disons que mon effet « whaou » est plus progressif que pour d’autres. Mais, même avec cet usage très précautionneux, je fais parfois en 2h ce que j’aurais fait en une journée.

Parfois, a contrario, j’ai une idée tellement précise de ce que je souhaite que le spécifier par écrit me prendrait plus de temps que de le faire, avec le risque que ce soit moins bien fait. C’est notamment le cas lorsque je travaille au cœur du domaine, en TDD. Dois-je alors faire par moi-même, ou bien investir un peu de temps pour lui apprendre à faire à ma place ?