Contact
Pipeline ETL de syndication d'annonces immobilières (ligneurs)

Pipeline ETL de syndication d'annonces immobilières (ligneurs)

Pipeline ETL du PIM Akeneo vers les portails immobiliers - livraison multi-format (XML, CSV, JSON) sur 4 ans d'exploitation continue.

Janvier 2019 - 2023
~4 ans
Technical Lead puis Project Manager
PHPSymfonyAkeneo PIM v2REST APIXMLCSVJSONFTP/SFTPGitLab CIDockerKubernetes (K8s)MySQL

Portails partenaires

Plusieurs dizaines

Migrés, intégrés et maintenus

Formats d'export

3

XML, CSV, JSON

Durée du projet

~4 years

Évolution continue

Disponibilité

99.5%+

Sur 4 ans de fonctionnement continu

Présentation

Définition et périmètre du projet

Vue d'ensemble du système

Le système "Export Ligneurs" est le moteur de diffusion automatisée des annonces immobilières du Groupe Pichet. Il extrait les données programmes et lots depuis le PIM Akeneo, les transformé au format spécifique requis par chaque partenaire (XML, CSV ou JSON) et les exporté automatiquement vers les plateformes de diffusion immobilière.

Le système constitue le lien critique entre les données produit de l'entreprise et sa visibilité commerciale : chaque annonce immobilière publiée sur les grands portails français (SeLoger, LeBonCoin, BienIci, LogicImmo...) transite par ce pipeline. Toute interruption ou incohérence de données se traduit directement en perte de leads et d'opportunités commerciales manquées.

En tant que seul responsable technique de ce système, j'étais en charge de toutes les décisions d'architecture, du développement, du déploiement, du monitoring et de la gestion des incidents - avec une responsabilité complète sur un pipeline alimentant un volume estimé à ***K euros/mois en acquisition de leads.

Nature

Pipeline ETL automatisé (Extract-Transform-Load) pour la diffusion multi-canaux d'annonces immobilières

Domaine

Immobilier / PropTech - B2B (équipes internes, portails partenaires) et B2C (indirect, acquéreurs potentiels)

Périmètre fonctionnel
  • Extraction automatisée des données depuis l'API REST PIM Akeneo v2
  • Transformation au format spécifique de chaque partenaire (XML, CSV, JSON)
  • Livraison automatisée par FTP/SFTP vers plusieurs dizaines de plateformes partenaires
  • Adaptation multi-format des images (4/3, 16/9, panoramique, carré)
  • Mapping des typologies immobilières (appartement, maison, duplex, triplex, studio, T1-T5+)
  • Monitoring des exécutions avec alertes email et système de monitoring centralisé
  • Capacité d'activation/désactivation individuelle par partenaire
  • Algorithme de matching SKU pour les programmes réels vs. programmes créés manuellement dans le PIM
Architecture du système
Export Ligneurs - Vue d'ensemble de l'architecture
Choix technologiques et justifications

État de l'art en 2019

Stack alignée avec le standard d'intégration B2B de l'époque : ETL batch et FTP/SFTP étaient la norme avant la généralisation des webhooks et des architectures event-driven.

PHP / Symfony

Cohérent avec l'écosystème backend existant. Le composant Symfony Console offrait un framework solide pour l'exécution de commandes batch planifiées.

Akeneo PIM v2

Choix stratégique de l'entreprise pour la gestion du catalogue produit. Son API REST fournissait un accès structuré à toutes les données programmes et lots avec des endpoints versionnés.

Docker / Kubernetes

Chaque job d'export isolé dans son propre conteneur, évitant les conflits de ressources entre modules partenaires. K8s sur AWS EKS gérait le scheduling et la récupération automatique des jobs en échec.

GitLab CI

Automatisation du cycle build-test-deploy pour chaque module partenaire de façon indépendante, permettant des déploiements ciblés sans impacter les autres flux actifs.

Objectifs, Contexte, Enjeux et Risques

Vision stratégique et contraintes

Objectifs
  • 1Migrer tous les flux d'export de l'ancien PIM v1.4 vers le nouveau PIM v2 Akeneo
  • 2Executer la migration partenaire par partenaire avec validation métier à chaque étape
  • 3Verifier la cohérence des données entre le PIM source et les flux envoyes aux portails
  • 4Gérer les spécificités de chaque portail (formats d'images, typologies, champs obligatoires)
  • 5Automatiser la supervision des flux (alertes en cas d'erreur, rapports d'exécution)
Contexte

Le projet a débuté lors du transfert de connaissances d'Andoni L. en janvier 2019. Le système existant fonctionnait sur l'ancien PIM v1.4 et devait être entièrement migré vers le PIM v2 Akeneo tout en maintenant un service continu vers tous les portails partenaires.

La migration devait être réalisée portail par portail - chacun avec ses propres spécifications de format, champs obligatoires, contraintes d'images et mappings de typologies immobilières - rendant impossible une migration "big bang". Chaque partenaire nécessitait une validation individuelle par les équipes métier avant la mise en production.

Le système s'inscrivait dans un écosystème de données plus large : en amont, les données provenaient du logiciel comptable et des ERP internes alimentant le PIM, tandis qu'en aval les flux étaient connectés à une centaine de fournisseurs de leads générant un volume estimé à 1 lead toutes les 2 secondes sur l'ensemble des portails.

Enjeux

Les portails immobiliers partenaires (SeLoger, LeBonCoin, BienIci...) sont des canaux majeurs d'acquisition de leads sur le marché immobilier. Toute interruption ou erreur dans les flux se traduit directement en perte de leads et réduction du pipeline commercial. Avec plusieurs dizaines de partenaires à migrer individuellement, le projet exigeait une attention soutenue sur plusieurs années tout en maintenant zero temps d'arrêt sur les flux actifs.

Risques

Incohérence des données

Risque de publier des prix incorrects, des images erronées ou des biens manquants sur les portails - impactant directement la confiance des acheteurs et les résultats commerciaux.

Interruption de service

Toute défaillance d'un flux signifie que les biens disparaissent des portails, causant une perte immédiate de leads pour les équipes commerciales.

Divergence de formats

Chaque portail à des exigences uniques (ratios d'images, codes de typologies, champs obligatoires) - une approche générique était impossible.

Instabilité de l'API

Les problèmes de connexion à l'API PIM Akeneo pouvaient bloquer tous les exports simultanément, nécessitant une gestion solide des erreurs et une logique de retry.

Décisions d'architecture clés

Architecture modulaire par partenaire

Décision: Un module isolé par portail plutôt qu'un moteur générique

Justification: Isolation des pannes : un bug dans un module n'impacte pas les autres. Déploiement et test indépendants par flux.

Migration progressive plutôt que big-bang

Décision: Migration portail par portail avec validation métier à chaque étape

Justification: Rayon d'impact limité a un seul partenaire à la fois, avec rollback immédiat possible en cas de problème.

Traitement batch ETL plutôt que streaming temps réel

Décision: Exports batch planifiés par CRON plutôt que publication événementielle

Justification: Les partenaires consommaient via des dépôts FTP/SFTP, pas des webhooks. Le temps réel aurait ajouté de la complexité sans bénéfice.

Pre-génération multi-format des images

Décision: Pre-générer toutes les variantes de format de façon centralisée plutôt que par partenaire

Justification: Évite le retraitement redondant de la même image sur plusieurs portails et garantit la conformité en amont.

Pipeline de données ETL
Pipeline Extract-Transform-Load pour la génération des flux partenaires

Les étapes - Ce que j'ai fait

Progression chronologique du projet

Phase 1
Transfert de connaissances et migration initiale
Janvier 2019
  • Seul référent technique en 2 semaines après le transfert d'Andoni L.
  • Migration du premier lot : SeLoger Neuf, LogicImmo, TULN, Paru Vendu
  • Mise en place de la checklist d'acceptation réutilisée par la suite
Phase 2
Développement de fonctionnalités et nouvelles intégrations
Juin - Septembre 2019
  • Intégration BienIci avec adaptation d'images dédiée
  • Adaptation du flux ImmoNeuf : conversion 16/9 vers 4/3
  • Stabilisation des flux SeLoger et Knock
Phase 3
Stabilisation et corrections critiques
Janvier 2020
  • Mise en place de garde-fous de validation prix avant publication
  • Circuit breaker et retry exponentiel sur l'API PIM
  • Logging structuré pour réduire le temps de diagnostic
Phase 4
Nouveaux partenaires et évolution continue
Juin 2020 - 2023
  • Création des intégrations Investimeo et BienIci
  • Désactivation propre du partenaire Marketshot
  • Résolution des anomalies NEEDOCS, BienIci et Green Valley

Les acteurs et interactions

Écosystème collaboratif

Coordination et collaboration

En tant que seul responsable technique, je coordonnais directement avec les parties prenantes métier, les prestataires externes et les portails partenaires. Chaque migration impliquait la définition des critères d'acceptation, le pilotage des cycles de validation et les décisions de go/no-go pour la mise en production. Cela exigeait de traduire les contraintes techniques en termes métier et inversement.

Andoni L. (Predecesseur)·Gaetan B. (Referent métier)·Leslie A. (Referente métier)·Franck C. (Manager (N+1))·Sebastien B. (Équipe prestataire)

Les résultats

Impact pour moi et pour l'entreprise

Pour moi
  • Responsabilite technique complète d'un système critique impactant directement les revenus
  • Décisions d'architecture autonomes avec responsabilité totale sur la fiabilité et la qualité des données
  • Projet de 4 ans piloté avec équipes métier, prestataires externes et plusieurs dizaines de portails partenaires
  • Cycle de vie complet : architecture, développement, déploiement, monitoring et réponse aux incidents
  • Leadership transverse sur les processus de validation et l'onboarding partenaire
Pour l'entreprise
  • Plusieurs dizaines de portails partenaires migrés du PIM v1.4 vers v2 Akeneo sans interruption de service
  • 2 nouvelles intégrations partenaires construites de zero (BienIci, Investimeo)
  • Plusieurs milliers d'annonces traitees quotidiennement sur tous les portails partenaires
  • 99,5%+ de disponibilité sur 4 ans, temps moyen de résolution d'incident inférieur a 4 heures
  • Typologies immobilières standardisées sur tous les flux, réduisant les signalements d'incohérence
Répartition par type de partenaire
Répartition des formats d'export

Les lendemains du projet

Ce qui s'est passe après la livraison

Évolution du système

Suite immédiate : Après la vague de migration de 2019, passage en phase de maintenance continue avec ajout de nouveaux partenaires et résolution d'anomalies au fil de l'eau.

A moyen terme : Résilience prouvée sur 4 ans, en absorbant les changements de format des partenaires et les évolutions internes du modèle de données.

Perspective à long terme : Devenu une pièce d'infrastructure fondamentale alimentant le pipeline commercial. L'architecture modulaire a permis l'évolution vers plusieurs dizaines de portails sans refonte, et tout développeur peut désormais ajouter un partenaire en suivant les patterns établis.

Répartition de l'effort technique

Mon regard critique

Analyse rétrospective honnete

Ce qui a bien fonctionne
  • Migration portail par portail : risque minimal, validation métier à chaque étape, rollback immédiat
  • Architecture modulaire : ajout/modification/désactivation des flux sans effets de bord
  • Onboarding standardisé : intégration des nouveaux partenaires passée de semaines à jours
Ce qui aurait pu être mieux
  • Un tableau de bord centralisé aurait évité de surveiller les alertes email individuelles
  • Des tests d'intégration automatisés par format partenaire auraient detecté plus tot les regressions
Si c'était a refaire aujourd'hui
  • En 2026, j'opterais pour une approche event-driven (Kafka/RabbitMQ) plutôt que batch CRON, avec un monitoring observability-first (OpenTelemetry, Grafana Tempo)
  • Un registre de spécifications partenaires dès le premier jour pour diviser par 2 le temps d'onboarding
  • Des tests d'intégration automatisés contre le schema de chaque partenaire avant déploiement
  • Un tableau de bord de monitoring centralisé en temps réel plutôt que des alertes email
Leçons clés apprises
  • Dans les systèmes multi-partenaires, pas de "solution universelle" - chaque intégration à ses contraintes
  • Les projets de long terme exigent une mentalite de maintenance des le premier jour
  • Sur un système critique pour les revenus, l'observabilité compte plus que la prévention de chaque défaillance

Parcours associé

Expérience professionnelle liée à cette réalisation

Technical Lead · Flux et Produits : contenus et intégration d'entreprise

Compétences mobilisées

Compétences techniques et humaines appliquées

Compétences techniques

Architecture & Conception5/5

Architecture & Conception Système

Conception de l'architecture ETL complète : pipeline modulaire par partenaire, batch plutôt que temps réel, pré-génération centralisée des images multi-format

Tech5/5

Data Engineering & ETL

Pipeline ETL bout en bout du PIM Akeneo vers plusieurs dizaines de portails : extraction, transformation multi-format (XML/CSV/JSON), livraison FTP/SFTP, monitoring

Développement logiciel5/5

Développement Full-Stack

Seul responsable technique sur 4 ans : PHP/Symfony, intégration Akeneo PIM v2, traitement d'images, générateurs de format, outillage de monitoring

Architecture & Conception4/5

Conception d'APIs REST

Intégration de l'API REST PIM Akeneo v2 pour l'extraction et de plusieurs dizaines d'endpoints partenaires (API REST et dépôts FTP/SFTP)

DevOps & Cloud3/5

DevOps & CI/CD

Déploiement Docker/Kubernetes avec GitLab CI par module partenaire, permettant la migration zero-downtime du PIM v1.4 vers v2

Galerie d'images

Captures et visuels du projet

Vous avez un Pipeline ETL de syndication à concevoir ?

J'ai livré un Pipeline ETL de syndication multi-portails : extraction PIM, transformation multi-format (XML/CSV/JSON), livraison FTP/SFTP et monitoring sur 4 ans d'exploitation continue. Parlons de votre contexte.

Contactez-moi