Pourquoi un cas d’usage d’IA sans responsable métier ne dépasse jamais le pilote

La séquence est devenue familière. Un cas d’usage est identifié, un prototype est construit en quelques semaines, la démonstration impressionne. Puis rien. Six mois plus tard, personne ne s’en sert, et l’entreprise conclut que l’IA n’était pas pour elle.

Ce n’est presque jamais un problème de technologie. Les projets qui aboutissent ont tous le même point commun, et les projets qui meurent partagent la même absence : quelqu’un dont le résultat dépend de l’outil.

Le mécanisme

Un pilote porté par la direction informatique ou par un prestataire n’a pas de propriétaire métier. Personne ne perd rien s’il s’arrête. Personne ne se bat pour l’imposer dans les habitudes, personne n’arbitre quand il faut modifier un processus pour qu’il fonctionne, personne ne défend le budget d’industrialisation. L’outil reste une curiosité.

À l’inverse, un responsable commercial dont le taux de transformation dépend d’un outil de préparation d’offres devient son meilleur avocat. Il en signale les défauts, il forme ses équipes, il réclame les évolutions.

Comment qualifier un cas d’usage

• Formuler le problème sans le mot « IA ». Si c’est impossible, il n’y a pas de problème métier, seulement une envie de faire de l’IA.
• Nommer un responsable métier. Pas un sponsor de principe : quelqu’un dont un indicateur bougera si l’outil fonctionne.
• Vérifier les données avant de commencer. Un cas d’usage qui repose sur des données non fiables est à reporter, pas à lancer.
• Chiffrer le gain attendu, même grossièrement. Un ordre de grandeur suffit à trancher.
• N’en lancer qu’un à la fois, jusqu’à ce qu’il ait produit un résultat mesuré.

Une dernière observation, contre-intuitive : les usages qui fonctionnent le mieux en PME portent rarement sur ce que quelqu’un faisait déjà. Ils portent sur ce que personne ne faisait, faute de temps : exploiter des années de documents, suivre un marché en continu, traiter le premier niveau des demandes clients.