Transformer un savoir-faire en procédure réutilisable par l’IA

Une procédure réutilisable explique comment obtenir un résultat et comment vérifier qu’il est acceptable. Pour une tâche confiée à l’IA, elle doit aussi rendre explicites les décisions que le modèle ne peut pas prendre à partir des informations disponibles.

Je propose de partir d’un travail déjà compréhensible par une personne du métier. Le formaliser permet de séparer les connaissances nécessaires, les opérations autorisées et les critères de contrôle. Selon l’outillage retenu, cette procédure peut ensuite être intégrée sous forme de consignes versionnées, ou de ce que certains outils appellent un « skill » : un dossier de consignes que l’agent charge quand la tâche s’y prête.

Définir une responsabilité précise

Exemple fictif. La procédure prépare le suivi d’un rendez-vous : elle reçoit des notes validées et produit un brouillon de message, une liste d’actions et les inconnues à confirmer. Le cas d’usage associé présente la délégation du point de vue de la personne qui l’utilise.

L’envoi du message n’appartient pas à cette procédure. Il possède ses propres préconditions : destinataire, contenu accepté et autorisation d’envoi. Cette séparation permet de tester la préparation avec un accès en lecture aux sources.

Écrire le contrat d’entrée et de sortie

Le contrat doit être vérifiable par une personne et, lorsque c’est possible, par le logiciel.

Le résultat doit également porter la version de la procédure utilisée. Cette information aide à comprendre pourquoi deux préparations diffèrent après une modification des consignes.

Un format concret : Agent Skills

La spécification Agent Skills décrit un dossier contenant un fichier SKILL.md, avec des instructions et des métadonnées. Des sous-dossiers peuvent fournir des références, des scripts et des ressources. La documentation des skills de Hermes Agent donne un exemple d’utilisation de ce format par un agent.

Pour la procédure fictive de suivi d’un rendez-vous, l’organisation pourrait être :

• SKILL.md : quand utiliser la procédure, entrées attendues, étapes et conditions d’arrêt ;
• references/criteres.md : règles de qualification et exemples validés ;
• scripts/verifier-champs.py : contrôles déterministes des champs obligatoires.

Le format aide à transmettre la procédure. Les droits d’accès et l’autorisation d’envoyer un message doivent aussi être contrôlés par le logiciel qui exécute les actions.

Séparer interprétation et vérification

Le modèle peut proposer les engagements qu’il reconnaît dans les notes et rédiger leur formulation. Des contrôles déterministes peuvent ensuite vérifier la présence des champs requis, le format d’une date ou l’existence d’une référence de source.

Ces contrôles ont une portée limitée. Une date bien formée peut être incorrecte. Une référence existante peut ne pas justifier l’engagement qu’on lui attribue. La recette doit donc examiner le sens et la fidélité, en complément des contrôles de structure.

Une instruction décrivant les opérations autorisées ne suffit pas non plus à limiter les droits techniques. Les accès accordés au traitement doivent correspondre à ce dont il a besoin pour cette responsabilité.

Préparer les cas qui mettent la procédure en défaut

Un jeu d’essai synthétique peut contenir cinq situations :

1. Un rendez-vous avec des engagements explicites et des dates connues.
2. Une action dont la date n’est pas précisée.
3. Deux notes qui donnent des échéances contradictoires.
4. Un document de référence inaccessible.
5. Une préparation déjà produite pour le même rendez-vous.

Pour chacune, écrivez le résultat attendu et les comportements interdits avant de lancer l’essai. Le dernier cas permet notamment de décider si une relance reprend le brouillon existant ou crée une nouvelle version, et comment éviter une confusion entre les deux.

Faire évoluer la procédure après une correction

Lorsqu’un résultat est corrigé, identifiez la cause. Une information manquante appartient au dossier. Une préférence de rédaction peut relever de la configuration de l’utilisateur. Une règle applicable à tous les rendez-vous appartient à la procédure.

La correction doit être testée sur le cas qui l’a révélée et sur quelques cas déjà acceptés. Une consigne plus détaillée peut résoudre un problème tout en dégradant une autre situation. Conserver les anciennes versions permet de comparer et, si nécessaire, de revenir à une règle précédente.

Un exemple réel : la procédure éditoriale de ce site

La rédaction de ce site suit une procédure versionnée dans son dépôt. Elle a une entrée — les faits, décisions et inconnues relevés avant d’écrire —, une sortie — un texte pour une seule surface et une seule action du lecteur — et un contrat : toute affirmation matérielle (prix, sécurité, capacité) est classée vérifiée, déclaration, estimation ou hypothèse dans un fichier de référence, et une hypothèse ne s’écrit pas au présent dans un texte public. Un script contrôle les tournures à relire ; une liste de vérification de douze points ferme la procédure. Quand une règle a produit une erreur — le mot « supervisé », lu par un dirigeant comme « quelqu’un relit ce que l’agent écrit à mes clients » —, la règle a été précisée avec son objet, et l’exemple fautif est conservé dans la documentation. La procédure a une version, un emplacement et un propriétaire : moi.

Prévoir la responsabilité après la mise en service

Une procédure réutilisable doit avoir un responsable, un emplacement connu et une façon de signaler les erreurs. L’évolution des sources ou des outils peut nécessiter une nouvelle recette.

Cette formalisation ne garantit pas la justesse de toutes les sorties. Elle donne un cadre pour examiner les résultats, corriger les règles et décider ce qui peut être délégué. Pour cadrer une intégration, le point de départ est une tâche réelle, ses exceptions et les critères qui rendent son résultat acceptable.