Responsabilité de l’IA : garder la main en entreprise
L’IA peut exécuter des tâches, pas porter leurs conséquences. Méthode pour définir les contrôles, responsabilités et compétences à garder en entreprise.
Déléguer à l'IA sans déléguer la responsabilité
Confier davantage de tâches à l'intelligence artificielle ne consiste pas seulement à automatiser. Cela veut aussi dire transférer des décisions - parfois à des agents capables d'agir dans les outils de l'entreprise. Un courriel envoyé à un client, une réponse dans un dossier, ou une étape qui se déclenche dans un processus : tout cela peut engager l'organisation. L'efficacité gagnée n'efface donc pas la question centrale : qui répond du résultat ?
À l'événement UiPath FUSION, organisé à Dubaï le 2 novembre 2026, Daniel Dines, fondateur et directeur général de l'entreprise, a défendu une idée simple. Oui, les organisations vont donner plus de place à l'IA. Mais elles devront aussi garder des humains pour la piloter et répondre de ce qu'elle fait. Il a également mis en garde contre le recours à l'IA quand un logiciel classique, testable et prévisible, suffit.
Ces positions invitent à sortir du débat « automatiser ou non ». Il faut décider quoi déléguer, quels contrôles conserver et quelles compétences développer. Voici une méthode pour faire ces choix, sans confondre autonomie technique et responsabilité réelle.
Pourquoi l'autonomie de l'IA ne transfère-t-elle pas la responsabilité ?
L'autonomie d'un système décrit ce qu'il peut faire sans intervention immédiate. Elle ne dit pas qui a décidé de lui confier la tâche, qui a fixé ses limites, ni qui a validé son accès aux outils. Or, dans une entreprise, ces choix ont des conséquences opérationnelles et commerciales.
Un agent qui répond à un client ne fait pas que « produire du texte ». Il peut promettre un délai, interpréter une règle interne ou déclencher des actions derrière le rideau.
À Dubaï, Daniel Dines a insisté sur ce point : dès qu'une entreprise donne à l'IA la capacité d'agir, quelqu'un doit répondre de ses actes. Il avait déjà présenté trois limites de l'IA lors du lancement de Cartographer, à Las Vegas, en septembre : elle ne progresse pas « toute seule » comme le ferait un salarié au quotidien, elle n'est pas exacte en permanence, et le fait qu'elle agisse ne rend pas l'entreprise responsable de ses effets.
L'erreur n'est pas seulement une mauvaise réponse
En conversation, une réponse incorrecte se remarque assez vite - avant d'être utilisée. Dans un processus automatisé, une erreur peut se propager. Un agent lit une donnée ambiguë, applique une règle inadaptée, envoie un message, puis met à jour un dossier. Le problème ne tient alors plus seulement à la qualité du texte, mais à l'enchaînement d'actions et à la difficulté de revenir en arrière.
La vraie question n'est donc pas « l'IA est-elle fiable ? », au sens général. Il faut demander : qu'est-ce qu'elle peut déclencher, avec quelles données, sous quelles limites, et avec quel mécanisme d'arrêt ? Un agent qui prépare un brouillon ne comporte pas le même risque qu'un agent qui envoie une réponse, accorde un remboursement ou modifie un dossier client.
Distinguer exécution, validation et responsabilité
Dans une organisation, il est utile de séparer trois rôles :
- L'exécution : l'IA prépare, classe ou réalise une opération prévue.
- La validation : une personne (ou un contrôle automatisé) vérifie avant toute action sensible.
- La responsabilité : un responsable métier assume la décision de déployer le système et les règles qui encadrent son usage.
Ces rôles peuvent ne pas être tenus par trois personnes différentes. Mais ils doivent être identifiables. Si une réponse erronée est envoyée, l'équipe doit pouvoir retrouver le processus concerné, les règles appliquées et la personne qui supervise. Sans traçabilité, la responsabilité humaine reste un slogan.
Qui doit répondre des actions d'un agent IA ?
La responsabilité doit être définie au niveau du processus, pas « à la fin », chez la personne qui a touché l'outil. Dans une entreprise, un agent n'est presque jamais isolé : il s'appuie sur des données, des consignes, des logiciels et des règles métier. La question à garder en tête est donc simple : qui a autorisé chaque étape de cette chaîne, et qui peut intervenir si le résultat dérape ?
Pour une tâche à faible conséquence, un contrôle par échantillonnage peut suffire. Pour une action qui engage l'entreprise, modifie un droit ou affecte un client, une validation avant exécution est souvent nécessaire. Le niveau de contrôle doit suivre le risque, pas l'« effet nouveauté » de la technologie. Un agent qui rédige une note interne et un agent qui communique une décision à un usager ne devraient pas avoir les mêmes permissions.
Construire une chaîne de responsabilité concrète
Avant le déploiement, documentez au minimum :
- Le propriétaire métier : la personne qui justifie l'automatisation et fixe son périmètre.
- Les actions autorisées : ce que l'agent peut lire, rédiger, envoyer ou modifier.
- Les points de validation : dans quels cas une approbation humaine est obligatoire.
- Les règles d'escalade : ce qui doit être transmis à un humain quand c'est ambigu, hors périmètre ou à fort impact.
- La procédure de reprise : comment arrêter l'agent, corriger une action et prévenir les personnes concernées.
Cette chaîne ne doit pas rester dans une slide de gouvernance. Elle doit vivre dans le quotidien. Si le responsable métier ne sait pas comment suspendre une automatisation, ou si les équipes ne savent pas à qui signaler un comportement anormal, la responsabilité est mal rangée.
Un exemple : un agent qui répond aux clients
Prenons un agent chargé de répondre aux demandes de suivi d'une entreprise française. Il peut retrouver un statut dans un système et préparer une réponse. Il ne devrait pas, pour autant, avoir la main pour promettre un remboursement, modifier une adresse ou annoncer une date de livraison que les données ne garantissent pas.
Une mise en œuvre prudente commence avec un périmètre limité : l'agent répond automatiquement aux demandes simples, puis transmet les cas ambigus à un conseiller. Les sources consultées, les exceptions et les formulations retenues doivent être conservées, pour qu'on puisse analyser les erreurs. Ensuite seulement, l'équipe élargit les permissions - après avoir mesuré les erreurs et les escalades.
Dans un cadre européen, il faut aussi tenir compte des obligations applicables, notamment sur les données personnelles et la protection des consommateurs. Le RGPD ne se « remplace » pas par une validation humaine improvisée : il faut examiner les données utilisées, les accès, et le traitement avec les bonnes fonctions de l'organisation.
Quand faut-il préférer un logiciel classique à l'IA ?
Une tâche peut être confiée à l'IA sans pour autant devoir l'être. C'est l'un des points martelés par Daniel Dines à Dubaï. Quand une règle est claire et qu'une opération doit donner le même résultat à chaque exécution, un logiciel classique est souvent plus simple à tester, à expliquer et à maintenir.
Cette approche marche particulièrement bien dans les processus répétitifs : calculer un montant à partir de règles connues, vérifier qu'un champ est présent, appliquer une condition déterministe, ou transférer une donnée d'un système à un autre. Si le résultat attendu peut être décrit sans ambiguïté, un programme traditionnel évite d'introduire de la variabilité liée à un modèle génératif.
Réserver l'IA aux tâches où elle apporte une vraie différence
L'IA peut être utile quand le travail implique des contenus non structurés ou des variations difficiles à gérer uniquement avec des règles manuelles : résumer un échange, extraire des informations d'un document, classer une demande, ou proposer une première version. Même dans ces cas, il faut juger la qualité sur des exemples représentatifs et prévoir une façon de corriger quand ça dérape.
Un cadre de décision pratique consiste à regarder quatre points :
- La stabilité de la règle : la tâche suit-elle des conditions précises et répétables ?
- La tolérance à l'erreur : que se passe-t-il si la sortie est inexacte ?
- La vérifiabilité : peut-on contrôler avant que l'erreur ait un effet ?
- Le coût de maintenance : qui corrigera les exceptions et fera évoluer le processus ?
Si la règle est stable, si l'erreur « coûte cher » et si le résultat se calcule facilement, le logiciel classique reste généralement le meilleur choix. Si la tâche porte sur des contenus variables et que la sortie peut être vérifiée, l'IA peut réduire le travail manuel. Et ce n'est pas un choix binaire : un même processus peut mêler les deux approches.
Utiliser l'IA pour produire du logiciel, pas pour supprimer les tests
Dines a aussi défendu une autre utilisation : faire générer par l'IA le code d'un logiciel déterministe, puis le faire relire et tester avant mise en service. Il l'a dit sur un ton volontairement provocateur, en expliquant que « personne ne toucherait plus au code ».
Pris au pied de la lettre, ce serait une mauvaise règle de production. Le code généré reste du code : il faut le relire, le tester, le documenter et le maintenir. L'idée intéressante est ailleurs : l'IA peut accélérer la fabrication d'un outil, tandis que tests et contrôles humains vérifient son comportement. Une automatisation fiable, ce n'est pas celle qui supprime la supervision. C'est celle dont les erreurs sont détectables et dont les conséquences sont maîtrisées.
Comment préparer les équipes à travailler avec l'IA ?
Une adoption réussie ne se limite pas à former des gens à utiliser un outil. Si une part du travail est déléguée, les équipes doivent comprendre le processus de bout en bout : pourquoi la tâche existe, quelles décisions elle implique, quelles exceptions reviennent le plus, et à quel moment on doit reprendre la main. C'est ce niveau de compréhension qui aide à repérer une sortie « plausible » mais inadaptée au contexte de l'entreprise.
Daniel Dines estime que le système éducatif, pensé pour former des travailleurs disciplinés dans une organisation industrielle, colle mal à un monde où l'on attend davantage d'initiative et de pilotage de systèmes automatisés. Pour les entreprises, la conséquence est directe : les compétences utiles ne se limitent pas à exécuter une spécialité étroite. Il faut aussi savoir relier les étapes d'un processus et comprendre leurs effets en aval.
Former des généralistes qui comprennent le système
Dines a pris l'exemple du droit : un agent peut analyser des textes, mais il ne sait pas automatiquement comment une règle s'applique dans une entreprise donnée. Ce décalage existe dans beaucoup de métiers. Une procédure interne, une exception commerciale, une contrainte de service : tout cela ne figure pas forcément dans les documents accessibles au modèle.
Concrètement, former les équipes, c'est leur apprendre à :
- décrire le processus et ses exceptions avant d'automatiser ;
- vérifier les informations utilisées par un agent ;
- distinguer une réponse plausible d'une réponse conforme aux règles internes ;
- signaler les écarts et documenter les décisions prises ;
- savoir quand arrêter l'automatisation et transférer le cas à un spécialiste.
Dans les entreprises françaises, ces compétences peuvent s'appuyer sur des processus réels : traitement d'une demande client, dossier administratif, opération comptable. La formation doit refléter les responsabilités du poste et les risques du flux concerné, plutôt que de rester une démonstration « IA » générique.
Ne pas sacrifier les profils juniors
Dines a aussi appelé à continuer de recruter des juniors et à les intégrer très tôt aux équipes expérimentées. Son point est clair : si on automatise toutes les tâches du début de carrière, on réduit les occasions d'apprendre comment les décisions sont prises.
Ça ne veut pas dire « garder » des tâches répétitives pour la forme. Il faut plutôt organiser l'apprentissage autrement. Un junior peut contribuer à vérifier des sorties, analyser des exceptions, documenter un processus, et observer comment un senior arbitre quand il y a plusieurs options. Le senior, lui, doit expliquer son raisonnement au lieu de laisser l'outil et la réponse finale hors de portée.
L'enjeu est de préserver une vraie progression : participation à des cas concrets, retours réguliers, montée en responsabilité. Sans cette transmission, l'entreprise peut gagner du temps à court terme, mais affaiblir sa capacité à superviser ses systèmes demain.
Conclusion : automatiser avec une responsabilité explicite
La question n'est pas de choisir entre une entreprise entièrement automatisée et une entreprise qui refuse l'IA. Le vrai travail consiste à déterminer où l'automatisation apporte un avantage concret, quand un logiciel déterministe est plus adapté, et quelles décisions doivent rester sous contrôle humain.
Avant de déployer un agent, identifiez le propriétaire métier, limitez ses permissions, définissez les cas d'escalade et prévoyez comment corriger une action. Ensuite, formez les équipes à comprendre le processus - y compris les juniors qui devront en assurer la continuité. L'IA peut prendre en charge du travail ; elle ne peut pas remplacer l'entreprise quand il s'agit d'assumer les conséquences.