Le problème « ça marchait hier » : pourquoi les applications générées par l'IA se cassent

Ce que signifie vraiment le problème « ça marchait hier »

Le problème « ça marchait hier » est frustrant parce qu'il donne l'impression que rien n'a changé. Même appli. Même utilisateur. Même bouton. Et puis, soudain, écran blanc, message d'erreur, ou connexion qui tourne dans le vide.

La plupart du temps, « hier » ne veut pas dire que l'app s'est cassée au hasard. Cela signifie qu'une chose a changé discrètement en arrière‑plan, et votre application en dépendait sans que vous ne le réalisiez. Avec les applications générées par l'IA, ces dépendances invisibles ont tendance à être plus nombreuses parce que le code est produit rapidement, les réglages se retrouvent éparpillés, et l'app peut s'appuyer sur des valeurs par défaut temporaires qui n'étaient pas prévues pour des utilisateurs réels.

Quelques changements invisibles causent cela plus souvent qu'on ne le pense :

• Une session ou une permission a expiré, donc l'app n'a plus accès à ce dont elle a besoin.
• Une clé, un mot de passe ou une variable d'environnement a été tournée, renommée ou supprimée.
• Un fournisseur a modifié une limite, une règle de sécurité ou un paramètre et votre app échoue désormais à une vérification.
• Le code a été régénéré ou recopié, et un correctif fonctionnel a été écrasé.

C'est pourquoi cela arrive si fréquemment dans les prototypes et les premiers lancements. Un prototype est généralement construit pour prouver un flux, pas pour survivre aux conditions réelles comme les expirations, les nouveaux utilisateurs, les quotas ou un redeploy accidentel. Les outils d'IA peuvent générer une démo qui fonctionne rapidement, mais ils sautent souvent les garde‑fous qui rendent les pannes prévisibles et faciles à diagnostiquer.

Un exemple simple : vous faites la démo d'un flux d'inscription le lundi depuis votre navigateur. Le mardi, un nouvel utilisateur l'essaie et se voit bloqué. Rien n'a changé dans l'UI, mais l'app dépendait d'un jeton temporaire stocké dans votre navigateur, ou d'un réglage backend qui ne fonctionnait que pour votre compte.

La bonne nouvelle, c'est que ces pannes sont généralement pratiques, pas mystiques. Si vous traitez « ça marchait hier » comme un indice qu'une chose a changé hors écran, l'investigation a une fin claire, ce n'est pas un jeu de devinettes.

Pourquoi les apps générées par l'IA rencontrent ce problème plus souvent

Le schéma « ça marchait hier » peut se produire dans n'importe quel logiciel, mais il est particulièrement courant dans les apps générées par l'IA parce que l'objectif est souvent une démo rapide, pas la stabilité à long terme. L'app a l'air finie en surface, tandis que le travail de fiabilisation en dessous manque.

Pourquoi la vitesse crée de la fragilité

Les outils d'IA excellent à produire quelque chose qui tourne une fois : un écran de connexion, une table de base de données, un appel d'API, un tableau de bord. Les apps en production ont besoin de garde‑fous autour de ces éléments. Sans eux, des changements normaux peuvent casser des flux essentiels.

Parmi les patterns fréquents : gestion lâche des configs et des secrets, auth qui ne fonctionne que sur le chemin « happy path », tests manquants, trop d'intégrations ajoutées trop vite, et une structure désordonnée où un changement affecte plusieurs écrans de façon inattendue.

Les petits changements font plus de dégâts

Dans une base de code propre, un changement de clé casse généralement un seul endroit et l'erreur vous guide. Dans une base générée à la va‑vite, la même valeur peut être dupliquée dans plusieurs fichiers, ou une fonction utilitaire peut exister en versions légèrement différentes. Le débogage devient aléatoire.

Exemple : un fondateur met à jour une clé API pour passer d'un compte de test à un compte live. L'app se compile toujours, mais un endpoint utilise l'ancienne clé d'un fichier de config oublié. L'auth échoue et les utilisateurs restent bloqués dans une boucle de connexion.

C'est le type de situation pour lequel FixMyMess existe : prendre des prototypes générés par l'IA et ajouter des garde‑fous basiques (environnements clairs, gestion plus sûre des secrets, structure plus maintenable) afin que la démo d'hier ne devienne pas la panne d'aujourd'hui.

Sessions et jetons expirés (auth qui time‑out)

Beaucoup d'échecs « ça marchait hier » ne sont que des sessions de connexion qui ont expiré.

En termes simples, une session ou un jeton est un laissez‑passer temporaire qui prouve que vous vous êtes déjà connecté. Les apps l'utilisent pour éviter de retaper le mot de passe à chaque clic. Le truc, c'est que ces laissez‑passer sont faits pour expirer, parfois après quelques minutes ou quelques heures.

Les prototypes générés par l'IA oublient souvent les aspects ingrats de l'auth : renouveler le jeton, gérer les timeouts, et empêcher les utilisateurs de rester bloqués. Tout semble correct juste après la connexion, puis casse plus tard.

Les déclencheurs typiques incluent des jetons qui expirent sans flux de refresh, un refresh implémenté mais non branché dans l'UI, des décalages d'horloge serveur/client, ou des jetons stockés au mauvais endroit (l'app vous « oublie » au rafraîchissement).

Signes observables sans lire le code : déconnexions aléatoires, même action qui marche juste après la connexion mais échoue ensuite, ou affichage d'erreurs « Unauthorized ». Dans les logs, vous verrez peut‑être des 401 ou 403, qui signifient souvent « vous n'êtes pas autorisé » ou « votre laissez‑passer n'est plus valide ».

Questions rapides qui resserrent le diagnostic :

• Échoue‑t‑il seulement après un certain temps ?
• Rafraîchir la page aggrave‑t‑il le problème ?
• Se déconnecter puis se reconnecter corrige‑t‑il temporairement ?

Exemple : un utilisateur de démo se connecte, teste le checkout, et ça marche. Deux heures plus tard, de vrais utilisateurs cliquent sur « Enregistrer » et sont renvoyés à l'écran de connexion. Ce pattern suggère fortement une expiration de jeton.

Les équipes comme FixMyMess règlent ça en fiabilisant le refresh des jetons, en gérant les timeouts avec souplesse, et en vérifiant le comportement avec des temps d'attente réels, pas seulement un test rapide du happy path.

Clés API, variables d'environnement et paramètres fournisseur modifiés

Une autre cause fréquente n'est pas un bug dans votre code, mais une connexion cassée vers quelque chose dont votre app dépend : e‑mail, paiements, cartes, stockage ou login.

Les apps parlent à ces services avec des secrets : clés API, client IDs, webhooks et URLs de callback. Ces valeurs peuvent vivre dans des variables d'environnement sur votre hôte, un tableau de bord fournisseur (Stripe, SendGrid, Google, etc.), un fichier de config dans le repo, ou un gestionnaire de secrets. Quand l'une d'entre elles change, tout peut sembler correct en local mais échouer en production.

Que peut‑il changer du jour au lendemain ? Les fournisseurs tournent des clés, révoquent des clés après activité suspecte, ou désactivent une clé exposée dans un dépôt public. Les essais se terminent. Les limites d'utilisation sont atteintes. Quelqu'un modifie des paramètres sur un dashboard et l'oublie. Même de petits changements comme modifier une URL de redirect ou basculer un mode peuvent bloquer des utilisateurs réels.

Les symptômes sont déroutants parce que l'app charge toujours, mais des fonctionnalités précises cessent de fonctionner : paiements qui échouent, cartes qui ne s'affichent pas, e‑mails qui ne partent pas, uploads renvoyant des 403, ou boucles de login.

Vérifications rapides qui font souvent gagner du temps :

• Confirmez que vous êtes dans le bon environnement (prod vs dev) et que les bonnes clés y sont définies.
• Cherchez des changements récents chez le fournisseur : clés révoquées, essais expirés, quotas dépassés.
• Regardez les logs de déploiement pour variables manquantes, erreurs de permission, ou messages « invalid API key ».
• Vérifiez que les URLs de webhook et de redirect/callback correspondent à votre domaine actuel.
• Assurez‑vous que personne n'a hardcodé une clé dans un fichier qui est écrasé lors du deploy.

Si vous avez hérité d'une app générée par l'IA, il est courant de trouver des placeholders, des clés dupliquées entre environnements, ou des secrets hardcodés au mauvais endroit. FixMyMess commence souvent par un audit rapide pour localiser chaque secret et confirmer quel paramètre fournisseur casse la production.

Dépendances et mises à jour de plateforme qui cassent la build

Parfois, rien dans votre repo n'a changé, et l'app casse quand même. C'est parce que le code n'est pas la seule pièce mobile. Votre app dépend de packages, de runtimes, de réglages d'hébergement et de services tiers qui peuvent évoluer sans que vous le remarquiez.

Les projets générés par l'IA sont particulièrement vulnérables parce qu'ils épinglent mal les versions (ou pas du tout). Vous pouvez trouver un package.json sans lockfile, des plages vagues comme ^1.2.0, ou des instructions qui tirent « latest » à chaque fois. La prochaine installation ou déploiement récupère une dépendance légèrement plus récente qui se comporte différemment, et voilà qu'une fonctionnalité qui marchait échoue.

Les plateformes changent aussi. Un hébergeur peut augmenter la version Node par défaut, une base managée peut upgrader son moteur, un provider serverless peut resserrer les limites de requêtes, ou une mise à jour de navigateur peut révéler un cas limite CSS/JS. Ce n'est pas un changement « fait par vous », mais c'est un changement que votre app doit supporter.

Signaux qui pointent vers des dépendances ou des mises à jour de plateforme :

• Nouveaux warnings ou erreurs de build qui n'existaient pas avant
• Déploiements qui échouent soudainement chez le fournisseur d'hébergement
• Une fonctionnalité marche en local mais échoue en production après une installation neuve
• L'UI a un rendu légèrement différent sans modification de design
• Des erreurs mentionnent un nom de package, une version Node/Python, ou un driver de base de données

Scénario : votre démo fonctionnait vendredi. Lundi, un déploiement frais récupère une nouvelle version d'une librairie de dates et un formulaire de checkout commence à rejeter des dates valides. Personne n'a touché le code, mais le comportement a changé.

Pour réduire les pannes récurrentes, misez sur des builds reproductibles : commitez les lockfiles, évitez les plages de versions vagues, épinglez les versions de runtime (Node, Python) dans les paramètres du projet, et lisez les logs de déploiement avant de vous fier à ce que l'UI affiche.

Si vous héritez d'une base IA avec des builds instables, FixMyMess peut l'auditer et identifier quelle dépendance ou quel changement de plateforme cause réellement la casse avant que vous ne gaspilliez des heures à deviner.

Régénération du code écrasant vos correctifs

Une cause sournoise est la régénération du code. Beaucoup d'apps construites par l'IA ne sont pas traitées comme des bases de code normales. Elles sont vues comme un output qui peut être recréé à tout moment. Pratique… jusqu'à ce que ça efface discrètement les changements qui faisaient fonctionner l'app.

La régénération peut arriver quand quelqu'un re‑rompt l'outil, clique sur un bouton d'auto‑fix, resynchronise un projet, ou demande un rebuild propre après une petite erreur. Certains outils réécrivent aussi des fichiers quand vous changez un paramètre de haut niveau ou ajoutez une fonctionnalité.

Les correctifs disparaissent parce que la modification a été faite dans un endroit que le générateur « possède ». Par exemple, vous corrigez un bug directement dans un fichier de composant, puis la prochaine exécution remplace ce fichier par un template. Sans règle claire « ce fichier est sûr à éditer », vous ne possédez pas vraiment le code que vous avez touché.

Les symptômes ressemblent à :

• Le même bug revient après un petit changement
• Un fichier que vous avez édité apparaît comme plus récent, mais vos lignes ont disparu
• Les choses échouent d'une façon qui donne l'impression de voyager dans le temps : « Pourquoi c'est revenu ? »
• L'historique Git (si vous l'avez) montre de grosses réécritures plutôt que de petits commits

Exemple : vous corrigez une redirection de login en changeant deux lignes. Le lendemain, vous demandez à l'IA d'ajouter une page de paramètres. Elle régénère le fichier de routage et votre correctif de redirection disparaît.

Pour éviter ça, protégez les correctifs : marquez les fichiers clés comme détenus par des humains, gardez une note de ce qui a changé et pourquoi, centralisez la logique critique quand c'est possible, et utilisez le contrôle de version pour comparer et restaurer.

Les équipes comme FixMyMess voient souvent ce pattern dans des projets construits avec Lovable, Bolt, v0, Cursor ou Replit. Une bonne première étape est d'identifier quels fichiers sont réécrits et de déplacer la logique critique hors de la zone à risque.

Étape par étape : comment réduire ce qui a changé

Quand vous tombez sur « ça marchait hier », ne devinez pas. Trouvez le plus petit changement qui explique la panne.

Commencez par une courte timeline depuis la dernière fois où ça fonctionnait. Incluez tout ce qui semble mineur : un déploiement, un réglage dans le dashboard d'un fournisseur d'auth, quelqu'un qui a nettoyé des vars d'env, ou un outil d'IA qui a régénéré une partie de l'app.

Ensuite, confirmez où vous testez. Beaucoup d'apps créées par l'IA se comportent différemment en dev, staging et production parce qu'elles utilisent des clés, des bases de données ou des URLs de callback différentes. Ne comparez pas « local ok » avec « prod cassé » sans vérifier.

Un flux simple :

• Verrouillez votre test : même compte, même appareil/navigateur, mêmes étapes à chaque fois.
• Capturez la première erreur que vous voyez. Notez l'heure et l'endroit (message écran, logs serveur, console navigateur).
• Choisissez une zone suspecte : auth/session, clés API et vars d'env, base de données, ou un changement récent de build/deploy.
• Faites un seul changement contrôlé : annulez ou rollback une modification récente (ou testez le déploiement précédent) et retestez.
• Notez ce qui s'est passé après chaque test pour ne pas retomber dans les mêmes suppositions.

Exemple : les utilisateurs ne peuvent plus se connecter. Si ça a commencé juste après un déploiement, suspectez les URLs de callback d'auth ou les variables d'environnement. Si ça a commencé après « une nuit », suspectez l'expiration des jetons ou les réglages de session. Si ça a commencé juste après avoir régénéré du code, suspectez un correctif écrasé.

Si vous avez hérité d'un prototype généré par l'IA et que la panne semble aléatoire, FixMyMess commence souvent par un diagnostic rapide qui range la panne dans une de ces catégories, puis vérifie le correctif avec des tests répétables.

Pièges courants qui font perdre des heures

La façon la plus rapide de perdre une journée est de chasser ce que vous voyez (un bouton cassé, une page blanche) au lieu de ce qui a changé en coulisses. Les apps générées par l'IA échouent souvent pour des raisons que l'UI ne peut pas expliquer : sessions expirées, valeur de config manquante, ou l'app qui parle au mauvais service.

Un piège fréquent est de déboguer le mauvais environnement. Vous corrigez en local et tout semble ok, mais la production est toujours cassée parce que l'app déployée a d'autres variables d'environnement, d'autres secrets ou une autre base de données. Si le problème n'arrive que pour des utilisateurs réels, considérez la production comme le lieu du bug jusqu'à preuve du contraire.

Autre perte de temps : n'envoyer que des captures d'écran. Une capture masque le texte exact de l'erreur, l'horodatage et la requête qui a déclenché le problème. Copiez le message d'erreur, notez quand il est arrivé, et sauvegardez la ligne complète du log si possible. Une ligne suffit souvent pour pointer vers un jeton expiré, une clé API manquante ou un changement de permissions.

Erreurs qui provoquent le plus de thrash :

• Corriger la page visible alors que la vraie cause est l'auth, les permissions ou la config
• Éditer les réglages dev alors que la panne est uniquement en staging ou production
• Coller des erreurs partielles (ou des screenshots) au lieu du message complet et de l'heure
• Changer plusieurs paramètres d'un coup, puis ne plus savoir lequel était important
• Cliquer sur régénérer pour remettre à zéro, puis écraser le correctif qui marchait hier

Exemple : vous mettez à jour un prompt pour nettoyer le flux de login, régénérez le code, et l'app recompile. Mais la régénération a remplacé votre logique de refresh de session, donc les utilisateurs commencent à être déconnectés après quelques minutes.

Si ce pattern revient, un simple journal des changements et un audit rapide de l'auth, des secrets et des déploiements peut vous sauver. Les équipes viennent à FixMyMess quand elles ont besoin de quelqu'un pour tracer le vrai changement et s'assurer que le correctif survive à la régénération suivante.

Checklist rapide avant de paniquer

L'objectif n'est pas de deviner la cause. C'est de savoir si la panne est liée à un utilisateur, une session navigateur, un déploiement ou un service tiers.

Faites ces tests rapides en premier :

• Essayez la même action en fenêtre privée/incognito. Si ça marche, vous traitez probablement une session expirée, un cookie bloqué ou du code front mis en cache.
• Demandez‑vous si une clé API, un mot de passe ou un secret a changé dans les dernières 24–72 heures (paiements, e‑mail, apps OAuth, mots de passe de DB).
• Souvenez‑vous : avez‑vous redeployé, modifié des réglages d'hébergement, ou mis à jour un package ? De petites configs peuvent casser la production.
• Vérifiez les logs autour du moment exact où ça a cassé. Cherchez le premier horodatage d'erreur et des messages comme « invalid token », « unauthorized », « missing env » ou « cannot connect ».
• Confirmez qui est affecté. Tout le monde, ou seulement certains comptes/rôles/nouveaux inscrits ? Cela oriente vers des permissions, des checks de rôle ou des différences de données.

Exemple : le fondateur peut toujours se connecter, mais les nouveaux utilisateurs ne le peuvent pas. Cela signifie souvent que le flux d'inscription échoue (clé du fournisseur d'e‑mail changée, quotas atteints, ou bug d'assignation de rôle), pas que toute l'app est cassée.

Si vous pouvez répondre à ces cinq vérifications en 10 minutes, vous coupez généralement des heures de devinettes. Si vous héritez d'un code généré par l'IA et que les signaux sont confus, FixMyMess peut lancer un audit gratuit et vous dire ce qui a changé et quoi réparer en priorité.

Un scénario simple : la démo a marché, puis les utilisateurs ont été bloqués

Un fondateur fait la démo d'une nouvelle app construite par l'IA à un investisseur le mardi. Le login marche, le dashboard charge, et le test paiement passe. Le mercredi matin, de vrais utilisateurs commencent à s'inscrire et toutes les tentatives de connexion échouent. Le fondateur n'a touché à aucun code, donc tout semble aléatoire.

Une cause probable est la gestion des tokens et des sessions. Beaucoup de prototypes utilisent des jetons à courte durée de vie ou un setup d'auth réservé au développement qui paraît correct pendant une démo rapide. Dans la nuit, la durée des jetons arrive à terme, le flux de refresh manque, ou l'app ne peut pas renouveler la session. Les utilisateurs sont renvoyés à la page de connexion ou voient une erreur générique « unauthorized ».

Une autre cause fréquente est une clé API tournée. Une clé fournisseur de paiement, d'e‑mail ou d'auth peut être changée, désactivée ou remplacée. L'app continue d'utiliser l'ancienne clé stockée dans une variable d'environnement, donc les requêtes échouent.

Une façon rapide de trancher :

• Retestez la connexion en fenêtre incognito pour éliminer les sessions mises en cache.
• Cherchez dans les logs « expired token » vs « invalid API key ».
• Vérifiez les valeurs de clé actuelles dans l'environnement de déploiement.
• Confirmez les paramètres du fournisseur (domaines autorisés, URLs de callback, quotas).
• Après un correctif, refaites le même flux deux fois : maintenant et de nouveau demain.

Pour éviter la surprise suivante : verrouillez l'emplacement des secrets (pas de hardcoding), ajoutez une surveillance basique pour les échecs d'auth et de clés, et évitez de régénérer du code par‑dessus des correctifs en production. Si la base est générée par l'IA et difficile à démêler, un audit ciblé de FixMyMess peut déterminer si c'est la gestion des tokens, les secrets, ou une régénération qui a écrasé le correctif.

Étapes suivantes pour faire cesser ça

Pour réduire le pattern « ça marchait hier », traitez votre app créée par l'IA comme un vrai produit, pas comme une démo ponctuelle. La plupart des pannes « mystérieuses » sont de petits changements sans trace, sans contrôles et sans alertes.

Stabiliser ce qui change le plus

Commencez par figer les parties mobiles. Si votre app dépend de librairies, de defaults d'hébergement ou de réglages fournisseur, de petites mises à jour peuvent changer le comportement discrètement.

• Épinglez les versions de dépendances pour que les installations soient reproductibles.
• Verrouillez les variables d'environnement et les secrets (qui peut les changer, et où ils résident).
• Ajoutez une surveillance basique : un check d'uptime plus des alertes pour les erreurs de login et les appels API échoués.
• Gardez les releases ennuyeuses : une seule méthode de deploy, un seul endroit pour consulter les logs.
• Rendez la régénération optionnelle : ne laissez pas un outil réécrire des fichiers sans revue.

Si un réglage peut casser les paiements, le login ou les données critiques, il ne devrait pas être modifiable sur un coup de tête.

Rendre les changements visibles et tester les chemins risqués

Tenez un journal léger des changements : modifications de prompt, rotations de clés, horaires de deploy, et mises à jour fournisseur. Quand quelque chose casse, vous pouvez comparer « dernier état fonctionnel » et « première erreur » en quelques minutes.

Ajoutez quelques tests garde‑fous pour les flux qui cassent souvent : login, inscription, réinitialisation de mot de passe, et tout ce qui dépend d'une clé API. Même des vérifications simples avant un déploiement peuvent attraper des vars manquantes, des redirects cassés et des échecs d'auth évidents.

Si les pannes reviennent, ou si vous voyez des risques de sécurité comme des secrets exposés ou des risques d'injection SQL, faites intervenir quelqu'un pour démêler et durcir la base. FixMyMess (fixmymess.ai) propose un audit de code gratuit pour identifier les vraies causes, puis répare et prépare les apps générées par l'IA pour la production avec une vérification humaine afin que les correctifs ne disparaissent pas au prochain déploiement.