- **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.)*
- **`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).
- **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.)*
- **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`.
- 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é.
- 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`.
- 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`.
- 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.
- 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 :