---
# Couches de déploiement — l'ordre de reconstruction de l'écosystème.
#
# Registre central (comme docs/dependances-groupes.yml). L'orchestrateur
# (scripts/orchestrer.py → make site) trie les groupes déployables par COUCHE
# (clé primaire, ordre ci-dessous), puis AFFINE l'ordre INTRA-couche avec le
# graphe des dépendances (dependances-groupes.yml, ex. dovecot avant postfix).
#
# Règle : chaque groupe déployable (= un playbooks/groupes/<groupe>.yml
# opérationnel) DOIT figurer dans exactement une couche. Le générateur refuse
# sinon (garde anti-dérive : un nouveau rôle non classé casse la génération).
#
# Règle de cohérence : un prérequis (dependances-groupes.yml) doit vivre dans
# une couche <= celle du groupe qui en dépend. Une arête « en arrière » (un
# groupe qui requiert un groupe d'une couche PLUS TARDIVE) = mauvaise
# classification → le générateur refuse.
#
# L'ordre des couches ci-dessous EST l'ordre de déploiement.
couches:
  - nom: socle
    raison: "Base du système : /etc/hosts (résolution interne au bootstrap), paquets, durcissement. Tout en dépend."
    groupes:
      - serveur_debian
      - serveur_durci

  - nom: pki_racine
    raison: "L'autorité de certification interne (step_ca) : la racine de confiance de tous les flux TLS est-ouest."
    groupes:
      - serveur_step_ca

  - nom: pki_client
    raison: "Émission des certificats et pose de la racine (root_ca 0644) sur chaque nœud. Prérequis de TOUT service qui sert ou vérifie du TLS."
    groupes:
      - client_pki

  - nom: observabilite
    raison: >-
      VOIR AVANT DE CONSTRUIRE. La mesure vient juste après la PKI, donc avant tout ce
      qu'elle devra surveiller — et non après, comme si l'on n'allumait la lumière qu'une
      fois la maison finie. Une reconstruction depuis zéro est précisément le moment où
      l'on a le plus besoin de voir ce qui se passe : chaque rôle déployé ensuite l'est
      sous l'œil de la supervision, et une unité qui casse se voit à la minute plutôt qu'à
      la fin. `obs` ne dépend de rien ; `serveur_icinga` n'exige que PostgreSQL, qui
      n'exige rien lui-même. Ce qui reste plus tard, c'est la CONSOLE (`icingaweb2`,
      `oauth2_proxy`), qui demande LDAP et Keycloak — l'interface humaine peut attendre,
      la mesure non.
    groupes:
      - serveur_postgresql
      - serveur_prometheus
      - serveur_loki
      - serveur_grafana
      - serveur_icinga

  - nom: agents_supervision
    raison: >-
      Les agents qui FONT voir, poses juste apres leurs serveurs. Deplacer la supervision
      en amont sans eux n'aurait rien change : ce sont eux qui rapportent. Des cette
      couche, chaque hote expedie ses metriques, ses journaux, et l'etat de ses unites
      systemd — donc tout ce qui se deploie apres est mesure pendant qu'on le construit.
    groupes:
      - client_metrique
      - client_journal
      - client_sante

  - nom: services
    raison: "Les services d'infrastructure dont dépendent les applications : bases, annuaire, DNS, cache, métriques, journaux, edge, courriel."
    groupes:
      - serveur_openldap
      - serveur_powerdns
      # Le resolveur du tenant vient APRES son autoritatif : il le prend en stub-zone,
      # et sa validation exige que la zone souveraine reponde deja.
      - serveur_resolveur
      - serveur_redis
      - serveur_nginx
      - serveur_rspamd
      - serveur_dovecot
      - serveur_postfix
      - serveur_backup
      # La source d'artefacts vient AVANT ceux qui installent des paquets — c'est tout
      # son objet. Placee plus tard, elle serait remplie apres avoir servi.
      - serveur_artefacts
      # LA RACINE DE LA CHAINE DE CACHES, et elle appartient au SITE, pas au tenant :
      #     VM du tenant -> cache du tenant -> cache du SITE -> Debian
      # Classee ici pour que son ordre soit dit, mais elle ne se deploie pas dans le meme
      # mouvement : elle vit dans l'underlay de l'hebergeur et se joint par
      # `scripts/site_inventaire.py`. Un tenant ne la deploie jamais — il la CONSOMME.
      - serveur_cache_site
      # La forge du genome, meme nature : elle vit dans l'underlay de
      # l'hebergeur et un tenant la CONSOMME sans jamais la deployer.
      - serveur_forge_site
      # Le resolveur du site, meme nature : prete aux locataires pendant leur jeunesse.
      - serveur_resolveur_site
      # Le depot de sauvegarde du site, meme nature : il recoit l'etat des locataires.
      - serveur_backup_site
      # Le DNS public du site vient APRES les services : il tire les zones que les
      # autoritatifs des locataires ecrivent, et n'a rien a servir avant eux.
      - serveur_dns_public
  - nom: apps
    raison: "Les applications métier, qui consomment les services (base, SSO, courriel, edge)."
    groupes:
      - serveur_keycloak
      - serveur_oauth2_proxy
      - serveur_forgejo
      - serveur_icingaweb2
      - serveur_collabora
      - serveur_nextcloud
      - serveur_web_frontal
      - serveur_web_dorsal
      # Le poste d'exploitation vient APRES la forge : il clone le genome depuis
      # elle. Le placer plus tot le laisserait sans source.
      - serveur_ops
      # Le runner de TENANT vient APRES le poste : il suppose les depots clones et le lien
      # `instance` pose. Il n'ajoute qu'un pouvoir -- celui de CONFIGURER cet ecosysteme,
      # par sa voute deposee chiffree.
      - serveur_ops_tenant
      # Le runner de SITE vient APRES le runner de tenant : il suppose les depots
      # clones. Il n'ajoute qu'un pouvoir -- celui de materialiser sur la fabric.
      - serveur_ops_site

  - nom: agents
    raison: "Les intégrations clientes qui expédient vers les services centraux (métriques, journaux, courriel, sauvegardes, résolution locale). Déployées en dernier, quand leurs cibles sont debout."
    groupes:
      - client_smtp
      - client_backup
      - client_resolveur
      - client_artefacts