Mistral AI confirme un chiffre que nous observons sur le terrain wallon : moins de 20 % des POC IA atteignent la production. Les 80 % d'échec partagent le même profil : démo convaincante, données propres, intégration inexistante, aucun plan de maintenance. Les 20 % qui réussissent ont défini l'architecture de production avant le POC, pas après.
Mistral vient de publier un chiffre que je ne trouve pas surprenant : moins de 20 % des projets IA pilotes atteignent la production.
Je travaille avec des PME wallonnes depuis le début de l'année. Ce chiffre correspond à ce que j'observe. Sur dix entreprises qui lancent quelque chose, huit s'arrêtent avant que ça tourne vraiment. La démo a fonctionné. Le projet, lui, est mort en silence quelques mois plus tard.
Ce n'est pas un problème technologique.
C'est un problème de méthode, et il commence bien avant la première ligne de code.
Voici ce que j'ai observé sur le terrain, pourquoi ça coince, et ce que les PME qui réussissent font différemment.
Qu'est-ce qu'un POC IA et pourquoi il ne suffit pas ?
Un POC (Proof of Concept) est une démonstration de faisabilité. On prend un cas d'usage, on l'isole, on configure un modèle IA sur des données préparées, et on montre que ça fonctionne dans ce contexte contrôlé.
C'est utile. C'est nécessaire pour valider une hypothèse technique avant d'investir.
Le problème, c'est quand le POC devient l'objectif du projet plutôt que son point de départ.
La démo fonctionne en réunion. Les données sont propres. Les cas sont choisis pour que ça marche. L'équipe applaudit. Le prestataire facture. Et là, dans la plupart des cas, le projet s'arrête, pas officiellement, mais dans les faits.
L'outil existe quelque part sur un serveur. Personne ne l'ouvre plus.
Ce scénario se répète parce que le marché a été structuré pour produire des démos, pas des systèmes. Et les PME, souvent non techniques, n'ont pas les outils pour faire la différence avant de signer.
Pourquoi un POC IA n'atteint pas la production ?
Quatre raisons structurelles. Elles apparaissent presque toujours ensemble.
Raison 1 : les données de test ne ressemblent pas aux données réelles
En démo, les données sont préparées. Elles sont propres, cohérentes, bien formatées. Dans un fichier Excel ou une base SQLite que le développeur a nettoyé pendant une semaine.
En production, les données arrivent autrement. Elles viennent de trois systèmes qui ne se parlent pas. Elles sont incomplètes, dupliquées, mal encodées. Une colonne « date » qui contient parfois « en cours ». Un champ client qui change de format selon qui l'a saisi.
L'IA qui fonctionne sur les données de test ne sait pas quoi faire avec la réalité.
Ce n'est pas un bug. C'est un angle mort de conception.
Raison 2 : l'intégration n'était pas dans le scope
Le POC tourne dans sa propre fenêtre. Il n'est pas connecté à l'ERP, au CRM, au logiciel de facturation, à la messagerie. Il existe à côté des outils que l'équipe utilise chaque jour, pas dedans.
Résultat : pour utiliser l'outil IA, l'employé doit ouvrir un onglet supplémentaire, copier-coller des informations depuis son logiciel habituel, lire la réponse, recopier le résultat dans son logiciel habituel.
C'est plus de travail qu'avant. Personne ne le fait.
Ce n'est pas un problème de résistance au changement. C'est un problème de conception : un outil qui crée de la friction supplémentaire ne s'adopte pas, quelle que soit sa qualité intrinsèque.
Raison 3 : l'adoption n'a pas été conçue
Un outil IA ne s'adopte pas parce qu'il est disponible. Il s'adopte parce qu'il supprime une friction précise dans une tâche précise, à un moment précis de la journée de quelqu'un.
La question à se poser avant de démarrer : « Qui va l'utiliser, à quelle étape de son travail, et pourquoi ce serait plus simple qu'avant ? »
Si cette question n'a pas de réponse précise au moment du lancement, l'outil restera une démo.
La plupart du temps, cette question n'est posée qu'après la mise en production quand les chiffres d'usage montrent que personne ne se connecte.
Raison 4 : la maintenance n'a pas été budgétée
Un système IA déployé se dégrade. Les données changent. Les process évoluent. Les comportements utilisateurs modifient les patterns que le modèle a appris. Sans boucle de feedback et sans maintenance régulière, le système se désaligne progressivement, et souvent en silence.
Personne ne reçoit d'alerte. L'outil continue de répondre. Ses réponses deviennent progressivement moins pertinentes. Les utilisateurs arrêtent de lui faire confiance. Ils arrêtent de l'ouvrir.
Six mois plus tard, le directeur se demande pourquoi « l'IA n'a pas marché ».
Le problème n'était pas l'IA. C'était l'absence de plan de vie du système.
Comment les 20 % qui réussissent s'y prennent ?
J'ai observé un point commun dans tous les projets qui tiennent dans le temps : l'architecture de production a été définie avant le POC, pas après.
Ce n'est pas une question de budget plus élevé. C'est une question d'ordre des décisions.
POC d'abord, production « on verra »
- Objectif vague : « améliorer la productivité »
- Données nettoyées à la main pour la démo
- Outil IA séparé des logiciels métiers
- Aucun budget maintenance
- Résultat : démo qui meurt en silence
Bâti pour la production dès le départ
- Objectif mesurable : « relances client de 8 h à 45 min/semaine »
- Données réelles, dans leur état brut
- Agent IA connecté à l'ERP/CRM/messagerie
- Revue trimestrielle budgétée
- Résultat : système qui performe durablement
Concrètement, l'ordre des décisions ressemble à ça :
Identifier deux ou trois tâches précises
Avant d'écrire une ligne de code. Pas « améliorer la productivité » mais « réduire le temps de traitement des relances client de 8 heures par semaine à 45 minutes ».
Cartographier les sources de données réelles
D'où viennent-elles, quel est leur format actuel, qui les saisit, à quelle fréquence. Puis concevoir le système pour ingérer ces données dans leur état réel, pas dans un état idéalisé.
Intégrer dans les outils existants
Si l'équipe travaille dans un ERP ou une messagerie, l'agent IA doit s'y connecter directement. Pas à côté.
Budgéter la maintenance dès le départ
Une revue trimestrielle minimum pour évaluer la dérive, ajuster les paramètres, intégrer les nouveaux cas d'usage qui émergent.
Ce n'est pas plus compliqué. C'est juste dans un ordre différent.
Qu'est-ce que MCP change à l'intégration IA en PME ?
MCP, Model Context Protocol, est le protocole qui permet à un agent IA de se connecter directement aux systèmes d'une entreprise : ERP, CRM, messagerie, bases de données, outils métiers.
Ce n'est pas un outil supplémentaire. C'est le câblage qui manquait.
Avant MCP, connecter un agent IA à un système existant nécessitait de développer une intégration sur mesure pour chaque connexion. Coûteux, fragile, difficile à maintenir.
Avec MCP, l'agent dispose d'une interface standardisée pour interroger et agir sur les systèmes existants, sans développement spécifique pour chaque connexion.
Concrètement, ça veut dire qu'un agent peut :
- Lire les commandes en attente directement dans l'ERP, sans qu'on les lui copie-colle.
- Rédiger et envoyer un email de relance depuis la messagerie de l'entreprise, pas depuis une interface externe.
- Mettre à jour un champ dans le CRM après un appel, sans que l'utilisateur change d'outil.
L'agent travaille dans le flux réel de l'entreprise. Pas à côté.
C'est ce qui rend un POC déployable. Sans cette connexion aux données et aux systèmes réels, l'agent reste dans sa fenêtre de démonstration.
Trois questions à poser avant de lancer un projet IA
Trois questions à poser à ton prestataire avant de signer quoi que ce soit.
Si la réponse implique une exportation manuelle régulière ou un fichier Excel intermédiaire, le système ne tient pas en production. Un système qui a besoin qu'un humain lui apporte les données manuellement n'est pas un agent. C'est un outil assisté.
Si le prestataire ne peut pas répondre à ça précisément, le projet est conçu pour la démo. La question de l'adoption doit être résolue avant le développement, pas après.
Si cette question provoque un flou dans la réponse, la maintenance n'est pas budgétée. Dans 12 mois, le système sera en dérive et personne ne saura pourquoi « l'IA a arrêté de bien fonctionner ».
Ces trois questions ne sont pas techniques. N'importe quel dirigeant peut les poser. Et les réponses disent immédiatement si le projet est conçu pour durer ou pour impressionner.
En résumé
Le fossé entre POC et production n'est pas un problème technologique. C'est un problème de méthode et d'ordre des priorités.
Une démo convaincante, des données propres, une intégration inexistante, et aucun plan de maintenance. Le projet meurt en silence dans les six mois.
L'architecture de production a été définie avant d'écrire le premier prompt. Données réelles, intégration native, adoption conçue, maintenance budgétée.
Si tu envisages un projet IA pour ta PME cette année, pose les trois questions ci-dessus avant de signer. Les réponses te diront tout ce que tu as besoin de savoir.
Ton POC est-il viable en production ?
Notre diagnostic de 45 minutes évalue si ton projet IA peut tenir en production, ou s'il restera une démo. Sans engagement, basé en Wallonie.
Réserver un diagnostic 45 minSans engagement. Basé en Wallonie.