Mettre ton app vibecodée en prod sans qu'elle lâche : les 3 points critiques

En bref : les 3 zones à vérifier avant de déployer

Une app qui tourne nickel sur ton laptop et une app qui tient en prod, ce sont deux choses différentes. Le passage à la prod fait tomber, presque toujours, sur les trois mêmes zones : la configuration et les secrets, les données réelles et la charge, et la gestion des pannes des services externes. Si tu vibecodes vite, l'IA t'écrit un code qui marche pour le cas nominal — celui de ta démo — mais elle ne devine pas ton environnement de prod, ni ce que fait un vrai utilisateur, ni ce qui se passe quand l'API tierce répond en 3 secondes ou pas du tout. C'est là que ça casse.

Le contexte n'est pas neutre : David Mytton, CEO d'Arcjet, prédit dans The New Stack (janvier 2026) de « grosses explosions » d'apps vibecodées déployées en prod sans revue. Pas une fatalité — juste un angle mort classique. Avant de déployer, tu passes ces trois zones au crible. Concrètement : tu sors toute config du code, tu testes avec des données sales et du volume, et tu supposes que chaque appel réseau va échouer. Le reste de l'article détaille quoi vérifier, dans l'ordre.

Zone 1 — Configuration, secrets et environnement

C'est le point n°1 des plantages au déploiement, et le plus bête à éviter. En vibecodant, l'IA a tendance à écrire des valeurs en dur : une URL localhost, une clé API collée dans le fichier, un port fixe, un DEBUG = true. Ça marche chez toi. En prod, l'URL n'existe pas, la clé est exposée dans ton dépôt Git, et le mode debug crache ta stack trace au premier visiteur.

Ce que tu vérifies avant de déployer :

Aucun secret dans le code ni dans Git. Clés API, tokens, mots de passe de base de données : tout passe par des variables d'environnement. Tu grep ton dépôt pour api_key, secret, password, token — et tu vérifies l'historique Git, pas juste l'état actuel.
Zéro valeur en dur d'environnement. Pas de localhost, pas d'URL de dev, pas de chemin absolu de ta machine. Tout ce qui change entre ton laptop et la prod est une variable.
Le mode debug est coupé. Les messages d'erreur détaillés révèlent ta structure interne. En prod : logs côté serveur, message générique côté utilisateur.
Les migrations et la config de base tournent au démarrage, pas « à la main quand j'y penserai ».
Un fichier .env.example liste toutes les variables attendues, sans les valeurs. Tu redéploies dans six mois, tu sais quoi remplir.

Le test qui ne ment pas : clone ton dépôt dans un dossier vierge, sans ton .env, et lance-le. S'il démarre alors qu'il ne devrait pas, ou s'il plante sans te dire quelle variable manque, tu as du travail.

Zone 2 — Données réelles et charge

Ta démo tourne sur trois lignes de données propres que tu as saisies toi-même. Les vrais utilisateurs, eux, envoient des chaînes vides, des emojis, du texte de 10 000 caractères, des apostrophes qui cassent tes requêtes, et ils cliquent deux fois sur « Envoyer ». Le code vibecodé gère rarement ça d'office, parce que le prompt décrivait le happy path.

Ce que tu vérifies :

Validation des entrées côté serveur. La validation côté navigateur, c'est du confort UX — elle ne protège rien. Tout ce qui arrive sur ton backend est supposé hostile jusqu'à preuve du contraire.
Requêtes paramétrées, jamais de concaténation SQL. C'est la porte d'entrée n°1 de l'injection. Si l'IA t'a écrit une requête en collant des variables dans une chaîne, tu la réécris.
Pagination et limites. Un SELECT * sans limite qui rend bien sur 10 lignes ramène 50 000 lignes en prod et fait tomber la page. Toute liste est paginée ou bornée.
Index sur les colonnes filtrées et triées. Sans index, les requêtes ralentissent silencieusement à mesure que la table grossit. Ça ne plante pas le jour du lancement — ça se dégrade sur trois semaines.
Idempotence sur les actions sensibles. Double-clic sur « Payer », requête rejouée après un timeout : ton code ne doit pas créer deux commandes.

Un petit test de charge suffit à débusquer l'essentiel. Tu injectes quelques milliers de lignes réalistes, tu lances 50 requêtes en parallèle, et tu regardes ce qui casse ou traîne. Tu n'as pas besoin d'outil sophistiqué : une boucle et un peu de patience révèlent déjà les requêtes non indexées et les fuites de connexions.

Zone 3 — Pannes des services externes

Ton app appelle sûrement des trucs qu'elle ne contrôle pas : une API de paiement, un service d'e-mail, un LLM, un stockage objet. En dev, ils répondent vite et bien. En prod, ils tombent, ils rate-limitent, ils répondent en 4 secondes, ils renvoient un 500. Le code vibecodé suppose presque toujours que l'appel réussit — pas de timeout, pas de retry, pas de plan B. Résultat : un service tiers qui hoquette fait tomber toute ton app.

La règle de pair senior : tout appel réseau échouera un jour, code comme si c'était aujourd'hui.

Ce que tu vérifies :

Un timeout sur chaque appel sortant. Sans timeout, une requête qui pend bloque un worker, puis deux, puis tout le pool. C'est comme ça qu'un ralentissement chez un fournisseur devient une panne totale chez toi.
Retry avec backoff sur les erreurs transitoires — mais pas sur tout. On réessaie un timeout ou un 503, jamais un 400.
Un comportement de repli défini. Le service d'e-mail est down : tu mets en file d'attente et tu réessaies plus tard, plutôt que de jeter une erreur 500 à l'utilisateur qui, lui, n'y est pour rien.
Les erreurs sont loguées avec du contexte, pas avalées en silence. Un catch vide, c'est une panne que tu découvriras par un utilisateur mécontent.
Les clés/quotas des tiers sont surveillés. Un quota d'API épuisé à 2 h du matin sans alerte, c'est une nuit blanche.

Récap : les 3 zones en un coup d'œil

Zone	Ce qui casse	Le réflexe
Config & secrets	Valeurs en dur, clés dans Git, debug ouvert	Tout en variables d'env, rien en dur
Données & charge	Entrées non validées, requêtes lentes, doublons	Valider côté serveur, paginer, indexer
Services externes	Pas de timeout, pas de repli	Timeout partout, retry ciblé, plan B

Par où commencer si tu as peu de temps

Si tu ne dois faire qu'une chose : sors les secrets du code et coupe le debug. C'est cinq minutes et ça élimine la classe de plantages la plus fréquente et la plus visible. Ensuite, ajoute un timeout sur ton appel externe le plus critique. Enfin, teste avec des données sales. Ces trois gestes couvrent une bonne partie de ce qui lâche vraiment en prod — et aucun ne demande de réécrire ton app.

Vibecoder vite et déployer solide ne s'opposent pas. Tu gardes la vitesse de l'IA, tu ajoutes la relecture ciblée d'un senior sur trois zones connues. C'est tout l'écart entre une démo et un produit.

FAQ

Le vibecoding est-il fiable pour de la prod ? Oui, à condition de relire ce que l'IA ne couvre pas d'elle-même. Le code généré vise le cas nominal ; la prod exige de gérer la config, les données réelles et les pannes. Ces trois relectures suffisent à combler l'essentiel de l'écart.

Quelle est l'erreur la plus fréquente au passage en prod ? Les valeurs en dur : URL localhost, clés API dans le code, mode debug laissé ouvert. C'est le premier réflexe à vérifier, parce que c'est à la fois le plus courant et le plus rapide à corriger.

Faut-il un outil de test de charge pour vibecodeur solo ? Non, pas pour commencer. Quelques milliers de lignes réalistes et une cinquantaine de requêtes en parallèle depuis un petit script révèlent déjà les requêtes non indexées et les fuites de connexions. Les outils dédiés viennent plus tard, quand le trafic le justifie.