Comment faire maîtriser un domaine à un agent IA

Un agent IA ne maîtrise pas un domaine parce qu’il sait simplement retrouver des documents. Pour obtenir un comportement fiable, vous devez faire coopérer quatre couches : la Knowledge Base répond à « que sait-il ? », les Agent Skills définissent « comment agit-il ? », les outils lui permettent d’exécuter une opération et le jeu d’évaluation vérifie si le résultat reste correct. Une approche limitée au RAG ou à un simple fichier d’instructions restera incomplète.

Cette méthode s’adresse aux ingénieurs qui développent un agent spécialisé, aux équipes de plateforme qui veulent formaliser des procédures internes et aux responsables qui préparent un déploiement continu dans un environnement contrôlé. Elle convient aussi aux usages créatifs, comme l’automatisation d’un contrôle de fichiers audio, la préparation d’un flux vidéo ou l’application de règles de conception dans un outil de design.

Commencez par séparer les quatre responsabilités

La première erreur consiste à traiter le savoir métier comme un seul bloc de texte. Un manuel d’exploitation, une procédure de validation, un accès à une API et un test de non-régression n’ont pas la même fonction. Les mélanger rend les mises à jour difficiles et masque les causes d’échec.

Cette séparation doit aussi guider l’organisation de votre dépôt. Les documents sources, les Skills et les résultats d’évaluation doivent posséder leur propre cycle de version. Si une même page contient une règle métier, une procédure et un résultat attendu, une modification mineure peut involontairement changer plusieurs responsabilités à la fois.

La documentation officielle sur les architectures RAG décrit notamment la séparation entre ingestion, indexation, recherche et génération. Pour votre agent, l’enjeu supplémentaire est de ne pas confondre la récupération du contexte avec l’exécution d’un processus.

Attention : la mémoire générale du modèle ne constitue pas une source auditable. Si une réponse doit être justifiée devant un client, une équipe de sécurité ou un responsable qualité, elle doit pouvoir remonter à une source versionnée ou à une trace d’exécution.

Première étape : construire une Knowledge Base traçable

Une Knowledge Base utile n’est pas une collection de fichiers déposés dans un espace de recherche. Chaque élément doit comporter un minimum de métadonnées : origine, propriétaire, version, date d’entrée en vigueur, date de révision, niveau de confidentialité et périmètre d’utilisation.

Pour un domaine logiciel, vous pouvez par exemple distinguer :

• les règles générales qui changent rarement ;
• les procédures opérationnelles validées par l’équipe ;
• les décisions d’architecture propres à un projet ;
• les incidents historiques, à ne pas présenter comme des règles actuelles ;
• les données dynamiques qui doivent être consultées au moment de la tâche.

Le moteur de recherche doit retourner plus qu’un fragment de texte. Les résultats doivent inclure un identifiant de document, un score de pertinence, des attributs filtrables et, si possible, la version de la source. Les interfaces de recherche vectorielle documentent généralement ce type de retour structuré, avec des métadonnées associées à chaque fragment ; vous pouvez consulter à ce sujet la référence officielle sur la recherche dans les magasins vectoriels.

La qualité de la récupération dépend également du découpage. Un paragraphe isolé peut perdre sa condition d’application, tandis qu’un document trop long noie l’instruction importante. Testez donc les cas suivants :

• une question qui exige une version précise ;
• une règle qui dépend du rôle de l’utilisateur ;
• deux documents dont les dates d’effet sont différentes ;
• une information volontairement périmée ;
• une demande dont la source autorisée est inaccessible.

L’agent doit savoir dire qu’il ne dispose pas d’une preuve suffisante. Une réponse moins complète mais explicitement limitée vaut mieux qu’une synthèse qui mélange une ancienne procédure et une règle actuelle.

Pour les contenus audio, vidéo et design, ajoutez aussi les propriétés réellement utiles au travail : format, codec, fréquence d’échantillonnage, profil colorimétrique, dimensions, version du logiciel ou destination de publication. Ces attributs doivent être recherchables séparément du texte descriptif, car ils déterminent souvent la validité du livrable.

Deuxième étape : transformer les SOP en Agent Skills

Les Agent Skills servent à encapsuler une compétence procédurale. Ils doivent contenir les étapes stables, les conditions de décision, les formats attendus, les contrôles et les comportements à adopter en cas d’incertitude. Ils ne doivent pas devenir une copie de toute votre Knowledge Base.

Un Skill correctement conçu peut suivre cette structure :

nom-du-skill/
├── SKILL.md
├── scripts/
├── exemples/
├── schemas/
└── tests/

Le fichier principal doit expliquer quand le Skill est pertinent, quelles entrées il accepte, quelles sorties il produit et dans quels cas il doit refuser l’exécution. La présentation officielle du format Agent Skills décrit un fonctionnement fondé sur un fichier SKILL.md, des métadonnées de découverte et un chargement progressif des instructions. Cette approche évite de placer tout le contenu spécialisé dans le contexte initial.

Écrivez le Skill comme une procédure destinée à un collaborateur compétent mais nouveau dans l’équipe. Évitez les formulations vagues telles que « vérifiez la qualité » ou « préparez le fichier correctement ». Remplacez-les par des critères observables :

1. identifier le type de livrable ;
2. récupérer la règle correspondant à sa version ;
3. appliquer le traitement autorisé ;
4. contrôler les propriétés de sortie ;
5. produire un rapport d’erreur si un contrôle échoue ;
6. demander une validation humaine lorsque le risque dépasse le périmètre défini.

Un Skill de montage vidéo pourra ainsi vérifier le format de sortie, appeler un outil d’analyse des pistes, signaler une fréquence incompatible et produire un rapport lisible. Un Skill de design pourra contrôler une nomenclature de calques, la présence de composants obligatoires et l’export des variantes prévues. Dans les deux cas, les valeurs susceptibles de changer doivent rester dans la Knowledge Base ou dans une source consultée à l’exécution.

La différence entre Knowledge Base et Agent Skills devient alors nette : le Skill contient la logique de traitement, tandis que la base conserve les faits auxquels cette logique se réfère. Si une norme ou une convention change, vous mettez d’abord à jour la source de vérité, puis vous vérifiez si le Skill doit évoluer.

Troisième étape : encadrer le rôle des outils

Un agent qui peut lire une information n’a pas nécessairement besoin de la modifier. Vous devez donc classer les outils selon leur niveau d’impact :

• lecture : consulter un document, une tâche, un fichier ou un état ;
• écriture : créer ou modifier une ressource ;
• exécution : lancer une commande, un rendu, un déploiement ou un traitement ;
• approbation : confirmer une action à risque ou irréversible.

Cette classification doit apparaître dans la description de l’outil, dans son système d’autorisation et dans les journaux. Ne donnez pas à un même outil une capacité de lecture et d’écriture sans raison précise. Préférez des interfaces étroites, avec des paramètres contrôlés, des limites de volume et des réponses structurées.

Le protocole MCP recommande notamment de traiter les outils comme des capacités pouvant exécuter du code arbitraire et d’obtenir un consentement explicite avant leur invocation ; les principes officiels de sécurité du protocole détaillent cette exigence. Pour les transports HTTP, la spécification d’autorisation prévoit l’usage d’OAuth 2.1, de connexions HTTPS et de PKCE côté client.

Une réponse d’outil devrait idéalement préciser :

{
  "status": "success",
  "operation_id": "op-123",
  "changed_resources": [],
  "next_action": "review",
  "error_code": null
}

Le format exact dépend de votre système, mais les champs doivent permettre à l’agent de distinguer un succès, un échec partiel, une absence de résultat, une demande d’approbation et une erreur temporaire. Un simple message texte comme « terminé » ne suffit pas pour décider de la suite.

Ajoutez une confirmation humaine lorsque l’action peut supprimer des données, publier un contenu, modifier une production, déclencher une dépense ou exposer une information confidentielle. La validation ne doit pas être une phrase ajoutée après coup : elle doit être une étape explicite du flux, visible dans les journaux et associée à l’identité de l’approbateur.

Quatrième étape : évaluer les connaissances et les procédures

Vous ne pouvez pas vérifier la maîtrise d’un domaine avec quelques questions faciles. Un jeu d’évaluation doit couvrir au moins quatre dimensions :

• exactitude des réponses documentaires ;
• respect de la procédure ;
• refus des demandes hors périmètre ;
• comportement lorsque l’information ou l’outil échoue.

Ajoutez également des cas de conflit entre sources, de document périmé, de permission insuffisante et d’entrée mal formée. Pour un agent de développement, testez par exemple une dépendance dont la version n’est plus supportée, une commande qui renvoie une erreur et une demande de modification sans droit d’écriture. Pour un agent de design, testez un fichier incomplet, un format non accepté et une exportation dont les propriétés ne correspondent pas à la destination.

Les évaluations doivent comparer des versions. Conservez le jeu de tests, les réponses obtenues, les traces d’outils et le jugement attendu. Une modification de la Knowledge Base peut améliorer la précision documentaire tout en dégradant une procédure ; une modification du Skill peut améliorer l’exécution tout en augmentant les refus injustifiés.

La documentation d’architecture sur l’exploitation des applications génératives rappelle que les systèmes composés de plusieurs étapes nécessitent une évaluation de bout en bout, et pas uniquement des tests isolés sur chaque composant. C’est particulièrement important lorsque l’agent choisit lui-même un outil ou enchaîne plusieurs opérations.

Traitez les mises à jour comme un changement contrôlé

La connaissance métier doit avoir un responsable. Pour chaque domaine, définissez :

• qui valide une nouvelle source ;
• à quelle fréquence les documents sont révisés ;
• comment une version devient active ;
• que faire lorsqu’une source contredit une autre ;
• quels Skills et tests doivent être rejoués ;
• combien de temps conserver les anciennes versions.

Le flux recommandé est le suivant :

1. enregistrer la nouvelle source ;
2. vérifier son origine et son périmètre ;
3. marquer l’ancienne version comme remplacée ;
4. mettre à jour l’index de recherche ;
5. analyser l’impact sur les Skills ;
6. rejouer les évaluations concernées ;
7. publier seulement après validation.

Ne mettez pas une règle dynamique dans un Skill simplement parce qu’elle est fréquente aujourd’hui. Une procédure stable peut rester dans le Skill ; une valeur susceptible de changer doit être récupérée depuis la source appropriée. Cette distinction évite qu’un agent continue d’appliquer une ancienne politique après une mise à jour documentaire.

Expérience de conception : lorsqu’une équipe corrige directement les instructions du Skill pour résoudre une erreur de connaissance, elle masque souvent la cause réelle. Commencez par chercher une source absente, mal indexée, mal datée ou inaccessible au rôle courant.

Vérifiez l’environnement avant l’ouverture

Même un agent fiable sur un jeu de tests peut échouer en environnement continu. Avant l’ouverture, examinez l’isolation du projet, la gestion des secrets, la conservation des journaux, la restauration d’état et les limites de concurrence.

Pour un assistant interne à faible risque, vous pouvez ouvrir progressivement la consultation, puis les écritures limitées, avant d’autoriser des opérations sensibles. Pour un agent qui agit sur des systèmes externes, le seuil doit être plus strict : confirmation humaine, environnement de test, possibilité d’annulation et surveillance des erreurs.

La référence officielle sur une architecture RAG avec agent sépare notamment l’ingestion des données, le service applicatif et le traitement de la requête. Cette séparation est utile pour identifier où appliquer les contrôles de version, de filtrage et de permission.

Utilisez cette checklist d’acceptation

• [ ] Chaque document possède une source, une version, une date et un propriétaire.
• [ ] Les informations périmées sont identifiées et ne sont pas servies comme des règles actuelles.
• [ ] La Knowledge Base conserve les faits, tandis que le Skill conserve la procédure.
• [ ] Chaque Skill définit ses conditions d’activation et ses cas de refus.
• [ ] Les outils sont classés en lecture, écriture, exécution ou approbation.
• [ ] Les retours d’outils indiquent explicitement le succès, l’échec et l’étape suivante.
• [ ] Les actions irréversibles exigent une confirmation humaine.
• [ ] Le jeu d’évaluation contient des cas normaux, ambigus, périmés et hors périmètre.
• [ ] Les évaluations sont rejouées après toute modification importante.
• [ ] Les journaux ne contiennent pas de secret exploitable.
• [ ] L’état d’une opération peut être retrouvé et restauré après interruption.
• [ ] La mise en production commence par un périmètre limité et observable.

Comparez les options d’architecture avant de choisir

Concluez avec une architecture vérifiable

La bonne question n’est pas « combien de documents l’agent peut-il lire ? », mais « quelle preuve possède-t-il, quelle procédure applique-t-il, quelle action peut-il réaliser et comment savez-vous qu’il ne s’est pas trompé ? ». Si vous ne pouvez pas répondre séparément à ces quatre questions, votre domaine n’est pas encore réellement transféré à l’agent.

Une installation locale improvisée peut fonctionner pour un prototype, mais elle expose souvent l’équipe à un environnement non reproductible, à des permissions difficiles à isoler et à une continuité limitée lorsque plusieurs personnes doivent tester le même flux. Une infrastructure cloud généraliste peut offrir davantage de souplesse, mais elle ne garantit pas automatiquement un environnement cohérent pour les outils, les journaux et les workflows propres à votre équipe.

Pour des essais temporaires, des validations de Skills ou des campagnes d’évaluation nécessitant un environnement Mac distant, louer un environnement auprès de ZavCloud peut être plus simple que d’acheter une machine dédiée ou de maintenir une configuration locale uniquement pour un projet ponctuel. Vous pouvez consulter les détails des forfaits Mac disponibles, puis vérifier les conditions adaptées à votre usage dans le centre d’aide de ZavCloud. L’objectif n’est pas de remplacer systématiquement une infrastructure stable, mais de disposer d’un espace contrôlé pour tester, comparer et valider votre Agent IA avant de lui confier des opérations réelles.

Questions fréquentes

Quelle différence entre Knowledge Base et Agent Skills ?

La Knowledge Base conserve les informations vérifiables : procédures, règles, versions, sources et dates de mise à jour. Les Agent Skills décrivent plutôt la manière d’exécuter une tâche : étapes, conditions, format attendu et contrôles. La première répond à « que sait-on ? », tandis que la seconde répond à « comment faut-il procéder ? ».

Où placer une connaissance métier : dans le RAG ou dans un Skill ?

Placez dans le RAG les informations qui changent, doivent être citées ou appartiennent à plusieurs processus. Placez dans un Skill les séquences stables, les décisions récurrentes et les règles de sortie. Un Skill peut consulter la Knowledge Base, mais ne devrait pas en recopier tout le contenu, au risque de devenir rapidement obsolète.

Comment vérifier qu’un agent maîtrise réellement un domaine ?

Ne vous limitez pas à quelques questions réussies. Constituez un jeu d’évaluation comprenant des questions factuelles, des cas ambigus, des procédures complètes, des demandes hors périmètre, des informations périmées et des échecs d’outils. Comparez toujours la même base de tests avant et après chaque modification.

Comment mettre à jour une connaissance périmée ?

Commencez par corriger la Knowledge Base, en conservant la version précédente et la nouvelle source. Vérifiez ensuite si le changement modifie une étape, une condition ou un format décrit dans un Skill. Enfin, rejouez les tests liés à cette connaissance et publiez la nouvelle version seulement après validation des résultats.