La plupart des projets pilotes d'IA n'échouent pas : ils s'enlisent. Ils fonctionnent, impressionnent lors de la démonstration, reçoivent des éloges, puis ne sont jamais mis en production. Ils restent dans une impasse : personne ne les annule officiellement – les annuler reviendrait à admettre une erreur – et personne ne les déploie – les déployer impliquerait de résoudre des problèmes que le projet pilote a justement évités.
Cette situation d'incertitude a un coût qui n'apparaît dans aucun rapport : budget englouti, crédibilité interne mise à mal et, surtout, la conclusion erronée que « l'IA ne fonctionne pas dans notre secteur ».
Les chiffres varient énormément selon les personnes qui les mesurent et les méthodes utilisées ; il est donc préférable de consulter plusieurs sources plutôt que de se fier à un seul titre.
le Étude des PDG d'IBM pour 2025, L'étude, menée auprès de 2 000 PDG de 33 pays, révèle que seulement 251 % des initiatives en matière d'IA ont produit le retour sur investissement escompté et que seulement 161 % ont été déployées à l'échelle de l'entreprise. Elle est, sur le plan méthodologique, la plus rigoureuse des trois sources.
S&P Global Market Intelligence Il a été publié en mars 2025 que 42% d'entreprises avaient abandonné la plupart de leurs initiatives en matière d'IA, contre 17% l'année précédente, et qu'en moyenne 46% de projets de validation de concept avaient été abandonnés avant d'atteindre la production.
Et puis il y a l'information qui a le plus circulé : le rapport Projet NANDA du MIT D'après le rapport de 2025, environ 95,1 % des organisations n'ont pas constaté de retour sur investissement mesurable grâce à l'IA générative. Il est important de préciser ce dernier point : il s'agit d'un rapport préliminaire, non évalué par les pairs, basé sur 52 entretiens et 153 enquêtes, et qui a fait l'objet de sérieuses critiques méthodologiques concernant sa période de mesure et la taille de son échantillon. La tendance générale concorde avec d'autres sources ; l'ampleur exacte reste cependant indéterminée.
L'important n'est pas de savoir lequel des trois chiffres est correct. C'est que tous trois convergent vers le même point de rupture : il ne se situe pas dans la réalisation du pilote, mais dans le processus entre le pilote et la production.
Cause | Qu'a évité le pilote ? | De quoi la production a-t-elle besoin ? |
Données | Un ensemble propre et sélectionné | Données réelles, incomplètes et contradictoires |
Permis | Un utilisateur disposant d'un accès complet | Rôles différents, visibilité limitée, traçabilité |
Exceptions | Le chemin heureux | Le 15-30% fait partie des rares cas qui n'ont pas été conçus |
Intégration | Copier et coller entre les écrans | Intégration ERP, CRM et identité |
Propriété | Une équipe d'innovation | Un gestionnaire d'entreprise et une équipe de soutien |
Coût | Volume de test | Coût unitaire à l'échelle réelle, avec des pics |
Les données. Le projet pilote s'exécute sur un extrait préparé. En production, les données arrivent incomplètes, dupliquées et incohérentes entre les systèmes. Le modèle ne présente aucun signe de défaillance : il choisit l'une des versions contradictoires sans avertissement.
Les permis. Lors des tests, le système a accès à tout. En production, un vendeur ne peut pas consulter les marges, un technicien ne peut pas accéder aux données de santé et un consultant externe ne peut voir que les informations qui lui appartiennent. Si le modèle de permissions n'était pas prévu dès la conception, il ne s'agit pas d'un simple ajustement : c'est une refonte complète.
Les exceptions. Le projet pilote illustre la voie à suivre, car c'est ce qui peut être prouvé en vingt minutes. La réalité du terrain consiste, en grande partie, à gérer ce qui ne s'y prête pas. Ce pourcentage – entre 151 et 301 tonnes de volume dans la plupart des processus que nous avons analysés – correspond au seuil d'automatisation où il faut décider quelles tâches confier à un humain et comment.
Intégration. Une démonstration peut permettre à l'utilisateur de copier des informations entre fenêtres. En revanche, un système de production doit lire le contexte opérationnel et exécuter des actions au sein des systèmes existants, en respectant les autorisations et en laissant un journal.
La propriété. Les pilotes sont généralement des innovateurs nés. La production exige un responsable : une personne dont l’objectif annuel dépend du bon déroulement du processus. Sans ce responsable, personne ne défend le budget de la phase suivante ni ne décide des exceptions.
Le coût unitaire. Lors de la phase pilote, le coût est négligeable en raison du faible volume. À grande échelle, avec les pics de demande et les tentatives de réexécution, le coût par cas peut rendre non rentable un projet pourtant brillant lors de la démonstration. Ce calcul doit donc être effectué en amont, et non après.
Nous avons développé le parcours complet entre les deux phases en De la preuve de concept de l'IA à la production
La solution n'est pas d'agrandir les projets pilotes. Il s'agit de les mener dès le départ en tenant compte des contraintes de production, même à une échelle réduite.
Définissez l'indicateur de performance de l'entreprise avant de commencer. Il ne s'agit pas du « nombre de demandes » ni du « nombre d'utilisateurs actifs », mais du délai de traitement, du taux d'erreur, du coût par cas, du taux de conversion ou de la marge. Ce critère définit le seuil qui détermine la poursuite ou l'arrêt du projet. Un programme pilote sans critère d'arrêt n'est pas une expérimentation ; c'est un compromis déguisé.
Utilisez des données réelles dès le départ, même si elles sont peu nombreuses. Un pilote ayant à son actif une centaine de cas réels est plus instructif qu'un autre avec dix mille cas parfaits, car les cent cas réels incluent les problèmes que vous allez rencontrer.
Elle inclut une exception concrète dans son champ d'application. Choisissez le cas rare le plus fréquent et traitez-le dans le cadre du projet pilote. Si la conception ne peut pas gérer une exception, elle ne pourra pas en gérer trente.
Nommez le chef d'entreprise avant l'équipe technique. Et que cette personne soit responsable du résultat du processus, et non de la technologie.
Calculer le coût unitaire au volume réel. Extrapolez à partir du premier jour. Si le chiffre ne se confirme pas à plus grande échelle, il est préférable de le vérifier au bout de deux semaines.
Indiquez-y une date d'expiration. Quatre semaines suffisent pour déterminer la viabilité d'un concept, mais c'est trop court pour qu'il devienne un projet abandonné. C'est précisément pourquoi nos preuves de concept adoptent ce format : une preuve de concept pleinement fonctionnelle en un mois, avec des garde-fous, une traçabilité et une supervision humaine. Non pas pour des raisons commerciales, mais parce qu'un délai court nous oblige à limiter la portée du projet à ce qui peut être véritablement validé.
Si le programme pilote existe déjà et n'avance pas, il existe trois solutions honnêtes, et aucune d'entre elles n'implique d'attendre.
Diagnostiquer et décider. Une analyse du modèle, des données, de l'intégration et des coûts qui répond à trois questions : que peut-on sauver, que faut-il réécrire et que faut-il abandonner ? Tel est l'objectif d'une telle analyse. audit de projet d'IA , et le problème se résout généralement en quelques semaines.
Réduire le périmètre à quelque chose de réellement déployable. Souvent, le dispositif 20% initialement prévu offre une valeur ajoutée de 80% et peut être déployé en un mois. La réticence à procéder ainsi est d'ordre politique, non technique : réduire la portée du dispositif revient à admettre un échec partiel.
Arrêtez cela et documentez pourquoi. C'est l'option la plus sous-estimée. Un pilote qui a cessé de travailler, mais dont l'expérience est clairement documentée, est un atout. Un pilote en situation d'incertitude est un fardeau qui mobilise l'attention chaque trimestre.
Lors de l'analyse des incidents de pilotes bloqués, presque aucun n'était dû au modèle lui-même. Les décès étaient liés aux données, aux autorisations, aux exceptions, à l'intégration ou à l'absence de responsable. Autrement dit, ils survenaient pour les mêmes raisons que celles qui expliquent l'échec des projets logiciels depuis trente ans.
C'est globalement une bonne nouvelle. Cela signifie que le problème n'est pas d'ordre technologique, mais plutôt lié à l'ingénierie et à la gouvernance du projet. Et nous savons comment résoudre ce genre de problèmes.
La question à aborder lors de la prochaine réunion du comité n'est pas de savoir si l'IA fonctionne, mais plutôt ce qu'il faut corriger au niveau de nos données, de nos autorisations et de notre intégration pour que toute automatisation, avec ou sans IA, puisse être déployée en production.
Pour six raisons récurrentes : des données réelles incomplètes et contradictoires, un modèle d’autorisation que le projet pilote n’a pas pris en compte, des exceptions non prévues, un manque d’intégration avec les systèmes existants, l’absence d’un responsable commercial et un coût unitaire non viable à grande échelle.
D'après l'étude 2025 d'IBM auprès des PDG, seulement 251 % des initiatives en IA ont généré le retour sur investissement escompté, et à peine 161 % ont été déployées à grande échelle. S&P Global estimait en mars 2025 que 421 % des entreprises avaient abandonné la plupart de leurs initiatives en IA. Ces chiffres varient considérablement selon la méthodologie employée.
Environ quatre semaines. C'est suffisant pour valider la faisabilité du projet avec des données réelles, mais trop court pour que le projet pilote se transforme en un projet indéfini sans fin. Ce délai restreint nous oblige à limiter son périmètre à un élément vérifiable.
Les indicateurs de performance clés (KPI) suivants sont définis avant le démarrage : délai de traitement, taux d’erreur, coût par cas, taux de conversion ou marge, avec un seuil explicite déterminant la poursuite ou l’arrêt du projet. Le nombre de demandes ou d’utilisateurs actifs ne constitue pas une preuve d’impact sur l’activité.
Il existe trois solutions : diagnostiquer le problème par un audit permettant de déterminer ce qui peut être conservé, ce qui doit être réécrit et ce qui doit être abandonné ; réduire la portée du projet à la partie déployable en quelques semaines ; ou interrompre le projet tout en documentant les enseignements tirés. Laisser le projet en suspens est la seule option qui engendre des coûts.
Ce chiffre provient d'un rapport préliminaire du projet NANDA du MIT datant de 2025, non évalué par les pairs, basé sur un petit échantillon et ayant fait l'objet de critiques méthodologiques. D'autres sources plus fiables, comme IBM, vont dans le même sens, avec des estimations différentes : le problème d'échelle est bien réel, mais son ampleur exacte reste à déterminer.
Votre pilote IA est-il resté inactif pendant des mois ? Nous analysons votre modèle, vos données, votre intégration et vos coûts, et nous vous indiquons ce qu'il faut conserver, ce qu'il faut réécrire et ce qu'il faut abandonner. Si le projet est viable, nous développerons une preuve de concept (PoC) fonctionnelle en quatre semaines, avec toutes les mesures de sécurité et la traçabilité nécessaires. Parlons de votre cas → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
