Rendre la préparation
vérifiable.
Un plan interactif pour attribuer et vérifier les tâches de lancement dans Activer, Renforcer, Accélérer et Rétablir. Il fonctionne sans compte ; les propriétaires SIU connectés peuvent, s’ils le souhaitent, enregistrer en privé les progrès par catégorie. Ce n’est ni un point de contrôle de publication, ni un outil de surveillance, ni un contrôle de production.
UTILISEZ-LE POUR: Utilisez l'ordre de priorité déterministe pour rendre la responsabilité et la vérification visibles, tout en préservant Inconnu et Ignorer comme résultats explicites plutôt que comme achèvement implicite.
Effectuez l'étape suivante connue.
- Choisissez une voie, puis assignez à chaque élément de priorité déterministe un état : Prêt, Inconnu ou Ignorer. Inconnu incite à obtenir une preuve ; Ignorer nécessite une décision responsable.
- Examinez le propriétaire et la déclaration de vérification pour chaque élément. Modifiez le champ propriétaire uniquement pour nommer un rôle ou une personne responsable — n'inscrivez jamais d'identifiants ni de données client dans le plan.
- Téléchargez le plan courant sur l'appareil lorsqu'un transfert portable est utile. L'enregistrement facultatif sur un compte SIU stocke uniquement l'étiquette du site et les états d'action catégoriels ; les URL, identifiants, fichiers et notes propriétaires en texte libre sont exclus.
Le tableau de contrôle du lancement.
Ordre déterministe : Les éléments restent dans leur séquence de priorité numérotée. Sélectionnez Inconnu lorsque les preuves font défaut ; sélectionnez Ignorer uniquement après une décision d'une personne responsable.
Activer
Établir les décisions minimales, les responsables et les éléments destinés au public avant qu'une publication ne soit lancée.
- 01Nommer l'intention de la publication et le parcours client qu'elle modifie
Un périmètre restreint et explicite donne aux relecteurs et aux intervenants un point de départ commun.
PROPRIÉTAIRE RESPONSABLE: Responsable de la publication · VÉRIFICATION: Un relecteur peut citer le parcours modifié, le résultat client visé et la fenêtre de publication dans un seul bref enregistrement. - 02Confirmer le contact côté client et la formulation d'escalade
Les clients ont besoin d'un moyen clair pour signaler un impact sans message improvisé pendant un changement.
PROPRIÉTAIRE RESPONSABLE: Responsable des communications client · VÉRIFICATION: Le contact d'astreinte ou de support est joignable via le canal approuvé et la formulation publique a un relecteur responsable. - 03Parcourir le parcours client principal avant le lancement
Un parcours visible dans le navigateur peut révéler des problèmes qu'un simple résultat de build ne montre pas.
PROPRIÉTAIRE RESPONSABLE: Responsable produit ou QA · VÉRIFICATION: L'équipe enregistre l'URL de départ, le résultat attendu et toute frontière nécessitant une connexion ou un paiement sans utiliser de données client.
Renforcer
Rendre la publication et son parcours de récupération plus faciles à inspecter, limiter et inverser avec les bonnes personnes.
- 04Enregistrer l'identifiant de la publication et un historique de changement réversible
Une référence précise réduit les conjectures si le changement doit être mis en pause ou annulé.
PROPRIÉTAIRE RESPONSABLE: Responsable de la publication · VÉRIFICATION: L'identifiant de la publication, la source de déploiement, l'approbateur et la procédure de retour en arrière connue sont accessibles au responsable de la réponse. - 05Vérifier que les opérateurs désignés disposent du bon chemin d'accès
L'escalade est plus lente lorsque les hypothèses d'accès ne sont pas testées.
PROPRIÉTAIRE RESPONSABLE: Responsable plateforme · VÉRIFICATION: Une exécution à vide en environnement non production ou approuvée confirme que les personnes responsables peuvent atteindre les outils documentés; ne partagez pas d'identifiants dans ce plan. - 06Passer en revue la surface de dépendances et de changements tiers
Les changements tiers peuvent modifier un parcours de lancement même lorsque le code applicatif reste inchangé.
PROPRIÉTAIRE RESPONSABLE: Responsable ingénierie · VÉRIFICATION: Le dossier de publication nomme les dépendances nouvelles ou modifiées, les points de terminaison externes et la personne pouvant évaluer chacun d'eux.
Accélérer
Réduire le travail de livraison évitable tout en conservant un parcours vers le lancement observable et examiné.
- 07Inspecter les images candidates à leur emplacement rendu
Une image source seule n'indique pas quels octets un client recevra.
PROPRIÉTAIRE RESPONSABLE: Responsable design ou performance · VÉRIFICATION: Pour les images prioritaires, l'équipe enregistre la largeur rendue prévue, le texte alternatif accessible et l'existence éventuelle de variantes responsives. - 08Définir un budget de livraison révisable pour le parcours modifié
Un contexte de mesure explicité est plus utile qu'une promesse de performance sans borne.
PROPRIÉTAIRE RESPONSABLE: Responsable performance · VÉRIFICATION: L'équipe documente la métrique, le contexte du test et la plage acceptable; cela n'implique pas une promesse de rapidité universelle. - 09Choisir un petit ensemble de parcours d'observation post-publication
Une vérification ciblée est plus facile à interpréter qu'une liste d'URL sans propriétaire.
PROPRIÉTAIRE RESPONSABLE: Responsable de la publication · VÉRIFICATION: Au maximum cinq chemins relatifs sont assignés à un responsable avec une réponse attendue ou une note d'observation.
Rétablir
Préparer une passation calme, une voie d'escalade et une réponse réversible avant que les clients n'en aient besoin.
- 10Attribuer les rôles décisionnels d'incident, technique et communication
La clarté des rôles favorise une réponse coordonnée sans supposer qu'une seule personne puisse diagnostiquer tous les problèmes.
PROPRIÉTAIRE RESPONSABLE: Responsable de la gestion des incidents · VÉRIFICATION: Chaque rôle a une personne nommée et responsable ou une voie d'escalade explicite pour la fenêtre de publication. - 11Répéter la délimitation décisionnelle pour la mise en pause ou le retour en arrière
Une procédure réversible est plus sûre lorsque ses étapes d'approbation et de vérification sont connues avant l'arrivée de la pression.
PROPRIÉTAIRE RESPONSABLE: Responsable de la publication · VÉRIFICATION: L'équipe connaît le déclencheur approuvé, qui l'autorise et quelles preuves doivent être capturées avant et après l'action. - 12Relier le travail de statut de service en direct à Status Is Down
SIU fournit des orientations de planification; le travail de statut de service en direct appartient à SID.
PROPRIÉTAIRE RESPONSABLE: Responsable communications · VÉRIFICATION: Le plan de communication oriente les personnes vers la destination SID pertinente pour le signal du service en direct et les mises à jour.
Passez en revue tous les éléments non marqués comme PRÊT avec le propriétaire concerné avant la décision de mise en production.
Confirmez les déclarations de vérification par rapport à l'environnement de mise en production réel et au processus de réponse documenté.
Dirigez le statut en direct et le travail d'incident en cours vers SID et le flux de travail d'incident de l'équipe.
Export de planification côté client. Il ne s'agit pas d'une approbation de mise en production, d'un enregistrement de surveillance ni d'un contrôle de production.
Notes de source, pas une certitude empruntée.
Base de planification : références Google SRE, CISA, OWASP, web.dev et MDN utilisées par les guides SIU liés
- CISA — Planning: Response & Recovery ↗CISA met en avant la planification de la récupération après incident et catastrophe, la priorisation par impact métier, les voies de contact et la structure de remontée interne.
- Google SRE Book — Production service best practices ↗Les recommandations préconisent des déploiements progressifs supervisés et un retour en arrière en premier lieu en cas de comportement inattendu, puis un diagnostic pour réduire le temps de récupération.
- OWASP — Software Supply Chain Security Cheat Sheet ↗OWASP recommande un inventaire des dépendances, la génération automatisée de SBOM lorsque pertinent, la surveillance, le verrouillage des versions, l'inventaire des outils de build et les contrôles de provenance.
- web.dev — Responsive images ↗web.dev explique que le poids des images peut être important et décrit les candidats responsive, srcset, sizes et picture pour les cas d'utilisation adaptés.
Rédaction : Brouillon éditorial SIU Enablement ; guidance opérationnelle limitée aux sources. Révisé par : Un propriétaire de mise en production doit revoir chaque plan. L'enregistrement facultatif sur compte persiste uniquement l'étiquette du site et les états d'action catégoriels en privé ; SIU n'approuve pas une mise en production. Revalider : Revalidez avant une mise en production majeure et lorsque la responsabilité, les outils ou les voies clients changent.