Agents IA en entreprise : ce qui tient en production

La plupart des démos d'agents fonctionnent. La vraie question, c'est la 400e demande, un mardi, quand le client écrit moitié en français, moitié en anglais, avec la photo floue d'une facture en pièce jointe.

Un agent, c'est un modèle qui lit une demande, décide quoi faire, appelle vos outils et agit. C'est cette dernière étape qui change le projet.

Un chatbot qui répond mal donne une mauvaise réponse. Un agent qui agit mal rembourse deux fois le même client, ou envoie un lead au mauvais commercial.

Si quelqu'un à votre comité de direction a demandé ce trimestre « et les agents, on en est où ? », voici la version courte : quatre cas d'usage qui tiennent, quatre façons de casser, et trois choses à avoir avant toute mise en production.

Les cas d'usage qui tiennent en production

Les cas d'usage qui durent ont la même forme. La tâche revient souvent, les entrées sont désordonnées, et une personne vérifie le résultat plus vite qu'elle ne le produirait.

Le support client. L'agent lit le ticket, récupère la commande ou le compte, puis répond ou prépare une réponse pour l'équipe. Statut de commande, changement d'adresse, règles de retour : les questions qui remplissent la file chaque matin. Il n'a pas besoin de clore chaque ticket : retirer la partie répétitive de la file change déjà la semaine de l'équipe.

La qualification de leads. Un formulaire arrive, ou un e-mail. L'agent l'enrichit à partir des informations publiques, le compare à vos critères et l'oriente : vers les commerciaux, vers une séquence de nurturing, ou nulle part. Les commerciaux arrêtent de lire chaque demande entrante pour trouver les trois qui comptent.

Le traitement de documents. Factures, bons de commande, contrats, pièces d'identité, déclarations de sinistre. L'agent extrait les champs, les vérifie dans vos systèmes et signale ce qui ne colle pas. C'est souvent le cas d'usage le moins visible, et souvent le premier rentabilisé : le volume est élevé et le travail ingrat.

Les outils internes. Un agent qui répond à « où est la dernière grille tarifaire ? » ou « qu'a-t-on convenu avec ce client en mars ? » à partir de vos propres documents et outils. Il marche quand les sources sont propres et qu'il les cite. Il échoue sans bruit quand elles ne le sont pas.

Là où ils cassent

Les agents échouent de façon prévisible. Connaître ces échecs à l'avance, c'est l'essentiel du cadrage.

Le premier, ce sont les cas rares. Un agent qui traite bien la plupart des cas peut rester un mauvais produit si les autres sont ceux qui coûtent cher : le client furieux, le contrat avec une clause hors norme, le lead qui est en fait un concurrent. Il faut savoir lesquels avant de décider ce que l'agent a le droit de faire seul.

Le deuxième, ce sont les données : si l'historique des commandes vit dans trois systèmes qui se contredisent, l'agent se contredira aussi. Aucun modèle ne corrige ça.

Parfois, le premier projet utile est une API propre au-dessus des données, et l'agent vient ensuite. C'est moins excitant à annoncer, et c'est ce qui fait marcher l'agent.

Le troisième, c'est le périmètre qui s'étend. Un agent qui fait bien une tâche se voit confier cinq. Chaque nouvel outil qu'il peut appeler ajoute des façons d'échouer, et l'évaluation construite pour la première tâche ne dit rien des autres.

Le quatrième, c'est le coût : chaque étape d'un agent est un appel au modèle, parfois plusieurs. Un workflow qui enchaîne dix appels par demande paraît bon marché en démo, beaucoup moins à 20 000 demandes par mois. Un modèle plus petit sur les étapes simples et un cache sur les étapes répétées font disparaître une bonne partie de ce coût, à condition que quelqu'un le mesure avant le lancement.

Comment vérifier qu'un agent IA marche

« Ça a l'air bien » n'est pas une mesure. Avant qu'un agent passe en production, trois choses doivent exister.

Un jeu de test tiré de cas réels. Prenez quelques centaines de vraies demandes des derniers mois, avec la réponse qu'aurait donnée un bon collaborateur. Faites tourner l'agent dessus avant chaque changement de prompt, de modèle ou d'outils. Sans ce jeu de test, chaque amélioration est une supposition, et chaque mise à jour du modèle un risque invisible.

Une limite claire pour la relecture humaine. Décidez ce que l'agent fait seul et ce qu'il se contente de proposer. Un partage courant : l'agent agit seul sur les actions à faible risque et réversibles, et prépare tout le reste pour qu'une personne valide en un clic. Suivez la fréquence à laquelle les gens modifient la proposition ; quand ce taux baisse sur une catégorie, laissez l'agent agir seul dessus.

Un coût par tâche. Pas la facture mensuelle d'API : le coût d'un ticket traité ou d'une facture traitée, en comptant les appels au modèle, l'infrastructure et les minutes de relecture. Mettez-le à côté de ce que coûte la même tâche aujourd'hui. Si ce chiffre ne tient pas à votre volume réel, le projet non plus, aussi bonne que soit la démo.

Jeu de test, limite de relecture, coût par tâche. S'il en manque un, l'agent n'est pas prêt.

Une fois en production, continuez à mesurer : enregistrez chaque exécution, prélevez-en quelques-unes chaque semaine et notez-les à nouveau. Le fournisseur du modèle sort une nouvelle version, et la question de remboursement qui marchait le mois dernier reçoit maintenant une réponse polie et fausse. Un agent que personne ne surveille se dégrade sans que personne ne le remarque.

À quoi ressemble une première version

Une bonne première version d'agent est étroite. Une tâche, une équipe, quelques outils, une étape de relecture que l'équipe utilise vraiment.

C'est assez pour connecter l'agent aux vrais systèmes, construire le jeu de test avec l'équipe qui fait le travail aujourd'hui, et le confronter à de vraies demandes avec une personne qui relit. Ce n'est pas assez pour automatiser tout un service. Les premières semaines en production vous en apprennent plus que n'importe quel pilote.

Deux questions arrivent tôt. La première : où vont les données. Elles peuvent rester hébergées en Europe, dans votre cloud ou sur site, selon vos règles. Pour un agent, ça compte plus que pour un chatbot, parce qu'il lit vos commandes, vos contrats et vos fiches clients pour faire son travail (plus de détails sur les données, le RGPD et l'AI Act).

La seconde : qui fait tourner l'agent après le lancement. Quelqu'un doit tenir le jeu de test, la file de relecture et le coût par tâche. Si personne chez vous n'a encore ce rôle, prévoyez-le dès le départ : c'est pour ça que nous faisons tourner ce que nous construisons, avec les personnes qui l'ont construit.

Commencer par une tâche

La bonne première question n'est pas « où utiliser des agents ? » mais « quelle tâche une personne ici répète-t-elle cent fois par semaine ? ». L'audit gratuit, c'est une heure sur cette question, suivie d'un document court qui dit quelles tâches méritent un agent et lesquelles non.

Réservez un audit gratuit et venez avec la tâche que vous confieriez en premier. Si un agent n'est pas la bonne réponse, le document le dira.