Déployer des agents IA exige de clarifier qui décide

Un agent d’IA opérationnel laisse en suspens les décisions de délégation

Un agent d’IA peut être prêt à agir alors même que l’organisation n’est pas encore prête à autoriser ses décisions. Pour les directeurs des systèmes d’information (DSI) qui font passer les agents à un usage opérationnel, le déploiement consiste donc à décider ce que le logiciel peut faire, quelles instructions il suivra et qui supervisera les conséquences. La réussite technique laisse ces responsabilités à la charge de l’organisation.

Les enjeux augmentent lorsque les agents interprètent des situations incertaines, prennent des décisions et agissent sans qu’une personne intervienne à chaque étape. Ces workflows autonomes permettent au logiciel d’exécuter des tâches de manière indépendante. À mesure que les organisations passent des expérimentations à des décisions opérationnelles déléguées, la plupart des dirigeants commencent à peine à traiter les responsabilités que crée l’action indépendante.

IBM, qui a un intérêt commercial à ce que les organisations adoptent l’IA, a publié des résultats qui montrent l’ampleur de cet écart de préparation. Dans une étude, seuls 11 % des DSI et des directeurs technologiques (CTO) se considéraient comme pleinement préparés à l’ampleur du déploiement d’agents anticipée au cours des 12 mois suivants. Plus des trois quarts des organisations interrogées dans cette même étude ont indiqué que l’adoption de l’IA dépassait leur capacité à la gouverner. Le premier constat mesure le niveau de préparation des dirigeants ; le second met en évidence une insuffisance organisationnelle dans la définition et l’application des règles d’usage de l’IA.

Définir ce qu’un agent peut faire

Combler cet écart commence par décider quelles actions un agent peut entreprendre. Un agent peut être capable d’envoyer un e-mail, de modifier un enregistrement, de lancer un workflow ou d’escalader un incident, mais chaque action soulève une question d’autorisation différente. Les DSI doivent donc passer de « Peut-il faire cela ? » à « Doit-il pouvoir le faire, et dans quelles conditions ? » La réponse fixe les limites du pouvoir discrétionnaire de l’agent.

Ces limites doivent refléter le contexte métier de chaque action. L’organisation doit identifier ce que l’agent peut faire, décider si chaque action est autorisée et préciser les éventuelles conditions ou exigences d’approbation humaine. Le résultat se répartit en trois catégories : le travail qui peut se poursuivre de manière autonome, le travail nécessitant une revue humaine et le travail excluant toute participation de l’agent. Chacune donne à l’agent une règle claire lorsqu’il choisit et exécute une action.

Un agent de gestion des incidents illustre la manière dont ces catégories peuvent fonctionner au sein d’un même processus. Une organisation pourrait autoriser l’agent à évaluer une alerte et à l’acheminer vers l’équipe appropriée de manière indépendante, car ces activités permettent de déterminer ce qui requiert une attention et où cela doit être traité. Son autorité indépendante s’arrêterait avant toute modification du service concerné. La remédiation, c’est-à-dire l’action visant à résoudre un incident affectant les clients, exigerait une autorisation humaine, car elle modifie la situation opérationnelle.

La communication nécessiterait une règle distincte au sein de ce même workflow. L’agent pourrait être capable de rédiger et d’envoyer un message au sujet de l’incident, mais toute communication externe exigerait une validation humaine selon cette politique illustrative. L’évaluation, l’acheminement, la remédiation et la communication auraient donc des exigences d’approbation distinctes, même si l’agent pouvait techniquement exécuter les quatre. Les organisations pourraient choisir des limites différentes ; chacune devrait les établir avant de s’appuyer sur une exécution autonome.

La même responsabilité s’applique lorsqu’une organisation acquiert un agent développé en externe. Ses fonctions doivent toujours s’inscrire dans le cadre d’autorisations de l’organisation, puisque ces fonctions ne peuvent pas déterminer l’autorité appropriée à une activité donnée. Les DSI restent responsables de la définition de ces limites en parallèle de la performance du système. Acheter la technologie laisse à l’organisation le soin de décider comment elle peut être utilisée.

Documenter le travail avant de demander aux agents de l’exécuter

L’application de ces autorisations exige une description claire du travail lui-même. Certains workflows reposent sur des connaissances détenues par des employés particuliers, des habitudes non écrites et des transferts informels de responsabilité entre équipes. Les personnes peuvent comprendre suffisamment ce contexte pour faire avancer le travail, alors qu’un agent a besoin d’instructions explicites et de limites de décision. Même un modèle sophistiqué avec un prompting efficace ne peut pas compenser l’absence d’accord au sein de l’organisation sur la manière dont son processus doit fonctionner.

Rendre cet accord explicite commence par documenter les étapes et la manière dont la responsabilité passe d’un participant à l’autre. L’organisation doit ensuite standardiser suffisamment le travail pour que le logiciel puisse le suivre de manière cohérente. Cela donne à l’agent à la fois le contexte nécessaire à ses décisions et des limites à son comportement. Des instructions claires favorisent une exécution plus rapide et plus fiable, car le processus requis est déjà établi.

La cohérence devient plus importante à mesure que le déploiement s’étend et que le travail se répète. Lorsque les équipes s’appuient sur des interprétations non écrites différentes, l’extension du déploiement intègre ces écarts dans la mise en œuvre. Les organisations disposant de processus documentés peuvent ainsi prendre l’avantage sur des concurrents dont le travail reste défini de manière moins cohérente. La conception des processus mérite une attention comparable à celle de l’architecture technique, car elle détermine si l’organisation peut expliquer le travail avec suffisamment de clarté pour que le logiciel l’exécute.

Préparer cette explication peut aussi révéler des faiblesses opérationnelles présentes depuis des années. Le déploiement d’agents donne aux organisations une raison de résoudre des responsabilités floues et des transferts informels que les employés géraient par l’expérience. Combler ces lacunes améliore le processus pour les personnes qui continuent à exécuter et à superviser le travail. La documentation favorise donc une exécution fiable par les agents et améliore les opérations par le seul fait de cette préparation, même si le déploiement exige toujours des capacités, des autorisations et une supervision adaptées.

Une livraison plus rapide rend cette préparation plus urgente. Les grands projets systèmes pouvaient prendre 18 mois, avec des bénéfices difficiles à quantifier, tandis que les initiatives d’IA agentique peuvent être lancées et affinées en l’espace d’un trimestre, avec des résultats visibles presque immédiatement. Des cycles plus courts permettent aux équipes d’observer et d’améliorer plus tôt l’usage opérationnel, mais ils laissent aussi moins de temps pour régler les questions de processus et de gouvernance pendant la mise en œuvre. Les organisations doivent donc établir le workflow et ses autorisations suffisamment tôt pour orienter ces premières décisions opérationnelles.

Définir l’autonomie en fonction des conséquences métier d’un échec

Un workflow documenté établit ce qui doit se produire ; les conséquences d’un échec déterminent le degré de liberté que l’agent doit recevoir en son sein. Les DSI doivent identifier où l’action indépendante crée de la valeur et mettre cette valeur en balance avec les effets d’une erreur. Cela exige une connaissance détaillée des opérations métier, car la seule capacité technique ne peut pas révéler l’ampleur des perturbations qu’une décision pourrait provoquer.

Une recommandation incorrecte dans un workflow interne peut causer un désagrément, tandis qu’un jugement erroné lors d’un incident client grave peut nuire à la confiance, interrompre les opérations et créer une exposition métier importante. Même à capacités équivalentes, ces conséquences justifient des autorisations différentes. Dans l’exemple de gestion des incidents, cela explique pourquoi la remédiation affectant les clients et la communication externe exigent des autorisations distinctes. Le niveau de supervision doit correspondre au risque associé au travail confié.

L’évaluation de ce risque rend la compréhension métier de plus en plus importante pour la direction des DSI. Les DSI doivent comprendre suffisamment bien les opérations pour déterminer où l’autonomie produit de la valeur et où les risques l’emportent, tout en continuant à fournir une infrastructure fiable, des systèmes sécurisés, une architecture technique solide, la stabilité des services et une livraison prévisible. La gouvernance dépend de systèmes fiables, et ces systèmes ont toujours besoin de limites claires quant à leur autorité. Ensemble, ces responsabilités relient la performance technique aux conséquences métier de l’exercice du jugement par le logiciel.

Préparer les employés à la supervision et au traitement des exceptions

Ces limites créent du travail pour les employés chaque fois qu’un agent doit attendre une approbation ou a besoin d’aide face à une exception, c’est-à-dire une situation nécessitant une intervention en dehors de l’exécution courante. À mesure que les agents prennent en charge les étapes routinières, les personnes consacrent davantage de temps au suivi des résultats et au traitement de ces cas. Les employés doivent donc comprendre ce que l’agent était censé faire et reconnaître quand un résultat requiert une attention. L’exécution autonome modifie l’endroit où se situe la responsabilité humaine dans le workflow.

Ce changement peut freiner un déploiement même lorsque la technologie fonctionne correctement. Un agent peut dépendre d’employés chargés de revoir des décisions ou de répondre à des exceptions, alors que ces employés peuvent ne pas être préparés à leurs nouvelles missions. La mise en œuvre technique doit donc avancer en parallèle de la conduite du changement et de la préparation de la main-d’œuvre. Les équipes ont besoin de temps pour s’adapter pendant la mise en œuvre afin que les personnes responsables de l’intervention soient prêtes lorsque l’usage opérationnel commence.

Préparer ces équipes signifie considérer chaque exigence de revue humaine comme une responsabilité opérationnelle continue. Les employés doivent être capables de superviser les résultats, de gérer les situations nécessitant une intervention et d’assumer les responsabilités qui leur sont attribuées lorsque l’agent atteint une limite de décision. Établir une règle de revue humaine engage l’organisation à mettre à disposition des personnes capables de l’appliquer pendant toute la durée de fonctionnement de l’agent.

Points clés

Définir les autorisations des agents : les DSI doivent classer les actions comme autonomes, soumises à une approbation humaine ou exclues de la participation de l’agent. Appliquez ces limites aux agents développés en interne comme à ceux acquis en externe avant tout usage opérationnel.
Documenter les workflows avant le déploiement : les responsables de processus doivent expliciter les étapes, les transferts et les limites de décision afin que les agents puissent exécuter de manière cohérente. Des cycles de déploiement plus rapides rendent indispensable la résolution précoce des responsabilités floues.
Adapter l’autonomie au risque métier : les DSI doivent évaluer les conséquences d’une erreur pour chaque action confiée. La remédiation orientée client et la communication externe justifient des exigences d’approbation différentes de celles de l’évaluation interne et de l’acheminement.
Préparer les employés à la supervision : chaque exigence de revue humaine crée une responsabilité opérationnelle continue. Préparez les employés chargés des approbations, du suivi des résultats et du traitement des exceptions en parallèle de la mise en œuvre technique.