Agents IA en entreprise : par où commencer

Un agent IA n’est pas un chatbot plus malin. C’est un logiciel qui reçoit un objectif, lit vos données, utilise vos outils et enchaîne les étapes jusqu’à un résultat : un ticket trié, une facture saisie, une relance rédigée. Bien choisi, il retire des heures de travail répétitif à une équipe. Mal cadré, il produit des erreurs plausibles à grande vitesse. La différence ne tient pas au modèle. Elle tient au choix du premier processus, à la place laissée à l’humain et à la façon de mesurer. Voici comment nous démarrons en 2026, en six semaines.

Ce qu’un agent sait faire, et ce qu’il rate

Les modèles de langage actuels, ceux d’Anthropic (Claude), d’OpenAI ou de Mistral, sont très bons pour lire, résumer, classer, extraire des informations d’un document et rédiger un premier jet. Reliés à des outils, ils deviennent des agents : ils consultent un CRM, interrogent une base documentaire, remplissent un formulaire, préparent un e-mail.

Leurs faiblesses sont connues, et il faut les nommer dès le départ :

• Les hallucinations. Un modèle peut affirmer avec assurance une information fausse. Sur une tâche ouverte, c’est inévitable sans vérification.
• L’injection de prompt. Un document ou un e-mail piégé peut contenir des instructions que l’agent risque de suivre. C’est le premier risque du Top 10 OWASP pour les applications LLM.
• La fuite de données. Ce que l’agent lit peut se retrouver dans ce qu’il écrit, ou chez un fournisseur de modèle si le contrat et l’hébergement ne sont pas choisis avec soin.
• Le coût qui dérive. Un agent qui boucle, relit dix fois le même document ou utilise le plus gros modèle pour tout coûte vite plus que prévu.

Rien de cela n’interdit les agents. Tout cela impose une architecture où l’erreur est attendue, détectée et rattrapée.

Choisir le premier processus

Le premier agent ne doit pas être le plus ambitieux. Il doit être le plus mesurable. Nous cherchons un processus répétitif, fréquent, aux règles claires, dont on peut vérifier le résultat, et où une erreur coûte peu ou se rattrape facilement.

Un bon test : si vous ne savez pas écrire en une page ce qu’est un résultat correct, le processus n’est pas prêt pour un agent.

L’humain dans la boucle, par niveaux

« Human in the loop » ne veut pas dire qu’un humain relit tout pour toujours. Cela veut dire que le niveau d’autonomie dépend du risque de chaque action.

1. L’agent propose, l’humain décide. L’agent prépare le brouillon, la classification ou la saisie. Une personne valide d’un clic. C’est le point de départ de presque tous nos projets.
2. L’agent agit, l’humain contrôle par échantillon. Une fois la qualité mesurée, les cas simples passent seuls. Les cas incertains, ceux où l’agent signale un doute, remontent à un humain.
3. L’agent agit seul sur un périmètre borné. Uniquement pour des actions réversibles, journalisées, avec des limites strictes.

Les actions irréversibles (envoyer, payer, supprimer, publier) restent derrière une validation humaine. Ce n’est pas une précaution temporaire, c’est une règle de conception.

Les données et les outils

Un agent vaut ce que valent les informations qu’il reçoit. Trois chantiers reviennent toujours.

• La base documentaire. Pour répondre à partir de vos documents, on utilise le RAG : les textes sont découpés, indexés dans une base vectorielle (pgvector sur PostgreSQL fait très bien l’affaire), et l’agent retrouve les passages pertinents avant de répondre. La qualité dépend surtout du ménage fait dans les documents : versions obsolètes, doublons, contradictions.
• Les outils. L’agent agit via des API ou le Model Context Protocol (MCP), un standard ouvert qui décrit les outils qu’un modèle peut appeler. Chaque outil reçoit les droits minimums : lecture seule tant que l’écriture n’est pas nécessaire.
• L’hébergement. Selon la sensibilité des données, on choisit un fournisseur avec engagement de non-réutilisation, un hébergement européen (Mistral propose cette option), ou un modèle open-weight auto-hébergé. Le RGPD s’applique comme pour tout traitement.

Mesurer avec des evals

Une démonstration réussie ne prouve rien. Ce qui compte, c’est le taux de bonnes réponses sur des cas réels. On construit donc un jeu d’évaluation (les « evals ») : une centaine de cas tirés de l’historique, avec la bonne réponse attendue. Chaque modification du prompt, du modèle ou des outils est rejouée contre ce jeu.

Les evals répondent à trois questions : l’agent est-il assez fiable pour ce niveau d’autonomie, une nouvelle version fait-elle mieux ou moins bien, et quels types de cas posent problème. Sans elles, chaque changement est un pari.

En production, on ajoute l’observabilité : chaque exécution est journalisée, avec les étapes, les outils appelés, le coût et la décision finale. Quand un utilisateur signale une erreur, on sait la reproduire.

Maîtriser les coûts

Le coût d’un agent se compose surtout des appels au modèle, facturés au volume de texte traité. Il se pilote avec quelques règles simples : un modèle léger pour les étapes simples (classer, extraire) et un modèle plus puissant seulement pour le raisonnement, la mise en cache des contextes répétés, une limite d’étapes et de dépenses par tâche, et un suivi quotidien. Nous fixons un budget par tâche pendant le pilote : il devient l’un des critères pour passer à l’échelle.

Un parcours en six semaines

Semaines 1 et 2 : cadrer et mesurer l’existant. On choisit le processus, on écrit la définition d’un résultat correct, on rassemble une centaine de cas réels et l’on mesure le temps passé aujourd’hui. On décide du niveau d’humain dans la boucle et de l’hébergement des données.

Semaines 3 et 4 : construire le pilote. Premier agent relié aux vrais outils, en lecture seule ou en mode « propose ». Evals en place, journaux actifs, budget par tâche. On itère sur les cas qui échouent.

Semaine 5 : tester avec l’équipe. Les personnes qui font le travail aujourd’hui utilisent l’agent en conditions réelles. Elles valident, corrigent, signalent. Leurs retours enrichissent le jeu d’évaluation.

Semaine 6 : décider. Fiabilité mesurée, coût par tâche, temps réellement gagné, retours de l’équipe. Trois issues possibles : étendre l’autonomie, élargir à un deuxième processus, ou arrêter. Arrêter est un résultat légitime, et bien moins cher que de découvrir le problème six mois plus tard.

Ce qu’il faut retenir

Commencez petit, mesurable et réversible. Gardez l’humain sur les décisions qui comptent. Mesurez avec des evals plutôt qu’avec des démonstrations. Donnez à l’agent les droits minimums et un budget. Et formez l’équipe qui travaillera avec lui : un agent que personne ne sait superviser ne reste pas longtemps en production.