Votre app vibe codée fonctionne. Maintenant, il faut pouvoir lui faire confiance.

La dette technique n’est pas née avec les assistants IA. Vous pouvez déjà reprendre une codebase mal documentée, hériter du travail d’un prestataire ou découvrir des décisions que plus personne ne maîtrise complètement.

Le vibe coding accentue cependant un phénomène particulier : vous pouvez produire beaucoup plus vite que vous ne construisez un modèle mental du système.

Avec un développement plus traditionnel, une partie de cette compréhension se construit en écrivant le code. Quand vous demandez à un agent d’ajouter une authentification, un espace client et un système de paiement, vous pouvez obtenir rapidement une démonstration convaincante sans avoir nécessairement répondu à des questions comme :

• où sont réellement vérifiées les permissions ?
• un utilisateur peut-il accéder aux données d’une autre organisation en modifiant une requête ?
• que se passe-t-il si un webhook arrive deux fois ?
• une migration peut-elle rendre incohérentes des données existantes ?
• quels services tiers ont été ajoutés ?
• qu’arrive-t-il si un appel à un modèle prend trente secondes ou coûte cent fois plus que prévu ?

Ces questions ne signifient pas que votre prototype est mauvais. Elles étaient souvent simplement hors de son objectif initial.

GitHub formule la même prudence dans sa documentation sur Copilot : le code généré peut paraître valide tout en étant incorrect ou vulnérable, et doit être revu et testé avant d’être intégré (GitHub Docs).

Un prototype cherche d’abord à vérifier qu’un usage mérite d’exister. En production, vous devez aussi garantir que le produit continue à fonctionner lorsque les conditions deviennent moins favorables : plus d’utilisateurs, plus de données, un service externe indisponible, une erreur de manipulation ou un changement de version.

Mais ces garanties ne sont pas absolues. Un outil interne utilisé par cinq personnes identifiées n’a pas le même profil de risque qu’un SaaS multi-tenant ouvert au public. Le Secure Software Development Framework du NIST suit cette logique : les pratiques doivent être adaptées au contexte, à la tolérance au risque, aux ressources et au coût.

Si vous récupérez une application que vous connaissez mal, votre premier réflexe sera souvent d’ouvrir le repository et de chercher ce qui semble « sale ». Ce n’est pourtant pas le meilleur point de départ.

Commencez plutôt par comprendre :

• qui utilise le système et avec quels rôles ;
• où vivent les données sensibles ;
• quels services externes interviennent ;
• quels traitements sont asynchrones ;
• quelles actions sont coûteuses, irréversibles ou difficiles à rejouer ;
• où le niveau de confiance change.

Cette dernière notion est importante. En threat modeling, OWASP recommande de représenter les flux de données, les acteurs externes et les frontières de confiance — les endroits où une donnée passe d’une zone où vous contrôlez ce qui se passe à une zone où vous ne le contrôlez plus — avant de raisonner sur les menaces.

Prenez une application SaaS avec un frontend, une API, PostgreSQL, Stripe et un modèle LLM externe. Le repository vous montre des modules. La cartographie des risques vous montre autre chose : les endroits où une donnée passe du navigateur vers l’API, d’un tenant à ses données, de votre backend vers Stripe ou de votre base vers un modèle externe.

C’est à ces frontières qu’il devient utile de demander quelles vérifications sont réellement effectuées et quelles hypothèses sont implicites. Une fonction de 80 lignes est rarement un risque en soi. Une règle d’autorisation implicite peut l’être.

Une fois le système compris, relire toute la codebase avec la même intensité est rarement le meilleur usage du temps.

Il est plus utile de commencer par les invariants : les propriétés qui doivent rester vraies.

Dans un SaaS B2B :

Dans un système de paiement :

Pour une intégration externe :

À partir de là, vous pouvez construire les contrôles qui apportent réellement de la confiance. Pour l’isolation entre tenants, par exemple, une matrice de tests explicite est souvent plus utile qu’un objectif abstrait de couverture :

Le contrôle d’accès cassé reste la première catégorie de l’OWASP Top 10 2025, et OWASP publie un guide spécifique sur les tests de régression d’autorisation.

Même logique pour l’idempotence : Stripe documente explicitement qu’un même événement webhook peut être reçu plusieurs fois et recommande de mémoriser les événements déjà traités (Stripe Docs).

La question n’est donc pas « avons-nous assez de tests ? », mais quelles propriétés importantes sommes-nous capables de défendre ?

Une codebase peut être imparfaite sans être dangereuse. À l’inverse, une application très propre peut cacher une hypothèse métier critique jamais testée.

Pour chaque zone sensible, regardez au moins cinq choses :

La probabilité compte, mais elle ne décide pas seule : sur un invariant de sécurité, l’étendue prime souvent, parce qu’une probabilité faible mais non nulle appliquée à l’ensemble de vos clients reste inacceptable.

Avant la production, nous regardons presque toujours les autorisations, l’isolation des tenants, les secrets, les migrations, l’intégrité des données, l’idempotence, les dépendances externes, les sauvegardes, les coûts variables et l’observabilité.

À l’inverse, duplication non critique, conventions hétérogènes, nommage moyen ou refactorings purement esthétiques peuvent souvent attendre.

L’OWASP Top 10 2025 place aussi les Software Supply Chain Failures en troisième position, ce qui justifie de regarder sérieusement les dépendances et la chaîne de build sur un prototype assemblé rapidement.

Une fois les risques prioritaires identifiés, les garde-fous deviennent beaucoup plus simples à choisir.

La question de la réécriture revient presque systématiquement quand vous reprenez un prototype. Notre position n’est pas « il ne faut jamais réécrire ».

Deux missions Vezero montrent les deux réponses possibles.

Passer en production ne signifie pas qu’il faut arrêter d’utiliser Cursor, Claude Code ou d’autres agents. Ce qui change, c’est la nature des instructions que vous leur donnez.

Pendant le prototypage :

Une fois le système critique :

Dans le premier cas, vous demandez à l’outil de produire une fonctionnalité. Dans le second, vous lui demandez de produire un changement sous contraintes.

GitHub recommande une approche similaire : utiliser tests et analyses automatisées, vérifier que le changement respecte l’architecture du projet et fournir à l’IA des sources de vérité comme la documentation ou les conventions du repository (GitHub Docs).

Il n’existe pas de score universel de production readiness. Mais sur un périmètre donné, vous devriez pouvoir répondre à trois questions :

Elles recouvrent exactement les trois garde-fous précédents : empêcher, voir, récupérer.

Si vous savez y répondre pour vos zones critiques, et que ces réponses sont testées plutôt que supposées, votre produit peut être prêt même si son code contient encore des imperfections. À l’inverse, un repository impeccable ne suffit pas si personne ne sait y répondre.