22 juillet 2026

Les Agent Skills, sorties du presse-papiers

Les consignes données aux assistants se sont installées là où rien ne se relit : dans des conversations et des fichiers personnels. Les sortir de là ne demande pas un outil de plus, mais de les traiter comme le reste du code.

Le symptôme est reconnaissable. Dans une équipe qui travaille avec un assistant depuis quelques mois, il existe une consigne qui marche bien : celle qui produit une note de conception au bon format, ou qui vérifie un livrable contre une norme métier. Elle est dans le presse-papiers de son auteur. Elle a été collée dans une conversation privée, envoyée à deux collègues, modifiée par l’un d’eux, et il en existe désormais trois versions dont personne ne sait laquelle est la bonne.

C’est exactement l’état où se trouvaient les scripts d’exploitation il y a vingt ans, et le remède est le même : les mettre dans un dépôt, leur donner un format, et faire passer les modifications par une revue. Ce qui manquait jusqu’ici était le format et le moyen de distribuer : deux choses qu’une spécification ouverte et un utilitaire en ligne de commande fournissent maintenant.

01Une consigne est un dossier

Le format est délibérément pauvre : un dossier, un fichier au format Markdown avec quelques métadonnées en tête, et les fichiers auxquels la consigne renvoie. Cette pauvreté est la qualité principale : il n’y a rien à apprendre, et un rédacteur qui n’écrit pas de code peut proposer une modification.

text

design-note-review/
├── SKILL.md            # the instruction itself, and when it applies
├── references/
│   └── internal-standard.md
└── scripts/
    └── check_headings.py

La partie qui décide de tout est la description en tête : c’est elle qui détermine si la consigne est convoquée au bon moment. Une description vague produit une consigne qui ne se déclenche jamais, ou pire, qui se déclenche partout. C’est le seul endroit où la rédaction demande du soin, et c’est celui qu’on bâcle.

02Le dépôt de l’entreprise comme source

L’utilitaire installe une consigne depuis un dépôt plutôt que depuis une machine. C’est tout ce qu’il faut : à partir du moment où l’adresse d’installation est celle du compte de l’entreprise, la consigne cesse d’être personnelle. Elle est relue avant d’être fusionnée, elle a un historique, et la retirer se fait une fois pour tous.

bash

# Install from the company account rather than from a public repository
npx skills install github:company/skills/design-note-review

# Whatever gets installed must be listable and removable
npx skills list
npx skills remove design-note-review

La conséquence organisationnelle est plus intéressante que la technique. Une consigne qui passe en revue devient un objet dont quelqu’un répond, et cela change ce qui s’y écrit : les formulations approximatives qui passaient inaperçues dans une conversation privée se font contester dès qu’un relecteur les lit. C’est la même mécanique qu’une revue de code, et elle produit le même effet sur la qualité moyenne.

03Ce que je laisse de côté

Je n’ai pas de méthode pour évaluer une consigne. On sait dire qu’une modification a amélioré un résultat sur trois essais ; on ne sait pas dire qu’elle ne l’a pas dégradé ailleurs, et la revue humaine ne le voit pas non plus. Tant que ce manque tient, une consigne partagée reste un artefact qu’on relit sans pouvoir le vérifier : ce qui est mieux que le presse-papiers, et moins bien que du code.

Et une réserve sur l’élan. La facilité d’installation pousse à en accumuler, et une bibliothèque de quarante consignes dont six servent est pire que six consignes : elle rend le choix coûteux au moment précis où il devrait être évident. Le retrait doit être aussi routinier que l’ajout, et il ne l’est jamais spontanément.