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

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

Le facteur qui distingue le mieux un projet d'agent IA qui tient ses promesses d'un projet qui s'arrête en silence n'est presque jamais le modèle retenu : c'est le cas d'usage choisi au départ. Le rapport The GenAI Divide, publié en juillet 2025 par le MIT NANDA à partir de plus de 300 déploiements d'IA générative analysés et de 52 entretiens structurés, constate que 95 % des pilotes — agents inclus — ne produisent aucun impact mesurable sur le résultat financier, malgré 30 à 40 milliards de dollars investis collectivement. Les 5 % qui réussissent partagent des traits communs.

Sept critères reviennent pour repérer ces cas avant de s'engager. Aucun n'est décisif isolément, mais un candidat qui n'en coche presque aucun survit rarement au-delà du pilote :

• 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 constate que les déploiements pilotés par les équipes de terrain avancent plus vite vers la production, décisions et ajustements se prenant au contact du 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 facteur que le même rapport associe à une adoption plus durable.
• 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. Le meilleur retour se situe, selon MIT NANDA, dans l'automatisation interne : 2 à 10 millions de dollars d'économies annuelles documentées sur le service client et le traitement documentaire, environ 1 million de dollars sur le contrôle des risques financiers, et une réduction de 30 % des dépenses d'agences externes ; plus de la moitié des budgets observés vont pourtant vers la vente et le marketing, au rendement plus superficiel. 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 du marché plutôt qu'un développement sur mesure, pour ce premier cas : les outils achetés atteignent le stade du déploiement à peu près deux fois plus souvent que les développements internes, selon le même rapport — 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 absolument

Trois profils de mauvais candidats reviennent le plus souvent, et font 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. Un agent reproduit ce qu'on lui montre : sur un processus déjà chaotique, il automatise 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, documente que les causes d'échec des projets d'IA touchent le plus souvent la définition du problème et la qualité des données, rarement l'algorithme — un processus instable est, par construction, un problème mal défini.

Une décision à fort enjeu financier ou juridique

Deux précédents 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 tribunal civil de Colombie-Britannique 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 ou les expulsions. 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 : aucun de ces terrains n'est un premier cas raisonnable, quelle que soit la qualité du 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.

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 indiscutable 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, la moitié des angles morts de l'agent. Le modèle de langage sous-jacent, souvent la première question posée en semaine 2, compte généralement moins à ce stade que le périmètre et les garde-fous — un sujet traité dans notre pilier IA et 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 le point le plus souvent sauté, parce qu'il demande un effort avant même de savoir si le projet ira au bout. Quatre indicateurs suffisent dans la plupart des cas, 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, presque toujours de façon optimiste.
• 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 reviennent souvent : 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 jamais 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.

Les critères d'arrêt manquent rarement pour des raisons techniques : c'est l'équipe qui a construit le pilote, souvent sous le parrainage d'un dirigeant qui l'a annoncé en interne, et personne n'a 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. Le coût réel se prend ailleurs, plus tard et en plus grand : selon Gartner, plus de 40 % des projets d'IA agentique en entreprise devraient être abandonnés d'ici fin 2027, pour cause de coûts qui dérapent, de valeur métier mal démontrée ou de garde-fous insuffisants — faute d'avoir fixé un critère d'arrêt dès le pilote, la plupart ont avancé par inertie budgétaire jusqu'à ce que l'addition devienne trop visible. Un « non » écrit en semaine 6 coûte quelques semaines ; le même « non », découvert dix-huit 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 dossier cas d'usage par secteur aide à identifier le cas suivant ; un premier échange pour cadrer le vôtre reste la façon la plus directe d'avancer, via une demande de devis.

Questions fréquentes

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

Le meilleur premier cas est 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. Il 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 ?

Six semaines suffisent généralement à 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 revient presque toujours à sauter l'étape de test à blanc, celle 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 : selon Gartner, plus de 40 % des projets d'IA agentique en entreprise seront abandonnés d'ici fin 2027, souvent après un investissement bien supérieur à six semaines de travail, faute d'avoir tranché plus tôt. Prolonger sans nouveaux critères écrits coûte presque toujours plus cher que d'arrêter et de 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 transforme le plus souvent un pilote prometteur en incident évitable.

En résumé

• Le facteur qui décide du succès d'un premier agent IA est presque toujours le cas d'usage choisi, pas le 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 acheté plutôt que développé sur mesure.
• 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.