L’autonomie ne se mesure pas seulement aux tâches accomplies. Elle se conçoit aussi autour des limites, des arrêts et des décisions à confier à une personne.
On parle beaucoup de rendre les agents IA plus autonomes. Mais pour moi, l’autonomie ne veut pas dire agir le plus souvent possible. Elle suppose aussi de reconnaître les situations où une action devrait attendre.
Information incomplète. Demande hors mandat. Risque trop élevé. Approbation nécessaire. Ces cas sont moins spectaculaires dans une démonstration, mais ils méritent une place centrale dans la conception d’un système destiné au travail réel.
Une réponse et une action ne portent pas les mêmes conséquences. Préparer un brouillon laisse une possibilité de vérification. Modifier un dossier ou envoyer un engagement à un client change déjà quelque chose dans l’entreprise.
L’autonomie commence par un mandat clair.
L’équipe définit l’objectif et les limites du mandat, qu’elle doit pouvoir réviser ou retirer. Elle précise ce que l’agent peut consulter, proposer et exécuter. À quel compte s’applique son action? Quels champs peut-il modifier? Quelles décisions restent réservées à une personne?
Une instruction générale comme « traite les demandes clients » laisse trop de place à l’interprétation. Un mandat utile décrit un périmètre, des conditions et des limites. Ces limites doivent être vérifiées par le système qui autorise l’action; elles ne doivent pas dépendre seulement de la formulation d’une réponse du modèle.
Un arrêt doit avoir une raison compréhensible.
L’agent peut préparer une proposition sans disposer de toutes les conditions nécessaires pour l’exécuter. Il faut rendre cette distinction visible. Une réponse qui paraît assurée ne prouve pas que le dossier, les permissions ou les règles ont été vérifiés.
On peut définir plusieurs situations d’arrêt, avec une suite différente pour chacune. Certaines demandent une information supplémentaire. D’autres exigent une validation. Une action hors mandat doit rester bloquée, même si elle semble techniquement possible.
Information insuffisante : préciser ce qui manque avant de poursuivre.
Référence ambiguë : présenter les options et demander une clarification.
Hors mandat : ne pas exécuter et orienter vers le bon responsable.
Risque élevé ou approbation requise : préparer le dossier pour une décision humaine.
Avant d’agir, vérifier les conditions
01Information incomplètePréciser ce qui manque.
02Référence ambiguëFaire confirmer le bon dossier.
03Mandat dépasséBloquer l’action et passer le relais.
04Approbation requisePréparer la décision de la bonne personne.
Si une condition manque, suspendre l’action et préparer une reprise claire.
Un exemple : modifier une commande déjà en préparation.
Prenons un scénario illustratif. Un courriel demande de modifier une commande en cours. L’agent retrouve un dossier correspondant et prépare le changement. Cela ne suffit pas à autoriser la modification. Il reste à vérifier l’identité du demandeur, le statut actuel de la commande, les conditions applicables et le rôle de la personne qui approuve.
Si la préparation a déjà commencé, si plusieurs dossiers correspondent ou si le changement dépasse le mandat, le parcours doit suspendre l’action. L’agent peut rassembler les éléments utiles et transmettre une proposition claire. Le dossier ne doit pas donner l’impression que la modification est faite alors qu’elle attend une décision.
L’approbation porte ensuite sur une action précise. Si les informations changent avant son exécution, les conditions doivent être réévaluées. Une validation précédente ne doit pas devenir une permission générale de continuer.
Demander de l’aide sans abandonner le travail.
Un simple message « je ne peux pas » ne donne pas toujours à l’équipe ce dont elle a besoin. Un passage de relais utile décrit la demande, les informations consultées, la proposition préparée et la condition qui empêche de poursuivre.
Il indique aussi qui doit décider et quel sera l’état du dossier pendant l’attente. La personne reprend un travail préparé, avec ses incertitudes visibles. Une demande d’approbation ne doit pas se perdre dans une notification sans responsable.
Une mauvaise réponse est une erreur. Une mauvaise action peut devenir un incident.
Évaluer les bonnes actions et les bons arrêts.
Un agent qui accomplit une tâche mérite d’être évalué sur la qualité de son résultat. Il faut également examiner les cas où il ne devait pas agir. A-t-il bloqué une demande hors mandat? Identifié une information manquante? Présenté une demande d’aide exploitable? Évité de répéter une action déjà exécutée?
Le test doit aussi regarder les arrêts inutiles. Un système qui bloque tout ralentit le travail. L’objectif est donc un périmètre utile, des conditions explicites et des décisions compréhensibles, plutôt qu’un maximum d’actions ou de refus.
Pour un premier pilote, je privilégierais un jeu de situations représentatives, avec les actions et les arrêts attendus définis avec l’équipe métier. On observe les erreurs, les blocages injustifiés et la qualité des reprises. L’autonomie devient alors un comportement à valider, plutôt qu’une impression donnée par la démonstration.
Les questions à poser avant de déléguer
✓ Quel est le mandat exact de l’agent et quelles actions lui sont interdites?
✓ Quelles informations et permissions doivent être vérifiées avant chaque action?
✓ Quels cas exigent un arrêt, une clarification ou une approbation?
✓ Qui reprend le dossier, avec quelles informations et quel statut pendant l’attente?
✓ Comment tester les actions injustifiées, les arrêts inutiles et les reprises après validation?
