Création et maintenance de site web
Projet d'équipe : développement, intégration et mise en production.
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 pour comprendre leurs attentes fonctionnelles et esthétiques. À 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 panel d'administration. Ces maquettes ont été soumises au client pour validation du parcours utilisateur (UX) et du design (UI), nous permettant de verrouiller le cahier des charges avant la phase technique.
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. J'ai structuré les tables nécessaires, notamment pour le contenu des articles et la gestion des comptes administrateurs, en intégrant un algorithme de hachage pour sécuriser les mots de passe. Pour gérer le développement à quatre, nous avons initialisé un dépôt sur l'instance GitLab de l'école. Cela nous a permis de versionner notre code et de séparer les branches front-end et back-end.
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. J'ai développé les formulaires et mis en place les requêtes SQL (dans un premier temps des requêtes simples, puis avec l'aide de notre enseignant, nous avons mis en place des requêtes préparées pour éviter toute faille SQL). J'ai assuré la liaison avec le back-end développé par mes collègues.


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). J'ai 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, n'autorisant l'accès SSH sur le port 22 qu'au travers d'échanges de clés cryptographiques.
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 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 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.
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.
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. J'ai compris l'importance vitale de faire le pont entre le monde du développement et celui de l'administration système.
5.2. Pour le client
Le club dispose d'un site sur mesure et d'un panel d'administration fonctionnel. Bien qu'aucune maintenance technique continue ne nous ait été demandée à l'issue du projet, l'infrastructure livrée est stable et permet au club de gérer son contenu de manière autonome. La rédaction des documentations permettra, si nécessaire dans le futur, une mise à jour simple et rapide du site web.
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.