Formaliser l'identite d'ecosysteme numerique souverain

Acter dans les docs d'autorite que Set-OPS ne se limite plus a
l'exploitation mais definit et construit l'ecosysteme numerique
souverain de Chezlepro Inc.

- AGENTS.md : nouvelle section « Mission et identite » (piliers,
  proprietes visees, nuances honnetes : pas auto-repare, defini avant
  deploiement, registres = source unique).
- README.md : section « Mission » + « Domaines prevus » rationalise en
  « Portee transverse » (retire ce que les piliers couvrent deja).
- CHANGELOG.md : entree du 2026-06-22.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

AGENTS.md

@@ -10,6 +10,31 @@ Le template Debian 13 Proxmox est seulement un sous-ensemble du dépôt. Le dép
 
 ---
 
+## Mission et identité
+
+Au-delà de l’exploitation, `Set-OPS` **définit et construit l’écosystème numérique souverain de Chezlepro Inc.** : une infrastructure interne auto-suffisante, sans dépendance SaaS, dont tous les piliers sont décrits en code et reliés entre eux.
+
+Piliers de l’écosystème :
+
+- identité — machines (PKI / certificats) et utilisateurs (annuaire + SSO) ;
+- confiance — autorité de certification interne (ACME) ;
+- nommage et adressage — DNS interne et nomenclature dérivable ;
+- données — bases relationnelles et cache, avec registre des connexions ;
+- communication — relais courriel interne ;
+- observabilité et supervision — métriques, journaux, tableaux de bord, supervision active ;
+- applicatif — services internes (forge, etc.) et couche web.
+
+Propriétés visées, avec leurs nuances honnêtes :
+
+- **Souverain / auto-suffisant** : c’est l’objectif. Aucune dépendance à un service externe pour la confiance, l’identité, le nom ou la communication. Cela justifie le choix de construire plutôt qu’assembler des SaaS.
+- **Déclaratif et convergent** : l’état voulu est décrit dans des registres machine-lisibles (`docs/nomenclature.yml`, `docs/dependances-groupes.yml`, `docs/bases-donnees.yml`) et appliqué par les groupes Ansible. Ces registres sont la **source unique de vérité**.
+- **Pas (encore) auto-réparé** : la convergence est pilotée par l’opérateur (GUI / CLI / `make`), pas une boucle fermée d’auto-remédiation.
+- **Définition avant déploiement** : une grande partie est planifiée et validée (`--syntax-check`, `ansible-lint`) mais pas encore exécutée contre des VM réelles. Ne jamais présenter un rôle non déployé comme « en production ».
+
+Conséquence pour le travail : préserver la discipline qui tient l’ensemble — registres comme source unique, dépendances explicites, validation de chaque pièce, secrets hors dépôt. C’est ce qui empêche l’écosystème de devenir un objet ingérable. Le template Debian 13 reste la fondation (le moule des VM), pas la finalité.
+
+---
+
 ## Règle d’or IA
 
 Un seul agent IA travaille dans ce dépôt à la fois.

CHANGELOG.md

@@ -3,6 +3,7 @@
 ## 2026-06-22
 
 ### Ajouté
+- 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.

README.md

@@ -2,17 +2,32 @@
 
 Dépôt Ansible central pour construire, configurer, maintenir et documenter les systèmes de Chezlepro Inc.
 
-## Domaines prévus
+## Mission
 
-- templates de VM Proxmox ;
-- groupes de conformité ;
+`Set-OPS` ne se limite plus à l'exploitation : il **définit et construit l'écosystème numérique souverain de Chezlepro Inc.** — une infrastructure interne auto-suffisante, sans dépendance SaaS, décrite en code et pilotée par des registres machine-lisibles qui font office de **source unique de vérité** (`docs/nomenclature.yml`, `docs/dependances-groupes.yml`, `docs/bases-donnees.yml`).
+
+Piliers de l'écosystème :
+
+- **identité** — machines (PKI / certificats) et utilisateurs (annuaire + SSO) ;
+- **confiance** — autorité de certification interne (ACME) ;
+- **nommage et adressage** — DNS interne et nomenclature dérivable ;
+- **données** — bases relationnelles et cache, avec registre des connexions ;
+- **communication** — relais courriel interne ;
+- **observabilité et supervision** — métriques, journaux, tableaux de bord, supervision active ;
+- **applicatif** — services internes (forge, etc.) et couche web.
+
+L'état voulu est **déclaratif et convergent** (appliqué par les groupes Ansible), **souverain** par conception, mais **piloté par l'opérateur** (pas d'auto-remédiation : la boucle n'est pas fermée). Une grande partie est aujourd'hui *définie et validée* avant d'être déployée sur des VM réelles ; le template Debian 13 reste la fondation, pas la finalité.
+
+Cadre et règles d'autorité : voir `AGENTS.md` (section « Mission et identité »).
+
+## Portée transverse
+
+Au-delà des piliers ci-dessus, le dépôt couvre des préoccupations transverses, communes à toutes les VM :
+
+- templates de VM Proxmox (la fondation) ;
+- groupes de conformité et durcissement ;
 - maintenance ;
-- web ;
-- bases de données ;
-- monitoring ;
-- sauvegardes ;
-- identité ;
-- applications.
+- sauvegardes.
 
 ## Premier chantier