Prototype IA en production : ce qu'il reste à faire

Un prototype IA qui tourne en démo n'est prêt pour la production que sur 20 % du chemin, pas 80 %. La partie visible, celle qui impressionne en réunion, est aussi la plus facile à produire avec les outils de vibe coding actuels. Ce qui reste est invisible tant que personne ne le cherche : gestion d'erreur, sécurité des accès, tests, observabilité, coût à l'échelle.

Ce n'est un jugement ni sur la méthode ni sur la personne qui l'a construit. Le vibe coding excelle pour valider une idée en quelques jours, c'est exactement son rôle. Le problème apparaît quand on confond validation d'une idée et système de production, et qu'on planifie un déploiement la semaine suivante sur cette base.

Voici l'inventaire honnête de ce qui sépare les deux, ce que chaque écart coûte en risque réel, et comment garder la valeur du prototype sans lui faire porter un rôle qu'il n'a jamais été construit pour tenir.

Guide pilier

Cet article fait partie de notre Guide projet IA en PME, qui regroupe l'ensemble de nos ressources sur le sujet.

Prototype IA vibe codé face à un système de production : écart entre démo fonctionnelle et déploiement en entreprise — Le prototype prouve l'idée. Le système de production doit tenir face aux données réelles, aux pannes et au volume.

En bref

Un prototype vibe-codé qui fonctionne en démo n'a résolu que la partie visible du problème : l'interface et le chemin nominal
Neuf chantiers séparent un prototype d'un système de production : données réelles, gestion d'erreur, secrets, tests, observabilité, coût, charge, conformité, reprise en main
Selon le projet NANDA du MIT (2025), 95 % des pilotes d'IA générative en entreprise ne produisent aucun effet mesurable sur le résultat, souvent parce que le passage à l'échelle n'a jamais été traité comme un chantier à part entière
Le prototype garde une vraie valeur une fois industrialisé ailleurs : il documente le besoin métier mieux qu'un cahier des charges rédigé à froid

Pourquoi un prototype IA qui fonctionne n'est pas prêt pour la production

Un prototype réussi valide une hypothèse métier avec le minimum de code nécessaire pour la tester. Un système de production doit rester fiable face à des données qu'il n'a jamais vues, des pannes qu'il ne contrôle pas, et un volume d'utilisateurs qui dépasse largement l'équipe qui l'a testé. Ce sont deux objectifs différents, pas deux étapes du même travail.

C'est un écart mesuré à grande échelle. Selon le rapport Project NANDA du MIT (2025), fondé sur l'analyse de plus de 300 initiatives IA en entreprise, 95 % des pilotes d'IA générative intégrés ne produisent aucun effet mesurable sur le résultat de l'entreprise. La cause dominante n'est pas la qualité des modèles, c'est l'intégration : le pilote fonctionne dans un environnement contrôlé, la production exige une tout autre robustesse.

Voici l'inventaire des neuf chantiers qui séparent concrètement un prototype d'un système déployable, avec le risque réel de les ignorer et l'effort approximatif pour les traiter.

Chantier	Symptôme dans le prototype	Risque en production	Effort
Données et cas limites	Testé sur un jeu de données propre et choisi	Plantage ou réponse fausse sur des entrées réelles	Moyen à élevé
Gestion d'erreur	Le chemin nominal seul est géré	Panne silencieuse, pas de reprise après échec	Moyen
Secrets et accès	Clés API en dur dans le code	Fuite, usage frauduleux, perte de données	Faible à moyen
Tests	Aucun test automatisé	Toute évolution risque de casser l'existant	Moyen à élevé
Observabilité	Aucun log structuré, aucune alerte	L'échec est signalé par le client, pas par le système	Moyen
Coût à l'échelle	Facture API testée sur quelques requêtes	Facture qui explose au premier vrai volume	Faible à moyen
Montée en charge	Un seul utilisateur à la fois en test	Ralentissement ou blocage sous charge réelle	Moyen à élevé
Conformité et traçabilité	Aucune trace de qui a fait quoi, sur quelles données	Non-conformité RGPD, incapacité à justifier une décision	Moyen
Reprise en main	Code généré sans intention d'architecture	Personne d'autre ne peut le faire évoluer sereinement	Élevé

Aucun de ces neuf points n'est visible dans une démo, et c'est précisément le problème : ils ne se manifestent qu'une fois le système exposé à des conditions que le prototype n'a jamais rencontrées. Cette grille sert justement à objectiver ce qui reste à faire, poste par poste, avant tout engagement de date.

Les données et les cas limites : ce que la démo n'a jamais vus

Un prototype tourne sur un échantillon de données choisi pour fonctionner, la production reçoit tout ce que les utilisateurs réels lui envoient : doublons, formats incohérents, champs vides, fichiers corrompus, tentatives volontaires de contournement. C'est la première cause de plantage silencieux d'un système qui marchait très bien en démo.

Le prototype tourne sur des données propres et choisies

Quand un stagiaire ou un dirigeant construit un prototype, il le teste avec les données qu'il a sous la main : un export récent, quelques dizaines de lignes, des documents qu'il connaît déjà. Ces données sont implicitement filtrées par le fait même qu'elles servent à tester. Elles ne contiennent presque jamais les anomalies qui existent réellement dans le système d'information de l'entreprise.

La production reçoit tout, sans tri préalable

Une fois déployé, le système reçoit des entrées que personne n'a anticipées : un client qui colle un tableau entier dans un champ texte, une date au mauvais format, un fichier PDF scanné à l'envers, une requête dans une langue non prévue. Sans un traitement explicite de ces cas, le système soit plante, soit pire, répond quand même avec une donnée fausse, sans le signaler.

Le cas limite silencieux est le plus dangereux

Un plantage visible s'arrête et se corrige vite. Le vrai risque, c'est le cas limite qui produit une réponse plausible mais fausse : un montant mal extrait, une date inversée, un document mal classé. Personne ne le voit tant que la conséquence métier ne remonte pas, parfois des semaines plus tard.

Erreurs, secrets et sécurité : ce qui casse en silence

Un code de prototype gère le cas où tout se passe bien. Il ne gère presque jamais ce qui se passe quand une API tierce répond mal, quand une connexion tombe, ou quand un identifiant se retrouve accessible à un composant qui n'en a pas besoin. Ces deux angles morts, l'erreur non gérée et le secret mal cloisonné, sont responsables des incidents les plus coûteux.

Pas de gestion d'erreur, pas de reprise après échec

Dans un prototype, une erreur d'API, un timeout ou une réponse mal formée du modèle fait souvent tout simplement planter le script, ou pire, se relance en boucle sans limite. En production, chaque point d'échec doit avoir une réponse prévue : retenter avec une limite, dégrader proprement le service, notifier plutôt que planter. Sans cela, un incident mineur chez un fournisseur externe (l'API d'un modèle, une base de données) devient une panne complète chez vous.

Secrets et clés API en dur dans le code

C'est le raccourci le plus fréquent en vibe coding : coller une clé API directement dans un fichier pour avancer vite, sans jamais revenir la retirer avant de partager ou de déployer le code. Le risque n'est pas théorique. Le 25 avril 2026, un agent de codage autonome a supprimé la base de production de l'éditeur PocketOS et ses sauvegardes en moins de dix secondes, après avoir trouvé dans un fichier sans rapport avec sa tâche un jeton disposant de privilèges élevés sur l'ensemble du compte d'hébergement (The Register, avril 2026). Les analyses convergentes pointent l'absence de cloisonnement du jeton et des sauvegardes stockées dans la même zone de risque que la production.

Ce que cet incident change concrètement

Un secret ne doit jamais apparaître en clair dans un fichier de code, même annexe
Chaque jeton d'accès doit être limité au strict périmètre dont il a besoin, jamais un accès global "par confort"
Une sauvegarde stockée au même endroit que la production n'est pas une sauvegarde
Un agent de codage autonome hérite des droits du jeton qu'il trouve : la vigilance sur les accès compte plus que la confiance dans l'outil

Tests, observabilité et coûts : piloter un système qu'on ne voit plus tourner

Un prototype se pilote à l'œil, en le regardant tourner sur son écran. Un système en production tourne en dehors du champ de vision de son créateur, souvent la nuit, un week-end, ou pendant un pic d'activité imprévu. Sans tests automatisés, sans observabilité et sans visibilité sur le coût réel, personne ne sait ce qui se passe tant que le client ne le signale pas.

Sans tests, on ne peut plus faire évoluer sans casser

Un prototype vibe-codé n'a généralement aucun test automatisé, ce qui est cohérent avec son objectif : aller vite pour valider une idée. Le problème arrive après, à la première modification. Sans tests, chaque changement risque de casser une fonctionnalité qui marchait, sans que personne ne le remarque avant la mise en production suivante. C'est la raison pour laquelle un prototype qui évolue vite en semaine 1 ralentit brutalement en semaine 6 : chaque ajout devient plus risqué que le précédent.

Observabilité : savoir que ça a échoué avant le client

En production, la question n'est pas si un incident va se produire, mais comment on le sait. Sans logs structurés, sans métriques de base (taux d'erreur, temps de réponse, volume traité) et sans alerte, la seule source d'information devient le client qui se plaint. C'est le signal le plus tardif, le plus coûteux en confiance, et le plus difficile à débugger a posteriori faute de traces.

Le coût réel à volume réel, et la montée en charge

Un prototype testé sur quelques dizaines de requêtes ne révèle rien du coût à l'échelle. Passer de 50 requêtes par jour à 5 000 ne multiplie pas seulement la facture d'API par 100 : cela peut aussi révéler des appels redondants, des re-calculs évitables, ou un modèle surdimensionné pour la tâche. La montée en charge pose la même question côté infrastructure : un script qui traite les requêtes une par une tient très bien pour une démo et s'effondre au premier pic d'utilisateurs simultanés.

Conformité, traçabilité et reprise en main : industrialiser sans tout reconstruire

Un prototype interne échappe souvent aux obligations qui s'appliquent dès qu'il traite des données de clients ou de salariés à l'échelle. Traçabilité des décisions, conservation des données, capacité à expliquer un résultat : ce sont des exigences qui ne se rattrapent pas après coup aussi facilement qu'on l'imagine, et qui conditionnent aussi la capacité d'une autre personne à reprendre le système.

Conformité et traçabilité

Dès qu'un système IA traite des données personnelles ou influence une décision qui concerne un client ou un salarié, des obligations s'appliquent : base légale du traitement, durée de conservation, capacité à expliquer comment une réponse a été produite. La CNIL publie des recommandations précises sur ces points pour les systèmes d'IA en entreprise. Un prototype qui n'a jamais eu vocation à être audité n'a généralement aucune trace de ces éléments, ce qui devient un vrai chantier au moment de la mise en production, pas un détail administratif.

La reprise en main par quelqu'un d'autre

Un code généré par itérations successives avec un assistant IA, sans intention d'architecture posée au départ, fonctionne souvent très bien tant que la personne qui l'a écrit reste dans la boucle. Le problème apparaît quand quelqu'un d'autre doit le reprendre : la logique n'est pas toujours cohérente d'un module à l'autre, les décisions ne sont pas documentées, et il n'existe pas toujours de séparation claire entre les responsabilités du code. Reprendre un tel prototype demande souvent de comprendre d'abord ce qu'il fait vraiment, avant de pouvoir le faire évoluer sereinement. C'est un travail d'audit à part entière, très proche de ce qu'implique de reprendre un projet IA laissé par un autre prestataire, à ceci près que l'auteur du prototype est souvent encore joignable.

Ce qui se garde du prototype vibe-codé

Un prototype vibe-codé garde une vraie valeur même quand son code n'est pas repris tel quel en production. Il documente le besoin métier réel mieux qu'un cahier des charges rédigé à froid, parce qu'il a été confronté à de vrais utilisateurs et à leurs usages spontanés, pas seulement à des hypothèses sur papier.

Le prototype documente le besoin mieux qu'un cahier des charges

Un cahier des charges décrit ce qu'on pense vouloir avant de l'avoir testé. Un prototype montre ce que les utilisateurs font réellement : les fonctionnalités qu'ils utilisent, celles qu'ils ignorent, les formulations qu'ils emploient spontanément, les raccourcis qu'ils cherchent. C'est une information qu'aucun atelier de cadrage ne produit avec la même précision.

Ce qui se récupère techniquement, et ce qui se réécrit

Dans la pratique, les prompts qui fonctionnent, la logique métier validée et le périmètre fonctionnel confirmé se gardent presque toujours. Ce qui se réécrit le plus souvent : la gestion des secrets, la gestion d'erreur, la couche de tests, et parfois l'architecture des données si elle n'a pas été pensée pour tenir dans la durée. Un audit du code existant permet de trancher poste par poste, plutôt que de tout jeter par principe ou de tout garder par économie mal placée.

Comment capitaliser sans repartir de zéro

La bonne séquence consiste à garder le prototype comme spécification vivante : ce qu'il fait, comment les utilisateurs s'en servent, où il échoue. Puis à faire trancher, module par module, ce qui peut être industrialisé tel quel et ce qui doit être reconstruit avec une intention d'architecture, de tests et de sécurité posée dès le départ. C'est exactement la logique que nous avons détaillée dans notre méthode de pilote IA en 3 mois, qui distingue la phase de validation de la phase de construction du système final. Si votre équipe a été formée au vibe coding et souhaite structurer sa pratique en amont, notre formation vibecoding avec Claude Code couvre précisément ce moment de bascule entre prototype et système structuré.

Le vibe coding n'est pas le problème. Le problème est de traiter un objet conçu pour valider une idée comme s'il était déjà un objet conçu pour durer. Un prototype et un système de production sont deux objets différents, avec des exigences différentes, et le passage de l'un à l'autre est un projet à part entière, pas une formalité de dernière minute avant le déploiement.

Questions fréquentes

Parce qu'une démo tourne dans des conditions choisies : données propres, scénarios prévus, un seul utilisateur à la fois, aucune coupure réseau. La production reçoit tout ce que la démo n'a jamais vu : entrées malformées, pics de charge, pannes d'API tierces, utilisateurs qui sortent du chemin prévu. Le code qui gère le cas nominal ne gère pas automatiquement ces situations, il faut l'écrire spécifiquement.

Cela dépend du périmètre, mais l'ordre de grandeur observé sur des projets d'entreprise se compte en semaines, rarement en jours, quand le prototype touche des données sensibles ou un volume réel d'utilisateurs. Le travail porte sur la gestion d'erreur, les tests, la sécurité des accès, l'observabilité et le coût à l'échelle : autant de chantiers qui ne se voient pas dans une démo mais qui conditionnent la fiabilité en production.

Rarement en totalité. La logique métier validée par le prototype, les prompts qui fonctionnent, les cas d'usage confirmés se gardent. Ce qui se réécrit le plus souvent : la gestion des secrets, la gestion d'erreur, la couche de tests et parfois l'architecture des données si elle n'a pas été pensée pour tenir dans la durée. Un audit du code existant permet de trancher poste par poste plutôt que de tout jeter par principe.

Les plus fréquents : une clé API ou un jeton d'accès laissé en dur dans le code qui finit exposé, une absence de gestion d'erreur qui plante silencieusement sur des cas non prévus, aucune trace de ce qui s'est passé quand un client signale un problème, et une facture API qui explose au premier pic de volume. Aucun de ces risques n'est visible tant que le prototype ne sert qu'à quelques personnes en interne.

La règle de base : aucun secret ne doit apparaître en clair dans le code, même dans un fichier qui semble sans rapport avec la fonctionnalité en cours. Les clés se stockent dans un gestionnaire de secrets ou des variables d'environnement, avec des droits limités à ce qui est strictement nécessaire (principe du moindre privilège), et une rotation possible sans redéploiement complet. Un jeton à privilèges larges oublié dans un fichier annexe est l'une des causes les plus documentées d'incident grave en 2026.

Oui, et c'est souvent sous-estimé. Le prototype documente le vrai besoin métier mieux qu'un cahier des charges rédigé à froid : il montre les cas d'usage que les utilisateurs testent spontanément, les formulations qu'ils emploient, les fonctionnalités qu'ils ignorent. Même quand le code n'est pas repris tel quel, ces enseignements évitent de reproduire les angles morts du cadrage initial dans la version de production.

Idéalement quelqu'un qui n'a pas peur de remettre en question les choix du prototype, avec une compétence d'architecture logicielle et de sécurité, pas seulement de génération de code assisté par IA. La personne qui a produit le prototype (dirigeant, stagiaire, développeur junior) reste une ressource précieuse pour expliquer l'intention métier, mais la reprise technique gagne à être auditée par un regard extérieur avant tout engagement de date de mise en production.

Un prototype qui marche, et maintenant ?

Faisons l'audit de ce qu'il reste à faire avant de déployer.

Réserver un Audit IA Gratuit

Aller plus loin

Découvrez notre audit technique RAG et Agents IA pour objectiver ce qu'il reste à faire sur votre prototype, ou notre offre de développement d'applications et SaaS IA si une reconstruction ciblée est la meilleure voie.