Du prototype à la production : ce dont une ébauche de vibe coding a encore besoin

Un prototype ne devient pas prêt pour la production parce qu'il fonctionne. Il le devient lorsque l'on a clarifié ce qui se passe en cas de saisies erronées, d'accès simultanés, de droits manquants et de défaillance — et lorsque quelqu'un peut l'exploiter, le modifier et, en cas d'urgence, le faire revenir en arrière. Ce sont douze points vérifiables, et pas seulement une question de qualité du code.

Pourquoi le passage du prototype à l'exploitation échoue-t-il si souvent ?

Parce qu'un prototype répond à une autre question qu'un produit. Le prototype répond à : est-ce seulement possible ? Le produit répond à : est-ce que cela tient lorsque cent personnes l'utilisent mal en même temps, que le réseau tombe et que, dans dix-huit mois, quelqu'un d'autre doit y intégrer une modification ?

Le prototype n'a de réponse à aucune de ces questions — non pas parce qu'il serait mal construit, mais parce qu'elles n'ont pas été posées. Le danger naît du pouvoir de conviction du résultat : ce qui a été présenté sans faille en réunion paraît plus abouti qu'il ne l'est.

Quels sont les douze points à clarifier avant la mise en ligne ?

Couche de données

• Mettre à niveau le modèle de données. Les prototypes stockent souvent tout à plat et sans relations. Ce qui fonctionne dans une démo empêche ensuite toute exploitation et toute modification.
• Rendre les migrations réversibles. Toute modification de schéma a besoin d'un chemin de retour. Une étape de migration générée sans contrepartie est une voie à sens unique.
• Vérifier la simultanéité. Que se passe-t-il lorsque deux utilisateurs modifient en même temps le même enregistrement ? Jamais survenu dans le prototype, survenu dès le premier jour en exploitation.

Exactitude

• Implémenter les cas d'erreur. L'OWASP Top 10:2025 range pour la première fois les exceptions mal traitées dans une catégorie à part (A10). Le code généré implémente de façon fiable le cas normal et avale le reste.
• Valider les saisies. Côté serveur, pas seulement dans le formulaire. Les prototypes contrôlent dans le navigateur, parce que cela suffit pour la démonstration.
• Écrire des tests pour le comportement à protéger. Voir Couverture de tests du code IA.

Accès

• Expliciter les droits d'accès. Pour chaque point d'accès, une question à laquelle on répond : qui peut l'appeler, et que se passe-t-il si quelqu'un d'autre essaie ? Le contrôle d'accès défaillant occupe toujours la première place de l'OWASP Top 10:2025.
• Sortir les secrets du code source. Les prototypes portent des identifiants dans le code, parce que c'était plus rapide.

Exploitation

• Inventorier les dépendances. Quels paquets sont présents, qui les maintient, sous quelle licence ? Les défaillances de la chaîne d'approvisionnement forment depuis 2025 une catégorie OWASP à part (A03).
• Journalisation et alerte. Si personne ne remarque que c'est cassé, c'est cassé plus longtemps.
• Chemin de retour arrière. Un déploiement sans retour possible est la promesse de ne commettre aucune erreur.
• Clarifier la protection des données. Quelles données personnelles sont traitées, sur quelle base juridique, pendant combien de temps sont-elles conservées, qui les traite pour votre compte ?

Vaut-il la peine de réécrire le prototype ?

Plus souvent qu'on ne le ressent — mais la décision devrait reposer sur un critère, et non sur une intuition. Le critère est le suivant : quelqu'un dans l'équipe comprend-il la structure assez bien pour la modifier de façon ciblée ?

• Oui : alors la mise à niveau est la voie la moins coûteuse. Traitez les douze points ci-dessus, dans cet ordre.
• Non : alors vous paierez la reconstruction de toute façon — soit maintenant, en connaissance de cause, soit plus tard, répartie sur chaque modification. Le prototype reste précieux comme spécification : il montre exactement ce que le produit doit faire.

Ce second cas est régulièrement sous-estimé dans le débat sur les outils d'IA. Les données de GitClear montrent que la véritable restructuration du code est en net recul : la part de code déplacé est passée de 21 % en 2022 à 3,8 % en 2026. Là où l'on ne restructure plus, c'est un patrimoine qui grossit, que plus personne ne voudra bientôt toucher.

Comment planifier la transition de façon réaliste ?

Chiffrez la transition comme un projet à part entière, et non comme un reliquat de travail. Un prototype né en deux jours exige typiquement, pour ces douze points, un multiple de ce temps — et ce n'est pas un échec, mais la répartition normale : la démo n'en est que la petite partie.

Une autre démarche est plus fiable que toute estimation forfaitaire : passer en revue les douze points, évaluer chacun séparément (fait, ouvert, incertain) et n'estimer que les points ouverts. Cela prend une heure et remplace une discussion qui, sinon, traverse tout le projet. Si vous souhaitez être accompagné sur cette voie en tant que prestation, notre développement SaaS est fait pour cela.

Questions fréquentes sur la mise en production

Puis-je mettre directement en ligne un prototype construit avec Lovable ou Bolt ?

Techniquement oui, de façon responsable seulement après les mêmes douze points. L'origine du code ne change pas les exigences : dès que de vrais utilisateurs et de vraies données sont concernés, elles s'appliquent, que ce soit un humain ou une machine qui ait écrit le code.

Suffit-il que les tests soient au vert ?

Non. Les tests vérifient ce que quelqu'un savait devoir vérifier. Pour un prototype, c'est précisément la lacune : les cas d'erreur auxquels personne n'a pensé ne sont pas testés non plus.

Quel est le point le plus souvent négligé ?

Les droits d'accès. La logique métier est implémentée de façon fiable parce qu'elle figure dans la commande. La question « cet utilisateur en a-t-il le droit ? » figure rarement dans la commande et fait donc souvent défaut.

Dois-je faire vérifier le prototype au préalable par quelqu'un ?

Un audit de code externe avant la mise en production est nettement moins coûteux qu'après un incident. Ce que vérifie un tel audit figure dans notre liste de contrôle pour l'audit de code.

Les douze points sont vite cochés et difficiles à traiter réellement. Code Guardian rattache les plus risqués d'entre eux — migration, déploiement, nouvelle dépendance — à des gates qui se tiennent devant l'étape concernée et exigent une validation, plutôt que de compter sur le fait que la liste soit rappelée au bon moment.

Sources

• OWASP Top 10:2025 (catégories A01 Broken Access Control, A03 Software Supply Chain Failures, A10 Mishandling of Exceptional Conditions), version finale de janvier 2026.
• GitClear, The Maintainability Gap: 2026 AI Code Quality Research.

Date : 27 juillet 2026. Appréciation technique d'ordre général ; l'ampleur concrète dépend du cas particulier et ne remplace pas une vérification individuelle.