Création et maintenance de site web

1. Introduction

Cette réalisation a été effectuée dans le cadre d'un travail d'équipe visant à concevoir, développer et héberger le site web du Club de billard de Segré. Il s'agissait de créer un site vitrine dynamique incluant un espace d'administration permettant aux gérants du club de modifier leurs pages, créer des articles et envoyer des newsletters en toute autonomie. Nous étions une équipe de quatre personnes. Je me suis principalement concentré sur le développement du front-end et sur la modélisation de la base de données (réalisée en équipe), avant de prendre en charge la configuration du serveur VPS chez OVH pour la mise en production.

2. Les objectifs

2.1. Objectifs techniques

• Modéliser et déployer une base de données
• Développer le front-end du site vitrine en PHP/HTML/CSS
• Configurer un serveur VPS OVH (stack LAMP) pour l'hébergement

2.2. Objectifs non techniques

• Se coordonner à quatre sur le même code (front-end public, back-end, front-end d'administration)
• Livrer un outil clé en main permettant au client de gérer son contenu sans intervention technique ultérieure
• Améliorer la visibilité du club de billard de Segré

3. Le contexte et les enjeux

Le Club de billard de Segré avait besoin d'une présence en ligne pour se promouvoir. Plutôt que d'utiliser un site vitrine classique, nous avons développé une solution sur mesure, leur permettant de mettre à jour, communiquer et administrer en toute autonomie. Une fois le code fonctionnel en local, le club nous a fourni une instance vierge chez OVH qu'il a fallu transformer en serveur web de production.

Enjeux principaux : Le premier était la synchronisation du travail d'équipe : faire correspondre le front-end que je développais avec le back-end de mon collègue et la base de données commune. Le second était le déploiement technique de notre code local vers un environnement de production en ligne de manière fonctionnelle. Nous n'avions jamais touché à une instance cloud à ce stade de notre formation, mais nous avons été accompagnés par notre encadrant pour réaliser cette partie au mieux.

Risque majeur : Un environnement de développement local diffère souvent d'un serveur distant, ce qui peut générer des erreurs bloquantes lors de la mise en ligne, notamment des connexions à la base de données non fonctionnelles ou des images non importées.

4. Les différentes étapes du projet

4.1. Recueil des besoins et maquettage

Le projet a débuté par une phase d'échange direct avec les gérants du club afin de comprendre leurs attentes fonctionnelles et esthétiques. Nous avons parlé du type de contenus qu'ils voulaient publier, de la manière dont ils souhaitaient présenter les événements du club et du niveau d'autonomie attendu pour les futurs administrateurs du site. À l'issue de ces réunions de cadrage, j'ai conçu avec mon équipe des maquettes graphiques pour l'interface publique et pour le panneau d'administration.

Ces maquettes ont été soumises au client pour validation du parcours utilisateur (UX) et du design (UI), ce qui nous a permis de verrouiller le cahier des charges avant la phase technique. Cette étape était importante, car elle nous a évité de développer trop tôt des fonctionnalités qui n'auraient pas correspondu aux usages réels du club. Elle a aussi permis de poser une base commune entre l'équipe et le client, afin d'avancer ensuite sans ambiguïté sur le rendu attendu.

4.2. Architecture de la base de données et environnement collaboratif

J'ai pris en charge la modélisation de la base de données sous MariaDB, en structurant les tables nécessaires pour le contenu des articles, les comptes administrateurs et les éléments de communication du club. J'ai réfléchi à la manière d'organiser les données pour éviter les redondances inutiles et pour faciliter la maintenance future. J'ai également intégré un algorithme de hachage pour sécuriser les mots de passe, car le projet devait rester exploitable dans la durée et pas seulement fonctionner en démonstration.

Pour gérer le développement à quatre, nous avons initialisé un dépôt sur l'instance GitLab de l'école et défini quelques règles de travail pour ne pas nous marcher dessus. Cela nous a permis de versionner notre code, de séparer les branches front-end et back-end et de suivre plus facilement les modifications de chacun. Le dépôt a aussi joué le rôle de point de synchronisation quand il fallait intégrer les nouvelles fonctionnalités ou corriger un bug sans casser le reste de l'application.

4.3. Phase de développement et codage

Sur la base des maquettes validées, nous sommes passés à l'écriture du code. J'ai pris en charge le développement de l'interface front-end en HTML/CSS et l'intégration de la logique dynamique en PHP, en veillant à ce que la présentation reste lisible et cohérente avec l'identité du club. J'ai développé les formulaires et mis en place les requêtes SQL ; dans un premier temps, nous avons utilisé des requêtes simples pour valider le fonctionnement général, puis, avec l'aide de notre enseignant, nous avons adopté des requêtes préparées pour éviter toute faille SQL.

J'ai également assuré la liaison avec le back-end développé par mes collègues, ce qui impliquait de vérifier que les noms de variables, les champs de formulaires et les réponses attendues correspondaient bien d'une partie à l'autre. Cette phase a demandé beaucoup d'aller-retour entre le code et le navigateur, car chaque détail pouvait créer un dysfonctionnement dans la chaîne complète. C'est à ce moment-là que le travail en équipe a vraiment pris son sens, puisque chaque bloc de code devait s'imbriquer proprement dans l'ensemble.

4.4. Déploiement et durcissement du VPS Linux

Le client nous avait fourni un accès à une instance VPS OVH vierge sous Debian 8. Je l'ai transformée en serveur de production en y installant manuellement la stack LAMP (Apache2, PHP 8, MariaDB). Avant même de mettre le site en ligne, j'ai vérifié que les paquets nécessaires étaient présents, que les services démarraient correctement et que les permissions du répertoire web restaient compatibles avec le fonctionnement attendu. J'ai ensuite activé le pare-feu UFW en autorisant uniquement le port 443 pour le trafic HTTPS, le port 80 redirigeant nativement vers le SSL via les VirtualHosts d'Apache.

Pour l'administration, j'ai modifié le fichier sshd_config pour interdire l'authentification par mot de passe et n'autoriser l'accès SSH sur le port 22 qu'au travers d'échanges de clés cryptographiques. Ce durcissement m'a permis d'aborder le serveur non seulement comme un espace d'hébergement, mais comme une vraie plateforme de production qu'il fallait sécuriser dès le départ. J'ai aussi vérifié que l'environnement reste administrable à distance, car le client devait pouvoir compter sur un serveur stable et fiable sans intervention permanente de notre part.

4.5. Débogage critique lors de la mise en production

Le déploiement du code depuis le dépôt GitLab vers le répertoire /var/www/html du VPS Linux a provoqué un dysfonctionnement majeur : fichiers CSS et images devenaient inaccessibles. Le développement ayant été réalisé en local sous Windows via XAMPP, nous avions commis l'erreur de coder les appels de fichiers en dur en utilisant l'arborescence absolue locale (du type C:/xampp/htdocs/...). Sur le système de fichiers Linux du serveur de production, ces chemins ne pointaient vers rien. J'ai ouvert une session SSH, puis j'ai analysé les liens un par un pour comprendre lesquels devaient être remplacés et lesquels pouvaient rester intacts.

Une fois le problème identifié, j'ai modifié l'intégralité de ces liens absolus par des chemins relatifs, rétablissant ainsi le chargement des dépendances et l'affichage du site. Cette étape m'a appris qu'un simple détail de chemin peut bloquer toute une mise en ligne, même si le code métier fonctionne correctement. Le débogage a donc été autant un travail technique qu'un travail de méthode, car il fallait isoler précisément la cause avant de corriger l'ensemble sans casser le reste du site.

4.6. Rédaction des documentations techniques et utilisateur

J'ai finalisé le projet en livrant deux documentations distinctes. La première, à destination du club, était un manuel utilisateur vulgarisé et illustré expliquant pas à pas comment rédiger des articles et gérer les accès via leur interface d'administration. La seconde était une documentation technique destinée à de futurs développeurs, répertoriant le schéma relationnel de la base MariaDB, la configuration des VirtualHosts Apache et une explication détaillée du code pour permettre l'évolution du site.

J'ai pris soin de distinguer les deux publics afin que chacun dispose d'un document vraiment utile : un support simple pour les utilisateurs du club, et une ressource plus technique pour la maintenance future. Cette dernière étape a aussi servi à formaliser le travail accompli, ce qui est essentiel quand on livre une solution de production. Le projet ne se résume pas au code livré, mais aussi à la capacité à transmettre ce que l'on a construit.

5. Les résultats

5.1. Pour moi

Techniquement, j'ai maîtrisé le cycle complet d'un projet web, de la gestion des versions sous GitLab à l'administration d'une base de données MariaDB et au durcissement d'un serveur Linux via UFW et SSH. Sur le plan personnel, la gestion de l'incident lors de la mise en ligne m'a appris à garder mon sang-froid sous pression et à diagnostiquer les erreurs système en direct. J'ai compris l'importance vitale de faire le pont entre le monde du développement (local sur Windows) et celui de l'administration système (production sur Linux).

Cette expérience a aussi affiné mes compétences en modélisation de bases de données : je comprends maintenant comment structurer les tables pour minimiser les requêtes SQL et assurer une meilleure évolutivité. La gestion des branches GitLab en équipe m'a montré les enjeux du versionnage collaboratif et la nécessité de conventions strictes de codage.

5.2. Pour le client

Le Club de billard de Segré a reçu un site vitrine professionnel, entièrement personnalisé selon son identité visuelle. Ils disposent d'un panneau d'administration fonctionnel et simple d'usage, leur permettant de publier des articles, de gérer les événements et d'envoyer des newsletters sans aucune compétence technique. Cet outil leur a donné une présence web moderne et crédible, essentielle pour attirer de nouveaux adhérents dans un contexte où la plupart des clubs proposent des solutions obsolètes.

Au niveau commercial, la mise en ligne du site a amélioré leur visibilité sur les moteurs de recherche locaux et leur a permis de communiquer directement avec leurs adhérents par e-mail. L'infrastructure livrée est stable et robuste : en trois ans d'exploitation, le site n'a connu aucune coupure, validant la qualité de l'architecture mise en place. La rédaction des documentations techniques permet aussi au club de faire évoluer le site ultérieurement avec un développeur externe, si besoin.

6. Ce que je retiens

Ce projet m'a démontré que le code et l'infrastructure d'hébergement sont indissociables. Notre plus grosse erreur a été de développer le site en local sous Windows sans anticiper les contraintes du serveur Linux de production, notamment la casse des chemins d'accès absolus et relatifs. Ma valeur ajoutée a été de prendre le lead sur le débogage système directement en ligne de commande sur le VPS OVH. Si je devais recommencer, j'imposerais dès le premier jour l'utilisation d'un environnement de développement conteneurisé, comme Docker, reproduisant exactement la stack Debian de production pour éviter tout conflit lors du déploiement.

7. Les lendemains du projet

La fin du projet a été marquée par la livraison en main propre des documentations techniques et du manuel utilisateur. À distance, nous n'avons plus été sollicités pour de la maintenance corrective, ce qui prouve la robustesse du code livré. Aujourd'hui, le site web est toujours en ligne et fonctionnel. L'interface publique n'a pas été altérée, confirmant la pérennité de l'infrastructure LAMP que j'ai configurée.