Votre premier flux de travail d'agent commence par un seul prompt et quelques outils. Il répond à des questions. Il vérifie le statut d'une commande. Ça fonctionne, alors vous le livrez.

Puis le produit grandit. Les ventes demandent un outil de mise à jour du CRM qui synchronise les notes de réunion. Le support a besoin d'un flux de remboursement qui touche trois systèmes internes. L'ingénierie ajoute des actions de navigation pour remplir des formulaires de fournisseurs. Chaque demande semble mineure. Chacune obtient son propre fichier de prompt, son propre fil Slack, son propre « correctif rapide ». Six mois plus tard, votre agent n'est plus un système unique. C'est un amas éparpillé de prompts copiés, de règles métier cachées et de décisions prises dans de vieux fils de discussion que personne ne retrouve. C'est ce qu'on appelle le « prompt sprawl » (l'éparpillement des prompts). Cela rend votre produit d'IA difficile à tester, difficile à réviser et impossible à annuler avec confiance.

La solution est un registre de compétences (skill registry) pour agents d'IA.

Ce qu'est réellement une compétence (skill)

Une compétence n'est pas un simple prompt enregistré dans un dossier. C'est un package versionné et testable qui définit ce que l'agent fait, quels outils il peut appeler et ce qu'il ne doit jamais faire. Considérez cela comme un contrat entre votre équipe et la machine. Lorsqu'un agent charge une compétence, il doit savoir exactement où se trouvent ses limites et à quoi ressemble le succès.

Sans cette structure, chaque prompt devient un minuscule système de production non déclaré. Il transporte des permissions cachées, des règles métier intégrées et des impacts sur les coûts que personne n'a suivis. Il s'éloigne du produit réel parce que la feuille de route du produit a évolué alors que le prompt est resté en arrière. Le pire, c'est qu'il finit par être copié. Quelqu'un le bifurque (fork) pour une démo, ou le colle dans un nouveau microservice, et vous vous retrouvez avec deux sources de vérité divergeant dans l'obscurité.

Pourquoi les prompts seuls ne suffisent pas

Les prompts ressemblent à du texte, donc les équipes les traitent comme de la configuration. En réalité, ils sont bien plus proches du code que quiconque ne veut l'admettre. Un prompt de production encode généralement une logique de séquençage, de formatage, de gestion des erreurs et de contrôle d'accès. Lorsque cette logique ne réside que dans le langage naturel, l'ambiguïté s'installe. L'agent a-t-il la permission de mettre à jour le CRM, ou le prompt l'a-t-il simplement suggéré ? Si l'API de facturation tombe en panne, le prompt sait-il comment échouer en toute sécurité, ou hallucine-t-il un message de succès ?

Le coût est un autre tueur silencieux. Un prompt qui demande à l'agent de « réfléchir étape par étape et de chercher de manière approfondie » peut consommer énormément de tokens à chaque exécution. Lorsqu'un tel prompt est copié dans un flux de support à fort trafic, votre facture mensuelle d'inférence double et personne ne sait pourquoi.

La dérive (drift) se produit lorsque l'entreprise change mais que le texte ne change pas. Votre politique de remboursement exige désormais l'approbation d'un responsable au-delà d'un certain seuil. Si cette règle réside à l'intérieur d'un prompt plutôt que dans une couche de politique, vous devez fouiller chaque déploiement pour trouver les copies qui doivent être mises à jour. Si vous en oubliez une, vos agents distribueront de l'argent qu'ils ne devraient pas.

Anatomie d'une compétence de production

Si vous voulez échapper à ce désordre, traitez chaque compétence comme un artefact logiciel. Une compétence de production utile inclut plus que du simple texte. Elle nécessite :

  • Nom et objectif. Pas « prompt_v3_final », mais « process_standard_refund » avec une description claire de l'objectif métier.
  • Schéma d'entrée et contexte requis. Définissez les champs exacts que la compétence attend. A-t-elle besoin d'un ID utilisateur, d'un historique de conversation, d'un identifiant de tenant ? Un typage fort ici empêche l'agent de faire des suppositions.
  • Permissions d'outils et limites de sécurité. Énumérez explicitement les outils que la compétence peut invoquer. Définissez des garde-fous sur les tentatives de réessai, les limites de dépenses et les plafonds de débit. Si la compétence ne doit pas toucher à l'API de suppression d'utilisateur, dites-le dans le code, pas seulement en prose.
  • Critères de succès et cas de test. Une compétence ne « fonctionne » pas simplement parce qu'elle s'exécute. Définissez ce que la sortie doit contenir. Pour une compétence de remboursement, le succès pourrait signifier un enregistrement de transaction validé, une confirmation par e-mail envoyée et une entrée dans le journal d'audit créée.
  • Historique des versions et statut du propriétaire. Quelqu'un doit en être responsable. Un journal des modifications (changelog) devrait expliquer pourquoi la v2.3 existe et ce qui a échoué dans la v2.2.

Séparez vos couches

La plus grande erreur des équipes est de tout entasser dans un seul prompt. Elles mélangent des conseils conviviaux, la documentation des outils, la politique de sécurité et la gestion des erreurs dans un mur de texte. C'est impossible à maintenir.

Divisez-le :

  • Les instructions sont des guides pour l'agent. Elles expliquent le ton, le format et l'approche générale.
  • Les règles d'outils (Tool Rules) indiquent à l'agent quels outils existent et ce qu'ils font. Il s'agit d'une phase de découverte, pas d'une autorisation.
  • La politique (Policy) est appliquée par le code, pas par l'espoir. Si un remboursement de plus de 500 $ nécessite un second regard, ce contrôle réside dans une fonction de validation qui s'exécute avant même que l'outil ne soit appelé.
  • Les évaluations (Evals) sont des tests qui prouvent que le skill fonctionne toujours après chaque modification.

Par exemple, n'écrivez pas : « S'il vous plaît, ne révélez jamais le numéro de carte de crédit complet du client. » Au lieu de cela, créez un formateur de données qui masque les PAN avant que l'agent ne les voie. La politique doit résider dans le code, car un utilisateur malin ne peut pas convaincre le code de ne pas faire son travail via une saisie astucieuse.

Arrêtez de pointer la production vers « latest »

Rien ne gâche plus un vendredi soir qu'une mise à jour silencieuse d'un prompt. Si votre agent de production tire toujours la version « latest » d'un skill, alors chaque fusion vers main est un incident potentiel en direct. Vous avez besoin d'alias tels que dev, staging et prod. Promouvez une version connue et testée à travers ces étapes. Lorsque prod pointe vers la v2.1.4, vous pouvez la surveiller, mesurer son comportement et dormir sur vos deux oreilles. Si quelque chose ne va pas, vous revenez à l'alias précédent. On ne débugue pas du langage naturel à minuit sous la pression.

Cette discipline force également votre équipe à réfléchir à la rétrocompatibilité. La v2.2 peut-elle gérer le même format d'entrée que la v2.1 ? Si ce n'est pas le cas, la promotion échoue en staging, et vous l'interceptez avant qu'un client ne le fasse.

La sécurité commence à l'intérieur du package

Un registre rempli de prompts non audités est une vulnérabilité latente. Vous devez scanner vos skills pour les mêmes risques que vous scanneriez dans du code.

Recherchez des secrets codés en dur ou des clés API enfouis dans les modèles de prompts. Vérifiez la présence de webhooks externes ou de commandes shell qui exfiltrent des données. Surveillez les tentatives de contournement de la politique système, comme des prompts contenant « ignore previous instructions » ou demandant à l'agent de révéler sa propre configuration. Ce ne sont pas seulement des théories. Ce sont des schémas courants dans les attaques par injection de prompt, et ils sont dangereux car ils accompagnent souvent du texte copié que personne n'a examiné.

Passez vos packages de skills par une analyse statique. Si un fichier de skill contient une URL qui ne figure pas sur une liste d'autorisation (allowlist), échouez la construction (build). S'il fait référence à un outil qui ne figure pas dans le manifeste approuvé, rejetez-le.

Si vous ne pouvez pas le tester, vous ne pouvez pas lui faire confiance

Un registre sans évaluations n'est qu'un dossier de prompts. Chaque skill a besoin d'un ensemble de tests qui éprouve le chemin nominal (happy path), les cas limites (edge cases) et les modes de défaillance. Pour les skills à haut risque, vous avez besoin de plus que des tests fonctionnels. Vous devez sonder les limites de permission pour vous assurer que l'agent ne peut pas voir les données d'un autre utilisateur. Vous devez vérifier le comportement de refus pour confirmer qu'il dit non lorsque la politique bloque une action. Vous devez effectuer des tests de résistance à l'injection de prompt pour vérifier que les entrées adverses ne contournent pas vos protections au niveau du code.

Nommez vos tests explicitement. Un test nommé « refund_skill_rejects_negative_amount » indique précisément au prochain ingénieur quel comportement est protégé. Lorsqu'un test échoue lors d'une promotion de version, vous avez la preuve concrète que la version candidate est dangereuse.

Le véritable objectif est le contrôle

La réutilisation est une bonne chose, mais le contrôle est ce qui vous permet de garder votre emploi. Un registre de skills permet à votre équipe d'affirmer avec certitude : voici le workflow approuvé. Voici la version qui tourne en production. Voici les outils qu'il peut utiliser. Voici exactement comment nous effectuons un rollback.

Cette clarté vous fait passer de la livraison de démos impressionnantes à l'exploitation de logiciels fiables. Les démos impressionnent les parties prenantes pendant dix minutes. Les logiciels fiables fonctionnent à trois heures du matin, gèrent les exceptions avec élégance et ne changent pas de comportement simplement parce que quelqu'un a fusionné une pull request un mardi après-midi.

Construisez votre registre. Versionnez vos skills. Appliquez vos politiques dans le code. Testez comme si votre sommeil en dépendait. Votre futur vous remerciera.