Connected Housing - IoT & Home Automation Platform

Event-driven microservices platform for smart housing with real-time IoT communication, interactive showroom, and Kubernetes infrastructure within a major French real estate group.

March 2019 - January 2020

~11 months

Technical Lead

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

Connected Housing - IoT & Home Automation Platform

Event-driven microservices platform for smart housing with real-time IoT communication, interactive showroom, and Kubernetes infrastructure within a major French real estate group.

March 2019 - January 2020

~11 months

Technical Lead

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

Environments

PROD + PREPROD

Microservices

Event Arbitrator + POC Mercure

Infrastructure Tickets

SRQ resolved

Team Members

Cross-functional team

Presentation

Project definition and scope

The Connected Housing program was a strategic initiative by Groupe Pichet, one of France's leading property developers, aimed at integrating home automation and IoT (Internet of Things) solutions into the group's new-build residential programs.

The project encompassed both a technical dimension (microservices, back-office, interactive showroom) and a commercial dimension (prospect demonstrations in a physical showroom). The goal was to offer a differentiating experience to homebuyers: connected lighting, energy management, remote security - all controllable from a centralized application.

As Technical Lead, I contributed to the core technical infrastructure: the Event Arbitrator microservice for IoT event routing, the POC Mercure protocol for real-time communication, Azure AD SSO integration for the back-office, Kubernetes deployment, and Centreon monitoring setup.

Domain

Real Estate / PropTech / Internet of Things (IoT) / Home Automation

Target Users

New-build homebuyers (B2C) and Groupe Pichet sales teams (showroom demonstrations)

Functional Scope

IoT Event Arbitrator

Interactive Showroom (Mercure)

Back-Office (Azure AD SSO)

Kubernetes Deployments

Health Pages (Centreon)

CI/CD Pipelines (GitLab)

System Architecture - Event Flow

Objectives, Context, Stakes & Risks

Strategic vision and constraints

Objectives

Develop a back-office for connected housing management with Azure AD Single Sign-On authentication
Prototype an interactive showroom with real-time communication via the Mercure protocol (POC)
Deploy the full infrastructure to production and pre-production environments on Kubernetes
Implement comprehensive monitoring through Centreon health pages for system availability tracking
Design and build the Event Arbitrator microservice for reliable IoT event routing and processing

Context

The project was born in a context of digital transformation for the real estate industry. Groupe Pichet, traditionally focused on property development and management, sought to position itself as an innovative player in the PropTech space. The connected housing program was part of a broader strategy to differentiate Groupe Pichet's offerings in an increasingly competitive new-build market.

The technical infrastructure relied on the group's internal Kariba platform (gitlab.kariba.fr, k8s.kariba.fr), a shared Kubernetes cluster hosting multiple applications across the organization. This shared infrastructure introduced both advantages (economies of scale, standardized tooling) and constraints (dependency on platform team for provisioning, shared resource limitations).

Business Stakes

Market Innovation

Position Groupe Pichet as a pioneer in connected housing among French property developers, creating a differentiating competitive advantage

Commercial Differentiation

Offer an immersive connected living experience in the physical showroom to drive buyer interest and accelerate new-build sales

Technical Architecture

Establish a scalable event-driven architecture capable of handling real-time IoT data streams from thousands of future connected units

Architecture Effort Distribution

Identified Risks

IoT Protocol Immaturity

The Mercure protocol was relatively new at the time, with limited production references. Using it for real-time showroom communication involved technology risk.

Shared Infrastructure Dependencies

Reliance on the shared Kariba Kubernetes cluster meant provisioning delays and vulnerability to platform-level incidents (e.g., cluster migration causing monitoring loss).

Cross-Team Coordination

The project involved multiple teams (SI Marketing, Kariba platform, Claranet/Oxalide ops) with different priorities and release cycles, creating alignment challenges.

The Steps - What I Did

Chronological phases and personal contributions

Project Progress Over Time

Phase 1

Phase 1 - Environment Setup

March 2019

Obtained Developer access to the Logement Connecte / showroom / poc-mercure repository on gitlab.kariba.fr
Analyzed existing codebase and understood the showroom application architecture
Set up local development environment with Docker containers mirroring production Kubernetes setup

Phase 2

Phase 2 - Event Arbitrator & Infrastructure

April 2019

Designed and developed the Event Arbitrator microservice for IoT event routing and processing
Requested and coordinated creation of PROD and PREPROD environments (SRQ0409864)
Implemented Centreon health page monitoring for production systems (SRQ0409278)
Extended monitoring to pre-production environment (SRQ0409998)

Phase 3

Phase 3 - Back-Office & SSO Integration

May - June 2019

Participated in back-office architecture meetings for Azure AD SSO integration
Contributed to the Mercure POC implementation for real-time event streaming to the showroom
Collaborated with the team on the connection layer between IoT sensors and the Event Arbitrator

Phase 4

Phase 4 - Presentation & Stabilization

September 2019 - January 2020

Participated in internal presentation "Presentation Offre Logement Connecte" to showcase the product and application
Diagnosed and resolved monitoring probe loss after Kubernetes cluster migration (SRQ0609468)
Worked with Claranet/Oxalide to restore Centreon monitoring on the new cluster infrastructure

Kubernetes Deployment Architecture

The Actors - Interactions

Stakeholders and collaboration dynamics

The Connected Housing project was inherently cross-functional, bringing together people from marketing, IT, development, and infrastructure operations. This diversity was both a strength and a challenge.

Remi P. (SI Marketing Project Manager) was the driving force behind the project, organizing meetings and aligning business requirements with technical capabilities. His role was crucial in translating commercial vision into actionable technical specifications.

Thomas R. (Kariba Developer) was a key collaborator on the Mercure POC, bringing expertise in the Kariba platform ecosystem. Our collaboration was hands-on: pair programming sessions, code reviews, and joint debugging of the real-time communication layer.

Franck C. (N+1, Technical Coordinator) provided strategic technical guidance and ensured alignment with the broader IT roadmap. His oversight helped prioritize tasks when multiple stakeholders had competing requests.

Antoine D. (Claranet/Oxalide) was our infrastructure partner, responsible for setting up and maintaining Centreon monitoring. When monitoring probes were lost after the cluster migration in December 2019, his rapid intervention was essential to restoring system visibility.

The wider team - Adrien ROCHES, Ludwig PICQUART, Alexandre GIRAUD, Stephane LOUBEYRES - each brought specific technical expertise to the back-office development, creating a truly collaborative engineering environment.

The main challenge was coordinating across organizational boundaries: the SI Marketing team had business-driven timelines, the Kariba platform team managed shared infrastructure with its own priorities, and Claranet/Oxalide operated under service-level agreements with defined response times. Aligning these different rhythms required constant communication and flexible planning.

Team Size

8+ people across 3 organizations

Methodology

Agile iterations with cross-team synchronization meetings

Collaboration Tools

GitLab (code + CI), Jira (SRQ tickets), 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

The Results

Personal growth and organizational impact

For Me

Gained hands-on experience with event-driven architecture in a real IoT context, moving beyond theoretical knowledge to production implementation
Deepened expertise in Kubernetes deployment and operations, including environment provisioning, health monitoring, and cluster migration recovery
Developed skills in real-time communication protocols (Mercure/SSE), understanding their strengths and limitations for IoT use cases
Strengthened cross-team coordination abilities, learning to navigate organizational complexity with multiple stakeholders having different priorities
Acquired domain knowledge in PropTech and IoT, understanding the unique challenges of connecting physical devices to digital platforms in real estate

For the Company

2 production environments deployed and operational on Kubernetes - enabling live demos to prospective buyers in the showroom
Event Arbitrator microservice successfully routing IoT events from sensors to the back-office and showroom applications
Comprehensive monitoring via Centreon health pages ensuring system availability was visible and measurable
Interactive showroom powered by Mercure protocol providing real-time demonstrations of connected housing capabilities
Commercial differentiation - Groupe Pichet could present itself as an innovative property developer with a tangible connected housing offering

Infrastructure Metrics

Tech Stack Radar

System Availability

The Aftermath

What happened next

Immediately after delivery, the Connected Housing showroom became an active commercial tool for Groupe Pichet's sales teams. Prospect visits included live demonstrations of the connected features, with real-time interactions powered by the Mercure protocol infrastructure we had built.

In the medium term, the project faced the typical challenges of innovative initiatives within large traditional organizations. The real estate market's cyclical nature, combined with the costs of equipping each unit with IoT devices, led to a reassessment of the program's scale and economic model. The question shifted from "can we do it technically?" (which we had proven) to "does the cost-benefit ratio justify systematic deployment?"

The infrastructure legacy outlasted the specific connected housing application. The patterns established - event-driven microservices on Kubernetes, health monitoring via Centreon, GitLab CI/CD pipelines - became templates for subsequent projects within the Kariba platform. The Event Arbitrator's architecture influenced how later projects approached asynchronous communication.

Today, the connected housing market has evolved significantly. What was innovative in 2019 has become more mainstream, with major players (Legrand, Schneider Electric, Somfy) offering standardized solutions. The early work at Groupe Pichet demonstrated foresight in recognizing this trend, even if the commercial rollout was more cautious than initially envisioned.

My Critical Reflection

Honest retrospective and lessons learned

What Worked Well

The event-driven architecture choice was sound. Using a dedicated Event Arbitrator to decouple IoT sensors from consuming applications proved to be the right pattern. It allowed the showroom and back-office to evolve independently while sharing the same event stream.
Kubernetes deployment provided the right abstraction level. Having PROD and PREPROD environments on the same cluster enabled rapid iteration and reliable testing before production releases.
Centreon monitoring caught real issues. When the cluster migration caused probe loss, the monitoring gap was immediately visible - proving the monitoring investment was justified.

What Could Have Been Better

The Mercure POC should have been validated earlier with load testing. We proved the concept worked but did not rigorously test its behavior under realistic IoT event volumes. This left an open question about scalability.
Documentation was insufficient. The cross-team nature of the project meant knowledge was distributed across people rather than centralized in documentation. When team members changed, onboarding was slower than it should have been.
The business model validation should have preceded the technical implementation. We built a technically sound solution before fully validating the unit economics of equipping apartments with IoT devices at scale.

What I Would Do Differently

Start with a lean MVP focused on 2-3 key connected features rather than a broad platform - validate commercial traction before investing in full infrastructure
Implement structured ADRs (Architecture Decision Records) from day one to capture the reasoning behind technical choices for future team members
Push for end-to-end integration tests simulating IoT device events through the full pipeline to the showroom display, rather than relying primarily on manual testing
Negotiate dedicated infrastructure rather than shared Kubernetes cluster to avoid dependency on platform team schedules and reduce blast radius of cluster-level incidents

Lessons Learned

1
Innovation in traditional industries requires patience - technical feasibility is necessary but not sufficient; commercial viability and organizational readiness are equally important
2
Event-driven architectures shine in IoT contexts where decoupling producers (sensors) from consumers (applications) is essential for system resilience
3
Monitoring is not optional infrastructure - it is a first-class requirement. The cluster migration incident proved that invisible systems are unmanageable systems
4
Cross-organizational projects need explicit communication protocols - assumptions about who knows what and who is responsible for what must be documented, not implied