Plan de continuité d’activité (PCA)¶
Mesures préventives et dispositifs permettant de maintenir le service en fonctionnement malgré les incidents (panne d’un composant, indisponibilité partielle d’un fournisseur, pic de charge, erreur humaine).
Voir aussi : Plan de reprise d’activité (PRA), Sauvegardes, Revues régulières, Provisioning, Monitoring, CI/CD.
Périmètre¶
Service |
Criticité |
Disponibilité visée |
|---|---|---|
Webapp publique (carte, assistant, API REST, iframes intégrateurs) |
Élevée |
Service de référence pour le grand public et les intégrateurs. |
Django Admin / CMS Wagtail / |
Moyenne |
Outils internes — indisponibilité tolérée le temps d’un incident. |
Plateforme data (Airflow + dbt) |
Moyenne |
Pipelines batchs — retard d’exécution acceptable, rattrapage par re-run. |
Documentation (GitHub Pages) |
Faible |
Hors périmètre opérationnel critique. |
Haute disponibilité native¶
Webapp Django (Scalingo osc-fr1)¶
Mécanisme |
Détail |
|---|---|
Gunicorn multi-workers |
Plusieurs workers servent les requêtes en parallèle derrière nginx local ( |
Worker django-tasks |
Container Scalingo |
nginx Scalingo (cache) |
Couche de cache devant Gunicorn ( |
WhiteNoise + |
Statiques servis directement par l’app, indépendants d’un CDN tiers. |
Cache applicatif en base |
|
Scalabilité horizontale Scalingo |
Possibilité d’augmenter le nombre de containers |
Bases de données (Scaleway RDB PostgreSQL 16)¶
Mécanisme |
Détail |
|---|---|
Offre RDB HA |
Instances |
Point-in-time recovery |
Rétention PITR 24 h (granularité seconde) sur chaque base. |
|
Chiffrement systématique des connexions clientes. |
Object Storage (Scaleway S3 fr-par)¶
Mécanisme |
Détail |
|---|---|
Stockage objet managé |
Durabilité & disponibilité standards du service S3 Scaleway (multi-AZ). |
Versioning |
Activé sur |
Snapshots horodatés |
|
Airflow (Scaleway Container as a Service)¶
Mécanisme |
Détail |
|---|---|
Containers séparés |
Webserver, scheduler et DAG processor déployés indépendamment — l’arrêt du webserver n’interrompt pas l’exécution des DAGs. |
Re-run de DAG |
Tout DAG en échec peut être relancé manuellement depuis l’UI sans perte (idempotence applicative à respecter par le développeur du DAG). |
Remote logs S3 |
|
Cleanup automatique |
DAG |
Redondance opérationnelle¶
Multi-environnements¶
Environnement |
Usage |
Bascule possible ? |
|---|---|---|
Prod |
Service public. |
— |
Preprod |
Réplique fonctionnelle (sync hebdo des données). |
Utilisable comme environnement témoin en cas d’incident sur la prod (lecture seule, validation d’une procédure de fix). |
Sauvegardes¶
Le détail (PITR 24 h, dumps quotidiens 7 j, copies cross-region, versioning S3, état Terraform versionné) est centralisé dans backups.md.
Infrastructure as Code¶
Toute l’infra Scaleway est décrite dans infrastructure/ (OpenTofu + Terragrunt). L’état est stocké, versionné et chiffré dans le bucket lvao-terraform-state. Conséquence PCA : la totalité du socle peut être re-provisionnée à l’identique sans connaissance tribale.
Prévention des incidents¶
Avant déploiement (CI)¶
Garde-fou |
Outil / workflow |
|---|---|
Tests automatisés |
Unit / integration / E2E (Playwright) déclenchés sur chaque PR ( |
Migration checks |
Vérification des migrations Django dans la CI avant merge. |
Linters & formatters |
Ruff, Black, Prettier, ESLint, |
Scan sécurité |
CodeQL, GitGuardian, Dependabot, |
Validation préprod |
Déploiement explicite sur preprod possible depuis chaque PR avant merge. |
Pendant le déploiement (CD)¶
Garde-fou |
Détail |
|---|---|
Build & push registry |
Images Airflow buildées et poussées sur |
Healthcheck post-deploy |
|
Notifications temps réel |
Canal Mattermost |
En production (monitoring)¶
Garde-fou |
Détail |
|---|---|
Sentry |
Détection en temps réel des erreurs back/front ( |
Scaleway Cockpit (Grafana) |
Métriques RDB PostgreSQL & containers Airflow. |
PostHog / Matomo |
Surveillance indirecte de l’usage (chute de trafic = signal faible d’incident). |
Dashlord ADEME |
Audit de sécurité externe continu (dashlord.incubateur.ademe.fr). |
Stratégies de dégradation contrôlée¶
Composant en panne |
Comportement attendu |
|---|---|
API BAN / geo.api.gouv.fr |
Cache HTTP (1 h pour BAN, 30 j à 1 an pour EPCI) absorbe l’indisponibilité courte. L’autocomplete d’adresses dégrade silencieusement. |
Notion API |
Le formulaire de contact échoue côté |
PostHog |
A/B testing et |
Matomo |
Aucune incidence fonctionnelle (analytics uniquement). |
Sentry |
Aucune incidence fonctionnelle, mais perte temporaire de visibilité sur les erreurs. |
Scaleway Object Storage |
Les images médias (uploads Django Admin) ne se chargent plus côté front, mais les pages restent servies. |
Airflow |
Les pipelines de données sont retardés — la webapp et l’API publique continuent de servir les données déjà consolidées. |
Rôles & responsabilités¶
Rôle |
Responsabilité PCA |
|---|---|
Équipe produit / dev |
Surveillance Mattermost / Sentry, déclenchement d’un rollback ou d’un re-run de DAG, communication interne. |
Scaleway |
SLA infra (RDB HA, S3, Container Registry, CaaS). |
Scalingo |
SLA hébergement webapp. |
GitHub |
Disponibilité du code, des Actions CI/CD et de la documentation. |
Limites connues¶
Pas de VPC : exposition publique des bases et containers, mitigée par
sslmode=requireet credentials forts (network.md).Pas de Redis : le cache applicatif est en base — saturation possible de
qf_django_cacheà surveiller via Cockpit.Dépendance région unique : prod et preprod sont toutes deux en région
fr-par/osc-fr1. Les sauvegardes cross-region offrent une couverture en cas de sinistre régional (voir PRA), mais pas de bascule chaud automatique.RTO/RPO formels non contractualisés : objectifs cibles documentés dans le PRA.