Skills d'un agent IA : écrire un contrat d'exécution

Un prompt ne se réutilise pas, un skill si#

Tout le monde a des prompts qui marchent. Presque personne ne peut les réutiliser.

Le prompt vit dans un onglet, dans un document partagé, dans la tête de celui qui l'a écrit. Il fonctionne parce que son auteur connaît le contexte implicite : ce qu'il faut fournir, ce qu'on attend en sortie, ce qui compte comme un bon résultat, ce qu'il ne faut jamais faire. Confiez-le à quelqu'un d'autre, ou à un agent, et tout ce contexte disparaît. Le prompt produit alors quelque chose de plausible et d'inutilisable.

Un skill est ce qui reste quand on écrit ce contexte. Ce n'est pas une formulation plus longue : c'est un contrat d'exécution — ce qu'il faut en entrée, ce qui sort, sous quelles règles métier, avec quels contrôles, et à quelles conditions le travail est accepté. Un agent peut le sélectionner tout seul, l'exécuter, et échouer proprement quand il manque quelque chose.

Cet article décrit la méthode que nous appliquons dans le Lab, section par section. Elle est exigeante, et cette exigence est le sujet : chaque section existe parce que son absence produit une panne identifiable, que je nomme à chaque fois.

Si la notion de capsule n'est pas familière, commencez par ce qu'est une capsule IA : les skills sont l'une de ses couches, déclarée dans son manifeste.

Phase 1 — Le cadrage : à quoi sert ce skill#

Six sections, et c'est la phase où l'on gagne ou perd la partie.

L'identité donne un nom en kebab-case de forme verbe-objet — generer-statuts-societe, pas assistant-juridique. La contrainte n'est pas esthétique : un nom qui décrit une action permet à un agent de choisir le bon skill parmi cent. Un nom qui décrit un rôle ne le permet pas. S'y ajoutent la version sémantique, le domaine métier, le propriétaire, la maturité — brouillon, bêta, stable —, le statut, la langue, la juridiction quand elle s'applique, et le niveau de distribution : privé, partagé, public, ouvert, souverain.

La description répond à une question précise et souvent mal comprise : quand et pourquoi utiliser ce skill. Elle n'est pas une présentation commerciale, c'est le texte que lit l'agent pour décider s'il s'agit du bon outil. Une description qui dit ce que fait le skill sans dire quand l'employer produit des sélections erronées.

La mission énonce le problème métier résolu, la valeur le bénéfice concret, le résultat attendu ce que l'utilisateur obtient à la fin, et les limites ce que le skill ne prétend pas faire. Cette dernière ligne est la plus utile de toute la phase : un skill sans limites déclarées finit employé hors de son domaine, où il produit des résultats convaincants et faux.

Le contexte métier situe l'usage : qui l'emploie, dans quelle situation, avec quelles contraintes. Les objectifs distinguent l'objectif principal, les objectifs secondaires et — encore — les objectifs interdits. Le périmètre liste ce que le skill fait et ce qu'il ne fait jamais.

Enfin, le contrat de capacité formalise l'échange : quelle capacité est offerte, ce qu'elle fournit, ce qu'elle requiert, ce qu'elle garantit. C'est la section qui permet à un orchestrateur de composer plusieurs skills sans les avoir lus.

Phase 2 — Entrées, sorties, règles#

Six sections qui transforment une intention en interface.

Les entrées sont nommées, typées, marquées obligatoires ou non, décrites. Les sorties de même. Les livrables vont plus loin : un nom, un format, une description — parce qu'un livrable est un objet remis à quelqu'un, pas une valeur de retour.

Les règles métier portent les contraintes qui ne se négocient pas. Deux règles reviennent dans presque tous nos skills, et elles méritent d'être citées telles quelles : toute donnée obligatoire absente déclenche une clarification, et aucun résultat livré sans passage des contrôles qualité. La première interdit d'inventer, la seconde interdit de livrer à l'aveugle.

Les préconditions disent ce qui doit être vrai avant de commencer, les postconditions ce qui doit être vrai après. Écrites, elles rendent l'échec diagnosticable : on sait laquelle a cédé.

Phase 3 — Déclenchement et arrêt#

Trois sections que presque personne n'écrit, et dont l'absence produit les pannes les plus difficiles à diagnostiquer.

Les conditions de démarrage disent ce qui active le skill — un événement, pas un prérequis. Les critères de sortie disent quand l'agent considère la tâche terminée et sort de sa boucle. Les conditions d'échec disent quand renoncer, et s'accompagnent de deux champs distincts : les critères d'arrêt — quand interrompre ou refuser — et la politique d'erreur.

Cette dernière est un tableau, pas une phrase : pour chaque type d'erreur, une stratégie nommée. Demander à l'utilisateur, réessayer, réessayer trois fois, se rabattre sur une solution dégradée, abandonner, arrêter, escalader, ignorer. Le fait que ce soit une liste fermée est le point important : on ne peut pas écrire « gérer proprement », on doit choisir un comportement.

Un skill sans critère de sortie explicite paraît fonctionner : il produit, il itère, il consomme. Le problème n'apparaît que dans la facture, ou le jour où l'on cherche pourquoi une tâche de dix minutes en a pris quatre-vingt-dix.

Phase 4 — Raisonnement et exécution#

Le cœur opérationnel, et la partie où se loge réellement l'expertise.

La stratégie de raisonnement décrit la méthode de travail du métier — comprendre, analyser, vérifier, décider, produire, contrôler — et s'accompagne du prompt système propre au skill. Le plan d'exécution énumère des étapes nommées, chacune avec son action, ce qu'elle produit, et sa conduite en cas d'erreur.

Le playbook métier est la section la plus dense, et celle qui distingue un skill d'une consigne générique. Elle ne se remplit pas en prose : pour chaque situation métier, on décrit la conduite à tenir étape par étape, un exemple, et le résultat attendu. C'est ici que passe le savoir-faire — l'ordre dans lequel un comptable vérifie, la façon dont un juriste qualifie un cas limite. Un skill sans playbook fonctionne sur les cas nominaux et improvise sur le reste.

La matrice de décision est une liste de couples « si condition, alors action », et sa consigne d'écriture est explicite : couvrir les exceptions, pas seulement le cas heureux.

La politique de clarification évite deux travers opposés — bloquer et inventer. Elle déclare quand demander, quand ne jamais demander parce qu'un défaut sûr existe, comment poser la question, et surtout un plafond de questions. Ce plafond est le détail qui change tout : sans lui, un agent scrupuleux transforme une tâche de cinq minutes en interrogatoire.

La politique d'escalade dit, pour chaque situation, vers qui remonter et par quel canal. La stratégie de reprise décrit comment repartir après une erreur, et s'accompagne d'une boucle de révision paramétrée : ce qui la déclenche, un nombre maximal d'itérations, et son critère de sortie. Produire, critiquer, corriger — mais avec une borne, parce qu'une boucle d'amélioration sans plafond est un budget sans plafond.

Phase 5 — Outils, données, permissions#

La phase qui borne la puissance, et dont chaque champ est consommé par le runtime.

La politique d'outils nomme chaque outil et surtout quand l'employer, avec des critères de sélection quand plusieurs conviennent. Les dépendances listent les autres skills, services et référentiels, et déclarent la mémoire utilisée : espace de connaissance interrogé, portées, ce qui est lu et ce qui est écrit. Cette dernière distinction est précieuse : un skill qui écrit dans une mémoire partagée engage les suivants.

Les sources de connaissance déclarent les référentiels d'autorité — ce qui rend une réponse traçable jusqu'à son origine.

Les permissions sont cochées une par une, avec une consigne sans ambiguïté : le runtime n'accordera que celles-là. C'est le moindre privilège appliqué par construction, pas par discipline.

Les limites et engagements de service sont des bornes dures : délai maximal, budget en centimes, nombre de reprises, concurrence maximale, limites de débit. Elles ne sont pas indicatives — le runtime les applique.

L'idempotence déclare si rejouer le skill produit le même effet, avec quelle clé, et quels effets de bord externes existent. Question anodine jusqu'au premier réessai automatique après une coupure réseau : un skill non idempotent qui envoie une facture l'envoie deux fois. Déclarer la clé force à concevoir l'unicité au lieu de la découvrir dans un rapprochement bancaire.

La gouvernance des données classe ce qui est manipulé — public, interne, confidentiel, secret —, déclare la présence de données personnelles, nomme les champs concernés et fixe la durée de conservation. C'est la section que réclame un délégué à la protection des données, et elle vit dans l'artefact plutôt que dans un tableur parallèle.

Phase 6 — Collaboration entre agents#

Quatre sections qui n'ont de sens qu'en équipe, et qui deviennent indispensables dès le deuxième agent.

Le contrat d'agent est un condensé opposable : objectif, actions autorisées, actions interdites, conditions de succès, conditions d'échec. Écrire une condition d'échec est l'exercice le plus révélateur du lot — beaucoup d'équipes découvrent qu'elles n'avaient jamais défini ce qui compte comme un travail raté, et un agent qui ne sait pas échouer se déclare toujours satisfait.

La section collaboration déclare à qui le skill peut déléguer, quels appelants sont autorisés — une liste de contrôle d'accès, vide par défaut, qui hérite alors de celle de l'équipe — et le passage de main : à qui, quand, avec quelle charge utile. Un passage de main implicite est la première cause de perte d'information dans une chaîne d'agents : chacun suppose que le précédent a transmis ce dont il a besoin.

Les événements métier déclarent ce que le skill émet et ce qu'il consomme, pour que d'autres réagissent sans être appelés directement. Ils sont explicitement distincts des événements techniques de l'observabilité — la confusion produit soit un flux métier pollué de bruit, soit une supervision qui déclenche des processus par accident.

Les comportements proscrits ferment la liste : ce que l'agent ne doit jamais faire, quoi qu'il arrive.

Phase 7 — Qualité et preuve#

Ce qui sépare une démonstration d'un système de production.

Les contrôles qualité énumèrent les dimensions vérifiées. Les portes de qualité les transforment en validations bloquantes et ordonnées : chacune porte un nom et une condition qui doit être vraie, et elles s'enchaînent de la première à la dernière. Ordonnées, elles évitent de vérifier la mise en forme d'un document dont le fond n'a pas encore été validé.

Les critères d'acceptation doivent être mesurables — c'est la consigne du champ. Ils s'accompagnent d'une auto-évaluation paramétrée : une méthode, une rubrique, et un seuil sur cent que l'agent doit atteindre. L'auto-évaluation fait boucler l'agent sur son propre travail ; elle ne remplace pas les portes, qui, elles, bloquent.

Les exemples de référence sont des paires entrée-sortie considérées comme justes : ils servent de mètre étalon quand on modifie le skill. Les cas de test vont plus loin : chacun porte une entrée, un résultat attendu et une assertion choisie dans une liste fermée — contient, égal, schéma valide, score au-dessus d'un seuil, non vide. Une assertion nommée est exécutable ; « le résultat doit être correct » ne l'est pas.

Les métriques disent ce qu'on mesure côté métier, l'observabilité ce qu'on émet côté technique, et la traçabilité ce qui est conservé pour l'audit.

Phase 8 — Gouvernance et cycle de vie#

Six sections pour finir, souvent traitées comme de la paperasse, et pourtant les seules qui parlent de la suite.

La conformité déclare ce qui s'applique. Les risques nomment ce qui peut mal tourner. Les hypothèses listent ce qu'on a tenu pour acquis — la section la plus honnête d'un contrat, celle qui explique pourquoi il cessera de fonctionner un jour. Le glossaire fixe le vocabulaire métier. La liste de validation énumère ce qu'il faut vérifier avant publication. L'évolution dit comment le skill changera et ce qui casse la compatibilité.

La génération déterministe : ce qui se pré-remplit sans IA#

La liste effraie. La méthode ne consiste pas à la remplir à la main.

Le constructeur pré-remplit ce qui est déductible de ce qu'on sait déjà : le nom, le domaine, le rôle, la mission, le projet, les outils du membre d'équipe concerné. Cette génération est déterministe — même entrée, même sortie, aucun appel à un modèle, aucun hasard. Elle produit un skill conforme d'emblée : nom, description, mission, plan d'exécution et livrables présents, avec des défauts sûrs pour le reste.

Ce choix technique a une conséquence méthodologique importante. Puisque le squelette est produit sans IA, il est reproductible et auditable : deux personnes qui partent du même besoin obtiennent la même base, et la discussion porte sur le fond métier plutôt que sur les variations d'une génération à l'autre.

Le travail humain se concentre alors là où il compte : les limites, les règles métier, le playbook du domaine, les exemples de référence, la définition de l'échec. Autrement dit, sur ce qu'aucun modèle ne peut deviner de votre métier.

Comment un agent choisit le bon skill#

Un registre de cent skills ne sert à rien si l'agent ne trouve pas le bon. Trois mécanismes s'en chargent, et ils expliquent plusieurs contraintes de nommage vues plus haut.

La taxonomie classe automatiquement chaque skill dans l'un des quinze domaines — ventes, marketing, design, données, IA et agents, ingénierie, sécurité, produit, stratégie, finance, ressources humaines, rédaction, recherche, opérations, automatisation — d'après son nom d'abord, sa description ensuite. Le nom pèse davantage : c'est pour cela qu'il doit décrire une action.

La description sert à la sélection fine : c'est le texte que l'agent lit pour trancher entre deux candidats du même domaine. Une description qui commence par « ce skill permet de… » gaspille sa première ligne ; une description qui commence par « quand une demande de devis arrive… » la rend utile.

Le contrat de capacité permet enfin la composition : un orchestrateur sait ce que chaque skill fournit et exige, donc peut les chaîner sans les lire en entier.

Par où commencer, concrètement#

Tout remplir d'un coup décourage. Voici l'ordre que nous recommandons pour un premier skill utile.

Écrivez d'abord les limites. Trois lignes : ce que ce skill ne fera pas. C'est contre-intuitif et c'est le meilleur point de départ, parce que cela force à délimiter avant de promettre.

Puis le livrable. Un objet nommé, avec son format. Si vous ne pouvez pas nommer ce qui est remis, le périmètre est encore trop vague.

Puis les entrées obligatoires. Ce sans quoi il est impossible de commencer. Chaque entrée obligatoire est une occasion de clarification plutôt qu'une invention.

Puis les règles métier. Ce qui ne se négocie pas dans votre domaine. C'est ici que réside la valeur : c'est la partie que personne ne peut écrire à votre place.

Puis les portes de qualité. Deux suffisent pour commencer : complétude et conformité.

Le reste — observabilité, glossaire, hypothèses, évolution — se remplit quand le skill sort de votre équipe. Les poser trop tôt produit une friction que personne ne maintient.

Questions fréquentes#

Quelle est la différence entre un skill et un prompt ?#

Un prompt est une formulation ; un skill est un contrat. Le prompt suppose un contexte implicite — ce qu'il faut fournir, ce qu'on attend, ce qui compte comme bon résultat — que seul son auteur possède. Le skill écrit ce contexte : entrées typées, livrables nommés, règles métier, critères de sortie, portes de qualité, comportements interdits. Conséquence pratique : un prompt se transmet mal et ne se teste pas, un skill se sélectionne automatiquement, s'exécute et échoue proprement.

Faut-il vraiment remplir quarante-cinq sections ?#

Non, pas d'un coup. Le constructeur pré-remplit de façon déterministe tout ce qui est déductible du nom, du domaine, de la mission et des outils, et pose des défauts sûrs ailleurs. Pour un premier skill interne, une dizaine de sections bien écrites suffisent — limites, livrables, entrées obligatoires, règles métier, portes de qualité. Les sections de gouvernance et d'observabilité deviennent nécessaires quand le skill sort de votre équipe ou entre dans un périmètre réglementé.

Pourquoi un nom en verbe-objet plutôt qu'un nom de rôle ?#

Parce que c'est un agent qui choisit. Face à cent skills, il lit d'abord les noms : generer-statuts-societe dit une action et un objet, donc se sélectionne ; assistant-juridique dit un rôle, donc ne se distingue pas de quatre autres. La taxonomie automatique s'appuie elle aussi en priorité sur le nom. C'est une contrainte de lisibilité machine, pas une convention esthétique.

Comment un skill s'articule-t-il avec une capsule ?#

Le skill est une couche de la capsule : le manifeste déclare les compétences exposées, et le périmètre des politiques s'exprime en compétences autorisées. Autrement dit, la capsule décide quels skills sont utilisables et sous quelles bornes ; le skill décide comment le travail est fait. Un même skill peut servir dans plusieurs capsules, et une capsule peut restreindre la liste de ceux qu'elle autorise.

Que se passe-t-il si un skill n'est pas idempotent ?#

Il produit des doublons au premier réessai automatique — deux factures, deux dossiers, deux débits. C'est la panne la plus embarrassante d'un système autonome, parce qu'elle survient précisément quand tout allait bien et qu'une erreur réseau passagère a déclenché une reprise. Déclarer l'idempotence force à concevoir une clé d'unicité au moment de la conception, plutôt qu'à la découvrir dans un rapprochement bancaire.

Les skills sont-ils réutilisables entre organisations ?#

Oui, et c'est l'un des objectifs du format : le niveau de distribution est déclaré — privé, partagé, public, ouvert, souverain. Un skill privé reste dans son organisation ; un skill public peut être installé ailleurs. Ce qui voyage bien, ce sont les skills de méthode, dont le playbook est indépendant de vos données. Ce qui voyage mal, ce sont ceux qui encodent des règles propres à votre entreprise — et c'est très bien ainsi : ce sont eux qui constituent votre avantage.

À retenir#

Un skill est un contrat d'exécution, pas un prompt bien rangé. Huit phases : cadrer, définir les entrées et sorties, dire quand ça part et quand ça s'arrête, décrire le raisonnement, borner les outils, organiser la collaboration, prouver la qualité, gouverner le cycle de vie.

La méthode paraît lourde ; elle est en réalité une liste de pannes évitées, écrite à l'envers. Les limites évitent l'emploi hors domaine, les critères de sortie évitent la boucle infinie, l'idempotence évite le doublon, la définition de l'échec évite le faux succès. Chaque section est un incident que quelqu'un a déjà vécu.

Pour la suite : les personas, qui décident du comportement, et le manifeste, qui déclare les skills autorisés.