Site communautaire de partage de figures de snowboard, développé de A à Z avec Symfony
Scores de cette page :
EcoIndex A
SEO 100%
Accessibilité 100%
Performance 100%
Bonnes Pratiques 100%
Projet de formation (OpenClassrooms) : développement complet d'un site communautaire pour apprendre les figures de snowboard, avec Symfony et Doctrine. Authentification par JWT fait maison, gestion de figures en CRUD avec upload de médias mixtes (images et vidéos), espace de discussion par figure.
Contexte : un vrai besoin métier derrière un exercice de formation
Projet réalisé en formation (parcours Développeur PHP/Symfony, OpenClassrooms), mais avec un vrai commanditaire fictif interprété par mon mentor : « Jimmy Sweat », qui voulait un site collaboratif de partage de figures de snowboard — un annuaire que les internautes peuvent enrichir eux-mêmes, avec un espace de discussion, pour faire connaître le sport et, à terme, attirer des marques partenaires. Contrainte du cahier des charges : aucune bibliothèque externe autorisée, à l'exception d'une seule pour générer les données de démonstration.
Avant de coder : comprendre et structurer le besoin
Avant d'écrire la moindre ligne de code, le besoin a été traduit en schémas visuels (diagrammes UML) : un premier schéma qui récapitule tout ce qu'un visiteur peut faire sur le site (consulter, s'inscrire, se connecter, publier, modifier, commenter, réinitialiser son mot de passe), puis des schémas plus détaillés pour chaque action précise — par exemple, la succession exacte d'étapes qui se déroule quand quelqu'un ajoute une nouvelle figure : connexion, remplissage du formulaire, vérification par le site, enregistrement, confirmation. Cette étape de mise à plat, invisible pour l'utilisateur final, sert de plan de construction pour organiser ensuite la base de données et le code.
Une organisation du travail traçable et réversible
Le développement a été suivi avec Git et GitHub, un outil qui garde une trace de chaque évolution du code et permet de revenir en arrière en cas d'erreur. Le travail a été découpé en 10 grandes étapes (analyse et diagrammes, configuration du projet, structure de la base de données, habillage visuel, inscription et authentification, ajout de figures, commentaires, modification et suppression, réinitialisation de mot de passe, puis relecture générale et amélioration de la qualité), chacune développée dans sa propre branche de code isolée, avec une relecture avant intégration à la version principale — une discipline qui limite le risque de casser une fonctionnalité existante en en développant une nouvelle.
Visite guidée du site, côté visiteur
Sans être connecté, n'importe qui peut consulter l'intégralité des figures publiées, triées par grandes familles (old school, grabs, flips...), et lire le détail de chacune : nom, description, catégorie, auteur, date de création et de dernière modification, ainsi que les commentaires déjà publiés — sans pouvoir en ajouter tant qu'on n'est pas inscrit.
Inscription et vérification par email
L'inscription demande un email, un nom d'utilisateur, un mot de passe et, en option, un avatar. Une fois le formulaire validé, le compte est créé mais reste inactif : un email de vérification est envoyé, avec un lien à durée de vie limitée (3 heures) à cliquer pour activer réellement le compte — une étape de sécurité qui confirme que l'email fourni existe bien et appartient à la personne qui s'inscrit.
Publier, modifier et supprimer ses propres figures
Une fois connecté, chaque utilisateur peut ajouter une nouvelle figure : catégorie, nom, description, une image principale, des images secondaires, et des vidéos via un code d'intégration. Seul l'auteur d'une figure peut ensuite la modifier ou la supprimer — les boutons correspondants n'apparaissent que sur ses propres publications, jamais sur celles des autres. Une vérification empêche également de créer deux figures portant exactement le même nom, pour éviter les doublons accidentels dans l'annuaire. La suppression demande une confirmation explicite avant d'être exécutée, pour éviter un clic accidentel.
Ce qui se passe concrètement à l'enregistrement d'une figure
Ajouter et modifier une figure partagent en réalité le même bloc de code sous-jacent (une seule fonction, appelée dans les deux cas), pour éviter d'écrire deux fois une logique identique. Cette fonction vérifie d'abord que le formulaire est valide et que le nom choisi n'existe pas déjà, puis génère un identifiant technique lisible par le site à partir du nom (le « slug »), enregistre l'image principale si elle a été fournie, puis les images secondaires et les vidéos. Les images uploadées par les utilisateurs sont stockées dans un dossier dédié sur le serveur ; à la suppression d'une figure, ses images sont supprimées avec elle plutôt que laissées à s'accumuler indéfiniment — un choix de gestion du stockage. Pour les vidéos intégrées, un paramètre de lecture automatique est systématiquement désactivé s'il est présent dans le code fourni, pour ne pas imposer un démarrage sonore ou visuel non désiré à la personne qui consulte la page.
Espace de discussion par figure
Chaque figure dispose de son propre fil de commentaires, paginé au-delà de dix messages, avec l'auteur, la date et l'avatar affichés à côté de chaque commentaire, et un formulaire de publication directement accessible aux utilisateurs connectés.
Réinitialisation de mot de passe
En cas d'oubli, un formulaire dédié permet de demander la réinitialisation à partir du nom d'utilisateur (une vérification s'assure que ce nom existe bien avant d'agir). Un email est alors envoyé avec un lien à usage unique menant vers un formulaire de saisie d'un nouveau mot de passe ; une fois validé, la connexion redevient possible avec ce nouveau mot de passe.
Sécurité : accès protégé même par l'URL
Les pages réservées aux utilisateurs connectés (ajouter une figure, notamment) ne sont pas seulement masquées dans le menu pour les visiteurs non connectés : la page elle-même refuse d'afficher son contenu et invite à se connecter ou s'inscrire, y compris si quelqu'un tente d'y accéder directement en tapant l'adresse dans son navigateur. Une protection complémentaire contre les soumissions de formulaire falsifiées (jeton CSRF) est également en place sur l'ensemble des formulaires du site.
Adapté au mobile, terrain de jeu naturel du sport concerné
Le site s'adapte au mobile, à la tablette et au desktop. Sur mobile, un menu classique en icône « burger » remplace le menu horizontal, et — détail pensé pour la rapidité de chargement — les médias (images et vidéos) d'une fiche figure sont masqués par défaut et ne s'affichent qu'au clic, pour ne pas alourdir inutilement le chargement d'une page sur une connexion mobile, potentiellement utilisée en station de ski plutôt que chez soi avec une bonne connexion.
Un habillage visuel adapté à partir d'un template existant
Pour limiter le budget et le temps de développement, l'habillage visuel de départ s'appuie sur un template existant (« Lonely »), largement retravaillé plutôt que repris tel quel — la structure générale de certains éléments d'interface (icônes, listes) provient du template d'origine, mais l'essentiel du détail visuel et fonctionnel du site a été modifié.
Environnement technique
PHP 8, Symfony (architecture MVC générée automatiquement à la création du projet, avec ses dossiers standards : configuration, migrations de base de données, ressources publiques, code source, templates), Composer comme gestionnaire de dépendances, MySQL comme base de données administrée via phpMyAdmin. Doctrine (génération de la structure de base de données et des fichiers associés) et les Fixtures (génération de données de démonstration réalistes : utilisateurs, figures et commentaires fictifs) sont les deux seules bibliothèques externes utilisées, conformément à la contrainte du cahier des charges. Les templates des pages sont écrits avec Twig, le moteur d'affichage fourni nativement par Symfony.
Qualité du code
Suivi avec Codacy, un outil connecté au dépôt GitHub qui analyse automatiquement le code et identifie les points d'amélioration : note A obtenue, avec 558 points mineurs identifiés comme marge de progression possible plutôt que comme défauts bloquants. Bonnes pratiques appliquées : noms de variables et de fonctions explicites, conventions de nommage cohérentes selon le langage (camelCase en PHP/JavaScript, snake_case en CSS), indentation soignée, commentaire systématique des fonctions (paramètres, valeur de retour), un fichier et une fonction dédiés à une seule responsabilité plutôt que des fichiers fourre-tout, et absence de code dupliqué (la fonction commune à l'ajout et à la modification d'une figure, par exemple). Gestion des erreurs prévue avec une page 404 dédiée et une page d'erreur générique qui redirige vers l'accueil.
Performance et accessibilité
Audit réalisé avec Google Lighthouse (performance, accessibilité, bonnes pratiques). Points d'amélioration identifiés : le contraste de certaines couleurs et l'ajout de descriptions alternatives sur davantage d'images, ainsi qu'un travail plus poussé sur le poids des images pour améliorer encore la vitesse de chargement — un site avec autant de photos gagnerait à recadrer et convertir automatiquement chaque image uploadée dans un format plus léger.
Pistes d'évolution envisagées avec le client
Au-delà du cahier des charges initial, plusieurs pistes ont été proposées pour la suite : un rôle administrateur avec un espace de gestion dédié pour le porteur du projet, la possibilité pour les utilisateurs de créer eux-mêmes de nouvelles catégories de figures (plutôt qu'une liste figée) et de supprimer celles qui restent vides, un espace de compte personnel pour modifier son email ou son avatar, une vérification ou un remplacement du code d'intégration vidéo par un simple lien plus accessible aux utilisateurs non techniques, et la possibilité de réorganiser l'ordre des images ou de choisir l'image à la une parmi celles déjà chargées plutôt qu'au moment de l'upload uniquement.
Note
Faker est le seul bundle tiers utilisé, conformément à la contrainte du cahier des charges, pour générer les données de démonstration : 12 figures réparties sur plusieurs catégories, associées à des utilisateurs fictifs — au-delà du minimum de 10 figures demandé.