Pourquoi les pilotes IA en usine meurent entre la démo et l'atelier
Le pilote a été présenté au comité de direction, tout le monde a applaudi, le budget de « passage à l’échelle » a été débloqué. Six mois plus tard, le système de vision par ordinateur qui détectait 98 % des défauts en démo en attrape à peine la moitié, les contrôleurs qualité ont cessé de lui faire confiance et le projet a discrètement migré vers la rubrique « initiatives reportées ». Ce n’est pas un incident isolé ni la faute d’un intégrateur en particulier. Selon RAND, c’est ainsi que se terminent plus de 80 % des projets IA en entreprise – et presque toujours pour des raisons visibles avant même le lancement.
Le plus dérangeant dans cette statistique, ce n’est pas le taux d’échec en soi, mais le fait que la technologie n’y est presque jamais pour rien. La RAND Corporation, dans son étude de 2024, a interrogé 65 data scientists et ingénieurs cumulant entre 5 et 30 ans d’expérience et a décortiqué les raisons pour lesquelles les projets IA n’atteignent pas la production. La conclusion est presque vexante : la cause d’échec la plus fréquente, c’est que les dirigeants et les équipes techniques n’ont pas compris le même problème. Pas les données, pas le modèle, pas les GPU. La formulation de la tâche.
Pour un responsable de production, c’est une bonne nouvelle. Si le problème venait de la technologie, il ne resterait qu’à attendre la prochaine génération de modèles. Mais puisqu’il s’agit de décisions managériales, on peut influer sur le résultat. Voici sept signes que votre pilote est condamné, tirés de RAND, McKinsey et de retours d’expérience dans l’automobile. Chaque signe est une question à poser à votre équipe avant de signer le budget de passage à l’échelle.
D’abord l’échelle : pourquoi « le pilote a réussi » ne veut rien dire
Lancer un pilote aujourd’hui n’a rien de compliqué. Le mener jusqu’à un usage quotidien sur trois postes, avec un impact visible dans le P&L – c’est une autre affaire. L’écart entre ces deux points est le principal piège.
McKinsey, dans son rapport 2025 sur le passage à l’échelle de l’IA dans l’industrie, avance un chiffre qui donne à réfléchir : seuls 2 % des industriels estiment que l’IA est pleinement intégrée dans leurs opérations. Environ deux tiers en sont encore au stade de l’exploration et des déploiements ponctuels – autrement dit, des pilotes sans fin. Le rapport du MIT, dont nous avons parlé séparément, dessine un tableau similaire : chez 95 % des entreprises, l’IA générative n’a pas produit d’effet mesurable sur les bénéfices.
Dans l’automobile, c’est visible à l’état pur. D’après les analyses de la revue sectorielle Automotive Manufacturing Solutions, la majorité des projets de vision par ordinateur pour le contrôle qualité ne dépassent jamais la cellule de test – non pas parce qu’ils détectent mal les défauts en démo, mais parce que la démo et l’atelier réel sont deux environnements distincts.
Passons aux signes.
Signe 1. Personne ne peut chiffrer le coût du problème
RAND place l’incompréhension de la tâche en tête des causes d’échec, et dans l’industrie, cela se manifeste de manière spécifique. On lance le pilote parce qu’« il faut déployer l’IA » ou parce qu’un concurrent s’en est vanté en conférence. Formuler quelle perte financière précise le projet est censé combler, personne ne peut le faire.
McKinsey relève le même mal de manière quantitative : chez la plupart des industriels, les initiatives IA ne sont rattachées à aucun objectif de valeur concret. Un projet sans coût du problème ne peut être ni priorisé, ni clôturé, ni déclaré réussi – il n’a tout simplement pas de critère. Comment construire un business case avec des données réelles, nous l’avons détaillé dans un autre article.
Avant de lancer le pilote, essayez de remplir une seule ligne : « ce problème nous coûte N euros par mois, parce que … ». Si vous n’arrivez pas à calculer N, cela ne signifie pas que la tâche est mauvaise. Cela signifie que vous ne la comprenez pas encore suffisamment pour y consacrer un budget IA. Choisissez celle où N est évident : arrêt de ligne, reprise de rebuts, pénalités pour retard de livraison.
Chiffrer le coût d'un problème est plus difficile qu'il n'y paraît. Testez l'IA sur 9 situations réelles de manager – de l'analyse de données à la réclamation fournisseur – gratuitement et sans inscription.
Sans paiement requis • Notification au lancement
Signe 2. Les données pour la tâche n’existent pas vraiment
Deuxième cause la plus fréquente dans la liste RAND : l’organisation ne dispose pas des données nécessaires. En usine, cela sonne particulièrement familier. Les données semblent être là : SCADA enregistre la télémétrie, le MES stocke les ordres de fabrication, le service qualité tient ses registres. Mais quand vient le moment d’entraîner ou de prompter le modèle, on découvre que la moitié des registres est sur papier, que SCADA n’a pas d’historique de pannes étiqueté et que chaque contrôleur décrit les défauts à sa manière.
C’est exactement la fragmentation des données dont se plaignent les acteurs de l’automobile : les données existent, mais elles sont dispersées entre les systèmes, non étiquetées et pas consolidées dans un format uniforme. Le modèle, entraîné sur un échantillon propre pour la démo, rencontre la réalité en production – et ses performances chutent.
Avant de commander un pilote, menez un audit honnête : où se trouvent les données liées à la tâche, dans quel format, qui les saisit et avec quelle cohérence. Si le malaise s’installe à cette étape, mieux vaut d’abord mettre de l’ordre dans les données, puis lancer l’IA. La couche « papier », par laquelle nous conseillions de commencer, présente justement l’avantage de ne pas exiger d’historique propre – le modèle travaille avec ce que vous lui donnez maintenant.
Signe 3. L’équipe est amoureuse de la technologie, pas du problème
La troisième cause identifiée par RAND est formulée sans détour : le projet se passionne davantage pour l’application de la dernière technologie que pour la résolution d’un problème réel. En production, cela se traduit par la volonté de construire d’emblée de la vision par ordinateur avec fine-tuning de réseau de neurones là où un simple assistant textuel aurait résolu la tâche en une semaine.
Le MIT note dans son rapport un biais similaire : plus de la moitié des budgets d’IA générative sont absorbés par des vitrines spectaculaires – ventes et marketing –, alors que le meilleur retour vient du back-office, bien moins glamour. En usine, l’équivalent de la vitrine est l’« atelier intelligent » pour les visites d’investisseurs ; l’équivalent du back-office, c’est l’automatisation des rapports de poste et du suivi des réclamations, qui n’impressionnera personne en comité de direction mais fait réellement gagner des heures.
Une question de vérification à poser à l’initiateur du pilote : « Si cette technologie n’existait pas, comment résoudrions-nous ce problème ? » Si la réponse est floue, c’est que la solution a été inventée avant le problème. Ramenez la conversation du modèle vers la tâche.
Signe 4. La tâche dépasse les capacités de l’IA actuelle
Cinquième cause dans la liste RAND : l’IA est appliquée à des tâches trop complexes pour elle. Ce n’est pas une condamnation de la technologie, c’est une question de limites. L’IA structure bien le texte, détecte les défauts récurrents, trouve des analogues de pièces. Elle est en difficulté quand il faut traiter des événements rares sans historique, raisonner physiquement sur un équipement inconnu ou prendre des décisions dont l’erreur a un coût en vies humaines, sans filet de sécurité.
Il est utile de répartir les tâches en trois catégories : « l’IA fait seule », « l’IA prépare un brouillon, l’humain valide », « on ne touche pas à l’IA pour l’instant ». La plupart des tâches industrielles tombent honnêtement dans la catégorie du milieu – et c’est normal. Les problèmes commencent quand on essaie de forcer une tâche de la troisième catégorie dans la première sous la pression des délais.
Où l'IA aide et où elle se trompe sans qu'on s'en aperçoive – cela ne se voit que dans la pratique. Le module ouvert propose 9 situations de manager avec analyse des erreurs typiques, gratuitement.
Sans paiement requis • Notification au lancement
Signe 5. La dérive que tout le monde oublie au bout de six mois
C’est un piège spécifiquement industriel, que les déploiements de bureau ne connaissent quasiment pas. Le modèle de vision par ordinateur qui fonctionnait parfaitement au lancement commence à se tromper quelques mois plus tard – non pas parce qu’on l’a cassé. L’éclairage de l’atelier a changé, le fournisseur a changé de nuance d’acier avec un reflet légèrement différent, la caméra s’est usée, la saison a modifié l’humidité. Le modèle, lui, est resté le même, mais le monde autour a bougé.
L’analyse de ce phénomène dans l’automobile révèle un schéma récurrent : les systèmes d’inspection ne se dégradent pas tout de suite, mais des mois après un pilote réussi, quand l’équipe de déploiement a déjà été dissoute et que personne n’a pensé au réentraînement du modèle. Un pilote qui n’a pas de plan pour la vie après le lancement est condamné, quelle que soit la qualité du démarrage.
Il faut intégrer au projet non seulement le lancement, mais aussi l’exploitation : qui vérifie la précision et à quelle fréquence, à quel seuil le réentraînement est déclenché, qui en est responsable. Si la réponse est « l’équipe de déploiement partira et on verra bien après », vous financez un pilote qui mourra selon un calendrier prévisible.
Signe 6. Tout repose sur deux ou trois spécialistes
Quatrième cause chez RAND : le manque d’infrastructure pour la gestion des données et le déploiement des modèles. En pratique, cela se déguise souvent en dépendance aux personnes : le pilote fonctionne parce que deux ingénieurs passionnés le maintiennent à bout de bras. Ils partent en vacances, changent de poste ou sont réassignés à un autre projet – et le système s’arrête, parce qu’il n’y a pas d’infrastructure capable de vivre sans eux.
Vérifiez si le projet survivrait au départ de n’importe quel membre de l’équipe. Si la réponse est « non », vous n’avez pas un système déployé mais une démo qui a survécu jusqu’en production par accident. Avant le passage à l’échelle, il faut une infrastructure minimale : processus documenté, accès, monitoring, protocole de mise à jour.
Signe 7. Le projet n’a pas de responsable côté métier
C’est la cause transversale qui relie toutes les précédentes. RAND et BCG s’accordent sur un point : les projets réussis ont un responsable produit côté métier – une personne qui répond du résultat en termes financiers, pas du fait que « le modèle a été entraîné ». Pour les responsables IT et produit qui mettent en place un processus similaire au sein de leur équipe, le constat est le même. Quand le pilote repose entièrement sur l’IT ou sur un intégrateur externe, personne n’est en mesure de formuler la tâche en termes d’atelier, de décider de l’arrêt du projet ni de s’assurer que l’atelier utilise réellement le système.
BCG décrit la proportion efficace des efforts de déploiement comme 70/20/10 : soixante-dix pour cent de l’énergie va aux personnes, aux processus et à la transformation du fonctionnement de l’atelier, vingt pour cent aux technologies et aux données, et seulement dix pour cent aux algorithmes. Si dans votre projet c’est l’inverse et que 90 % du budget part en licences et en intégration, le déséquilibre est flagrant.
Le responsable côté production doit être nommé avant le lancement, pas après. Il doit avoir le pouvoir d’arrêter le projet – et la motivation de le mener jusqu’à l’usage quotidien.
Comment rassembler tout cela en une checklist
Avant de signer le budget de passage à l’échelle d’un pilote, passez en revue ces sept questions. Chaque « non » n’est pas une raison de renoncer à l’IA, mais un endroit où le projet cassera si vous ne le corrigez pas à temps.
- Pouvons-nous chiffrer le coût du problème en euros ?
- Disposons-nous de données exploitables pour cette tâche ?
- Résolvons-nous un problème ou admirons-nous la technologie ?
- Cette tâche est-elle à la portée de l’IA actuelle ?
- Avons-nous un plan pour la vie du système après le lancement, tenant compte de la dérive ?
- Le projet survivrait-il au départ de n’importe quel membre de l’équipe ?
- Y a-t-il un responsable côté métier avec le pouvoir d’arrêter le projet ?
Le constat de RAND se lit entre les lignes de cette liste : six des sept questions portent sur le management, et une seule sur la technologie. Une usine qui sait répondre « oui » aux questions managériales mènera jusqu’à l’atelier même un modèle modeste. Une usine qui espère que la technologie compensera tout échouera même avec le meilleur modèle.
Et voici ce qui est encourageant malgré ces statistiques sombres. La capacité à formuler une tâche, à en chiffrer le coût et à distinguer « à la portée de l’IA » de « hors de portée » n’est ni un talent inné ni une compétence rare de consultant hors de prix. C’est une discipline managériale qui se travaille. Elle s’acquiert le plus facilement non pas sur un pilote coûteux qui échoue, mais sur des exercices d’apprentissage sans risque, où l’erreur se voit immédiatement et ne coûte rien.
De la checklist à la compétence systématique
Module ouvert mysummit.school : 9 exercices pratiques qui montrent où l'IA aide réellement et où elle se trompe sans qu'on s'en aperçoive. Le socle du cours développe les compétences de formulation de tâches, d'évaluation des résultats et de gestion des risques IA – ce qui sépare un pilote réussi d'un projet éternellement reporté. Gratuit, sans inscription.
Часто задаваемые вопросы
Pourquoi la plupart des pilotes IA ne dépassent-ils pas la cellule de test ?
Qu'est-ce que la dérive de modèle et pourquoi tue-t-elle les déploiements IA en production ?
Comment savoir si une tâche IA est à la portée des modèles actuels ?
Pourquoi BCG recommande-t-il de consacrer 70 % de l'effort d'un projet IA aux personnes plutôt qu'à la technologie ?
Qui doit être le responsable d'un projet IA en production ?
Stanislav Belyaev
Engineering Leader chez Microsoft18 ans a diriger des equipes d'ingenieurs. Fondateur de mysummit.school. 700+ diplomes chez Yandex Practicum et Stratoplan.