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.

Mars 2019 - Janvier 2020

~11 mois

Lead Technique

Mercure ProtocolAzure Active DirectoryKubernetesDockerCentreonGitLab CISSE (Server-Sent Events)IoT SensorsMicroservices

Logement Connecté - Plateforme IoT & Domotique

Mars 2019 - Janvier 2020

~11 mois

Lead Technique

Mercure ProtocolAzure Active DirectoryKubernetesDockerCentreonGitLab CISSE (Server-Sent Events)IoT SensorsMicroservices

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

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.

Domaine

Immobilier / PropTech / Internet des Objets (IoT) / Domotique

Utilisateurs cibles

Acquereurs de logements neufs (B2C) et équipes commerciales Groupe Pichet (démonstrations en showroom)

Périmètre fonctionnel

Event Arbitrator IoT

Showroom interactif (Mercure)

Back-Office (SSO Azure AD)

Déploiements Kubernetes

Health Pages (Centreon)

Pipelines CI/CD (GitLab)

Architecture système - Flux d'événements

Objectifs, Contexte, Enjeux & Risques

Vision stratégique et contraintes

Objectifs

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

Contexte

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).

Enjeux business

Innovation marche

Positionner le Groupe Pichet comme un pionnier du logement connecté parmi les promoteurs immobiliers français, creant un avantage concurrentiel differenciateur

Differenciation commerciale

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

Architecture technique

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

Architecture Effort Distribution

Risques identifies

Immaturité du protocole IoT

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.

Dépendances infrastructure partagee

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).

Coordination inter-équipes

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

Progression du projet dans le temps

Phase 1

Phase 1 - Mise en place de l'environnement

Mars 2019

Obtention de l'accès Developer au repository Logement Connecté / showroom / poc-mercure sur gitlab.kariba.fr
Analyse du code existant et compréhension de l'architecture de l'application showroom
Configuration de l'environnement de développement local avec des conteneurs Docker reproduisant la configuration Kubernetes de production

Phase 2

Phase 2 - Event Arbitrator & Infrastructure

Avril 2019

Conception et développement du microservice Event Arbitrator pour le routage et le traitement des événements IoT
Demande et coordination de la création des environnements PROD et PREPROD (SRQ0409864)
Implémentation du monitoring health pages Centreon pour les systèmes de production (SRQ0409278)
Extension du monitoring à l'environnement de pre-production (SRQ0409998)

Phase 3

Phase 3 - Back-Office & Intégration SSO

Mai - Juin 2019

Participation aux réunions d'architecture du back-office pour l'intégration SSO Azure AD
Contribution à l'implémentation du POC Mercure pour le streaming d'événements temps réel vers le showroom
Collaboration avec l'équipe sur la couche de connexion entre les capteurs IoT et l'Event Arbitrator

Phase 4

Phase 4 - Présentation & Stabilisation

Septembre 2019 - Janvier 2020

Participation à la présentation interne "Présentation Offre Logement Connecte" pour presenter le produit et l'application
Diagnostic et résolution de la perte des sondes monitoring après la migration du cluster Kubernetes (SRQ0609468)
Collaboration avec Claranet/Oxalide pour restaurer le monitoring Centreon sur la nouvelle infrastructure du cluster

Architecture de déploiement Kubernetes

Les Acteurs - Les Interactions

Parties prenantes et dynamiques de collaboration

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.

Taille de l'équipe

8+ personnes reparties sur 3 organisations

Méthodologie

Iterations agiles avec réunions de synchronisation inter-équipes

Outils de collaboration

GitLab (code + CI), Jira (tickets SRQ), Outlook (coordination)

Remi P.

SI Marketing Project Manager

Driving force behind the project, organized meetings and aligned business requirements with technical capabilities

Thomas R.

Kariba Developer

Key collaborator on POC Mercure, pair programming sessions and joint debugging of real-time communication

Franck C.

N+1 - Technical Coordinator

Strategic technical guidance, ensured alignment with broader IT roadmap and prioritized competing requests

Antoine D.

Claranet/Oxalide - Infrastructure

Set up and maintained Centreon monitoring, critical intervention during cluster migration incident

Les Résultats

Croissance personnelle et impact organisationnel

Pour moi

Acquisition d'une expérience pratique en architecture event-driven dans un contexte IoT réel, passant de la connaissance theorique à l'implémentation en production
Approfondissement de l'expertise en déploiement et opérations Kubernetes, incluant le provisionnement d'environnements, le monitoring de sante et la récupération après migration de cluster
Développement de compétences en protocoles de communication temps réel (Mercure/SSE), comprenant leurs forces et limités pour les cas d'usage IoT
Renforcement des capacités de coordination inter-équipes, apprenant à naviguer dans la complexité organisationnelle avec de multiples parties prenantes aux priorités différentes
Acquisition de connaissances métier en PropTech et IoT, comprenant les defis uniques de la connexion d'appareils physiques à des plateformes digitales dans l'immobilier

Pour l'entreprise

2 environnements de production déployés et opérationnels sur Kubernetes - permettant des demos en direct aux prospects dans le showroom
Microservice Event Arbitrator routant avec succès les événements IoT des capteurs vers le back-office et les applications showroom
Monitoring complet via les health pages Centreon assurant une visibilité et une mesurabilite de la disponibilité système
Showroom interactif alimenté par le protocole Mercure fournissant des démonstrations temps réel des capacités du logement connecte
Differenciation commerciale - le Groupe Pichet pouvait se presenter comme un promoteur immobilier innovant avec une offre de logement connecté tangible

Métriques d'infrastructure

Tech Stack Radar

System Availability

Les Lendemains du Projet

Ce qui s'est passe ensuite

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

Ce qui a bien fonctionne

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.

Ce qui aurait pu être mieux

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.

Ce que je ferais différemment

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

Leçons apprises

1
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
2
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
3
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
4
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