Pourquoi modifier quelque chose qui fonctionne déjà semble-t-il risqué ? Parce que la plupart des outils vous font modifier sur place — vous écrasez l'ancienne version, et si le changement casse quelque chose, il n'y a aucune version vers laquelle revenir. Cette crainte est tout à fait rationnelle quand il n'existe pas d'annulation. Ici, il n'y a donc pas de « sur place ». Chaque modification produit quelque chose de nouveau à côté de ce qui existait déjà.
Que se passe-t-il réellement quand je demande un changement ?
Vous indiquez au chat de build ce que vous voulez — une retouche de texte, une nouvelle section, une fonctionnalité entière — et la plateforme produit une nouvelle version à côté de l'ancienne. Pas à sa place. Les deux restent prévisualisables, les deux restent téléchargeables, et l'ancienne n'est pas reléguée dans une archive qu'il faudrait aller chercher. C'est un produit fonctionnel, à un clic de redevenir la version en ligne. Une fois qu'annuler un changement coûte aussi peu, vous arrêtez de traiter chaque modification comme un pari.
Relancer une vérification complète à chaque version ne ralentit-il pas les choses ?
C'est exactement le problème inverse que la vérification résout. Le mode d'échec habituel avec l'édition itérative par IA n'est pas le changement lui-même — c'est ce que ce changement casse discrètement ailleurs. Corrigez la page tarifs, et le lien de navigation vers celle-ci renvoie silencieusement une erreur 404. La version 9 subit donc exactement la même chaîne que la version 1 : revue de code, sécurité, vérification des liens, accessibilité, conformité. Si un changement casse quelque chose, il est détecté dès le cycle qui l'a introduit. Pas trois semaines plus tard quand un utilisateur vous envoie un e-mail au sujet d'un bouton cassé. (Détails complets dans Comment les builds se vérifient eux-mêmes.)
Que se passe-t-il quand je déploie sur mon propre serveur ?
Les déploiements par SFTP vers votre propre hébergeur bénéficient du même traitement, juste un cran plus bas. Avant que quoi que ce soit ne soit écrit, la plateforme capture votre répertoire web actuel. Chaque version déployée après cela reste sur l'hébergeur et reste restaurable. Donc si un déploiement semble parfait en aperçu puis qu'un élément de votre pile de production — un en-tête de cache, une règle CDN étrange, peu importe — le fait paraître incorrect une fois en ligne, vous revenez en arrière en un clic au lieu de redéployer un ancien export en espérant avoir pris le bon.
Et le sous-domaine gratuit ?
Même principe, en plus léger : publier là-bas conserve aussi chaque version publiée, et republier une version antérieure est tout aussi simple que d'en publier une nouvelle.
| Où | Ce qui est conservé | Annulation |
|---|---|---|
| Dans le builder | Chaque version, prévisualisable et téléchargeable | Restaurer n'importe quelle version |
| Votre sous-domaine | La version publiée, remplaçable à tout moment | Republier une version antérieure |
| Votre propre serveur | Capture avant déploiement + chaque version déployée | Retour en arrière en un clic sur l'hébergeur |
N'est-ce finalement qu'un système de sauvegarde sophistiqué ?
Non — un système de sauvegarde vous protège d'un désastre. Ici, l'objectif est de changer votre comportement au quotidien. Quand le coût d'une supposition erronée tombe au niveau d'un clic, « essayons simplement » cesse d'être une suggestion risquée et devient la réponse par défaut à presque toutes les idées.
