Studélites
03.2024
BNP Paribas
Présentation
Un opérateur de résidences étudiantes avec 53 sites, 6 000 logements et des annonces qui vivaient dans plusieurs systèmes sans jamais se parler. L'enjeu : tout faire converger dans un seul Drupal, sans perdre en route ni la donnée ni l'expérience.
Notre approche
pour ce projet.
01. Objectifs
Studélites gère 53 résidences implantées dans plus de 20 villes françaises — Bordeaux, Lyon, Paris, Grenoble, Marseille, Chambéry, Valence, Saint-Étienne. Des milliers de logements disponibles, des disponibilités qui changent en temps réel, des prix qui varient selon les résidences, des typologies d'appartements différentes, des services qui ne sont pas les mêmes d'un site à l'autre. En arrière-plan de tout ça : des systèmes de gestion immobilière qui ont leurs propres structures de données, leurs propres flux, leurs propres logiques de publication.
Le problème n'était pas de créer un site. C'était de créer un site qui soit une interface fiable sur des données qui vivent ailleurs — et qui doivent rester à jour sans ressaisie manuelle, sans délai, sans approximation. Un étudiant qui cherche un studio à Lyon pour septembre n'a pas le temps d'attendre qu'un gestionnaire mette à jour une page. La disponibilité est soit vraie soit fausse, et si elle est fausse la plateforme perd en confiance.
02. Approche
Le design venait d'un autre prestataire. Notre terrain était ailleurs : l'architecture technique, le développement Drupal, et surtout l'intégration des APIs externes qui alimentent les annonces en temps réel.
Drupal a été choisi pour ses capacités natives de gestion de contenu structuré à grande échelle — des dizaines de résidences, chacune avec ses propres métadonnées, ses galeries, ses services disponibles, ses prix, ses disponibilités. Un système de types de contenus construit pour cette réalité : pas un template générique appliqué à chaque résidence, mais une architecture qui modélise fidèlement la diversité du parc.
L'intégration des APIs externes était le chantier central. Les annonces ne vivent pas dans Drupal — elles viennent des systèmes de gestion immobilière de BNP Paribas Immobilier Résidences Services, qui ont leurs propres formats, leurs propres rythmes de mise à jour, leurs propres règles de disponibilité. Il fallait concevoir une couche d'intégration robuste : ingestion des flux, normalisation des données, gestion des erreurs, affichage en temps réel côté front — sans que l'équipe ait besoin d'intervenir sur le contenu des annonces elle-même.
03. Résultats
Une plateforme qui affiche des annonces réelles, à jour, issues directement des systèmes de gestion — sans ressaisie, sans délai artificiel. Un étudiant qui cherche un logement à Grenoble voit les disponibilités réelles de la résidence, au moment où il les consulte.
53 résidences dans un seul CMS. Des fiches résidences riches — services, galeries, disponibilités, proximity maps — gérées centralement avec la flexibilité nécessaire pour que chaque site garde sa spécificité. Un moteur de recherche par ville, par critère, par type de logement — alimenté par des données propres.
L'intégration API tient en production depuis sa mise en service. Les flux arrivent, se normalisent, s'affichent. Quand quelque chose déraille côté source, le système le dit, et l'équipe le voit avant les utilisateurs.
Méthode
Intégrer une API externe dans un CMS, c'est plus facile à dire qu'à faire quand la source de données a son propre caractère.
Les flux immobiliers ont des structures qui ne correspondent jamais exactement à ce que le front a besoin d'afficher. Il y a toujours un écart entre "ce que le système de gestion sait dire" et "ce que l'utilisateur doit voir". Cet écart se gère dans la couche d'intégration — par des transformations, des validations, des règles de fallback pour les champs manquants, des logiques de cache pour ne pas interroger l'API à chaque chargement de page.
On a conçu ce système pour tenir dans la durée : des endpoints clairement documentés, des logs d'erreur lisibles par l'équipe technique de Studélites, des alertes en cas de rupture de flux. Une intégration qui ne se contente pas de fonctionner au moment de la livraison — mais qui peut être maintenue et surveillée par d'autres que ceux qui l'ont construite.
L'architecture Drupal a été pensée avec la même exigence de maintenabilité. Des modules bien séparés, une gestion des dépendances propre, une configuration versionnée — pour que les évolutions futures de la plateforme ne nécessitent pas de repartir de zéro à chaque fois qu'une résidence s'ajoute ou qu'un service change.
