--- title: "Logement Connecté - Plateforme IoT & Domotique" description: "Plateforme de microservices event-driven pour le logement connecté avec communication IoT temps réel, showroom interactif et infrastructure Kubernetes au sein d'un grand groupe immobilier français." locale: "fr" canonical: "https://portfolio.josedacosta.info/fr/realisations/logement-connecte-iot-domotique" source: "https://portfolio.josedacosta.info/fr/realisations/logement-connecte-iot-domotique.md" html_source: "https://portfolio.josedacosta.info/fr/realisations/logement-connecte-iot-domotique" author: "José DA COSTA" date: "2019" type: "achievement" slug: "logement-connecte-iot-domotique" tags: ["Mercure Protocol", "Azure AD", "Kubernetes", "Docker", "Centreon", "GitLab CI", "SSE", "IoT"] generated_at: "2026-04-23T15:45:27.983Z" --- # Logement Connecté - Plateforme IoT & Domotique Plateforme de microservices event-driven pour le logement connecté avec communication IoT temps réel, showroom interactif et infrastructure Kubernetes au sein d'un grand groupe immobilier français. **Date:** Mars 2019 - Janvier 2020 **Duration:** ~11 mois **Role:** Lead Technique **Technologies:** Mercure Protocol, Azure AD, Kubernetes, Docker, Centreon, GitLab CI, SSE, IoT ### Key Metrics - Environnements: **-** - PROD + PREPROD - Microservices: **-** - Event Arbitrator + POC Mercure - Tickets Infrastructure: **-** - SRQ resolus - Membres d'équipe: **-** - Équipe transversale ## Présentation _Définition et périmètre du projet_ ### Domain Immobilier / PropTech / Internet des Objets (IoT) / Domotique ### Target Users Acquereurs de logements neufs (B2C) et équipes commerciales Groupe Pichet (démonstrations en showroom) **Content:** Le programme **Logement Connecte** était une initiative stratégique du **Groupe Pichet**, l'un des premiers promoteurs immobiliers français, visant a intégrer des solutions de domotique et d'IoT (Internet des Objets) dans les programmes immobiliers neufs du groupe. Le projet comportait une **dimension technique** (microservices, back-office, showroom interactif) et une **dimension commerciale** (démonstrations aux prospects dans un showroom physique). L'objectif était d'offrir une expérience differenciante aux acquereurs : eclairage connecté, gestion energetique, sécurité à distance - le tout pilotable depuis une application centralisee. En tant que **Lead Technique**, j'ai contribué à l'infrastructure technique centrale : le microservice Event Arbitrator pour le routage des événements IoT, le POC du protocole Mercure pour la communication temps réel, l'intégration SSO Azure AD pour le back-office, le déploiement Kubernetes et la mise en place du monitoring Centreon. **Domain:** Domaine **Target Users:** Utilisateurs cibles **Functional Scope:** Périmètre fonctionnel **Scope Event Arbitrator:** Event Arbitrator IoT **Scope Showroom:** Showroom interactif (Mercure) **Scope Back Office:** Back-Office (SSO Azure AD) **Scope Kubernetes:** Déploiements Kubernetes **Scope Monitoring:** Health Pages (Centreon) **Scope C I C D:** Pipelines CI/CD (GitLab) ## Objectifs, Contexte, Enjeux & Risques _Vision stratégique et contraintes_ ### Context Le projet est ne dans un contexte de **transformation digitale du secteur immobilier**. Le Groupe Pichet, traditionnellement centre sur la promotion et la gestion immobilière, cherchait a se positionner comme un acteur innovant dans l'espace PropTech. Le programme logement connecté s'inscrivait dans une stratégie plus large de differenciation de l'offre du Groupe Pichet sur un marché du neuf de plus en plus concurrentiel. L'infrastructure technique s'appuyait sur la plateforme interne **Kariba** du groupe (gitlab.kariba.fr, k8s.kariba.fr), un cluster Kubernetes partage hebergeant de multiples applications. Cette infrastructure mutualisee introduisait des avantages (économies d'échelle, outillage standardise) et des contraintes (dépendance à l'équipe plateforme pour le provisionnement, limitations des ressources partagees). ### Stake Innovation Positionner le Groupe Pichet comme un pionnier du logement connecté parmi les promoteurs immobiliers français, creant un avantage concurrentiel differenciateur ### Stake Commercial Offrir une expérience immersive de vie connectée dans le showroom physique pour stimuler l'intérêt des acquereurs et accelerer les ventes de logements neufs ### Stake Architecture Etablir une architecture event-driven evolutive capable de gérer les flux de données IoT temps réel de milliers de futures unites connectees - Développer un back-office de gestion du logement connecté avec authentification Single Sign-On Azure AD - Prototyper un showroom interactif avec communication temps réel via le protocole Mercure (POC) - Déployer l'infrastructure complète en production et pre-production sur Kubernetes - Mettre en place un monitoring complet via des health pages Centreon pour le suivi de disponibilité - Concevoir et développer le microservice Event Arbitrator pour le routage fiable des événements IoT **Objectives:** Objectifs **Context:** Contexte **Stakes:** Enjeux business **Stake Innovation:** Innovation marche **Stake Commercial:** Differenciation commerciale **Stake Architecture:** Architecture technique **Risks:** Risques identifies **Risk1 Title:** Immaturité du protocole IoT **Risk1 Desc:** Le protocole Mercure était relativement nouveau à l'epoque, avec peu de références en production. Son utilisation pour la communication temps réel du showroom comportait un risque technologique. **Risk2 Title:** Dépendances infrastructure partagee **Risk2 Desc:** La dépendance au cluster Kubernetes partage Kariba impliquait des délais de provisionnement et une vulnérabilité aux incidents plateforme (ex. : migration de cluster causant une perte de monitoring). **Risk3 Title:** Coordination inter-équipes **Risk3 Desc:** Le projet impliquait plusieurs équipes (SI Marketing, plateforme Kariba, Claranet/Oxalide ops) avec des priorités et des cycles de release différents, creant des defis d'alignement. ## Les Étapes - Ce que j'ai fait _Phases chronologiques et contributions personnelles_ - Phase 1 - Mise en place de l'environnement - Phase 2 - Event Arbitrator & Infrastructure - Phase 3 - Back-Office & Intégration SSO - Phase 4 - Présentation & Stabilisation **Phase1 Period:** Mars 2019 **Phase2 Period:** Avril 2019 **Phase3 Period:** Mai - Juin 2019 **Phase4 Period:** Septembre 2019 - Janvier 2020 ## Les Acteurs - Les Interactions _Parties prenantes et dynamiques de collaboration_ **Content:** Le projet Logement Connecté était intrinsequement **transversal**, reunissant des personnes du marketing, de l'IT, du développement et des opérations d'infrastructure. Cette diversite était à la fois une force et un defi. **Remi P.** (Chef de Projet SI Marketing) était le moteur du projet, organisant les réunions et alignant les besoins business avec les capacités techniques. Son rôle était crucial pour traduire la vision commerciale en spécifications techniques actionnables. **Thomas R.** (Développeur Kariba) était un collaborateur clé sur le POC Mercure, apportant son expertise de l'écosystème de la plateforme Kariba. Notre collaboration était concrète : sessions de pair programming, revues de code et debogage conjoint de la couche de communication temps réel. **Franck C.** (N+1, Coordinateur technique) apportait une direction technique stratégique et assurait l'alignement avec la feuille de route IT globale. Sa supervision aidait a prioriser les tâches lorsque plusieurs parties prenantes avaient des demandes concurrentes. **Antoine D.** (Claranet/Oxalide) était notre partenaire infrastructure, responsable de la mise en place et de la maintenance du monitoring Centreon. Lorsque les sondes de monitoring ont été perdues après la migration du cluster en décembre 2019, son intervention rapide a été essentielle pour restaurer la visibilité système. L'équipe élargie - **Adrien ROCHES**, **Ludwig PICQUART**, **Alexandre GIRAUD**, **Stephane LOUBEYRES** - apportait chacun une expertise technique spécifique au développement du back-office, creant un environnement d'ingenierie veritablement collaboratif. Le defi principal était de **coordonner entre les frontieres organisationnelles** : l'équipe SI Marketing avait des délais guides par le business, l'équipe plateforme Kariba gerait une infrastructure partagee avec ses propres priorités, et Claranet/Oxalide operait sous des accords de niveau de service avec des temps de réponse definis. Aligner ces rythmes différents nécessitait une communication constante et une planification flexible. **Team Size:** Taille de l'équipe **Team Size Value:** 8+ personnes reparties sur 3 organisations **Methodology:** Méthodologie **Methodology Value:** Iterations agiles avec réunions de synchronisation inter-équipes **Tools:** Outils de collaboration **Tools Value:** GitLab (code + CI), Jira (tickets SRQ), Outlook (coordination) ## Les Résultats _Croissance personnelle et impact organisationnel_ ## Les Lendemains du Projet _Ce qui s'est passe ensuite_ **Content:** **Immédiatement après la livraison**, le showroom Logement Connecté est devenu un outil commercial actif pour les équipes de vente du Groupe Pichet. Les visites de prospects incluaient des démonstrations en direct des fonctionnalités connectees, avec des interactions temps réel alimentees par l'infrastructure du protocole Mercure que nous avions construite. **A moyen terme**, le projet a fait face aux defis typiques des initiatives innovantes au sein de grandes organisations traditionnelles. La nature cyclique du marché immobilier, combinee aux coûts d'équipement de chaque unite en dispositifs IoT, a conduit à une reévaluation de l'échelle et du modèle economique du programme. La question est passee de "peut-on le faire techniquement ?" (ce que nous avions prouve) a "le ratio cout-bénéfice justifie-t-il un déploiement systematique ?" **L'héritage d'infrastructure** a survécu à l'application spécifique du logement connecte. Les patterns etablis - microservices event-driven sur Kubernetes, monitoring de sante via Centreon, pipelines CI/CD GitLab - sont devenus des modèles pour les projets subsequents au sein de la plateforme Kariba. L'architecture de l'Event Arbitrator a influence la façon dont les projets ultérieurs ont aborde la communication asynchrone. **Aujourd'hui**, le marché du logement connecté a considérablement evolue. Ce qui était innovant en 2019 est devenu plus courant, avec des acteurs majeurs (Legrand, Schneider Electric, Somfy) proposant des solutions standardisees. Le travail precurseur au Groupe Pichet a démontré une vision prospective dans la reconnaissance de cette tendance, même si le déploiement commercial a été plus prudent qu'initialement envisage. ## Mon Regard Critique _Rétrospective honnete et leçons apprises_ ### What Worked - **Le choix de l'architecture event-driven était judicieux.** L'utilisation d'un Event Arbitrator dédié pour decoupler les capteurs IoT des applications consommatrices s'est avéré être le bon pattern. Cela a permis au showroom et au back-office d'évoluer independamment tout en partageant le même flux d'événements. - **Le déploiement Kubernetes offrait le bon niveau d'abstraction.** Disposer d'environnements PROD et PREPROD sur le même cluster a permis une iteration rapide et des tests fiables avant les releases en production. - **Le monitoring Centreon a détecté de vrais problèmes.** Lorsque la migration du cluster à cause la perte des sondes, le gap de monitoring était immédiatement visible - prouvant que l'investissement en monitoring était justifie. ### What Could Improve - **Le POC Mercure aurait du être validé plus tot avec des tests de charge.** Nous avons prouve que le concept fonctionnait mais n'avons pas rigoureusement teste son comportement sous des volumes d'événements IoT realistes. Cela a laisse une question ouverte sur la scalabilité. - **La documentation était insuffisante.** La nature inter-équipes du projet signifiait que la connaissance était distribuee entre les personnes plutôt que centralisee dans la documentation. Lorsque des membres de l'équipe changeaient, l'onboarding était plus lent qu'il n'aurait du l'être. - **La validation du modèle economique aurait du preceder l'implémentation technique.** Nous avons construit une solution techniquement solide avant de valider complètement l'economie unitaire de l'équipement des appartements en dispositifs IoT a grande échelle. ### Would Do Differently - Commencer par un **MVP lean centre sur 2-3 fonctionnalités connectées clés** plutôt qu'une plateforme large - valider la traction commerciale avant d'investir dans l'infrastructure complete - Implementer des **ADR structures** (Architecture Décision Records) des le premier jour pour capturer le raisonnement derriere les choix techniques pour les futurs membres de l'équipe - Insister sur des **tests d'intégration bout en bout** simulant les événements des appareils IoT à travers tout le pipeline jusqu'à l'affichage du showroom, plutôt que de se fier principalement aux tests manuels - Negocier une **infrastructure dediee** plutôt qu'un cluster Kubernetes partage pour éviter la dépendance aux calendriers de l'équipe plateforme et réduire le rayon d'impact des incidents au niveau du cluster ### Lessons - L'innovation dans les industries traditionnelles requiert de la patience - la faisabilite technique est nécessaire mais pas suffisante ; la viabilite commerciale et la maturité organisationnelle sont tout aussi importantes - Les architectures event-driven excellent dans les contextes IoT ou le decouplage des producteurs (capteurs) et des consommateurs (applications) est essentiel pour la résilience du système - Le monitoring n'est pas une infrastructure optionnelle - c'est une exigence de premier ordre. L'incident de migration du cluster a prouve que les systèmes invisibles sont des systèmes ingerables - Les projets inter-organisationnels nécessitent des protocoles de communication explicites - les hypotheses sur qui sait quoi et qui est responsable de quoi doivent être documentees, pas implicites **What Worked:** Ce qui a bien fonctionne **What Could Improve:** Ce qui aurait pu être mieux **Would Do Differently:** Ce que je ferais différemment **Lessons:** Leçons apprises