Définir la préparation autour d'un résultat client
Commencez par les résultats, pas par les étiquettes d'infrastructure. Une page d'accueil accessible ne suffit pas si le visiteur ne peut pas accomplir la tâche qui compte. Pour chaque parcours critique, indiquez qui essaie de faire quoi, ce que signifie la réussite et quel résultat est inacceptable. Démarrez avec quelques parcours afin que l'équipe puisse prendre des décisions concrètes.
Classez chaque étape comme essentielle, importante ou reportable. Essentielle signifie que le parcours ne peut pas se terminer sans elle ; importante peut permettre une solution de contournement limitée dans le temps ; reportable peut être omise, retardée ou simplifiée. C'est une décision produit éclairée par l'ingénierie, pas un classement technique universel.
Consigner un résultat utilisable, par exemple une commande acceptée et une confirmation enregistrée, plutôt que de se limiter à un objectif de réponse de page.
Cartographier les dépendances et décider ce qui peut se dégrader
Pour chaque parcours critique, cartographiez l'hébergement ou la distribution, le DNS, les services applicatifs, les bases de données, l'authentification, les e-mails, le paiement, la recherche, les tags, les outils de consentement et les API externes. Enregistrez le propriétaire, la voie de support, la limite pertinente et l'effet pour l'utilisateur si chacun est indisponible. OWASP recommande de connaître les dépendances logicielles ; la même discipline de propriété aide pour les dépendances opérationnelles.
Une dépendance dure bloque la tâche lorsqu'elle échoue. Une dépendance souple peut être absente ou obsolète tandis que la fonction principale continue de fonctionner. AWS décrit la dégradation gracieuse comme le maintien de la fonction centrale lorsque des dépendances sont dégradées. Définissez un choix produit spécifique : masquer un widget non essentiel, différer un rapport ou présenter un recours honnête. N'inventez pas d'inventaire, de prix, d'états de commande ou de résultats de paiement.
Consigner l'usage, le propriétaire, la limite connue, le fallback, le contact de changement et la date du dernier test pour chaque élément.
Transformer une prévision de trafic en expérience de capacité
Utilisez un scénario, pas un seul chiffre de trafic. Indiquez l'événement, le motif d'arrivée, le mélange de requêtes, la part d'utilisateurs connectés, la géographie, l'activité de paiement ou d'écriture simultanée et la période de pointe. Incluez un cas haut et les hypothèses. Google note que les requêtes peuvent avoir des coûts en ressources très différents, donc les requêtes par seconde seules peuvent être un mauvais modèle de capacité.
Testez un trafic soutenu, représentatif et de bout en bout sur une configuration proche de la production, avec approbation et garde-fous. AWS met en garde contre le fait de tester uniquement des composants, d'utiliser un sous-ensemble de requêtes non représentatif ou de s'arrêter à une petite marge au-dessus de la charge prévue. Documentez la première contrainte ou le premier ralentissement. Les tests en production active peuvent affecter les clients ; utilisez un environnement contrôlé sauf si un exercice planifié et encadré est approprié.
Conservez le scénario, la configuration, le mélange de requêtes, la durée, la contrainte observée, le changement de capacité et le responsable du suivi.
Préparer les choix de changement, rollback et récupération
Avant un changement à enjeux élevés, identifiez l'artéfact ou la configuration à restaurer, l'approbation requise, la personne autorisée et la méthode de validation. Gardez un runbook court pour mettre en pause une release, revenir sur un déploiement, désactiver un feature flag, réduire une intégration non critique ou restaurer des données en suivant une procédure approuvée. Testez les mécanismes avant l'événement ; une sauvegarde ou un plan de rollback non exercé reste une hypothèse.
Définissez des objectifs de récupération à partir de l'impact business. Recovery Time Objective, ou RTO, est le délai maximal acceptable avant la restauration du service. Recovery Point Objective, ou RPO, est la perte de données maximale acceptable mesurée depuis le dernier point de récupération. AWS met en garde contre des cibles arbitraires ou irréalistes et note que les objectifs des dépendances influencent ce qui est réalisable. Considérez ces objectifs comme des buts de planification, pas comme des promesses aux clients.
Vérifiez un rollback ou une restauration limitée et sûre, et consignez ce qui a été vérifié, par qui et les éventuels écarts constatés.
Attribuer la responsabilité avant que les décisions ne deviennent urgentes
Une simple liste de contacts n'est pas de la propriété. Pour chaque parcours critique, attribuez un propriétaire business pour le résultat acceptable, un propriétaire technique pour la mise en œuvre, et un décideur autorisé à effectuer un changement protecteur. Nommez des remplaçants et clarifiez quand un fournisseur, une agence, un processeur de paiement ou une équipe interne prend la suite.
Effectuez une courte revue de préparation avant l'arrivée du trafic. Parcourez une défaillance de dépendance : ce qui reste disponible, quel levier est sûr, qui l'approuve et comment la réussite est vérifiée. Il s'agit d'une répétition proactive, pas d'un rapport d'état en direct. Consignez les actions datées, les propriétaires et les échéances.
Prédéfinissez l'autorisation de petites actions sûres lorsque c'est approprié afin que la protection n'attende pas une chaîne d'approbation floue.
Traiter les parcours sensibles au paiement et à la sécurité avec une attention particulière
La préparation du parcours de paiement doit préserver la validité autant que la disponibilité. Ne contournez pas l'autorisation, n'affaiblissez pas les contrôles d'accès, n'exposez pas de credentials et ne modifiez pas à la légère les scripts des pages de paiement. Les recommandations du PCI SSC traitent de l'autorisation, de l'intégrité et de la détection de falsification pour les scripts de pages de paiement et les en-têtes HTTP impactant la sécurité. Si le site accepte des cartes ou utilise un cadre de paiement intégré, faites examiner les modifications matérielles par le marchand, le processeur, l'acquéreur et des conseillers qualifiés en sécurité ou conformité.
Tenez un inventaire des scripts de production, des intégrations, des versions et des propriétaires de comptes, et restreignez qui peut les modifier. OWASP note que les inventaires de dépendances et le verrouillage de version (version pinning) peuvent réduire l'incertitude sur ce qui entre dans une build, tandis que les résultats automatisés nécessitent toujours une vérification manuelle. Ces pratiques soutiennent la préparation mais n'établissent pas la conformité PCI ni ne remplacent une évaluation de sécurité.
N'utilisez qu'un flux alternatif approuvé et examiné par le processeur ; ne collectez jamais de données de carte via des canaux informels.