Analyse
Les systèmes d'IA exécutent de plus en plus souvent des choses eux-mêmes : mettre à jour un statut, préparer un message, préparer une modification pour la production. La question de savoir si le système en est capable est vite réglée. Celle de savoir s'il peut en décider est une autre question, et on la pose rarement à part.

Bill Gates a récemment utilisé le terme Human Reserved pour le travail que nous réservons délibérément aux humains, même là où des machines pourraient techniquement s'en charger. Il compare cela à une réserve naturelle : on pourrait y construire, on choisit de ne pas le faire, parce que la perte serait trop grande. Ses exemples concernent l'emploi et les soins, un robot qui ne devrait pas être celui qui vous annonce une mauvaise nouvelle, et la question de savoir qui trace alors ces limites. Cette dernière question, il la laisse ouverte.
Je trouve le terme utile aussi à une échelle bien plus petite : la manière dont une entreprise fait travailler l'IA et les agents dans son fonctionnement quotidien. C'est mon application, pas celle de Gates. Là, il s'agit rarement de savoir quel métier entier doit rester humain. Il s'agit de savoir quelle décision on ne transfère pas, même lorsque le système peut techniquement exécuter parfaitement l'action correspondante. Chez Gates, l'accent est mis sur ce que nous ne voulons pas perdre. Dans une entreprise, une autre question s'y ajoute : qui est habilité à prendre la décision, et qui en reste responsable ensuite ?
Être capable, être autorisé, être habilité
Avec l'IA, on commence presque toujours par la première question : le système en est-il capable ? Comparer des sources, rédiger une proposition, produire du code, résumer un dossier, repérer un écart. Aujourd'hui, la réponse est le plus souvent oui, et là où c'est encore non, c'est souvent temporaire.
La deuxième question est de savoir s'il y est autorisé dans cet environnement. Peut-il modifier un fichier, mettre à jour un statut, préparer un brouillon de message ? C'est une affaire d'accès et de paramètres, et la plupart des entreprises règlent cela correctement, ne serait-ce que parce que l'IT le demande.
La troisième question reçoit rarement une réponse distincte : le système est-il habilité à décider là-dessus ? C'est autre chose que l'accès. Un nouveau collaborateur peut parfaitement maîtriser l'ERP et y avoir tous les droits, et pourtant ne pas pouvoir accorder une remise, envoyer une offre au-delà d'un certain montant ni bloquer un client. Personne ne trouve cela étrange. Dans une entreprise, l'habilitation est toujours quelque chose qui se donne explicitement, par une procuration, une description de fonction ou un accord. Elle ne découle pas du fait que quelqu'un fait la bonne évaluation.
Pour un système d'IA, c'est pareil, sauf qu'on le regarde moins souvent sous cet angle. Un système peut disposer d'assez d'informations pour faire une bonne proposition sans pour autant avoir le droit de décréter que cette proposition est désormais la décision. Il peut évaluer correctement quel est sans doute le meilleur choix, et ne pas être mandaté pour accorder une exception au nom de l'entreprise, approuver quelqu'un, publier quelque chose ou prendre un engagement commercial.
Il peut avoir raison sans être habilité à décider.
Cette distinction gagne en importance à mesure que les modèles s'améliorent, elle n'en perd pas. Tant que l'IA n'est pas fiable, le contrôle humain va de soi et personne n'a à le défendre. Gates note lui-même que le grand basculement n'arrive que lorsque l'IA fonctionne presque sans faute, parce qu'il ne semble alors plus y avoir de raison pratique de laisser quelqu'un garder un œil dessus. À l'échelle d'une entreprise, le risque est le même. Pas nécessairement que quelqu'un décide consciemment de transférer le pouvoir de décision, mais qu'il glisse peu à peu avec la fiabilité, parce que c'est devenu facile et que personne n'a fixé la limite explicitement.
Un humain dans la boucle ne dit pas encore où se trouve le pouvoir de décision
« Human in the loop » a quelque chose de rassurant, mais en soi cela dit peu. Il peut encore y avoir quelqu'un qui appuie sur un bouton tout à la fin alors que le système a déjà formulé la question, réduit les options, fait l'évaluation et mis une seule réponse en avant comme allant de soi. Formellement, il y avait un humain entre les deux. En pratique, cette personne ne fait guère plus que confirmer ce qui semble déjà décidé, surtout la dixième fois de la journée, quand les neuf précédentes étaient correctes.
Ce n'est pas un argument contre les humains dans la boucle. C'est un argument pour poser la question autrement : quelle décision n'a jamais été déléguée au système, et la personne qui la prend a-t-elle encore vraiment son mot à dire ?
Que peut proposer le système ? Que peut-il exécuter lui-même ? Quelle étape change le statut d'une information ? Quelle étape crée une conséquence en dehors de l'entreprise ? Et qui a le mandat pour approuver cette transition ?
Cela doit être fixé avant l'automatisation, pas au moment où quelqu'un se demande après coup pourquoi le système a fait quelque chose.
Une demande n'est pas encore une approbation
Dans un Ambassador Journey que nous avons développé nous-mêmes, beaucoup de choses sont automatisées. Les personnes soumettent leur profil et leurs demandes de produits, l'application vérifie si les données nécessaires sont présentes, conserve le statut et l'historique, montre ce qui demande encore de l'attention et prépare l'étape suivante. Un aperçu opérationnel quotidien évite que les points ouverts se dispersent à nouveau dans des fichiers et des boîtes mail. L'IA et les agents ont aidé pour la recherche, l'architecture, le développement, les tests et le contrôle, ce qui permet à l'app de reprendre de manière fiable une grande partie de la préparation et du suivi.
La couche commerciale fait bel et bien partie de cet Ambassador Journey. L'évaluation, les choix de produits, l'approbation et le transfert final vers Sales relèvent du même processus. Simplement, ces étapes n'ont pas toutes le même propriétaire.
Le Journey peut enregistrer que quelqu'un a soumis un profil ou une demande. Il peut vérifier si l'information est complète et montrer quelle évaluation reste à faire. Il peut préparer une sélection approuvée pour le transfert.
Mais une demande ne devient jamais d'elle-même une approbation au nom de l'entreprise. L'app ne détermine pas de manière autonome quelle évaluation commerciale s'applique et ne crée pas de handoff définitif vers Sales tant que quelqu'un disposant de l'habilitation requise n'a pas explicitement franchi cette étape. La demande en elle-même ne donne lieu à aucune commande, aucun contrat ni aucun engagement commercial.
Un logiciel pourrait techniquement attribuer lui-même un statut suivant sans grande difficulté. Ce n'est simplement pas la même chose qu'être habilité à prendre la décision commerciale sous-jacente. La limite ne tient donc pas seulement à ce que l'app peut faire, mais aux transitions de statut qu'elle peut exécuter seule et à celles qui exigent une décision humaine explicite.
Certaines décisions contiennent un contexte qui ne tient pas entièrement dans des champs de saisie : une relation, une exception, un arbitrage commercial, la responsabilité de ce qui se passe ensuite. Et au bout du compte, quelqu'un doit être habilité, au nom de l'organisation, à dire oui ou non, y compris vis-à-vis de la personne qui a fait la demande.
Vérité et pouvoir de décision sont deux questions différentes
J'ai écrit plus tôt qu'une IA plus performante nous oblige à déterminer plus précisément ce qui est vrai : ce qu'est une hypothèse, ce qu'est une décision et ce qu'est la vérité actuelle du projet.
Cela reste nécessaire. Mais supposons que tout soit en ordre. La source est correcte, l'information est à jour et le modèle l'interprète correctement. La question de savoir si le système peut agir sur cette base reste alors entière. La qualité de l'information n'y répond pas.
L'un détermine ce qui compte comme vrai. L'autre détermine qui ou quoi peut en faire quelque chose. Les deux vont ensemble, mais le pouvoir de décision ne se déduit pas d'une information correcte.
En anglais, cela s'appelle authority governance, ce qui sonne plus solennel que ça ne l'est.
Des limites fixes permettent plus d'automatisation
Human Reserved donne l'impression qu'on veut protéger quelque chose contre l'automatisation. En pratique, c'est plutôt l'inverse. Une fois établi quelle transition de statut, quelle décision ou quelle action externe exige une habilitation humaine, le système peut travailler bien plus librement jusqu'à cette limite, sans demander la permission à chaque étape intermédiaire. L'attention humaine va aux quelques moments où elle est vraiment nécessaire, et ces moments sont nommés.
Cela ne veut pas dire qu'un système ne peut jamais décider. Une commande automatique de réassort sous un montant seuil est aussi une décision, et elle a été déléguée. Simplement, cela s'est fait délibérément, avec une limite, et tout le monde sait que c'est ainsi.
Cela me paraît plus utile que de distribuer un maximum d'autonomie pour ensuite reconstituer après coup où la décision a réellement été prise.
Ce que l'IA sait faire continuera d'évoluer, et ce qui est impossible aujourd'hui devient demain une fonction ordinaire. Le pouvoir de décision, lui, ne suit pas automatiquement. Quelqu'un doit le transférer ou le garder délibérément, et la différence entre les deux n'est le plus souvent rien de plus qu'un accord conclu à temps.