Processus agentiques en entreprise : où placer le code, les skills et le jugement

Une skill se mesure comme un comportement, pas comme un interrupteur

La documentation d’Agent Skills propose un protocole statistique de déclenchement qui révèle la nature du format : la description oriente un modèle, elle ne constitue pas un appel de fonction garanti [1].

• Constituer environ vingt requêtes qui devraient ou ne devraient pas déclencher la skill.
• Exécuter chaque requête trois fois afin d’observer la variabilité entre essais.
• Séparer 60 % des exemples pour l’amélioration et 40 % pour la validation.
• Calculer le taux de déclenchement ; le seuil de 0,5 est un défaut de protocole, pas une promesse de qualité en production.

Ce protocole répond à une question de découverte — « le modèle pense-t-il à charger la bonne compétence ? » — alors qu’un processus métier doit aussi répondre à des exigences de complétude, d’exactitude et de maîtrise des effets.

• Une skill correctement décrite peut se déclencher bien plus souvent que le seuil d’acceptation.
• Une requête simple peut ne pas l’activer si le modèle estime pouvoir répondre directement.
• La même entrée peut produire un choix de skill ou une sortie différente lors d’un autre essai.
• Une action obligatoire doit donc être imposée par l’orchestrateur plutôt que laissée à la seule découverte sémantique.

Ce qu’une skill capitalise réellement

Une skill est un dossier centré sur SKILL.md, dont les métadonnées facilitent la découverte et dont le corps, les scripts, les gabarits et les références transmettent une méthode de travail [2] [3].

• name identifie la compétence et description explique quand l’utiliser.
• Le corps Markdown décrit la procédure, les critères et les cas limites.
• Les ressources annexes ne sont lues que lorsqu’elles deviennent nécessaires.
• Les scripts exécutent les opérations qui gagnent à rester déterministes.

Le chargement progressif limite le contexte consommé, mais il crée un point de fragilité puisque la qualité de la description et la taille du catalogue influencent ce que le modèle découvre.

• Les métadonnées de toutes les skills sont visibles avant le chargement du corps.
• Une description trop vague augmente les faux déclenchements ; une description trop étroite crée des oublis.
• Les catalogues volumineux imposent de tester la découverte après chaque ajout ou modification.
• Les évaluations de déclenchement doivent être distinctes des évaluations de qualité de sortie.

Le format est un support raisonnable de capitalisation inter-outils, tout en exigeant une validation par environnement plutôt qu’une promesse de portabilité absolue.

• Le standard a été ouvert après son lancement initial par Anthropic [4].
• OpenAI, Microsoft et Google documentent une prise en charge dans certains de leurs produits [5].
• Les permissions, outils disponibles, commandes et chemins restent propres à chaque client.
• La valeur durable réside dans la méthode écrite ; son exécution doit être qualifiée sur chaque plateforme.

Un workflow agentique organise le jugement au lieu de lui céder le processus

Dans cet article, « workflow » désigne un chemin d’exécution piloté par du code, conformément à la distinction d’Anthropic entre chemins prédéfinis et agents qui dirigent dynamiquement leur propre usage des outils [6].

• Le code porte les requêtes, filtres, jointures, conditions, limites et reprises.
• Les appels de modèle interviennent aux endroits où une réponse ne peut pas être entièrement spécifiée à l’avance.
• Le graphe peut comporter des branches dynamiques sans abandonner la persistance, la journalisation ni les autorisations.
• Le choix entre workflow et boucle agentique dépend de la prévisibilité du travail et du coût d’une erreur.

La relance de devis illustre une division concrète entre règle, jugement et engagement, sans prétendre que trois catégories couvrent tous les métiers.

#	Étape	Nature	Exécutant
1	Sélectionner les devis sans réponse depuis quinze jours	Vérifiable	Requête
2	Lire les échanges et repérer un refus implicite	Interprétative	Agent, sortie structurée
3	Exclure les litiges, dédupliquer, plafonner le lot	Règle de gestion	Code versionné
4	Rédiger un projet de relance adapté	Générative	Agent
5	Enregistrer chaque message en brouillon	Effet contrôlé	Code idempotent
6	Présenter la synthèse au dirigeant	Synthèse	Agent
7	Après validation, envoyer et journaliser	Engagement	Code avec autorisation humaine

L’étape d’interprétation gagne à retourner un objet contrôlable plutôt qu’un paragraphe libre, afin de séparer la lecture du modèle de la décision de l’entreprise.

• refus_implicite fournit une valeur exploitable par le flux.
• motif résume le raisonnement utile à la revue.
• citation_source permet de remonter au matériau d’origine.
• Un schéma valide la forme, tandis qu’un cas de référence ou une revue vérifie le fond.

L’écriture en brouillon dissocie création et engagement, ce qui rend possible une validation portant sur l’action exacte et non sur une intention abstraite.

• Le modèle rédige sans disposer du droit d’envoyer.
• Le système présente destinataire, contenu et pièces jointes avant autorisation.
• L’autorisation expire ou s’applique à un lot précisément défini.
• Le journal conserve la proposition, la décision et l’effet réellement exécuté.

La fiabilité de bout en bout exige des hypothèses explicites

Multiplier les taux de succès de chaque étape fournit une illustration utile uniquement sous indépendance, et ne constitue ni un pire cas ni une borne générale.

• Avec vingt événements réussissant chacun marginalement à 95 %, la réussite conjointe peut aller de 0 % à 95 % selon leur dépendance.
• Sous indépendance, le calcul donne (0{,}95^{20} \approx 35{,}8,%).
• Avec trois événements à 95 %, la plage possible est de 85 % à 95 % ; l’indépendance donne (0{,}95^3 \approx 85{,}7,%).
• Dans un système réel, on estime des probabilités conditionnelles à partir de traces représentatives.

Toolathlon mesure des répétitions d’une même tâche de benchmark, de sorte que ses résultats renseignent la stabilité entre essais sans simuler les étapes successives d’un processus [7].

• Le benchmark rapporte 80,6 % de réussite au premier essai pour la meilleure configuration citée.
• La réussite de trois répétitions atteint 73,1 %, contre 52,4 % si l’on multipliait naïvement trois fois 80,6 % sous indépendance.
• L’écart indique une dépendance entre répétitions sur ce jeu d’essai.
• Il ne donne aucune borne universelle pour une chaîne métier ni aucun taux applicable à un client.

AutomationBench mesure pour sa part l’état final de flux longs inspirés de clients de Zapier dans une entreprise simulée, ce qui teste mieux l’orchestration inter-applications sans constituer une mesure de production [11].

• Le banc couvre la vente, le marketing, les opérations, le support, la finance et les ressources humaines.
• L’agent doit découvrir les interfaces, suivre des règles superposées et éviter des données leurres.
• La publication d’avril 2026 situe les meilleurs modèles évalués sous 10 % de réussite complète.
• Ce résultat motive des contrôles locaux ; il ne donne pas la probabilité d’échec d’un workflow particulier.

Les horizons de METR apportent un autre repère, à condition de lire « durée » comme la longueur humaine de référence d’une tâche et « 80 % » comme quatre succès sur cinq dans le modèle statistique, pas comme une autonomie continue ni une exigence universelle de production [8].

• Les tâches concernent surtout le logiciel, l’apprentissage automatique et la cybersécurité.
• La durée mesure le temps d’un expert humain sur la tâche, pas le temps passé par l’agent.
• Un horizon à 80 % correspond au point où la courbe ajustée prévoit 80 % de réussite.
• Le niveau acceptable dépend de la vérifiabilité et des conséquences ; METR signale que certaines tâches critiques et difficiles à vérifier peuvent exiger plus de 98 % [9].

Quatre contrôles rendent l’orchestration exploitable

Un processus agentique devient opérable lorsque ses sorties, reprises, évaluations et autorisations sont traitées comme des composants du système plutôt que comme des consignes adressées au modèle.

• Contrats de sortie : schéma, règles métier et preuve source pour contrôler la forme et le fond.
• Idempotence et reprise : clé d’opération, état persistant et compensation pour éviter les doublons.
• Évaluations : cas connus, seuils par risque et comparaison avant chaque changement de modèle ou de consigne.
• Autorisation et trace : permissions minimales, validation sur l’action exacte et journal en ajout seul.

MCP fournit un vocabulaire pour décrire les outils, mais ses annotations sont des indications déclaratives et ne remplacent pas une politique appliquée par le client [10].

• readOnlyHint décrit l’absence supposée de modification.
• destructiveHint et idempotentHint qualifient les effets d’un outil qui écrit.
• openWorldHint signale une interaction possible avec des entités externes.
• Un serveur non fiable peut mentir ; l’autorisation doit s’appuyer sur une source de confiance et sur l’état réel.

La sécurité et la fiabilité convergent vers la même règle : le modèle peut proposer une action, tandis que le programme décide si cette action est permise et sous quelles conditions.

• Afficher l’outil, ses entrées et la portée de l’action avant une approbation sensible.
• Limiter les droits au périmètre nécessaire et refuser les combinaisons de capacités dangereuses.
• Tester les échecs, délais, reprises et doubles soumissions avant la mise en service.
• Conserver les éléments nécessaires pour expliquer, annuler ou reprendre l’exécution.

NetInjectBench illustre le coût d’une barrière trop grossière et l’intérêt d’une politique d’exécution, sur un protocole expérimental qui ne garantit pas les mêmes taux hors benchmark [12].

• L’exécution naïve produit 82,50 % d’actions dangereuses sur 240 attaques de ce banc réseau.
• Une liste blanche statique ramène ce taux à 5 % mais bloque tous les changements approuvés.
• Une barrière fondée sur des métadonnées intègres obtient 0 action dangereuse sur 240 et préserve 99,17 % à 100 % de l’utilité mesurée.
• Le résultat dépend explicitement de l’intégrité des métadonnées et demande donc une racine de confiance indépendante du contenu hostile.

L’ANSSI formule la même frontière sur un plan normatif en recommandant de proscrire les actions critiques automatisées sur le système d’information et de limiter celles qui partent d’entrées non maîtrisées [13].

• R9 vise les actions critiques sur le système d’information.
• R27 vise les actions automatiques déclenchées à partir d’entrées telles que des données internet ou des messages reçus.
• R29 demande de journaliser les traitements du système d’IA.
• L’application concrète dépend de l’analyse de risque et du périmètre technique de l’organisation.

Trois questions pour attribuer chaque étape

Le découpage se fait avant le choix du modèle en examinant successivement la vérifiabilité, la nature du travail et la conséquence de la sortie.

• Réponse unique et vérifiable : compter, filtrer, joindre, calculer et appliquer une règle stable reviennent généralement au code.
• Travail d’interprétation : lire du non-structuré, réconcilier des sources ou adapter une présentation peut justifier un modèle.
• Sortie engageante : une action irréversible, financière, réglementée ou visible d’un client impose une autorisation indépendante du modèle.

Cette grille reste une heuristique de conception, car certaines tâches mêlent calcul et jugement et doivent être décomposées davantage plutôt que forcées dans une catégorie unique.

• Extraire d’abord les sous-étapes vérifiables.
• Formuler la décision métier une fois, puis la versionner si elle est stable.
• Encadrer l’étape interprétative par des entrées limitées et une sortie contrôlable.
• Placer la validation au dernier moment avant l’effet engageant.

Trois limites à intégrer dès la conception

La première limite tient aux processus dont la forme se découvre pendant l’exécution, pour lesquels un graphe entièrement fixé serait trop rigide mais un moteur durable peut mémoriser les décisions et reprendre le chemin effectivement suivi.

• Les enquêtes, le développement logiciel et la recherche ouverte comportent des sous-tâches imprévisibles.
• Le modèle peut choisir la prochaine exploration dans une enveloppe de permissions.
• Le moteur persiste les résultats et rejoue les étapes acquises après une interruption.
• Des limites de coût, de temps et d’itérations empêchent la boucle de dériver.

La deuxième limite concerne les sorties structurées, dont la validité syntaxique ne garantit ni l’exactitude ni l’utilité.

• Contraindre un JSON peut éliminer les erreurs de forme.
• Le modèle peut néanmoins produire une valeur fausse mais conforme.
• La vérification métier doit donc porter sur les champs, les sources et les invariants.
• Lorsque le raisonnement souffre d’un décodage trop contraint, le schéma peut être appliqué au moment de transmettre le résultat.

La troisième limite vient des benchmarks, qui isolent des capacités utiles sans reproduire l’ensemble d’un système, de ses données et de ses conséquences.

• Toolathlon renseigne la répétabilité d’essais d’outils.
• METR relie réussite et durée humaine de tâches techniques bien spécifiées.
• OSWorld 2.0 rapporte 20,6 % d’achèvement complet contre 54,8 % de score partiel sur 108 workflows longs, signal d’un écart entre opérations réussies et tâche terminée [14].
• La décision d’architecture exige des évaluations locales et des incidents simulés.

Le premier chantier tient dans une carte de processus

Une PME peut commencer sans plateforme dédiée en choisissant un processus fréquent ou périodique, mesurable et réversible, puis en décrivant ses entrées, sorties, règles et effets avant toute automatisation.

• Quotidien : trier les demandes entrantes et proposer une catégorie.
• Hebdomadaire : préparer les relances de devis restés sans réponse.
• Mensuel : rassembler les données et produire le dossier d’un comité.
• À éviter au départ : paiement, engagement contractuel ou communication externe sans validation.

Le premier livrable est une liste numérotée qui rend le processus discutable et testable, sans prétendre résoudre en une demi-journée les exceptions, les droits d’accès ou la qualité des données.

• Décrire l’état d’entrée et le résultat attendu de chaque étape.
• Attribuer l’étape au code, au modèle, à une décision humaine amont ou à une validation.
• Recenser les exceptions, les données manquantes et les effets impossibles à annuler.
• Définir quelques cas de référence et le journal nécessaire à une reprise.

Une skill conserve alors le savoir-faire, tandis que le workflow conserve l’ordre, l’état et les garanties dont l’entreprise a besoin.

• Réviser la skill quand la méthode métier évolue.
• Réviser le workflow quand la règle, l’autorisation ou le système connecté change.
• Réévaluer les deux lors d’un changement de modèle ou d’environnement.

Réservez l’audit de maturité IA Junyr : une visio gratuite de 30 minutes, sans engagement, pour choisir un premier processus à examiner.

---

Références

[1] Agent Skills, « Optimizing skill descriptions », consulté le 6 septembre 2026 : protocole de requêtes positives et négatives, trois essais, séparation entraînement-validation et seuil par défaut. https://agentskills.io/skill-creation/optimizing-descriptions

[2] Anthropic, « Agent Skills », consulté le 6 septembre 2026 : structure d'une skill et divulgation progressive. https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview

[3] Agent Skills, « Specification », consulté le 6 septembre 2026 : métadonnées et structure du format. https://agentskills.io/specification

[4] Anthropic, « Skills for organizations and the skills directory », 18 décembre 2025. https://claude.com/blog/organization-skills-and-directory

[5] Documentation officielle : OpenAI, Build skills ; Microsoft, Agent skills ; Google, Gemini CLI skills, consultées le 6 septembre 2026.

[6] Anthropic Engineering, « Building effective agents », 19 décembre 2024 : distinction entre workflows à chemins prédéfinis et agents à contrôle dynamique. https://www.anthropic.com/engineering/building-effective-agents

[7] Anthropic, System Card: Claude Opus 5, 24 juillet 2026, §8.13.6 Toolathlon Verified : taux Pass@1 et Pass³, cités comme essais répétés d'un benchmark. PDF

[8] METR, « Task-Completion Time Horizons of Frontier AI Models », mis à jour le 8 mai 2026 : définition par durée humaine de référence et courbe de réussite. https://metr.org/time-horizons/

[9] Thomas Kwa, METR, « Clarifying limitations of time horizon », 22 janvier 2026 : portée, incertitudes et fiabilité requise selon la vérifiabilité. https://metr.org/notes/2026-01-22-time-horizon-limitations/

[10] Model Context Protocol, « Tools », révision du 18 juin 2025, et blog MCP, « Tool Annotations as Risk Vocabulary », 16 mars 2026 : schémas de sortie, annotations non fiables hors serveur de confiance et validation humaine. Spécification ; analyse des annotations.

[11] Daniel Shepard et Robin Salimans, « AutomationBench », 21 avril 2026 : 47 applications, règles métier superposées et notation sur l'état final. https://arxiv.org/abs/2604.18934

[12] Ruksat Khan Shayoni et al., « NetInjectBench », 11 juillet 2026 : 130 scénarios, 240 attaques et comparaison de défenses sous hypothèse d'intégrité des métadonnées. https://arxiv.org/abs/2607.10490

[13] ANSSI, « Recommandations de sécurité pour un système d'IA générative », 29 avril 2024, recommandations R9, R27 et R29. PDF officiel

[14] Mengqi Yuan et al., « OSWorld 2.0 », 28 juin 2026 : 108 workflows longs, métriques d'achèvement complet et de score partiel. https://arxiv.org/abs/2606.29537