Un agent IA peut automatiser une partie croissante du travail administratif d’une PME ou d’une ETI : trier et qualifier les demandes entrantes, préparer un dossier à partir de plusieurs sources, rapprocher des documents, pré-remplir des fiches dans vos outils. Il est efficace sur les tâches à fort volume, aux étapes variables et aux données peu structurées. En revanche, il ne doit pas décider seul d’une action irréversible ou engageante (payer, envoyer à un client, supprimer, trancher sur une personne) : ces étapes restent validées par un humain. La valeur d’un agent dépend moins du modèle que des droits, des outils et des garde-fous qu’on lui donne.
Qu’est-ce qu’un agent IA, concrètement ?
Un agent IA est un système dans lequel un modèle de langage reçoit un objectif, décide des étapes à suivre, appelle des outils (une API, une base de données, un moteur de recherche) et ajuste sa démarche en fonction des résultats obtenus, jusqu’à atteindre l’objectif ou s’arrêter.
Anthropic distingue deux familles qui sont souvent confondues :
- Le workflow : le modèle et les outils sont orchestrés selon un chemin écrit à l’avance par les développeurs. Par exemple : extraire les données d’une facture, les vérifier, puis les enregistrer.
- L’agent : le modèle dirige lui-même son processus et choisit ses outils. Il convient aux problèmes ouverts, dont on ne peut pas prévoir le nombre d’étapes.
La même source recommande de chercher la solution la plus simple possible et de n’ajouter de la complexité que si elle apporte un gain mesurable. Dans la pratique des PME, une grande partie des besoins se résout avec un workflow où le modèle n’intervient qu’à une étape précise, ce qui est plus prévisible, plus rapide et moins coûteux qu’un agent autonome.
Pour se brancher sur vos outils, un agent passe par des connecteurs. Le Model Context Protocol (MCP) est un standard ouvert qui normalise cette connexion entre applications d’IA et systèmes externes (fichiers, bases de données, outils métier). Il simplifie le branchement, mais ne règle pas la question essentielle : ce que l’agent a le droit de faire une fois connecté.
Ce qu’un agent IA sait bien faire dans une entreprise
Les cas d’usage les plus solides partagent trois traits : un volume élevé, un résultat facile à vérifier par un humain, et des données dispersées ou peu structurées.
| Processus | Ce que fait l’agent | Ce qui reste humain |
|---|---|---|
| Demandes entrantes (e-mails, formulaires) | Classe, extrait les informations, crée la fiche dans le CRM, propose une réponse | Envoi de la réponse aux cas sensibles |
| Factures fournisseurs | Extrait les données, rapproche avec commande et réception, signale les écarts | Validation du paiement |
| Appels d’offres | Lit le dossier de consultation, liste les exigences, prépare une matrice de conformité | Décision de répondre, prix, engagement |
| Support interne | Cherche dans la documentation, propose une réponse sourcée | Arbitrage des cas non documentés |
| Relances commerciales | Repère les opportunités dormantes, rédige des brouillons personnalisés | Envoi et ton de la relation |
| Contrôle de cohérence des données | Détecte doublons, champs manquants, incohérences entre CRM et ERP | Fusion ou suppression des fiches |
Prenons une entreprise de négoce qui reçoit chaque jour des centaines de demandes de devis par e-mail, avec des pièces jointes hétérogènes. Un agent peut identifier le client, reconnaître les références produits malgré les variantes d’écriture, vérifier la disponibilité dans l’ERP et préparer un devis en brouillon. Le commercial relit, corrige si besoin, et envoie. Le gain vient de la suppression des ressaisies, pas de la disparition du contrôle.
Les agents qui répondent à partir de vos documents internes reposent souvent sur la technique du RAG, détaillée dans notre article sur l’IA branchée sur les documents internes.
Ce qu’un agent IA ne doit pas faire seul
Le risque d’un agent n’est pas qu’il se trompe : tout système se trompe. C’est qu’une erreur se transforme en action réelle, sans que personne ne l’ait vue. L’OWASP nomme ce risque « agentivité excessive » et lui attribue trois causes : trop de fonctionnalités, trop de permissions, trop d’autonomie.
Voici les actions qui doivent rester soumises à une validation humaine, quelle que soit la qualité apparente de l’agent :
- Les mouvements d’argent : paiement, remboursement, avoir, modification d’un RIB fournisseur.
- Les engagements externes : envoi d’un devis, d’un contrat ou d’une réclamation à un client ou un partenaire, publication d’un contenu.
- Les actions irréversibles : suppression ou fusion de données, clôture d’un dossier, résiliation.
- Les décisions sur des personnes : sélection de candidats, sanction, refus de service. Le RGPD, en son article 22, donne aux personnes le droit de ne pas faire l’objet d’une décision fondée exclusivement sur un traitement automatisé produisant des effets juridiques ou les affectant de manière significative. L’AI Act classe en outre les usages RH à haut risque, comme nous l’expliquons dans notre guide de l’AI Act.
- Les changements de droits : création de comptes, attribution de permissions, modification de paramètres de sécurité.
Une seconde menace est propre aux agents : l’injection de prompt indirecte. L’OWASP la décrit comme le cas où le modèle lit un contenu externe (une page web, un fichier, un e-mail) qui contient des instructions cachées modifiant son comportement. Un agent qui lit les e-mails entrants et peut aussi écrire dans votre ERP est exposé : un message piégé peut tenter de lui faire modifier des coordonnées bancaires. La parade n’est pas de « mieux rédiger le prompt », mais de limiter ce que l’agent peut faire.
Comment encadrer un agent IA : les garde-fous indispensables
L’ANSSI, dans ses recommandations de sécurité pour les systèmes d’IA générative, invite à une « posture de prudence » lors de l’intégration de ces systèmes dans un système d’information existant. En pratique, cinq règles de conception font l’essentiel :
- Le moindre privilège. L’agent n’accède qu’aux outils et aux données dont il a besoin, avec des comptes dédiés. Lecture seule partout où l’écriture n’est pas indispensable. Pas d’accès générique de type « exécuter n’importe quelle commande ».
- L’autorisation contrôlée par vos systèmes, pas par le modèle. C’est l’API de votre ERP ou de votre CRM qui refuse une action interdite, pas une consigne donnée à l’IA. L’OWASP insiste sur ce point : ne jamais laisser le modèle décider si une action est permise.
- La validation humaine des actions à fort impact. L’agent prépare, l’humain valide. Concrètement, une file d’attente de propositions dans l’interface métier, avec les éléments qui ont motivé chaque proposition.
- Des limites explicites. Nombre maximal d’étapes, plafond de dépenses d’appels au modèle, périmètre de données, arrêt automatique en cas d’échec répété, comme le recommande Anthropic.
- Un journal complet. Chaque lecture, chaque appel d’outil, chaque proposition et chaque validation sont tracés. Sans ce journal, impossible de comprendre une erreur, de corriger le comportement ou de répondre à un contrôle.
Ces garde-fous relèvent de l’architecture des intégrations et API bien plus que de l’IA elle-même : ce sont les mêmes principes que pour tout flux automatisé entre vos outils, décrits dans notre article sur la connexion des outils par API et webhooks.
Comment démarrer un premier projet d’agent sans prendre de risque ?
Une approche progressive limite le risque et permet de mesurer la valeur réelle avant d’investir davantage.
| Phase | Autonomie de l’agent | Ce qu’on mesure |
|---|---|---|
| 1. Observation | L’agent propose, rien n’est exécuté ; on compare ses propositions aux décisions humaines | Taux de propositions correctes, types d’erreurs |
| 2. Assistance | L’agent prépare, un humain valide chaque action | Temps gagné par dossier, taux de correction |
| 3. Autonomie encadrée | L’agent exécute seul les catégories de cas à faible risque, validées sur un historique suffisant | Écarts détectés a posteriori, réclamations |
| 4. Extension | De nouvelles catégories passent en autonomie, une à une | Stabilité de la qualité dans le temps |
Pour réussir la première phase, trois conditions :
- Choisir un processus mesurable : on sait combien de cas sont traités, en combien de temps, avec quel taux d’erreur aujourd’hui.
- Disposer de données propres : un agent qui consulte un CRM rempli de doublons produira des propositions médiocres, quel que soit le modèle utilisé.
- Impliquer les équipes métier dès le départ : ce sont elles qui savent reconnaître une bonne proposition et qui valideront les actions.
Une erreur fréquente consiste à vouloir un agent « généraliste » qui fait tout. Un agent spécialisé sur un processus, avec trois ou quatre outils bien délimités, est plus fiable, plus simple à tester et plus facile à faire accepter par les équipes.
Agent du marché ou agent intégré sur mesure ?
Les suites bureautiques et les CRM proposent désormais des agents prêts à l’emploi, par exemple dans l’environnement Microsoft 365. Ils conviennent aux tâches génériques qui restent dans l’outil de l’éditeur : résumer une réunion, rédiger un e-mail, chercher un document.
Un agent intégré sur mesure se justifie lorsque le processus traverse plusieurs outils (CRM, ERP, messagerie, outil métier), lorsqu’il repose sur des règles propres à l’entreprise, ou lorsque la traçabilité et le contrôle des droits doivent être maîtrisés finement. Dans ce cas, l’agent devient une brique d’une application métier, avec ses écrans de validation, son journal et ses tests.
Vous avez repéré un processus qui pourrait bénéficier d’un agent IA ? Décrivez-le dans notre diagnostic de projet : nous vous aidons à déterminer si un agent, un simple workflow ou une intégration classique est la bonne réponse.
