Compétences du Bloc B1 : B1.3 — Développer la présence en ligne de l’organisation · B1.1 — Gérer le patrimoine informatique
Le contexte et l’objectif
Le site que vous êtes en train de lire est lui-même un projet du portfolio. Pour l’épreuve E5, j’avais besoin d’un espace de publication régulière : des articles présentant mes réalisations, classés par compétences du Bloc B1, enrichis au fil de la formation, avec des documents téléchargeables (les procédures techniques en PDF). Ce besoin éditorial — publication fréquente, taxonomie, gestion de médias, back-office — justifie cette fois pleinement un CMS, là où mon projet de site vitrine avait, pour un besoin inverse, justifié un site statique. J’ai choisi WordPress, le CMS le plus répandu, et je l’ai déployé sous forme conteneurisée avec Docker sur mon VPS personnel (Debian 12), qui héberge déjà d’autres services derrière Apache.
Le besoin technique
Le cahier des charges que je me suis fixé : une pile LAMP complète (Apache, MySQL, PHP) portant WordPress ; une cohabitation propre avec les services déjà en production sur le VPS, sans conflit de ports ni dépendances entremêlées ; des données strictement séparées du moteur applicatif, pour pouvoir mettre à jour ou reconstruire les conteneurs sans jamais toucher au contenu ; une exposition publique uniquement en HTTPS ; et une stratégie de sauvegarde complète et testée — un blog de portfolio qui perdrait ses articles la veille de l’épreuve serait un comble.
La solution retenue : la conteneurisation
Docker répond exactement à la problématique de cohabitation. Plutôt que d’installer PHP et MySQL directement sur le système — au risque d’entrer en conflit avec l’existant et de compliquer chaque mise à jour — la pile WordPress vit dans deux conteneurs isolés, décrits dans un unique fichier de composition : un conteneur applicatif (Apache + PHP + WordPress, l’image officielle) et un conteneur de base de données MySQL. Les données persistantes (base de données d’un côté, fichiers du site de l’autre) résident dans des volumes Docker dédiés, indépendants du cycle de vie des conteneurs : détruire et recréer la pile ne touche pas au contenu.
L’intégration au VPS suit une architecture de production classique : le conteneur WordPress n’écoute que sur l’interface locale de la machine, jamais directement sur Internet ; c’est l’Apache déjà en place sur le VPS qui joue le rôle de mandataire inverse (reverse proxy) et publie le blog sur son sous-domaine, avec un certificat TLS Let’s Encrypt renouvelé automatiquement. La base de données, elle, n’est joignable que depuis le réseau interne des conteneurs — elle n’expose aucun port, ni sur Internet, ni même sur le VPS.
Enfin, conformément à l’exigence de sauvegarde, un script automatisé exporte chaque nuit les trois composants vitaux — la base de données (export logique cohérent), les fichiers du site (thèmes, extensions, médias) et la configuration de la pile — avec une rotation des archives, et la procédure de restauration associée a été rédigée et testée : une sauvegarde dont on n’a jamais vérifié la restauration n’offre aucune garantie.
La dimension sécurité
La sécurité du déploiement repose sur la réduction de la surface exposée : un seul point d’entrée public (le reverse proxy en HTTPS), un conteneur applicatif confiné à l’interface locale, une base de données invisible de l’extérieur, et des secrets (mots de passe de la base) stockés dans un fichier d’environnement exclu de toute publication — jamais en dur dans la configuration. La conteneurisation apporte aussi une hygiène de maintenance : les mises à jour de WordPress, de PHP ou de MySQL se font en remplaçant les images, de façon réversible, les données étant hors des conteneurs. Les sauvegardes chiffrables et externalisables complètent le dispositif en couvrant le dernier risque : la perte du serveur lui-même.
Ma plus-value personnelle
Ce projet boucle la boucle du portfolio : l’outil qui présente mes compétences est lui-même une démonstration de ces compétences. J’y ai fait des choix d’architecture argumentés (conteneurisation pour la cohabitation, reverse proxy pour l’exposition, volumes pour la persistance) plutôt qu’une installation par défaut, et j’ai traité la sauvegarde comme une exigence de premier rang, avec script, planification, rotation et test de restauration. C’est aussi une réponse assumée à mon propre article sur le site vitrine : le bon choix technique dépend du besoin — statique quand le contenu est figé, CMS conteneurisé quand la publication est vivante. Savoir défendre les deux, c’est précisément ce que j’attends de moi en tant que futur administrateur.
La procédure technique détaillée pas à pas (déploiement Docker, reverse proxy, HTTPS) ainsi que la procédure complète de sauvegarde et de restauration sont disponibles en téléchargement au format PDF ci-dessous.