Ce qui tourne, et pourquoi¶
Le parc compte six hôtes Docker, environ trois cents conteneurs, un hyperviseur et une équipe d'agents IA (relevé du 2026-10-06). Énumérer les conteneurs ne dirait pas grand-chose ; cette page procède autrement et parcourt le parc par capacité. Pour chacune, elle donne ce qui est en place et ce qui a fait poser la brique. Presque toujours, c'est un incident ou un manque qu'on a mesuré, rarement une envie d'outil.
Ce que cette page tait
Elle nomme les outils, mais ne donne ni version, ni adresse, ni port, ni règle de détection, et ne signale aucun écart encore ouvert. Une architecture se raconte ; une liste de versions exposées est une liste de CVE à essayer. Le détail vit dans le vault privé.
En un coup d'œil¶
| Capacité | Ce qui la porte | Pour aller plus loin |
|---|---|---|
| Détection et réponse | SIEM, détection comportementale, inventaire, investigation à distance, bannissement HTTP | Détection · Réponse |
| Secrets | Deux coffres : machines et humains | Lire un secret |
| Sauvegardes | Un dépôt chiffré par hôte, copie hors site | Continuité |
| Supervision et alertes | Métriques, sondes de bout en bout, santé des disques, un point d'entrée pour les notifications | Câbler une notification |
| Identité et accès | SSO, réseau maillé auto-hébergé | Sécurité |
| Exposition web | Reverse proxy à deux étages, un enregistrement DNS par nom | Chaîne reverse proxy |
| Tickets | Boucle détection → ticket → correctif → preuve | — |
| Agents IA | Une équipe d'agents dans un bac à sable | Agents |
| Modèles de langage | Inférence locale sur GPU, passerelle unique | Agents |
| Automatisation | Workflows | — |
| Code | Forge auto-hébergée, miroir de partage | Intégration continue |
| Hôtes | Hyperviseur, mises à jour nocturnes autonomes | Hôtes du parc |
| Connaissance | Un vault source, un wiki interne, ce site | Où écrire quoi |
Détection et réponse¶
Wazuh joue le rôle de SIEM : intégrité des fichiers, vulnérabilités connues, corrélation avec MITRE ATT&CK. Falco observe le comportement des processus au niveau du noyau, et osquery tient l'inventaire des hôtes, qu'il remonte dans Wazuh. Velociraptor sert à poser une question à tout le parc pendant un incident. CrowdSec bannit au niveau HTTP.
Pourquoi. Wazuh répond, en juin 2026, au besoin d'auditer les hôtes eux-mêmes et non plus seulement les services. Velociraptor vient d'une panne de système de fichiers, le 2026-08-24 : elle a coûté neuf heures parce qu'il fallait aller interroger chaque machine une par une. CrowdSec, enfin, part d'un constat simple : des dizaines de noms publics, et aucun système de prévention d'intrusion devant eux.
Falco suit une règle d'introduction propre au parc : chaque nouvel hôte commence en collecte seule, le temps de mesurer son bruit pendant 24 heures. On pose ensuite les exceptions, nommées une par une, et c'est seulement alors que la notification est armée. Une alerte qui sonne pour rien finit par ne plus être lue.
Secrets¶
Les secrets machines (clés d'API, mots de passe de service, jetons) sont dans OpenBao, sur une machine qui ne fait que ça. Ils descendent jusqu'aux conteneurs sous forme de fichiers chiffrés SOPS. Les secrets humains (comptes web, codes de secours) sont dans Vaultwarden.
Pourquoi. La séparation date du 2026-09-27. Un secret qu'une machine lit et un secret qu'une personne tape n'ont ni le même cycle de vie, ni le même rythme de rotation, ni les mêmes lecteurs. Le coffre machine est en outre tenu hors du démarrage : chaque hôte garde sa copie chiffrée, si bien qu'un coffre éteint retarde les rotations sans empêcher le parc de redémarrer.
Sauvegardes¶
restic, piloté par Backrest, sauvegarde six hôtes, chacun dans son propre dépôt chiffré, vers le NAS. Une copie part hors site, hors de portée des hôtes sauvegardés. Le NAS ajoute ses propres instantanés de volume.
Pourquoi. Le runbook de sauvegarde par hôte est resté à l'état « prévu » pendant des semaines, pendant que les données s'accumulaient. Les niveaux de sauvegarde et la restauration chronométrée sont décrits dans Continuité.
Supervision et alertes¶
Prometheus collecte les métriques des hôtes et porte les règles d'alerte versionnées. Gatus sonde les services de bout en bout et alimente une page de statut publique. Scrutiny suit la santé SMART des disques physiques. Un tableau du matin rassemble l'état des hôtes et les derniers incidents. alerts-hub est le point d'entrée unique des notifications : un seul appel, et le message part vers la messagerie du bon canal.
Pourquoi. Le 2026-08-14, le parc ne comptait aucune règle d'alerte. Quarante et un arrêts par manque de mémoire ont été découverts le lendemain, sur une capture d'écran. Pour les sondes publiques, la décision du 2026-09-16 est de mesurer la chaîne entière (DNS, proxy, application), parce qu'un service peut être sain derrière un chemin cassé.
Identité et accès¶
Authentik fournit le SSO. Pour tout nouveau service, la règle est OIDC d'abord. Le forward auth (un mur devant l'application) reste un dernier recours, et on n'empile jamais les deux. Le réseau privé entre les hôtes passe par un tailnet piloté par Headscale, auto-hébergé.
Pourquoi. Le forward auth ne transmet aucune identité à l'application : pas de compte, pas de rôle, pas de vraie déconnexion. Combiné à OIDC, il intercepte le retour de connexion et provoque une boucle. Headscale a remplacé le service hébergé le 2026-08-19 : des clés de nœud qui n'expirent plus en silence, des listes d'accès versionnées, et OIDC sans abonnement.
Exposition web¶
Une requête venue d'Internet traverse deux étages de Caddy. Le premier tient la bordure, le second sert les services internes. Les certificats sont émis par défi DNS. Chaque nom public porte son propre enregistrement DNS : il n'y a aucun joker dans la zone.
Pourquoi. La règle du 2026-09-10 est simple : un nom n'est exposé que si quelqu'un l'a décidé, pour ce nom précis. Un joker expose par défaut tout ce qu'on oublie. Le détail est dans Chaîne reverse proxy.
Tickets¶
Ce qui est détecté automatiquement ouvre et ferme son propre ticket, par calcul, avec une hystérésis pour ne pas battre au rythme des sondes. Ce qui est trouvé en séance de travail ouvre un ticket à la main, et ce ticket ne se ferme qu'avec une résolution écrite : comment le vérifier. Un agent de tri répartit la file.
Pourquoi. Fin août 2026, 529 notes portaient encore le statut « ouvert », et plus rien ne recalculait ce statut. Un état qu'on déclare dans un système capable de le calculer finit toujours par mentir.
Agents IA¶
Une équipe d'agents IA, baptisée en interne STA Inc, tourne à raison d'un conteneur par agent, sur une VM bac à sable dédiée. Chaque agent ne reçoit que ses propres jetons ; les secrets du parc ne sont pas sur cette VM. Les agents prennent leur travail dans Vikunja. Parmi eux, Clio, la documentaliste, mesure la couverture de la documentation et comble les manques.
Pourquoi. Le 2026-10-02, il est apparu qu'un agent lancé depuis la VM de développement aurait eu accès à tous les secrets et à tous les hôtes. La VM dédiée referme ce rayon d'action. Les agents sont organisés en arbre, pour qu'aucun ne puisse se renvoyer une tâche en boucle.
Modèles de langage¶
Ollama sert des modèles en local, sur le GPU de l'hôte de calcul. LiteLLM est la passerelle unique de tout le parc : chaque appel, local ou vers un fournisseur externe, passe par elle, avec une clé par consommateur, un budget et un repli.
Pourquoi. La passerelle unique rend le coût et l'usage lisibles d'un seul endroit, et permet de changer de fournisseur sans toucher aux consommateurs. Elle est devenue un stack indépendant le 2026-09-28.
Automatisation¶
n8n porte les workflows : chaînes d'approbation, notifications, traitements de documents. Il ne parle à Docker qu'à travers un proxy de socket filtrant, jamais directement au socket.
Une règle tirée de l'expérience accompagne n8n : une tâche quotidienne qui doit tenir ne repose pas sur un déclencheur planifié de n8n, qui peut dériver. Elle passe par un timer système qui constate l'état et réessaie.
Code¶
Gitea, auto-hébergé, est la source de chaque dépôt. GitHub sert au partage. Un synchroniseur tourne toutes les cinq minutes dans les deux sens et ne force jamais rien.
Pourquoi. Un miroir à sens unique écrase en force : un merge fait côté GitHub aurait disparu au passage suivant (décision du 2026-09-27). Une appli qui a une interface a son dépôt à elle ; l'image construite en local a sa recette versionnée à côté de sa configuration.
Hôtes¶
Les VM tournent sur un hyperviseur Proxmox. Les hôtes Linux appliquent leurs mises à jour la nuit, sans intervention, et chaque nuit produit un rapport. La pile de l'hyperviseur reste mise à jour à la main, parce que ses scripts d'installation redémarrent les services de gestion.
Pourquoi. Jusqu'en septembre 2026, les VM tournaient sur un poste de bureau qui portait à lui seul plus de quatre-vingts conteneurs, sur un disque virtuel lent, pendant que l'autre hôte de calcul saturait. La migration vers l'hyperviseur, en septembre 2026, a déplacé cette charge sur du stockage local rapide.
Connaissance¶
Le vault, des notes Markdown sous git éditées dans Obsidian, est la source de toute la connaissance du parc : décisions datées, runbooks, environ 1 700 FAQ d'incidents. Un wiki interne en est le miroir lisible. Ce site en est la version relue et publique.
Pourquoi. Une FAQ naît d'un incident et raconte une enquête, avec ses fausses pistes ; sa place est dans le vault. Ce site n'en garde que ce qui reste vrai une fois l'enquête close. Le partage est détaillé dans Où écrire quoi.
Et pour l'usage quotidien¶
Le parc sert aussi : photothèque (Immich, dont l'analyse d'images tourne sur le GPU, environ dix fois plus vite qu'en CPU sur plus de quarante mille photos), domotique (Home Assistant, Node-RED, MQTT), médiathèque. Ce sont les services pour lesquels tout le reste existe.
Dernière vérification de cette page : 2026-10-06