Origine et objectifs du projet

Le projet HAP (Housing Application) est né d’un besoin fictif mais réaliste : concevoir une plateforme permettant à des propriétaires de gérer leurs biens immobiliers et à des particuliers ou entreprises de les consulter, le tout depuis un espace web sécurisé et une application mobile dédiée.

Ce projet a été conduit en autonomie tout au long de la deuxième année, avec pour objectif de couvrir l’intégralité du cycle de développement : analyse du besoin, modélisation de la base de données, développement back-end, création de l’API, développement mobile et documentation technique.

Objectifs pédagogiques

HAP a été conçu pour valider plusieurs compétences clés du référentiel BTS SIO SLAM : conception d’une base de données relationnelle, développement d’une API REST sécurisée, gestion des rôles et des droits, et intégration d’une couche mobile communiquant avec le back-end.

Structure du projet

HAP repose sur une architecture en deux volets complémentaires qui partagent la même base de données et la même API REST centrale.

Projet HAP — Web
Interface d’administration PHP/MySQL
  • Tableau de bord administrateur
  • Gestion des utilisateurs et des rôles
  • CRUD complet sur les biens immobiliers
  • Accès exclusif aux fonctions admin
  • Singleton PDO centralisé
  • Transactions SQL pour l’intégrité des données
  • Protection contre les injections SQL et XSS
HapMobile — Flutter
Application mobile Dart/Flutter
  • Inscription et connexion via JWT
  • Consultation des biens avec pagination
  • Gestion de profil utilisateur
  • Quatre rôles : Visiteur, Particulier, Entreprise, Propriétaire
  • État global géré par Riverpod
  • Gestion des erreurs réseau
  • Interface responsive multi-plateforme
L’API REST — Pont entre les deux volets

Les deux applications communiquent via une API REST développée en PHP. Chaque requête est authentifiée par un token JWT (algorithme HS256, expiration 30 jours). L’API valide les droits de l’utilisateur avant chaque opération, garantissant que seuls les rôles autorisés accèdent aux ressources correspondantes.

Stack technique utilisée

PHP 8
Back-end web
MySQL
Base de données
Flutter
Application mobile
Dart
Langage mobile
JWT
Authentification
PDO
Accès base de données
Riverpod
State management
REST API
Communication
Git / GitHub
Versioning
Merise
Modélisation BDD

Schéma de la base de données

La base de données de HAP a été conçue avec la méthode Merise. Voici le modèle logique des principales entités du projet, représentant les relations entre les utilisateurs, leurs rôles, les biens immobiliers et les interactions associées.

UTILISATEUR 🔑 id_utilisateur (PK) nom prenom email mot_de_passe (hash) date_inscription token_jwt 🔗 id_role (FK) 🔗 id_bien (FK, nullable) ROLE 🔑 id_role (PK) libelle description plateforme (web/mobile) BIEN_IMMOBILIER 🔑 id_bien (PK) titre description prix surface_m2 ville date_publication 🔗 id_proprietaire (FK) FAVORIS 🔑 id_favori (PK) 🔗 id_utilisateur (FK) 🔗 id_bien (FK) date_ajout MESSAGE 🔑 id_message (PK) 🔗 id_expediteur (FK) 🔗 id_destinataire (FK) 🔗 id_bien (FK) contenu date_envoi N:1 1:N LÉGENDE 🔑 Clé primaire (PK) 🔗 Clé étrangère (FK) Relation entre tables MLD simplifié — Projet HAP v1.0 (beta) 5 tables · Relations 1:N et N:M via tables de liaison

Difficultés rencontrées et solutions apportées

Tout projet de développement réel comporte des obstacles techniques. En voici les principaux que j’ai rencontrés sur HAP, et la façon dont je les ai résolus.

01

Gestion de l’authentification JWT entre le web et le mobile

Problème

Au départ, le système d’authentification était géré différemment côté web (sessions PHP) et côté mobile (tokens maison). Cela créait des incohérences : un utilisateur pouvait être authentifié sur un volet et rejeté sur l’autre pour la même ressource.

Solution

J’ai unifié l’authentification autour d’un système JWT centralisé (HS256, expiration 30 jours). L’API REST vérifie désormais le token à chaque requête, quel que soit le client. Une seule logique d’authentification pour les deux volets.

02

Intégrité des données lors des opérations critiques

Problème

Lors de la suppression d’un bien immobilier, des données orphelines subsistaient en base (favoris, messages liés). Cela provoquait des erreurs d’affichage côté mobile et compromettait l’intégrité des données.

Solution

Mise en place de transactions SQL avec PDO : les suppressions sont désormais atomiques. Si l’une des étapes échoue, l’ensemble de l’opération est annulé via ROLLBACK. Ajout de contraintes de clés étrangères avec ON DELETE CASCADE.

03

Gestion de l’état global dans Flutter

Problème

Les données de l’utilisateur connecté (profil, rôle, favoris) devaient être accessibles depuis n’importe quel écran de l’application mobile. Passer ces données manuellement de widget en widget rendait le code illisible et difficile à maintenir.

Solution

Adoption de Riverpod comme solution de state management. Les providers centralisent l’état global et chaque widget s’abonne uniquement aux données dont il a besoin. Le code est devenu beaucoup plus lisible et maintenable.

04

Gestion des erreurs réseau côté mobile

Problème

En cas d’API indisponible ou de connexion instable, l’application Flutter se bloquait sans message d’erreur clair pour l’utilisateur. L’expérience était désastreuse et le comportement imprévisible.

Solution

Implémentation d’une couche de gestion des erreurs réseau systématique : timeout configuré, try/catch sur toutes les requêtes HTTP, messages d’erreur explicites affichés à l’utilisateur, et mécanisme de retry automatique sur les erreurs transitoires.

Compétences mobilisées

Ce projet couvre un large spectre des compétences du référentiel BTS SIO SLAM, ce qui en fait une réalisation centrale pour l’épreuve E4.

B1.4

Travailler en mode projet

Planification des développements, gestion des priorités, versioning Git avec branches dédiées par fonctionnalité.

B1.5

Mettre à disposition un service

Déploiement de l’API REST, tests fonctionnels de bout en bout, rédaction de la documentation technique.

B2.1

Concevoir et développer

Analyse du besoin, modélisation Merise, développement PHP et Flutter, intégration de l’authentification JWT.

B2.2

Maintenance corrective et évolutive

Correction des bugs identifiés lors des tests, évolution des fonctionnalités en réponse aux besoins identifiés.

B2.3

Gérer les données

Conception du MCD/MLD, requêtes SQL complexes, transactions, contrôle d’intégrité référentielle.

B1.6

Développement professionnel

Apprentissage autonome de Flutter/Riverpod et JWT en dehors des cours, veille sur les bonnes pratiques API REST.

Avancement et prochaines étapes

Septembre 2025

Analyse et modélisation

Rédaction du cahier des charges, conception du MCD/MLD, définition de l’architecture et des rôles utilisateurs.

Octobre – Novembre 2025

Développement back-end PHP

Mise en place de la base de données, développement de l’API REST, système d’authentification JWT, singleton PDO.

Novembre 2025 – Janvier 2026

Développement web de l’application

Création de l’application web, intégration de l’API, gestion des rôles, des biens…

Février – Mars 2026

Adaptation de l’appli web en appli mobile

Tests fonctionnels, corrections des bugs identifiés, amélioration de la gestion des erreurs. Mise en place et découverte de Flutter. Statut actuel : version bêta fonctionnelle.

Objectif Avril – Juin 2026

Finalisation et documentation

Finalisation des fonctionnalités restantes, rédaction complète de la documentation technique, préparation pour l’épreuve E4.

Dépôts GitHub

Le code source des deux volets du projet est disponible sur GitHub. Les dépôts sont publics et organisés avec des branches dédiées par fonctionnalité.

Omnous-Luminae / Projet_SLAM
Interface web PHP/MySQL — back-end et administration
Voir le dépôt →
Omnous-Luminae / hap_mobile (en cours de développement)
Application mobile Flutter — interface utilisateur
Voir le dépôt →