Le POC a impressionné le comité de direction. Six mois plus tard, il n'est toujours pas en production. Ce n'est presque jamais le modèle qui est en cause — ce sont les cinq chantiers que le POC avait le droit d'ignorer, et que la production n'autorise pas.
Un POC réussi ne prouve pas grand-chose
Un démonstrateur prouve la faisabilité : sur des données choisies, avec un utilisateur bienveillant, le modèle produit un résultat convaincant. C'est utile, mais c'est un test dans des conditions que la réalité ne reproduira jamais. La production, elle, impose des données sales, des utilisateurs pressés, des cas limites, des pannes, des coûts et des auditeurs.
Le passage à l'échelle échoue rarement sur l'intelligence du système. Il échoue sur ce qui l'entoure.
Les cinq chantiers que le POC a esquivés
1. La donnée réelle
Le POC tournait sur un échantillon propre. La production doit avaler des documents scannés de travers, des tableaux fusionnés, des fichiers en double avec trois versions contradictoires, et vingt ans d'historique. Le coût réel d'un projet IA se cache presque toujours ici : la qualité, l'accès et la fraîcheur des données.
2. La sécurité — et notamment les clés d'API
C'est l'erreur d'architecture la plus coûteuse que nous voyons. Une clé d'API de modèle embarquée dans une application livrée à l'utilisateur — application mobile, code JavaScript d'un site — est extractible. Elle sera extraite, et elle sera utilisée. La facture arrive sans prévenir.
La règle ne souffre aucune exception : la clé vit sur votre serveur, jamais dans le client. L'application appelle votre backend, votre backend appelle le fournisseur. À cela s'ajoutent un plafond de dépense côté fournisseur, une limite de débit par utilisateur, et une rotation possible sans redéployer l'application.
3. Le coût unitaire, et son plafond
En POC, personne ne compte. En production, la question devient : combien coûte une requête, combien d'utilisateurs, combien de requêtes par utilisateur, et que se passe-t-il si quelqu'un boucle ? Une application IA sans plafond de dépense n'est pas un produit, c'est un risque financier. Le calcul doit être fait avant l'ouverture, pas à la première facture.
4. L'évaluation continue
Un système IA n'a pas de « ça marche » binaire. Il faut un jeu d'évaluation : des cas de référence, des réponses attendues, un score suivi dans le temps. Sans cela, vous ne saurez jamais si le changement de modèle du mois prochain a amélioré ou dégradé le service — vous le découvrirez par les réclamations.
5. L'adoption
Le dernier chantier est humain. Un assistant IA imposé sans que personne n'ait été formé à ses limites produit deux comportements symétriques et également nuisibles : la confiance aveugle (on copie-colle la réponse sans vérifier) et le rejet (on retourne à l'ancienne méthode dès la première erreur). L'un et l'autre tuent le projet, pour des raisons opposées.
La checklist « mon POC est-il industrialisable ? »
- Le système tourne-t-il sur les données réelles, dans leur saleté d'origine ?
- Aucune clé d'API ne se trouve-t-elle côté client, dans quelque artefact que ce soit ?
- Un plafond de dépense est-il posé chez le fournisseur, et une limite de débit par utilisateur ?
- Existe-t-il un jeu d'évaluation avec un score suivi dans le temps ?
- Les erreurs sont-elles traitées (délai d'attente, repli, message clair) plutôt que subies ?
- Les droits d'accès des utilisateurs sont-ils respectés par construction ?
- Sait-on ce que le système a répondu à qui, et peut-on le rejouer ?
- Peut-on changer de modèle sans réécrire l'application ?
Huit questions. Un POC qui répond « oui » aux huit est à quelques semaines de la production. Un POC qui répond « non » à trois d'entre elles n'est pas en retard : il n'a pas commencé.
Notre IA Factory prend les projets exactement à cet endroit : celui où le démonstrateur doit devenir un service exploitable, sécurisé et supervisé.
Voir l'offre IA FactorySujets liés : exposer ses documents en branchant une IA et le cadrage des cas d'usage, qui évite de construire un POC dont personne ne voulait.