Raphaël Simon

Plus j’utilise des outils LLM en CLI comme Claude Code et Opencode, plus je réalise que :

• le principe des skills est l’une des meilleures idées que j’ai vues et utilisées jusqu’ici dans l’exercice de travailler avec des LLMs
• ça fait exactement ce que les packages font avec mes langages préférés : factoriser des trucs complexes et utiles en briques réutilisables qu’on peut appeler en quelques mots
• c’est encore immature et ça devrait clairement évoluer pour se comporter comme des packages

Je bidouille autour de cette approximation skills~=packages et les résultats actuels me plaisent assez pour en parler, ne serait-ce que pour me relire dans quelques mois et constater à quel point cette prise de position vieillit mal. De cette vision découle mon approche actuelle : Agent Kit Manager (akm).

Les LLM Skills, au sens de la spécification ouverte pour un format de prompt réutilisable, c’est MALIN. Tout le monde bidouillait du prompt engineering et réutilisait des bouts qui marchaient dans des prompts de plus en plus longs, à coups de copier-coller et de renvois vers des documents longs comme le bras. Les skills répondent à tout : le progressive disclosure permet de garder du contexte pour l’essentiel avant d’atterrir dans la dumb zone, l’auto-activation fait qu’on ne gaspille ni tours ni tokens à invoquer explicitement le skill, et l’arborescence de dossiers permet d’aller encore plus loin dans le progressive disclosure, avec des fichiers lus uniquement dans certaines situations, des scripts utilisés par le skill… ...

Depuis fin décembre 2025, je passe 10 à 12 heures par jour à écrire du logiciel avec des agents LLM et des outils en ligne de commande.

J’ai pris des notes depuis le premier jour où j’ai essayé Opus 4.5, sur mon téléphone. Ce billet raconte ce que ça fait vraiment : passer du vélo électrique à la voiture de course.

Pendant les 3 premiers trimestres de 2025, les LLM m’étaient aussi utiles qu’ils l’avaient été depuis qu’OpenAI a lâché ChatGPT sur nous tous. J’avais l’impression que personne n’avait trouvé de workflow durable. Beaucoup de copier-coller depuis l’interface web. Des démos impressionnantes et quelques tentatives d’autonomie, mais aussi beaucoup d’histoires d’horreur (adieu la base de prod). Les modèles hallucinaient tout autant qu’avant, trop pour qu’on leur fasse confiance en production. Dans la plupart des cas, le résultat n’était pas assez en avance sur ce qu’un humain compétent pouvait produire.

Deux choses ont changé, presque en même temps.

1. Les modèles se sont nettement améliorés. Pas de manière incrémentale. Avec la sortie de Claude Opus 4.5 d’Anthropic, on a soudain obtenu de meilleurs résultats du premier coup. Une meilleure cohérence sur des plans longs. Moins de moments où le modèle dérive de ce qu’on lui a demandé.

2. Les agents en ligne de commande comme Claude Code (ou Copilot CLI, Mistral Vibe, Opencode…) ont donné aux modèles accès à la machine, de la bonne manière. grep, find, git, CI/CD : bash, c’est tout ce qu’il faut apparemment ! Le modèle peut explorer du code sans gaspiller de tokens. Il peut participer au versionnage de son propre travail et à la documentation. Il peut lancer des tests, lire les erreurs, réessayer. Il peut faire tout ça en parallèle sur plusieurs branches, ou des git-worktrees.

Bienvenue sur mon blog ! C’est ici que je partagerai mes divagations, sur à peu près tout : de la médecine et la santé publique à l’ingénierie logicielle, la science des données, et les problèmes intéressants qui émergent à leurs intersections.

J’essaie de tenir un blog depuis mes 11 ans, ça fait plus de 20 ans maintenant. Qu’est-ce qui a changé ? Aucune idée. J’imagine que j’ai assez vieilli pour comprendre à quel point écrire est important ? Ou alors c’est juste une lubie qui durera deux semaines.

Qui sait ?