Set-OPS-Public/docs/ecosysteme-chezlepro.md

L'écosystème numérique Chezlepro

Pour qui : le lecteur externe — client, partenaire, évaluateur. Ce n'est pas un document technique.

Document de présentation — souveraineté et sécurité

En une phrase

Chezlepro est un écosystème numérique souverain : une infrastructure interne complète — identité, confiance, nommage, données, communication, observabilité, applications — hébergée sur sa propre grappe Proxmox, sans dépendance à un service en nuage tiers, entièrement décrite en code et reconstructible à volonté.

Le moteur qui la construit et l'entretient s'appelle Set-OPS. Il est libre, réutilisable par n'importe quel hébergeur, et s'exploite entièrement à la main : la documentation, les commandes make et l'interface locale suffisent. L'outil libère de la dépendance aux géants du numérique ; il ne la remplace pas par une dépendance à une intelligence artificielle.

---

Pourquoi un écosystème, et pas seulement des serveurs

La plupart des organisations louent leur identité, leurs courriels, leurs noms de domaine et leur confiance numérique à quelques fournisseurs étrangers. Chaque brique louée est une dépendance, un coût récurrent et une perte de contrôle.

Chezlepro renverse cette logique : chaque pilier de l'infrastructure est hébergé et maîtrisé en interne, et les piliers sont reliés entre eux comme un tout cohérent.

Pilier	Ce qu'il apporte
Identité	Annuaire interne (LDAP) et authentification unique (SSO) : un seul compte, partout.
Confiance	Autorité de certification interne (PKI/ACME) : les serveurs se reconnaissent par certificats émis localement, sans acheter de confiance à l'extérieur.
Nommage	DNS interne : des noms de machines stables et dérivables, plutôt que des adresses IP fragiles.
Données	Bases relationnelles et cache, avec un registre des connexions applicatives.
Communication	Service de courriel souverain : boîtes adossées à l'annuaire, réception SMTP, lecture IMAP, antispam et signature DKIM. Le relais des alertes système en est distinct.
Observabilité	Métriques, journaux centralisés, tableaux de bord et supervision active.
Applicatif	Services internes (forge logicielle, collaboration documentaire) derrière une couche web sécurisée.

Tous ces services sont libres : OpenLDAP, Keycloak, step-ca, PowerDNS, Unbound, PostgreSQL, Redis, NGINX, Postfix, Dovecot, rspamd, Prometheus, Loki, Grafana, Icinga, Forgejo, Nextcloud, Collabora, restic. Aucun verrou propriétaire, aucune licence captive, et aucun conteneur — tout est installé nativement, en paquets et unités systemd.

(Cette liste nommait Sendmail jusqu'au 2026-09-06 : ce rôle a été retiré le 2026-07-04, supersédé par Postfix.)

---

Comment c'est construit : reproductible par conception

Rien n'est configuré « à la main » sur un serveur. Tout part d'un plan déclaratif — quelques fichiers lisibles qui décrivent l'état voulu de l'infrastructure (les serveurs, les applications, les bases de données, les domaines). À partir de ce plan :

1. l'inventaire des machines est généré automatiquement ;
2. chaque VM est clonée depuis un modèle Debian de référence (« golden template ») durci une fois pour toutes ;
3. sa configuration réelle est appliquée par Ansible, de façon idempotente (on peut la relancer sans effet de bord).

Conséquence concrète pour la résilience : si une machine est perdue, elle se reconstruit à l'identique depuis le plan et le code. L'infrastructure n'est pas un objet fragile patiemment bricolé — c'est un artefact reproductible.

Honnêteté sur le statut — mise à jour le 2026-09-06. Ce paragraphe disait, bien après que ce fut faux, que l'écosystème n'avait « pas encore été éprouvé sur des machines réelles ». Il l'a été : la flotte entière a été rasée et remontée depuis zéro le 2026-08-13, puis deux fois le 2026-09-02 — 15/15 puis 14/14 machines, zéro échec, et la validation complète à zéro échec sur treize hôtes. La reconstruction n'est donc pas une promesse de conception : c'est une manœuvre exécutée, chronométrée et rejouée.

Ce qui reste honnête à dire : la reconstruction prouve qu'un plan mène des machines nues à l'état voulu. Elle ne dit rien de la tenue d'un service sous charge, ni de sa mise à jour dans la durée — deux questions distinctes, et non traitées ici. Le degré de maturité, service par service, est tenu à jour dans docs/catalogue-services.md, et nous ne présentons jamais comme « en production » un service que ce tableau ne donne pas pour tel.

---

Mesures de renforcement (durcissement)

La sécurité n'est pas une couche ajoutée après coup : elle est intégrée dès le socle commun de chaque machine, puis renforcée par un groupe de durcissement appliqué aux serveurs. Voici les mesures réellement en place dans le moteur.

1. Accès SSH verrouillé

L'accès distant est la porte d'entrée la plus exposée ; elle est fermée par défaut à tout ce qui n'est pas strictement nécessaire.

• Authentification par clé uniquement — le mot de passe est désactivé (PasswordAuthentication no, AuthenticationMethods publickey).
• Connexion root interdite (PermitRootLogin no), pas de mots de passe vides, pas d'authentification par hôte.
• Aucune redirection : X11, agent, ports TCP, tunnels, sockets — tout est désactivé.
• Sessions limitées : déconnexion automatique des sessions inactives, nombre de tentatives plafonné (MaxAuthTries 3), délai de grâce court (LoginGraceTime 20s), sessions simultanées limitées.
• Garde-fou opérationnel : toute modification SSH est validée (sshd -t) avant d'être rechargée, et l'authentification par mot de passe n'est jamais coupée avant d'avoir confirmé que l'accès par clé fonctionne — pour ne jamais se verrouiller dehors.

2. Protection contre le brute-force

• fail2ban surveille les tentatives de connexion SSH et bannit automatiquement les adresses fautives (5 échecs en 10 min → bannissement d'1 h).

3. Durcissement du noyau (sysctl)

Une trentaine de paramètres noyau resserrent le comportement du système et du réseau, notamment :

• Réseau : rejet des redirections et du routage par la source ICMP/IP, protection anti-spoofing (rp_filter), cookies SYN contre les inondations, journalisation des paquets « martiens », rejet des broadcasts ICMP.
• Noyau : ASLR activé (randomize_va_space), restriction de dmesg et des pointeurs noyau, blocage de Ctrl-Alt-Suppr, restriction de perf_event.
• Système de fichiers : protection des liens durs/symboliques, des FIFO et fichiers réguliers, interdiction des core dumps SUID.

4. Pare-feu prêt, activé au bon moment

• nftables est volontairement désactivé dans le modèle — on n'active jamais un pare-feu générique sans connaître la fonction réelle de la machine — et armé sur chaque serveur de la flotte, en politique « tout refuser » par défaut.
• Ses règles ne sont pas écrites à la main. Chaque rôle déclare ce qu'il écoute et ce à quoi il se connecte ; le jeu de règles en est dérivé. Le même registre alimente le pare-feu de l'hyperviseur et la frontière du site : trois couches de filtrage qui ne peuvent pas se contredire, parce qu'elles descendent d'une seule décision. C'est aussi ce qui produit la matrice d'accès réseau exigée par un audit de sécurité — source, destination, port, chiffrement et raison, pour chaque flux autorisé.

5. Confinement et intégrité

• AppArmor : confinement des applications par profils.
• auditd : journalisation d'audit du système avec un jeu de règles Set-OPS.
• debsums / needrestart / apt-listchanges : vérification de l'intégrité des paquets et détection des services à redémarrer après mise à jour.

6. Mises à jour de sécurité automatiques

• unattended-upgrades applique automatiquement les correctifs de sécurité Debian. Le redémarrage automatique reste désactivé par défaut (décision laissée à l'opérateur), et les dépendances inutilisées sont nettoyées.

7. Journalisation maîtrisée

• journald est borné (rétention et taille plafonnées) pour garder des traces utiles sans saturer le disque. Les journaux peuvent ensuite être centralisés vers Loki.

8. Politique de mots de passe et gestion des secrets

• libpam-pwquality impose une qualité minimale des mots de passe locaux.
• Aucun secret n'est stocké en clair dans le code. Mots de passe, clés privées, jetons et certificats sont gérés hors dépôt (Ansible Vault, fichiers locaux non versionnés, gestionnaire de secrets). Le modèle de VM ne contient ni données de clone, ni secret, ni clé privée.

9. Garde-fous sur les actions destructives

• Toute opération risquée (modification bloquante de SSH, activation d'un pare-feu, suppression d'utilisateurs ou de paquets critiques, formatage, purge de données, redémarrage massif, opérations de stockage…) exige une confirmation explicite. Sans elle, l'exécution est refusée.

10. Sécurité par l'architecture

Au-delà des réglages machine, l'architecture elle-même est une mesure de sécurité :

• Tout service exposé en HTTP(S) passe par un point d'entrée unique (NGINX en mandataire inverse, terminaison TLS, WAF) plutôt que d'être exposé directement.
• Authentification centralisée : les services à accès humain se branchent au SSO, ce qui évite la multiplication des comptes et des mots de passe dispersés.
• Certificats internes : les services se font confiance via la PKI interne, sans exposer de secrets à des autorités externes.
• Dépendances déclarées : un service ne se déploie pas si ses prérequis (DNS, PKI…) ne sont pas réellement actifs — ce qui évite les états incohérents.
• Source unique de vérité : l'état voulu vit dans des registres lisibles, versionnés par Git, qui sert de filet en cas d'erreur.
• Les sauvegardes sortent du site. L'état non régénérable (clés de l'autorité, annuaire, bases, boîtes, forge) est sauvegardé chiffré côté client vers un dépôt hors-machine, puis emporté hors du bâtiment. Chaque nœud vérifie lui-même son propre dépôt distant : celui qui héberge les octets ne peut pas les lire, donc ne peut pas les juger.
• Ce qu'on affirme, on le prouve. Un harnais de 57 vérifications rejoue à la demande ce que le dépôt promet et produit une pièce justificative datée ; dix « devis » interrogent en plus le système déployé pour confirmer qu'il ressemble à ce qui est déclaré.

---

Souveraineté jusqu'au bout

Trois principes résument la posture de Chezlepro :

1. Tout est libre. Aucune brique propriétaire, aucune licence captive.
2. Aucune dépendance externe pour les fonctions vitales — confiance, identité, nom, communication sont hébergées et maîtrisées en interne.
3. Exploitable sans IA, par un humain. La documentation, make et l'interface locale forment l'interface complète. L'intelligence artificielle n'assiste éventuellement que le mainteneur de l'outil — jamais l'utilisateur final, qui reste pleinement autonome.

---

Détails techniques et runbooks : voir AGENTS.md (autorité du dépôt), docs/catalogue-services.md, docs/plan-et-generation.md, docs/positionnement.md.