Agents IA en entreprise : ce qui marche, ce qui échoue

Gartner prévoit que plus de 40 % des projets d’IA agentique seront annulés d’ici fin 2027, faute de cas d’usage clair ou de retour sur investissement mesurable. Le cabinet estime par ailleurs qu’une centaine de fournisseurs seulement, sur les milliers qui revendiquent l’agentique, proposent réellement des agents plutôt qu’un chatbot ou un robot logiciel rebaptisé.

Ce guide sert à situer votre projet : ce qu’un agent fait qu’un chatbot ne fait pas, ce qu’il faut avoir avant de commencer, ce que l’AI Act impose à vos agents, et pourquoi les 40 % échouent.

Sommaire

• Quatre niveaux d’automatisation, et lequel vous concerne
• Ce qu’il y a dans un agent
• Ce qu’il faut avoir avant de commencer
• Ce que l’AI Act impose à vos agents
• L’injection de prompt et les identités machine
• Pourquoi 40 % des projets seront annulés
• Par où commencer

Quatre niveaux d’automatisation, et lequel vous concerne

Le mot « agent » recouvre aujourd’hui quatre familles d’outils qui ne demandent ni le même budget, ni les mêmes compétences, ni les mêmes garde-fous.

Un prestataire ayant mené une quarantaine de projets de ce type formule une règle que nous partageons : dans neuf cas sur dix, mieux vaut commencer par une automatisation classique avant d’ajouter une couche d’agent. Un workflow n8n ou un robot RPA traite très bien une tâche stable et prévisible, pour un coût sans commune mesure.

L’agent devient utile ailleurs, sur les exceptions et les décisions contextuelles. Un processus qui fonctionne à 95 % avec des règles et qui déraille sur les 5 % restants est un bon candidat : l’agent traite les 5 %, les règles gardent le reste.

Si votre besoin consiste à répondre à des questions plutôt qu’à agir, lisez plutôt notre page sur le chatbot d’entreprise.

Ce qu’il y a dans un agent

Quatre briques, et la quatrième décide souvent du sort du projet.

• Un modèle de langage qui raisonne sur la situation et décide de l’action suivante.
• Un orchestrateur qui tient la boucle : agir, observer le résultat, reconsidérer, recommencer.
• Des outils exposés au modèle par appel de fonction : interroger une base, appeler une API, lire un document, écrire dans un CRM, envoyer un message.
• Une mémoire, courte pour la conversation en cours, longue pour ce que l’agent doit retenir d’une session à l’autre.

Un prestataire ayant suivi douze agents déployés chez ses clients en 2025 et 2026 rapporte que neuf d’entre eux sont utilisés quotidiennement, contre trois sur huit l’année précédente avec des chatbots. La variable qui séparait les deux cohortes n’était pas le modèle de langage employé, mais la présence d’une mémoire longue. Les agents qui repartent de zéro à chaque session sont abandonnés en moins de trois semaines.

Ce qu’il faut avoir avant de commencer

Un agent agit dans vos systèmes. Trois conditions conditionnent donc le projet avant toute question de modèle ou de framework.

Des API sur les systèmes concernés. Un agent qui doit mettre à jour votre CRM a besoin d’y écrire. Si l’accès passe par une interface humaine sans API, vous retombez sur du RPA, avec sa fragilité.

Des droits d’accès définis par rôle. L’agent aura une identité technique, des jetons, des clés. Ces identités machine se gouvernent comme des comptes utilisateurs, et elles sont rarement supervisées avec la même attention.

Une définition écrite de ce que l’agent ne fait pas. La liste est courte à établir et elle vous évitera l’essentiel des incidents : supprimer des données, envoyer un message externe sensible, valider un paiement, modifier un contrat, traiter une donnée de santé, RH ou financière, déclencher une action qui touche directement un client ou un salarié. Ces opérations passent par une validation humaine.

Ce que l’AI Act impose à vos agents

Le règlement européen s’applique par étapes, et deux échéances concernent directement les agents.

Depuis le 2 août 2026, les obligations de transparence de l’article 50 sont opposables. Un agent qui interagit avec une personne doit lui indiquer qu’elle s’adresse à un système d’IA, et les contenus qu’il génère doivent porter un marquage lisible par machine. C’est la règle la plus souvent ignorée, parce qu’elle paraît anodine.

Au 2 décembre 2027 s’appliqueront les obligations des systèmes à haut risque de l’annexe III, reportées de seize mois par le Digital Omnibus entré en vigueur le 27 juillet 2026. Les systèmes intégrés aux produits réglementés de l’annexe I suivront au 2 août 2028. Les sanctions atteignent 35 millions d’euros ou 7 % du chiffre d’affaires mondial pour les pratiques interdites, avec des plafonds inférieurs pour les autres manquements.

Ces seize mois se consomment vite. Le point qui surprend le plus les directions : la classification en haut risque ne dépend pas de l’exposition publique du système, mais de sa fonction. Un agent qui intervient dans une décision de recrutement, de promotion ou d’évaluation relèvera de l’annexe III même s’il n’est utilisé qu’en interne, par une seule équipe RH, sur un intranet fermé.

Les obligations qui suivront sont substantielles : documentation technique, gestion des risques, supervision humaine effective, enregistrement dans la base européenne. Une organisation qui déploie aujourd’hui son agent avec un outil low-code, sans journalisation ni documentation, aura tout à reconstruire.

La question à poser avant de développer reste la même : cet agent intervient-il dans une décision qui affecte une personne ? Si oui, le cadrage réglementaire précède le développement. Le détail des échéances figure dans notre guide de l’AI Act.

L’injection de prompt et les identités machine

Microsoft décrit l’injection de prompt comme un phishing de nouvelle génération, en observant que les agents disposent de plus d’accès et de moins d’instinct de sécurité que les personnes dont ils reprennent les tâches.

Le mécanisme se comprend en une phrase. Un agent chargé de résumer les factures entrantes lit ce qu’on lui envoie. Une facture contenant une instruction dissimulée peut donc lui demander de transmettre les suivantes à une adresse externe. Contrairement au phishing classique, l’attaque ne demande aucun clic humain : l’agent exécute, parce que c’est son travail d’exécuter.

Deux cas documentés donnent la mesure du risque. Une banque asiatique a vu son agent de vérification d’identité approuver des dossiers frauduleux après manipulation de sa base documentaire. Et la décision Air Canada de 2024 a établi que l’entreprise qui déploie un agent répond de ce qu’il fait, y compris quand il se trompe.

Les protections tiennent en quelques principes. Traiter tout contenu externe comme non fiable. Valider les appels d’outils côté serveur, et non dans le prompt. Appliquer le moindre privilège sur les données comme sur les connecteurs. Journaliser les plans, les appels et leurs effets. Prévoir un arrêt d’urgence.

Les outils de prévention des fuites de données ne suffisent pas ici. Ils ont été conçus pour des humains qui envoient des fichiers, et fonctionnent au niveau du réseau ou du poste. Un agent fait des appels d’API et orchestre des workflows, ce que ces outils ne voient pas.

Pourquoi 40 % des projets seront annulés

Les causes que nous rencontrons sont toujours les mêmes, et aucune n’est liée au modèle choisi.

Le cas d’usage n’en était pas un. Le projet démarre parce que la technologie existe, pas parce qu’un processus coûte cher. Personne n’a chiffré le temps consommé aujourd’hui, donc personne ne pourra mesurer le gain.

L’agent n’était qu’un chatbot rebaptisé. C’est ce que Gartner appelle l’agent washing. Le fournisseur promet un agent, livre une interface de conversation branchée sur une base documentaire, et le client découvre au bout de trois mois que rien ne s’exécute.

Le périmètre était trop large. Un agent censé traiter toutes les demandes d’un service les traite toutes mal. Les projets qui aboutissent commencent par un processus, parfois par une seule étape d’un processus.

Personne ne pouvait dire si l’agent avait raison. Sans jeu de cas de référence ni taux de réussite mesuré avant la mise en service, la décision de déployer se prend au ressenti. La première erreur visible suffit alors à disqualifier l’outil auprès des équipes.

Par où commencer

1. Chiffrez le processus avant d’en parler à un prestataire. Combien d’heures par semaine, sur quel volume, avec quel taux d’erreur actuel. Sans ces trois chiffres, aucun retour sur investissement ne sera démontrable.
2. Vérifiez qu’une automatisation classique ne suffit pas. Si le processus est stable et les règles connues, un workflow coûtera dix fois moins cher.
3. Écrivez la liste des actions interdites avant d’écrire la première ligne de code.
4. Testez la résistance à l’injection sur les agents qui lisent du contenu venu de l’extérieur, courriels, documents, formulaires.
5. Déployez par paliers d’autonomie : lecture seule, puis actions réversibles, puis actions irréversibles sous validation humaine.

Ces arbitrages supposent des équipes qui comprennent ce qu’elles pilotent. Notre formation agent IA couvre la conception, les garde-fous et la gouvernance sur une journée.

Un projet cadré ainsi produit un premier agent en production en quelques mois. Un projet qui commence par le choix du framework découvre au sixième mois que les API nécessaires n’existent pas.

Notre agence d’automatisation IA cadre ce type de projet, le construit et le met en production, avec cession du code source.

À propos de l’auteur

Charles GERARD est Directeur IA chez Atheïa, cabinet de conseil en data et intelligence artificielle. Il conçoit et industrialise des systèmes d’IA pour des grands comptes de la banque, de l’assurance, du retail et du transport, avec une pratique des architectures RAG, des systèmes agentiques et de leur gouvernance en environnement réglementé.