Agents IA : l’autonomie se mérite, elle ne se décrète pas.

Le mot « agent » ne dispense pas de décrire le travail.

Un agent peut rechercher une information, préparer une recommandation, modifier une donnée ou déclencher une action externe. Ces opérations ne présentent ni le même enjeu ni le même besoin de contrôle. Les réunir sous un même mot brouille la décision : une organisation peut être prête à automatiser la préparation d’un dossier sans être prête à déléguer la décision qu’il contient.

Commencer par un inventaire des actions. Pour chacune : quel objectif, quelles informations d’entrée, quels outils, quels droits, quel effet sur le monde et quel moyen de constater la réussite ? Une action dont le succès ne peut pas être vérifié exige une prudence différente d’une opération au résultat simple et observable. Le périmètre de délégation se définit à ce niveau, pas au niveau d’une promesse générale d’autonomie.

Choisir la complexité qui résout le problème.

Dans son texte Building effective agents, publié en décembre 2024, Anthropic distingue les workflows dont les chemins sont prédéfinis des agents qui dirigent dynamiquement leur processus et leurs outils. Cette distinction architecturale reste utile pour raisonner, même si les outils décrits dans ce document historique ont évolué.

Un traitement connu peut bénéficier d’une orchestration explicite : étapes contrôlées, validation des entrées, gestion des exceptions. Un problème ouvert peut justifier une exploration plus flexible. La question économique est celle du gain marginal : l’autonomie supplémentaire améliore-t-elle assez le résultat pour compenser le coût, la latence, le contrôle et les nouvelles possibilités de défaillance ? Davantage d’étapes n’est pas une démonstration de sophistication utile.

Une séparation pratique consiste à laisser le système explorer dans un espace limité, puis à imposer un point de décision déterministe avant une action engageante. Cette frontière peut être plus importante que le choix du modèle. Elle rend visible ce que l’organisation accepte de déléguer et ce qu’elle choisit encore de vérifier.

Croiser conséquence et réversibilité.

Notre matrice propose deux questions. L’effet d’une erreur est-il limité ou important ? L’action est-elle facile ou difficile à annuler ? Une action à conséquence limitée et réversible peut se prêter à une autonomie bornée, après évaluation. Une action réversible mais importante réclame des plafonds et une surveillance adaptée. La réversibilité réduit un dommage potentiel ; elle ne rend pas l’erreur gratuite.

Une action peu réversible, même d’apparence mineure, mérite une validation plus explicite : le coût cumulé ou la diffusion d’une erreur peut changer son enjeu. Lorsque conséquence et irréversibilité sont élevées, une validation humaine préalable et des permissions étroites deviennent des éléments centraux de conception. La classification dépend toujours du contexte : envoyer un message de test et notifier un client réel ne sont pas le même acte.

La matrice est un instrument de discussion, pas une autorisation automatique. La sensibilité des données, les obligations applicables et la capacité à détecter une erreur complètent l’analyse. Un même produit peut donc porter plusieurs niveaux d’autonomie selon les actions et les populations concernées.

Faire grandir le périmètre au rythme de la preuve.

Une progression possible commence par l’observation sans action : le système produit une proposition, comparée au travail réel. Vient ensuite l’assistance, avec validation de chaque résultat. Une autonomie limitée peut suivre pour un ensemble étroit de cas, avec conditions d’arrêt et retour simple à l’humain. Cette progression n’est pas nécessairement linéaire ; un changement de données ou d’outil peut justifier un retour à un périmètre plus réduit.

Le jeu d’évaluation doit représenter les cas fréquents, les exceptions importantes et les situations où le système doit s’abstenir. Mesurer seulement la réussite sur des cas propres crée une vision incomplète. Il faut aussi mesurer les escalades inutiles, les actions non autorisées, le temps de reprise et la qualité des traces disponibles pour comprendre un incident.

Le budget fait partie du périmètre : nombre d’appels, durée maximale, volume de données et actions autorisées. Sans ces limites, un système peut poursuivre un objectif techniquement cohérent tout en devenant disproportionné pour le service attendu. Les limites doivent être exécutables, pas simplement décrites dans une consigne.

Le produit commence quand quelque chose se passe mal.

Une démonstration montre la trajectoire heureuse. L’exploitation révèle la qualité du dispositif de reprise. Qui reçoit l’escalade ? Avec quel contexte ? Dans quel délai doit-elle être traitée ? L’opérateur peut-il annuler une action, reprendre une tâche ou expliquer ce qui s’est produit ? Une interface qui expose un résultat sans son statut de validation impose une confiance que le système n’a peut-être pas méritée.

Le bon indicateur de maturité n’est pas le pourcentage maximal de tâches sans intervention. C’est la capacité à maintenir un résultat acceptable dans un périmètre connu, avec des coûts et des conséquences maîtrisés. Une abstention bien placée peut protéger davantage de valeur qu’une réponse supplémentaire.

Notre conviction : l’autonomie est une décision d’organisation rendue possible par la technique. Elle s’accorde à un système, pour des actions précises, dans des conditions précises. La frontière utile n’oppose pas l’humain à la machine ; elle relie la liberté d’action à la qualité de la preuve.