Choisir son premier chantier d'intelligence artificielle demande d'autres réflexes qu'un projet web classique. Au-delà de la valeur métier et du coût, deux critères font la loi : la tolérance à l'erreur, et l'accessibilité d'une source de référence.
Cinq questions à passer avant de dire oui, trois anti-cas à connaître, et un cas client où l'on a tracé la ligne entre IA, règles métier et humain.
Le sujet visible est rarement le bon
Quand on rénove une maison, on ne commence pas par la couleur des volets. On regarde si la toiture tient l'hiver, si la chaudière passera la saison, si les fondations encaissent. Pourtant, beaucoup d'entreprises lancent leur premier projet d'agent IA à l'inverse : elles choisissent ce qui brille, pas ce qui dure.
Le chatbot pour le service client, l'agent commercial qui pré-rédige les propositions, le copilote qui prend des notes en réunion. Trois projets qui sonnent bien dans une présentation de direction, qui font le tour des couloirs. Trois projets qui ne dépassent souvent jamais le stade du prototype.
Selon Gartner, plus de 40 % des projets d'IA agentique seront abandonnés d'ici fin 2027, principalement à cause de coûts qui dérapent, d'une valeur business floue, et de contrôles de risque insuffisants. Derrière le chiffre, presque toujours le même scénario : trois mois après le lancement, le prototype dort dans un coin de Drive, et personne n'ose le dire en réunion. Le chiffre ne dit pas que l'agentique ne marche pas. Il dit que beaucoup d'entreprises ont mal choisi par où démarrer.
La vraie question n'est pas « quel cas d'usage prioritaire ? ». C'est « où peut-on s'autoriser à se tromper trois fois avant que ça tourne ? ». Et accessoirement : « qui suit ça pendant 18 mois ? ». Le bon premier cas est souvent un flux ennuyeux qui tourne déjà en sous-marin dans les équipes opérationnelles. C'est là que se cachent les gains réels.

Cinq questions à se poser avant de dire oui
Un dirigeant sait évaluer un projet web : valeur métier, complexité de fabrication, coût total, risque. Cette grille fonctionne depuis vingt ans. Elle est juste insuffisante quand le projet implique un agent IA. Voici les cinq questions qu'on déroule quand on cadre un dossier IA.
Le flux tolère-t-il une marge d'imperfection ?
Un calcul qui se trompe 5 % du temps, c'est un projet raté. Un agent qui se trompe 5 % du temps sous l'œil d'un humain, c'est un succès qu'on industrialise. Si l'erreur produit un dommage immédiat (médical, juridique, financier direct), ce n'est pas le bon terrain pour démarrer.
Existe-t-il une source de référence accessible ?
Si on retire l'agent et qu'on demande à un humain de faire le travail, sur quoi s'appuie-t-il ? Une doctrine, un catalogue, un historique, un référentiel ? Si la réponse est claire, l'agent peut s'y connecter. Si la réponse est floue (« c'est l'expérience, c'est la maison »), l'agent va inventer poliment.
Le volume rend-il l'investissement rentable ?
Un agent demande de la supervision et du suivi dans la durée. Pour vingt occurrences par mois, l'investissement met longtemps à se rembourser. À deux mille, le calcul change immédiatement.
Les contraintes de données autorisent-elles le mode le plus simple ?
Les données manipulées peuvent-elles transiter par un fournisseur extérieur, ou exigent-elles une installation chez le client ? Cette question est généralement traitée trop tard, et c'est probablement le critère qui transforme le plus radicalement un projet. Un service IA hébergé à quelques euros le millier de requêtes, ou un serveur installé chez le client à plusieurs centaines d'euros par mois : ce n'est pas le même projet, pas le même délai, pas le même budget.
Y a-t-il quelqu'un pour rattraper les cas hors cadre, et qui restera ?
Un agent IA orphelin meurt en six mois. Il faut un porteur métier identifié, qui accepte le mandat de suivre le dispositif sur 18 mois. La réponse « on verra plus tard » condamne le projet avant le démarrage.
Les cinq questions ne donnent pas une note sur dix. Elles s'utilisent comme un filtre. Si l'une se passe mal, on remet le cas sur la table. Si toutes se passent bien, on a un premier cas viable.
Trois anti-cas qu'on écarte d'office
Certains terrains paraissent évidents et sont des pièges. Trois qu'on écarte dès le premier cadrage.
- Le projet exposé directement au client final. Le chatbot sur le site corporate, l'assistant qui répond aux clients en direct. C'est tentant parce que c'est démonstratif. C'est précisément pour ça que c'est mal calibré. Une seule réponse à côté en clientèle, et le projet vit avec une réputation dégradée pendant des mois.
- L'expertise métier rare et non documentée. L'expert qui sait juger une situation complexe l'a appris en quinze ans, il l'a très peu écrit. Si on lui demande de former l'agent, on lui demande en réalité de documenter en six semaines ce qu'il fait par intuition. Le résultat est presque toujours décevant. On peut y arriver, mais pas comme premier projet.
- Le remplacement d'une décision, plutôt que sa préparation. L'agent prépare, l'humain tranche. Pas l'inverse. Un bon premier cas amène une recommandation argumentée à un humain qui valide vite. Pas une décision finale prise dans l'ombre.
Un dossier au passage du filtre
Un cas qu'on instruit en ce moment. Un distributeur d'équipements médicaux qui assure le support de premier niveau pour ses clients finaux (cabinets, laboratoires). L'idée initiale, version comité de direction : un chatbot sur le site web, qui répondrait directement aux clients en cas de panne. Sujet visible, idée vendeuse. Premier anti-cas de notre liste.
Passage au filtre.
Les trois premières questions passent vite. L'erreur est rattrapable tant qu'on garde l'humain entre l'agent et le client. Les sources de référence sont là, fraîches et structurées : la base d'historique du support du distributeur, la documentation constructeur, les FAQ des fabricants. La plupart des cas qu'on voit passer en ont une, parfois deux. Trois sources, c'est rare et précieux. Sur le volume, plusieurs centaines de structures clientes et un flux journalier répétitif, le calcul est rapide.
C'est sur la question 4 que le projet change de forme. Le client a une doctrine claire sur ses données : aucune ne sort de son infrastructure, quelles que soient les garanties contractuelles d'un fournisseur. Ce n'est pas négociable. La conséquence est immédiate. L'idée de l'agent qui répond en direct au client sur le site web devient secondaire. La priorité bascule vers un agent qui assiste les téléopérateurs en interne, installé chez le client, alimenté par les trois sources, qui suggère une réponse que l'humain valide avant envoi. Même technologie, projet différent. Plusieurs semaines de mise en place supplémentaires, un budget infrastructure récurrent.
Reste la cinquième question. L'équipe support existe, elle change de mode de travail. Le responsable du service prend le mandat sur les 18 prochains mois. Plus de souffle, pas plus de tâches, un porteur identifié.
L'idée finale ne ressemble plus au chatbot client de départ. Elle est plus simple à livrer, plus utile au métier, et elle évite le piège qu'on aurait découvert au bout de trois mois si on était partis en prototype sans avoir traité la question 4.
Retour terrain : l'IA là où on l'attend le moins
Tenir le premier kilomètre
Cette grille est une posture autant qu'un outil. Elle suppose qu'on accepte de retarder le premier prototype d'une ou deux semaines pour s'assurer que le cas qu'on s'apprête à lancer a les caractéristiques qui font qu'il peut vivre. Ces deux semaines sont probablement les mieux investies de l'ensemble du projet.
Elle suppose aussi qu'on accepte de dire non à des sujets vendeurs pour dire oui à des sujets ingrats. Le chatbot pour le service client se défend mieux en comité de direction que l'agent qui assiste les téléopérateurs. Sauf à montrer qu'à dix-huit mois, l'un est en production et l'autre est mort.
On voit régulièrement des dirigeants arriver enthousiastes avec un projet, et repartir tout aussi enthousiastes avec une version transformée. C'est probablement le moment le plus intéressant du cadrage.
Le premier kilomètre n'a pas besoin d'être beau. Il a besoin d'être tenu.