Créer des skills d’agent IA pour les flux de travail métier propres à un domaine

L’agent IA généraliste de programmation prend en charge avec compétence un éventail étonnamment large de tâches. Il lit la documentation, écrit du code, débogue les erreurs et résout des problèmes inconnus dès lors qu’il dispose de suffisamment de contexte. Mais la plupart des équipes qui déploient ces agents dans des environnements opérationnels réels rencontrent la même difficulté : fournir ce contexte constitue en soi une tâche, dont l’ampleur augmente avec la complexité du domaine.

Un analyste de données qui demande à l’agent d’extraire les délais de livraison des fournisseurs à partir d’un dossier de bons de commande aux formats variés ne souhaite pas expliquer à chaque fois ce qu’est un bon de commande, comment fonctionnent les conventions de nommage de son entreprise et quel format de sortie les systèmes en aval attendent. Un développeur chargé de la supervision de l’infrastructure ne souhaite pas recopier les mêmes seuils d’alerte et définitions des niveaux de gravité dans chaque conversation. C’est cette répétition qui pose problème.

Les skills — des configurations réutilisables qui regroupent les connaissances du domaine et les consignes de comportement dans une seule unité que l’on peut invoquer — répondent directement à ce problème. Cet article décrit leur conception, leur déploiement dans des flux de travail récurrents et les situations dans lesquelles elles apportent une valeur fiable.

Ce qu’est réellement une skill

Une skill n’est ni une fonctionnalité du modèle ni une capacité de l’API. C’est un fichier, plus précisément un fichier Markdown placé dans un répertoire que l’agent parcourt au démarrage de la session (dans Claude Code, par exemple, un fichier SKILL.md dans un dossier sous ~/.claude/skills/ ou sous .claude/skills/ dans le projet ; les autres environnements d’exécution d’agents utilisent leurs propres emplacements). Lorsqu’une demande correspond à la description de la skill, l’agent charge ses instructions et les suit, plutôt que de réfléchir depuis le début à la manière d’aborder la tâche.

Le fichier contient quatre éléments : un bloc de description qui indique à l’agent quand activer la skill ; un ensemble d’instructions qui précise comment traiter cette catégorie de tâches ; des déclarations facultatives d’accès aux outils qui, selon l’environnement d’exécution, préautorisent ou limitent les outils que l’agent peut utiliser pendant l’exécution (dans Claude Code, allowed-tools préautorise des outils sans restreindre les autres) ; et des exemples facultatifs illustrant le comportement attendu sur des entrées réalistes.

Le fichier ne contient pas de données métier codées en dur. Une skill décrit comment aborder une catégorie de tâches — le vocabulaire du domaine, la démarche de raisonnement, le format de sortie — et non les tâches elles-mêmes. Cette distinction entre définir l’approche et intégrer les données est au cœur de la conception de skills qui restent utiles dans le temps.

Quand intégrer les connaissances du domaine — et quand s’en abstenir

La plupart des skills qui échouent le font parce qu’elles intègrent trop d’informations. Enthousiasmées par le concept, les équipes rédigent une skill qui inclut des noms de fournisseurs précis, les paliers tarifaires actuels, le format de rapport préféré d’un client et les points de terminaison exacts des API utilisés aujourd’hui. Six mois plus tard, la moitié de ces informations sont erronées, la skill ne correspond plus à la réalité et personne ne sait à quelles parties se fier.

La règle pratique : intégrer ce qui évolue lentement et laisser à l’agent le soin de gérer ce qui change fréquemment.

Le vocabulaire du domaine évolue lentement. Une skill destinée au traitement des documents d’importation doit connaître le certificat d’origine, la méthode déductive d’évaluation en douane et le cadre réglementaire du marché cible. Ces connaissances évoluent bien plus lentement que les détails opérationnels, même si les cadres réglementaires sont modifiés et nécessitent toujours un réexamen périodique. Elles ont leur place dans la skill.

Les formats précis de dépôt des documents, les noms des contreparties, les seuils réglementaires en vigueur et les échéances exactes changent constamment. Ils doivent figurer dans les données que l’agent reçoit à l’exécution, et non dans la définition de la skill. Celle-ci apprend à l’agent à lire une catégorie de documents. Le document à traiter lui est fourni comme contexte.

Un test utile : si vous devez mettre à jour la skill à chaque changement dans l’environnement de l’entreprise, elle contient les mauvaises informations. Les skills bien conçues restent utiles malgré les changements organisationnels. Les autres deviennent presque immédiatement obsolètes.

La structure SKILL.md

La structure de référence d’un fichier de skill est simple. Un bloc de métadonnées en en-tête, ou frontmatter, identifie la skill et définit quand l’activer ; le corps du fichier indique comment l’utiliser.

---
name: import-document-processor
description: Use when processing import declarations, ACP applications,
  or customs documentation for Singapore, Japan, or EU markets
---

## Context
Contexte sur le domaine : ce qu'est cette classe de documents, pourquoi
elle existe, ce que l'agent doit savoir pour en interpréter un intelligemment.

## Approach
Instructions étape par étape pour gérer la tâche : quoi chercher,
comment gérer les cas ambigus, quoi escalader à la revue humaine.

## Output Format
Exactement ce que la sortie doit contenir, dans quelle structure.

## Edge Cases
Modes d'échec connus et comment les gérer.

Sur le plan opérationnel, le bloc de description est la partie la plus importante. Il détermine si l’agent active la skill. Une description vague — « utiliser pour les documents » — entraîne une activation irrégulière. Une description précise, qui nomme les types de documents, les contextes métier et les marchés concernés, produit un comportement fiable.

La description ne doit toutefois pas être trop restrictive. Si elle l’est, l’agent passe à côté de demandes pertinentes. L’objectif est qu’un professionnel averti reconnaisse dans cette description sa propre situation, ni plus ni moins. Cela nécessite des ajustements en pratique. Tester les cas limites lors du déploiement initial permet de vérifier que le périmètre d’activation correspond à vos attentes.

Le mécanisme /loop pour les tâches récurrentes

Certains flux de travail métier suivent un calendrier : extraction quotidienne depuis un point de terminaison de l’API, agrégation hebdomadaire de rapports fournisseurs, génération mensuelle de synthèses destinées aux clients. Il ne s’agit pas d’interactions ponctuelles, mais de processus opérationnels qui se poursuivent indépendamment de toute intervention manuelle.

Dans Claude Code, la commande /loop transforme une interaction pilotée par une skill en une opération récurrente :

/loop 24h /process-supplier-reports

La skill désignée s’exécute de nouveau à l’intervalle spécifié au sein de la session en cours, qui fournit le contexte à chaque invocation. La skill effectue le travail ; la boucle gère la planification. En octobre 2026, la documentation de Claude Code précise que /loop est limité à la session : les tâches ne se déclenchent que tant que la session est active, et les tâches récurrentes expirent après sept jours. Les planifications durables en production doivent donc passer par une tâche cron, un pipeline CI ou une tâche planifiée dans le cloud qui appelle la même skill.

La conception de skills récurrentes impose des exigences particulières qui ne s’appliquent pas aux skills interactives. Elles doivent être idempotentes : exécuter deux fois la même skill sur la même entrée ne doit ni créer d’enregistrements en double, ni envoyer de notifications en double, ni corrompre l’état des systèmes en aval. Leur comportement en cas d’erreur doit être explicite : il faut définir clairement ce qui se passe lorsque l’entrée est mal formée, qu’une API est indisponible ou que les données attendues sont absentes. Enfin, si des systèmes en aval utilisent leur sortie, celle-ci doit être exploitable par une machine, et pas seulement lisible par un humain.

Les skills qui fonctionnent de manière fiable en boucle ont presque toujours un périmètre plus restreint que celles conçues pour un usage interactif. Une skill interactive peut traiter correctement cinq types de documents différents, avec des résultats moins complets mais acceptables pour les types inconnus. La version en boucle traite un seul type de document avec précision et signale explicitement une erreur face à toute entrée inattendue. La fiabilité opérationnelle privilégie la précision plutôt que la souplesse.

Un repère pratique : si vous ne pouvez pas décrire en moins de dix minutes l’intégralité du comportement attendu de la skill, y compris les cas d’erreur, son périmètre est probablement trop large pour une exécution planifiée fiable.

Exemples pratiques issus de la production

Trois approches que nous avons utilisées dans des environnements opérationnels réels :

Extraction de données à partir des communications des fournisseurs. Les fournisseurs envoient des confirmations de commande, des notifications d’expédition et des mises à jour de factures dans des formats hétérogènes, parfois structurés, mais souvent non. Une skill adaptée au style de communication de chaque fournisseur extrait des données structurées de textes non structurés. Elle sait qu’un fournisseur donné inclut une référence de bon de commande dans le deuxième paragraphe de son e-mail de confirmation, que son format de date est DD.MM.YYYY et que ses codes produit suivent un schéma précis. Le contenu de l’e-mail change chaque semaine ; la méthode d’analyse reste la même. Les données extraites alimentent directement les systèmes de gestion des stocks, sans intervention manuelle entre la réception du message et la saisie des données.

Génération de rapports à partir de données opérationnelles. Produire une synthèse opérationnelle hebdomadaire exige de savoir quels indicateurs comptent, quels seuils sont significatifs, quelles comparaisons entre périodes sont pertinentes et comment présenter les conclusions à un public donné. Rien de cela ne change d’une semaine à l’autre. Une skill définit ce cadre une seule fois. À l’exécution, l’agent reçoit les données actuelles et applique le cadre d’analyse configuré. Le format de sortie, le registre de langue et les sections obligatoires sont tous définis dans la skill, sans devoir être précisés à chaque fois. Le résultat est une cohérence que la rédaction manuelle de prompts atteint rarement à grande échelle.

Supervision des systèmes et alertes. L’infrastructure génère des journaux en continu. Les skills de supervision définissent les schémas qui constituent un événement notable, la manière de classer sa gravité et les informations dont une personne a besoin pour réagir efficacement à une alerte. Associées au mécanisme de boucle et exécutées à intervalles courts, ces skills vérifient les conditions définies et génèrent des alertes structurées lorsqu’elles sont remplies.

Le principal enjeu de conception est ici la gestion des faux positifs. Une skill qui déclenche une alerte à chaque anomalie habitue les professionnels à ignorer les alertes. Le véritable travail consiste à ajuster les critères et à définir précisément les conditions dans lesquelles une alerte mérite une attention humaine. Ce n’est pas un problème technique, mais un problème de connaissance du domaine. Pour le résoudre correctement, il faut recueillir les indications détaillées des personnes qui traitent actuellement les incidents manuellement : elles savent déjà distinguer le signal du bruit. La skill formalise ce savoir.

Ce que les skills ne résolvent pas

Les skills formalisent un savoir-faire propre à certains domaines. Elles ne créent pas de capacité générale.

Une skill bien configurée traite les schémas connus de manière fiable. Elle gère mal les situations réellement nouvelles, car les instructions qui la rendent fiable dans les contextes familiers la contraignent dans les contextes inconnus. En pratique, les skills fonctionnent mieux lorsque le périmètre des tâches est raisonnablement délimité : documents d’importation de marchés précis, génération de rapports pour un ensemble défini d’indicateurs, analyse de journaux à partir de schémas d’alerte connus. « Aider à gérer les opérations de l’entreprise » n’est pas un périmètre délimité. Une skill ne peut pas rendre un agent compétent dans un domaine où personne n’a pris le temps de définir ce qu’est un travail compétent.

L’autre limite est la maintenance. Les skills qui intègrent des connaissances métier doivent être mises à jour lorsque ces connaissances évoluent. Pas à chaque changement, puisque les skills bien conçues évitent les informations instables, mais certaines évolutions sont inévitables. Maintenir les skills à jour exige la même rigueur que maintenir la documentation à jour. Les organisations qui n’y consacrent pas de moyens découvrent progressivement que leurs skills ne correspondent plus à la réalité. La défaillance est silencieuse : la skill continue de s’exécuter et de produire des résultats, mais ceux-ci comportent des erreurs subtiles qui prennent du temps à être détectées.

Les organisations qui tirent le plus de valeur des skills investissent à la fois dans la configuration initiale et dans les ajustements continus. L’investissement initial est inférieur à ce que la plupart prévoient. L’effort de maintenance continue est supérieur à ce que la plupart anticipent : le planifier honnêtement fait la différence entre les skills qui restent utiles et celles qui deviennent une source d’erreurs silencieuses.

Analyses connexes

• Claude Skills : la réponse d’Anthropic au problème de personnalisation de l’IA – Comment le système de skills d’Anthropic est conçu et quel problème organisationnel il résout
• Créer un assistant IA local avec recherche web : configuration de MCP et Ollama – Configuration pratique des outils pour les agents IA dans un environnement auto-hébergé
• Intégration Punchout avec WooCommerce : simplifier les achats B2B grâce à l’automatisation intelligente – Automatisation propre à un domaine appliquée à un flux de travail B2B structuré