Déployer un premier agent IA : par où commencer

Corrigé le 22/10/2026 : la première version de cet article (23/09/2026) présentait comme établis des constats que les sources ne donnent pas : une statistique du rapport MIT NANDA (« 95 % des pilotes — agents inclus ») dont les auteurs jugent eux-mêmes les chiffres indicatifs et qui ne distingue pas les agents ; des chiffres du rapport (agences, budgets, outils achetés), anonymes, théoriques ou déclarés par les personnes interrogées, présentés plus largement ou plus fermement que dans le rapport ; une conclusion prêtée à la RAND (« rarement l'algorithme ») que son rapport ne formule pas ; une cause (« faute d'avoir fixé un critère d'arrêt ») attribuée à une prévision de Gartner dont le communiqué donne d'autres raisons ; et plusieurs fréquences sans source (« presque toujours », « la moitié des angles morts »). Les renvois vers le pilier « cas d'usage » (alors sans aucun article) et vers le pilier « IA et modèles » (qui suit l'actualité des modèles sans traiter du choix d'un modèle) sont aussi corrigés. La thèse centrale, les critères de sélection et le pilote de six semaines sont des lectures et des recommandations de la rédaction, désormais présentées comme telles. Notre politique de corrections.

Les critères d'un bon premier cas d'usage

Ce qui distingue un projet d'agent IA qui tient ses promesses d'un projet qui s'arrête en silence tient, selon nous, moins au modèle retenu qu'au cas d'usage choisi au départ ; les deux études citées ci-dessous vont dans ce sens en mettant en cause la conduite du projet plus que le modèle. Le rapport préliminaire The GenAI Divide, daté de juillet 2025 et présenté sous le nom de MIT NANDA, s'appuie sur une revue de plus de 300 initiatives d'IA rendues publiques, 52 entretiens structurés et une enquête auprès de 153 dirigeants. Il avance que, malgré 30 à 40 milliards de dollars investis par les entreprises en IA générative, les outils propres à une tâche, sur mesure ou vendus par un éditeur, ne comptent que 5 % de mises en production réussies (un effet marqué et durable sur la productivité ou le résultat financier, selon les utilisateurs ou dirigeants interrogés), ce qu'il résume par un « taux d'échec de 95 % ». Il l'explique moins par la qualité des modèles ou la réglementation que par l'approche des organisations et par des outils qui n'apprennent pas de leurs retours. Ses auteurs jugent ces chiffres « directionally accurate » (justes dans la tendance), tirés d'entretiens individuels et non de comptes d'entreprise ; des analystes en contestent la méthode. Ses chiffres ne distinguent pas les agents, que le rapport n'évoque qu'à part : il les présente comme une piste encore expérimentale. Les organisations qui réussissent, disent ses auteurs, font trois choix différents des autres : acheter plutôt que construire, confier l'initiative aux responsables de terrain plutôt qu'à un laboratoire central, et choisir des outils qui s'intègrent en profondeur et s'adaptent dans le temps.

Nous retenons sept critères pour repérer un bon premier cas avant de s'engager. Ce sont des recommandations de la rédaction, pas des résultats d'étude : certains recoupent le rapport ci-dessus, d'autres non. Aucun n'est décisif isolément, mais un candidat qui n'en coche presque aucun est un mauvais premier choix :

• Un périmètre étroit, un seul objectif mesurable. « Améliorer le service client » n'est pas exploitable ; « qualifier et router les remboursements sous 100 € » l'est.
• Une équipe métier identifiée aux commandes, pas une cellule IA centrale : MIT NANDA relève que les organisations qui réussissent confient l'initiative aux responsables de terrain plutôt qu'à un laboratoire central ; selon ses auteurs, cette initiative venue du terrain, associée à la responsabilité de la direction, a accéléré l'adoption tout en préservant l'adéquation au travail réel.
• Une intégration dans l'outil déjà utilisé au quotidien, pas un système séparé qu'il faut se souvenir d'ouvrir — un point que le même rapport range parmi les attentes des acheteurs : ne pas perturber les outils existants.
• Des actions réversibles, ou validées par un humain avant exécution. Annuler sans dommage (reprogrammer un rendez-vous, préparer un brouillon) engage bien moins de risque qu'une action définitive dès le premier essai.
• Un volume réel mais borné : assez de cas pour apprendre quelque chose de représentatif en quelques semaines, pas tout le flux d'un coup.
• Un cas interne plutôt que client final. Selon MIT NANDA, le retour est souvent le plus élevé dans des fonctions de back-office comme les opérations et la finance, alors qu'environ la moitié des budgets d'IA générative irait à la vente et au marketing (estimation théorique demandée à des dirigeants ; le rapport donne ailleurs environ 70 %). Les gains cités, d'organisations anonymes que le rapport range parmi les « best-in-class » et sans date précise, viennent du remplacement de prestataires externes : 2 à 10 millions de dollars par an en supprimant des contrats d'externalisation du service client et du traitement de documents, 1 million de dollars par an sur la gestion externalisée des risques en services financiers, et 30 % de baisse des coûts externes de création et de contenu. Exemple type : un assistant branché sur la documentation d'une équipe support via une architecture RAG, avant d'envisager un agent qui agit sur les tickets.
• Un outil d'éditeur plutôt qu'un développement interne, pour ce premier cas : dans l'échantillon du même rapport, les partenariats avec un éditeur sur des outils personnalisés et capables d'apprendre (achetés ou co-développés) ont atteint le déploiement environ deux fois plus souvent que les développements internes (environ 67 % contre 33 %, résultats déclarés par les personnes interrogées ; les auteurs précisent que cette corrélation ne prouve pas nécessairement un lien de cause à effet) — encore faut-il les choisir sur des critères vérifiés, ce que couvre notre méthodologie de test.

Ces critères éliminent plus qu'ils ne guident. Certains cas, très demandés en interne, n'en cochent presque aucun — c'est précisément ce qu'il faut savoir repérer avant de s'engager.

Les cas à éviter

Nous déconseillons avant tout trois profils de candidats : ils peuvent faire dérailler un premier projet même quand tout le reste est bien exécuté.

Un processus déjà instable

Si trois personnes de l'équipe décrivent trois façons différentes de traiter le même dossier, si le temps de traitement varie du simple au triple sans explication, ou si personne ne sait combien de fois le processus part mal aujourd'hui, ce n'est pas un bon premier cas — c'est un problème de processus à régler avant l'IA, pas avec elle. À notre avis, automatiser un processus déjà chaotique revient à en automatiser l'incohérence, et il devient impossible de savoir, une fois le pilote terminé, si un mauvais résultat vient de l'agent ou du désordre préexistant. La RAND Corporation, dans un rapport 2024 fondé sur 65 entretiens avec des data scientists de l'industrie et du monde académique, relève que les causes d'échec des projets d'IA tiennent d'abord à la définition du problème, puis à la qualité des données ; les limites de la technologie elle-même ne viennent qu'ensuite, citées par un quart à un tiers des praticiens de l'industrie interrogés. Son périmètre exclut toutefois les projets qui se contentent d'un grand modèle de langage pré-entraîné (le « prompt engineering »), ce qui en limite la portée pour des agents. Un processus instable est, par construction, un problème mal défini.

Une décision à fort enjeu financier ou juridique

Deux cas illustrent ce risque, même s'ils concernent des chatbots et non des agents au sens strict. En 2022, un chatbot d'Air Canada avait assuré à un client qu'il pouvait payer plein tarif puis demander après coup un remboursement au tarif « deuil » — une politique inexacte, contredite par la page même vers laquelle le chatbot renvoyait. Le Civil Resolution Tribunal de Colombie-Britannique, saisi d'un litige de petites créances, a jugé Air Canada responsable et l'a condamnée à indemniser le client, rejetant l'argument que le chatbot serait une entité distincte de l'entreprise (Moffatt v. Air Canada, 2024 BCCRT 149). En 2024, The Markup a montré que MyCity, le chatbot d'aide aux entreprises de la ville de New York, affirmait à tort qu'un employeur pouvait garder une part des pourboires de son personnel — l'une de plusieurs réponses erronées sur le droit du travail relevées par le média, aux côtés d'affirmations tout aussi fausses sur le logement, notamment le refus de locataires bénéficiant d'une aide au logement ou la mise à la porte d'un locataire. Ces deux systèmes répondaient sans agir : la leçon vaut plus fort pour un agent — au sens où on l'entend dans ce dossier agents IA — qui n'affiche pas une erreur mais l'exécute, remboursement envoyé, contrat modifié, commande annulée. Droit du travail, fiscalité, engagement contractuel, montant significatif : nous déconseillons ces terrains pour un premier cas, même avec un très bon modèle. Le même risque vaut dès qu'un agent vocal traite des données personnelles, avec les obligations détaillées dans notre article RGPD et callbot. Ce guide ne constitue pas un avis juridique.

L'absence de mesure de référence avant le lancement

Lancer un pilote sans avoir chiffré la situation de départ — temps, taux d'erreur, coût, volume actuels — revient à se priver, dès le premier jour, de tout moyen de prouver ensuite qu'il y a eu une amélioration. C'est l'erreur la plus silencieuse des trois : elle ne fait dérailler personne pendant le pilote, elle rend simplement son résultat impossible à trancher, dans un sens comme dans l'autre, une fois qu'il ne reste que des impressions contradictoires à comparer. Détail des indicateurs à fixer avant de commencer plus bas dans cet article.

Cadrer un pilote de six semaines

« Testons pendant six semaines et on verra » ne cadre rien : cela repousse simplement la définition du succès au moment où plus personne n'est neutre pour la juger. Voici la structure que nous recommandons, avec un jalon vérifiable à chaque étape plutôt qu'une durée écoulée.

Semaine	Jalon	Ce qui doit être vrai à la fin
1 — Cadrage	Périmètre, mesure de référence et critères d'arrêt écrits avant toute configuration	Un document d'une page, validé par le responsable métier et par qui finance le projet, fixe le cas, les chiffres de départ et les seuils de décision
2 — Construction	Connexion aux systèmes réels, permissions volontairement limitées	Autorisations, plafonds d'action et cas de transmission à un humain sont définis et testés
3 — Test à blanc	L'agent tourne en observation sur des cas réels, sans agir ni être visible des utilisateurs	Chaque décision est comparée à ce qu'aurait fait un humain ; un journal d'erreurs existe
4 — Production limitée	Traitement d'un sous-ensemble réel de cas, sous supervision rapprochée	Volume restreint ; validation avant ou vérification systématique après, selon la réversibilité
5 — Montée en charge	Volume en hausse progressive ; cas atypiques volontairement recherchés	Les indicateurs de la semaine 1 sont mesurés en continu, sur le même périmètre
6 — Bilan et décision	Chiffres de fin comparés aux chiffres de départ, selon les critères de semaine 1	Décision explicite prise — industrialiser, ajuster, ou arrêter — et documentée

Deux règles évitent que cette structure reste cosmétique. D'abord, les critères fixés en semaine 1 ne se modifient pas en cours de route : les assouplir après avoir vu les résultats revient à supprimer le pilote. Ensuite, les semaines 3 et 4 ne sont pas optionnelles, même sous pression de calendrier : sauter de la démonstration à une production non supervisée fait manquer l'étape où l'on découvre, sans conséquence réelle, les angles morts de l'agent. Pour un premier pilote, nous plaçons le choix du modèle de langage sous-jacent après le périmètre et les garde-fous ; notre pilier IA et modèles suit l'actualité des modèles.

Mesurer l'avant et l'après

Un pilote sans mesure de référence ne peut, par construction, rien prouver — c'est un point facile à sauter, parce qu'il demande un effort avant même de savoir si le projet ira au bout. Nous retenons quatre indicateurs, mesurés sur un échantillon réel avant de commencer, puis exactement de la même façon pendant et après :

• Le temps de traitement par cas, sur un échantillon réel — pas estimé de mémoire.
• Le taux d'erreur ou de reprise actuel : combien de dossiers sont repris, corrigés ou escaladés aujourd'hui, avant tout agent.
• Le coût complet par cas, temps humain inclus, pas seulement le prix affiché d'un outil.
• Un indicateur de satisfaction ou de réclamation, côté client ou équipe, pour vérifier qu'on ne gagne pas de temps en dégradant la qualité perçue.

Deux pièges sont à éviter : mesurer différemment avant et après — une impression au départ, un tableau de bord précis à l'arrivée — fabrique à elle seule une fausse amélioration ; et confondre activité et résultat, alors que le nombre de cas traités par l'agent ne dit rien de la qualité du traitement. C'est un indicateur d'activité, pas de performance, et il ne doit pas remplacer les quatre indicateurs ci-dessus dans la décision finale.

Décider d'industrialiser ou d'arrêter

Un pilote qui ne peut pas échouer n'est pas un pilote : c'est une décision déjà prise, habillée en test pour la faire accepter plus facilement. Si la direction a annoncé que l'agent serait adopté quoi qu'il arrive, ou si personne n'a le mandat explicite de dire stop, les six semaines qui précèdent ne servent à rien.

À notre avis, les critères d'arrêt manquent rarement pour des raisons techniques : l'équipe qui a construit le pilote, parfois sous le parrainage d'un dirigeant qui l'a annoncé en interne, n'a guère intérêt à porter la nouvelle d'un échec une fois les six semaines passées. D'où la nécessité de les écrire en semaine 1, signés par le responsable métier et par qui finance le projet, avant tout résultat.

Trois issues, pas deux, doivent être envisagées dès le départ :

• Industrialiser — les indicateurs de semaine 6 dépassent le seuil fixé en semaine 1, aucun incident de sécurité ou de conformité n'est survenu, et l'équipe confirme que l'agent allège sa charge plutôt que de la déplacer vers de la supervision.
• Ajuster et refixer un délai — amélioration partielle, cause identifiée et corrigible, seuils non atteints : le projet continue avec un nouveau délai fixe et de nouveaux critères écrits, pas une prolongation ouverte.
• Arrêter — aucune amélioration mesurable malgré une exécution correcte, ou un incident qui révèle un défaut de conception, ou une charge de supervision plus lourde que le travail qu'elle devait remplacer.

Arrêter à ce stade n'est pas un échec : c'est l'un des résultats que le pilote devait pouvoir produire. À notre avis, le coût réel se prend ailleurs, plus tard et en plus grand. Dans un communiqué du 25 juin 2025, Gartner prévoit que plus de 40 % des projets d'IA agentique seront abandonnés d'ici fin 2027, à cause de coûts qui montent, d'une valeur métier peu claire ou de contrôles des risques insuffisants. Le communiqué ne parle pas de critères d'arrêt : notre lecture est qu'un critère d'arrêt écrit dès le pilote évite d'avancer par inertie jusqu'à ce que l'addition devienne trop visible. Un « non » écrit en semaine 6 coûte quelques semaines ; le même « non », découvert des mois plus tard, coûte le budget et la crédibilité du projet suivant.

Si le pilote réussit, ne pas le traiter comme terminé pour autant : garder la mesure en continu, laisser la propriété à l'équipe métier plutôt qu'à une cellule centrale, et traiter chaque montée en volume comme un nouveau mini-pilote — un volume dix fois supérieur ne se comporte pas nécessairement comme le volume testé. Notre pilier cas d'usage par secteur, en cours de constitution, doit aider à identifier le cas suivant ; pour cadrer le vôtre, vous pouvez aussi passer par une demande de devis.

Questions fréquentes

Par quel cas d'usage commencer un premier projet d'agent IA ?

Nous recommandons de commencer par une tâche interne, à périmètre étroit et objectif unique, déjà prise en charge par une équipe métier identifiable, avec des actions réversibles ou validées par un humain avant exécution. Ce cas doit aussi être mesurable avant le lancement : sans chiffres de départ sur le temps, le coût ou le taux d'erreur actuels, aucune amélioration ne pourra être prouvée. À l'inverse, un processus déjà instable, une décision à fort enjeu financier ou juridique, ou un projet lancé sans mesure de référence doivent éliminer un candidat, quelle que soit sa visibilité en interne.

Combien de temps doit durer un premier pilote d'agent IA ?

Nous recommandons six semaines (une durée de référence de la rédaction, pas une norme) pour passer d'un cadrage écrit à une décision chiffrée, à condition de respecter les étapes intermédiaires : cadrage, construction à permissions limitées, test à blanc sans impact réel, production limitée sous supervision, montée en charge progressive, puis bilan. Réduire ce délai conduit à raccourcir ou à supprimer une étape ; nous déconseillons de sacrifier le test à blanc, celui qui permet de repérer les erreurs sans conséquence réelle.

Que faire si le pilote ne montre aucune amélioration après six semaines ?

Arrêter, si les critères fixés avant le lancement ne sont pas atteints malgré une exécution correcte. C'est un résultat valide, pas un échec d'équipe. À titre de repère, Gartner prévoit, dans un communiqué du 25 juin 2025, que plus de 40 % des projets d'IA agentique seront abandonnés d'ici fin 2027. Nous déconseillons de prolonger sans nouveaux critères écrits : mieux vaut arrêter et choisir un autre cas.

Faut-il commencer par un agent qui répond ou par un agent qui agit sur des systèmes réels ?

Il vaut mieux commencer par une autonomie limitée : un système qui prépare une action et la soumet à validation humaine plutôt qu'un système qui l'exécute seul dès le premier jour. Cette étape intermédiaire permet d'observer la fiabilité réelle de l'agent avant de lui retirer la validation humaine, et elle correspond à l'étape de production sous supervision du cadrage en six semaines. Étendre l'autonomie trop tôt expose à des incidents évitables.

En résumé

• Selon la lecture de la rédaction, le succès d'un premier agent IA tient d'abord au cas d'usage choisi plutôt qu'au modèle : périmètre étroit, équipe métier aux commandes, intégration dans l'outil existant, actions réversibles, volume borné, cas interne, outil d'éditeur plutôt que développement interne.
• Trois profils de cas doivent être éliminés d'emblée : un processus déjà instable, une décision à fort enjeu financier ou juridique, et tout projet lancé sans mesure de référence chiffrée.
• Un pilote de six semaines se cadre avec des jalons vérifiables — cadrage écrit, construction à permissions limitées, test à blanc, production supervisée, montée en charge, bilan chiffré — pas avec une simple durée écoulée.
• Les mêmes indicateurs doivent être mesurés avant et après, sur le même périmètre : temps, taux d'erreur, coût complet, satisfaction. Une mesure asymétrique entre l'avant et l'après fabrique de fausses améliorations.
• Trois décisions sont possibles à l'issue du pilote — industrialiser, ajuster avec un nouveau délai, ou arrêter — et elles doivent être écrites avant le lancement, pas négociées après avoir vu les résultats.

Un pilote qui ne peut pas se solder par un arrêt n'a rien testé : il a seulement retardé une décision prise d'avance.

Sources

• The GenAI Divide: State of AI in Business 2025 (MIT NANDA, rapport préliminaire, juillet 2025) — consulté le 22/10/2026 ; copie hébergée par un tiers, octet pour octet identique à celle de MLQ.ai, le fichier d'origine du MIT n'étant plus servi
• Why We Don't Believe MIT NANDA's Weird AI Study (Futuriom, 26 août 2025) — consulté le 22/10/2026
• The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed: Avoiding the Anti-Patterns of AI (RAND, RR-A2680-1, 13 août 2024) — consulté le 22/10/2026
• Moffatt v. Air Canada, 2024 BCCRT 149 (Civil Resolution Tribunal, 14 février 2024), texte officiel du tribunal — consulté le 22/10/2026
• NYC's AI Chatbot Tells Businesses to Break the Law (The Markup, 29 mars 2024) — consulté le 22/10/2026
• Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 (Gartner, 25 juin 2025) — consulté le 22/10/2026

Pour aller plus loin

• Qu'est-ce qu'un agent IA ? Définition, exemples et différences avec un chatbot
• Créer un agent IA sans coder : ce qu'un dirigeant doit savoir
• Sécurité et gouvernance des agents IA : risques, garde-fous, contrôle
• Human-in-the-loop