Processus agentiques d'entreprise : une skill se réutilise, un workflow se rejoue

La mesure officielle du déclenchement d’une skill

La documentation du standard ouvert qui définit aujourd’hui les skills contient un passage que peu de dirigeants ont lu, alors qu’il devrait commander leurs choix d’architecture. Pour vérifier qu’une skill se déclenche lorsqu’elle doit se déclencher, le standard recommande une procédure en trois temps : écrire une vingtaine de requêtes de test, exécuter chacune d’entre elles trois fois, puis calculer un taux de déclenchement défini comme la proportion d’exécutions au cours desquelles la skill a effectivement été invoquée. Une requête censée déclencher la skill est considérée comme réussie dès lors que ce taux dépasse un seuil, et le standard précise que 0,5 constitue une valeur par défaut raisonnable [1].

Autrement dit, la procédure d’acceptation officielle d’une tâche réutilisable, dans le format que quarante-six produits savent aujourd’hui lire, consiste à vérifier qu’elle se déclenche plus d’une fois sur deux. Le standard assume ce choix et l’explique en une ligne : « Le comportement du modèle est non déterministe : la même requête peut déclencher la skill lors d’une exécution et pas lors de la suivante » [1].

Ce chiffre de 0,5 se prête toutefois à un contresens qu’il vaut mieux lever tout de suite. Le seuil sert de critère d’acceptation à l’intérieur d’un protocole de test, où il permet de décider si une description est assez bonne pour être conservée, et une skill correctement réglée se déclenche en pratique bien plus souvent qu’une fois sur deux. Ce que ce chiffre révèle tient donc moins à la performance qu’à l’unité de mesure : le standard raisonne en fréquence, quand une entreprise qui exécute un processus de gestion raisonne en garantie.

Le non déterminisme appartient au matériau, et le standard le documente au lieu de le masquer. Les difficultés commencent lorsqu’une entreprise construit un processus de facturation, de relance commerciale ou de production documentaire sur cette propriété sans en avoir conscience, puis s’étonne que le résultat obtenu le lundi ne ressemble pas à celui du mardi. La discipline qui répond à ce problème est ancienne, et elle porte un nom que les directions techniques connaissent depuis quarante ans : le génie logiciel.

Anatomie d’une skill

Une skill se présente matériellement comme un dossier, organisé autour d’un fichier SKILL.md obligatoire, composé d’un en-tête et d’un corps rédigé en Markdown, auquel viennent s’ajouter des scripts, des gabarits et des documents de référence [2]. L’en-tête ne comporte que deux champs obligatoires, un name d’au plus 64 caractères et une description d’au plus 1 024 caractères [3]. Le corps décrit une méthode de travail en langage naturel, de la même façon qu’une procédure interne le ferait : comment relire un contrat de sous-traitance dans cette entreprise, quelles vérifications effectuer sur un devis avant de l’envoyer, quel plan type suivre pour répondre à un appel d’offres.

Le mécanisme de chargement mérite d’être compris, parce qu’il explique à la fois l’économie du format et sa fragilité. Au démarrage, l’agent ne charge que le nom et la description de chaque skill disponible, ce qui représente environ cent jetons par skill et suffit à lui signaler l’existence d’une compétence sans encombrer sa mémoire de travail [2]. Lorsqu’une demande semble correspondre à l’une de ces descriptions, il lit alors le SKILL.md complet. Les fichiers annexes restent gratuits tant qu’ils ne sont pas ouverts, et les scripts embarqués s’exécutent sans que leur code entre dans le contexte, seule leur sortie étant facturée en jetons [2]. Anthropic désigne ce fonctionnement sous le nom de divulgation progressive.

Trois propriétés expliquent la diffusion rapide du format :

• la lisibilité : le fichier reste intelligible par un humain, ce qui en fait un document d’entreprise que le métier peut relire et amender, plutôt qu’un artefact réservé aux développeurs ;
• la portabilité : lancé par Anthropic le 16 octobre 2025 [4], publié comme standard ouvert le 18 décembre 2025 avec une gouvernance distincte [5], le format est aujourd’hui reconnu par la documentation officielle d’OpenAI pour ChatGPT et Codex [6], de Microsoft pour GitHub Copilot dans VS Code [7] et de Google pour Gemini CLI [8], la page de compatibilité du standard recensant quarante-six produits au 30 août 2026 [9] ;
• la composabilité : plusieurs skills peuvent s’empiler sur une même tâche, l’agent identifiant lui-même celles dont il a besoin [4].

Cette dernière propriété constitue également la limite du format, puisque l’agent qui identifie les skills pertinentes est aussi celui qui peut se tromper. La documentation du standard est explicite sur ce transfert de responsabilité, en indiquant que « la description porte à elle seule toute la charge du déclenchement » [1], et elle ajoute une nuance que les équipes découvrent le plus souvent sur le terrain : une demande simple en une seule étape peut ne pas déclencher la skill correspondante alors même que la description lui correspond parfaitement, l’agent estimant pouvoir s’en passer [1]. Le réglage du déclenchement relève dès lors d’une démarche statistique plutôt que d’un paramétrage, avec un jeu d’entraînement d’environ 60 % des requêtes et un jeu de validation de 40 % mis de côté pour vérifier que les améliorations se généralisent [1].

Un détail de la documentation de Claude Code achève de fixer l’idée, et il devrait être connu de toute organisation qui envisage de déployer des skills à grande échelle. Le catalogue des skills disponibles occupe une part du contexte plafonnée à 1 % de la fenêtre du modèle, dont ce site a détaillé ailleurs les contraintes de taille et de coût, et lorsque la liste dépasse ce budget, l’outil raccourcit les descriptions pour la faire tenir, « ce qui peut retirer les mots-clés dont Claude a besoin pour faire correspondre votre demande » [10]. Ajouter une skill peut donc suffire à en faire cesser une autre de fonctionner, sans que rien n’ait été modifié dans la skill devenue muette : c’est précisément le type de couplage invisible que le génie logiciel a mis des décennies à apprendre à éliminer.

Il devient alors possible d’énoncer avec précision le contrat que porte une skill.

• Ce qu’elle garantit : la réutilisation d’un savoir-faire, sous la forme d’une méthode écrite une fois, appliquée par n’importe quel agent compatible, transportable d’un outil à l’autre, et révisable par la personne qui connaît le métier plutôt que par un développeur.
• Ce qu’elle laisse ouvert : le moment de son déclenchement, ainsi que la stricte identité de deux résultats successifs obtenus sur la même entrée.

L’équivalent humain de ce contrat est familier à toute organisation. Une skill correspond à une procédure remise à un collaborateur compétent : elle élève le niveau moyen, elle rend le travail transmissible et elle survit au départ de celui qui l’a rédigée, sans pour autant transformer son destinataire en machine-outil. Personne n’attend de deux commerciaux qu’ils produisent la même réponse à appel d’offres mot pour mot.

Anatomie d’un workflow agentique

Un mot doit être désambiguïsé avant d’aller plus loin, faute de quoi la discussion devient impossible avec un interlocuteur technique, car le terme « workflow » recouvre deux emplois distincts dans la documentation des éditeurs. À l’intérieur d’un SKILL.md, il désigne une procédure décrite en Markdown, c’est-à-dire une suite d’étapes rédigées que le modèle suit avec son jugement. Dans le vocabulaire d’architecture, il désigne un enchaînement piloté par du code, et c’est ce second sens qui nous occupe ici. Anthropic le retenait déjà dans son billet d’ingénierie du 19 décembre 2024, en distinguant deux familles de systèmes : les workflows, « où les modèles de langage et les outils sont orchestrés par des chemins de code prédéfinis », et les agents, « où les modèles de langage dirigent dynamiquement leurs propres processus et leur usage des outils » [11]. Ce texte approche ses deux ans, ce qui en fait un repère conceptuel daté plutôt qu’un état de l’art, mais la distinction qu’il pose n’a pas vieilli.

Un processus agentique d’entreprise, au sens où je l’emploie dans cet article, est un workflow au second sens du terme. Son squelette est algorithmique, composé de requêtes, de filtres, de jointures, de boucles, de conditions et de reprises, écrites une fois et versionnées, et ce squelette n’improvise jamais. Il appelle des agents en des points identifiés à l’avance, pour accomplir les trois opérations qu’un algorithme ne sait pas conduire :

• analyser, c’est-à-dire lire du non structuré et en extraire une information exploitable, qu’il s’agisse d’un fil d’e-mails, d’un compte rendu de visioconférence, d’un contrat ou d’une réclamation ;
• synthétiser, c’est-à-dire réconcilier plusieurs sources qui ne disent pas la même chose et hiérarchiser ce qui compte pour la décision à prendre ;
• présenter, c’est-à-dire mettre en forme un résultat pour un destinataire donné, dans son registre et dans son format.

Toutes les autres opérations relèvent du code. Compter, trier, dédupliquer, plafonner, joindre deux tables, appliquer une règle de gestion, écrire dans une base ou envoyer une notification admettent une seule réponse juste, et confier une réponse juste à un exécutant non déterministe constitue un choix d’architecture dont l’entreprise ne retire aucun bénéfice.

Le tableau ci-dessous applique ce découpage à un processus banal et vérifiable, la relance des devis restés sans réponse, écrite comme un workflow de sept étapes dont trois seulement font appel à un agent.

#	Étape	Nature	Qui l’exécute
1	Sélectionner les devis envoyés depuis plus de quinze jours, sans réponse entrante du contact	Déterministe	Une requête
2	Lire le fil d’e-mails et le compte rendu de visio de chaque dossier, détecter un refus implicite	Non déterministe	Un agent, sortie structurée
3	Écarter les clients en litige, dédupliquer par société, plafonner à vingt dossiers	Déterministe	Du code
4	Rédiger un projet de relance adapté à chaque dossier retenu	Non déterministe	Un agent
5	Écrire chaque message en brouillon dans la messagerie, sans jamais l’envoyer	Déterministe	Du code
6	Produire la note de synthèse destinée au dirigeant	Non déterministe	Un agent
7	Journaliser, marquer les dossiers traités, notifier	Déterministe	Du code

Deux étapes de ce tableau méritent un commentaire, parce qu’elles portent l’essentiel de la valeur d’ingénierie de la chaîne.

L’étape 2 contient le geste le plus rentable de l’ensemble, puisque l’agent y rend un objet structuré plutôt qu’un paragraphe : un booléen indiquant s’il a détecté un refus implicite, un motif court, et la citation exacte sur laquelle il s’appuie. Il en découle trois conséquences immédiates. Le résultat devient vérifiable, un humain pouvant remonter à la phrase citée pour contrôler le jugement rendu. Il devient testable, puisque l’entreprise peut constituer un jeu de dossiers dont elle connaît la bonne réponse. Il devient enfin une donnée directement exploitable par l’étape suivante, ce qui évite de repayer un tirage non déterministe pour interpréter ce que le précédent a voulu dire.

L’étape 5 illustre le mouvement inverse, celui de la retenue délibérée. Le processus rédige et s’arrête là, la décision d’envoyer restant à un humain parce qu’il s’agit de la seule étape de la chaîne à la fois irréversible et visible d’un client. Cette retenue relève d’une contrainte inscrite dans le code, qui n’expose tout simplement pas la fonction d’envoi, plutôt que d’une consigne adressée à l’agent dans son prompt.

Cette architecture a cessé d’être une opinion au cours de l’année 2026, puisqu’elle est devenue un produit chez plusieurs éditeurs en l’espace d’un semestre. La documentation de Claude Code décrit depuis la fin du mois de mai 2026 une primitive de workflow, et son tableau de comparaison officiel range côte à côte les quatre manières de faire travailler des agents. À la question de savoir qui décide de ce qui s’exécute ensuite, la réponse donnée est « Claude, tour par tour » pour les sous-agents comme pour les équipes d’agents, « Claude, en suivant la consigne » pour les skills, et « le script » pour un workflow ; à la question de savoir ce qui est réutilisable, la réponse est « les instructions » pour une skill et « l’orchestration elle-même » pour un workflow [12]. Le titre de cet article reprend donc une ligne de tableau de documentation. Le déterminisme y est du reste imposé par la machine plutôt que recommandé, puisqu’à l’intérieur d’un script de workflow les appels Date.now() et Math.random() lèvent une exception, afin qu’une exécution relancée refasse exactement les mêmes appels d’agents [12].

Temporal, éditeur d’un moteur d’exécution durable, en donnait le 20 août 2026 la formulation la plus complète. Son auteure observe qu’il est devenu remarquablement facile de donner des capacités à un agent et considérablement plus difficile de lui confier une responsabilité, dans la mesure où la responsabilité suppose un contrôle. Les modèles de langage étant à la fois extraordinairement capables et imprévisibles par nature, en placer un sur le chemin d’un processus métier qui parle à des clients, opère des systèmes de production ou transfère de l’argent oblige à entourer cette imprévisibilité d’éléments prévisibles : des règles applicables, une exécution fiable et un historique qui restitue exactement ce qui s’est passé [13].

Le coût de fiabilité du non déterminisme

Le calcul qui suit tient en une ligne et se fait pourtant rarement. Si chaque étape d’une chaîne réussit avec une probabilité de 95 % et que les étapes sont indépendantes, une chaîne de vingt étapes réussit de bout en bout dans 36 % des cas, tandis que la même chaîne ramenée à trois étapes non déterministes remonte à 86 %. Aucun modèle n’a été amélioré entre ces deux valeurs, seul le nombre de tirages ayant changé.

La courbe porte un second enseignement, moins intuitif que le premier. Passer de 95 % à 99 % de fiabilité par étape, ce qui représente un effort de recherche considérable sur un modèle, fait remonter une chaîne de vingt étapes de 36 % à 82 %, alors que diviser par sept le nombre d’étapes non déterministes, ce qui relève d’une décision d’architecture prise en une après-midi, produit un effet du même ordre de grandeur. Ces deux leviers présentent donc des coûts d’accès sans commune mesure.

Une réserve d’honnêteté s’impose sur ce calcul, et elle se mesure. L’hypothèse d’indépendance est fausse, et les données publiées permettent aujourd’hui d’en évaluer l’écart. Sur Toolathlon, un banc d’essai de 108 tâches réelles d’usage d’outils qui expose plus de 600 outils à travers 32 applications, avec des trajectoires de vingt à vingt-six tours, le meilleur modèle de juillet 2026 réussit 80,6 % des tâches à la première tentative et 73,1 % des tâches trois fois de suite [14]. Sous hypothèse d’indépendance, la seconde valeur vaudrait 0,806 au cube, soit 52,4 %, et les vingt points d’écart indiquent que les échecs se concentrent sur des tâches durablement difficiles au lieu de se répartir au hasard. La multiplication des probabilités constitue donc une heuristique de pire cas plutôt qu’une loi empirique, et une chaîne correctement écrite, dotée de reprises et de contrôles intermédiaires, se situe encore au-dessus de la courbe. Le sens de la pente, en revanche, ne dépend d’aucune hypothèse, puisque chaque nœud non déterministe ajouté fait baisser la fiabilité de l’ensemble selon une loi multiplicative.

Reste la question que se pose légitimement un dirigeant, celle de savoir où en est aujourd’hui un agent laissé seul sur un processus d’entreprise réel. Un banc d’essai publié le 21 avril 2026 par deux chercheurs de Zapier y répond de la façon la plus directe possible. AutomationBench place l’agent dans une entreprise simulée traversant 47 applications, avec des tâches tirées de flux de travail réellement observés chez les clients de la plateforme, en vente, marketing, opérations, support, finance et ressources humaines, et lui demande de découvrir seul les points d’accès, d’enchaîner des dizaines d’appels interdépendants, de respecter des documents de règles métier superposés et d’éviter des leurres délibérément plantés, la notation étant binaire et ne portant que sur l’état final des systèmes [15]. Au mois d’avril, le papier fondateur constatait que les meilleurs modèles de pointe passaient sous la barre des 10 % ; trois mois plus tard, le meilleur d’entre eux atteint 26,0 %, contre 17,0 % pour la génération précédente [14]. Le progrès est réel et rapide, et il laisse néanmoins trois processus métier réalistes sur quatre en échec lorsque l’agent travaille sans encadrement.

Ces chiffres expliquent pourquoi un processus d’entreprise gagne à être conçu comme un enchaînement dont on a délibérément retiré tout le non déterminisme improductif, plutôt que comme un agent autonome à qui l’on décrirait un objectif.

Les quatre gestes de génie logiciel applicables à l’orchestration

Depuis deux ans, les agents écrivent le code métier, une bascule que ce site a décrite sous le nom d’UltraCoding. Un article publié en juillet documentait cette bascule sur un registre de dix-sept jours de travail : lorsque écrire du code correct ne coûte presque plus rien, le goulot d’étranglement devient la décision de ce qu’il faut écrire [16]. Ce qui reste à concevoir dans un processus agentique tient donc à l’orchestration, c’est-à-dire à la couche qui détermine à quel moment un agent est appelé, avec quelles entrées, sous quelles garanties, et ce qu’il advient lorsqu’il se trompe.

Anthropic nomme la question centrale de cette couche dans sa propre documentation d’écriture de skills, sous le terme de degrés de liberté [17], et en distingue trois régimes :

• liberté haute, lorsque plusieurs approches sont valables et que le contexte tranche, auquel cas des consignes en langage naturel suffisent ;
• liberté moyenne, lorsqu’un motif est préféré tout en laissant une variation acceptable ;
• liberté basse, lorsque les opérations sont fragiles, que la cohérence est critique et qu’une séquence précise doit être respectée, auquel cas l’éditeur recommande un script exact, sans paramètre.

L’image employée dans la documentation est celle d’un robot progressant sur un chemin : un pont étroit bordé de précipices appelle des garde-fous et des instructions exactes, tandis qu’un champ ouvert sans danger appelle une simple direction générale. La consigne opérationnelle qui en découle figure dans la liste de contrôle officielle en sept mots, préférez les scripts pour les opérations déterministes [17], ce qui revient à écrire validate_form.py plutôt qu’à demander au modèle de générer le code de validation à chaque exécution.

Quatre gestes de génie logiciel se déduisent de ce principe, et aucun d’entre eux ne s’obtient en améliorant la rédaction d’un prompt.

Premier geste, déclarer l’idempotence plutôt que l’espérer. Le protocole MCP, qui relie un agent à ses outils, prévoit dans son schéma officiel quatre annotations par outil, portant respectivement sur la lecture seule, le caractère destructeur, l’idempotence et le monde ouvert [18]. Les valeurs par défaut méritent une lecture attentive, puisqu’en l’absence de déclaration un outil est réputé destructeur et non idempotent, destructiveHint valant true et idempotentHint valant false : le protocole part du principe qu’un outil non documenté peut casser quelque chose et qu’un second appel identique produira un second effet. La spécification ajoute que les clients doivent considérer ces annotations comme non fiables tant qu’elles ne proviennent pas d’un serveur de confiance [19], de sorte que la garantie effective se construit du côté de l’appelant, sous forme de clé d’idempotence, de verrou ou de vérification avant écriture. Les mainteneurs du protocole l’écrivent sans détour dans un billet du 16 mars 2026 : un serveur non fiable peut mentir, annoncer une opération en lecture seule et supprimer malgré tout des fichiers ; ces annotations ne constituent pas un mécanisme d’application, et l’obtention d’une garantie qu’un outil ne peut pas exfiltrer de données relève du contrôle réseau ou du bac à sable. Leur consigne tient en une ligne, gardez vos garanties de sûreté réelles dans des contrôles déterministes [20].

Le rejeu ne s’obtient toutefois pas gratuitement, et une évaluation d’orchestrations multi-agents publiée le 5 août 2026 le mesure, en constatant que le rejeu aveugle reproduit les fautes latentes et allonge le délai de détection [21]. La reprise n’apporte donc de valeur que si le système sait d’abord qu’il a échoué et à quel endroit, les auteurs précisant eux-mêmes que leurs résultats sondent des mécanismes en chaîne contrôlée et ne constituent pas une mesure sur une charge de production réelle.

Deuxième geste, valider les sorties par machine. Le même protocole permet à un outil de publier un schéma de sortie, assorti d’une règle asymétrique selon laquelle le serveur doit produire un résultat conforme et le client devrait le valider [19]. Anthropic prolonge le principe dans un motif qu’elle recommande explicitement pour les opérations par lots, les changements destructeurs et les enjeux élevés, en cinq temps : analyser, produire un fichier de plan, valider ce plan par un script, exécuter, vérifier [17]. La justification avancée reprend celle du génie logiciel classique, puisque la validation identifie les problèmes avant que les changements ne soient appliqués et qu’un script fournit une vérification objective, le plan intermédiaire restant modifiable alors que l’exécution engage.

Troisième geste, construire les évaluations avant d’en avoir besoin. La documentation d’Anthropic est directe sur ce point, et le budget d’un projet gagne à l’intégrer dès le départ : les évaluations constituent la source de vérité qui permet de mesurer l’efficacité d’une skill, et « il n’existe pas actuellement de moyen intégré d’exécuter ces évaluations. Les utilisateurs peuvent créer leur propre système d’évaluation » [17]. La méthode conseillée consiste à construire les évaluations avant d’écrire la documentation, en mesurant d’abord ce que le modèle produit sans la skill, afin de savoir ce qu’elle apporte réellement. Une entreprise qui déploie des agents sans jeu de cas de référence se prive de tout moyen de constater une régression, alors qu’elle en rencontrera nécessairement, ne serait-ce qu’au prochain changement de modèle.

Quatrième geste, inscrire la boucle humaine et la trace dans le code. La révision du 28 juillet 2026 de la spécification MCP formule ces deux exigences au niveau du protocole lui-même. Pour la boucle humaine, elle indique que, pour des raisons de confiance, de sûreté et de sécurité, il devrait toujours y avoir un humain en mesure de refuser une invocation d’outil. Pour la trace, elle demande aux clients de présenter les entrées de l’outil à l’utilisateur avant l’appel, de solliciter une confirmation sur les opérations sensibles, d’imposer des délais d’expiration et de journaliser l’usage des outils à des fins d’audit [19]. Ces quatre lignes composent un cahier des charges d’exploitation, inscrit dans une spécification de protocole.

La sécurité parvient à la même conclusion par un autre chemin, et l’édition 2026 du Top 10 de l’OWASP consacré aux applications à modèle de langage, publiée au début du mois d’août, la formule sans détour. Le classement s’appuie sur un corpus de 7 714 incidents réels dont 6 639 ont pu être classés, pondéré à trois quarts par le vote de la communauté et à un quart par le relevé d’incidents, et il en tire deux enseignements pour qui construit des processus. Le premier tient à la montée de l’excès d’autonomie, catégorie baptisée Excessive Agency, qui accède à la troisième place et constitue « le mouvement le plus lourd de conséquences de la liste », parce que le vote et les incidents concordent sur le fait que les dégâts atterrissent dans les déploiements agentiques [22]. Le second tient à une phrase qui mériterait de figurer dans tout cahier des charges : l’injection de requête est intrinsèque à l’état actuel de l’IA générative, aucun mécanisme de prévention fiable n’existe aujourd’hui, et « la défense est donc architecturale plutôt qu’interceptive » [22]. La recommandation associée, appelée médiation complète, rejoint ce que décrit cet article depuis le début, en demandant d’implémenter l’autorisation dans la logique du programme au lieu de s’en remettre à un modèle de langage pour décider si une action est permise. La lettre d’ouverture du document tient d’ailleurs en deux phrases qui vaudraient cahier des charges pour n’importe quel processus métier : cessez d’essayer de construire un modèle qu’on ne puisse pas tromper, et construisez le système autour de lui de sorte que, lorsque le modèle sera trompé, et il le sera, rien d’important ne casse [22].

Un travail publié le 11 juillet 2026 met des chiffres sur cette phrase, et le détail y vaut mieux que le résumé. Le banc d’essai compte 130 scénarios d’exploitation réseau et 240 cas d’attaque, évalués sur trois modèles ouverts de petite taille, et une exécution naïve y produit 82,50 % d’actions d’outil dangereuses. Quatre défenses formulées au niveau des consignes ramènent ce taux à 25,63 %, 21,67 %, 18,33 % et 10,00 %, ce qui représente un progrès réel tout en restant très éloigné de ce qu’un processus d’entreprise peut accepter.

Le même travail publie ensuite le résultat qui interdit de conclure trop vite. Une liste blanche statique, forme la plus grossière du déterminisme, descend à 5,00 % d’actions dangereuses en bloquant la totalité des changements pourtant approuvés, soit 0 % d’utilité. Une barrière de politique qui raisonne sur les métadonnées de l’outil avant l’appel produit pour sa part zéro action dangereuse sur 240, avec une borne haute de 1,58 % à 95 % de confiance, tout en préservant 99,17 % de l’utilité en scénario d’attaque et 100 % sur les changements approuvés, sous réserve explicite que les métadonnées soient elles-mêmes intègres [23]. Appliqué sans discernement, le déterminisme détruit donc le service qu’il prétend protéger, alors qu’appliqué au bon endroit et sur les bonnes données, il ne coûte pratiquement rien : c’est l’écart déjà rencontré à la Figure 2, mesuré cette fois sur le terrain de la sécurité.

L’ANSSI formulait déjà des recommandations proches dans son guide pour un système d’IA générative du 29 avril 2024, publié avant que le mot agent ne devienne courant. Deux d’entre elles concernent directement le sujet : proscrire l’usage automatisé d’un système d’IA pour des actions critiques sur le système d’information, et limiter voire proscrire les actions automatiques déclenchées depuis un système d’IA à partir d’entrées non maîtrisées, telles que des données issues d’Internet ou de messages reçus [24]. Ce document a plus de deux ans, ce qui souligne la stabilité de la règle : seul le nombre d’entreprises concernées a changé depuis.

Un motif traverse l’ensemble de ces documents, et il mérite d’être nommé parce qu’il situe précisément le travail qui reste à la charge de l’entreprise. L’écosystème de 2026 a adopté le vocabulaire du génie logiciel, tout en précisant que ce vocabulaire n’engageait personne. Le protocole MCP normalise un indicateur d’idempotence, puis indique qu’il s’agit d’un indice invérifiable. Les conventions d’observabilité d’OpenTelemetry définissent des traces dédiées aux agents et aux appels d’outils, dans un dépôt spécialisé créé le 5 mai 2026, tout en les marquant au statut Development, dont la définition officielle indique sans ambiguïté que le composant ne devrait pas être utilisé en production et peut être retiré sans préavis [25]. Le cadre de conception d’agents le plus étoilé de GitHub, les 12-Factor Agents, dont le facteur 8 s’intitule « possédez votre flux de contrôle », affiche 25 590 étoiles et n’a reçu aucun commit de contenu depuis le 21 septembre 2025 [26]. La norme désigne ainsi le travail d’ingénierie sans le prendre en charge, et le renvoie à l’intégrateur.

Aucun de ces quatre gestes ne suppose une compétence nouvelle. Ce sont les réflexes que les équipes appliquent depuis toujours à un traitement par lots nocturne, à savoir des contrats d’interface, un rejeu maîtrisé, un journal, une alerte et des droits minimaux, et ils avaient simplement cessé d’être visibles parce que le code métier occupait toute la place.

La méthode de découpage en trois questions

Le découpage entre ce qui revient au code et ce qui revient à l’agent se décide avant l’écriture, étape par étape, à l’aide de trois questions posées dans un ordre qui n’est pas indifférent.

La première question porte sur la vérifiabilité : cette étape admet-elle une seule réponse juste, contrôlable par quelqu’un d’autre ? Compter des devis, appliquer un seuil, joindre une table de clients à une table de factures ou calculer une marge appellent tous une réponse affirmative, et ces étapes reviennent au code. Cette seule question retire en général la moitié des étapes d’un processus au domaine du jugement, ce qui explique qu’elle vienne en premier : elle est de loin la plus rentable des trois.

La deuxième question porte sur la nature du travail : cette étape suppose-t-elle de lire du non structuré, de réconcilier des sources divergentes ou de mettre en forme pour un destinataire ? Une réponse négative signale le plus souvent une décision de gestion déguisée en étape de processus, du type de celles qui consistent à savoir s’il faut relancer les clients en litige ou plafonner le traitement à vingt dossiers plutôt qu’à cinquante. Ces arbitrages se tranchent une fois, par un humain, et deviennent ensuite des constantes du code, car les laisser à l’appréciation d’un agent à chaque exécution reviendrait à retirer une règle de gestion à l’entreprise pour la confier à un tirage.

La troisième question porte sur la conséquence : la sortie de cette étape déclenche-t-elle une action irréversible ou visible d’un client ? Une réponse affirmative maintient l’agent en place et intercale une validation humaine, écrite dans le code. La documentation de Claude Code fournit à la fois le mécanisme et sa justification, puisqu’un réglage permet de retirer au modèle le droit de déclencher une skill en réservant l’invocation à l’humain, motivé par l’éditeur en ces termes : « vous ne voulez pas que Claude décide de déployer parce que votre code a l’air prêt » [10]. Ce principe est celui qu’a déjà posé l’article de ce site consacré à l’ingénierie des systèmes agentiques et au human-in-the-loop [27], selon lequel le garde-fou vit dans le code plutôt que dans le prompt.

Les étapes qu’aucune des trois questions n’a éliminées reviennent à l’agent, avec une sortie structurée, et se limitent aux trois opérations identifiées plus haut : analyser, synthétiser, présenter.

Les trois objections à cette analyse

L’argument développé ici présente des points faibles qu’il vaut mieux exposer soi-même que laisser à un lecteur technique.

La première objection porte sur la forme du graphe. Un éditeur de moteurs d’exécution durable, Inngest, la formule clairement : la différence critique entre une boucle d’agent et un graphe de workflow classique tient au caractère dynamique de la boucle. Un graphe possède une forme connue au moment de la conception, avec une étape A, puis une étape B, puis une répartition vers C et D, tandis que la forme d’un agent est décidée à l’exécution par le modèle, le graphe se dessinant à mesure que l’agent progresse [28]. Une forme inconnue à l’avance ne peut évidemment pas être écrite à l’avance. La réponse tient au choix d’un mot, puisque ce qu’une entreprise a besoin de garantir concerne moins la connaissance préalable du graphe que sa capacité à être rejoué. Inngest le résout d’ailleurs exactement ainsi, avec un code non déterministe au premier passage et un rejeu déterministe à la reprise, les résultats mémorisés forçant le même chemin [28]. Une observation de terrain complète cette réponse : la plupart des processus qu’une PME souhaite automatiser en premier possèdent bel et bien une forme connue, la relance des devis sans réponse comportant toujours les mêmes sept étapes.

La deuxième objection porte sur une recommandation formulée plus haut dans cet article même, celle de contraindre la sortie d’un agent par un schéma, et elle oblige à la préciser. Un travail publié le 20 mai 2026, fondé sur 15 000 générations, mesure ce que son auteur appelle la taxe de contrainte : imposer un schéma dur pendant le décodage fait passer la validité de la structure de 61,5 % à 100 % et l’exactitude de la réponse de 19,7 % à 11,0 %, la proportion de sorties fausses mais structurellement valides montant de 49,5 % à 88,9 %. Sur le cas le plus proche d’un appel d’outil, une sortie JSON demandée par simple consigne atteint 91,5 % d’exactitude exécutable, contre 48,0 % lorsque le même schéma est imposé en dur, à validité structurelle identique dans les deux cas [29]. L’étude porte sur de petits modèles de moins de trois milliards de paramètres et son auteur refuse explicitement d’extrapoler, mais sa formule corrige utilement la mienne et je la reprends : raisonner librement, contraindre tard. Le schéma sert à emballer un résultat au moment de le transmettre, sans guider le raisonnement qui le produit, et un tableau de bord qui suivrait uniquement le taux de sorties bien formées pourrait donc s’améliorer pendant que l’exécution en aval se dégrade.

La troisième objection est la plus gênante, car elle émane de chercheurs qui ne défendent pas la thèse de cet article. OSWorld 2.0, banc d’essai de 108 flux de travail informatiques longs publié le 28 juin 2026, retient des tâches qui demandent à un humain une heure trente-six en médiane et mobilisent en moyenne 318 appels d’outils. Sur sa mesure principale, l’achèvement complet, la meilleure configuration testée atteint 20,6 % des tâches pour un score partiel de 54,8 % [30], et l’écart entre ces deux chiffres constitue tout le sujet, puisqu’il décrit un agent qui accomplit correctement de nombreuses opérations et achève rarement le travail. Le diagnostic des auteurs porte sur la tenue de route plutôt que sur la capacité brute, les agents perdant le fil des contraintes énoncées et manquant l’information qui arrive en cours de tâche. Ils en concluent qu’il faut de meilleurs agents, là où cet article conclut à un squelette extérieur, et les deux lectures peuvent parfaitement être vraies ensemble : le squelette permet d’exploiter des agents cette année, quand de meilleurs agents repousseront la frontière l’an prochain, sans que ni l’un ni l’autre ne dispense de savoir où cette frontière passe aujourd’hui.

Ce qu’une PME ou une ETI peut engager dès maintenant

Un article publié sur ce site il y a trois jours défendait que trois couches d’un produit agentique bougent en permanence sous les pieds de l’entreprise, à savoir le harnais, le modèle et les connecteurs [31]. La conclusion pratique de la présente analyse en découle directement, puisque l’élément qui traverse un changement de modèle sans perdre sa valeur est l’enchaînement lui-même.

Un workflow écrit en code conserve son sens lorsque le modèle change de version : les requêtes restent valides, les schémas de sortie restent valides, les tests restent exécutables, et le remplacement d’un modèle par un autre se constate sur un jeu de cas connu au lieu de se découvrir en production. Une skill constitue un actif d’une autre nature, qui porte le savoir-faire, se transporte d’un fournisseur à l’autre et tire précisément sa valeur de sa souplesse. Les deux objets se complètent, à condition de ne pas attendre de l’un la garantie que seul l’autre peut apporter. Cette répartition prolonge une thèse déjà défendue ici, selon laquelle le conversationnel ne saurait devenir une interface de travail : l’interface durable d’un processus est son enchaînement écrit, et la conversation n’en est que le point d’entrée.

Une étude Deloitte publiée le 11 août 2026 chiffre l’écart qui sépare encore les intentions des réalisations. Menée d’avril à juin 2026 auprès de 501 dirigeants dont toutes les organisations pilotaient au minimum des solutions agentiques, elle mesure que 15 % seulement ont atteint une adoption multi-agents orchestrée à l’échelle, quand 42 % en sont à tester quelques agents et 43 % à les étendre à plusieurs fonctions. Elle classe surtout sept dimensions de préparation et place les processus métier au dernier rang, à 21 %, derrière la vision stratégique à 52 %, l’infrastructure technique à 48 %, le socle de données à 42 %, la gouvernance à 39 %, les partenariats à 34 % et les effectifs à 25 % [32]. Les causes que l’étude nomme sont, dans l’ordre, des processus mal documentés et mal compris, des données et des systèmes fragmentés, et des habitudes de travail installées. La dimension la moins prête est donc celle qui ne suppose ni licence ni serveur.

Pour une PME ou une ETI, la traduction opérationnelle tient en un livrable unique. Le premier document d’un projet d’automatisation par agents est une liste numérotée qui reprend les étapes d’un processus existant et porte, en face de chacune, la réponse aux trois questions exposées plus haut. Ce document se rédige en une demi-journée, sans outil et sans budget, et il indique ensuite sans discussion possible combien de tirages non déterministes l’entreprise s’apprête à empiler et lesquels elle peut retirer.

La plupart des processus qu’on croit impossibles à automatiser sont surtout des processus que personne n’a jamais pris le temps d’écrire.

---

Sources

Toutes les pages listées ci-dessous ont été récupérées directement le 30 août 2026. Les documentations vivantes ne portent pas de date de publication : la date indiquée est celle de la consultation.

[1] Agent Skills, « Optimizing skill descriptions », documentation du standard ouvert, consultée le 30 août 2026 : protocole de mesure du taux de déclenchement, vingt requêtes, trois exécutions chacune, seuil par défaut de 0,5, découpage entraînement 60 % et validation 40 %. https://agentskills.io/skill-creation/optimizing-descriptions

[2] Anthropic, « Agent Skills », documentation, consultée le 30 août 2026 : divulgation progressive en trois niveaux, environ 100 jetons de métadonnées par skill toujours chargées, corps du SKILL.md sous 5 000 jetons chargé au déclenchement, ressources sans coût jusqu'à lecture, scripts exécutés par bash dont seule la sortie entre en contexte. https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview

[3] Agent Skills, « Specification », consultée le 30 août 2026 : champs obligatoires name (64 caractères au plus) et description (1 024 caractères au plus). https://agentskills.io/specification

[4] Anthropic, « Introducing Agent Skills », 16 octobre 2025 : lancement du format. https://claude.com/blog/skills

[5] Anthropic, « Skills for organizations and the skills directory », 18 décembre 2025 : publication du format comme standard ouvert. https://claude.com/blog/organization-skills-and-directory

[6] OpenAI, « Build skills », documentation, consultée le 30 août 2026 : prise en charge du standard ouvert dans ChatGPT et Codex. https://learn.chatgpt.com/docs/build-skills

[7] Microsoft, « Agent skills », documentation Visual Studio Code, page datée du 26 août 2026 : prise en charge par GitHub Copilot dans VS Code, l'interface en ligne de commande et l'agent cloud. https://code.visualstudio.com/docs/copilot/customization/agent-skills

[8] Google, « Skills », documentation Gemini CLI, page datée du 30 avril 2026. https://geminicli.com/docs/cli/skills/

[9] Agent Skills, « Client Showcase », consultée le 30 août 2026 : 46 produits recensés, décompte fait à la main sur la liste publiée. https://agentskills.io/clients

[10] Anthropic, « Extend Claude with skills », documentation Claude Code, consultée le 30 août 2026 : réglage disable-model-invocation, budget du catalogue de skills fixé à 1 % de la fenêtre de contexte et raccourcissement des descriptions au-delà. https://code.claude.com/docs/en/skills

[11] Anthropic Engineering, « Building effective agents », 19 décembre 2024 : distinction entre les workflows, orchestrés par des chemins de code prédéfinis, et les agents, qui dirigent dynamiquement leurs propres processus. Repère conceptuel daté, cité comme tel. https://www.anthropic.com/engineering/building-effective-agents

[12] Anthropic, « Orchestrate subagents at scale with dynamic workflows », documentation Claude Code, consultée le 30 août 2026 : tableau de comparaison sous-agents, skills, équipes d'agents et workflows (« Who decides what runs next » : « Claude, turn by turn » / « Claude, following the prompt » / « The lead agent, turn by turn » / « The script » ; « What's repeatable » : « The instructions » pour une skill, « The orchestration itself » pour un workflow) ; contrainte de déterminisme (« Claude Code makes Date.now(), Math.random(), and a no-argument new Date() throw inside the script, so that a relaunched run repeats the same agent() calls »). Primitive livrée fin mai 2026. https://code.claude.com/docs/en/workflows

[13] Cornelia Davis, « Temporal Agent Harness: durable agent infrastructure », blog Temporal, 20 août 2026. https://temporal.io/blog/temporal-agent-harness-durable-agent-infrastructure

[14] Anthropic, System Card: Claude Opus 5, 24 juillet 2026. §8.13.6 Toolathlon Verified : 108 tâches réelles d'usage d'outils, plus de 600 outils sur 32 applications, trajectoires de 20 à 26 tours ; Claude Opus 5 obtient 80,6 % de Pass@1, 87,0 % de Pass@3 et 73,1 % de Pass³, moyenne de 23,5 tours. §8.13.7 AutomationBench : Claude Opus 5 à effort maximal obtient 26,0 %, contre 17,0 % pour Claude Opus 4.8 et 17,4 % pour Claude Fable 5 ; à effort moyen, 24 % pour 0,89 dollar par tâche. PDF récupéré et converti localement le 30 août 2026. https://www-cdn.anthropic.com/c5fbac3f0b1280a933ebd26d3cb8bb9f5bdeaf48/Claude%20Opus%205%20System%20Card.pdf

[15] Daniel Shepard, Robin Salimans, « AutomationBench », arXiv:2604.18934, 21 avril 2026 : tâches tirées de flux de travail réels de la plateforme Zapier, six domaines (vente, marketing, opérations, support, finance, ressources humaines), découverte autonome des points d'accès, règles métier superposées, leurres, notation programmatique sur l'état final. « Even the best frontier models currently score below 10%. » https://arxiv.org/abs/2604.18934

[16] Paul-Antoine Tual, « Le développement à décision gardée : quand le goulot passe de l'exécution à la décision », paulantoinetual.fr, 29 juillet 2026. /blog/developpement-a-decision-gardee

[17] Anthropic, « Skill authoring best practices », documentation, consultée le 30 août 2026 : degrés de liberté haute, moyenne et basse, image du pont étroit, consigne « prefer scripts for deterministic operations », motif analyser puis planifier puis valider puis exécuter puis vérifier, et absence d'outil intégré d'exécution des évaluations. https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices

[18] Model Context Protocol, schéma officiel, révision 2026-07-28, interface ToolAnnotations : readOnlyHint par défaut à false, destructiveHint par défaut à true, idempotentHint par défaut à false, openWorldHint par défaut à true. https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/schema/2026-07-28/schema.ts

[19] Model Context Protocol, spécification, révision 2026-07-28, section « Tools » : annotations à considérer comme non fiables hors serveur de confiance, schéma de sortie que le serveur doit respecter et que le client devrait valider, humain dans la boucle avec capacité de refus, confirmation sur les opérations sensibles, délais d'expiration et journalisation à des fins d'audit. https://modelcontextprotocol.io/specification/2026-07-28/server/tools

[20] Model Context Protocol, blog officiel, « Tool Annotations as Risk Vocabulary: What Hints Can and Can't Do », 16 mars 2026, Ola Hungerford (mainteneur), Sam Morrow (GitHub), Luca Chang (AWS) : un serveur non fiable peut mentir sur ses annotations, celles-ci ne constituent pas un mécanisme d'application, et les garanties de sûreté réelles doivent vivre dans des contrôles déterministes. https://blog.modelcontextprotocol.io/posts/2026-03-16-tool-annotations/

[21] Kumar Shashwat et alii, « OrchestraBench: Evaluating Multi-Agent Orchestration Failure Modes, Recovery, and Decomposition Quality », arXiv:2608.05263, 5 août 2026 : le rejeu aveugle reproduit les fautes latentes et allonge le délai de détection ; les auteurs qualifient eux-mêmes leurs résultats de sondes de mécanismes en chaîne contrôlée, et non de mesures sur charge de production. https://arxiv.org/abs/2608.05263

[22] OWASP GenAI Security Project, « OWASP Top 10 for Large Language Model Applications », édition 2026, publiée début août 2026, licence CC BY-SA 4.0 : méthodologie (7 714 incidents réels collectés, 6 639 classés, pondération trois quarts vote de la communauté et un quart relevé d'incidents), chapitre LLM01 Prompt Injection (« no reliable prevention mechanism exists today », « defense is therefore architectural rather than interceptive ») chapitre LLM03 Excessive Agency (médiation complète, autorisation implémentée dans la logique du programme) et lettre d'ouverture des responsables du projet (« Stop trying to build a model that cannot be fooled. Build the system around it, so that when the model is fooled, and it will be, nothing important breaks. »). Contenu réutilisé ici sous licence Creative Commons Attribution-ShareAlike 4.0, https://creativecommons.org/licenses/by-sa/4.0/. https://github.com/GenAI-Security-Project/GenAI-LLM-Top10

[23] Ruksat Khan Shayoni, Muhammad Faraz Shoaib, S M Asif Hossain, M. F. Mridha, « NetInjectBench: Benchmarking Indirect Prompt Injection in Tool-Using Large Language Model Agents for Network Operations », arXiv:2607.10490, 11 juillet 2026 : 130 scénarios, 240 cas d'attaque, trois modèles ouverts (Qwen2.5-7B, Llama3.1-8B, Mistral-7B) ; exécution naïve 82,50 % d'actions dangereuses, défenses au niveau des consignes 25,63 % / 21,67 % / 18,33 % / 10,00 %, liste blanche statique 5,00 % avec 0,00 % d'utilité et 100,00 % de surblocage, barrière de politique sensible aux métadonnées 0 sur 240 avec borne haute de Wilson à 1,58 %, 99,17 % et 100,00 % d'utilité préservée. https://arxiv.org/abs/2607.10490

[24] ANSSI, « Recommandations de sécurité pour un système d'IA générative », ANSSI-PA-102, 29 avril 2024 : recommandation R9, proscrire l'usage automatisé de systèmes d'IA pour des actions critiques sur le système d'information, et recommandation R27, limiter les actions automatiques depuis un système d'IA traitant des entrées non maîtrisées. Document normatif antérieur à la fenêtre de fraîcheur des sources de marché, cité avec sa date. https://cyber.gouv.fr/publications/recommandations-de-securite-pour-un-systeme-dia-generative

[25] OpenTelemetry, conventions sémantiques GenAI, dépôt open-telemetry/semantic-conventions-genai créé le 5 mai 2026 (relevé du 30 août 2026, dernier envoi le 27 août 2026) ; les spans d'agent et d'appel d'outil portent le statut Development, défini dans specification/maturity-levels.md par « The component SHOULD NOT be used in production. The component MAY be removed without prior notice. » https://github.com/open-telemetry/semantic-conventions-genai

[26] Dex Horthy (HumanLayer), « 12-Factor Agents », dépôt GitHub humanlayer/12-factor-agents, créé le 30 mars 2025 : 25 590 étoiles et dernier commit sur la branche principale daté du 21 septembre 2025, relevés par appel à l'API GitHub le 30 août 2026. Le facteur 8 s'intitule « Own your control flow ». https://github.com/humanlayer/12-factor-agents

[27] Paul-Antoine Tual, « Ingénierie des systèmes agentiques : règles d'or, architecture et sécurité du Human-in-the-Loop », paulantoinetual.fr, 4 juillet 2026. /blog/ingenierie-systemes-agentiques-human-in-the-loop

[28] Inngest, « Durable agents », documentation, consultée le 30 août 2026 : « A workflow DAG has a known shape at design time [...] In contrast, an agent's shape is decided at runtime by the model [...] The workflow graph is drawn as the agent runs », et la résolution proposée, code non déterministe au premier passage et rejeu déterministe à la reprise, les résultats mémorisés forçant le même chemin. https://www.inngest.com/docs/learn/durable-agents

[29] Jaideep Ray, « The Constraint Tax: Measuring Validity-Correctness Tradeoffs in Structured Outputs for Small Language Models », arXiv:2605.26128, 20 mai 2026 : 15 000 générations sur Qwen2.5-0.5B, Qwen2.5-1.5B et SmolLM2-1.7B ; le décodage sous schéma dur porte la validité structurelle de 61,5 % à 100,0 % et fait baisser l'exactitude de la réponse de 19,7 % à 11,0 %, les sorties fausses mais valides passant de 49,5 % à 88,9 % ; sur un schéma d'appel d'outil (Qwen2.5-1.5B), 91,5 % d'exactitude exécutable par simple consigne contre 48,0 % sous schéma dur, à 100 % de validité dans les deux cas ; motif recommandé « reason free, constrain late ». https://arxiv.org/abs/2605.26128

[30] Mengqi Yuan et alii, « OSWorld 2.0: Benchmarking Computer Use Agents on Long-Horizon Real-World Tasks », arXiv:2606.29537, 28 juin 2026 (v2 du 13 juillet 2026) : 108 flux de travail longs, médiane d'environ 1,6 heure de travail humain par tâche, 318 appels d'outils en moyenne ; sous la métrique principale d'achèvement binaire à 500 étapes, la meilleure configuration testée atteint 20,6 % des tâches pour un score partiel de 54,8 %, GPT-5.5 plafonnant vers 13 %. https://arxiv.org/abs/2606.29537

[31] Paul-Antoine Tual, « Conception agentique : pourquoi Cowork ne construit pas des agents durables », paulantoinetual.fr, 27 août 2026. /blog/cowork-agents-ia-durables

[32] Deloitte, « AI agents are only the beginning: The path to agentic transformation », 11 août 2026 : enquête menée d'avril à juin 2026 auprès de 501 dirigeants américains, toutes les organisations interrogées pilotant au minimum des solutions agentiques, complétée par 20 entretiens. https://www.deloitte.com/us/en/insights/industry/technology/path-to-agentic-transformation.html