Catégorie : B1.3 Présence en ligne

Compétences du Bloc B1 : B1.3 — Développer la présence en ligne de l’organisation · B1.4 — Travailler en mode projet · B1.5 — Mettre à disposition des utilisateurs un service informatique

L’organisation et le contexte

Dans le cadre d’un projet proposé en BTS SIO, j’ai réalisé le site vitrine de la Brasserie Terroir & Saveurs, une brasserie artisanale des Hauts-de-France souhaitant moderniser sa présence en ligne. L’objectif : un site présentant son identité, ses produits (bières et spiritueux) et ses informations de contact, mis en ligne et accessible publiquement.

Le cahier des charges fixait des contraintes précises : affichage du logo et de photos de la production, respect d’un code couleur cuivré (beige, ocre, marron, orange), barre de navigation structurant les rubriques, et fiches produits consultables pour l’ensemble des références.

Le besoin et l’analyse du cahier des charges

Derrière la demande « faire un site », le vrai besoin de l’organisation était une vitrine : un contenu stable, présenté avec soin, qui ne nécessite ni espace de publication régulière, ni comptes utilisateurs, ni fonctionnalités dynamiques. Cette analyse a directement orienté mes choix d’architecture — c’est elle qui distingue un projet réussi d’un projet techniquement surdimensionné.

Les choix techniques et leur justification

Le sujet préconisait WordPress. J’ai fait — et assumé — un choix différent : un site statique (HTML/CSS/JS) servi par Apache, hébergé sur mon VPS Debian 12 déjà en production pour d’autres services. La justification est concrète : un CMS complet implique une pile PHP, une base de données, et surtout une maintenance continue (mises à jour du cœur, des extensions, de la base), pour un site dont le contenu n’a pas vocation à changer chaque semaine. Sur un VPS aux ressources partagées entre plusieurs projets, un site statique est plus léger, plus rapide, et surtout n’ajoute aucune surface d’attaque à maintenir. À l’inverse, un besoin de publication éditoriale régulière justifierait pleinement un CMS — c’est d’ailleurs le choix que j’ai fait pour ce blog, dans un autre contexte et pour un autre besoin.

Pour la production du code, j’ai utilisé Lovable, un outil de génération de sites assisté par IA, en lui fournissant le cahier des charges complet et les ressources visuelles (logo, photos, fiches produits). Le rôle du technicien ne s’arrête pas à la génération, au contraire : la relecture systématique du code produit m’a permis d’identifier et de corriger une erreur réelle — deux bières inversées sur les fiches produits, les descriptions ne correspondant pas aux visuels — directement dans les fichiers avant toute mise en ligne.

Le déploiement a ensuite suivi un processus maîtrisé : transfert sécurisé des fichiers sur le VPS, configuration d’un hôte virtuel Apache dédié, et mise en production sur un sous-domaine propre au projet. Le résultat final respecte l’intégralité du cahier des charges : identité visuelle cuivrée sur toutes les pages, navigation vers les cinq rubriques, fiches consultables pour les cinq références, affichage adapté aux mobiles, et site publiquement accessible.

La dimension sécurité

Le choix du statique est en lui-même une décision de sécurité : pas de code exécuté côté serveur, pas de base de données exposée, pas de back-office à protéger ni de CMS à patcher en urgence à chaque vulnérabilité publiée. La surface d’attaque se réduit au serveur web lui-même, déjà administré et maintenu à jour sur le VPS. Le transfert des fichiers vers le serveur s’effectue exclusivement par canal chiffré, et le site est servi en HTTPS.

Ma plus-value personnelle

Ce projet démontre une compétence que je considère centrale : savoir justifier un choix technique face à une préconisation, en argumentant sur le besoin réel plutôt qu’en suivant l’outil à la mode. Il illustre aussi ma capacité à utiliser les outils de génération assistée par IA de manière professionnelle — comme des accélérateurs dont la production doit être relue, validée et corrigée, jamais comme des boîtes noires : l’erreur d’inversion des fiches produits, invisible sans relecture attentive, serait partie en production. Enfin, héberger le résultat sur ma propre infrastructure, plutôt que sur une plateforme clé en main, m’a fait pratiquer la chaîne complète de mise en ligne : du fichier local au site public, en passant par la configuration du serveur web.

La procédure de déploiement détaillée est disponible en téléchargement au format PDF ci-dessous, et le site est consultable en ligne.

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.