Agents IA : vers l'autonomie maîtrisée

Un agent IA se distingue d'un assistant par une différence simple : il n'attend pas d'instruction à chaque étape. On lui confie un objectif, il décide lui-même de la succession d'actions à mener, appelle des outils, évalue les résultats et poursuit jusqu'à ce qu'il estime avoir terminé. C'est une bascule considérable — et le mot important dans cette description n'est pas « autonome », c'est « estime ».

L'enthousiasme actuel autour des agents repose sur une promesse séduisante : automatiser non plus des tâches, mais des processus entiers. La réalité observée sur le terrain est plus contrastée, et elle mérite d'être exposée sans détour, car elle détermine les décisions d'investissement des dix-huit prochains mois.

Le premier constat est que la fiabilité d'un agent décroît avec le nombre d'étapes. Un système qui exécute correctement une action dans quatre-vingt-quinze pour cent des cas semble excellent. Enchaîné sur dix étapes dépendantes, il produit un résultat correct dans environ soixante pour cent des cas. Sur vingt étapes, un tiers. Cette arithmétique n'est pas un défaut de conception que la prochaine génération de modèles corrigera : c'est la conséquence mécanique de la composition. Elle impose une conclusion pratique — les agents efficaces sont ceux dont on a délibérément limité la profondeur.

Le deuxième constat concerne le mode d'échec. Un logiciel classique qui échoue s'arrête et le signale. Un agent qui échoue continue. Il interprète un résultat inattendu, s'adapte, poursuit dans une direction que personne n'avait prévue, et produit à la fin un rapport plausible sur un travail qui n'a pas été fait correctement. C'est une différence de nature, pas de degré : l'échec silencieux est infiniment plus dangereux que l'erreur bruyante, parce qu'il ne déclenche aucune alerte.

Le troisième constat porte sur les droits. Un agent utile agit — il écrit dans des systèmes, envoie des messages, engage des ressources. Chaque capacité accordée élargit la surface de ce qu'il peut faire de travers. La question de sécurité pertinente n'est pas « le modèle est-il fiable ? » mais « quel est le pire résultat possible si cet agent se trompe complètement, et ce résultat est-il acceptable ? ».

Voici une séquence typique. Elle ne décrit pas une organisation identifiable, mais un enchaînement observé sous plusieurs formes. Une direction financière déploie un agent chargé du rapprochement entre factures fournisseurs et bons de commande, avec autorisation de valider les écarts inférieurs à un seuil. Le dispositif fonctionne remarquablement pendant plusieurs semaines. Puis un fournisseur modifie le format de ses factures. L'agent, ne trouvant plus le champ attendu, se rabat sur un autre champ numériquement plausible et continue de valider. L'anomalie n'est détectée qu'au rapprochement bancaire mensuel. Le problème n'est pas que l'agent se soit trompé : c'est qu'il ait continué à travailler avec assurance après avoir cessé de comprendre ce qu'il lisait.

Ce cas illustre le principe que nous appliquons systématiquement : un agent doit être conçu pour s'arrêter, pas seulement pour réussir. Chez KAIROS Impulse, nous n'abordons pas ces projets par la question « que peut faire l'agent ? » mais par la question inverse : dans quelles circonstances doit-il refuser d'agir et rendre la main ? Cela suppose de définir des conditions de sortie explicites, des seuils de confiance, et un point de contrôle humain positionné là où la décision devient irréversible — pas systématiquement, ce qui annulerait le bénéfice, mais précisément là.

Il faut également distinguer deux familles d'agents que le débat public confond. Les agents à périmètre fermé opèrent sur un ensemble d'outils défini, avec des étapes prévisibles et un objectif borné : traiter une demande de congés, préparer un dossier de renouvellement, extraire et vérifier des informations dans un ensemble documentaire connu. Ils sont matures et rentables aujourd'hui. Les agents à périmètre ouvert, censés se débrouiller face à un objectif général avec des outils génériques, relèvent encore largement de la démonstration. La distance entre les deux est considérable, et une part de la déception actuelle vient d'organisations qui ont investi dans la seconde catégorie en pensant acheter la première.

Une objection légitime se pose : à trop encadrer un agent, ne le réduit-on pas à un automate classique, sans le bénéfice de l'intelligence ? La réponse tient dans ce que l'agent apporte réellement. Sa valeur n'est pas de décider librement, mais de gérer la variabilité de l'entrée — comprendre un e-mail formulé de dix manières différentes, traiter un document dont la structure varie, reconnaître qu'un cas sort de l'ordinaire. C'est précisément ce qu'un automate classique ne sait pas faire. Encadrer les actions tout en laissant la souplesse d'interprétation à l'entrée n'est pas un compromis : c'est la conception juste.

Trois questions avant d'engager un projet d'agents. Combien d'étapes séquentielles ce processus comporte-t-il, et avons-nous calculé la fiabilité composée qui en résulte ? Quelle est la pire conséquence possible d'une action erronée, et est-elle réversible ? Et enfin, comment saurons-nous que l'agent s'est trompé — quel signal nous parviendra, et dans quel délai ? Si la troisième réponse est « nous le verrons bien », le projet n'est pas prêt.