Pourquoi un PoC IA réussi dans un service ne se généralise presque jamais ailleurs

Un pilote d'intelligence artificielle qui fonctionne dans un service ne dit presque rien sur ce qui se passera dans le service voisin. C'est l'un des constats les plus mal anticipés par les PME qui investissent dans un premier projet IA, et l'un des plus coûteux quand il arrive trop tard dans le calendrier.

Le scénario se répète avec une régularité frappante. Un service, souvent le commercial ou le marketing, lance un pilote IA sur un usage précis, la qualification de leads, la rédaction de comptes-rendus, l'analyse de retours clients. Les données sont propres, le process est déjà documenté informellement, et l'utilisateur qui pilote le test est volontaire et compétent. Les résultats sont bons, parfois excellents. La direction en conclut naturellement que l'IA fonctionne dans l'entreprise, et décide de généraliser l'approche à la production, au service client ou aux ressources humaines. C'est à ce moment que les difficultés commencent, et elles ne viennent presque jamais de l'outil.

Le problème central est celui des silos de données. Le service qui a réussi son PoC disposait souvent d'un CRM structuré, d'un historique propre et d'un volume suffisant pour que l'IA produise des résultats fiables. Le service qui tente ensuite de reproduire ce succès découvre fréquemment que ses propres données sont dispersées entre plusieurs fichiers, mal étiquetées, ou tout simplement absentes sous forme exploitable. Reformater ces données avant de pouvoir lancer un usage IA comparable demande souvent plus de temps que le pilote initial. Ce délai n'est pas un échec du projet, c'est une étape que le calendrier n'avait tout simplement pas prévue.

Un confrère consultant qui accompagne des ETI industrielles partageait récemment une observation similaire, un PoC IA réussi en trois semaines sur la maintenance prédictive d'une ligne de production ne s'est pas généralisé aux autres lignes avant huit mois, non pas à cause de la technologie, mais parce que chaque ligne avait ses propres capteurs, ses propres formats de log et son propre historique de pannes. Le pilote avait démontré la faisabilité technique. Il n'avait rien démontré sur la répétabilité du travail de préparation des données.

Cette réalité invite à repenser le moment où l'on décide d'un budget d'industrialisation. Beaucoup d'entreprises attendent la fin du PoC pour se poser la question de la généralisation, une fois les résultats obtenus. C'est trop tard. La question de la reproductibilité, quelles données sont nécessaires ailleurs, quel process doit être documenté indépendamment de l'outil utilisé, quel service serait le deuxième candidat naturel, devrait être posée avant même de lancer le pilote. Un PoC pensé dès le départ pour être généralisable coûte à peine plus cher qu'un PoC isolé, et évite huit mois d'attente ensuite.

Il existe aussi un biais moins visible, celui de l'utilisateur pilote lui-même. Le collaborateur qui teste un PoC IA est presque toujours volontaire, curieux et déjà à l'aise avec les outils numériques. Cette motivation initiale masque une partie du travail réel de conduite du changement que la généralisation devra affronter, former des équipes moins volontaires, qui n'ont pas choisi le projet et qui découvrent l'outil sans l'avoir expérimenté par curiosité personnelle. Un pilote mené par une personne moyennement à l'aise avec le numérique, plutôt que par le collaborateur le plus enthousiaste du service, donne une image plus honnête de ce que sera réellement l'adoption à l'échelle de l'entreprise.

La généralisation elle-même gagne à ne pas rester portée par le seul service pilote. Celui qui a réussi son test connaît l'usage, mais rarement les contraintes des autres services. Une coordination transverse, portée par la direction générale ou un référent IA identifié, permet d'arbitrer entre les priorités de plusieurs services aux besoins différents, plutôt que de reproduire mécaniquement une solution pensée pour un contexte particulier. Pour les flux qui relient plusieurs services autour d'un même processus IA, des outils d'automatisation comme Make.com évitent de redévelopper chaque intégration à la main, ce qui réduit sensiblement le coût de cette deuxième vague.

C'est exactement ce que l'étape Modélisation de la méthode IMPACT cherche à anticiper, avant même le lancement du premier pilote : documenter le process indépendamment de l'outil retenu, et repérer dès le départ quelles données seraient nécessaires dans les autres services concernés par une future généralisation. Un PoC réussi reste une bonne nouvelle, il démontre qu'un usage précis fonctionne dans des conditions précises. Ce n'est simplement pas, à lui seul, une preuve que l'entreprise entière est prête à passer à l'échelle. Un diagnostic de 5 jours ouvrés permet de vérifier cette reproductibilité avant de lancer le pilote suivant.