Agent IA en entreprise : quel niveau d'autonomie lui donner ?

Un agent IA peut lire, classer, rédiger, mettre à jour une fiche ou envoyer un message. Ces actions n'ont pas le même poids. Mal classer un e-mail entrant ne coûte presque rien. Envoyer un avoir erroné à un client coûte bien plus. Se demander si l'agent doit être « autonome » n'a donc pas de sens. La question utile porte sur chaque action : qui décide, et qui exécute ?

Deux expressions reviennent souvent. « Human in the loop » : une personne valide avant que l'action ne prenne effet. « Human on the loop » : l'action s'exécute, et une personne surveille, avec la possibilité d'intervenir ou d'annuler après coup. Les deux approches sont légitimes. Le choix dépend de l'action, pas de l'outil.

Le même agent peut donc travailler à plusieurs niveaux en même temps : seul pour classer, sous validation pour répondre, et jamais pour payer. Un agent réglé d'un seul bloc est presque toujours soit trop bridé pour être utile, soit trop libre pour être sûr.

Cette grille prolonge celle de l'article sur le choix entre agent IA et automatisation classique, avec un niveau de plus. Chaque niveau dit ce que l'agent fait seul et ce qui reste à une personne. Plus on monte, moins l'humain intervient avant l'action, et plus les garde-fous techniques doivent être solides.

Le niveau N3 est souvent le plus intéressant : l'agent fait gagner du temps sans que personne ne repasse derrière chaque action. Il n'est sûr que si le périmètre est borné, les actions annulables et le journal relu par échantillon. Sans ces trois conditions, restez en N2.

Pour chaque action, cinq questions suffisent à situer le niveau de départ. Posez-les avec la personne qui fait le travail aujourd'hui, pas seulement avec celle qui le pilote. C'est elle qui connaît les exceptions, les pièges et le coût réel d'une erreur.

Le critère le plus défavorable fixe le plafond. Une action peu coûteuse mais irréversible reste en N2. Un fort volume ne justifie jamais à lui seul de supprimer la validation : il incite à réduire le risque, par exemple en plafonnant l'action ou en la rendant annulable, pour pouvoir ensuite la confier à l'agent.

Un garde-fou efficace ne dépend pas de la bonne volonté de l'agent. Écrire dans ses consignes « ne jamais dépasser tel montant » ne suffit pas : une consigne peut être mal interprétée, ou détournée par un texte piégé glissé dans un e-mail. La limite doit être imposée par l'outil lui-même, ou par les droits du compte qu'utilise l'agent.

Ces garde-fous rejoignent les recommandations de l'OWASP, une fondation de référence en sécurité des applications, sur le risque d'« agentivité excessive » : trop de fonctions, trop de droits, trop d'autonomie. C'est aussi le cadre qu'OMEGA applique à ses agents : outils autorisés, permissions explicites, limites d'action, validation humaine et journal d'exécution.

La validation humaine n'est utile que si la personne regarde. Quand les demandes s'enchaînent et que l'agent a presque toujours raison, valider devient un clic machinal. C'est le biais d'automatisation : la tendance à se fier par défaut à ce que propose la machine. Le règlement européen sur l'IA le cite d'ailleurs expressément.

Pour rester réelle, la validation doit être rare, rapide à faire et facile à refuser. La personne voit ce que l'agent propose, sur quoi il s'appuie et ce qui va changer. Elle peut accepter, corriger ou rejeter. Deux signaux sont à suivre : le temps passé par validation et la part des propositions modifiées.

Si plus personne ne corrige rien, deux explications sont possibles. Soit l'agent est fiable sur cette action, et elle peut monter d'un niveau. Soit la validation est devenue de façade. Un contrôle par échantillon, relu à froid par une autre personne, permet de trancher.

Une action démarre au niveau le plus bas raisonnable, souvent N1 ou N2. Elle monte quand le journal le justifie, pas quand une démonstration a impressionné. Les critères de passage s'écrivent avant le démarrage : on sait à l'avance ce qu'il faudra observer pour décider.

On monte d'un niveau à la fois, pour un type d'action à la fois. Juste après un passage, le contrôle par échantillon est renforcé pendant une période fixée à l'avance, puis allégé si rien ne dérive. Les autres actions de l'agent gardent leur niveau.

Le chemin inverse existe aussi. Un changement de modèle, de logiciel ou de règle métier, ou une erreur sérieuse, justifient de redescendre d'un niveau le temps de vérifier. Ce retour en arrière n'est pas un échec : c'est le garde-fou qui fonctionne.

Le règlement européen sur l'intelligence artificielle prévoit que les systèmes classés « à haut risque » puissent être effectivement contrôlés par des personnes pendant leur utilisation. Son article 14 demande des mesures de contrôle « proportionnées aux risques, au niveau d'autonomie et au contexte d'utilisation ». La personne chargée du contrôle doit notamment pouvoir décider de ne pas utiliser le système, et l'interrompre « au moyen d'un bouton d'arrêt ».

Les usages à haut risque sont listés dans l'annexe III du règlement. On y trouve par exemple le recrutement ou la sélection de personnes, et l'évaluation de la solvabilité des personnes physiques. Un agent qui met à jour un CRM ou relance des factures n'y figure pas en tant que tel. Pour un usage précis, la qualification se vérifie avec un juriste.

Même hors de ce cadre, la logique du texte est un bon repère : un contrôle proportionné au risque et à l'autonomie, une personne qui comprend ce qu'elle supervise, et un moyen d'arrêter le système à tout moment. Ce sont les garde-fous décrits plus haut.

Les erreurs suivantes ne tiennent pas à la qualité du modèle, mais au cadre qu'on lui donne. Elles se repèrent facilement sur le papier, et presque toutes se corrigent avant le démarrage, à condition de se poser les bonnes questions avec les personnes qui connaissent le processus.