Un site vitrine pour une brasserie artisanale : choix d’architecture et mise 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.