Un agent IA autonome en production : ce que ça demande

Une démonstration d'agent IA dure trois minutes et impressionne. Un agent qui tourne vraiment, lui, agit quand personne ne regarde l'écran. Entre les deux il n'y a pas un modèle plus puissant, mais une question qu'on ne pose presque jamais avant de brancher quoi que ce soit : qu'est-ce que cette chose peut casser le jour où elle se trompe ?

Un agent IA autonome n'est pas un agent plus intelligent, c'est un agent dont l'espace d'action est borné : un périmètre fermé, un canal de modification tracé et réversible, une limite d'étapes et de budget, et une consigne nette sur le moment où il doit s'arrêter et demander. Ce qui le rend acceptable en production, ce n'est pas qu'il ait raison souvent, c'est que sa pire erreur possible reste rattrapable.

Ce qui sépare une démonstration d'un agent qui tourne

La différence la plus visible n'est pas technique, elle est humaine : dans une démonstration, quelqu'un est là. Il formule la demande, il regarde l'agent travailler, il arrête la séance si ça part de travers. Cette présence fait énormément de travail silencieux, et on ne s'en aperçoit qu'au moment de la retirer. Un agent réellement autonome n'est pas déclenché par une personne : il est réveillé par un événement, une alerte, une horloge, un autre agent. Personne ne lui parle, personne ne regarde. Sur le capot, qu'est-ce qu'un agent IA sépare le concept de la mécanique.

L'autonomie n'est pas une propriété du modèle

C'est le point que la plupart des discussions sur le sujet manquent, et il a des conséquences très pratiques. On parle d'autonomie comme d'une qualité de l'IA, quelque chose qui arriverait avec la prochaine génération de modèles. Je ne crois pas que ce soit la bonne façon de regarder. Un modèle plus capable fait moins d'erreurs, il n'en fait pas zéro, et il ne vous dira pas quand il s'est trompé. Tant que la sûreté repose sur sa justesse, vous avez un pari plutôt qu'un dispositif. Elle doit reposer sur ce que l'agent a matériellement le droit de faire.

Je fais tourner depuis plus d'un an une astreinte d'infrastructure tenue par un agent. Il reçoit une alerte, diagnostique, applique un correctif par le canal de déploiement normal (donc revu, tracé, annulable), et laisse un rapport que je lis le lendemain matin. Ce qui rend ce dispositif supportable n'est pas la qualité de son raisonnement, même si elle m'a souvent surpris : c'est que les droits qu'on lui a donnés sur le système lui interdisent les gestes destructeurs, par construction. S'il déraille, l'infrastructure dit non. J'ai détaillé ce montage dans le retour d'expérience sur cette astreinte.

Les trois bornes techniques d'un agent autonome

La première, c'est le périmètre fermé. On ne liste pas ce que l'agent n'a pas le droit de faire, on liste ce qu'il a le droit de faire, et tout le reste est refusé par défaut. La nuance a l'air scolaire, elle est décisive : une liste d'interdits est toujours incomplète, une liste d'autorisations est complète par construction. Cela se traduit par des droits techniques, des comptes de service restreints, de la lecture large et de l'écriture étroite. Pas par un paragraphe d'instructions, qu'une donnée malveillante entrée dans son contexte peut contredire.

La deuxième, c'est le canal de modification tracé. Ce que l'agent produit doit passer par le chemin que vos équipes empruntent déjà, avec le même historique et la même capacité d'annulation. Si vos déploiements passent par des commits et une revue, les siens aussi. L'intérêt est double : vous savez exactement ce qu'il a changé et quand, et vous revenez en arrière avec un geste que tout le monde connaît. Un agent qui modifie l'état d'un système par un chemin de traverse vous enlève les deux d'un coup.

La troisième, c'est la limite d'étapes et de budget. Un agent qui boucle est un cas normal, pas un incident exceptionnel : il tente, échoue, réessaie autrement, et peut tourner longtemps sur un problème qu'il ne résoudra pas. Un plafond d'étapes et un plafond de coût par exécution transforment ce scénario en arrêt propre accompagné d'un rapport, plutôt qu'en facture et en surprise. C'est un bon signal de qualité : si vos agents touchent souvent leur plafond, le problème n'est pas le plafond, c'est la tâche qu'on leur confie.

La quatrième borne n'est pas technique : savoir ne rien faire

Un agent a un biais structurel vers l'action : on lui a donné un objectif et des outils, il va chercher à produire quelque chose. Face à un signal ambigu, à un incident déjà résolu tout seul, à une situation qui ne ressemble à rien de connu, sa pente naturelle est d'inventer une intervention pour justifier son exécution. C'est là qu'il fait des dégâts, presque jamais sur les cas clairs. L'instruction la plus utile dans un agent autonome n'est donc pas une procédure de résolution, c'est la description des situations où il doit s'arrêter, ne rien toucher et réveiller un humain.

Ce qui ne marche pas, et ça va vite

L'autre versant existe, et il est brutal. Un agent autonome lâché sur un périmètre mal borné produit des dégâts bien plus vite qu'un humain dans la même situation. Là où une personne hésite, demande, va déjeuner, se dit qu'elle verra demain, l'agent enchaîne des dizaines d'actions, chacune cohérente avec la précédente et toutes dans la mauvaise direction. Pas de pause naturelle dans son exécution, pas de malaise, pas de coup de fil à un collègue. La vitesse, qui est l'argument de vente, transforme aussi une mauvaise hypothèse de départ en situation difficile à démêler.

Deux conséquences pratiques. D'abord, un processus mal défini ne devient pas plus clair parce qu'on y met un agent : il devient plus rapide, donc plus coûteux quand il est faux. Ensuite, la bonne première tâche n'est jamais la plus complexe, c'est la plus bornée, même modeste. On cherche un périmètre où l'on sait écrire « au pire il fait X, et X se répare en Y minutes ». Tant que cette phrase n'est pas écrite, le sujet n'est pas prêt, et aucun modèle ne compensera.

Par où ça commence vraiment

Si vous envisagez un agent autonome chez vous, la première question n'est ni le choix de l'outil ni celui du modèle. C'est de savoir quel processus est assez bien défini pour qu'on puisse en décrire le périmètre, le canal de modification et le pire cas. Dans la plupart des organisations que j'accompagne, cette question révèle que le travail préalable n'est pas de l'IA : c'est d'écrire ce que le système et l'équipe savent déjà sans l'avoir formulé. Ce chantier profite aux humains autant qu'aux agents, et le guide de l'IA agentique en entreprise rassemble la méthode complète.

Mon avis, après plus d'un an à vivre avec un agent qui travaille pendant que je dors : le sujet n'est pas de savoir jusqu'où l'autonomie ira, mais où vous acceptez qu'elle s'exerce. C'est une question d'architecture et de responsabilité plutôt que de technologie, et elle se pose dans les mêmes termes qu'avant l'IA, avec moins de délai pour y répondre. Ce qui me frappe le plus à l'usage, c'est que le travail sur les bornes a amélioré ma compréhension du système : on ne décrit pas le pire cas d'un processus sans découvrir deux ou trois choses qu'on croyait savoir.