Reprendre l'exploitation du guichet de demandes

1. Ce que vous reprenez

Un guichet de demandes GLPI 11 pour la mairie : demandes des administrés par email uniquement (boîte collecteur), interface web réservée aux agents/élus (2FA TOTP imposée), sur un VPS OVH dédié (Debian 12, Docker : Caddy → GLPI → MariaDB), sauvegardé chaque nuit (chiffré, hors du serveur) avec test de restauration mensuel automatique, supervisé par une sonde externe.

L'exploitation quotidienne se fait depuis n'importe quel hôte disposant du dossier projet + du .env (SSH vers le VPS). Le VPS lui-même est jetable : le provisioning et la restauration sont scriptés et le reconstruisent de zéro — c'est testé (plan de reprise après sinistre, RPO 24 h, RTO ≤ ½ journée).

1 bis. Ce que contient le dossier remis

Vous n'avez pas encore accès au dépôt : voici son contenu exact. Tout ce qui vous est remis tient dans cette arborescence — le .env (les secrets), transmis à part par canal sûr, est la seule pièce manquante.

gestion-de-lauris/
├── README.md            ← commencez ici : architecture + schéma
├── RUNBOOK.md           ← gestes courants : mise à jour, secrets, incidents
├── DRP.md               ← reprise après sinistre (perte serveur, corruption…)
├── HANDOVER.md          ← le dossier de transfert (version complète de cette page)
├── .env.example         ← toutes les variables attendues, documentées (sans valeurs)
├── migrate-domain.sh    ← LE script du jour J (bascule assistance.lauris.fr)
├── deploy/
│   ├── deploy.sh        ← (re)déploie la stack ; --provision pour un serveur vierge
│   ├── configure-glpi.sh← (re)configure GLPI de A à Z (comptes, collecteur, 2FA…)
│   └── templates/       ← Caddyfile, docker-compose, jails fail2ban…
├── backup/              ← backup.sh + restore.sh + timers (README dédié)
├── monitoring/          ← probe.sh + scheduler.sh + alertes (README dédié)
├── glpi/branding/       ← logos « Mairie de Lauris » montés dans le conteneur
└── docs/architecture.svg

Les 5 scripts, et quand les lancer :

Tout le reste (templates/, unités systemd, scripts d'alerte) est de la mécanique interne appelée par ces cinq-là — vous n'avez pas à y toucher.

Les 3 commandes du quotidien :

./monitoring/probe.sh --remote      # état de santé complet, après toute intervention
cd deploy/ && ./deploy.sh           # (re)déployer après un changement de .env
cd deploy/ && ./configure-glpi.sh   # (re)configurer GLPI après un changement de mot de passe

2. Inventaire des accès à transférer

3. Transfert du VPS — changement de contact OVH (zéro coupure)

Procédure OVH « changement de contact » sur le service VPS, depuis l'espace client du titulaire actuel : Tableau de bord → service VPS → Contacts → modifier — désigner le compte OVH du prestataire (ou de la mairie) comme contacts admin + tech + facturation. Validation par email des deux parties, effectif en quelques minutes. L'IP est conservée : aucune interruption, aucun changement DNS, la stack ne redémarre même pas.

Conditions OVH : comptes dans la même zone OVH (Europe), pas d'impayé, moyen de paiement valide côté destinataire.

Plan B (si le changement de contact est impossible ou non souhaité) : nouveau VPS chez vous + reconstruction scriptée — c'est le scénario 1 du plan de reprise après sinistre, environ 30 à 45 minutes de travail effectif. Ce plan B prouve au passage que le DRP fonctionne.

4. Sauvegardes — votre propre bucket S3

1. Créez un bucket S3 (OVH Object Storage ou compatible) + clés dédiées.
2. Renseignez dans le .env : S3_ENDPOINT, S3_REGION, S3_BUCKET, S3_ACCESS_KEY, S3_SECRET_KEY (et une nouvelle phrase de chiffrement si vous préférez — les anciennes archives restent alors lisibles seulement avec l'ancienne : conservez les deux au coffre pendant la rétention de 14 jours).
3. Redéployez (une commande), puis lancez une première sauvegarde et un test de restauration immédiat pour valider.
4. La sonde vérifie le bucket toutes les ~20 minutes ; un backup non testé n'existe pas (test automatique le 5 du mois).

5. Migration de domaine — assistance.lauris.fr (jour J)

Outil : le script migrate-domain.sh, livré avec le dossier — testé à blanc en réel : l'instance a réellement basculé sur un second nom de domaine puis est revenue, avec vérifications automatiques de bout en bout (HTTPS/certificat, connexion 2FA, email→ticket, accusé de réception, sonde de supervision).

Prérequis côté mairie (ses seules actions) :

• l'enregistrement DNS A assistance.lauris.fr → <IP du VPS> dans la zone lauris.fr (le script affiche la ligne exacte s'il ne le trouve pas, et ne modifie rien tant que le DNS n'est pas prêt) ;
• la boîte assistance@lauris.fr dans son Google Workspace, avec mot de passe d'application (IMAP activé) — ou OAuth2 via le plugin oauthimap si votre politique l'exige (non couvert par le script).

# 1. Éditer le .env : boîte email cible + hôtes IMAP/SMTP Gmail
#    (le préflight du script vérifie ces accès AVANT de toucher à la prod)
./migrate-domain.sh to assistance.lauris.fr
# → DNS vérifié, bascule, vérifications de bout en bout ; l'ancien nom reste
#   servi en redirection et le retour arrière est trivial :
./migrate-domain.sh rollback              # retour exact à l'état d'avant
./migrate-domain.sh finalize              # quand tout est validé côté utilisateurs

Le domaine gestion-de-lauris.fr reste la propriété de Nicolas Ziegle : après finalize, plus rien n'en dépend.

6. Rotation des secrets à la reprise (obligatoire)

Objectif : vous repartez avec des secrets que l'ancien exploitant ne connaît plus. Le mécanisme est toujours le même : générer la nouvelle valeur, la mettre dans le .env (+ votre coffre), rejouer le script concerné.

Après rotation : nouvelle copie du .env au coffre-fort, puis validation d'un coup — sonde toute verte + un email de test qui devient un ticket.

7. Transfert du monitoring (< 30 min)

C'est le cas nominal prévu par conception : la sonde vit dans le dossier projet et tourne de n'importe où ; l'hôte d'ordonnancement n'a que le déclencheur périodique.

1. Chez vous : copier le dossier + .env, lancer la sonde en mode distant → tout doit être ok.
2. Activer l'ordonnanceur fourni (alerte email uniquement sur fait nouveau) ; valider avec une panne factice (arrêt du conteneur GLPI → alerte → redémarrage → rétablissement).
3. Sur l'ancien hôte d'exploitation : désinstallation en une commande.

Ou remplacez-le par votre propre supervision (Zabbix, Centreon, Elastic…) : seule compte l'interface de la sonde — une ligne JSON par vérification ({"check": …, "status": "ok|warn|crit", "detail": …}) + un code retour 0/1/2, directement exploitable comme check Nagios/Centreon, item Zabbix ou document à indexer.

8. Export en dépôt autonome

Le dossier projet est conçu pour être extrait de son dépôt d'origine et vivre dans votre propre dépôt git : tous les scripts d'exploitation (déploiement, sauvegarde, restauration, supervision, migration de domaine) sont autosuffisants (bash + curl + ssh + python3 standard, aucun outil propriétaire). Le .env reste à part, au coffre-fort — il est déjà exclu de git.

9. Checklist de reprise — pas à pas

Quatre phases. Chaque étape se termine par une vérification observable ; tant qu'elle n'est pas verte, on ne passe pas à la suivante. Les § renvoient au détail plus haut. Aucune étape n'est irréversible avant la phase D.

Avant la séance de remise : lire la présentation de l'architecture (15 min) et survoler le guide d'exploitation ; côté mairie/prestataire, identifier le compte OVH qui recevra le VPS (§ 3) — c'est le seul prérequis administratif.

Phase A — Séance de remise (~1 h, ensemble — rien ne change pour les utilisateurs)

1. Recevoir le dossier (§ 8) sur votre hôte d'exploitation — un Linux avec bash, ssh, curl et python3, rien d'autre.
2. Recevoir le .env par canal sûr (jamais par email) → racine du dossier + copie dans votre coffre-fort. La phrase de chiffrement des sauvegardes qu'il contient est irremplaçable.
3. Vérifier que vous savez déjà exploiter : ./monitoring/probe.sh --remote → toutes les lignes ok. Ce seul test prouve : accès SSH au serveur, HTTPS, conteneurs, sauvegardes, DNS.
4. Test fonctionnel : un email à la boîte du guichet → ticket créé en moins de 2 minutes + accusé de réception reçu.
5. Changement de contact OVH du VPS (§ 3) — lancé en séance, effectif après validation email des deux parties. Zéro coupure, l'IP ne change pas.

Fin de phase A : vous avez tout ; techniquement rien n'a changé.

Phase B — Première semaine (vous seul, à votre rythme)

1. Vos sauvegardes (§ 4) : votre bucket S3 + clés dans le .env → redéploiement, puis première sauvegarde et test de restauration immédiats. Vérification : les deux se terminent OK, la sonde reste verte.
2. Votre monitoring (§ 7) : ordonnanceur activé chez vous, validé par une panne factice (arrêt du conteneur GLPI → alerte → redémarrage → rétablissement) ; l'ancien exploitant désinstalle le sien. Ou branchez votre propre supervision sur le contrat JSON de la sonde.
3. Rotation complète des secrets (§ 6, tableau ligne à ligne) : clé SSH (la vôtre ajoutée, celles de l'ancien exploitant retirées), boîte email, comptes GLPI, base de données, S3 + phrase de chiffrement. Vérification finale : sonde toute verte + un email → ticket. Nouvelle copie du .env au coffre.

Fin de phase B : l'ancien exploitant n'a plus aucun accès technique. Le service tourne toujours à l'identique sur l'ancien domaine.

Phase C — Jour J du domaine (avec la mairie, quand elle est prête)

1. Prérequis mairie (§ 5) : enregistrement DNS A assistance.lauris.fr → <IP du VPS> dans la zone lauris.fr, et boîte assistance@lauris.fr (Workspace) avec mot de passe d'application IMAP.
2. .env : boîte cible + hôtes IMAP/SMTP Gmail. Le préflight du script les vérifie avant de toucher à la production.
3. Bascule : ./migrate-domain.sh to assistance.lauris.fr. Vérifications automatiques de bout en bout (HTTPS, connexion 2FA, email→ticket, accusé de réception, sonde) ; l'ancien nom reste servi en redirection ; en cas de doute : ./migrate-domain.sh rollback — retour exact à l'état d'avant.
4. Informer les agents : nouvelle URL, comptes et 2FA inchangés.
5. Après quelques jours de recul : ./migrate-domain.sh finalize.

Phase D — Clôture

1. Révoquer le jeton API DNS de l'ancien domaine (espace OVH du titulaire) — il ne sert plus à rien.
2. Dernière copie du .env dans votre coffre ; détruire les copies intermédiaires.
3. Nicolas décommissionne librement ce qui reste sur gestion-de-lauris.fr (boîte, sous-domaine) — plus rien n'en dépend.

À l'issue : l'ancien exploitant n'a plus aucun accès (SSH retiré, secrets renouvelés, monitoring désinstallé de son côté) et n'est plus un point de passage.