diff --git a/CHANGELOG.md b/CHANGELOG.md
index 05ce7e9..d88fe87 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,5 +1,109 @@
# CHANGELOG — Set-OPS
+## 2026-09-20 (3) — La capacité du système ne se déduit pas de la méthode
+
+**82 preuves dans le rapport du 17 septembre, non rejouées ici.** Le premier comparatif
+SOC 2 expliquait la différence entre méthode et attestation. Il répondait à côté de la
+question : le système construit peut-il satisfaire les critères, et que lui manque-t-il ?
+
+### Nommer les contrôles disponibles, puis les réglages qui restent à relire
+
+Le dossier HTML/PDF `2026-09-20-comparatif-setops-soc2`, **hors dépôt dans `livraisons/`**,
+est recentré sur cette capacité : oui sous conditions, pas une conformité acquise.
+Les identités, flux, certificats, traces, sauvegardes et moyens de reprise sont rapprochés
+de critères identifiés, sans déclarer une couverture exhaustive ni un résultat d'audit.
+
+La lecture relève des points concrets : vérification des clés d'hôtes SSH désactivée,
+interfaces Prometheus/Loki déclarées sans authentification interne, TLS optionnel dans
+les défauts de certains rôles et limite du VPN sans MFA. **Les défauts de rôle ne sont
+pas présentés comme les réglages réels d'une instance.** La conservation des traces,
+la résistance des sauvegardes, les objectifs de reprise et les traitements applicatifs
+restent à vérifier selon les engagements. Le dossier propose une recette, il ne l'exécute pas.
+
+### Corriger la réponse sans modifier l'infrastructure
+
+Le générateur et le README de livraison sont mis à jour ; les quatre fichiers précédents
+sont archivés avant remplacement. Les huit pages PDF, leur texte, leurs liens et leur
+pagination sont contrôlés ; la page HTML est vérifiée de 320 à 1440 pixels et sans
+JavaScript. Les références officielles AICPA et les constats de code sont relus.
+Les dossiers clients, le kit VPN et l'habillage partagé restent inchangés.
+
+Aucun rôle, playbook ou réglage SSH/TLS n'est modifié. Aucun sondage de VM, aucune
+ouverture de voûte, aucun test d'intrusion : la syntaxe Ansible et les preuves ne sont
+pas rejouées pour cette modification strictement documentaire.
+
+## 2026-09-20 (2) — Un contrôle rejouable n'est pas une attestation indépendante
+
+**82 preuves dans le rapport du 17 septembre, non rejouées ici.** Comparer Set-OPS à un
+service couvert par SOC 2 exige de distinguer l'architecture, son exploitation et
+l'assurance indépendante : aucun compteur du harnais ne donne un taux de conformité SOC 2.
+
+### Comparer sans faire passer une capacité pour un statut
+
+Un nouveau dossier HTML/PDF de huit pages, `2026-09-20-comparatif-setops-soc2`, est ajouté
+à `livraisons/`, **hors dépôt**, avec son générateur et sa documentation. Il reprend
+l'habillage partagé sans modifier les dossiers clients ni le kit VPN. Les références
+officielles AICPA, consultées le 20 septembre, accompagnent la distinction entre rapport
+et certification du logiciel, les types 1 et 2 et les catégories des Trust Services Criteria.
+
+Le rapprochement nomme les mécanismes de Set-OPS, les limites de leurs preuves, les
+questions d'exploitation et la frontière hébergeur/locataire. Les écarts proposés restent
+des questions de préparation, pas un audit de l'entreprise ; aucun rapport SOC 2 d'un
+fournisseur ou de Chezlepro n'a été examiné. Ni conformité ni supériorité de sécurité
+ne sont attribuées au projet.
+
+Structure, sources, liens, rendu de 320 à 1440 pixels, lecture sans JavaScript et PDF de
+huit pages sont vérifiés. Aucun sondage des VM, aucune ouverture de voûte et aucune
+modification du moteur d'exploitation.
+
+## 2026-09-20 — Une nouvelle couverture ne rajeunit pas une mesure
+
+**82 preuves dans le rapport du 17 septembre, non rejouées ici.** Les dossiers de
+livraison datés du 16 septembre présentaient des réponses HTTP anciennes comme un état
+de livraison et ne décrivaient pas encore les tunnels d'administration nominatifs.
+Leur révision distingue les capacités, les faits déclarés au plan et les usages à recevoir.
+
+### Donner envie sans transformer le dossier en attestation
+
+Les quatre HTML et leurs quatre PDF de `livraisons/`, **hors de ce dépôt**, sont revus
+pour Chezlepro et TechnoLibre : bénéfices, services reliés, prise en main, autonomie,
+remise des clés et responsabilités. Les noms du 16 septembre restent stables ; la
+révision du 20 septembre est visible. Les réponses 200/302 restent des mesures anciennes,
+pas une preuve actuelle de SSO. La séparation des runners n'est plus présentée comme
+une suppression des pouvoirs de l'hyperviseur.
+
+### Une source pour les deux formats, et des responsabilités qui ne disparaissent pas
+
+Les générateurs lisent les machines, applications et expositions dans les plans ; la
+charte conserve ses vingt lignes, lues dans le tableau canonique. L'habillage commun
+est distinct de celui du kit VPN confidentiel, laissé intact. Un README décrit la
+régénération et les originaux sont archivés avant remplacement.
+
+Les quatre pages sont vérifiées de 320 à 1440 pixels ; chaque PDF compte sept pages.
+Les liens, les titres, les cellules de la charte, les adresses dérivées et la pagination
+sont contrôlés. Aucun déploiement, aucune lecture de voûte et aucun sondage de VM :
+ces vérifications portent sur les documents, pas sur l'état actuel des services.
+
+## 2026-09-19 — L’histoire commence là où les traces commencent
+
+**82 preuves dans le dernier rapport versionné, non rejouées pour cette page.** Le premier
+commit contient déjà 308 fichiers : raconter la naissance de Set-OPS comme une succession
+d'étapes antérieures aurait inventé ce que Git ne montre pas.
+
+### Les décisions se racontent, leurs sources restent consultables
+
+`promo/histoire.html` raconte huit étapes à partir des 641 commits accessibles depuis
+`05b85eb`, du 24 juin au 17 septembre 2026. Les reconstructions, les limites des preuves
+statiques et les changements de direction gardent leur date et leur périmètre. Le récit
+renvoie aux commits charnières ; les 641 titres originaux, leurs dates et leurs identifiants
+sont intégrés dans une archive recherchable, avec un graphique d'activité issu du même
+corpus. Aucun service externe, aucune police distante, aucun moteur Ansible modifié.
+
+La page Capacités donne accès à cette chronique. Le README de `promo/` précise son
+caractère figé, son fonctionnement hors ligne et les éléments à actualiser ensemble
+pour prolonger le récit. Les vérifications de cette livraison portent sur la page et
+ses interactions, pas sur les playbooks ni sur la flotte.
+
## 2026-09-17 (6) — TechnoLibre a son tunnel, et son kit de mise en service
- Instance `admins-technolibre` (`wg23`, port 52023, `10.23.29.0/24`), pair declare dans le
diff --git a/promo/README.md b/promo/README.md
index 83cda32..eee6e5c 100644
--- a/promo/README.md
+++ b/promo/README.md
@@ -1,7 +1,8 @@
# promo/ — pages de présentation Set-OPS
-Quatre pages web **autonomes** (un seul fichier chacune, aucun asset externe, aucune
-dépendance réseau), sœurs de thème et liées entre elles par la barre de navigation.
+Cinq pages web **autonomes** (un seul fichier chacune, aucun asset externe, aucune
+dépendance réseau) : quatre pages de présentation liées par la barre de navigation,
+et une chronique éditoriale accessible depuis la page Capacités.
| Fichier | Public visé | Répond à |
|---|---|---|
@@ -9,6 +10,7 @@ dépendance réseau), sœurs de thème et liées entre elles par la barre de nav
| `offres.html` | prospect, client | *Qu'est-ce que vous pouvez bâtir pour moi ?* |
| `tarifs.html` | prospect, acheteur | *Combien ça coûte ?* |
| `valeur.html` | direction, CA, bailleur de fonds | *Qu'est-ce que ça me rapporte, et comment le vérifier ?* |
+| `histoire.html` | lecteur, contributeur, futur exploitant | *Comment ce moteur s'est-il construit, et qu'a-t-il appris ?* |
> ⚠️ **`tarifs.html` est du matériel commercial de Chezlepro inc.**, publié dans un dépôt
> public. Les montants y sont donc visibles de tous, y compris des concurrents et des
@@ -120,7 +122,33 @@ tarifs Set-OPS : ce sont des ordres de grandeur à remplacer.
## Voir / publier
+### `histoire.html` — la chronique du dépôt
+
+Huit chapitres racontent les décisions et les épreuves consignées entre le 24 juin
+et le 17 septembre 2026. Le corpus est **figé au commit `05b85eb`** : 641 commits
+accessibles depuis cette révision, fusions comprises, avec leurs dates d'auteur.
+Les chiffres décrivent cet instantané, pas l'état courant du dépôt.
+
+Les sources de chaque chapitre ouvrent le titre original, la date, l'identifiant
+complet et la commande `git show` correspondante. L'archive intégrée permet de
+rechercher les 641 titres et de filtrer par mois, sans réseau. Le récit, le graphique
+et les réserves restent lisibles sans JavaScript ; la recherche et les détails
+interactifs nécessitent JavaScript.
+
+La page conserve la marque, les liens de navigation et la palette nocturne, avec une
+composition éditoriale propre. Ses styles sont isolés sous `.history` : ils ne
+modifient pas les sélecteurs communs aux quatre pages commerciales. Elle comprend
+une mise en page mobile, une feuille d'impression et le respect du mouvement réduit.
+
+Pour prolonger cette chronique, choisir explicitement une nouvelle révision, relire
+les commits concernés et mettre à jour ensemble le récit, le JSON `commit-data`,
+le graphique journalier, les compteurs, les périodes et le lien de la page Capacités.
+Ne pas remplacer les résultats historiques par des affirmations sur la flotte actuelle.
+
+### Ouvrir les pages
+
```bash
+xdg-open promo/histoire.html
xdg-open promo/offres.html
python3 -m http.server -d promo 8080 # puis http://localhost:8080/offres.html
```
diff --git a/promo/histoire.html b/promo/histoire.html
new file mode 100644
index 0000000..877f941
--- /dev/null
+++ b/promo/histoire.html
@@ -0,0 +1,1240 @@
+
+
+
+
+
+
+
+ Set-OPS — Histoire · Chezlepro
+
+
+
+ Aller au récit
+
+
+
641 commits. Des choix, des pannes, des recommencements. L’histoire d’un écosystème numérique qui apprend à se construire, à se vérifier et à remettre les clés.
+
+
+ Une même intention. Des branches qui s’émancipent.
+
+
+
+
641
commits dans l’historique
86
jours calendaires couverts
8
chapitres pour suivre le fil
82
preuves au dernier rapport
+
+
+
+
+
+
Le fil conducteur
Posséder le code. Pouvoir en repartir.
+
Au fil de l’été, la question s’élargit. Comment configurer une machine ? Comment reconstruire une flotte ? Puis : qui détient les moyens de le faire, et que devient l’écosystème quand son créateur s’en va ? Chaque réponse laisse une trace dans Git.
+
+
+
Le rythme de la construction
57 jours avec des commits · une barre par jour
+
+
JUIN 21 commitsJUILLET 151 commitsAOÛT 310 commitsSEPTEMBRE 159 commits
+
+
+
+
+
+
CHAPITRE 0124 — 30 juin 2026
+
Le plan précède la machine.
+
L’histoire visible commence le 24 juin. Le premier commit arrive avec 308 fichiers : des rôles Ansible, un générateur d’inventaire, une interface web et des modèles. Git ouvre donc sur un projet déjà construit en partie. Il ne raconte pas le travail qui l’a précédé.
+
L’intention, elle, est déjà nette : bâtir un écosystème souverain sur Proxmox, à partir d’un plan. Le gabarit Debian est sa fondation ; l’application et ses relations donnent la forme de l’ensemble. L’inventaire devient un résultat que le moteur produit.
+
Le 30 juin, les ressources des VM se calculent depuis les logiciels, les instances peuvent se succéder dans le même moteur et leur index commence à ordonner l’adressage. Un plancher /etc/hosts apporte une indépendance essentielle : les machines peuvent se nommer avant que leur DNS soit debout.
+
Ce qui changeLe savoir nécessaire pour reconstruire commence à quitter les machines pour entrer dans le plan.
Les premiers déploiements réels font apparaître ce qu’une vérification de syntaxe ne peut voir : paquets manquants, secrets mal raccordés, certificats à remplacer. Les rôles se confrontent à Debian et aux services qu’ils doivent réellement faire fonctionner.
+
Le courriel oblige à choisir. Un premier prototype utilise Stalwart ; le 2 juillet, le projet documente les obstacles rencontrés et pivote vers Postfix, Dovecot et rspamd. Le critère est opérationnel : une configuration maîtrisable, reproductible, adaptée à un service critique. Ce choix appartient à ce moment du projet, pas à un jugement intemporel sur un logiciel.
+
Postfix→Dovecot+rspamd↔LDAP
+
Keycloak se fédère à l’annuaire. Grafana et Forgejo rejoignent le SSO. Les bases, les certificats et les expositions web sont reliés par le plan. Les sauvegardes restic et la pile Icinga entrent dans l’ensemble. Le 7 juillet, un orchestrateur ordonne le déploiement et les flux réseau commencent à dicter les pare-feu.
+
La licence change aussi, le 2 juillet : l’AGPLv3 remplace la licence initiale. Le dépôt affirme un modèle de logiciel libre accompagné de services.
Le 20 juillet, le projet commence à auditer ses propres paroles. Le parcours de démarrage renvoie parfois au mauvais endroit ; le code et la documentation ne sont pas toujours d’accord. Un registre d’affirmations relie les promesses publiques à des moyens de les vérifier. make prouver produit un rapport rejouable.
+
Les premières preuves examinent la cohérence du dépôt. Leur périmètre s’élargit bientôt : les autres instances et les modèles doivent aussi tenir. Un protocole est écrit pour qu’un administrateur extérieur puisse, un jour, éprouver le parcours sans aide de l’auteur.
+
Le 23 juillet, une autre duplication disparaît : sous-réseaux, passerelles et VLAN cessent d’être des valeurs recopiées dans la nomenclature. Ils sont dérivés d’un index. Le lendemain, le réseau physique de l’hébergeur acquiert sa propre description, distincte du plan des locataires.
+
Ce qui changeLa documentation devient un engagement vérifiable. Les données dérivables cessent d’être des réglages à recopier.
Le plan descend jusqu’aux commutateurs et à la frontière OPNsense. Les devis doivent maintenant parler le dialecte du matériel réel. Une commande plausible ne suffit plus : il faut vérifier qu’elle existe, qu’elle est acceptée et qu’elle produit l’effet attendu.
+
Une limite des commutateurs force une décision d’architecture. Le mécanisme d’isolation envisagé ne peut pas être appliqué comme prévu sur leurs interfaces de routage. Le 3 août, le routage des locataires est réorienté vers Proxmox SDN et EVPN, avec des tables de routage séparées. Ce commit fixe une cible ; les suivants construisent et corrigent sa mise en œuvre.
+
Le pare-feu Proxmox reçoit lui aussi ses règles depuis le registre des flux. Le 6 août, les applicateurs apprennent à créer, modifier et retirer. La convergence inclut enfin la disparition de ce que le plan ne demande plus.
+
Ce qui changeLes contraintes mesurées du matériel transforment l’architecture. Une déclaration doit arriver jusqu’au paquet réseau.
Le 8 août marque une bascule de méthode. La politique de mot de passe est déclarée mais mal appliquée. L’autorité sert un certificat expiré depuis plus de huit heures. Le dépôt possède pourtant ses contrôles. Ils vérifient le code ; ils n’interrogent pas le service.
+
Les devis de service naissent de cet écart. Ils relèvent l’identité, les certificats réellement servis, les expositions, la base et le courriel, puis comparent le réel au déclaré. La règle devient : écrire, relire, comparer.
+
Le 9 août, quatorze VM sont détruites et reconstruites. Les cinq devis retrouvent le verdict de référence, avec une intervention sur la base de Grafana consignée dans le commit. Le même jour, un rejeu atteint zéro modification sur la flotte : le nombre de tâches exécutées est contrôlé pour s’assurer que ce zéro ne vient pas d’un déploiement qui n’aurait rien fait.
+
0tâche modifiée au troisième passage 14 hôtes · 9 août
37 minreconstruction sans intervention 43 groupes · 13 août
+
Le 13 août, la reconstruction se déroule d’un trait. Les défauts de premier démarrage ont été exposés puis corrigés. La capacité de repartir de zéro a désormais une épreuve documentée.
Le 20 août, une CI est ajoutée. Sa préparation pose une question simple : un clone public, sans l’environnement du mainteneur, passe-t-il ses propres vérifications ? L’essai révèle cinq défauts. La portabilité cesse de se déduire du bon fonctionnement d’une seule installation.
+
Le lendemain, le projet nomme son génome : les dépôts nécessaires à sa reproduction. Puis un runner apprend à l’exécuter. Posséder une copie du code ne suffit pas ; l’écosystème doit avoir les outils et les accès lui permettant de s’en servir.
+
01 / LE PLAN
Calculer
Produire l’inventaire depuis les déclarations.
02 / LE LOCATAIRE
Configurer
Appliquer les services avec sa propre voûte.
03 / LE SITE
Matérialiser
Créer les VM avec les accès à la fabric.
+
Les pouvoirs se séparent entre site et locataire. Le 28 août, un ancien mot de passe partagé entre plusieurs voûtes est remplacé par des clés distinctes. Le même moteur peut tourner partout ; les secrets présents bornent sa portée. L’amorçage d’un nouveau runner est codifié, au lieu de rester une opération connue du seul mainteneur.
+
La filiation, la mutualisation et l’émancipation deviennent des états explicites. Un petit écosystème peut emprunter des services au site, puis reprendre certaines fonctions chez lui. Dans le même mouvement, Collabora passe en natif : la dernière exception conteneurisée disparaît.
Le gabarit doré avait grossi jusqu’à recopier le socle et son durcissement. Il devient minimal le 1er septembre : quatre rôles, juste ce qui doit exister avant qu’Ansible puisse agir. Le reste revient aux playbooks de conformité. Le 9, cloud-init est retiré des machines après leur naissance, pour qu’il ne réapplique plus une configuration concurrente au démarrage.
+
Les sauvegardes quittent la flotte du locataire pour le dépôt du site. Leur vérification suit un principe précis : celui qui détient la clé juge le contenu. L’hébergeur peut vérifier que son stockage reçoit des écritures ; il ne peut pas lire à la place du locataire ses instantanés chiffrés.
+
L’observabilité remonte dans l’ordre de déploiement, juste après la confiance PKI. La reconstruction doit être observable pendant qu’elle se déroule. Puis vient l’épreuve des fondations : le 12 septembre, les VM du site d’hébergement sont elles-mêmes reconstruites depuis zéro.
+
16défauts révélés au premier tour du site · 12 septembre
37′24″au troisième tour, sans nouveau défaut deux passages documentés
+
La première tentative découvre seize obstacles. La deuxième en trouve deux autres et corrige le runbook. La troisième aboutit sans nouveau défaut. Les hyperviseurs et la frontière ne sont pas reconstruits par cette épreuve : son périmètre est celui des machines virtuelles du site.
La console devient un service du runner. Sa publication oblige à rendre explicite son authentification : le jeton de la page protège les requêtes, il n’identifie pas l’utilisateur. Une entrée protégée est ajoutée ; la console distingue ensuite ce qu’un site et un locataire ont le pouvoir de faire.
+
Le 16 septembre, la remise au client prend une forme exécutable. D’abord l’identité, puis la machine à une échéance inscrite. La clé du client entre, celle de l’exploitant sort, la voûte change de clé. Un registre nomme le responsable et une preuve surveille les engagements de remise.
+
Les zones DNS publiques se construisent autour du même partage : le locataire écrit et signe, le site sert. Le matériel rejoint la supervision avec ses températures et ses capteurs. Enfin, l’administration entre par des tunnels WireGuard nominatifs, déclinés par locataire et limités à son réseau.
+
Le dernier commit du corpus corrige un petit paradoxe : le premier pair VPN ne pouvait pas obtenir d’adresse parce qu’aucun pair n’existait encore. Jusqu’au bout, le premier usage réel révèle ce que le cas déjà installé ne montre pas.
+
Ce qui changeLa souveraineté prend une forme concrète : des pouvoirs séparés, des accès révocables et une procédure pour les transmettre.
Retrouvez une décision, un service ou un incident dans les 641 titres originaux. Du plus récent au plus ancien.
+
+
+
+
+
+
+
+
+
+
Méthode & provenance
Une histoire située. Des traces consultables.
+
Cette chronique est une lecture éditoriale de l’historique Git, des messages des commits charnières et du changelog. Les huit chapitres sont un découpage du récit, pas des versions officielles du logiciel.
Le corpus contient les 641 commits accessibles depuis 05b85eb, fusions comprises. Les dates sont les dates d’auteur conservées par Git. Les 86 jours couvrent les deux bornes, du 24 juin au 17 septembre 2026 ; ils ne mesurent pas un temps de travail. Le graphique compte les commits par jour, pas leur importance.
Les liens « Traces Git » affichent le titre original, la date et l’identifiant complet. Depuis un clone du dépôt, git show <identifiant> permet de relire le message et le changement. Cette page conserve un instantané ; les commits ultérieurs n’y sont pas ajoutés automatiquement.
Le premier commit contient déjà un ensemble substantiel. Cette chronique ne reconstitue pas une genèse antérieure que Git ne documente pas. Projet porté par Daniel Allaire · Chezlepro / Alliance Boréale.
+
+
+
Ce que cette histoire ne prouve pas.
+
Les résultats de reconstruction sont ceux consignés à leur date. Les 82 preuves du rapport du 17 septembre portent sur la cohérence du dépôt ; elles ne constituent pas un contrôle en direct de la flotte.
+
Une reconstruction réussie ne démontre ni la tenue sous charge, ni toutes les mises à jour à venir. L’épreuve par un opérateur indépendant reste un protocole dans les documents consultés. La convergence demeure pilotée par un humain : le projet ne revendique pas une boucle d’auto-réparation.
+
Le récit s’arrête au commit 05b85eb. Il laisse visibles les erreurs et les changements de direction qui ont fait évoluer le moteur.
+
+ La suite reste à écrire
Construire. Relire. Pouvoir transmettre.
Au terme de ces 641 commits, Set-OPS porte des services et la mémoire de ce qu’il a fallu apprendre pour les faire tenir ensemble.