Set-OPS/CHANGELOG.md

# CHANGELOG — Set-OPS

## 2026-06-24

### Modifié
- **Consolidation minimale post-diagnostic (ménage documentaire, sans risque).** Suite à une relecture à froid « auteur » de l'état réel du dépôt. (1) **En-tête généré rafraîchi** : `instance/inventories/production/hosts.yml` pointait encore vers l'ancienne source `docs/` ; régénéré via `instancier-appliquer` (diff sémantique **vide** — contenu inchangé, seul l'en-tête a bougé ; commité côté instance `OPS-Chezlepro`). (2) **`docs/catalogue-services.md`** : nouvelle section **« État d'implémentation des rôles »** qui distingue sans ambiguïté les rôles **implémentés** (validés *en tant que code*, **non éprouvés en prod**), les **échafaudages** (playbooks-ancres `debug` sans rôle : `serveur_nextcloud`, `serveur_collabora`, `client_supervision`, `serveur_web_frontal`, `serveur_web_dorsal`) et les **rôles-catégories inertes** (`applications`, `backup`, `database`, `identity`, `monitoring`, `proxmox`, `storage`, `web` — vestiges d'un regroupement par catégorie abandonné, l'architecture réelle étant plate `serveur_*`/`client_*`) ; colonnes « Rôle futur » → « Rôle ». (3) **`docs/vm-lifecycle.md` §8** : flux de déploiement réaligné sur le plan (`instancier-appliquer` puis `deployer`) au lieu de la commande supplantée `hote-ajouter`. Vérifié : `make verifier` (exit 0), `ansible-lint` 0 échec. **Non touché à dessein** : les références `instance/inventories/lab/` des docs de template sont **correctes** (contexte golden template, distinct de `production`) ; le bas du `README.md` (« Premier chantier »/« Principe ») est daté mais **exact** (template = socle), donc laissé tel quel pour éviter le churn.
- **`creer-vm` enfin piloté par le plan — couture « inventaire → création VM » fermée (étape 4 du diagnostic).** `make creer-vm HOTE=<hôte>` ne prend plus qu'**un argument** : il **lit VMID/IP/CIDR/passerelle/VLAN/stockage/disque/nœud directement dans l'inventaire généré** (comme `deployer` lit ses groupes) au lieu de les redemander à la main, et **n'écrit plus** dans l'inventaire (l'appel à `hote-ajouter` est supprimé — l'hôte est déjà présent via le plan). Repli sur le nœud par défaut de `config` si `proxmox_noeud` absent. Les 3 cibles legacy `hote-ajouter` / `hote-planifier` / `hote-groupes` (qui éditaient l'inventaire généré à la main — anti-pattern) sont **neutralisées** : refus explicite renvoyant vers `serveurs.yml` + `instancier-appliquer`. `aide` et docs (`README`, `QUICKSTART`, `procedure-template-debian13-proxmox`) alignées sur `creer-vm HOTE=…`. La chaîne déclarative est désormais **continue** : `plan → instancier-appliquer → creer-vm HOTE → (activer) → deployer HOTE`. Activation laissée **manuelle** (édit du plan, par décision). Vérifié : `make verifier` exit 0 (dont 4 tests unitaires), extraction testée sur l'inventaire réel (`data-01` avec nœud, `collab-01` sans nœud → repli), chemins de refus (HOTE vide, hôte absent, cibles legacy) exit 2. *(Clonage réel non exécuté : exige Proxmox — c'est la preuve VM, étape suivante.)*
- **Neutralisation complète pour partage public (« 100 % neutre »).** Préparation au don public du moteur : suppression de **toute** trace Chezlepro de l'**outil** (rôles, scripts, docs publiques, exemples, LICENSE) — prouvée par scan exhaustif (`git grep` revient **vide** pour `chezlepro`, pour `asgard`/`TrueNAS`, et pour le supernet réel `10.1.x`). Corrigés au passage **5 défauts de généricité fonctionnels** qui auraient déployé du Chezlepro chez tout hébergeur : `roles/motd/templates/motd.j2` (« Système Chezlepro » → `{{ domaine_interne | default('Set-OPS') }}`), `serveur_forgejo` (`APP_NAME`), `serveur_openldap` (organisation par défaut), `serveur_step_ca` (nom d'AC par défaut), et surtout les **IP réelles codées en dur dans les `defaults`** de plusieurs rôles (`db_host`, `loki_url`, `reseaux_autorises` → plage d'exemple `10.0.x`). Noms de tâches/playbooks et exemples de README généricisés ; marqueurs de fichiers gérés alignés sur `setops` (READMEs en retard) ; placeholder GUI neutralisé. **LICENSE : copyright → Alliance Boréale.** Fichiers **mainteneur** (`AGENTS.md`, `CLAUDE.md`, `SOLUTION.md`, doc Codex) et `CHANGELOG` conservés (couche gouvernance/historique — peuvent nommer Chezlepro, par décision). L'instance `OPS-Chezlepro` **surcharge déjà** ses vraies valeurs de topologie dans ses `group_vars` : la séparation moteur/instance tient, le changement des `defaults` ne casse pas Chezlepro (seule `client_journal_loki_url` reste à surcharger côté instance). Vérifié : `make verifier` exit 0 (4 tests), 42 fichiers, scans de fuite **vides**.

### Ajouté
- **Sous-commande `inventory_host.py parametres-proxmox --hote X`** : émet, machine-lisible (`SETOPS_*='valeur'`), les paramètres de clonage Proxmox d'un hôte lus dans l'inventaire généré ; refuse si l'hôte est absent ou s'il manque un champ requis (VMID/IP/CIDR/passerelle/VLAN). Consommée par `make creer-vm`. **Premier test stdlib du dépôt** `scripts/tests/test_inventory_host.py` (sans pytest) + cible **`make test`**, câblée dans `make verifier`.

## 2026-06-23

### Corrigé
- **Robustesse du moteur pour une instance hors dépôt (révélé par une instance d'essai agnostique).** Les scripts affichaient des chemins via `Path.relative_to(RACINE)`, qui **lève** quand l'instance est en dehors du dépôt (`SETOPS_INSTANCE` pointant un chemin externe, ex. `../OPS-laPreuve`). Remplacé par `os.path.relpath` (`scripts/instancier.py`, `inventory_gui.py`, `config_proxmox.py`). Le moteur génère désormais correctement depuis n'importe quel emplacement d'instance — agnosticité prouvée (instance `lapreuve.local` / `10.9.0.0/16` : inventaire distinct, **zéro fuite Chezlepro**).

### Modifié
- **Dette doc soldée après le découpage moteur/instance.** Rafraîchissement des chemins dans les docs secondaires, README de rôles, messages et docstrings : `inventories/...` → `instance/inventories/...`, `docs/<plan>.yml` → `instance/plan/<plan>.yml`. Correction au passage de chemins de playbooks périmés (préexistants) dans `CLAUDE.md`/`SOLUTION.md` : `playbooks/vm_templates/debian13_proxmox_prepare|verify|cleanup.yml` → `playbooks/modeles_vm/debian13_proxmox_preparer|verifier|nettoyer.yml`, et `confirm_template_cleanup` → `template_cleanup_confirm`. Validé : diff vide, `ansible-lint` 0 échec, `make inventaire-verifier`.
- **Découpage moteur/instance — Phase 3 (modèle A) : deux dépôts.** Le contenu de `instance/` (plan + inventaire) part dans un **dépôt d'instance dédié** (`OPS-Chezlepro` pour Chezlepro, sur la forge). `Set-OPS` devient le **moteur pur** (rôles, scripts, playbooks, guides, exemples). L'instance est **montée via un symlink** `instance -> ../OPS-Chezlepro` (gitignoré) : le défaut `SETOPS_INSTANCE=instance` la résout sans configuration. Le moteur lit le plan et **régénère `hosts.yml` dans le dépôt d'instance**. `.ansible-lint` exclut `instance/`. Validé : diff vide, `ansible-lint` 0 échec, `make inventaire-verifier`, `instancier-appliquer`. **Modèle A (dépôts frères)** retenu jusqu'à preuve du concept ; le **modèle B (moteur en sous-module)** pour la meute viendra ensuite. Le moteur ne contient plus aucune donnée Chezlepro.
- **Découpage moteur/instance — Phase 2b : sortir l'inventaire dans `instance/inventories/`.** L'inventaire (hôtes générés, `group_vars`, vault) quitte `inventories/` pour `instance/inventories/`. Suivent : `ansible.cfg`, le `Makefile` (`export SETOPS_INSTANCE ?= instance`, chemins dérivés), les scripts (`INSTANCE / "inventories/..."`), `config_proxmox.py`, `.gitignore`. Les docs primaires (`AGENTS.md`, `README.md`, `docs/plan-et-generation.md`, `docs/architecture-set-ops.md`) reflètent le layout `instance/`. Non destructif : diff vide, `ansible-lint` 0 échec, `make inventaire-verifier` OK. *(Docs secondaires à rafraîchir ; Phase 3 : deux dépôts.)*
- **Découpage moteur/instance — Phase 2a : sortir le plan dans `instance/plan/`.** Les 5 registres (`serveurs`, `applications`, `bases-donnees`, `domaines`, `nomenclature`) quittent `docs/` pour `instance/plan/`. Les scripts les localisent via **`SETOPS_INSTANCE`** (variable d'env, défaut `<dépôt>/instance`) ; les rôles/playbooks via **`setops_plan_dir`** (group_vars d'instance). `docs/` ne garde que les guides `.md` + `dependances-groupes.yml` (moteur). `.ansible-lint` exclut `instance/plan/` (registres de données). Non destructif : diff vide, `ansible-lint` 0 échec, `include_vars` via `setops_plan_dir` testé. *(Phase 2b : sortir l'inventaire ; Phase 3 : deux dépôts.)*
- **Découpage moteur/instance — Phase 1b : neutraliser la marque `chezlepro`.** Les noms de fichiers gérés par les rôles (`99-chezlepro.conf`, `chezlepro_filter`, `chezlepro-bind.conf`, `/etc/redis/chezlepro.conf`, etc.) et les 14 templates correspondants passent à la marque neutre du moteur **`setops`** (`git mv` + références `src`/`dest`). Un loup ne déploie plus de fichiers marqués « chezlepro ». Cohérence `src ↔ template` vérifiée, `ansible-lint` 0 échec, diff vide. (Les README gardent leurs exemples ; génériciser plus tard.)
- **Découpage moteur/instance — Phase 1 : délier les rôles du domaine Chezlepro.** Introduction d'une variable d'identité d'instance **`domaine_interne`** (dans `inventories/*/group_vars/all.yml`). Les 13 rôles qui codaient `chezlepro.internal` en dur (zones DNS, FQDN, relais SMTP, AC, etc.) utilisent désormais `{{ domaine_interne }}` ; le `base_dn` LDAP et le domaine court sont **dérivés** (`dc={{ domaine_interne.split('.') | join(',dc=') }}` → `dc=chezlepro,dc=internal`, ou `dc=acme,dc=local` pour un autre loup). Comportement **identique** pour Chezlepro (qui pose `domaine_interne: chezlepro.internal`), mais le moteur devient générique — première brique pour partager l'outil à la meute (`docs/positionnement.md`). Ajout d'`exemples/instance.exemple.yml`. Non destructif : diff de génération vide, `ansible-lint` 0 échec. *(La marque `chezlepro` sur les noms de fichiers gérés — `99-chezlepro.conf`, `chezlepro_filter` — sera neutralisée en Phase 1b ; sortie du plan en Phase 2 ; deux dépôts en Phase 3.)*

### Ajouté
- **Principe gravé : Set-OPS exploitable par un humain SANS IA.** Ajouté comme principe #10 d'`AGENTS.md` (règle pour le mainteneur : ne jamais introduire de fonctionnalité qui exige une IA) **et** en face humaine dans le `README` (survit à la livraison sans les fichiers IA). La doc / `make` / GUI sont l'interface primaire et complète ; l'IA n'assiste que le mainteneur, jamais l'utilisateur. `AGENTS.md`/`CLAUDE.md` ne font pas partie de l'outil livré. (Souveraineté jusqu'au bout : pas de dépendance aux géants remplacée par une dépendance à une IA.)
- **Accueil d'un nouvel hébergeur (parcours à froid).** Nouveau **`QUICKSTART.md`** : le chemin linéaire « de zéro à ton écosystème déployé sur ta grappe Proxmox » (cloner le moteur → choisir un modèle → créer son instance + symlink → renseigner → `make config` + secrets → **construire le golden template une fois** → `instancier` → `cloner-vm` → activer + `deployer`), honnête sur les prérequis et le seam création-de-VM. `README.md` réorienté : « moteur générique qu'un hébergeur peut utiliser » (plus « infra de Chezlepro »), avec pointeur QUICKSTART. **Garde-fou `_instance-requise`** dans le Makefile : si l'instance manque, message utile (liste des modèles + QUICKSTART) au lieu d'un faux « valide » silencieux, sur `instancier`/`instancier-appliquer`/`inventaire-ui`/`inventaire-verifier`/`deployer`. `make aide` route vers QUICKSTART.
- **Catalogue de modèles d'écosystèmes prêts à déployer (`exemples/modeles/`).** Un hébergeur copie le modèle qui colle à son offre, le renseigne à ses couleurs (ou celles de son client) et instancie — plus besoin de démonstrateur. Structure **socle + modules + presets** : un socle souverain (DNS interne, AC/PKI, edge TLS, relais courriel) + des modules (web, identité, forge, observabilité, collaboration). Modèles livrés et validés (chacun génère un écosystème distinct, **zéro fuite Chezlepro**, IPs `10.10.x`) : **`socle`** (4 VM), **`presence-web`** (7), **`forge`** (6), **`identite`** (LDAP+Keycloak, 6), **`observabilite`** (Prometheus/Loki/Grafana+Icinga, 7), **`integral`** (11). **`collaboration`** (Nextcloud/Collabora) reste à construire (rôles non implémentés). `.ansible-lint` exclut `exemples/`. Remplace l'instance d'essai jetable.
- **`docs/positionnement.md` — décision de positionnement vs l'existant.** Acte que le cœur de Set-OPS (plan déclaratif → génération d'inventaire) recoupe **NetBox/Nautobot** (+ `nb_inventory`), le GUI d'exécution recoupe **AWX/Semaphore**, le « la définition instancie la flotte » recoupe **NixOS+Colmena / Terraform**, et le modèle application-pivot recoupe **Backstage**. Décision en vigueur : on **garde** le plan de contrôle maison (souverain, bien dimensionné pour ~13 VM) mais on **gèle son périmètre** ; seuils explicites d'adoption de l'outil mûr (RBAC/audit → AWX ; IPAM/source de vérité partagée → NetBox). Règle ancrée dans `AGENTS.md`.
- **Documentation — passe complète (le dépôt « dit ce qu'il fait »).** Nouveau guide central **`docs/plan-et-generation.md`** : le modèle (entités + liens), les registres et leurs schémas, la référence des commandes `make`/CLI et des vues GUI, le flux « éditer le plan → `instancier` → appliquer », les garde-fous. `AGENTS.md` gagne la section « Le plan et la génération de l'inventaire » (règle d'or : `hosts.yml` est généré, ne pas l'éditer). `README.md` : section « Le plan : on édite, l'inventaire se génère » + remplacement du flux legacy `hote-planifier`/`ajouter` par le flux par le plan. Rafraîchissement de `docs/architecture-set-ops.md` (entités du plan), `docs/nomenclature-vm.md` et `docs/catalogue-services.md` ; correction de la terminologie **domaine → fonction** dans la prose (collision avec le DNS levée jusque dans la doc).

### Modifié
- **Noms de rôles et playbooks au singulier.** `serveurs_*` → `serveur_*`, `clients_*` → `client_*`, et suffixes pluriels au singulier (`serveur_web_dorsal`/`serveur_web_frontal`, `client_metrique`, `client_journal`). Renommage par **tokens exacts** : répertoires de rôles, playbooks de groupes, `group_vars`, **variables internes des rôles** (`serveur_nginx_*`, conformité `ansible-lint`), groupes du plan (`applications.yml`, `serveurs.yml: integrations`), constantes de code (`GROUPES_OPERATIONNELS_PREFIXES`, sockle), docs. Les faux-amis sont **préservés** (`serveurs_bd` clé du registre BD, `scripts/serveurs.py`, fonctions Python). Les groupes d'état restent au pluriel (`hotes_actifs`/`hotes_planifies`/`modeles_vm`). Validé : `ansible-lint` 0 échec (0 var-naming), **diff vide** de la génération, `node --check`, tous les registres. Ajout de `.ansible-lint` excluant `docs/` (registres de données, pas du contenu Ansible).
- **Rework GUI : l'UI édite le plan (branche `bascule-inventaire-genere`).** La vue **Serveurs** devient éditable (fonction / état / placement Proxmox / intégrations `clients_*`, avec VMID/IP/VLAN dérivés en direct), avec « + Serveur », « Sauvegarder les serveurs » (`POST /api/serveurs`) et **« Appliquer le plan → hosts.yml »** (`POST /api/instancier` → `instancier appliquer`). La vue **Inventaire** passe en **lecture seule** : bandeau explicite + l'écriture directe (`POST /api/inventaire`) est refusée (409) puisque `hosts.yml` est désormais généré. Tout passe par le plan (`serveurs.yml` / `applications.yml`) puis « Appliquer ». Garde-fou JS `node --check` exécuté à chaque étape.
- **Bascule méta-classe (branche `bascule-inventaire-genere`).** `make instancier-appliquer` régénère `inventories/production/hosts.yml` **depuis le plan** (refuse si le diff n'est pas vide, sauf `FORCE=1` pour un changement intentionnel ; git sert de filet). Effectuée avec diff vide vérifié : `hosts.yml` est désormais un artefact généré, sémantiquement identique à l'ancien (vérifié par `make inventaire-verifier` complet + chargement GUI). À ce stade le GUI édite encore `hosts.yml` directement (rework à venir) : éditer le **plan** (`serveurs.yml`/`applications.yml`) puis `make instancier-appliquer`.
- **Phase 2 (début) — vue Chaîne holistique.** Dans `make inventaire-ui`, la vue Chaîne montre désormais, pour chaque application d'un hôte, l'ensemble de ses liens : `expose` (FQDN publics), `requiert` (applications dont elle dépend) et ses bases (DSN), plus son port. On voit d'un coup d'œil comment VM, applications, bases et domaines s'articulent.
- **Phase 1b — clarté de nommage.** La clé `domaines:` de `docs/nomenclature.yml` (familles fonctionnelles : `infra-pki`, `web-frontal`…) est renommée **`fonctions:`** pour lever la collision avec les domaines DNS (`docs/domaines.yml`). L'auto-proposition du GUI suit (`fonctionDe` / `infoFonction`, `nomenclature.fonctions`, libellés « Fonction inconnue… », placeholder `fonction-NN`). Aucun rôle ni inventaire impacté : la nomenclature n'est consommée qu'au moment de la planification.
- **Refonte « application-hub », Phase 1 — les liens deviennent explicites (inventaire inchangé, zéro régression).** L'application porte désormais tous ses liens : `groupe` (capacité/rôle), `hote` (VM), `port`, **`requiert`** (autres applications dont elle dépend) et **`expose`** (FQDN publics qui la publient). L'**exposition DNS quitte `docs/domaines.yml`** (le bloc `exposition` est retiré) et vit sur l'application via `expose` ; `docs/domaines.yml` ne décrit plus que les zones (autorité, edge, secondaires, dnssec, mail). `serveurs_nginx` dérive ses vhosts des **applications** (`expose` + edge du domaine), résolvant `application → hôte → IP` (rôle + `expositions.conf.j2` réécrits). Nouvelle règle partagée `expositions_des_applications` (+ `domaine_parent`) dans `inventory_rules.py`, exposée à Ansible par le filter plugin ; `valider_applications` valide `requiert` (applis connues), `expose` (domaine parent déclaré) et `port`. CLI (`applications.py --port/--requiert/--expose`, `domaines.py` affiche les expositions dérivées) et **GUI** (champs Port/Requiert/Expose sur la fiche Application, persistés) suivent ; l'API expose aussi le registre des domaines. Le groupe n'est plus une cible de liaison, seulement une capacité. *(Renommage `nomenclature.domaines:` → `fonctions:` reporté en Phase 1b ; génération de l'inventaire depuis le plan en Phase 3.)*

### Ajouté
- **Phase 3 — générateur d'inventaire depuis le plan (non destructif ; diff vide prouvé).** `make instancier` (`scripts/instancier.py`) génère `inventories/production/hosts.genere.yml` (gitignoré, artefact) depuis le plan — `docs/serveurs.yml` + `docs/applications.yml` + `docs/nomenclature.yml` — puis **compare sémantiquement** (via `ansible-inventory --list`, formatage ignoré) avec l'inventaire actuel : host vars dérivés (IP/VMID/VLAN/passerelle de la nomenclature, placement/taille du registre serveurs), groupes dérivés (socle `debian`/`durcis` + services depuis les applications + intégrations `clients_*` + état). Prérequis posés : `make applications-bootstrap` (services `serveurs_*` → applications) et `serveurs.yml` enrichi d'`integrations` (les `clients_*` par VM, capturés au bootstrap). **Résultat : DIFF VIDE — le plan reproduit exactement les 13 hôtes de l'inventaire.** La bascule (rendre `hosts.yml` généré et faire éditer le plan par l'UI) reste **non effectuée** : elle attend une validation explicite.
- **Phase 2 — le serveur (VM) entre dans le plan (lecture seule, l'inventaire reste autorité).** Nouveau registre `docs/serveurs.yml` (VM = `fonction` + `etat` + placement/dimensionnement Proxmox), **bootstrapé depuis l'inventaire** (`make serveurs-bootstrap`). La dérivation nomenclature (fonction + rang → VMID/IP/VLAN/passerelle) est portée en Python (`deriver_nomenclature`, source unique, miroir de l'auto-proposition du GUI) et la **réconciliation** compare le dérivé aux valeurs de l'inventaire (`reconcilier_serveur`). CLI `scripts/serveurs.py` (`lister`/`verifier`/`bootstrap`) + cibles `make serveurs` / `serveurs-verifier` / `serveurs-bootstrap`, intégré à `make inventaire-verifier`. GUI : vue **Serveurs** (lecture seule) affichant le plan + valeurs dérivées + statut de réconciliation. Bootstrap initial : **13 serveurs, tous réconciliés** (le dérivé reproduit exactement l'inventaire → la génération de Phase 3 pourra viser un diff vide).
- **Application = entité de première classe** (une VM peut porter plusieurs applications). Nouveau registre `docs/applications.yml` (`application → groupe, hote`). Les bases se lient via `consommateur` + **`portee`** (`application` | `groupe` | `hote`, défaut `groupe`) dans `docs/bases-donnees.yml` : une application `A` (groupe `G`, hôte `H`) reçoit les bases où `(portee=application ET consommateur=A) OU (portee=groupe ET consommateur=G) OU (portee=hote ET consommateur=H)` — plusieurs DSN par application. Résolution + validation partagées dans `inventory_rules.py` (`charger_applications`, `valider_applications`, `applications_de_hote`, `bases_de_application`, `PORTEES_BD` ; `valider_bases` croise désormais `portee=application` avec le registre des applications). CLI `scripts/applications.py` (`lister`/`verifier`/`ajouter`/`retirer`) + `scripts/bases_donnees.py --portee` ; cibles `make applications` / `applications-verifier` ; validation intégrée dans `make inventaire-verifier`. GUI : vue **Applications** (CRUD), sélecteur de **portée** + consommateur dynamique (groupe/hôte/application) dans la vue Bases, et **vue Chaîne par application** (DSN résolus par hôte). Filter plugin `filter_plugins/registres.py` exposant la **même** règle de résolution à Ansible (source unique) ; les playbooks `serveurs_web_dorsaux` / `serveurs_web_frontaux` itèrent désormais sur les applications de l'hôte et résolvent leurs bases (scaffold ; le déploiement applicatif réel s'y insère). Les services en grappe (keycloak/icingadb/forgejo) restent en `portee: groupe` (inchangés).
- Vhosts `serveurs_nginx` **dérivés du registre `docs/domaines.yml`** (bloc `exposition`) : pour chaque exposition `web` ciblant cet edge, un vhost est généré (`expositions.conf.j2`) avec amont = `amont` explicite, sinon `http://<IP interne de la cible>:<port>` résolu depuis l'inventaire ; une exposition non résolvable (cible sans hôte actif, ou sans port) est listée mais non publiée. Variables `serveurs_nginx_groupe` (edge ciblé) et `serveurs_nginx_publier_expositions` (bascule). Les sites déclarés à la main continuent de coexister. Ajout du `port: 3000` à l'exposition `forge`.

## 2026-06-22

### Ajouté
- Registre déclaratif des domaines publics `docs/domaines.yml` (publication externe des hostnames), symétrique de `docs/bases-donnees.yml`. Modèle d'autorité retenu : **primaire caché + secondaires** (PowerDNS backend PostgreSQL + API non exposé, secondaires publics via AXFR/TSIG). Bloc **`exposition`** = binding `nom public → service interne (cible) → edge`, destiné à trois consommateurs (génération de zone publique, vhosts `serveurs_nginx`, noms à certifier ACME). Validation partagée dans `inventory_rules.py` (`charger_domaines`, `valider_domaines`, `fqdn_exposition`, `expositions_du_groupe` ; autorités connues `primaire-cache|auto-heberge|delegue`, `edge` requis, FQDN uniques). CLI miroir `scripts/domaines.py` (`lister`/`verifier`) + cibles `make domaines` / `make domaines-verifier`, et validation intégrée dans `make inventaire-verifier`. Première entrée réelle : `forge.alliance-boreale.ca → serveurs_forgejo` (DNSSEC, secondaires et enregistrements mail laissés à renseigner).
- Formalisation de l'identité du dépôt : `AGENTS.md` (nouvelle section « Mission et identité ») et `README.md` (section « Mission ») actent que `Set-OPS` **définit et construit l'écosystème numérique souverain de Chezlepro Inc.** — piliers (identité, confiance, nommage/adressage, données, communication, observabilité/supervision, applicatif), propriétés (souverain, déclaratif/convergent) et limites honnêtes (pas d'auto-remédiation ; en grande partie défini/validé avant déploiement réel). Le template Debian 13 reste la fondation, pas la finalité.
- Gestion des bases de données dans la GUI et la CLI : vue « Bases » de `make inventaire-ui` présentant les serveurs de BD, les bases applicatives et leurs **chaînes de connexion** (mot de passe masqué), avec gestion complète (ajout / édition / retrait) et endpoint `POST /api/bases` (validé, jeton). CLI `scripts/bases_donnees.py` (`lister` / `verifier` / `ajouter-serveur` / `ajouter-base` / `retirer-*`) + cibles `make bases` et `make bases-verifier`. Le registre est désormais validé dans `make inventaire-verifier`. GUI et CLI partagent les mêmes règles (`inventory_rules`).
- Rôle `serveurs_forgejo` (forge Git, Phase 5) : binaire officiel Forgejo (version épinglée + lien symbolique), utilisateur `git`, **base PostgreSQL via le registre** (4e consommateur, entrée `forgejo`), publication derrière `serveurs_nginx` (`HTTP_ADDR=127.0.0.1`, `INSTALL_LOCK`), secrets (BD + `SECRET_KEY` + `INTERNAL_TOKEN` + admin) via Vault, mailer vers `serveurs_sendmail`, compte administrateur initial créé une fois. Détails d'installation tirés de la doc officielle Forgejo. Activation de l'entrée `forgejo` dans `docs/bases-donnees.yml`. Playbook de groupe et `group_vars` production associés.
- Rôle `serveurs_icinga` (supervision active — cœur, Phase 4) : dépôt apt officiel Icinga, `icinga2` + `icingadb` + `icingadb-redis`, `icinga2 api setup` + activation de la fonctionnalité `icingadb`, **base PostgreSQL via le registre** (entrée `icingadb`, import du schéma, mot de passe partagé via Vault), config Icinga DB (BD + Redis). **Icinga Web 2 différé** à une phase dédiée. Détails de configuration Icinga DB paramétrés et signalés comme non vérifiables verbatim (pages doc partiellement indisponibles). Ajout de l'entrée `icingadb` à `docs/bases-donnees.yml`. Playbook de groupe et `group_vars` production associés.
- Rôle `serveurs_redis` (cache / files, paquet Debian) : surcharge **non destructive** de `redis.conf` via `include`, `requirepass` (Vault, car exposé sur le réseau interne), `maxmemory` + politique `allkeys-lru`, écoute localhost + IP interne. Complète le nœud données (data-01) aux côtés de PostgreSQL. Playbook de groupe et `group_vars` production associés.
- Rôle `clients_smtp` (intégration cliente relais mail) : `msmtp` + `msmtp-mta` relaient le courrier sortant (notifications, cron, alertes) vers `serveurs_sendmail`, sans daemon. Dernière intégration cliente dont le serveur central existe. Playbook de groupe et `group_vars` production associés.
- Rôle `clients_ldap` (intégration cliente identité utilisateur) : **SSSD** (NSS + PAM) vers `serveurs_openldap`, activation de `sss` dans `/etc/nsswitch.conf` (passwd/group/shadow), création automatique des répertoires personnels (`mkhomedir`), bind anonyme par défaut (bind dédié possible via Vault). Authentification des utilisateurs centralisée — complète l'identité machine de `clients_pki`. Playbook de groupe et `group_vars` production associés.
- Rôle `clients_pki` (intégration cliente PKI / identité machine) : `step-cli` (dépôt Smallstep), **confiance** dans l'AC interne (`step ca bootstrap --install` → racine dans le magasin système), **certificat d'hôte** via le provisioner, **renouvellement automatique** (unités systemd officielles `cert-renewer@.{service,timer}`, vérification toutes les 15 min). Chaque hôte obtient une identité machine vérifiable et un TLS interne réel (remplace les certificats auto-signés). Secrets (empreinte racine + mot de passe provisioner, partagé avec `serveurs_step_ca`) via Vault. Détails tirés de la doc officielle Smallstep. Playbook de groupe et `group_vars` production associés.
- Rôle `clients_journaux` (intégration cliente journaux) : **Grafana Alloy** (dépôt apt Grafana) lit le journal système (journald) et le pousse vers `serveurs_loki` ; l'utilisateur `alloy` est ajouté au groupe `systemd-journal`. Complète l'observabilité côté client (métriques + journaux). Playbook de groupe associé.
- Rôle `clients_metriques` (intégration cliente métriques) : installe `prometheus-node-exporter` (paquet Debian) sur les VM du groupe ; `serveurs_prometheus` dérive et scrape automatiquement la cible depuis l'inventaire. Première intégration cliente — ferme la boucle d'observabilité côté métriques. Playbook de groupe associé.
- Rôle `serveurs_grafana` (tableaux de bord, dépôt apt officiel Grafana) : datasources Prometheus + Loki **provisionnées automatiquement** (`/etc/grafana/provisioning/datasources/`), domaine/`root_url` et mot de passe admin (Vault) via un **drop-in systemd non destructif** (ne touche pas `grafana.ini` du paquet), inscriptions publiques désactivées, publication derrière `serveurs_nginx`. Clôt la Phase 3 observabilité. Playbook de groupe et `group_vars` production associés.
- Rôle `serveurs_loki` (agrégation de journaux, dépôt apt officiel Grafana) : configuration single-node (stockage `filesystem`, schéma TSDB v13), rétention via compactor (`retention_enabled`), écoute `:3100`. Le dépôt apt Grafana est partagé avec `serveurs_grafana`. Playbook de groupe associé.
- Rôle `serveurs_prometheus` (collecte de métriques, paquet Debian) : début de la Phase 3 observabilité. Config Prometheus avec cibles `node_exporter` **dérivées de l'inventaire** (hôtes actifs de `clients_metriques` → `:9100`, comme la zone DNS), jobs additionnels libres, rétention configurable via `/etc/default/prometheus`, `promtool check config` avant rechargement (handler dans le rôle). Playbook de groupe associé.
- Rôle `serveurs_keycloak` (SSO/IAM, hub d'authentification centralisée) : distribution Quarkus (version en variable, URL release officielle), **premier consommateur de bout en bout du registre de BD** (`serveurs_postgresql` crée la base/compte `keycloak`, le rôle lit la même entrée pour son DSN — mot de passe partagé via `vault_bd_keycloak`), publication derrière `serveurs_nginx` (`proxy-headers=xforwarded`, `http-enabled=true`), secrets (BD + admin bootstrap) dans un `EnvironmentFile 0640`/`no_log`, `kc.sh build` puis service systemd `start --optimized`. Activation de l'entrée `keycloak` dans `docs/bases-donnees.yml`. Détails de configuration tirés de la doc officielle Keycloak. Playbook de groupe et `group_vars` production associés.
- Rôle `serveurs_openldap` (annuaire interne) : slapd Debian configuré via debconf (installation non interactive, backend MDB), base DN dérivée du domaine (`dc=chezlepro,dc=internal`), mot de passe admin **obligatoire depuis Vault**, unités organisationnelles de base (`people`, `groups`) via `community.general.ldap_entry`. Playbook de groupe et `group_vars` production associés.
- Registre déclaratif des bases de données applicatives `docs/bases-donnees.yml` (patron « 1 appli → 1 base → 1 compte propriétaire → 1 chaîne de connexion »). Consommé côté serveur par `serveurs_postgresql` (crée base + compte propriétaire, mot de passe depuis la variable Vault nommée par `secret`) et, côté appli, pour bâtir la chaîne de connexion — secret partagé, source unique. Évite un rôle par base. Vide par défaut.
- Rôle `serveurs_step_ca` (AC interne Smallstep step-ca + provisioner ACME) : dépôt apt officiel Smallstep (clé + source deb822), installation `step-ca`/`step-cli`, utilisateur système `step`, initialisation de l'AC **une seule fois** (`step ca init` standalone + ACME, garde-fou `creates: ca.json`), mots de passe CA et provisioner **obligatoires depuis Vault**, unité systemd durcie officielle. Playbook de groupe et `group_vars` production associés. Clôt la Phase 1 des fondations. Détails d'installation tirés de la documentation officielle Smallstep (non inventés).
- Rôle `serveurs_sendmail` (relais SMTP sortant, basé sur Postfix qui fournit l'interface `sendmail`-compatible) : installation non interactive (debconf), relais limité à `mynetworks` (`10.1.0.0/16`, pas de relais ouvert), smarthost amont optionnel, TLS opportuniste (snakeoil par défaut), `postfix check` avant reload. Playbook de groupe et `group_vars` production associés.
- Rôle `serveurs_nginx` (edge) : reverse proxy et terminaison TLS, certificat auto-signé (snakeoil) par défaut avec chemins en variables pour bascule vers l'AC interne/ACME, durcissement de base (`server_tokens off`, TLS 1.2/1.3), sites de reverse proxy pilotés par variables (vides par défaut), validation `nginx -t` avant reload (handler dans le rôle). Playbook de groupe `serveurs_nginx` et `group_vars` production associés.
- Rôle `serveurs_postgresql` (premier service applicatif après PowerDNS) : PostgreSQL packagé Debian 13, écoute `127.0.0.1` + IP interne, `pg_hba` en `scram-sha-256` ouvert au réseau interne `10.1.0.0/16`, configuration via `conf.d`, provisionnement optionnel de comptes/bases par variables (mots de passe via Vault), handlers reload/restart dans le rôle. Playbook de groupe `serveurs_postgresql` et `group_vars` production associés. Ajout de `requirements.yml` (collections `community.postgresql`, `community.general`).
- Vue des liens VM → groupes → playbooks → rôles dans `make inventaire-ui` : onglet « Chaîne » par hôte (panneau détail) et vue arbre globale (bascule « Inventaire / Chaîne » en en-tête). Les rôles sont extraits des `playbooks/groupes/*.yml` et exposés dans l'API ; les groupes sans rôle sont signalés « stub ».
- Champ de mot de passe du vault Ansible dans la modale de déploiement de `make inventaire-ui` : transmis via fichier temporaire `0600` + `ANSIBLE_VAULT_PASSWORD_FILE`, supprimé après exécution, jamais journalisé. Évite tout prompt `--ask-vault-pass` bloquant en exécution non-interactive. Le flux vault de `make cloner-vm` / `creer-vm` n'est pas modifié.
- Catégorie « Modèles / essais » (VLAN 99 → `10.1.99.0/24`) dans `docs/nomenclature.yml`.
- Registre de nomenclature machine-lisible `docs/nomenclature.yml` (source unique) : domaines, catégories, plan d'adressage `10.1.0.0/16` segmenté par fonction (un /24 et un VLAN par catégorie), dérivations hostname / VMID / VLAN / IP / passerelle.
- Auto-proposition dans `make inventaire-ui` : bouton « ✨ Proposer » et auto-remplissage à la saisie du nom, qui dérivent VMID, VLAN, IP et passerelle depuis `docs/nomenclature.yml` (avec indice de zone). Migration du plan d'adressage interne vers `10.1.0.0/16` (remplace les essais `192.168.12.x`).
- Adoption du nom officiel « Set-OPS — Votre artisan numérique » : titre et en-tête de `make inventaire-ui`, et titre du `README.md`.
- Déploiement depuis `make inventaire-ui` : boutons « Vérifier » (dry-run `--check --diff`) et « Déployer » (réel) par hôte, avec console de sortie en direct. Garde-fous : jeton anti-CSRF (`X-Jeton`), verrou (une seule exécution à la fois), validation du nom d'hôte (anti-injection), refus si l'hôte n'est pas actif, déploiement bloqué tant qu'une vérification n'a pas réussi (réarmé à chaque sauvegarde), restriction à l'inventaire production. Déploiement non transactionnel (sans rollback) signalé à l'opérateur.
- Cible `make verifier-deploiement HOTE=…` : déploiement à blanc (`--check --diff`) d'un hôte selon ses groupes, réutilisée par l'interface.
- Refonte de l'interface `make inventaire-ui` : thème sombre dense, grille de cartes d'hôtes groupées par état (Actifs / Planifiés) avec badge de statut coloré, chips de filtre (Tous / Actifs / Planifiés / Bloqués), recherche, et panneau détail maître-détail à onglets (Réseau / Proxmox / Groupes) avec tuiles de chiffres-clés (VMID, mémoire, cœurs, disque, groupes), bascule d'état actif/planifié, panneau de dépendances repliable, raccourci Ctrl/Cmd+S.
- Saisie des paramètres de provisioning par hôte dans l'inventaire (variables d'hôte) : `proxmox_cidr`, `proxmox_passerelle`, `proxmox_vlan`, `proxmox_pont`, `proxmox_dns`, `proxmox_noeud`, `proxmox_stockage`, `proxmox_disque_taille`, `proxmox_memoire`, `proxmox_coeurs`, avec validation (VLAN 1-4094, CIDR 0-32, entiers positifs) et round-trip non destructif. Documentées dans `docs/nomenclature-vm.md`.
- Scission de la couche applicative web en deux groupes distincts de l'edge `serveurs_nginx` :
  - `serveurs_web_frontaux` (présentation web : UI, rendu, assets) ;
  - `serveurs_web_dorsaux` (application web : API, traitement) ;
  - playbooks homonymes et entrée dédiée dans `docs/catalogue-services.md`.
- Ajout de `make hote-planifier` pour renseigner un hôte, son VMID et ses groupes sans création ni déploiement immédiat.
- Ajout de `scripts/inventory_rules.py` pour centraliser les règles partagées entre la gestion CLI et l'interface locale d'inventaire.
- Ajout de `docs/dependances-groupes.yml` comme registre exploitable des dépendances causales entre groupes.
- Ajout du contrat `serveurs_powerdns` afin de représenter la capacité DNS centrale requise par `clients_dns`.
- Ajout du premier jalon DNS interne :
  - rôle `serveurs_powerdns` avec PowerDNS Authoritative et backend BIND ;
  - génération de la zone interne depuis l'inventaire actif ;
  - rôle `clients_dns` avec validation de zone et modification resolver protégée ;
  - variables de production DNS et runbook `docs/dns-interne.md`.

### Modifié
- Bindings appli↔BD explicites et **plusieurs bases par application** : chaque base porte un `consommateur` (le groupe applicatif qui l'utilise) et un `usage` (principale/cache…). La GUI (vue « Bases » : menu déroulant **Consommateur** + champ **Usage**) et la CLI (`ajouter-base --consommateur --usage`) gèrent le lien ; la vue **Chaîne devient détaillée** (chaque groupe affiche ses rôles ET ses bases avec leur chaîne de connexion). Rôles `serveurs_keycloak`/`serveurs_forgejo`/`serveurs_icinga` migrés pour résoudre leur base par consommateur (plus de clé codée en dur).
- Registre `docs/bases-donnees.yml` passé à un **modèle multi-serveurs** : section `serveurs_bd` (serveurs de BD nommés — `type`/`hôte`/`port`/`groupe`) que chaque base référence. La **chaîne de connexion dérivée** devient le lien appli↔BD ; l'hôte n'est plus codé en dur. Rôles `serveurs_postgresql` (filtre par serveur nommé relié à son groupe) et `serveurs_keycloak`/`serveurs_forgejo`/`serveurs_icinga` (hôte/port lus depuis le registre) migrés.
- Robustesse du serveur `make inventaire-ui` : `repondre()` avale proprement les connexions fermées par le client (`BrokenPipeError`/`ConnectionResetError`) au lieu de déverser une trace dans la console ; ajout d'un favicon (204) pour éviter le 404 répété du navigateur.
- `make deployer` et `make verifier-deploiement` détectent un `group_vars` de production chiffré (Ansible Vault) et demandent le mot de passe **une seule fois** (réutilisé pour tous les playbooks et sous-vérifications via fichier temporaire `0600`, nettoyé en fin de run). Refus propre si vault chiffré détecté en exécution **non-interactive** ; la GUI ferme `stdin` du sous-processus et fournit le mot de passe via la modale, donc elle ne bloque jamais. Ferme l'asymétrie de gestion des secrets entre terminal et GUI.
- Migration complète de l'adressage interne vers `10.1.0.0/16` : golden template `basiqueChezlepro` → `10.1.99.99`, et tous les exemples `192.168.x` (README, Makefile, runbooks Proxmox et template) réécrits vers le schéma `10.1.x` / `web-frontal-01`.
- Remplacement du groupe `serveurs_web` par `serveurs_web_frontaux` et `serveurs_web_dorsaux` dans les inventaires lab et production, mises à jour des exemples `README.md` et `AGENTS.md`.
- Retrait des hôtes de test `web-01` et `web-02` de l'inventaire production.
- Planification de la couche applicative web : `web-frontal-01` (95301), `web-frontal-02` (95302) dans `serveurs_web_frontaux` et `web-dorsal-01` (95401) dans `serveurs_web_dorsaux`, tous en `hotes_planifies` avec socle et durcissement.
- Mise à jour de `docs/nomenclature-vm.md` : domaines `web-frontal` / `web-dorsal`, retrait des noms de test `web-01`/`web-02`.
- Renforcement de la validation d'inventaire :
  - un hôte doit être soit planifié, soit actif, mais pas les deux ;
  - un hôte actif doit avoir `ansible_host` ;
  - un hôte doit porter au moins un groupe opérationnel ;
  - les VMID dupliqués sont refusés.
- Conservation du VMID dans l'inventaire lors de `make creer-vm` et `make hote-ajouter`.
- Alignement de l'aide Makefile et de la documentation sur le flux opérateur : planifier, activer/créer, déployer.
- Retrait des groupes génériques obsolètes `serveurs_bases_donnees` et `serveurs_supervision` au profit des groupes de services précis.
- Consolidation des groupes Icinga en `serveurs_icinga` afin de représenter une seule capacité de supervision serveur sur `mon-01`.
- Validation des prérequis actifs avant déploiement d'un groupe, déploiement d'un hôte ou sauvegarde active via l'interface d'inventaire.
- Refonte visuelle de `make inventaire-ui` pour afficher les dépendances causales, les prérequis manquants et l'état déployable ou bloqué des hôtes.

## 2026-06-21

### Ajouté
- Ajout de facilités `make` pour exploiter Ansible sur les VM Debian déployées :
  - diagnostic `ping`, `sudo` et `faits` ;
  - variables `LIMITE`, `VERIFICATION`, `DIFF`, `ETIQUETTES`, `SAUTER_ETIQUETTES` et `VARIABLES`.
- Ajout de facilités `make` pour inspecter et valider les inventaires Ansible :
  - `hote-ajouter` ;
  - `hote-groupes` ;
  - `hote-afficher` ;
  - `inventaire-verifier` ;
  - `inventaire-lister` ;
  - `inventaire-graphe` ;
  - `inventaire-hote` ;
  - `inventaire-lab` ;
  - `inventaire-production`.
- Ajout de `deployer` et `deployer-groupe` comme commandes opérateur simplifiées pour appliquer les playbooks de groupes.
- Ajout de `scripts/inventory_host.py` pour gérer les entrées d'inventaire et leur appartenance aux groupes sans édition YAML manuelle.
- Ajout de la convention `1 groupe opérationnel = 1 playbook homonyme` avec les premiers playbooks :
  - `playbooks/groupes/serveurs_debian.yml` ;
  - `playbooks/groupes/serveurs_durcis.yml`.
- Ajout du playbook `playbooks/maintenance/verifier_hote_debian.yml` pour valider une VM Debian 13 gérée par Set-OPS après socle et durcissement.
- Ajout de directives `AGENTS.md` pour formaliser le `Makefile` comme interface opérateur, la convention groupe/playbook, la francisation de la surface opérateur et les points de stabilisation avant commit.
- Ajout du playbook `playbooks/proxmox/cloner_vm_debian.yml` et des cibles `make cloner-vm` / `make creer-vm` pour créer des clones Debian via l'API Proxmox sans stocker de secret dans le dépôt.
- Ajout de `inventories/lab/group_vars/proxmox.yml` pour les paramètres Proxmox non sensibles et de `proxmox.vault.yml.example` pour préparer les secrets API avec Ansible Vault.
- Ajout de `make config` pour renseigner les paramètres Proxmox et créer ou éditer le Vault API depuis le terminal.

### Modifié
- Francisation de la surface opérateur :
  - variables `make` ;
  - cibles `make` ;
  - groupes d'inventaire ;
  - chemins des playbooks maison ;
  - libellés du script de gestion d'inventaire.
- Documentation du flux de déploiement d'une VM clonée depuis le modèle doré avec les commandes `make`.
- Optimisation de la procédure de bootstrap du modèle Debian 13 pour utiliser Cloud-Init comme source unique de l'identité initiale au lieu de maintenir une création manuelle parallèle du compte et de la clé SSH.
- Simplification de `make cloner-vm` et `make creer-vm` pour que les paramètres Proxmox communs viennent des variables Ansible plutôt que de la ligne de commande ou de l'environnement.
- Ajustement de `make config` pour ne plus redemander les valeurs Cloud-Init déjà portées par le modèle Proxmox.
- Déplacement du VLAN hors de `make config` afin de l'exiger explicitement à chaque création de VM avec `VLAN=...`.
- Retrait des options `DEMANDER_MDP` et `DEMANDER_SUDO` du `Makefile`; le flux suppose SSH par clé et sudo NOPASSWD déjà fonctionnels.
- Retrait des playbooks de couches redondants `playbooks/socle/debian_commun.yml` et `playbooks/durcissement/debian_serveur_durcissement.yml`; la conformité des VM déployées passe maintenant par `playbooks/groupes/`.
- Bonification de `AGENTS.md` pour désigner `playbooks/groupes/` comme source officielle de conformité et éviter les cibles `make` de couches parallèles.
- Simplification de l'aide du `Makefile` pour exposer d'abord les gestes opérateur : inventaire, groupes, déploiement.
- Clarification de `make aide` pour expliquer les différences entre `creer-vm`, `cloner-vm`, `deployer`, `deployer-groupe` et `appliquer`.
- Réorganisation de `make aide` par objets d'exploitation : VM, hôtes, groupes, inventaires, modèle et validation.
- Retrait des commandes opérateur explicites de ping et sudo; ces vérifications sont maintenant implicites dans `deployer` et `preparer-modele`.
- Ajout d'une demande automatique de mot de passe Ansible Vault pour `make cloner-vm` et `make creer-vm` lorsqu'un `proxmox.vault.yml` chiffré est présent.
- Amélioration du message d'erreur lorsque `proxmox.vault.yml` ne peut pas être chargé.
- Ajustement du playbook Proxmox pour laisser apparaître les erreurs API utiles sans masquer entièrement les échecs de clonage.
- Modification de `make deployer HOTE=...` pour appliquer les playbooks correspondant aux groupes de l'hôte.
- Ajout d'une vérification explicite de la bibliothèque Python `proxmoxer` avant les appels API Proxmox.
- Retrait de la taille disque clone des paramètres Proxmox persistés afin de ne pas tenter de réduire un disque hérité du modèle.
- Ajout de la validation inventaire/playbooks pour empêcher un groupe opérationnel avec hôtes sans playbook homonyme.
- Ajout du playbook de groupe `serveurs_web` comme point d'ancrage explicite avant l'ajout d'un rôle web.
- Ajout d'un catalogue de services pour préparer Keycloak, OpenLDAP, PostgreSQL, Loki, Icinga, Prometheus, Grafana, Forgejo, Sendmail, step-ca, Redis, NGINX, Nextcloud et Collabora.
- Ajout des groupes et playbooks homonymes neutres pour les prochains services centraux et intégrations clientes.
- Documentation de l'ordre d'implémentation recommandé des services selon leurs dépendances et intégrations.
- Ajout d'une nomenclature VM/VMID et distinction entre hôtes planifiés et hôtes actifs dans l'inventaire.
- Ajout d'une interface web locale `make inventaire-ui` pour éditer et sauvegarder l'inventaire sans lancer de déploiement.
- Ajustement de la nomenclature planifiée vers des noms d'hôtes par domaine afin de permettre la cohabitation de plusieurs services sur une même VM.

## 2026-06-19

### Ajouté
- Structure initiale globale du dépôt Set-OPS.
- Playbooks de création du template Debian 13 Proxmox.
- Rôles de base Debian.
- Rôles de durcissement template-safe.
- Playbook de vérification.
- Playbook de nettoyage final avant conversion en template.

## 2026-06-20

### Contexte
- Clarification : `Set-OPS` est le dépôt global d’exploitation Ansible de Chezlepro Inc.
- Clarification : le template Debian 13 Proxmox est un sous-ensemble du dépôt, pas sa finalité unique.
- Clarification : les services applicatifs spécialisés doivent être installés sur les clones par des playbooks dédiés, pas directement dans le template.

### Ajouté
- Ajout des directives renforcées dans `AGENTS.md` :
  - validation Ansible obligatoire ;
  - vérification des handlers Ansible ;
  - interdiction de déclarer un playbook prêt si `--syntax-check` échoue ;
  - préférence pour les correctifs ciblés au lieu des régénérations massives ;
  - rappel que `Set-OPS` ne doit pas être restructuré autour d’un seul besoin ponctuel.
- Ajout d’une logique de template Debian 13 Proxmox :
  - `playbooks/modeles_vm/debian13_proxmox_preparer.yml` ;
  - `playbooks/modeles_vm/debian13_proxmox_verifier.yml` ;
  - `playbooks/modeles_vm/debian13_proxmox_nettoyer.yml`.
- Ajout d’une couche de durcissement template-safe :
  - AppArmor ;
  - auditd ;
  - fail2ban SSH ;
  - unattended-upgrades ;
  - journald ;
  - sysctl de sécurité ;
  - nftables installé et préparé, mais désactivé par défaut dans le template.
- Ajout d’un document d’architecture pour les intégrations futures des VM :
  - supervision ;
  - métriques ;
  - identité ;
  - PKI interne ;
  - DNS interne.
- Documentation détaillée des ajouts appliqués au modèle doré Debian 13 Proxmox depuis une installation minimale.
- Ajout d'un runbook explicite pour le playbook de préparation du modèle doré Debian 13 Proxmox.
- Ajout d'un runbook manuel précis pour le bootstrap initial de la VM vanille Debian 13 :
  - correction des sources APT après installation depuis DVD ;
  - installation minimale de `sudo`, SSH, `cloud-init`, `cloud-guest-utils` et `qemu-guest-agent` ;
  - utilisation de Cloud-Init pour injecter le compte `ansible`, sa clé SSH, le réseau et le point de bascule vers le `Makefile`.
- Ajout d'un document de cycle de vie des VM Chezlepro :
  - VM vanille ;
  - goldenisation ;
  - clonage ;
  - socle ;
  - durcissement ;
  - conformité continue.
- Ajout de directives `AGENTS.md` pour la convergence des VM existantes et futures :
  - cycle de vie des VM ;
  - distinction service central et intégration cliente ;
  - groupes d'inventaire par intégration ;
  - séparation des variables de template, conformité et services.
- Ajout d'un `Makefile` comme interface d'exploitation courante :
  - validation ;
  - syntax-checks ;
  - préparation, vérification et nettoyage protégé du template ;
  - socle et durcissement des VM Debian.
- Durcissement SSH du template dès la construction :
  - accès par clé publique obligatoire ;
  - authentification par mot de passe désactivée ;
  - forwarding et tunnels SSH désactivés par défaut ;
  - limites de tentatives, sessions et démarrages SSH resserrées.

### Modifié
- Renforcement attendu de `CLAUDE.md` pour rappeler que `AGENTS.md` est la source d’autorité principale.
- Clarification du comportement attendu de Claude Code :
  - lire l’existant avant modification ;
  - vérifier `git status --short` ;
  - ne pas faire de régénération massive sans demande explicite ;
  - valider les playbooks touchés ;
  - signaler les tests non exécutés ;
  - mettre à jour `CHANGELOG.md` si pertinent.
- Migration des variables de rôles vers des préfixes propres à chaque rôle pour respecter `ansible-lint`.
- Mise à jour de la variable de confirmation du nettoyage final :
  - `template_cleanup_confirm`.
- Correction de la structure du `CHANGELOG.md` pour retirer le titre dupliqué.
- Simplification ciblée de l'arborescence `roles/` :
  - retrait des doublons non utilisés sous `roles/base/` ;
  - retrait des doublons non utilisés sous `roles/security/` ;
  - retrait des doublons non utilisés sous `roles/vm_template/`.
- Ajout d'un renvoi depuis la procédure manuelle vers la justification du golden template.
- Séparation documentaire et opérationnelle entre variables de template et variables de conformité.
- Extension du playbook de groupe `playbooks/groupes/serveurs_debian.yml` pour maintenir le socle commun des VM Debian déployées.
- Mise à jour de la documentation pour exiger un `ciuser` cloud-init avec clé publique avant l'exécution d'Ansible.
- Déplacement des listes de paquets communes dans les defaults des rôles `common_packages` et `hardening_packages`.
- Déplacement des variables de construction du template dans `inventories/lab/group_vars/modeles_vm.yml`.
- Déplacement des variables de conformité Debian dans `inventories/production/group_vars/serveurs_debian.yml`.
- Ciblage du playbook de durcissement sur `serveurs_debian` au lieu de `all`.
- Renforcement du playbook de vérification du modèle doré.

### Corrigé
- Vérification des rôles contenant `notify`.
- Confirmation des handlers SSH requis dans les rôles concernés :
  - `roles/ssh_baseline/handlers/main.yml` ;
  - `roles/ssh_hardening/handlers/main.yml`.

### Validé
- Vérification que chaque `notify` du template Debian 13 Proxmox pointe vers un handler existant.
- Relance du playbook de préparation du template Debian 13 Proxmox.
- Nettoyage final non lancé.