Cette liste s'accompagne d'un article qui explique son fonctionnement en détail. Si vous ne savez pas
comment vous en servir, n'hésitez pas à aller voir le lien ci-après.
Les schémas de base de données sont créés via du code et déployés par des migrations automatiques
Les tests de type unitaire et d'intégration sont automatisés
Les configurations des applications et de l’infrastructure sont automatisées via de l’Infra as Code
Un environnement ISO PROD (infra) permet de valider les fonctionnalités
Les identifiants et comptes d’accès sont gérés à travers un gestionnaire de mots de passe
Les secrets sont chiffrés
Les systèmes critiques sont redondés
L’infrastructure est prévue pour scale up à l’échelle d’une journée (possibilité d’augmenter les capacités de l’infra dans la journée)
Un monitoring technique est en place (RAM, CPU, Occupation disques, débit entrée/sortie, latence réseau…)
Un mécanisme de healthcheck donne l’état des applications en production à tout moment - article
Les applications produisent des logs structurés
Les applications en prod exposent leur version
Une stratégie d'exploitation de logs est définie (durée de rétention, gestion d'accès, RGPD)
Un outil de visualisation et requêtage des logs est mis en place
Les moyens de contact des hébergeurs, opérateurs et partenaires externes sont renseignés dans un document
Les informations de la mise en service ont été communiquées aux utilisateurs (ex : date, information d'accès)
Le produit est conforme aux exigences d'accessibilité (a11y) - article
Un dispositif pour assurer la 1ère MES, la gestion d'incident et le support est mis en place
Un dispositif de support aux utilisateurs est mis en place (canal, personnes pour gérer le flux, experts métiers, support tech, etc.)
Le système a été mis à l’épreuve d’une charge cible
Les coûts d’infrastructure ont été estimés
Avant chaque Mise en Service (MES)
Tout ce qui doit être maintenu et révisé à chaque Mise En Service
Le déploiement est automatisé et testé
Le processus de MES est documenté et à jour
Les fonctionnalités peuvent être feature flippées de bout en bout
La fiabilité du système est vérifiée avant chaque MES
L’intégration aux systèmes tiers est validée avec les partenaires
Les actions métier réalisées en PROD sont tracées et auditables (identité, nature, ...)
Récurrent / Sanity Check
Tout ce qui évolue à un rythme différent de celui du projet
Le SI ou le produit est conforme à la législation
Un document d'exploitation existe, est connu et est à jour
De la documentation sur l'architecture, les technologies, l’infrastructure, l’organisation, etc. existe et est mise à jour
Les accès entre applications sont gérés de façon impersonnifiée
Les opérations réalisées en PROD sont traçables et auditables (identité, nature, ...)
Les vulnérabilités de sécurité communes (CVEs) sont détectées automatiquement - article
Une matrice de risque à jour informe les priorités
La détection de faille de sécurité est automatisée
Un mécanisme automatique de sauvegarde et restauration des données est régulièrement testé
La procédure de rollback est automatisée et testée (Generic Mitigation) - article
Le système est surveillé selon des SLIs (ex: Golden Signals) - article
Les niveaux de service attendu (SLO) sont définis par application - notamment la disponibilité - article
Les contraintes de sécurités minimales du produit (MVSP : Minimal Viable Secure Product) sont atteintes
Des logs enrichis et multidimensionnels rendent le système observable
Les accès des effectifs entrants et sortants sont gérés de manière automatisée et sont résilients en cas de départ (ex. compte de service)
Une politique de rotation de secret a été mise en place
La distribution des coûts d’infrastructure est suivie
Un processus de gestion d'incident est suivi et mis à jour (rôles, template de suivi, liste de contacts, template de postmortem)
L'analyse des incidents via postmortem permet l'amélioration du système et la gestion d'incident
Des entrainements de gestion d'incident sont réalisés régulièrement
Changement d'échelle
Tout ce qui remet en question nos besoins et donc nos pratiques
Les anomalies sont signalées par des alertes qui permettent de les localiser
Les rôles et responsabilités sur le RUN sont définis
Le service est bêta-testé par un petit groupe d'utilisateurs
Des tests fonctionnels et de bout en bout automatisés
Des indicateurs métiers sont mis en place
Des "quality gates" de MES des fonctionnalités et conditions de GO MEP sont définies (ex: % de tests auto, documentation, change file)
Un environnement ISO prod (infra, sizing, données) permet de valider les performances en amont d’une MES
L'enchaînement des événements peut être reconstitué par de la corrélation de logs
Des smoke tests sont réalisés suite à des mises en prod (de manière automatique ou non)
Les applications peuvent être déployées sans interruption de service (ZDD, Zero Downtime Deployment)
La performance des applications (vitesse/latence) est mesurable automatiquement
Des mécanismes de dégradation de service permettent de ne pas faire tomber complètement le système en cas de surcharge (Generic Mitigation) - article
Les astreintes sont mises en place
Lorsque le système est surchargé, des mécanismes déplacent le trafic dans une autre zone (Generic Mitigation) - article
Les indisponibilités des flux externes (circuit breaker) sont gérées (Generic Mitigation) - article
Des mécanismes de blocage sur les requêtes "gourmandes" permettent de garantir la stabilité du système (Generic Mitigation) - article
Changes 28/03/2025
Ajout de liens sur les capacités :
Un mécanisme de healthcheck donne l’état des applications en production à tout moment
Les vulnérabilités de sécurité communes (CVEs) sont détectées automatiquement
Le système est surveillé selon des SLIs (ex: Golden Signals)
Les niveaux de service attendu (SLO) sont définis par application - notamment la disponibilité
Changes 28/02/2025
Ajout de liens sur les capacités :
Le produit est conforme aux exigences d'accessibilité (a11y)
La procédure de rollback est automatisée et testée (Generic Mitigation)
Des mécanismes de dégradation de service permettent de ne pas faire tomber complètement le système en cas de surcharge (Generic Mitigation)
Lorsque le système est surchargé, des mécanismes déplacent le trafic dans une autre zone (Generic Mitigation)
Les indisponibilités des flux externes (circuit breaker) sont gérées (Generic Mitigation)
Des mécanismes de blocage sur les requêtes "gourmandes" permettent de garantir la stabilité du système (Generic Mitigation)
Changes 21/02/2025
ajout d'un changelog en fin de page
Changes 14/02/2025
Ajout de nouvelles capacités sur la gestion d'incident :
Un processus de gestion d'incident est suivi et mis à jour
L'analyse des incidents permet d'amélioration le système et la gestion d'incident via postmortem
Des entrainements de gestion d'incident sont réalisés régulièrement
Renommage des capacités
Un dispositif pour assurer la 1ère MES et le support est mis en place -> Un dispositif pour assurer la 1ère MES, la gestion d'incident et le support est mis en place
