tva
← Insights

Construire des compétences d'agent IA pour les workflows métier spécifiques à un domaine

L'agent de codage IA généraliste gère une gamme surprenamment large de tâches avec compétence. Il lit la documentation, écrit du code, débogue les défaillances et raisonne à travers des problèmes inconnus avec suffisamment de contexte. Mais la plupart des équipes déployant ces agents dans des environnements opérationnels réels se heurtent au même point de friction : fournir ce contexte est lui-même une tâche, qui croît avec la complexité du domaine.

Un analyste de données qui a besoin de l'agent pour extraire les délais de livraison des fournisseurs depuis un dossier de bons de commande en formats mixtes ne veut pas expliquer ce qu'est un bon de commande, comment fonctionnent les conventions de nommage de son entreprise, et quel format de sortie attendent les systèmes en aval — à chaque fois. Un développeur maintenant la surveillance d'infrastructure ne veut pas coller les mêmes seuils d'alerte et définitions de gravité dans chaque conversation. La répétition est le problème.

Les compétences — des configurations packagées et réutilisables qui regroupent la connaissance du domaine et les instructions comportementales dans une seule unité invocable — sont une réponse directe à ce problème. Cet article décrit comment elles sont construites, comment elles sont déployées dans des workflows récurrents, et où elles livrent de manière fiable de la valeur.

Ce qu'est réellement une compétence

Une compétence n'est pas une fonctionnalité de modèle ou une capacité API. C'est un fichier — spécifiquement un fichier Markdown placé dans un répertoire que l'agent scanne au démarrage de la session. Quand l'agent rencontre une requête qui correspond à la description de la compétence, il charge les instructions de la compétence et les suit, plutôt que de raisonner à partir de zéro sur comment aborder la tâche.

Le fichier contient quatre choses : un bloc de description qui dit à l'agent quand activer la compétence ; un ensemble d'instructions qui spécifie comment gérer la classe de tâche ; des déclarations d'accès aux outils optionnelles qui étendent ou restreignent ce que l'agent peut atteindre pendant l'exécution ; et des exemples optionnels démontrant le comportement correct sur des entrées réalistes.

Ce que le fichier ne contient pas, ce sont des données métier codées en dur. Une compétence encode comment aborder une classe de tâches — le vocabulaire du domaine, le pattern de raisonnement, le format de sortie — pas les tâches elles-mêmes. Cette distinction, entre encoder l'approche et encoder les données, est la question de conception centrale dans la construction de compétences qui restent utiles au fil du temps.

Quand encoder la connaissance du domaine — et quand ne pas le faire

La plupart des implémentations de compétences qui échouent le font parce qu'elles encodent trop. Les équipes, enthousiastes à l'idée du concept, écrivent une compétence qui inclut des noms de fournisseurs spécifiques, des niveaux de tarification actuels, le format de rapport préféré d'un client, et les endpoints API exacts en usage aujourd'hui. Six mois plus tard, la moitié de ces informations sont incorrectes, la compétence a dérivé de la réalité, et personne n'est sûr de quelles parties faire confiance.

La règle pratique : encoder ce qui change lentement, laisser à l'agent ce qui change fréquemment.

Le vocabulaire du domaine change lentement. Une compétence pour traiter la documentation d'importation doit savoir ce qu'est un certificat d'origine, ce que signifie la méthode déductive dans la valorisation douanière, et à quoi ressemble le cadre réglementaire pour le marché cible. Cette connaissance, une fois correcte, reste correcte pendant des années. Elle appartient à la compétence.

Les formats de dépôt spécifiques, les noms des contreparties, les seuils réglementaires actuels et les délais exacts changent constamment. Ceux-ci appartiennent aux données que l'agent reçoit au moment de l'exécution — pas dans la définition de la compétence. La compétence apprend à l'agent comment lire une classe de documents. Le document réel arrive comme contexte.

Un test utile : si vous deviez mettre à jour la compétence chaque fois que quelque chose change dans l'environnement commercial, les mauvaises choses sont dans la compétence. Les compétences bien conçues survivent aux changements organisationnels. Les mal conçues deviennent périmées presque immédiatement.

La structure SKILL.md

La structure canonique du fichier de compétence est simple. Un bloc frontmatter identifie la compétence et définit quand l'activer ; le corps définit 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.

Le bloc de description est opérationnellement la partie la plus importante. Il détermine si l'agent active la compétence du tout. Une description vague — « utiliser pour les documents » — produit une activation erratique. Une description précise, nommant les types de documents, les contextes métier et les marchés pertinents, produit un comportement fiable.

Mais en réalité, la description ne doit pas sur-spécifier. Si elle est trop étroite, l'agent rate des correspondances genuines. L'objectif est une description qu'un praticien réfléchi reconnaîtrait comme correspondant à sa situation — ni plus ni moins. Cela nécessite une calibration en pratique, et il vaut la peine de tester les cas limites lors du déploiement initial pour vérifier que les limites d'activation sont là où vous les attendez.

Le pattern /loop pour les tâches récurrentes

Certains workflows métier fonctionnent selon un calendrier. Extraction quotidienne depuis un endpoint API. Agrégation hebdomadaire de rapports fournisseurs. Génération mensuelle de résumés à destination des clients. Ce ne sont pas des interactions ponctuelles — ce sont des processus opérationnels qui fonctionnent en continu, indépendamment de si quelqu'un les initie manuellement.

Le pattern /loop transforme une interaction pilotée par compétences en une opération récurrente :

/loop 24h process-supplier-reports

Cela exécute la compétence nommée à l'intervalle spécifié, passant le contexte actuel à chaque invocation. La compétence gère le travail ; le loop gère la planification.

Les compétences récurrentes nécessitent des considérations de conception spécifiques que les compétences interactives n'ont pas. Elles doivent être idempotentes — exécuter la même compétence deux fois sur la même entrée ne doit pas créer des enregistrements en double, envoyer des notifications en double, ou corrompre l'état en aval. Elles ont besoin d'un comportement d'erreur explicite — définition claire de ce qui se passe quand l'entrée est malformée, quand une API est indisponible, ou quand les données attendues sont absentes. Et si des systèmes en aval consomment leur sortie, cette sortie doit être lisible par machine, pas seulement par des humains.

Les compétences qui fonctionnent de manière fiable en boucle sont presque toujours plus étroites que celles construites pour l'usage interactif. Une compétence interactive peut gérer gracieusement cinq types de documents différents avec une dégradation raisonnable pour les types inconnus. La variante en boucle gère précisément un type de document et signale explicitement tout ce qui est inattendu. La fiabilité opérationnelle favorise la spécificité sur la flexibilité.

Une heuristique pratique : si vous ne pouvez pas décrire le comportement attendu complet de la compétence — y compris les cas d'erreur — en moins de dix minutes, elle est probablement trop large pour une exécution planifiée fiable.

Exemples pratiques issus de la production

Trois patterns que nous avons utilisés dans des environnements opérationnels réels :

Extraction de données depuis les communications fournisseurs. Les fournisseurs envoient des confirmations de commande, des notifications d'expédition et des mises à jour de factures dans des formats incohérents — parfois structurés, souvent non. Une compétence configurée pour le style de communication de chaque fournisseur extrait des données structurées depuis du texte non structuré. La compétence sait qu'un fournisseur particulier 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 JJ.MM.AAAA, et que ses codes produit suivent un pattern spécifique. Ce qui change chaque semaine, c'est le contenu réel de l'e-mail ; ce qui reste fixe, c'est comment l'analyser. La sortie extraite alimente directement les systèmes d'inventaire sans intervention manuelle entre la réception du message et la saisie des données.

Génération de rapports depuis des données opérationnelles. Générer un résumé opérationnel hebdomadaire nécessite de savoir quelles métriques comptent, quels seuils sont significatifs, quelles comparaisons sont significatives sur les périodes, et comment formuler les conclusions pour une audience spécifique. Rien de tout cela ne change d'une semaine à l'autre. Une compétence l'encode une fois. Au moment de l'exécution, l'agent reçoit les données actuelles et applique le cadre analytique configuré. Le format de sortie, le registre de langue, les sections qui doivent toujours apparaître — tous définis dans la compétence, pas re-spécifiés à chaque fois. Le résultat est une cohérence que le prompting manuel atteint rarement à grande échelle.

Surveillance du système et alertes. L'infrastructure génère des logs continuellement. Les compétences de surveillance définissent quels patterns constituent un événement notable, comment classifier la gravité, et quelles informations un humain a besoin pour agir efficacement sur une alerte. Couplées au pattern loop et s'exécutant à un intervalle court, ces compétences vérifient les conditions définies et génèrent des alertes structurées quand ces conditions sont remplies.

La considération de conception clé ici est la gestion des faux positifs. Une compétence qui alerte sur chaque anomalie entraîne les praticiens à ignorer les alertes. Le vrai travail est la calibration — définir des conditions précises dans lesquelles une alerte mérite l'attention humaine. Ce n'est pas un problème technique ; c'est un problème de connaissance du domaine. Le résoudre correctement nécessite un input détaillé des personnes qui répondent actuellement manuellement aux incidents, parce qu'elles ont déjà intériorisé le seuil entre signal et bruit. La compétence formalise cette connaissance.

Ce que les compétences ne résolvent pas

Les compétences encodent la compétence dans des domaines spécifiques. Elles ne créent pas de capacité générale.

Une compétence bien configurée gère les patterns connus de manière fiable. Elle ne gère pas bien les situations véritablement nouvelles, parce que les instructions qui la rendent fiable dans les contextes familiers la contraignent activement dans les contextes inconnus. L'implication pratique est que les compétences fonctionnent le mieux quand l'espace des tâches est raisonnablement délimité — documentation d'importation de marchés spécifiques, génération de rapports pour un ensemble défini de métriques, analyse de logs selon des patterns d'alerte connus. « Aider avec les opérations commerciales » n'est pas un espace de tâches délimité. Les compétences ne peuvent pas rendre un agent compétent dans des domaines où personne n'a investi pour définir à quoi ressemble la compétence.

L'autre limitation est la maintenance. Les compétences qui encodent la connaissance du domaine nécessitent des mises à jour quand cette connaissance change — pas chaque changement, parce que les compétences bien conçues évitent d'encoder des informations volatiles, mais certains changements sont inévitables. Garder les compétences à jour nécessite la même discipline que garder la documentation à jour. Les organisations qui n'y investissent pas découvrent, progressivement, que leurs compétences ont dérivé de la réalité. Le mode d'échec est silencieux : la compétence continue à s'exécuter, continue à produire de la sortie, et la sortie est subtilement incorrecte de manières qui prennent du temps à détecter.

Les organisations qui extraient le plus de valeur des compétences investissent à la fois dans la configuration initiale et dans la calibration continue. L'investissement initial est plus petit que la plupart ne l'anticipent. L'engagement de maintenance continue est plus grand que la plupart ne le planifient — et le planifier honnêtement est ce qui sépare les compétences qui restent utiles de celles qui deviennent une source d'erreurs silencieuses.

Insights connexes

Articles connexes

Construire un catalogue produit B2B avec des pages de certification

Construire un Entrepôt de Données Amazon avec FastAPI et TimescaleDB

Construire une infrastructure de données prête pour la production pour les vendeurs Amazon : présentation de tva-fetch