Observabilité et alerting
Des métriques et des logs centralisés, requêtables (Prometheus, Grafana, Loki), des dashboards qui répondent à la question « est-ce que tout va bien ? », et des alertes actionnables, peu nombreuses. C’est le premier chantier.
Pourquoi. L’incident du 1er juin : deux jours de services privés en panne, découverts par un hasard d’usage. Être prévenu, sans avoir à aller vérifier.
CI/CD systématique pour l’infra
J’utilise GitLab CI en contexte professionnel. Le chantier est de l’appliquer systématiquement à ma propre plateforme : déploiements reproductibles déclenchés par Git, plus aucune étape manuelle.
Pourquoi. Chaque étape manuelle est une occasion d’oubli, et la plateforme sert des clients réels.
Infrastructure as Code
La configuration des services est déjà déclarative (Compose, fichiers versionnés). L’étape suivante décrit aussi le provisionnement (Terraform, Ansible) : un serveur doit pouvoir se reconstruire de zéro sans mémoire humaine.
Pourquoi. Le jour où le serveur disparaît, la reconstruction ne doit dépendre que de Git. C’est le complément direct du chantier sauvegardes.
Sauvegardes éprouvées
Généraliser la stratégie 3-2-1 à l’ensemble du serveur (dumps par service, rotation, copie hors-site), puis tester les restaurations régulièrement et mesurer un temps de reprise réel.
Pourquoi. Le tradeoff est assumé sur la page sauvegardes : tant que la restauration n’est pas exercée, le temps de reprise reste une estimation. Ce chantier en fait une mesure.
Outillage des secrets
Scan automatique des dépôts et de leur historique (gitleaks ou équivalent) et hooks de pre-commit. L’audit est aujourd’hui une pratique manuelle.
Pourquoi. Un audit manuel a trouvé une clé committée : la pratique fonctionne, l’outillage la rendra systématique.
Au-delà du mono-serveur
Un second nœud, puis une topologie multi-serveurs : d’abord pour la résolution DNS et les services critiques, ensuite comme terrain d’apprentissage d’une infrastructure plus large.
Pourquoi. La panne hébergeur du 19 juin : le risque mono-serveur est compris et accepté à cette échelle, ce chantier prépare la suite.
Kubernetes et cloud managé
L’orchestration (k3s d’abord) et les primitives d’un cloud public (AWS) : en environnement d’expérimentation, puis en migrant des services réels de la plateforme.
Pourquoi. Parler le langage des équipes qui opèrent à plus grande échelle, et donner une cible commune aux chantiers précédents : IaC, observabilité et multi-nœuds en sont les prérequis.
La méthode
Chaque brique passe en production sur ma propre infrastructure, avec les mêmes exigences que le reste : configuration déclarative, versionnée, documentée. Une fois en place, le chantier rejoint les pages de détail du site, avec son record de décision.