Une app générée par IA plante après le déploiement : workflow simple pour corriger

Ce que signifie généralement « plante après le déploiement »

Quand une app construite par IA fonctionne en local mais échoue juste après le déploiement, la production atteint en général un chemin que votre poste n'a jamais vraiment testé. En local vous avez des valeurs par défaut de dev, un serveur tolérant et des sessions en cache. En production, la plateforme est plus stricte et le trafic moins prévisible.

« Plantage » peut vouloir dire plusieurs choses, et la formulation compte parce qu'elle indique où regarder :

• Une page blanche ou un spinner qui tourne indéfiniment (souvent une erreur frontend ou un appel API raté)
• Une erreur 500 sur un écran ou un endpoint API (l'app tourne, mais une route échoue)
• Une boucle de redémarrage où le service monte puis crashe en continu (souvent config au démarrage, secrets manquants ou mismatch build/runtime)
• Un échec de connexion seulement après le déploiement (raccourcis d'auth, cookies ou paramètres d'environnement incorrects)

Les prototypes générés par IA cassent après le déploiement pour des raisons prévisibles : variables d'environnement manquantes ou mal nommées, paramètres d'auth qui ne correspondent pas au domaine réel, étapes de build qui réussissent localement mais pas sur le serveur, et problèmes de base de données (chaîne de connexion erronée, migrations non appliquées, ou nom de table différent).

L'objectif n'est généralement pas une réécriture. La plupart des échecs post‑déploiement se ramènent à une route qui échoue et une cause concrète, comme un secret manquant ou une seule requête foireuse. Si vous pouvez reproduire le crash, identifier la requête exacte qui le déclenche et lire le log approprié à ce moment, la correction est souvent petite et sûre.

Si vous avez hérité d'une base générée par des outils comme Lovable, Bolt, v0, Cursor ou Replit, une approche « audit d'abord » est souvent la plus rapide. FixMyMess, par exemple, commence par un audit de code gratuit pour repérer la panne avant de changer quoi que ce soit. La règle est simple : isoler d'abord, modifier ensuite.

Triage rapide : réduire la panne en 10 minutes

Notez ce que vous avez fait juste avant l'échec. Soyez précis : quelle page vous avez chargée, quel bouton vous avez cliqué et ce que vous attendiez. Ensuite copiez le texte d'erreur exact (ou faites une capture). De petits détails comme un nom de route, un code d'état ou un « Cannot read property… » pointent souvent directement vers la zone cassée.

Ensuite, décidez ce qui échoue réellement : la page, l'API, ou les deux.

• Une page blanche, un overlay d'erreur React, ou « Application error » indique souvent un problème frontend.
• Une page qui se charge mais plante à l'envoi d'un formulaire signifie souvent qu'une route backend retourne un 500.

Si vous pouvez ouvrir DevTools, regardez l'onglet Réseau. Une requête en rouge est souvent le point de départ.

Capturez les informations de base pour ne pas chasser le mauvais déploiement : version/commit de l'app, heure du déploiement et quel environnement vous avez testé (production vs staging). Des environnements « presque identiques » diffèrent souvent d'une seule variable d'environnement ou d'une URL de base de données.

Enfin, notez qui est affecté. Essayez les mêmes étapes déconnecté et connecté. Si seuls les utilisateurs authentifiés plantent, la cause est souvent l'auth, les cookies ou un secret manquant en production. Si seuls les nouveaux utilisateurs échouent, il se peut qu'une migration manque ou qu'un champ requis ne soit pas présent.

Cette prise de notes de 10 minutes vous fera gagner des heures, et elle donne à une équipe comme FixMyMess assez de contexte pour reproduire rapidement le crash pendant un audit gratuit.

Trouver les bons logs (build vs runtime vs requête)

La façon la plus rapide d'arrêter les suppositions est de décider quel système vous allez croire en premier. Commencez par l'endroit qui exécute réellement votre code (votre hébergeur ou plateforme serverless), puis élargissez vers votre base de données, le fournisseur d'auth et les API tierces.

Trois types de logs comptent, et ils répondent à des questions différentes.

Logs de build : le déploiement a‑t‑il réussi ?

Les logs de build vous disent si l'app a été compilée et packagée correctement. Cherchez des variables d'environnement manquantes, des installes échouées, des erreurs de type, ou une étape de build qui a été silencieusement sautée.

Si le build a échoué, les logs runtime peuvent être bruyants ou vides parce que l'app n'a jamais démarré.

Logs runtime : le serveur a‑t‑il démarré et reste‑t‑il en vie ?

Les logs runtime montrent ce qui se passe quand votre app boot en production. C'est là que vous verrez des crashs comme « cannot read property of undefined », une mauvaise config, des secrets manquants, ou un processus serveur qui redémarre sans cesse.

Restez concentré : filtrez sur une fenêtre temporelle serrée. Commencez 1–2 minutes avant que vous n'ayez déclenché le crash et terminez 1–2 minutes après. Vous voulez la première erreur, pas la pile d'échecs qui suit.

Logs de requête : quelle requête déclenche le crash ?

Les logs de requête relient une requête HTTP précise à une erreur. Cherchez les codes d'état (500/502/504), le chemin de la route, et tout ID de requête ou trace ID.

Quand vous partagez des détails avec quelqu'un d'autre, limitez‑vous à ce qui est nécessaire et sûr :

• Message d'erreur et trace
• Route (par exemple, POST /api/login)
• ID de requête et horodatage
• Version de déploiement ou de build

Ne collez pas de dumps d'environnement, d'en‑têtes contenant des tokens, de cookies ou de chaînes de connexion à la base. Ces quatre éléments suffisent généralement pour reproduire la panne sans exposer de secrets.

Mapper le crash à une seule route en échec

Un crash après déploiement peut sembler aléatoire parce que vous ne voyez qu'une page blanche, un spinner, ou un message générique « Something went wrong ». Rendez‑le solvable en mappant l'action utilisateur à la requête exacte qui déclenche l'échec.

Commencez par l'action utilisateur : chargement de la page d'accueil, clic sur « Sauvegarder », soumission d'une connexion, ouverture d'un tableau de bord. Cette action déclenche généralement un ou plusieurs appels réseau. Trouvez quel appel échoue en premier. Les échecs ultérieurs sont souvent des effets secondaires.

Si vous le pouvez, reproduisez‑le en regardant l'onglet Réseau. Cherchez la première requête qui retourne un mauvais code de statut (souvent 500, 401, 403 ou 404). Notez le chemin de l'endpoint, l'horodatage et l'ID de requête si votre plateforme l'affiche. Puis faites correspondre cet horodatage à vos logs runtime backend.

Si plusieurs appels arrivent en même temps, gardez l'isolation simple :

• Rechargez et regardez quelle requête échoue en premier
• Relancez directement le même endpoint (même méthode et payload)
• Désactivez temporairement les fonctionnalités UI optionnelles qui déclenchent des appels en plus
• Comparez un chargement de page qui fonctionne à un chargement qui plante

Une fois la route en échec identifiée, confirmez ce que l'app attend. Si l'UI appelle GET /api/me juste après la connexion et que cela renvoie 500, toute l'app peut paraître « en panne » même si un seul endpoint est cassé.

C'est aussi là que le « crash après déploiement » devient un problème concret : un handler ne peut pas lire une variable d'environnement, une requête DB casse sur des données de production, ou un contrôle d'auth rejette de vrais cookies. Corrigez d'abord cette route et le reste récupérera souvent.

Pourquoi la production est différente de votre machine locale

Votre app peut sembler parfaite sur votre laptop et pourtant échouer dès qu'elle atteint la production. Le code généré devine souvent son environnement, et la production est plus impitoyable.

La configuration est la première différence. En local, vous avez peut‑être des valeurs par défaut et des secrets en cache. En production, des valeurs manquantes ou vides sont courantes et peuvent faire planter un serveur au démarrage ou à la première requête. Quelques vérifications évitent beaucoup de pannes :

• Les variables d'environnement requises existent et ne sont pas vides (clés API, URL de base de données, secrets d'auth)
• NODE_ENV et les URLs de base correspondent à ce que l'app attend
• Les URLs de callback d'auth et les options de cookie conviennent au domaine déployé (cookies sécurisés, sameSite)
• CORS autorise l'origine réelle du frontend, pas seulement localhost
• Les timeouts et limites mémoire sont réalistes pour des routes lentes

Les données sont le second piège. Votre base locale contient souvent les migrations appliquées, des données de seed et des tables déjà créées. La production peut être une base fraîche. Une route peut planter parce qu'une colonne manque, qu'un nom de table diffère, ou que des données requises n'ont jamais été insérées.

Les chemins de fichiers se comportent aussi différemment. En local, lire ./data/config.json peut fonctionner parce que le fichier existe sur le disque. Dans beaucoup de déploiements, le système de fichiers est en lecture seule, le répertoire de travail est différent, ou le fichier n'a pas été inclus dans le résultat du build.

Un scénario courant : la connexion fonctionne en local, mais en production une 500 survient juste après le redirect OAuth. La cause est souvent un mismatch entre l'URL de base déployée et l'URL de callback configurée, ou des cookies définis sans secure=true sur HTTPS. Le code n'est atteint qu'en production, donc le bug reste caché jusqu'au déploiement.

Pour une vérification rapide, commencez par vérifier les secrets, les migrations et les paramètres d'auth. Ce sont les différences à fort impact entre local et production.

Workflow pas à pas pour reproduire et isoler le bug

Le chemin le plus rapide est de transformer le « crash aléatoire » en une requête reproductible. Une fois que vous pouvez le déclencher à la demande, la correction devient claire.

Un workflow qui marche presque à tous les coups

1. Reproduisez et écrivez des étapes exactes. Notez l'URL, la méthode (GET/POST), le compte utilisé, et ce que vous avez cliqué ou envoyé. Incluez le résultat attendu et le résultat réel (erreur 500, page blanche, boucle de redirection).

2. Ajoutez des logs minimaux autour de la route suspectée. Journalisez trois moments : début, entrées clés, fin. Gardez‑le petit pour ne pas vous noyer dans la sortie.

3. Exécutez la même requête avec un client simple. Si c'est une page web, rafraîchissez avec DevTools ouvert. Si c'est un appel API, envoyez une requête avec un outil basique pour la répéter exactement.

4. Réduisez les variables jusqu'à ce que ça casse de manière consistante. Utilisez un seul utilisateur, un seul jeu de données, un seul endpoint et une seule config d'environnement. Désactivez les fonctionnalités optionnelles (webhooks, jobs background, retries automatiques) jusqu'à ce que la panne soit facile à déclencher.

5. Confirmez le plus petit changement de code qui arrête le crash. Faites une toute petite modification, redéployez, et relancez la même requête. Si le crash cesse, continuez par petites étapes jusqu'à comprendre pourquoi.

Voici un exemple de « logs minimaux » qui aide sans divulguer de données sensibles :

console.log("/api/login start", { hasEmail: !!email });
console.log("/api/login query start");
// db call
console.log("/api/login end", { ok: true });

Deux règles : ne loggez pas de mots de passe, tokens ou corps de requête complets. Et si vos logs n'affichent jamais « start », la requête n'atteint peut‑être pas la route que vous pensez (mauvais chemin, mauvaise URL de base, middleware qui bloque).

Si vous avez hérité d'une base générée par IA et que vous n'obtenez pas de repro propre, un audit peut malgré tout aider en identifiant la route qui échoue et le plus petit correctif sûr.

Les causes racines les plus courantes dans les apps générées par IA

La plupart des crashs post‑déploiement ne sont pas mystérieux. Ce sont des échecs prévisibles qui apparaissent sous des paramètres d'environnement réels, du HTTPS réel et des données réelles.

Les schémas suivants sont particulièrement fréquents dans les projets générés par IA :

• Mauvaise configuration d'auth : URL de callback toujours en localhost, secret de session manquant, ou cookies avec des flags inadaptés en HTTPS.
• Échecs de connexion à la base : chaîne de connexion erronée, migration non exécutée (table/colonne manquante), ou pool qui se vide sous charge et commence à timeouter.
• Confusion build vs runtime : le déploiement réussit, mais une route spécifique plante parce qu'elle importe quelque chose réservé au serveur, utilise une API Node indisponible, ou suppose qu'un fichier existe.
• Variables d'environnement manquantes et hypothèses de type : une valeur est undefined en production, mais le code la traite comme une chaîne ou un objet (classique : process.env.X.trim() ou JSON.parse(process.env.X)).
• Erreurs asynchrones non gérées : un appel externe échoue (fournisseur d'auth, email, paiements), il n'y a pas de try/catch, et le process jette une rejection non gérée.

Un exemple concret : la connexion fonctionne localement, mais en production le fournisseur d'auth redirige vers une ancienne URL de callback. L'app essaie alors de lire un cookie de session qui n'a jamais été défini, la route jette, et les requêtes vers /dashboard retournent des 500.

Erreurs communes qui font perdre des heures

La façon la plus simple de perdre une journée est de commencer à changer du code avant d'avoir capturé la première erreur. La première erreur est souvent l'indice le plus clair que vous obtiendrez.

Un gros gaspillage de temps est de modifier plusieurs zones à la fois. Si vous touchez au routage, à l'auth et à la base dans le même commit, vous ne saurez pas ce qui a corrigé le crash (ou ce qui a introduit un nouveau bug). Faites un seul petit changement, redéployez et confirmez le comportement.

Un autre piège est de redéployer en boucle sans sauvegarder les détails originaux. Copiez la trace complète, notez le chemin de la requête qui l'a déclenchée et enregistrez l'horodatage. Sinon vous finirez par deviner, et les logs tournent plus vite que vous ne le pensez.

Évitez les raccourcis de sécurité « temporaires ». Désactiver des contrôles d'auth, des règles CORS ou la validation d'entrée peut masquer le vrai bug et créer de nouveaux risques. Si vous relâchez une règle pour confirmer une hypothèse, notez‑le et rétablissez‑la immédiatement après.

Soyez prudent avec le logging. Déverser des corps de requête, tokens, cookies ou mots de passe dans les logs peut créer une fuite et ne pas aider au débogage. Privilégiez un petit ensemble de champs sûrs :

• ID de requête et nom de route
• Code de statut, temps d'exécution, message d'erreur
• Rougez par défaut les données utilisateurs et les secrets

Enfin, ne peaufinez pas l'UI tant que le backend échoue. Un joli toast n'arrangera pas une route qui jette.

Livrer un petit correctif sans réécrire l'app

Le gain le plus rapide est généralement un petit patch sur le chemin exact qui échoue, pas une réécriture. Visez un changement que vous pouvez expliquer en une phrase, puis prouvez qu'il corrige le crash avec la même requête qui échouait.

Commencez par des clauses de garde là où les entrées de production diffèrent : variables d'env manquantes, champs indéfinis, tableaux vides ou utilisateur null. Un bon patch valide tôt et renvoie une 4xx claire, ou fournit une valeur par défaut sûre pour éviter une explosion de code.

Recette simple de petit fix :

• Valider les entrées en bordure de route (query/body/headers) et renvoyer une erreur utile.
• Protéger la configuration manquante (par exemple, si DATABASE_URL est vide, renvoyer un 500 et logger un message clair).
• Attraper les échecs attendus (auth expirée, timeout d'un service tiers) et renvoyer une réponse sûre.
• Conserver une preuve reproductible (une requête unique que vous pouvez relancer à l'identique).
• Ajouter un fallback sûr pour l'utilisateur (une page d'erreur ou un message, pas un écran blanc).

Gardez la preuve ciblée. Si le crash concerne POST /api/login, sauvegardez une charge utile connue‑mauvaise et une connue‑bonne, puis relancez les deux après le redéploiement. Vous n'avez pas besoin d'une grosse suite de tests pour confirmer qu'une route est corrigée.

Après redéploiement, vérifiez avec les mêmes étapes de reproduction. Gardez une option de rollback prête (build précédent ou config) pour revenir rapidement si le patch introduit une nouvelle erreur.

Checklist rapide avant de déclarer la panne corrigée

Un crash qui semble corrigé en local peut encore être cassé après le déploiement. Faites un passage de sanity en production.

Commencez par la reproductibilité :

• Pouvez‑vous reproduire le crash deux fois de suite avec les mêmes étapes (même compte, mêmes entrées, même route) ?
• Après le correctif, les mêmes étapes réussissent‑elles deux fois de suite en production ?

Ensuite, assurez‑vous que vos logs donnent au moins une trace concrète : un chemin de route, un nom de fonction ou un type d'erreur spécifique qui n'apparaît que pendant la requête défaillante.

Puis vérifiez la configuration. Les valeurs manquantes ressemblent souvent à des crashs aléatoires. Comparez ce que l'app attend et ce que la production a réellement, en particulier les variables requises comme les URL de base de données, les secrets d'auth et les clés API.

Enfin, faites un rapide contrôle de sécurité pendant que le contexte est frais. Les apps générées impriment parfois des secrets ou les embarquent côté client par erreur. Confirmez qu'aucun secret n'est exposé dans les logs ou dans le code livré au navigateur.

Si vous continuez à avoir des crashs « surprise », il est souvent moins coûteux de reculer et faire un diagnostic structuré une fois que de continuer à patcher à l'aveugle.

Exemple : un flux de connexion qui plante uniquement en production

Un schéma courant avec les apps générées par IA est : tout semble OK en local, vous déployez, et l'app échoue dès qu'un utilisateur se connecte. La page d'accueil se charge, les boutons répondent, puis la première étape backend réelle (auth) déclenche une erreur.

Voici ce qui se passe généralement. Un utilisateur clique sur « Log in », est redirigé vers le provider, puis retourne sur la route de callback de votre app (souvent /auth/callback). Cette route tente ensuite de créer une session (définir un cookie, écrire un token, ou stocker un enregistrement utilisateur). En production, cette dernière étape échoue. La requête jette, et la plateforme peut redémarrer le process si elle considère le crash comme fatal.

Dans les logs de requête autour du callback, vous verrez souvent des indices comme « Invalid redirect URI », « Missing AUTH_SECRET », « Cookie not set », ou « JWT decode failed ». L'important est de lier la panne à une seule route : le handler de callback.

Les corrections typiques sont petites mais précises :

• Configurer correctement l'URL de callback dans les réglages du provider et dans les variables d'environnement de production.
• Définir les options de cookie adaptées à la production (cookies sécurisés et domaine correct), au lieu de valeurs par défaut locales.
• Ajouter ou faire tourner le secret utilisé pour signer les sessions, et s'assurer qu'il est défini en production, pas seulement dans un .env local.

Pour confirmer la correction, vérifiez trois choses : la connexion se termine et amène l'utilisateur à la bonne page, les logs montrent un flux propre 200/302 à travers la route de callback, et l'app cesse d'entrer en boucle de redémarrage après une tentative de connexion.

Etapes suivantes si les crashs persistent

Si vous avez corrigé un crash de déploiement mais que d'autres continuent d'apparaître, considérez‑le comme un signal. Des échecs répétés signifient généralement que l'app manque quelques basiques : validation d'entrée, frontières claires entre routes et accès aux données, configuration d'env cohérente, et gestion d'erreur sûre.

Cherchez le motif. Si chaque crash est lié à la même zone (auth, écritures DB, uploads de fichiers), vous avez probablement besoin d'une petite refactorisation à ce niveau. Si les crashs sautent sur des routes sans lien, cela pointe souvent vers des problèmes plus profonds comme de l'état global partagé, une config incohérente ou du couplage caché entre modules.

Conservez un court template de rapport de bug pour que chaque nouveau crash prenne des minutes et non des heures :

• Qu'est‑ce qui a changé depuis le dernier déploiement qui marchait (commit, variable d'env, dépendance)
• Étapes exactes pour reproduire (type de compte et exemple d'entrée)
• Route et méthode en échec (par exemple, POST /api/login)
• Logs pertinents (horodatés, avec ID de requête si disponible)
• Différences local vs production (vars d'env, base, version Node/runtime)

Si vous voulez une correction rapide et vérifiée pour une app générée par IA qui plante après le déploiement, FixMyMess (fixmymess.ai) peut diagnostiquer la base de code, réparer la logique qui échoue et renforcer les points faibles qui causent des incidents répétés. Commencer par un audit de code gratuit est souvent le moyen le plus rapide d'identifier la route exacte qui échoue et le décalage spécifique à la production.