Une architecture de référence

Pourquoi

Quinze leçons ont présenté, un par un, les services dont Signalements avait besoin. Une application de production n'est pourtant pas une liste de services : c'est un assemblage, avec des dépendances, des points de défaillance, un coût et des procédures. Les questions qu'on pose à cet assemblage ne se posent à aucun service isolé : que se passe-t-il si la zone fr-par-1 tombe ? combien coûte un mois de production ? par où entre un attaquant ? qui sait redémarrer quoi, à 3 h du matin, et avec quelle procédure ?

La métropole, avant de signer pour trois ans, demande un dossier d'architecture qui réponde à ces questions. Sans lui, la connaissance de l'architecture vit dans la tête de deux personnes, l'estimation de coût dans un tableur jamais mis à jour, et la première panne sérieuse se règle par improvisation. Avec lui, l'équipe peut raisonner, l'auditeur peut vérifier, et le nouvel arrivant peut comprendre.

Une architecture de référence est ce document, accompagné des choix qui le justifient. Cette leçon la construit pour Signalements, en reprenant chaque leçon du cours, puis fournit les outils pour la tenir à jour.

Les concepts

Le schéma d'ensemble

    flowchart TB
  U["Habitants, agents"] -->|HTTPS| ES["Edge Services<br/>(global) : cache, TLS, WAF"]
  M["Métropole<br/>192.168.50.0/24"] -->|"IPsec + BGP"| VGW
  ES --> LB["lb-signalements<br/>(fr-par-1, bascule documentée)"]
  subgraph VPC["vpc-signalements (fr-par)"]
    subgraph PNA["pn-signalements 172.16.20.0/22"]
      LB
      G1["Groupe d'instances<br/>fr-par-1"]
      G2["Groupe d'instances<br/>fr-par-2"]
      R[("Redis<br/>(zonal)")]
      GW1["Passerelle publique<br/>fr-par-1"]
      GW2["Passerelle publique<br/>fr-par-2"]
      VGW["Passerelle VPN<br/>fr-par-1"]
    end
    subgraph PND["pn-sig-donnees 172.16.24.0/22"]
      DB[("sig-db PostgreSQL<br/>HA multizone + réplica")]
    end
    subgraph PNM["pn-sig-admin 172.16.28.0/22"]
      ADM["Instance d'administration"]
    end
  end
  LB --> G1
  LB --> G2
  G1 --> DB
  G2 --> DB
  G1 --> R
  G2 --> R
  G1 -->|"photos"| OS[("Object Storage<br/>signalements-pj (régional)")]
  OS -.->|"événement"| Q["Queues"] --> F["Function<br/>traitement des photos"]
  F --> OS
  G1 -.-> TEM["Transactional Email"]
  SM["Secret Manager"] -.-> G1
  SM -.-> G2
  REG["Container Registry"] -.-> G1
  REG -.-> G2
  CK["Cockpit"] -.- G1
  AT["Audit Trail"] -.->|"export quotidien"| SEC[("Bucket d'audit<br/>projet sécurité, Object Lock")]
  

Le schéma se lit de haut en bas, comme une requête : Edge Services en frontal, le répartiteur, les instances réparties dans deux zones, la base et le cache derrière ; puis, à côté, le traitement asynchrone des photos et les services de support (secrets, registre, observabilité, audit).

Les choix, un par un

Chaque ligne du dossier d'architecture associe un besoin à un choix, et dit ce que l'on a écarté. Le tableau suivant reprend les décisions du cours.

Un choix mérite un mot de plus. Le cours a fait tourner l'API sur des instances en groupes d'autoscaling, et non sur Serverless Containers. Ce n'est pas un rejet : Serverless Containers (leçon 5) conviendrait techniquement à une API sans état. L'équipe a choisi les instances parce qu'elles gardent la même forme que le cours précédent, qu'elles se relient au VPN et au Redis sans contrainte, et qu'elles préparent la migration vers Kapsule. Une autre équipe, avec un trafic plus irrégulier, ferait le choix inverse et l'écrirait dans son propre tableau.

Zonal, régional, global : la tenue à la perte d'une zone

Le cours Le cloud : les fondamentaux a posé la règle : chaque ressource est zonale, régionale ou globale, et une architecture tient à la perte d'une zone si chaque composant zonal existe dans au moins deux zones, ou peut se reconstruire sans le plan de contrôle de la zone perdue. Appliquons-la :

Deux choix délibérés apparaissent : le Redis n'est pas doublé, parce qu'un cache perdu n'est qu'un ralentissement ; la passerelle VPN n'est pas doublée, parce que le flux qu'elle porte n'est pas critique. Les deux sont écrits dans le dossier, avec leur justification et la condition qui les ferait changer (« si la synchronisation devient horaire, deuxième passerelle VPN en fr-par-2 »).

L'estimation de coût

Une estimation sérieuse a trois qualités : elle est ligne par ligne, elle est datée, et elle est reproductible par quelqu'un d'autre. Le tableau suivant utilise les prix publics relevés le 5 octobre 2026 (hors taxes, en euros, 730 heures par mois) pour les composants dont le prix a été vérifié sur les pages de tarifs de Scaleway ou dans les leçons précédentes. Les autres lignes portent la mention « à relever » : la section En pratique montre comment.

Le total partiel, autour de 310 € par mois hors base, adresses IP et services à l'usage, montre déjà deux choses. Les instances dominent : c'est là que le dimensionnement et l'autoscaling (réduire la nuit) rapportent le plus. Et les petites lignes s'additionnent : les deux passerelles publiques et la passerelle VPN coûtent ensemble plus que deux instances. La base, en haute disponibilité multizone avec un réplica, sera vraisemblablement la deuxième ligne du budget ; elle se relève sur la page de tarifs des bases managées au moment du devis.

L'empreinte environnementale

Scaleway publie une estimation de l'empreinte de chaque projet, en kilogrammes d'équivalent CO2 et en mètres cubes d'eau, selon une méthode d'analyse du cycle de vie qui suit le référentiel de l'ADEME pour les services d'hébergement et de cloud : fabrication des équipements, énergie consommée (avec le PUE du centre de données et le mix électrique du pays), eau de refroidissement (WUE). Les données sont accessibles par la console, un rapport PDF mensuel, et l'API.

La mesure a ses limites, que la documentation énumère : au 5 octobre 2026, les produits intégrés sont les instances, Block Storage, Object Storage, Load Balancer, Kubernetes, les bases managées (PostgreSQL, MySQL, Redis, MongoDB), Elastic Metal, Apple silicon et les API d'IA générative. Les produits serverless et le VPC sont en cours d'intégration ; le registre, les passerelles publiques, IPAM, InterLink et Edge Services ne le sont pas encore. Le chiffre du projet Signalements est donc un minorant, dominé par les instances et la base, ce qui est cohérent avec ce qui consomme réellement.

Les mêmes leviers servent le coût et l'empreinte : moins d'instances la nuit, des types adaptés à la charge réelle, une conservation des journaux et des photos limitée à ce qui est nécessaire.

La liste de contrôle de mise en production

Le dossier se termine par une liste que l'on coche avant chaque mise en production importante, et qui reprend le cours :

• Comptes et droits : projets séparés ; aucune clé sans expiration ; second facteur obligatoire ; revue des accès datée de moins de trois mois (leçons 1, 15).
• Réseau : aucune instance ni base avec adresse publique ; Network ACL en refus par défaut ; groupes de sécurité stricts ; /metrics bloqué au répartiteur (leçons 12, 13, 14).
• Données : haute disponibilité de la base active ; sauvegardes automatiques vérifiées ; une restauration testée ce trimestre ; bucket des photos privé, chiffré, versionné (leçons 3, 15).
• Secrets : rien dans les images ni dans cloud-init ; rotation documentée (leçon 8).
• Observabilité : tableaux de bord de la base, du répartiteur et de l'application ; alertes 5xx et latence testées ; contacts à jour (leçon 14).
• Audit : export d'Audit Trail actif dans chaque région, vers un bucket verrouillé ; alertes de sécurité abonnées (leçon 15).
• Résilience : test de perte d'une zone réalisé (arrêt du groupe de fr-par-1) ; dimensionnement du groupe restant vérifié.
• Coût : budget et alertes de facturation actifs ; inventaire sans ressource orpheline (cours précédent, leçon 8).
• Runbooks : écrits, relus, et joués au moins une fois.

Les runbooks essentiels

Un runbook est une procédure écrite pour une situation d'exploitation précise : les symptômes qui la déclenchent, le diagnostic, les actions, la vérification, et qui prévenir. Le livre Site Reliability Engineering de Google, dans son introduction, estime que consigner à l'avance les bonnes pratiques dans de telles procédures divise par environ trois le temps moyen de réparation, par rapport à l'improvisation. Pour Signalements, six suffisent pour commencer :

En pratique

Les commandes ont été vérifiées avec l'aide de la CLI scw 2.62 et les structures du SDK Go. La leçon ne montre aucune sortie.

1. Le modèle du dossier d'architecture

Le dossier s'écrit en Markdown, dans le dépôt de l'infrastructure, et se relit comme du code. Son plan s'inspire du modèle arc42, réduit à l'essentiel :

docs/architecture.md
1. Contexte et objectifs : qui utilise Signalements, quelles exigences (disponibilité, données, contrat)
2. Vue d'ensemble : le schéma, et un paragraphe par bloc
3. Décisions : le tableau besoin / choix / écarté, chaque ligne datée ; renvoi aux notes de décision
4. Résilience : le tableau zonal / régional / global et le comportement à la perte d'une zone
5. Sécurité : zones de confiance, flux autorisés, identités, chiffrement, audit, angles morts
6. Exploitation : observabilité, alertes, runbooks, astreinte
7. Coûts et empreinte : estimation datée, méthode de mise à jour, empreinte du dernier mois
8. Risques et dettes connus : ce qui n'est pas doublé, ce qui reste manuel, et à quelle condition on y reviendra
9. Historique : date et auteur de chaque révision

La section 8 est celle que l'on est tenté d'omettre, et celle que l'auditeur lit en premier.

2. L'inventaire réel du projet

Le dossier décrit l'architecture voulue ; l'inventaire dit ce qui existe. Le script suivant parcourt les produits du cours dans toutes les zones et régions du projet de production. Il ne modifie rien.

#!/usr/bin/env bash
# Inventaire d'un projet Scaleway : une ligne par ressource (produit, nom, localisation).
# Usage : PROJET=<id du projet> ./inventaire.sh   (exige scw et jq)
set -uo pipefail
PROJET=${PROJET:?définissez PROJET}

liste() {   # liste "libellé" commande scw...
  local libelle=$1; shift
  "$@" project-id="$PROJET" -o json 2>/dev/null \
    | jq -r --arg l "$libelle" '(if type == "array" then . else [] end)[]
        | [$l, (.name // .id), (.zone // .region // "-")] | @tsv'
}

liste instance     scw instance server list zone=all
liste volume       scw block volume list zone=all
liste ip           scw instance ip list zone=all
liste lb           scw lb lb list zone=all
liste passerelle   scw vpc-gw gateway list zone=all
liste vpn          scw s2s-vpn vpn-gateway list region=all
liste reseau       scw vpc private-network list region=all
liste postgresql   scw rdb instance list region=all
liste redis        scw redis cluster list zone=all
liste registre     scw registry namespace list region=all
liste secret       scw secret secret list region=all
liste conteneur    scw container container list region=all
liste fonction     scw function function list region=all
for z in fr-par-1 fr-par-2 fr-par-3; do
  liste autoscaling scw autoscaling group list zone="$z"
done

• Chaque commande accepte zone=all ou region=all d'après son aide, sauf scw autoscaling group list, qui ne connaît que les zones de Paris : d'où la boucle.
• La fonction liste ne garde que les réponses qui sont des tableaux : si une commande renvoie une erreur (droits, produit non activé), la ligne est simplement absente, ce qui se voit à la relecture.
• Les champs name, zone et region sont ceux des objets du SDK Go ; une ressource sans nom affiche son identifiant.

Comparez la sortie au schéma : toute ressource de l'inventaire absente du dossier est soit un oubli du dossier, soit une ressource orpheline à supprimer.

3. Mettre l'estimation à jour avec le catalogue

Le catalogue public des produits de Scaleway s'interroge par l'API, ce qui permet de refaire l'estimation sans recopier de pages web :

$ scw product-catalog product list product-types.0=instance zone=fr-par-1 -o json \
    | jq -r '(if type == "array" then . else .products end)[]
        | [.product, .variant, .unit_of_measure.unit,
           ((.price.retail_price.units // 0) + (.price.retail_price.nanos // 0) / 1e9)] | @tsv' \
    | grep -i 'PRO2-XXS'

• product-types filtre la catégorie (instance, load_balancer, managed_relational_database, managed_redis_database, object_storage, secret_manager, serverless_containers...).
• Le prix est un montant au format du SDK : une partie entière (units) et des milliardièmes (nanos), que le filtre additionne. L'unité (unit_of_measure) dit à quoi il s'applique : l'heure, le gigaoctet, la requête.
• Le filtre if type == "array" tient compte de la forme de la réponse, que la CLI peut renvoyer comme une liste ou comme l'objet complet de l'API, avec son champ products.

Le même catalogue expose, pour chaque référence, une estimation d'impact environnemental (environmental_impact_estimation, en kilogrammes d'équivalent CO2 et en mètres cubes d'eau) : de quoi comparer deux types d'instances sur les deux critères à la fois.

4. L'empreinte du mois écoulé

$ scw environmental-footprint data get \
    start-date=2026-09-01T00:00:00Z end-date=2026-10-01T00:00:00Z \
    project-ids.0="$PROJET" -o json \
    | jq '{total: .total_impact,
           par_region: [.projects[].regions[] | {region, impact: .total_region_impact}]}'

La réponse donne l'impact total de la période, puis le détail par projet, par région, par zone et par référence (champ skus). Archivez ce chiffre mois par mois dans la section 7 du dossier : c'est la tendance, plus que la valeur, qui renseigne sur l'effet des choix de dimensionnement.

5. Écrire un runbook

Un runbook tient sur une page. Celui de la perte d'une zone, par exemple :

RUNBOOK : perte de la zone fr-par-1
Déclencheurs : alertes simultanées (instances, répartiteur) sur fr-par-1 ;
               page d'état de Scaleway.
1. Confirmer : tableaux de bord Cockpit, page d'état, test de /sante depuis l'extérieur.
2. Vérifier la bascule du répartiteur (réponse sur son IP flexible) ;
   sinon, ouvrir un ticket au support en priorité haute.
3. Vérifier que le groupe d'instances de fr-par-2 absorbe la charge ;
   sinon, augmenter sa capacité maximale (scw autoscaling group update ...).
4. Vérifier la base : nœud actif, latence. Le cache Redis est perdu : la latence
   remonte, c'est attendu.
5. Prévenir la métropole : le lien VPN est coupé ; la synchronisation reprendra.
6. Ne rien recréer dans fr-par-1 pendant l'incident.
7. Après retour : vérifier les deux groupes, le Redis, le VPN ; postmortem sous 5 jours.
Contacts : astreinte Lyneko, référent technique de la métropole.

L'étape 6 est la plus importante et la plus contre-intuitive : pendant une panne de zone, le plan de contrôle est sollicité par tous les clients à la fois. Une architecture qui ne demande aucune création pour survivre (la stabilité statique du cours précédent) est celle qui traverse l'incident.

Sous le capot

Pourquoi la stabilité statique. Une architecture peut survivre à la perte d'une zone de deux façons : en ayant déjà la capacité nécessaire dans l'autre zone, ou en la créant au moment de la panne. La seconde est moins chère au quotidien, mais elle dépend du plan de contrôle du fournisseur au pire moment, quand des milliers de clients font la même chose. C'est pourquoi les deux groupes d'instances ont une taille minimale qui permet à chacun de porter seul la charge normale : on paie en permanence une marge, en échange de ne rien demander à l'API pendant l'incident.

Pourquoi le dossier et l'inventaire divergent. Toute infrastructure modifiée à la main dérive de sa description : une règle ajoutée pendant un incident, une instance de test oubliée, une IP réservée « pour plus tard ». L'inventaire régulier révèle cette dérive, mais ne la corrige pas. La seule correction durable est de faire de la description la source de l'infrastructure : c'est l'infrastructure as code (cours Terraform et OpenTofu : les fondamentaux), et, pour les applications, le GitOps (cours GitOps avec Argo CD).

Ce que mesure l'empreinte. L'analyse du cycle de vie impute à votre projet une part de la fabrication des serveurs (amortie sur leur durée de vie), de l'énergie consommée (multipliée par le PUE du centre de données, puis convertie en CO2 selon le mix électrique du pays) et de l'eau de refroidissement. En France, le mix électrique peu carboné réduit la part de l'usage : la fabrication pèse alors relativement plus, ce qui plaide pour des types d'instances bien dimensionnés plutôt que pour des instances surdimensionnées et peu chargées.

Pièges courants

Un dossier écrit une fois. Un dossier daté d'il y a dix-huit mois est pire que pas de dossier : il rassure à tort. La section 9 (historique) et une revue à chaque changement d'architecture le maintiennent vivant.

Oublier les composants zonaux cachés. Le répartiteur, le Redis, la passerelle VPN sont zonaux ; les oublier dans l'analyse de perte de zone conduit à une architecture « multizone » qui tombe avec la première zone.

Dimensionner le groupe de secours au minimum. Deux groupes à une instance minimum chacun ne tiennent pas la charge normale si l'un disparaît. La taille minimale de chaque groupe se calcule à partir de la charge que l'ensemble doit porter.

Une estimation sans date. Les prix changent, les gammes se renouvellent (et les anciennes passent en fin de vie) : une estimation sans date ni source ne peut pas être vérifiée.

Additionner le prix horaire et oublier le reste. Adresses IP, passerelles, trafic sortant, conservation des journaux, sauvegardes : les lignes oubliées font l'écart entre le devis et la facture.

Confondre empreinte mesurée et empreinte réelle. Les produits non intégrés au calculateur ne comptent pas pour zéro ; ils ne sont simplement pas mesurés.

Sécurité

L'architecture de référence est aussi un document de sécurité, et elle en a les deux faces :

• Elle sert la défense. Les zones de confiance, les flux autorisés et les angles morts de l'audit, écrits noir sur blanc, permettent de vérifier que la réalité correspond à l'intention, et de répondre aux questionnaires sans improviser.
• Elle sert l'attaquant. Un schéma complet, avec les plages d'adresses, les noms des ressources et la liste de ce qui n'est pas journalisé, est une carte. Le dossier vit dans un dépôt privé, aux accès revus comme le reste ; la version transmise au client peut omettre les détails dont il n'a pas besoin.
• Les composants non doublés sont aussi des cibles. Une passerelle VPN unique est un point où une attaque par déni de service coupe la métropole ; c'est acceptable tant que le flux n'est pas critique, et c'est écrit.

En production

• Automatiser. Tout ce cours a été fait à la main, pour la compréhension. La suite logique est de décrire cette architecture en Terraform ou OpenTofu, avec les projets, les réseaux, les ACL, les groupes, la base et les politiques IAM ; le dossier se simplifie alors, puisque le code en devient la référence détaillée.
• Passer à Kapsule ? Le groupe d'instances qui fait tourner un conteneur est un orchestrateur rudimentaire. Avec plusieurs services, des déploiements fréquents et une équipe déjà outillée (Lyneko exploite ses propres applications sur le cluster Kapsule lyneko-apps, avec Argo CD), Kubernetes devient rentable : déploiements progressifs, autoscaling par service, secrets par External Secrets. Le cours Kapsule : Kubernetes managé chez Scaleway reprendra l'architecture sous cette forme ; les briques de ce cours (VPC, base, Redis, Object Storage, Cockpit, Audit Trail) restent les mêmes.
• Tester la panne. Le test de perte de zone se planifie, en préproduction d'abord, puis en production en heures ouvrées : arrêter le groupe de fr-par-1, observer, mesurer le temps de retour, mettre à jour le runbook.
• Revoir le coût chaque mois. La consommation réelle (cours précédent, leçon 8) se compare à l'estimation ; un écart de plus de 20 % mérite une explication écrite.

Exercices

1. Analyse de perte de zone (niveau 300). L'équipe propose de déplacer la base en mode single_zone pour réduire la facture, et de passer à un seul groupe d'instances de quatre machines en fr-par-2. Reprenez le tableau de la perte de zone pour fr-par-1, puis pour fr-par-2, et rédigez l'avis à joindre au dossier.

2. Compléter l'estimation (niveau 300). Relevez, avec la commande du catalogue ou les pages de tarifs, les prix manquants du tableau d'estimation (base en haute disponibilité multizone avec un réplica, Redis, Edge Services), datez-les, et calculez le total mensuel. Quelle ligne est la deuxième plus importante ?

3. Un runbook de plus (niveau 300). Écrivez, au format de la leçon, le runbook « retour arrière d'un déploiement » pour les groupes d'instances, en partant de l'alerte 5xx de la leçon 14.

Récapitulatif

• Une architecture de référence associe chaque besoin à un choix argumenté, avec ce qui a été écarté, et se tient à jour comme du code.
• La tenue à la perte d'une zone se vérifie composant par composant : zonal (répartiteur, groupes d'instances, Redis, passerelles), régional (réseaux, base, Object Storage, secrets), global (Edge Services, IAM). Les composants non doublés le sont par choix écrit.
• La stabilité statique (capacité déjà en place dans chaque zone) évite de dépendre du plan de contrôle pendant l'incident.
• Une estimation de coût est ligne par ligne, datée et reproductible ; le catalogue de produits se lit par l'API pour la mettre à jour.
• L'empreinte environnementale se mesure par projet, en kg d'équivalent CO2 et en m³ d'eau, sur les produits intégrés seulement : c'est un minorant.
• La liste de contrôle et les runbooks transforment le cours en procédures ; l'inventaire révèle l'écart entre l'intention et la réalité.
• La suite : décrire tout cela en code (Terraform), et, quand les services se multiplient, passer à Kapsule.

Pour aller plus loin

• Le modèle arc42, pour un dossier d'architecture plus complet.
• Le livre Site Reliability Engineering de Google (introduction et chapitre sur la gestion des incidents), pour l'usage des procédures écrites.
• Les piliers fiabilité et durabilité du Well-Architected Framework d'AWS : les principes valent pour tout fournisseur.
• Le référentiel de l'ADEME sur l'évaluation environnementale des services cloud, pour comprendre les chiffres de l'empreinte.
• Le cours Terraform et OpenTofu : les fondamentaux, qui fera de cette architecture du code.