Un agent chargé de préparer une réponse à un appel d’offres doit connaître votre méthode et respecter les limites de son rôle. « Fais une bonne réponse » ne précise ni les pièces à examiner, ni les engagements autorisés, ni la personne qui doit valider le dossier.
Les skills et les hooks répondent à deux besoins distincts : transmettre une manière de travailler et déclencher des contrôles. Les comprendre évite de confondre une instruction écrite avec une règle effectivement appliquée.
Le skill : une procédure réutilisable
Le format Agent Skills organise des instructions et des ressources autour d’un fichier SKILL.md. Une compétence peut inclure des exemples et des scripts. Elle ne garantit pas à elle seule que le résultat sera correct.
Prenons un scénario fictif de réponse à consultation. Nous proposerions une méthode qui précise : les documents d’entrée, la grille d’analyse, les références internes utilisables, le format de la synthèse et les situations imposant une revue. L’agent devrait distinguer une exigence de l’acheteur, une capacité démontrée et un point restant à confirmer.
Le livrable pourrait être un tableau avec exigence, preuve, écart et responsable. Les prix, engagements de délai et exclusions contractuelles seraient explicitement soumis à validation. La méthode appartiendrait à un responsable métier, avec une version et un historique des changements.
Le hook : un déclencheur à une étape définie
Dans Claude Code, un hook peut exécuter un contrôle lors d’un événement, notamment avant certains appels d’outils. Ses possibilités dépendent de l’événement et du type de hook. Un contrôle programmé peut être déterministe ; un contrôle confié à un modèle comporte une part de jugement.
Pour notre scénario, nous recommanderions un contrôle avant publication : dossier approuvé, destinataire autorisé, pièces présentes et format conforme. Vérifier après l’envoi peut servir à tracer une erreur, mais ne permet pas d’empêcher l’envoi déjà effectué.
Définir les trois responsabilités
- Méthode : ce que l’agent doit produire et la façon d’y parvenir.
- Déclencheur : le moment où un contrôle doit s’exécuter.
- Contrôle : la condition à vérifier, le résultat attendu et la réaction en cas d’échec.
La présence d’un champ « approuvé » ne suffit pas : le système doit pouvoir vérifier qui l’a approuvé et pour quelle version. Les permissions de l’outil métier doivent également limiter les actions possibles. Une phrase dans un prompt ne remplace pas cette restriction.
Tester les échecs, pas seulement la démonstration
Nous suggérons de tester un dossier incomplet, une preuve périmée, une modification après validation et un destinataire incorrect. Il faut aussi prévoir l’indisponibilité du contrôle : suspendre l’action sensible, signaler le problème et définir la reprise. Les tentatives doivent rester compréhensibles pour l’équipe qui exploite le dispositif.
Un contenu trouvé dans un document ne doit pas pouvoir redéfinir les règles d’exécution. La connaissance consultée apporte des informations ; les instructions et autorisations de l’agent relèvent de sa configuration et du processus retenu.
Ce que Mintera propose de construire
L’accompagnement peut livrer une procédure formalisée, une matrice des contrôles, un circuit de validation et un ensemble de tests. Les mesures portent sur la qualité du dossier avant revue, le temps total jusqu’à approbation, les blocages justifiés et les corrections nécessaires.
L’objectif est une méthode transmissible et une exécution contrôlable, que vos équipes peuvent maintenir lorsque leurs règles changent.