La plupart des pilotes d'IA s'enlisent pour des raisons qui ont peu à voir avec le modèle. Les données sont plus désordonnées que dans la démo, l'ERP n'offre aucune connexion exploitable, personne n'est responsable du résultat, personne n'approuve les résultats et personne n'a défini ce que « terminé » veut dire. Un pilote arrive en production quand un workflow obtient un responsable, une étape d'approbation et un indicateur avant toute construction.
#À retenir
- Un pilote qui a fonctionné en démo a prouvé le modèle, pas le workflow qui l'entoure.
- Les blocages habituels sont les données, l'intégration aux systèmes anciens, la responsabilité, l'approbation et l'absence de définition de « terminé ».
- Brancher l'IA sur un vieil ERP dépourvu d'API exploitable est un projet d'intégration que la plupart des plans de pilote n'avaient jamais prévu.
- Un pilote passe en production quand une personne nommée en est responsable et qu'une autre approuve ce qu'il produit.
- Commencez par un workflow et de vrais utilisateurs, pas par trois pilotes et un comité de pilotage.
#Pourquoi les pilotes d'IA s'enlisent-ils avant la production ?
Vous n'êtes pas seul si trois pilotes se sont terminés en trois démos. Gartner, juillet 2024 prévoyait que 30 % des projets d'IA générative seraient abandonnés après la preuve de concept, en citant une qualité de données insuffisante, des contrôles des risques faibles et une valeur métier peu claire. Un rapport du MIT, relayé par Virtualization Review à propos du rapport MIT NANDA, août 2025, a constaté que 95 % des organisations n'avaient tiré aucun retour économique de l'IA générative.
Dans les entreprises à forte composante opérationnelle, les cinq mêmes lacunes reviennent sans cesse :
- Données : le pilote a tourné sur un échantillon propre. Les vraies entrées arrivent sous forme de PDF scannés, de formulaires à moitié remplis et de messages en arabe et en anglais.
- Intégration : le workflow repose sur un ERP vieux de quinze ans. Lire dedans et y réécrire n'a jamais été cadré.
- Pas de responsable : le pilote appartenait à une équipe innovation, et le service censé l'utiliser ne l'avait jamais demandé.
- Pas d'étape d'approbation : personne n'a décidé qui vérifie les résultats avant qu'ils n'atteignent un client, un fournisseur ou la comptabilité.
- Pas de définition de « terminé » : le pilote a été jugé sur l'impression qu'il faisait, pas sur un chiffre que le service suit déjà.
#Qu'est-ce qui change quand un pilote est conçu pour tourner en production ?
L'ordre du travail change. Au lieu de commencer par un modèle, Stennir commence par cartographier un workflow avec la personne qui le fait tourner : où arrive l'entrée, quelles règles s'appliquent, où va le résultat et quelles exceptions demandent du jugement. Cette carte devient la spécification, et elle montre tôt si le vrai blocage vient des données ou de l'intégration.
Trois points sont ensuite convenus avant la construction : qui est responsable du workflow côté client, qui approuve les résultats, et quel indicateur signifie « terminé », comme la taille du retard accumulé ou la part des cas traités sans reprise. La construction se fait dans les systèmes que l'équipe utilise déjà, chaque action est journalisée, et de vrais utilisateurs la voient dès la première version.
#Comment passer un prototype de hackathon en production en toute sécurité ?
Un prototype de hackathon est une preuve utile : il montre que la tâche est faisable. Ce qui lui manque en général, c'est la gestion des erreurs, les contrôles d'accès, la journalisation, un jeu de test construit à partir de cas réels et un moyen de l'arrêter. Traitez le prototype comme un brouillon de spécification, pas comme la première version.
La voie sûre consiste à reconstruire les parties qui touchent les clients ou l'argent derrière une étape d'approbation, à les tester sur un ensemble de cas passés réels et à ajouter un suivi avant d'ouvrir à davantage d'utilisateurs. L'exemple détaillé de passage d'un prototype d'IA en production déroule ces étapes sur un workflow.
We are
Stennir fait passer un workflow du pilote à la production dans vos propres systèmes, avec un responsable nommé, une personne qui approuve les résultats et un indicateur convenu dès le départ.
We aren't
Stennir n'est pas un laboratoire qui multiplie les pilotes, ni un éditeur de plateforme qui vous demande de transférer votre travail dans un nouvel outil.
#Notre projet est bloqué au stade de l'essai. Par quoi commencer ?
Choisissez le pilote que le service concerné veut vraiment, et demandez à la personne qui l'utiliserait au quotidien de décrire le travail qu'il remplace. Si elle n'y arrive pas, le pilote résolvait le mauvais problème. Si elle y arrive, notez les exceptions, nommez un approbateur et convenez de l'indicateur. Cela révèle en général si la lacune tient aux données, à l'intégration ou à la responsabilité.
Les équipes du Golfe ajoutent souvent une étape : le workflow doit traiter des entrées en arabe et en anglais, pas seulement l'échantillon en anglais sur lequel le pilote a été testé. Le vérifier tôt évite un nouvel enlisement plus tard.
#Que doit faire ensuite un directeur des opérations dont les pilotes sont bloqués ?
Choisissez un pilote bloqué et un responsable, puis venez avec les deux pour parler de mise en œuvre de l'IA : Stennir construit un workflow qui tourne avec de vrais utilisateurs et en assure le suivi ensuite. Si vous ne savez pas quel pilote le mérite, le conseil en IA classe d'abord les options. Consultez aussi l'IA pour les opérations. Vous pouvez faire l'évaluation de maturité gratuite ou réserver un appel de 30 minutes.
#Questions fréquentes
De quoi avez-vous besoin de notre part pour relancer un pilote bloqué ?
Du pilote lui-même, de la personne qui l'utiliserait chaque jour, d'un ensemble de cas passés réels et d'un accès aux systèmes dans lesquels il doit lire et écrire. Vous désignez aussi qui approuve les résultats. Stennir s'en sert pour cartographier le workflow et identifier laquelle des cinq lacunes l'a arrêté.
Pouvez-vous réutiliser ce que nos développeurs ont déjà construit ?
Souvent, oui. Un prototype montre quels prompts et quelles étapes fonctionnent. Stennir garde ce qui tient face aux cas réels et reconstruit ce qui manque pour la production : contrôle d'accès, journalisation, gestion des erreurs, étape d'approbation et suivi. Vos développeurs peuvent rester impliqués et gardent le code, qui reste dans vos comptes.
Cela fonctionne-t-il avec un vieil ERP sans véritable API ?
C'est possible, mais c'est un travail d'intégration, cadré comme tel dès le départ. Les options incluent la lecture d'exports, l'accès direct à la base de données en lecture seule ou le passage par les écrans que votre équipe utilise déjà. Stennir annonce l'approche avant de construire, pour que personne ne soit surpris plus tard.
Qu'est-ce qui pourrait mal tourner en production alors que tout allait bien en pilote ?
Les vraies entrées sont plus désordonnées, les volumes plus élevés, et des cas limites apparaissent que l'échantillon ne contenait pas. C'est pourquoi Stennir garde une personne qui approuve les résultats, journalise chaque action, teste sur des cas passés réels et suit les résultats dès l'arrivée des vrais utilisateurs, pour que les problèmes apparaissent sous forme de chiffres plutôt que de réclamations.
