Agent IA en entreprise: ce qui tourne vraiment

Ce qu'un agent fait de plus qu'un assistant

La différence tient en un mot: agir. Un assistant produit du texte que quelqu'un relit puis utilise. Un agent enchaîne des étapes et déclenche des actions dans tes systèmes, sans repasser par un humain à chaque pas.

Cette dernière ligne surprend souvent. Un agent qui cherche, se corrige et recommence consomme plusieurs fois ce que coûte une réponse unique, et la facture ne suit pas le nombre d'utilisateurs mais le nombre de tâches et leur difficulté.

La troisième ligne est celle qui décide du reste. Avec un assistant, le contrôle arrive après: quelqu'un lit avant d'envoyer. Avec un agent, il doit arriver avant, sous forme d'une liste d'actions permises. Ce déplacement est tout le sujet de cet article.

Les quatre décisions à prendre avant la mise en production

Elles se prennent en réunion, pas en développement, et aucune ne demande de compétence technique. Ce sont pourtant elles qui déterminent si l'agent tourne encore dans trois mois.

1. Le périmètre. Un seul processus, nommé, avec un début et une fin. Un agent qui doit « aider l'équipe commerciale » n'a pas de périmètre, donc pas de critère de réussite ni de moment où on l'arrête.
2. Les actions autorisées. La liste écrite de ce qu'il a le droit de faire seul, et de ce qui attend une validation humaine. Lire, chercher et rédiger passent en général sans validation. Envoyer, écrire dans un outil métier et engager de l'argent n'y passent pas.
3. Le plafond de coût. Un montant mensuel au-delà duquel l'agent s'arrête. Sans lui, une boucle qui part de travers un vendredi soir se découvre le lundi sur une facture.
4. Le propriétaire. Une personne nommée qui reçoit les alertes, lit les traces et décide des corrections. Pas une équipe, une personne.

La quatrième est celle qu'on saute le plus souvent, et c'est aussi celle qui explique la majorité des agents abandonnés au bout d'un trimestre. Un système sans propriétaire ne meurt pas d'un incident, il s'éteint faute de quelqu'un pour le rallumer.

Ces quatre décisions ne dépendent pas de la technologie choisie. Elles sont identiques que tu déploies un projet libre, que tu achètes une plateforme ou que tu fasses développer sur mesure.

Où placer la validation humaine

La tentation est de tout faire valider, ce qui revient à payer un agent pour produire des brouillons. L'autre extrême, tout laisser passer, transforme la première erreur en incident client. La règle utile place la validation aux frontières, pas dans le flux.

Une frontière est un endroit où l'effet devient visible en dehors du système. Tant que l'agent travaille pour lui-même, il n'y a rien à valider. Dès que sa sortie devient la référence d'un collègue ou d'un client, il y a quelque chose à valider.

Cette grille a un effet secondaire utile: elle rend la trace lisible. Quand la validation se demande aux frontières, chaque approbation correspond à un moment identifiable, et l'audit d'après-incident devient possible.

Ce que ça coûte, et pourquoi personne ne peut te le chiffrer d'avance

Une réponse chiffrée donnée avant le cadrage est une réponse inventée. Ce qui se dit honnêtement, c'est la structure de la facture et ce qui la fait bouger.

• Le modèle. Facturé au token, chez ton fournisseur. C'est la ligne qui domine dès que l'agent tourne en continu, et elle suit la longueur des contextes autant que le nombre de tâches.
• L'hébergement. Quelques dizaines d'euros par mois pour un service qui tourne, davantage s'il faut de la haute disponibilité.
• La mise en place. Le cadrage, les connecteurs, la politique d'actions, les garde-fous. C'est un coût de départ, pas récurrent.
• L'exploitation. Surveillance, mises à jour, corrections. Quelques heures par mois même quand tout va bien, et c'est la ligne que les devis oublient.

Deux facteurs multiplient tout le reste. Le nombre d'exceptions du processus réel, parce que chaque cas particulier ajoute du code et des reprises. Et la qualité des données d'entrée, parce qu'un agent alimenté par des fiches incomplètes produit des erreurs plus vite qu'un humain.

C'est pour ça qu'un cadrage de vingt à quarante minutes sur un processus précis vaut mieux qu'un devis établi sur une description générale. Le devis générique se révèle faux au premier cas particulier.

Trois cas où l'agent est le mauvais outil

Dire non à un agent est plus utile que de le déployer dans ces trois situations, et ça se voit avant d'écrire la première ligne.

Le processus est entièrement prévisible. Si les règles s'écrivent, une automatisation classique fait le travail sans modèle, pour moins cher et sans variabilité. Ajouter un appel probabiliste à un enchaînement déterministe ajoute une source de panne et une facture qui bouge, sans rien gagner.

Personne ne sait dire ce que le processus fait aujourd'hui. Un agent ne découvre pas les règles implicites de ton métier, il les hérite du prompt qu'on lui écrit. Si la procédure vit dans la tête de trois personnes qui ne sont pas d'accord entre elles, le travail à faire est de la formaliser, pas de l'automatiser.

Le volume ne justifie pas la maintenance. Un agent qui traite dix demandes par mois coûte plus en exploitation qu'il ne fait gagner. Le seuil dépend du temps réellement passé sur chaque demande, et il se calcule avant, pas après.

Ces trois cas ont un point commun: aucun n'est un problème technique. Ils se règlent en cadrage, et c'est là que se joue la différence entre un agent qui tient et un projet abandonné.