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.