Comment un changement arrive sur votre site en ligne
Huit étapes, une frontière de validation et une cible de retour arrière qui survit au changement. Cette page décrit la mécanique ; elle ne promet aucun résultat de recherche.
D’une demande en langage clair à un verdict consigné
La même séquence s’applique à une réécriture de titre, à une redirection et à la reconstruction d’une page. Aucune étape ne se saute, et l’ordre est la propriété de sûreté.
- 01
Demande
Un constat de l’audit ou du rapport hebdomadaire devient un changement en langage clair : ce qui change, pourquoi, et la preuve derrière.
- 02
Bac à sable
Le changement est préparé sur une branche git isolée, contre le code du site. La production n’est pas modifiée pendant la construction.
- 03
Aperçu
La branche reçoit une URL d’aperçu privée, pour lire le changement au vrai format avant toute publication.
- 04
Contrôles
Le contrat SEO, les liens internes, le schéma et le budget de performance sont vérifiés en intégration continue, contre la version précédente.
- 05
Relecture
Une personne lit le changement sur l’aperçu, puis le valide ou le refuse. Par défaut, c’est le relecteur SiteBienfait ; le propriétaire qui le préfère peut valider lui-même chaque changement.
- 06
Publication
Un changement validé est publié en production. Le déploiement précédent reste accessible comme cible de retour arrière.
- 07
Mesure
Une fenêtre de mesure convenue avant la publication s’ouvre, et le rapport hebdomadaire la lit contre la référence.
- 08
Verdict
À la fin de la fenêtre, le changement est conservé ou annulé. Le rapport consigne lequel, avec les données derrière.
Le même chemin, dessiné
Le schéma marque la frontière de validation, parce que c’est l’étape qui ne bouge pas : rien n’est publié sans elle.
- 1. Demande: En langage clair
- 2. Bac à sable: Branche git isolée
- 3. Aperçu: URL privée
- 4. Contrôles: SEO, liens, vitals
- 5. Validation: Une personne décide
- 6. Publication: En production
- 7. Mesure: Fenêtre ouverte
- 8. Verdict: Garder ou revenir
Un contrôle fait échouer le changement ; il n’avertit pas
Un avertissement que l’on peut ignorer reste une suggestion. Chaque contrôle ci-dessous arrête le changement, et l’échec est consigné.
- Contrat SEO
-
URL, titres, descriptions, canoniques et données structurées sont comparés avant et après. Une URL perdue, un titre manquant ou une canonique cassée est un échec, pas un avertissement.
Échec : le changement n’est pas livré.
- Diff visuel
-
L’aperçu est comparé à la page en ligne au même format, pour voir une régression de mise en page au lieu de la supposer.
Échec : l’aperçu est refusé et le diff est joint.
- Liens internes
-
Chaque lien interne de la construction est résolu vers un fichier construit ou une ancre de la page. Un lien mort fait échouer le contrôle.
Échec : le changement n’est pas livré.
- Budget de performance
-
La page doit rester dans le budget JavaScript et Core Web Vitals du site. Une régression sur la page livrée fait échouer le contrôle.
Échec : le changement est repris dans le bac à sable.
La version précédente reste accessible
Le retour arrière n’est pas une reconstruction : c’est un retour au déploiement qui servait déjà la production. La cible est donc créée avant la publication, pas après un problème.
- 01
Une version connue comme valide
Chaque changement de production conserve le dernier bon déploiement comme cible de retour arrière.
- 02
Une action depuis la console
Le retour arrière s’exécute depuis la console, sans édition manuelle d’une base de données ni reconstruction de mémoire.
- 03
Consigné, pas masqué
Un retour arrière est inscrit contre le changement et sa fenêtre de mesure, pour que la proposition suivante parte de ce qui s’est passé.
Ce que le propriétaire contrôle
Le propriétaire n’est pas spectateur dans ce déroulé. Voici les décisions qui restent entre ses mains à chaque étape.
-
La validation, si vous la voulez
Vous relisez les pages une fois avant la mise en ligne. Ensuite, une personne valide chaque changement sur son aperçu, et vous pouvez demander à être cette personne — pour un changement ou pour tous. Un changement refusé n’est pas livré sous une autre forme.
-
Périmètre
Un changement reste un changement. Le propriétaire peut refuser un lot qui mélange des modifications sans rapport au lieu de tout valider.
-
Calendrier
Le propriétaire décide quand un changement validé est publié, y compris en le gardant pour une période plus calme.
-
Retour arrière
Le propriétaire peut revenir au déploiement précédent après toute publication, pas seulement quand un agent le propose.
-
Propriété
Le domaine, le dépôt source et le compte d’hébergement restent au nom du propriétaire, et le dépôt peut être exporté à tout moment.
Ce que cette page ne revendique pas
Un déroulé rend les changements plus sûrs et réversibles. Il ne décide pas ce qu’un moteur de recherche ou un moteur de réponse fera de la page ensuite.
- Un changement plus sûr n’est pas une position.
- Les contrôles protègent l’existant. Ils ne font pas choisir la page par un moteur de recherche.
- Passer tous les contrôles ne prouve pas un résultat.
- La preuve est que le changement n’a pas cassé le contrat. C’est la fenêtre de mesure qui lit une direction.
- Aucune étape n’est sautée en silence.
- Si un contrôle ne peut pas tourner, le changement n’est pas livré. Un contrôle manquant n’est pas traité comme réussi.
Commencer par un audit gratuit
L’audit est en lecture seule et coûte 0 €. Une personne relit le rapport, et rien n’est préparé sans votre demande.
Recevoir mon audit gratuit