---
# Politique d'integration. Voir roles/client_metrique/meta/integration.yml pour le
# raisonnement, et docs/decisions-architecture.md (D-33).
integration:
  # DE QUI CETTE INTEGRATION DEPEND, ET POURQUOI L'ORDRE COMPTE.
  #
  # L'AC doit exister ET repondre avant qu'un hote lui demande un certificat. Sur l'hote
  # qui la porte, le role recharge `step-ca` en reemettant son propre certificat :
  # pendant cette fenetre, elle ne repond plus. Mesure du 2026-08-25 : quatre clients en
  # echec simultane, message `TLS handshake timeout` — qui accuse le reseau, pas l'ordre.
  #
  # Le playbook de groupe applique l'hote qui porte ce serveur AVANT ceux qui s'y
  # adressent, et la preuve P44 refuse tout ecart entre cette declaration et lui.
  serveur: serveur_step_ca
  universelle: true
  raison: >-
    Tout hote fait confiance a l'AC interne et porte un certificat : c'est le
    prerequis du chiffrement est-ouest (voir docs/zero-confiance.md). Un hote sans
    certificat ne peut ni presenter ni verifier — il retombe en clair en silence.
  # AUCUNE exemption, et l'autorite non plus. Elle ne s'ENROLE pas aupres d'elle-meme —
  # sa racine est deja sur son disque — mais elle a besoin de CERTIFICATS comme tout le
  # monde : sans eux, ses propres services restent en clair et `client_metrique` echoue
  # sur la seule machine qu'on ne peut pas se permettre de ne pas mesurer.
  #
  # Le role distingue donc les deux : bootstrap pour les autres, EMISSION LOCALE sur
  # l'AC (voir tasks/main.yml). Exempter l'hote entier confondait « ne pas s'enroler »
  # avec « ne pas avoir de certificat », et laissait un angle mort au coeur du systeme.
  # Constate le 2026-08-06 : `client_pki` exemptait l'AC, `client_metrique` exigeait un
  # certificat, et les deux politiques avaient raison separement.