Processus agentiques et interfaces de demain

La thèse en une phrase. Quand l’IA produisait des réponses, la conversation suffisait comme interface ; dès lors qu’elle exécute des processus, l’interface utile devient un poste de pilotage, et la fiabilité devient une question d’architecture avant d’être une question de modèle.

Règle de sourcing. Chaque affirmation porte une source datée, vérifiée en primaire. Les documentations vivantes sont citées à leur date de consultation. Aucune source de marché antérieure à février 2026 n’est utilisée comme état de l’art ; les documents normatifs plus anciens sont cités avec leur date. Ce livre blanc fait suite à Maturité IA des PME françaises et à Du POC à l’industrialisation : il constitue le troisième volet de la collection Méthode Junyr™.

1. Le goulot d’étranglement est désormais la décision

Ce qui change. Les mêmes modèles qui rédigeaient enchaînent désormais des actions dans le système d’information : lire une base, appeler une interface de programmation, écrire un brouillon, déclencher une notification.

Les trois conséquences, et elles sont exclusives l’une de l’autre.

• Sur la valeur. Ce qu’il faut outiller cesse d’être la génération de l’artefact pour devenir la décision qui l’autorise. Quand un agent rédige quarante relances en une minute, relire les quarante ne passe pas à l’échelle, alors qu’approuver le plan de relance reste tenable.
• Sur la fiabilité. Elle se conçoit dans l’enchaînement des étapes, avant de dépendre du modèle employé.
• Sur l’interface. Elle cesse d’être un endroit où l’on demande pour devenir un endroit où l’on décide, où l’on constate, et où l’on reprend la main.

La preuve par le chiffre. Nous avons mesuré cette bascule sur un registre de dix-sept jours de travail réel : 565 plans écrits, 477 livrés, 31 abandonnés dont 26 avant qu’une ligne de code ne soit écrite (Le développement à décision gardée). Ces 26 abandons sont le rendement le plus honnête de la méthode : un travail qui n’a pas eu lieu parce qu’on a compris à temps qu’il ne fallait pas le faire.

2. Skill et workflow : deux objets, deux promesses

Le point à retenir. La confusion la plus coûteuse rencontrée en entreprise porte sur deux objets que le vocabulaire courant mélange.

Une skill est une tâche réutilisable confiée au jugement du modèle.

• Forme : un dossier organisé autour d’un fichier SKILL.md, dont l’en-tête ne comporte que deux champs obligatoires, un nom et une description.
• Portabilité : format lancé le 16 octobre 2025, publié comme standard ouvert le 18 décembre 2025, reconnu par la documentation officielle d’OpenAI, de Microsoft et de Google ; 46 produits compatibles au 30 août 2026.
• Ce qu’elle garantit : la réutilisation d’un savoir-faire, révisable par le métier plutôt que par un développeur.
• Ce qu’elle laisse ouvert : le moment de son déclenchement, et l’identité de deux résultats successifs.
• La preuve, écrite par le standard lui-même : la procédure de test officielle demande d’exécuter chaque cas trois fois et retient un taux de déclenchement supérieur à 0,5, au motif que le comportement du modèle est non déterministe.

Un workflow agentique est un enchaînement décidé par du code.

• Forme : boucles, filtres, jointures, conditions et reprises écrites une fois et versionnées.
• Ce qu’il garantit : l’enchaînement lui-même, rejouable et testable.
• La confirmation de l’éditeur : la documentation de Claude Code répond, à la question de savoir ce qui est réutilisable, « les instructions » pour une skill et « l’orchestration elle-même » pour un workflow.

Les trois seules opérations qu’il est rationnel de confier à un agent dans un enchaînement.

• Analyser : lire du non structuré et en extraire une information exploitable.
• Synthétiser : réconcilier des sources divergentes et hiérarchiser ce qui compte.
• Présenter : mettre en forme pour un destinataire donné.

Tout le reste relève du code, parce que compter, trier, joindre, plafonner ou écrire en base admettent une seule réponse juste. Développement complet, avec un exemple de processus en sept étapes dont trois font appel à un agent : Processus agentiques d’entreprise.

3. Chaque nœud non déterministe ajouté divise la fiabilité de l’ensemble

Le calcul. À 95 % de réussite par étape et sous hypothèse d’indépendance, une chaîne de vingt étapes réussit de bout en bout dans 36 % des cas ; ramenée à trois étapes non déterministes, elle remonte à 86 %. Aucun modèle n’a été amélioré entre les deux valeurs.

La correction honnête. L’hypothèse d’indépendance est fausse, et l’écart se mesure.

• Sur le banc d’essai Toolathlon, 108 tâches réelles exposant plus de 600 outils à travers 32 applications, le meilleur modèle de juillet 2026 réussit 80,6 % des tâches à la première tentative et 73,1 % trois fois de suite, quand l’indépendance prédirait 52,4 % (Anthropic, System Card: Claude Opus 5, 24 juillet 2026, §8.13.6).
• La multiplication des probabilités constitue donc une heuristique de pire cas plutôt qu’une loi.
• Le sens de la pente, en revanche, ne dépend d’aucune hypothèse.

L’état réel d’un agent laissé seul sur un processus d’entreprise. AutomationBench, publié le 21 avril 2026 par deux chercheurs de Zapier, place l’agent dans une entreprise simulée traversant 47 applications, sur des flux tirés de clients réels en vente, marketing, opérations, support, finance et ressources humaines.

• Avril 2026 : les meilleurs modèles de pointe passent sous la barre des 10 %.
• Juillet 2026 : le meilleur atteint 26,0 % (System Card: Claude Opus 5, §8.13.7).
• Lecture : le progrès est rapide, et trois processus métier réalistes sur quatre échouent encore sans encadrement.

4. Quatre gestes de génie logiciel suffisent à rendre un processus tenable

Le principe. Le génie logiciel est la seule discipline qui dispose de cinquante ans d’expérience de la délégation d’exécution à des systèmes. Aucun des quatre gestes ci-dessous ne s’obtient en améliorant la rédaction d’une consigne.

1. Déclarer l’idempotence plutôt que l’espérer.

• Le schéma officiel du protocole MCP prévoit quatre annotations par outil : lecture seule, caractère destructeur, idempotence, monde ouvert.
• Par défaut, un outil non documenté est réputé destructeur et non idempotent.
• La spécification impose de considérer ces annotations comme non fiables hors serveur de confiance.
• Les mainteneurs du protocole, le 16 mars 2026 : un serveur peut annoncer une opération en lecture seule et supprimer malgré tout des fichiers, les garanties réelles devant vivre dans des contrôles déterministes.

2. Valider les sorties par machine.

• Le protocole permet de publier un schéma de sortie : le serveur doit produire un résultat conforme, le client devrait le valider.
• Anthropic recommande un motif en cinq temps pour les opérations par lots, les changements destructeurs et les enjeux élevés : analyser, produire un fichier de plan, valider ce plan par un script, exécuter, vérifier.

3. Construire les évaluations avant d’en avoir besoin.

• La même documentation pose que les évaluations sont la source de vérité, et qu’aucun moyen intégré ne permet aujourd’hui de les exécuter.
• À porter au budget du projet, pas à sa surprise : sans jeu de cas de référence, une régression ne se constate pas.

4. Inscrire la boucle humaine et la trace dans le code.

• La révision du 28 juillet 2026 de la spécification MCP demande qu’un humain puisse toujours refuser une invocation d’outil.
• Elle demande aux clients de présenter les entrées avant l’appel, de confirmer les opérations sensibles, d’imposer des délais d’expiration et de journaliser à des fins d’audit.

La sécurité aboutit à la même conclusion par un autre chemin.

• L’édition 2026 du Top 10 de l’OWASP, publiée début août sur 7 714 incidents réels dont 6 639 classés, fait accéder l’excès d’autonomie à la troisième place, les dégâts atterrissant dans les déploiements agentiques.
• Sa lettre d’ouverture vaut cahier des charges : cessez d’essayer de construire un modèle qu’on ne puisse pas tromper, construisez le système autour de lui de sorte que rien d’important ne casse lorsqu’il le sera.
• L’ANSSI formulait la même règle le 29 avril 2024 : proscrire l’usage automatisé pour les actions critiques, limiter les actions déclenchées à partir d’entrées non maîtrisées.

La mesure qui tranche, et sa nuance. Sur NetInjectBench, 240 cas d’attaque publiés le 11 juillet 2026 :

Appliqué sans discernement, le déterminisme détruit le service qu’il prétend protéger.

5. La conversation ne peut pas porter un processus d’entreprise

La distinction utile. Les outils conversationnels sont excellents pour la transformation, et nous les employons massivement en formation. Ils ne constituent pas des outils d’automatisation, pour deux familles de raisons distinctes.

Raison d’infrastructure : trois couches instables. Détail dans Conception agentique.

• Le harnais logiciel qui entoure le modèle évolue par livraisons quotidiennes.
• Le modèle est soumis à une politique de retrait avec préavis minimal.
• Les connecteurs restent gérés par des tiers, le protocole prévoyant nativement des outils variant d’une session à l’autre.

Raison d’ergonomie : quatre propriétés manquantes. Détail dans Le conversationnel ne saurait devenir une interface de travail. Une conversation ne dit pas :

• ce qui est en attente de décision ;
• ce qui a échoué, et à quelle étape ;
• ce qui fait trace opposable ;
• ce qu’un tiers peut reprendre.

Ce sont exactement les quatre propriétés qu’un processus d’entreprise exige.

6. La dispersion des surfaces précède les agents et les aggrave

• Le constat mesuré : sur 874 conversations métier réelles analysées, deux tiers de l’e-mail dit utile sont substituables par des surfaces mieux conçues (La fin des e-mails et des suites Office d’ici 2030).
• L’effet des agents : ils ajoutent une surface de plus plutôt qu’ils n’en retirent.
• Le symptôme : des validations réparties entre une fenêtre de conversation, une boîte de réception et un outil métier, sans qu’aucune ne détienne l’état complet.

7. Le poste de pilotage repose sur quatre propriétés

L’expérience de référence. Nous avons retiré Git d’un produit en production pour le remplacer par un registre d’intentions, avec deux tables, six états et un point de validation humaine unique (Nous avons retiré Git).

Les quatre propriétés, qui découlent une à une des quatre gestes de la section 4.

• Une file de ce qui attend une décision, ordonnée et partagée, plutôt que des demandes dispersées dans des fils individuels.
• Un registre des autorisations, qui répond aux trois questions qu’un dirigeant doit pouvoir poser : où est la liste de ce que les agents ont le droit de faire, qui a signé chaque autorisation, qu’est-ce qui vérifie l’exécution.
• Un journal en ajout seul, qui fait foi et rend la trace opposable.
• Une reprise explicite, qui indique à quelle étape l’enchaînement s’est interrompu.

Le test de maturité. Une organisation qui répond « c’est dans l’historique de la conversation » à la question du registre a un problème de gouvernance plutôt qu’un problème d’outillage.

8. L’interface générative : une proposition de conception, trois limites

Statut de la source. Une étude de conception menée pour nos travaux propose une plateforme d’exécution stratégique associant humains et agents, organisée en quatre zones : contrôle multi-échelle, canevas du workflow, panneau de gouvernance, console de supervision. Nous la présentons pour ce qu’elle est, une proposition d’architecture, sans mesure ni test d’usage.

Les trois idées qui répondent à un problème identifié plus haut.

• Le continuum d’abstraction : l’option stratégique, la feuille de route et le graphe d’exécution sont la même chose vue à trois échelles, avec un curseur qui ajuste la densité et regroupe les sous-ensembles au-delà du seuil de lisibilité. Réponse au fait qu’un comité de direction et une équipe d’exécution ne regardent pas le même niveau.
• La comparaison visuelle entre plan et exécution réelle : superposer l’enchaînement prévu et celui que les agents ont parcouru rend visible la vérification outillée de la section 4.
• La fiche de porte d’approbation : un résumé d’intention en une phrase, un niveau de risque affiché, le détail technique en second niveau, un plan de secours prévalidé. C’est le point de validation humaine rendu utilisable par quelqu’un qui n’a pas écrit le processus.

Les trois limites, à porter avec la même clarté.

• Aucune mesure d’usage ni de coût n’accompagne la proposition.
• Elle suppose le processus déjà écrit sous forme de graphe : elle décrit l’interface d’un processus mûr, pas le chemin pour y parvenir.
• Elle nomme sans le traiter le risque le mieux documenté du dispositif, la validation passive. Le Top 10 de l’OWASP recommande de présenter à l’approbateur l’action rendue exactement plutôt qu’un résumé, en relevant que la fatigue de consentement dégrade le jugement dès que le volume augmente.

9. La règle de validation appartient au code

• Le principe : le garde-fou vit dans le code plutôt que dans la consigne (Ingénierie des systèmes agentiques).
• La raison : une validation qui dépend de la bonne volonté d’un agent est une validation que le système peut contourner ; une validation inscrite dans le code est une fonction que le système n’expose pas.
• La ligne de partage utile sépare le réversible de l’irréversible, plutôt que le sensible de l’ordinaire.
• La formulation de l’OWASP, sous le nom de médiation complète : implémenter l’autorisation dans la logique du programme, avec une politique graduée qui laisse s’approuver ce qui est récupérable et route vers une revue humaine ce qui ne l’est pas.

10. Trois paliers d’usage, cinq conditions de passage

L’échelle d’usage de la Méthode Junyr™. Chaque palier se caractérise par ce que la machine exécute seule et par le moment où l’humain engage l’entreprise.

Les cinq conditions de l’autonomie encadrée, cumulatives.

• Un décideur humain identifié et unique par périmètre d’engagement.
• Une revue d’artefact déjà remplacée par des vérifications exécutables.
• Un fonctionnement en zone de préparation avec retour arrière éprouvé.
• Un filet de vérification dense, testé sur données réelles.
• Des sauvegardes testées, pas supposées.

Tant qu’une condition manque, le processus reste au palier supervisé. Savoir quels processus ne seront jamais candidats à l’autonomie fait partie de la compétence attendue d’un chef de projet de transformation.

11. Onze disciplines du génie logiciel se transposent une à une

Le motif à connaître. 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 pour les agents, dépôt créé le 5 mai 2026, portent le statut Development, dont la définition indique que le composant ne devrait pas être utilisé en production.
• Les 12-Factor Agents, cadre le plus étoilé de GitHub, dont le facteur 8 s’intitule « possédez votre flux de contrôle », n’ont reçu aucun commit de contenu depuis le 21 septembre 2025.

12. L’accompagnement se conduit sur deux plans et à quatre cadences

Un point de départ commun, celui de la Méthode Junyr™. Une séance de cadrage, puis une journée de diagnostic scindée en deux demi-journées à interlocuteurs et livrables différents : le matin le cadrage avec la direction, l’après-midi la mise en pratique avec les équipes sur données réelles.

Deux plans menés de front.

• Plan stratégique : revue de direction mensuelle. Avancement au regard de la feuille de route, arbitrages de périmètre, priorisation du chantier suivant, décisions d’investissement. Compte rendu écrit à chaque revue.
• Plan opérationnel : sessions courtes et régulières avec les équipes. Déblocage, revue des choix d’implémentation, correction de trajectoire avant sédimentation des habitudes.

Quatre cadences, mêmes briques. Seule la fréquence du plan opérationnel change : deux sessions par mois pour installer la méthode, une par semaine pour le rythme de croisière, deux par semaine pour une phase de construction intensive, ou aucune cadence imposée. Le changement se fait à chaque fin de mois.

Ce que le marché confirme. Une étude Deloitte du 11 août 2026, menée d’avril à juin auprès de 501 dirigeants dont toutes les organisations pilotaient au minimum des solutions agentiques :

• 15 % seulement ont atteint une adoption multi-agents orchestrée à l’échelle.
• Sur sept dimensions de préparation, les processus métier arrivent au dernier rang à 21 %, derrière la vision stratégique, l’infrastructure technique, le socle de données, la gouvernance, les partenariats et les effectifs.
• Causes nommées, dans l’ordre : processus mal documentés et mal compris, données et systèmes fragmentés, habitudes de travail installées.
• Lecture : la dimension la moins prête est celle qui ne suppose ni licence ni serveur.

13. Le premier livrable prend la forme d’une liste numérotée

Les trois questions à poser à chaque étape, dans cet ordre.

1. Cette étape admet-elle une seule réponse juste, contrôlable par quelqu’un d’autre ? Si oui, elle revient au code. Cette question retire en général la moitié des étapes au domaine du jugement, et c’est pourquoi elle vient en premier.
2. Suppose-t-elle de lire du non structuré, de réconcilier des sources divergentes ou de mettre en forme pour un destinataire ? Si non, il s’agit d’une décision de gestion à trancher une fois en amont, puis à figer en constante du code.
3. Sa sortie déclenche-t-elle une action irréversible ou visible d’un client ? Si oui, l’agent reste en place et une validation humaine s’intercale, écrite dans le code.

Les quatre critères de choix du premier processus, cumulatifs.

• Déjà décrit noir sur blanc.
• Exécuté au moins chaque semaine.
• Mesurable en temps passé.
• Sans effet irréversible sur un client dans sa première version.

Trois candidats habituels : la relance des devis sans réponse, le tri des demandes entrantes, la préparation d’un comité mensuel.

Le coût du livrable : une demi-journée, sans outil et sans budget. Il indique ensuite, sans discussion possible, combien de tirages non déterministes l’entreprise s’apprête à empiler et lesquels elle peut retirer.

14. Trois objections que nous prenons au sérieux

1. La forme d’un enchaînement agentique n’est pas toujours connue à l’avance.

• Inngest : un graphe de workflow a une forme connue à la conception, la forme d’un agent est décidée à l’exécution par le modèle.
• Notre réponse : ce qu’il faut garantir concerne moins la connaissance préalable du graphe que sa capacité à être rejoué.
• Observation de terrain : la plupart des processus qu’une organisation automatise en premier ont bel et bien une forme connue.

2. Contraindre une sortie par un schéma coûte de l’exactitude si on le fait au mauvais moment.

• Un travail du 20 mai 2026 sur 15 000 générations : le schéma dur au décodage porte la validité de la structure de 61,5 % à 100 % et fait baisser l’exactitude de la réponse de 19,7 % à 11,0 %.
• Réserve de l’auteur : petits modèles uniquement, aucune extrapolation.
• Le principe que nous retenons : raisonner librement, contraindre tard.

3. Les chercheurs qui mesurent les agents sur des tâches longues ne concluent pas comme nous.

• OSWorld 2.0, 28 juin 2026 : 108 flux de travail demandant à un humain une heure trente-six en médiane, meilleure configuration à 20,6 % d’achèvement complet pour un score partiel de 54,8 %.
• Leur diagnostic porte sur la tenue de route plutôt que sur la capacité brute, et ils appellent à de meilleurs agents là où nous concluons à un squelette extérieur.
• Les deux lectures tiennent ensemble : le squelette permet d’exploiter des agents cette année, de meilleurs agents repousseront la frontière l’an prochain, et aucune des deux ne dispense de savoir où elle passe aujourd’hui.

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