L’IA a cassé mon site, comment revenir en arrière

Le réflexe qui aggrave tout

Le site marchait. Tu as demandé une petite modification. Plus rien ne s’affiche.

Le réflexe naturel est de dire à l’IA « ça ne marche plus, répare ». C’est le pire enchaînement possible, pour une raison simple : elle ne se souvient pas de l’état d’avant. Elle va donc reconstruire, de mémoire, quelque chose qui ressemble à ce que tu avais. Tu te retrouves avec une troisième version, ni l’originale ni la cassée, et le problème devient introuvable.

Ne répare pas. Reviens en arrière.

Dans l’ordre

1. Arrête de modifier. Chaque changement supplémentaire éloigne de l’état qui fonctionnait. Ferme, respire.

2. Reviens à la dernière version qui marchait. Si ton projet est suivi par un outil de versions, c’est une seule commande et c’est instantané. Tu récupères exactement ce que tu avais, à la virgule près.

3. Regarde ce qui avait changé. Une fois revenu en lieu sûr, tu peux comparer les deux versions tranquillement et voir les lignes exactes qui ont cassé.

4. Redemande la modification, autrement. Cette fois, demande le plan avant l’exécution.

Les trois pannes, et pourquoi il faut les distinguer

« Cassé » recouvre trois situations très différentes, et confondre les trois est ce qui fait perdre l’après-midi.

La page est blanche. Le plus spectaculaire, et souvent le moins grave : une seule erreur suffit à tout arrêter net. Le reste du site est intact, il ne s’affiche simplement pas.

La page s’affiche, mais quelque chose ne répond plus. Un bouton inerte, un formulaire qui n’envoie rien, une image absente. Là, la casse est locale et elle se cherche à l’endroit exact de la dernière modification.

Tout marche chez toi et rien ne marche en ligne. Le cas le plus déroutant, parce qu’il n’y a rien à réparer dans ton code. La différence est ailleurs : un fichier oublié à l’envoi, une adresse valable seulement sur ta machine, une clé absente du serveur.

Dans les trois cas, le retour en arrière reste le bon premier geste. Mais savoir dans lequel tu es t’évite de chercher pendant deux heures dans le mauvais fichier.

La sauvegarde qui n’en est pas une

Beaucoup pensent être couverts et ne le sont pas, pour deux raisons qui reviennent tout le temps.

« Mon hébergeur fait des sauvegardes. » Peut-être, et elles servent surtout à le protéger lui. Elles sont souvent quotidiennes, parfois payantes à la restauration, et elles remontent l’état complet du serveur — pas la version de ton fichier d’avant-hier. Une sauvegarde que tu ne sais pas restaurer toi-même, en pratique, n’existe pas.

« J’ai une copie du dossier. » C’est déjà mieux que rien, et ça reste un point unique dans le temps. Tu peux revenir à la copie ; tu ne peux pas savoir ce qui a changé entre-temps, ni revenir à un état intermédiaire. C’est la différence entre une photo et un film.

Le test qui tranche est simple, et il se fait un jour où rien ne brûle : essaie de restaurer. Si tu n’y arrives pas en dix minutes sans aide, tu n’as pas de sauvegarde, tu as une intention.

Si tu n’as rien de tout ça

Si ton projet n’est suivi par aucun outil de versions, il n’y a pas de solution élégante. Ta sauvegarde la plus récente est ta seule issue, et si elle date d’il y a trois semaines, tu perds trois semaines.

C’est la situation dans laquelle personne ne veut se trouver, et c’est celle où se trouvent la plupart des gens qui débutent.

Mets en place un suivi de versions avant de reprendre le travail. Pas après, pas la semaine prochaine. C’est trente minutes une fois, et ça transforme chaque catastrophe future en une commande.

Comment rendre ce problème impossible

Presque tous les accidents de ce type viennent d’une modification que tu n’avais pas demandée : un nettoyage spontané, une amélioration au passage, un fichier voisin retouché « tant qu’on y est ».

Une consigne écrite dans ton fichier d’instructions ferme cette porte, à condition d’être formulée comme un ordre vérifiable et non comme un souhait. C’est toute la différence entre une consigne suivie et une consigne ignorée : « sois prudent » ne veut rien dire pour une machine, « attends mon accord avant de modifier un deuxième fichier » se vérifie d’un coup d’œil.

La plus efficace de toutes est celle qui impose de montrer le plan avant d’agir. Un plan de cinq lignes te laisse voir venir la modification surprise avant qu’elle soit appliquée — c’est-à-dire au seul moment où elle ne coûte rien.

Ce qui reste vrai

Une consigne écrite peut être ignorée. Rarement, mais ça arrive.

C’est pour ça qu’un suivi de versions n’est pas optionnel. La consigne réduit la fréquence des accidents. La sauvegarde décide de ce qui se passe le jour où l’accident arrive quand même.