J’ai passé la dernière année à assister à des conversations sur le déploiement de l’IA avec des banques, des assureurs, des intégrateurs de systèmes et des challengers digital natives. Pratiquement tous les types d’entreprises imaginables, et j’ai eu une version de cette conversation avec chacune d’entre elles. Cela se déroule généralement de la même façon. Un responsable de la gouvernance de l’IA nous explique ce que ses agents font déjà en production. Les gens hochent la tête. Et puis, à un moment donné, on voit la salle réaliser silencieusement que personne, dans cette pièce, ne peut réellement répondre à une question pourtant assez simple : si cette chose se trompe demain, qui en est responsable, et quelle règle a-t-elle enfreinte ?
Cette question, et non la capacité du modèle, est ce qui va déterminer combien de programmes d’agents IA actuels survivront réellement. Gartner prévoit que plus de 40 % des projets d’IA agentique seront abandonnés d’ici la fin de 2027, et les raisons invoquées ne sont pas « la technologie n’a pas fonctionné ». Ce sont des coûts qui s’envolent, une valeur métier peu claire, et des contrôles des risques insuffisants. Cette troisième raison est celle que personne ne veut mettre sur la diapositive de lancement.
Nous avons commencé à appeler cet élément manquant une Fondation de Processus Agentique. Ce n’est pas ce que le secteur vend actuellement sous le nom de gouvernance de l’IA, car la majeure partie de ce discours porte encore sur la documentation, et la documentation n’a jamais vraiment été le problème.
Tout le monde donne le même conseil, et ce n’est pas tout à fait le bon
En assistant à suffisamment de ces conversations, on entend toujours la même prescription : cartographiez vos processus, documentez vos flux de travail, donnez plus de contexte à l’IA. Rien de tout cela n’est faux en soi. C’est simplement insuffisant, et l’écart ne se révèle que lorsqu’il est déjà devenu un problème.
Une cartographie des processus vous indique ce qui se passe dans un flux de travail. Elle ne vous dit pas ce qui pourrait mal tourner, qui a la responsabilité de l’empêcher, ni quelle réglementation le contrôle en question est censé satisfaire. J’ai vu de bonnes équipes d’ingénierie construire des diagrammes de processus magnifiquement détaillés (le genre que l’on serait fier de présenter à un conseil d’administration), puis confier à un agent ce même processus sans la moindre idée de l’étape nécessitant une seconde signature, ou du montant en dollars qui transforme une transaction de routine en quelque chose devant être signalé. Le diagramme était exact. Il n’était tout simplement pas conçu pour répondre à la question qui comptait.
L’écart n’est donc pas la visibilité, du moins pas celle que la plupart des gens ont en tête lorsqu’ils emploient ce mot. C’est, plus précisément, le contexte de risque et de conformité. Et presque personne parmi ceux à qui je parle ne construit cela délibérément. La plupart des entreprises y arrivent par hasard, si tant est qu’elles y arrivent, après que quelque chose a déjà mal tourné.
J’ai entendu ce concept présenté sous deux étiquettes différentes, et toutes deux méritent d’être nommées, car aucune ne suffit à elle seule.
L’intelligence des processus, le volet Process Mining et analytique de ce marché, vous indique ce qui s’est réellement passé dans un flux de travail : où se situent les goulots d’étranglement, où les exceptions se concentrent, combien de temps les choses prennent réellement une fois qu’on écarte ce que prétend la documentation. C’est certainement utile, et je ne le remets pas en cause. Mais c’est une description du comportement, pas une attribution de responsabilité. Cela vous dit que le processus est lent à l’étape quatre. Cela ne vous dit pas qui est censé être responsable de l’étape quatre, ni ce qui se casse si cette étape est sautée.
Et le contexte de processus, le discours plus récent, celui que j’ai moi-même utilisé, signifie généralement simplement que l’agent reçoit plus d’informations sur le processus avant d’agir. Cela ressemble à un progrès jusqu’à ce que l’on remarque que ces informations ne disent toujours pas qui est responsable de la troisième étape d’approbation, à quel contrôle elle est liée, ni ce qui se passe si elle est mal exécutée.
Les deux vous donnent une image plus intelligente du processus. Aucun des deux, à lui seul, ne vous donne une réponse gouvernée à la question de qui est responsable et de ce qui casse. C’est là le véritable écart, plus étroit et moins spectaculaire que ce que suggère l’une ou l’autre étiquette.
Quel que soit le nom qu’on lui donne, cela doit fonctionner à la même profondeur que l’agent. La plupart des outils de gouvernance d’entreprise ne voient que le sommet de la hiérarchie des processus, pas l’étape enfouie à l’intérieur où l’agent agit.
Les quatre niveaux d’une Fondation de Processus Agentique
En observant suffisamment de ces déploiements, un schéma se dégage. Les entreprises qui réussissent construisent généralement quatre éléments, dans cet ordre. Ce sont les quatre niveaux d’une Fondation de Processus Agentique :
Visibilité. Visibilité sur les risques et les contrôles. Où réside le risque dans un processus, et qui en est responsable.
Priorisation. Priorisation ajustée au risque. Où pointer un agent en premier lieu, simulé sous des contraintes réelles de risque et de contrôle avant que quoi que ce soit n’atteigne la production.
Contexte. Contexte de risque en temps réel. Les risques spécifiques, les contrôles et les responsables associés à l’étape exacte qu’un agent est sur le point d’exécuter, délivrés au moment même où il l’exécute.
Optimisation. Conformité par rapport à la référence approuvée, afin que toute dérive soit détectée comme une dérive, et non comme une constatation d’audit.
L’ordre compte, car chaque niveau dépend du précédent. On ne peut pas ajuster une liste de priorités au risque sans un registre des risques auquel se référer. On ne peut pas donner à un agent un contexte en temps réel qui n’a jamais été consigné par écrit. Et on ne peut pas tester la conformité sans une référence approuvée à laquelle se conformer. Sauter l’un d’eux fragilise discrètement celui qui suit. Ce sont quatre capacités distinctes et séquentielles, pas quatre façons de décrire la même chose.
La visibilité est la première, et elle consiste à disposer d’un endroit où l’on peut réellement consulter où se situe le risque et qui en est responsable. Pas un diagramme, mais quelque chose de plus proche d’un registre des risques avec des noms associés. La plupart des entreprises disposent déjà de cette information. Elle est simplement dispersée dans des feuilles de calcul, des classeurs d’audit, et dans la tête de la seule personne présente depuis quinze ans qui se souvient pourquoi tel contrôle existe. Rien de tout cela n’est interrogeable par un agent avant qu’il n’agisse, ce qui signifie, concrètement, que rien de tout cela ne protège quoi que ce soit. Il vaut la peine de dire clairement à quel point la plupart des entreprises sont en retard sur ce plan : l’enquête State of AI de McKinsey de novembre 2025, portant sur près de 2 000 organisations, a révélé que seulement 23 % faisaient monter en puissance des agents dans au moins une fonction métier, et que 39 % de plus en étaient encore au stade expérimental. Cela représente un grand nombre d’entreprises déployant des agents dans des processus dont le profil de risque n’a jamais été consigné nulle part où un agent pourrait le trouver.
La priorisation vient en second lieu : faire preuve de discipline quant à l’endroit où l’on pointe un agent en premier lieu. Il ne devrait pas s’agir d’un concours de popularité pour le processus qui semble le plus facile à automatiser. Cela devrait impliquer de réellement simuler la façon dont l’agent se comporterait à l’intérieur de ce processus, sous ses contraintes réelles de risque et de contrôle, avant que quoi que ce soit n’atteigne la production. Je vois sans cesse des équipes sauter cette étape et foncer directement vers ce qui est le plus visible plutôt que vers ce qui compte réellement, et ensuite, ce qu’elles n’avaient pas simulé (un chemin d’exception que personne n’avait signalé, un seuil réglementaire enfoui trois étapes plus loin) se manifeste après la mise en production, au pire moment possible pour le découvrir.
Le contexte vient en troisième lieu, et c’est celui qui protège réellement un agent une fois en production : lui fournir les risques spécifiques, les contrôles et les responsables associés à l’étape exacte qu’il est sur le point d’exécuter, précisément au moment où il l’exécute, et non un document plus volumineux à interpréter seul. La réponse réelle, déjà élaborée. C’est aussi là que se situe véritablement la préoccupation des personnes qui pilotent ces programmes. L’enquête Global AI Pulse de KPMG du printemps 2026, qui a porté sur plus de 2 100 dirigeants seniors dans 20 pays, a révélé que près de trois personnes sur quatre sont plutôt ou très préoccupées par la sécurité des données, la confidentialité et le risque. C’est la préoccupation la mieux classée de toute l’enquête, devant le coût, devant les talents, devant presque tout ce dont les gens se soucient à voix haute. Je me souviens d’une conversation avec l’équipe IA interne d’une banque digital native qui avait fini par construire cela elle-même, manuellement, parce que personne ne le lui avait proposé. Quand j’ai demandé pourquoi elle n’avait pas simplement attendu qu’un fournisseur le fasse, la réponse m’est restée en tête : personne d’autre ne semblait résoudre le véritable problème, qui n’a jamais été « donner plus d’informations à l’agent ». C’était « lui donner la bonne information, avec un nom qui y est associé ».
L’optimisation vient en quatrième lieu : vérifier, après coup, si ce qui s’est réellement passé correspond à ce qui était censé se passer. La conformité, en d’autres termes. Comparer l’exécution à la référence de risque approuvée et détecter la dérive avant qu’elle ne se transforme en constatation d’audit, plutôt qu’après. J’ai eu, il n’y a pas si longtemps, une conversation avec quelqu’un d’une institution beaucoup plus ancienne, du genre à posséder un manuel de normes internes de plus de cent pages, qui décrivait passer de véritables heures chaque mois à vérifier manuellement les nouveaux travaux de processus par rapport à ce manuel. Puis, presque avec espoir, cette personne a demandé à être la première sur la liste si quelqu’un automatisait un jour cela. Cette demande en dit long. Quand vos collaborateurs conformité les plus expérimentés se portent volontaires pour tester en avant-première quelque chose qui n’existe pas encore, ce n’est pas un simple « plus » inscrit quelque part sur une feuille de route. C’est un arriéré auquel personne ne s’est encore attaqué.
Même les équipes les plus avisées tombent dans ce piège
Voici la partie qui m’a un peu surpris, pour être honnête. L’erreur que je rencontre le plus souvent ne vient pas des entreprises en retard. Elle vient des équipes les plus avancées de la pièce, celles qui jonglent avec cinq ou six initiatives d’IA à la fois, pleinement convaincues d’avoir déjà résolu la gouvernance parce qu’elles ont résolu la documentation.
Vous entendrez une version de ceci : pourquoi aurais-je besoin de tout cela alors que je peux simplement demander à un modèle généraliste de me dessiner un diagramme de processus à partir d’une description simple ? Une remarque juste, mais qui passe à côté du sujet. Demandez à ce même modèle qui est responsable de la troisième étape d’approbation, ou quelle version d’un contrôle était réellement en vigueur à la date où une décision a été prise, et il n’a rien à répondre. Une image d’un processus n’est pas la même chose qu’un enregistrement gouverné de qui en est responsable. Personne ne remarque la différence pendant des mois. Puis un régulateur ou un auditeur interne pose directement la question, et soudain c’est la seule chose qui compte dans la pièce.
Ce qui est un peu ironique, c’est que les équipes les plus susceptibles de penser que c’est déjà réglé sont généralement celles qui sont les plus exposées si ce n’est pas le cas. Se sentir confiant vis-à-vis de sa pile technologique d’IA et être capable de rendre compte de ce qu’elle fait sont deux choses différentes, et je ne pense pas qu’assez de personnes pilotant ces programmes aient encore fait la distinction.
Vers où cela se dirige
Si je devais parier, je dirais que la conversation sur la gouvernance de l’IA évolue de façon assez significative au cours de l’année à venir, en s’éloignant de « avons-nous une stratégie » pour se rapprocher de « qui valide quand l’agent se trompe ». Je pense qu’elle passera d’une diapositive enfouie dans un dossier de conformité à un sujet que les comités d’audit aborderont systématiquement, un peu comme la cybersécurité il y a environ une décennie. Les conseils d’administration n’ont pas commencé à s’interroger sur la réponse aux violations de données parce que les RSSI amélioraient leurs diapositives. Ils ont commencé à s’interroger parce qu’une poignée d’échecs très médiatisés ont fait paraître imprudent le fait de ne pas poser la question. Je pense que la responsabilité en matière d’IA suit la même trajectoire, simplement plus rapidement, parce que le cycle de déploiement est plus rapide.
Les entreprises qui construisent ces quatre niveaux dès maintenant, avant qu’un membre du conseil d’administration ou un régulateur ne les y oblige, passeront l’année prochaine à livrer. Celles qui attendent la passeront à s’expliquer, après que quelque chose se sera déjà produit, sur les raisons pour lesquelles un modèle qui a fonctionné exactement comme prévu a pris une décision que personne ne peut réellement défendre.
Je pense encore à cette responsable de la gouvernance, en plein milieu de phrase, regardant sa propre équipe réaliser que personne ne pouvait dire qui serait responsable si leur agent se trompait sur le prochain appel. Cela va se produire dans beaucoup plus de salles cette année. Les entreprises qui ont déjà une réponse ne remarqueront même pas que cela se produit. Toutes les autres vont découvrir à leurs dépens que les prochains échecs de l’IA ne seront pas des échecs de modèle. Ce seront des échecs de responsabilité portant le visage d’un modèle.
Daniel Hughes dirige les ventes pour l’Amérique du Nord et le Japon chez iGrafx, où il travaille avec des banques, des assureurs et des entreprises technologiques sur la gestion des risques liés aux agents IA et la gouvernance des processus.
Foire aux questions
Une Fondation de Processus Agentique est la couche de risque et de conformité dont un agent IA a besoin avant de pouvoir agir en toute confiance au sein d’un processus gouverné. Elle comporte quatre niveaux séquentiels : Visibilité, Priorisation, Contexte et Optimisation. Ensemble, ils établissent où réside le risque et qui en est responsable, où pointer un agent en premier lieu, ce que l’agent doit savoir au moment où il agit, et si ce qui s’est passé correspond à ce qui a été approuvé.
Gartner prévoit que plus de 40 % des projets d’IA agentique seront abandonnés d’ici la fin de 2027, en citant des coûts qui s’envolent, une valeur métier peu claire, et des contrôles des risques insuffisants. La troisième raison est celle qui bloque silencieusement les programmes. Une équipe incapable de dire qui est responsable si un agent commet une erreur ne sera pas autorisée à pointer cet agent vers un processus qui compte réellement, si bien que le programme ne quitte jamais le stade pilote.
La responsabilité doit être attribuée avant que l’agent n’agisse, et non déterminée après coup. Dans la plupart des organisations, ce n’est pas le cas. Le responsable du risque pour une étape de processus donnée existe quelque part dans une feuille de calcul, un classeur d’audit, ou la mémoire d’une seule personne, autant d’éléments qu’un agent ne peut interroger avant d’agir. Nommer le responsable désigné pour chaque étape, et rendre cet enregistrement disponible en temps réel, est ce qui transforme la décision d’un agent en une décision que l’organisation peut défendre devant un régulateur ou un auditeur interne.
L’intelligence des processus vous indique ce qui s’est réellement passé dans un flux de travail : où se forment les goulots d’étranglement, où les exceptions se concentrent, et combien de temps les étapes prennent réellement une fois qu’on écarte ce que prétend la documentation. C’est une description du comportement. Une Fondation de Processus Agentique y ajoute l’attribution de la responsabilité, c’est-à-dire quel risque s’applique à une étape donnée, quel contrôle la régit, et qui est responsable du résultat. L’intelligence des processus vous dit qu’une étape est lente. Une Fondation de Processus Agentique vous dit qui est responsable si elle est sautée.