Application React de location de logements, du découpage en composants à l'intégration API-ready
Scores de cette page :
EcoIndex A
SEO 100%
Accessibilité 100%
Performance 100%
Bonnes Pratiques 100%
Projet de formation (parcours Développeur Web, OpenClassrooms) : reconstruction complète du front-end de Kasa, plateforme de location de logements entre particuliers, en React et React Router à partir de maquettes Figma. Architecture pensée composant par composant, chargement des données en Axios pour anticiper une future API, SCSS organisé en miroir de la structure React.
Contexte
Projet réalisé pendant ma formation de développeuse web (OpenClassrooms). Le brief : reconstruire entièrement l'interface de Kasa, une plateforme de location de logements entre particuliers sur le même principe qu'Airbnb, en React, à partir de maquettes fournies. Pas de vrai back-end à ce stade de la formation : les logements viennent d'un fichier JSON, mais le code va chercher ces données exactement comme il irait chercher une vraie base en ligne — le jour où un back-end existe, il suffit de changer une adresse, pas de réécrire la logique.
Cinq pages, une structure pensée pour s'y retrouver facilement
Le site tient en cinq pages : l'accueil avec la liste des logements, la page à propos, la fiche détaillée d'un logement, une page de chargement et une 404. Plutôt que de tout mettre en vrac, le code est rangé en quatre dossiers qui se parlent peu : un pour les pages, un pour les morceaux d'interface réutilisables (le header, le footer, une carte de logement...), un pour les styles, un pour les quelques fonctions utilitaires. Résultat concret : les pages elles-mêmes contiennent très peu de code — la page d'accueil, par exemple, se résume à assembler un header, une liste de cartes et un footer, sans rien de codé en dur entre les deux.
Pourquoi découper en petits morceaux, même sans les réutiliser
Le header, le footer, la navigation et la carte de logement reviennent sur plusieurs pages : les transformer en briques séparées était une évidence. Mais j'ai poussé le découpage plus loin, même là où ça ne servait à rien de « réutiliser » : la fiche d'un logement n'existe qu'à un seul endroit du site, et pourtant elle est éclatée en plusieurs petits morceaux — le carrousel de photos, le titre avec ses étiquettes et ses étoiles, les infos sur l'hôte, la description, les équipements. Pas pour la réutilisation, mais pour la lisibilité : relire ou corriger un seul petit fichier, c'est tout de suite plus simple que de fouiller dans un gros bloc qui fait tout à la fois.
Des données appelées comme pour une vraie base en ligne
Les logements sont stockés dans un simple fichier JSON du projet, mais je ne les lis pas directement : je passe par Axios, exactement comme je le ferais pour interroger un vrai serveur. Ça peut sembler un détour inutile vu qu'il n'y a pas encore de vraie base de données derrière — mais ça évite justement de devoir réécrire cette logique plus tard, le jour où un back-end existera : il suffira de changer l'adresse appelée. Pendant que les données se chargent, une page dédiée s'affiche à l'écran, pour anticiper le cas où le site serait un jour plus lourd ou plus lent à répondre.
La page à propos, en accordéon
Quatre engagements (fiabilité, respect, service, responsabilité) présentés sous forme de volets dépliables : au clic, le texte correspondant s'affiche sans recharger la page, et les autres volets restent fermés. Une façon simple de présenter du contenu dense sans surcharger l'écran dès l'arrivée sur la page.
Un clic sur un volet l'ouvre, sans toucher aux autres :
Le SCSS organisé comme les composants React
En React, chaque composant doit être enveloppé dans un seul élément racine — cette règle m'a donné l'idée d'organiser les styles de la même façon : la classe qui enveloppe tout le contenu d'un composant porte le même nom que son fichier, et le fichier SCSS correspondant reproduit la même hiérarchie, du parent vers l'enfant. J'ai travaillé d'abord sur la version ordinateur, puis adapté au mobile (plutôt que l'inverse) : grâce à cette organisation en miroir, je retrouve immédiatement, en comparant les deux maquettes, où ajouter les réglages propres au mobile pour un composant donné, sans risquer de dérégler le reste du site.
Navigation simple, carrousel qui boucle
Trois pages principales (accueil, à propos, fiche d'un logement avec son identifiant dans l'adresse), plus une redirection automatique vers la 404 pour toute adresse inconnue. La navigation reste volontairement minimale : le logo renvoie à l'accueil, le menu ne propose que deux liens, et chaque carte de logement mène à sa propre fiche. Sur cette fiche, le carrousel de photos boucle dans les deux sens — de la dernière image on revient à la première, et inversement — avec une version mobile réorganisée verticalement, conformément aux maquettes fournies et vérifiée à l'écran pendant la présentation du projet.
Petits détails de configuration
Les icônes (flèches du carrousel, chevrons) viennent de Font Awesome, chargées directement dans la page plutôt que via une installation complète — suffisant pour les quelques icônes utilisées ici. Le fichier README du dépôt contient le brief pédagogique complet du projet plutôt qu'une documentation technique classique : une particularité propre aux projets de formation OpenClassrooms, où les consignes et le contexte client (fictif) sont fournis sous cette forme.
Note
Projet validé lors de la soutenance, avec deux retours positifs explicites du mentor : le choix de Sass, déjà utilisé sur un projet précédent de la formation et remobilisé ici de façon cohérente — un réflexe que peu d'étudiants ont d'un projet à l'autre — et l'ajout d'une page de chargement dédiée, un plus non demandé par le brief mais salué comme une bonne pratique.