Le pilote fonctionne. Les utilisateurs invités à la démonstration sont convaincus. Pourtant, le projet reste plusieurs mois dans cet état : suffisamment prometteur pour ne pas être arrêté, insuffisamment préparé pour devenir un service ordinaire.
Ce décalage peut s’expliquer simplement : l’essai a montré qu’une tâche était réalisable dans certaines conditions. Le déploiement exige de savoir si elle restera utile, contrôlable et soutenable avec d’autres données, d’autres personnes et les contraintes quotidiennes.
Les projets pilotes d’IA ne sont donc pas tous destinés à passer à l’échelle. Certains doivent être modifiés ou arrêtés. Le problème apparaît lorsque l’entreprise ne sait pas quelles preuves lui manquent pour décider.
Que signifie passer un projet d’IA à l’échelle ?
Dans cet article, le passage à l’échelle désigne l’extension d’un usage au-delà de son périmètre d’essai, avec des responsabilités, des moyens et un fonctionnement compatibles avec l’activité réelle de l’entreprise.
Il faut distinguer les questions auxquelles répondent les étapes. Une preuve de concept explore surtout une faisabilité. Un pilote examine un usage sur un périmètre limité. Une mise en production engage la continuité du service et ses conséquences pour les utilisateurs. Les entreprises emploient parfois ces mots différemment ; l’essentiel est de préciser ce qui a réellement été vérifié.
Ajouter des utilisateurs n’est ainsi qu’une partie du sujet. Il faut aussi examiner les exceptions, les mises à jour, les demandes d’aide et la capacité de l’organisation à reprendre la main.
Ce que la recherche permet de comprendre
Le rapport de RAND sur les causes d’échec des projets d’IA, publié le 13 août 2024 par James Ryseff, Brandon De Bruhl et Sydne Newberry, s’appuie sur 65 entretiens avec des scientifiques des données et des ingénieurs expérimentés.
Il relève notamment des problèmes mal définis, des données inadaptées, une attention excessive à la technologie et des infrastructures insuffisantes. Cette enquête qualitative aide à identifier des difficultés possibles. Elle ne mesure pas un taux universel d’échec applicable à tous les pilotes, tous les secteurs ou tous les outils d’IA générative.
Le rapport OCDE–BCG–INSEAD sur l’adoption de l’IA dans les entreprises, publié le 2 mai 2025, repose notamment sur une enquête de 2022–2023 auprès de 840 entreprises adoptantes du G7, complétée par 167 entreprises au Brésil. Il souligne des enjeux de maturité des données, d’information et de capacités organisationnelles. Ses résultats ne décrivent pas automatiquement toutes les PME françaises.
Ces travaux invitent à regarder l’environnement du système. La grille qui suit est notre proposition de lecture pour les responsables d’entreprise, et non un modèle d’évaluation validé par ces publications.
Les conditions invisibles qui rendent le pilote convaincant
Un essai peut bénéficier d’une attention exceptionnelle. Les documents ont été sélectionnés, les demandes difficiles écartées et une personne experte reste disponible pour corriger les sorties. Ces choix peuvent être légitimes pour explorer une idée.
Ils deviennent trompeurs si le résultat est présenté comme celui d’un dispositif déjà prêt à fonctionner seul. Il faut rendre visibles les interventions qui ont permis la réussite.
Des données préparées pour l’essai
Un assistant peut donner une bonne réponse à partir d’un dossier propre et actualisé. Cela ne dit pas comment il se comportera face à des versions contradictoires, des documents incomplets ou des informations dont l’accès doit être limité.
L’entreprise doit donc identifier ce qui a été préparé manuellement et ce qui pourra être maintenu en fonctionnement normal. La qualité d’une démonstration ne dispense pas de répondre à cette question.
Un utilisateur qui connaît déjà les limites
La personne qui a conçu l’essai sait souvent comment formuler une demande, reconnaître une erreur et contourner une difficulté. Un nouveau collègue ne dispose pas nécessairement de ces repères.
Il est utile d’observer ce qui se passe lorsqu’une personne moins familière accomplit une tâche représentative avec les seules consignes prévues. Le but est de découvrir ce que l’organisation doit transmettre, pas de mettre le collaborateur en défaut.
Une assistance dont le coût reste caché
Lorsque l’équipe projet répond immédiatement à chaque question, elle assure une partie du service. Avant d’élargir l’usage, il faut préciser qui reprendra cette fonction.
L’assistance peut rester nécessaire. Elle doit alors être organisée et prise en compte dans la décision. Un projet ne devient pas autonome parce que le support informel n’apparaît pas dans le bilan.
Un scénario fictif : rechercher une procédure interne
Imaginons une entreprise qui teste un assistant pour retrouver des procédures. Pendant le pilote, les réponses sont jugées utiles par un petit groupe de collaborateurs.
Avant de proposer le service à une autre équipe, plusieurs questions apparaissent. Une procédure a changé ; un document porte encore une ancienne version. Une demande combine deux situations. Un nouvel utilisateur ne sait pas si la réponse indique une règle officielle ou une suggestion.
Ces difficultés ne prouvent pas que le projet est condamné. Elles montrent ce qu’il faut examiner : la mise à jour des documents, la présentation des sources, le traitement des questions ambiguës et la personne à solliciter lorsqu’un doute persiste.
L’entreprise peut choisir un élargissement limité, observer les demandes nouvelles et corriger le dispositif. Elle peut aussi conclure que l’effort nécessaire dépasse l’intérêt de cet usage. Ce scénario ne décrit aucun client Learning Coach et ne prédit aucun résultat.
Cinq questions à traiter avant d’élargir l’usage
La décision gagne à porter sur des éléments vérifiables. Voici une grille proposée pour une revue de projet ; elle doit être adaptée à la nature et aux conséquences de l’usage.
| Question | Ce qu’il reste à examiner |
|---|---|
| Le besoin est-il toujours le même ? | Les nouvelles équipes réalisent-elles la même tâche et attendent-elles le même niveau de qualité ? |
| Les informations resteront-elles utilisables ? | Qui les actualise, les vérifie et gère les accès ? |
| Le travail s’intègre-t-il au fonctionnement réel ? | Qui reçoit la sortie, la contrôle et décide de son utilisation ? |
| Les utilisateurs savent-ils agir face à une limite ? | Peuvent-ils repérer un doute, demander une aide et reprendre la tâche autrement ? |
| Le service peut-il être suivi dans la durée ? | Qui traite les incidents, examine les changements et décide de poursuivre ou d’arrêter ? |
La grille ne donne pas une note automatique de maturité. Elle sert à rendre explicites les informations nécessaires à une décision collective.
La responsabilité ne peut pas rester dans l’équipe projet
Pendant l’essai, les rôles peuvent être souples. À mesure que l’usage s’installe, cette souplesse peut devenir une ambiguïté : personne ne sait qui tranche lorsqu’une sortie est contestée ou lorsqu’une condition change.
Le cadre volontaire AI Risk Management Framework du NIST, dans sa version 1.0 publiée le 26 janvier 2023, propose d’intégrer la gestion des risques à la conception, au développement, à l’utilisation et à l’évaluation des systèmes. Il ne constitue ni une certification de réussite ni une procédure qui remplacerait les obligations applicables à une entreprise. La page du NIST indique, au moment de la consultation, qu’une révision de cette version est en cours.
Pour une organisation, l’implication pratique est de nommer les responsabilités au-delà de la livraison initiale. La qualité d’un système doit pouvoir être discutée après son lancement, avec des interlocuteurs identifiés.
Le passage à l’échelle est aussi un transfert de compétences
Une procédure peut être documentée sans que les utilisateurs sachent la mobiliser. Une formation peut être suivie sans que la personne sache reconnaître une situation où l’outil ne convient pas.
La perspective Learning Coach consiste à examiner ce transfert : que savent désormais faire les équipes qui n’ont pas conçu le pilote ? Peuvent-elles expliquer le but de l’usage, vérifier une sortie et signaler une limite ?
On peut proposer une activité de reprise : traiter une demande légèrement différente de celles de l’essai, justifier les contrôles effectués et expliquer quand recourir à une autre méthode. Il s’agit d’une suggestion pédagogique, à adapter au métier et aux risques.
Notre article sur les méthodes d’apprentissage selon les sciences cognitives aide à distinguer familiarité et capacité d’utilisation. Il ne démontre pas l’efficacité d’une méthode particulière de déploiement de l’IA.
Le temps et les conditions de pratique comptent également dans l’organisation de la formation. Notre réflexion sur l’engagement des adultes en entreprise examine la clarification des attentes et des responsabilités dans cet apprentissage.
Arrêter un pilote peut être une décision utile
Un pilote doit permettre d’apprendre quelque chose sur une possibilité. Si l’entreprise découvre que les données nécessaires ne peuvent pas être maintenues, que la vérification est trop lourde ou que le besoin est mieux traité autrement, elle dispose d’une information pour décider.
La revue peut donc distinguer trois issues : poursuivre dans un périmètre défini, modifier les conditions puis réexaminer, ou arrêter en conservant ce qui a été appris. Répéter les démonstrations sans préciser la question encore ouverte entretient une attente difficile à évaluer.
Un bilan utile explique ce qui a été observé, ce qui reste incertain et les conditions de la décision. Il évite de présenter l’extension comme l’unique preuve de réussite de l’équipe.
Quel rôle pour un séminaire sur l’IA ?
Une rencontre entre dirigeants, responsables métiers, équipes techniques et fonctions de formation peut aider à rendre ces dépendances visibles. Elle peut partir d’un usage fictif ou d’une situation interne préparée, puis faire travailler les participants sur les conditions de son fonctionnement ordinaire.
La conférence ouvre une perspective commune ; un atelier permet d’examiner les décisions et les informations manquantes. Aucun de ces formats ne remplace la validation technique, l’expertise métier ou le pilotage du service.
Pour préparer cette discussion sur l’IA, l’apprentissage et les capacités humaines, découvrez les keynotes Learning Coach et précisez les questions que votre organisation doit résoudre.
Le vrai passage à l’échelle commence lorsque l’entreprise sait expliquer ce qui doit rester fiable après la fin des conditions exceptionnelles de l’essai.
Ressources
RAND — The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed, 13 août 2024 : enquête qualitative par entretiens.
OCDE, BCG et INSEAD — The Adoption of Artificial Intelligence in Firms, 2 mai 2025 : enquête et analyse de l’adoption dans les entreprises.
NIST — AI Risk Management Framework, version 1.0 du 26 janvier 2023 : cadre volontaire de gestion des risques. Sources consultées le 27 octobre 2026.
