Recentrer ce dépôt sur l'infrastructure, pas sur les sites

Ce dépôt parle du serveur ; les sites parlent d'eux-mêmes dans leur propre
dépôt. Dupliquer leurs procédures ici garantissait qu'elles divergent.

Sortent donc : les procédures de déploiement détaillées de static et du wiki,
et la section « développement local ». À leur place, un tableau qui dit
seulement **où** chercher — y compris pour la messagerie, dont le paragraphe
d'avertissement ajouté ce matin décrivait le site et non la machine.

Le courrier sortant, les certificats et les sauvegardes deviennent des renvois
vers infra/docs/, où le détail vit désormais. Trois sections que j'avais
écrites ici ce matin et qui y faisaient double emploi : une information écrite
à deux endroits est une information qui sera fausse à l'un des deux.

Restent ce qui est propre à la machine : le serveur lui-même, les bases, le
SSO, les comptes, les credentials, et la carte de ce qu'elle héberge.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SFbwnJurBwTs7x7t93ecku

README.md

@@ -33,63 +33,28 @@ Ces projets ont leur propre dossier, au même niveau que celui-ci — un dépôt
 
 Leurs procédures de déploiement sont décrites dans leur propre README.
 
-> **La messagerie ne se déploie pas comme les autres.** owni n'en est pas un
-> clone : la mise à jour s'y fait par **copie de fichiers, base d'abord, code
-> ensuite**, et non par `git pull`. La procédure et les pièges qu'elle
-> désamorce sont dans `docs/installation.md` de ce dépôt. En service depuis le
-> 22/09/2026 — 256 abonnés, un worker appelé chaque minute, trois boîtes
-> relevées en IMAP : ce qui casse casse pour de vrai.
-
 Gitea : **https://gitea.alpinux.org/alpinux.cedrica5l**  
 ISPConfig : **https://owni.alpinux.org:8080**  
 AlpID (SSO) : **https://alpid.alpinux.org** — realm `master`
 
 ---
 
-## Procédure de déploiement
+## Déployer un site
 
-### Vue d'ensemble
+**Chaque projet décrit son déploiement dans son propre dépôt.** Ce dépôt-ci
+parle du serveur, pas des sites qu'il héberge : dupliquer les procédures ici
+garantirait qu'elles divergent.
 
-| Projet | Méthode | Commande |
-|--------|---------|----------|
-| `home` | git pull sur serveur | `ssh alpinux.org "cd <web root> && git pull"` |
-| `static` (app) | rsync local + restart | `cd ~/Projects/alpinux.static && scripts/deploy-app.sh` |
-| `static` (assets) | rsync local | `cd ~/Projects/alpinux.static && scripts/push-assets.sh` |
+| Projet | Où est la procédure |
+|---|---|
+| `static` | `alpinux-static/README.md` — `scripts/deploy-app.sh`, `scripts/push-assets.sh` |
+| `wiki` | webhook Gitea à chaque push ; <https://wiki.alpinux.org/technique/deploiement-wiki/> |
+| `home` | `git pull` sur le serveur |
+| `messagerie` | `alpinux.messagerie/docs/installation.md` — **copie de fichiers, base d'abord** |
+| autres | le README du dépôt concerné |
 
 Dans tous les cas : versionner avec `git push` **avant** de déployer.
 
-### static.alpinux.org
-
-Le détail (app Flask et assets CDN) est dans `~/Projects/alpinux.static/README.md`.
-
-```bash
-cd ~/Projects/alpinux.static
-git push origin main         # versionner d'abord
-scripts/deploy-app.sh        # app Flask → /opt/static-cdn + restart service
-scripts/push-assets.sh       # logo/, wiki/, stats/, error/ → web root ISPConfig
-```
-
-### Wiki
-
-Rien à faire : un webhook Gitea construit et met en ligne à chaque push sur `main`.
-Voir https://wiki.alpinux.org/technique/deploiement-wiki/
-
----
-
-## Développement local
-
-| Projet | Commande | URL |
-|--------|----------|-----|
-| `~/Projects/alpinux.static` | `python app/app.py` | http://localhost:5003 |
-
-```bash
-cd <projet>
-python3 -m venv venv && source venv/bin/activate
-pip install -r requirements.txt
-cp .env.example .env && nano .env
-flask run --port <port>
-```
-
 ---
 
 ## Authentification AlpID
@@ -173,31 +138,24 @@ Cloud-init réseau désactivé : `/etc/cloud/cloud.cfg.d/99-disable-network-conf
 
 ---
 
-## Courrier sortant : tout passe par un relais
+## Courrier sortant
 
-**Depuis les 25-26 septembre 2026**, Postfix ne remet plus directement aux
-destinataires : `relayhost = [mail.acemail.fr]:587`, en soumission
-authentifiée.
+Tout le courrier de la machine passe par un relais depuis les 25-26/09/2026
+(`mail.acemail.fr`), et l'IP qui parle aux destinataires n'est plus celle
+d'owni. SPF, DKIM, DMARC, les plafonds de Postfix, les boîtes du service et
+les pièges qui vont avec :
 
-| | |
-|---|---|
-| **IP qui parle aux destinataires** | `176.9.125.188` (le relais), et non plus `51.91.79.148` |
-| **SPF** | `v=spf1 a mx include:_spf.acemail.fr -all` |
-| **DKIM** | signé par owni **avant** la remise au relais |
-| **DMARC** | `p=quarantine`, `rua=mailto:postmaster@alpinux.org` |
+→ **[infra/docs/courrier-sortant.md](https://gitea.alpinux.org/alpinux.cedrica5l/alpinux-infra/src/branch/main/docs/courrier-sortant.md)**
 
-Trois conséquences qu'il vaut mieux connaître avant de chercher ailleurs :
+---
 
-- **La réputation d'expéditeur n'est plus la nôtre seule.** Un rejet de plus
-  compte contre une IP partagée avec les autres clients de l'hébergeur.
-- **Un plafond d'envoi s'ajoute à celui de Postfix**, celui du relais, et il
-  n'est pas connu à ce jour. Le franchir se verrait en `status=deferred` dans
-  `/var/log/mail.log`, avec un code `4.x.x` venu du relais.
-- **L'enveloppe doit survivre au relais.** La messagerie utilise des adresses
-  de retour variables (`bounce+<référence>@alpinux.org`) pour identifier les
-  non-remises. Vérifié le 27/09 : le relais les préserve. À revérifier après
-  tout changement chez l'hébergeur — la panne serait silencieuse, les rebonds
-  cessant simplement d'arriver.
+## Certificats TLS
+
+Deux mécanismes coexistent — un certificat certbot multi-domaines pour huit
+sites, un certificat par site émis par ISPConfig via acme.sh — avec un piège
+qui a déjà cassé deux fois le HTTPS d'un site pendant plusieurs semaines.
+
+→ **[infra/docs/certificats.md](https://gitea.alpinux.org/alpinux.cedrica5l/alpinux-infra/src/branch/main/docs/certificats.md)**
 
 ---
 
@@ -220,22 +178,17 @@ S'y ajoutent `dbispconfig`, `roundcube` et `phpmyadmin`.
 
 ---
 
-## Sauvegardes : ce qui est couvert, et ce qui ne l'est pas
+## Sauvegardes
 
-État au 27/09/2026, à corriger — voir le ticket
-[#1](https://gitea.alpinux.org/alpinux.cedrica5l/alpinux-owni/issues/1).
+Les sept bases sont tirées chaque nuit vers le poste par
+`infra/scripts/sauvegarder-owni.sh`. La procédure de **restauration** — et ses
+pièges, dont le worker de la messagerie qui réexpédierait une campagne — est
+écrite à côté :
 
-- **Une base sur six** est sauvegardée quotidiennement, la messagerie, dans
-  `/var/backup/web21/`. Les cinq autres ne le sont pas, Dolibarr et Gitea
-  compris.
-- **Une seule copie conservée** (`backup_copies = 1`) : une corruption
-  remarquée deux jours plus tard n'est plus récupérable.
-- **Les 14 sites sont à `backup_interval = none`** côté fichiers.
-- **Tout reste sur owni.** Un disque perdu emporte les données et leurs
-  copies. Ce que contient `/var/backup/ispconfig/` ne concerne qu'ISPConfig
-  lui-même.
+→ **[infra/docs/sauvegardes.md](https://gitea.alpinux.org/alpinux.cedrica5l/alpinux-infra/src/branch/main/docs/sauvegardes.md)**
 
-Une sauvegarde qu'on n'a jamais restaurée est une hypothèse, pas une garantie.
+Ce qui n'est **pas** sauvegardé : les fichiers des sites, les boîtes mail,
+`/etc`. Ce sont des choix, écrits comme tels dans le document.
 
 ---