Skills ou sous-agents : ce qui marche vraiment

Les skills, dans la plupart des cas, et le résultat surprend assez de monde pour mériter d’être posé d’emblée : un agent unique doté de skills approfondis atteint la performance d’architectures multi-agents sur un large éventail de tâches, pour un coût et une complexité de maintenance sans commune mesure.

Le réflexe du découpage vient d’une intuition raisonnable, celle de la division du travail. Si un humain spécialisé fait mieux qu’un généraliste, un agent spécialisé devrait faire mieux qu’un agent unique. Cette intuition se transporte mal, pour une raison que la pratique révèle vite : la spécialisation humaine repose sur des années d’expérience accumulée, alors que la spécialisation d’un sous-agent repose sur une consigne système que vous venez d’écrire.

Ce que chaque approche apporte réellement

La distinction utile ne porte pas sur la performance mais sur la nature de ce qu’on ajoute.

Un skill apporte du savoir-faire. C’est une procédure écrite, portable, que l’agent charge au moment où elle devient pertinente et qu’il applique. Elle est réutilisable par n’importe quel agent, elle se versionne comme du code, et elle n’existe dans le contexte que lorsqu’elle sert.

Un sous-agent apporte un espace. Il possède son propre contexte, sa propre consigne et ses propres droits d’accès aux outils. Ce qu’il ajoute n’est pas de la compétence mais de l’isolement : ce qu’il lit et produit ne vient pas encombrer la conversation principale, et il peut avoir des permissions que l’agent principal n’a pas.

Formulée ainsi, la règle de choix devient assez simple. Si le problème est que l’agent ne sait pas bien faire quelque chose, écrivez un skill. Si le problème est que la tâche produit trop de matière, ou qu’elle exige des droits que vous ne voulez pas accorder partout, prenez un sous-agent.

Le résultat qui doit changer votre pratique

Voici le point le plus important des travaux récents, et il est contre-intuitif pour qui espérait industrialiser la chose.

Les skills générés automatiquement n’apportent aucun gain mesurable en moyenne. Ceux qui sont rédigés et relus par des humains, en revanche, dépassent régulièrement la référence sans skill. Et surtout, un skill de mauvaise qualité ne se contente pas d’être inutile : il dégrade activement la performance, parce qu’il oriente l’agent vers une procédure inadaptée avec l’autorité d’une instruction explicite.

La conséquence est désagréable pour tout le monde. Demander à un modèle d’écrire les skills de votre agent est exactement la chose qui ne marche pas, et c’est malheureusement la première idée de chacun. Le travail reste humain, il est lent, et il consiste surtout à écrire ce que vos meilleurs praticiens font sans y penser.

C’est d’ailleurs une observation qui dépasse la technique. Le savoir tacite d’un business manager expérimenté, ce qui lui fait dire qu’un client refusera ce profil ou qu’une disponibilité est optimiste, est précisément la matière d’un bon skill. Le formaliser est un investissement dont le bénéfice dépasse l’agent, puisqu’il devient transmissible aux humains aussi.

Ce que consomme réellement chaque architecture

Un point rarement chiffré dans les discussions d’architecture, et qui pèse pourtant sur la facture autant que sur la latence.

Un sous-agent démarre avec un contexte vide qu’il faut remplir. Lui confier une tâche suppose donc de lui transmettre l’état pertinent : la demande d’origine, ce qui a déjà été trouvé, les contraintes du client. Cette transmission se paie en jetons à chaque appel, et elle se paie une deuxième fois quand le résultat revient et doit être réintégré. Sur une chaîne de trois sous-agents, le même contexte est facturé quatre ou cinq fois.

Un skill fonctionne à l’inverse. Il ne coûte rien tant qu’il n’est pas chargé, et il n’apporte que la procédure sans emmener le contexte avec lui. C’est ce qui explique qu’une architecture à agent unique bien outillée soit souvent moins chère à l’exécution qu’un découpage élégant sur le papier.

La latence suit la même logique. Trois sous-agents en série, c’est trois attentes qui s’additionnent, et l’utilisateur les ressent toutes. Le parallélisme n’aide que si les tâches sont réellement indépendantes, ce qui est plus rare qu’on ne le croit dès qu’un résultat dépend du précédent.

Cela dit, il existe un cas où le découpage gagne nettement, et il faut le reconnaître : quand une tâche produit un volume de matière intermédiaire qui saturerait le contexte principal. Explorer deux cents fiches pour en retenir cinq est exactement cela. Le sous-agent lit tout, ne renvoie que la synthèse, et l’agent principal n’a jamais vu les cent quatre-vingt-quinze autres. C’est un usage de filtre plutôt que de spécialiste, et c’est probablement le plus solide des deux.

Comment reconnaître un skill qui sert

Trois critères se vérifient en une demi-heure et évitent d’accumuler des fichiers inutiles.

Il doit être testable. Vous devez pouvoir exhiber une tâche que l’agent réussit avec le skill et rate sans lui. Si vous n’y arrivez pas, le skill répète probablement ce que le modèle sait déjà et il consomme du contexte pour rien.

Il doit être spécifique à votre maison. « Comment rédiger un bon email » n’est pas un skill, c’est une compétence générale du modèle. « Comment nous rédigeons une proposition de profil pour ce client, avec les trois éléments qu’il regarde en premier » en est un.

Il doit être révisable. Un skill écrit une fois et jamais relu se dégrade comme une procédure d’entreprise : le monde bouge et le fichier reste. Une revue par trimestre suffit largement, à condition que quelqu’un en soit nommé responsable.

Ce que nous en avons tiré pour Balt

Nous avons commencé par l’architecture multi-agents, comme à peu près tout le monde en 2025, avec l’idée séduisante d’un agent de sourcing, d’un agent de compte rendu et d’un agent de relance qui se passeraient le travail.

Deux problèmes sont apparus vite. Le premier est le coût de la coordination : faire transiter le contexte entre trois agents consomme plus que de le garder au même endroit, et chaque passage est une occasion de perdre un détail. Le second est le diagnostic : quand le résultat final est mauvais, savoir lequel des trois s’est trompé demande un travail d’enquête disproportionné.

Nous sommes revenus à un agent principal doté de skills écrits à la main, en gardant les sous-agents pour deux situations précises. Celles où la tâche produit beaucoup de matière intermédiaire qu’il serait absurde de conserver dans la conversation principale, et celles où les droits diffèrent, typiquement une lecture sur une source que l’agent principal n’a pas à atteindre. Ce second cas est aussi une décision de sécurité plutôt que de performance, puisqu’il limite ce qu’une injection réussie peut faire.

La leçon générale nous paraît valoir au-delà de notre cas. La complexité architecturale se paie tous les jours en maintenance et en difficulté de diagnostic, tandis que la qualité d’un skill se paie une fois à l’écriture. À performance égale, le choix n’est pas difficile, et il ressemble beaucoup à celui qui oppose déjà un workflow bien fait à un agent : la solution la plus simple qui répond au besoin est presque toujours la bonne.