Ce qu'on a appris de 50 POC IA en entreprise

On ne nomme pas les clients. On ne donne pas de chiffres qui permettraient de les identifier. Mais après cinquante POC IA en entreprise — industrie, finance, services, secteur public —, les patterns sont suffisamment stables pour en tirer des conclusions utiles. Voici ce qu'on a observé, sans les habituels vernis de communication.

Les 5 patterns d'échec les plus fréquents

1. Le cas d'usage choisi pour convaincre, pas pour délivrer. Le premier POC est souvent choisi parce qu'il est « visible » et va impressionner le COMEX — pas parce qu'il est faisable en 8 semaines avec les données disponibles. Résultat : une démo qui fonctionne sur des données préparées, et rien qui passe en production.

2. Pas de sponsor métier avec un vrai problème business. Quand le POC est piloté par la DSI ou un lab innovation sans sponsor métier identifié, il meurt au moment du passage en production. Personne ne se bat pour le budget d'industrialisation parce que personne n'a vraiment mal.

3. Les données de production découvertes à la fin. Le POC tourne sur un export Excel propre préparé exprès. En production, les mêmes données sont dans trois systèmes, avec des champs vides, des formats incohérents et des règles métier non documentées. L'écart détruit le projet.

4. Le critère de succès défini après coup. Sans définition binaire du succès avant de commencer, le POC a toujours l'air d'avoir « presque » marché. On refait une itération. Puis une autre. On ne décide jamais. Le projet s'éteint par épuisement.

5. La sécurité et la conformité intégrées trop tard. Le POC est validé techniquement en semaine 6. Le RSSI et le DPO découvrent le projet en semaine 8. Ils posent des questions légitimes. Le projet repart pour trois mois de mise en conformité — et perd son sponsor métier entre-temps.

Les 3 conditions du succès

Les POC qui passent en production ont tous les mêmes caractéristiques. Pas les mêmes technologies. Pas les mêmes secteurs. Les mêmes conditions organisationnelles.

Un problème business douloureux et mesurable. Pas « améliorer la productivité ». Un problème précis : « nos commerciaux passent 4 heures par semaine à rédiger des comptes-rendus de réunion, on veut descendre sous 30 minutes. » Le critère de succès est dans la définition du problème.

Un sponsor métier avec du budget et une échéance. Le directeur commercial qui a besoin du résultat pour son plan stratégique Q3 est un meilleur sponsor que le DSI qui veut « explorer les possibilités de l'IA ». L'urgence business tire le projet.

La sécurité dans la conception, pas en bout de chaîne. Les entreprises qui ont une charte IA, un DPA avec leur fournisseur et un accord RSSI avant de commencer le POC avancent deux fois plus vite que les autres. Pas parce qu'elles ont moins de contraintes — parce qu'elles ne les découvrent pas en cours de route.

Ce qui change entre le POC et la production

La question la plus sous-estimée n'est pas « est-ce que le modèle fonctionne ? » mais « qu'est-ce qui se passe quand il se trompe ? »

En POC, on tolère les erreurs parce que c'est un test. En production, une erreur a des conséquences réelles — un contrat mal analysé, une information client incorrecte, une décision automatisée injuste. Le dispositif de supervision humaine, les seuils de confiance, les cas de sortie du flux automatique : tout ça doit être conçu avant le passage en prod, pas découvert après.

Les volumes aussi changent tout. Un modèle qui répond en 3 secondes dans une démo avec 10 requêtes simultanées peut s'effondrer à 500 requêtes. L'infrastructure de production — load balancing, cache, gestion des files d'attente — n'est pas un détail.

Pourquoi les POC « réussis » échouent au passage en prod

C'est le paradoxe le plus douloureux : un POC peut être techniquement réussi et pourtant ne jamais passer en production. On l'a vu une dizaine de fois.

La raison la plus fréquente : le POC a été conçu comme une démonstration, pas comme la version 0 d'un produit. L'architecture est jetable. Les API sont codées en dur. Il n'y a pas de monitoring, pas de logs exploitables, pas de gestion des erreurs. Industrialiser ce code revient à tout réécrire — et personne ne veut financer une réécriture d'un projet qui « existe déjà ».

La deuxième raison : l'équipe qui a fait le POC n'est plus disponible au moment du passage en prod. Le projet a été fait par des consultants ou une équipe projet. L'équipe run n'a pas été impliquée, ne comprend pas le système, et ne veut pas en prendre la propriété.

Le remède tient en une phrase : concevez le POC comme si vous alliez devoir le mettre en production dans 60 jours. Parce que si ça marche, vous le ferez.

Pour aller plus loin sur la méthode : notre guide complet sur comment réussir un POC IA en entreprise.