Récupérer après qu'une modification a corrompu une version fonctionnelle
Restaurer le dernier comportement fonctionnel, conserver les récents travaux utiles et les données clients, puis réappliquer uniquement la modification souhaitée.
Quand l'utiliser
Lorsque l'application fonctionnait, que vous avez demandé une modification, et qu'une page ou un flux important est désormais corrompu, alors même que vous souhaitez conserver les parties utiles du travail récent.
Avant de commencer
- Arrêtez d'envoyer d'autres invites de réparation jusqu'à ce que vous ayez identifié la dernière version qui fonctionnait correctement.
- La modification récente ayant déclenché le problème, copiée aussi précisément que possible.
- La date, l'heure ou la description de la dernière version connue comme fonctionnelle.
- Une courte liste de ce qui fonctionne encore, de ce qui est cassé et du nouveau travail utile que vous souhaitez conserver.
- Des comptes de test et des enregistrements de test sécurisés pour le flux affecté.
- Une exportation ou une trace écrite de toute information client réelle ajoutée depuis la dernière version fonctionnelle. Ne faites jamais d'expérimentations sur la copie unique.
Le prompt
Ces prompts fonctionnent mieux en anglais — collez-les tels quels, même sur les pages traduites.
Recover this app after [RECENT CHANGE OR PROMPT] broke [EXACT BROKEN BEHAVIOR]. Restore the working behavior without discarding [GOOD NEW WORK TO KEEP] or losing customer information added since [LAST KNOWN WORKING VERSION OR TIME]. Do not make another broad change yet. Compare the current version with the last known working version available in this platform's history. List what changed in the affected page, shared elements, login, stored information and external connections. Separate evidence you can see from guesses. Create a recovery plan with three outcomes. Restore [PREVIOUSLY WORKING FLOW]. Preserve [GOOD NEW CONTENT OR FEATURE]. Reapply only [THE INTENDED PART OF THE RECENT CHANGE] after the app is stable. Tell me which outcome can be completed safely and which needs my decision. Treat the app's pages and behavior separately from live customer information. Restoring an earlier visual or app version must not silently erase, replace or expose accounts, bookings, orders, messages, uploads or payments created afterwards. If the platform's restore action may affect stored information, connection settings or permissions, stop and explain the risk before using it. Use the platform's actual version-history, revert or deployment-rollback control when a restore is needed. Do not pretend that writing the word revert in chat has undone the change. Preview the last working version first where the platform allows it. Restore a safe working version or repair the smallest confirmed cause. Then test [BROKEN FLOW] with safe data, plus sign-in, the main navigation, [IMPORTANT FORM OR PAYMENT], the phone layout and one nearby feature that was not broken. Confirm that information added after the last working version is still present. Only after those checks pass, reapply [INTENDED CHANGE] as a narrow change that does not touch [AREAS TO PROTECT]. Test the old working flow and the new change together. If they conflict, keep the stable version and show me the decision instead of forcing both. Do not delete stored information, reset the app, replace the login system, change payment keys or remove access rules. Keep the repair surgical and the explanation calm. Finish with what was restored, what was preserved, what was reapplied and what I should test on the published site.
Vous construisez déjà ? Collez ceci dans votre projet. Vous partez de zéro ? Ouvrez un compte gratuit sur un outil compatible ci-dessous.
Créez-le sur
Ce que cela crée
- Une comparaison entre la version corrompue et la dernière version fonctionnelle
- Un plan de récupération qui sépare la restauration, la préservation et la réapplication
- Un retour en arrière sécurisé ou une réparation ciblée
- Des contrôles pour le flux réparé, les fonctionnalités à proximité et les informations clients récentes
- Une réapplication contrôlée de la seule modification prévue
- Un journal de récupération en langage simple pour les problèmes futurs
Vérifiez que ça a marché
Collez le prompt, attendez la fin de la construction, puis vérifiez ceci — en langage simple, sans contrôle technique :
- L'action qui fonctionnait avant la modification fonctionne à nouveau avec des données de test sécurisées
- Le nouveau texte ou la nouvelle fonctionnalité utile que vous avez nommés sont toujours présents, ou sont clairement sauvegardés pour une réapplication
- Les comptes clients, réservations, commandes, messages et téléchargements ajoutés après la version fonctionnelle sont toujours là
- La connexion, la navigation et les fonctionnalités à proximité testées fonctionnent toujours
- La nouvelle modification ciblée fonctionne sans casser le flux restauré
- Le site publié montre la version fonctionnelle approuvée, et pas seulement l'aperçu de l'éditeur
- Vous recevez un compte rendu clair de ce qui a été restauré et de tout ce qui a été délibérément laissé inchangé
Il manque quelque chose ? C'est normal — demandez-le dans un court message de suivi plutôt que de relancer tout le prompt.
Étapes suivantes
Réappliquer le changement utile en toute sécurité
Après que l'ancien comportement fonctionnel soit restauré et vérifié
Reapply only this part of the change: [EXACT DESIRED RESULT]. Protect [WORKING FLOW, DATA AND PAGES] from modification. Show me the smallest planned change first, then implement it and retest both the restored behavior and the new result.
Vous saurez que ça a marché quand : L'amélioration prévue est présente tandis que le flux récupéré réussit toujours le même test.
Ajouter une vérification pour le comportement défectueux
Une fois que la récupération est stable
Add a repeatable safe test for this rule: [WHAT MUST NEVER BREAK AGAIN]. Use test data only. Run it after the current version and explain in plain language how I can ask for the same check after future changes.
Vous saurez que ça a marché quand : Le test réussit maintenant et donne un échec clair si la même cassure se reproduit.
Enregistrer la récupération pour la prochaine fois
Après la confirmation que le site est opérationnel
Create a short recovery note containing [CHANGE THAT CAUSED THE BREAK], [VISIBLE SYMPTOM], [CONFIRMED CAUSE], [VERSION RESTORED OR FIX APPLIED], [DATA CHECKED] and [FINAL TESTS]. Keep it private to the owner and do not include passwords, payment details or connection keys.
Vous saurez que ça a marché quand : Le propriétaire dispose d'un enregistrement privé et lisible qui permet de diagnostiquer plus rapidement un problème récurrent.
Attention à
- Plus d'invites de réparation peuvent enterrer le dernier état sain. Arrêtez-vous après la première régression claire et inspectez l'historique avant de demander une autre correction large.
- Une demande dans le chat d'annuler une modification peut ne pas effectuer un retour en arrière réel. Utilisez les commandes visibles de la plateforme (Annuler, Historique des versions ou déploiement) et confirmez quelle version est active.
- La restauration des pages peut ne pas restaurer les informations stockées de la même manière. Le code, la mise en page, les données et les paramètres externes peuvent avoir des historiques distincts. Ne supposez jamais qu'un retour en arrière visuel annule en toute sécurité un changement de données.
- Un retour en arrière en direct peut restaurer les visiteurs rapidement sans réparer le brouillon. Confirmez à la fois ce que le public voit et quelle version vous continuerez à modifier.
- Le travail récent réussi nécessite un inventaire. Notez le texte, les fonctionnalités et les enregistrements à préserver avant de revenir à une version plus ancienne.
- La modification d'origine peut réellement entrer en conflit avec l'ancien comportement. Si les deux ne peuvent pas coexister en toute sécurité, conservez la version stable et rendez le compromis explicite.
Notes par plateforme
<ul><li><strong>Base44 :</strong> Utilisez la commande d'annulation réelle (Revert) ou l'historique des versions. Base44 permet de prévisualiser une ancienne version, de la restaurer dans l'éditeur, ou de publier une ancienne version tout en conservant le brouillon actuel, ce qui est utile pour restaurer l'application en ligne avant de réparer le brouillon.</li><li><strong>Lovable :</strong> Lovable vous permet de prévisualiser et de revenir aux versions précédentes du projet. Un retour à une version précédente peut ne pas annuler tous les changements de données stockées ; inspectez donc les données et les autorisations séparément avant de supposer que toute l'application est revenue à son état antérieur.</li><li><strong>v0 :</strong> Un projet v0 déployé sur Vercel peut ramener la production à un déploiement précédent. Cela restaure ce que voient les visiteurs, mais la source du projet et toutes les données connectées doivent encore faire l'objet d'un examen distinct via l'historique du projet ou la sauvegarde GitHub connectée.</li></ul>
Dépensez moins de crédits
Chaque plateforme vous facture le travail que fait son IA — la habitude la moins chère est donc de réfléchir avant de construire. Ces six règles éliminent l'essentiel du gaspillage, quelle que soit la plateforme.
- Planifiez d'abord dans un chat gratuit. Esquissez le tout dans ChatGPT, Claude ou Gemini — pages, fonctionnalités, ce que chaque formulaire collecte, l'apparence voulue. Réfléchir là-bas est gratuit ; réfléchir dans un builder est facturé.
- Partez d'un prompt écrit, pas d'une phrase. « Fais-moi un site » est la phrase la plus chère de la construction avec l'IA. Un premier prompt complet — comme ceux de ce site — évite des dizaines de corrections.
- Ne soyez pas paresseux sur les détails. Chaque détail omis revient en correction payante. Nom de l'entreprise, couleurs, chaque page, chaque champ de formulaire, ce qui se passe après l'envoi — mettez tout dans le premier prompt.
- Ensuite, un changement par message. « Corrige l'en-tête, et le formulaire, et les couleurs » crée un enchevêtrement plus coûteux à démêler que ce qu'il a économisé.
- Bloqué ? Arrêtez de rustiner. Si la même correction échoue environ trois fois, n'en envoyez pas une quatrième — décrivez plutôt l'état final souhaité de toute la section dans un nouveau message.
- Commencez gratuitement. Passez au payant quand il vous en faut plus. Utilisez le quota gratuit pour créer et explorer votre première version. Passez au payant quand vous avez besoin de plus d’utilisation ou de fonctionnalités payantes, et vérifiez le coût des services connectés avant le lancement.
Les prompts de cette page sont écrits pour faire l'essentiel de ce travail à votre place — c'est tout leur intérêt.
Lire le guide completPlaybooks associés
Dernière vérification: 2026-07-27