Contact
Travaillons ensemble
Système de syndication automatisé vers 25+ portails immobiliers

Système de syndication automatisé vers 25+ portails immobiliers

Pipeline ETL complet extrayant les annonces immobilières du PIM Akeneo, les transformant au format requis par chaque partenaire (XML, CSV, JSON) et les livrant vers SeLoger, LeBonCoin, BienIci, LogicImmo et d'autres portails - 4 ans d'exploitation continue.

Janvier 2019 - 2023
~4 ans
Technical Lead puis Project Manager - Distribution Export
PHPSymfonyAkeneo PIM v2REST APIXMLCSVJSONFTP/SFTPGitLab CIDockerKubernetesMySQL

Portails partenaires

27+

Migres, integres et maintenus

Formats d'export

3

XML, CSV, JSON

Durée du projet

~4 years

Évolution continue

Volume quotidien

~2,000/day

Annonces traitees sur tous les portails

Disponibilité

99.5%+

Sur 4 ans de fonctionnement continu

Branches GitLab

12+

Features et hotfixes documentes

Présentation

Définition et périmètre du projet

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

En tant que seul responsable technique de ce système, j'etais 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 responsabilite complète sur un pipeline alimentant un volume estime a 400K 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, acquereurs 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 25+ plateformes partenaires
  • Gestion des images avec adaptation multi-format (4/3, 16/9, panoramique, carre, ratios spécifiques par portail)
  • Mapping des typologies immobilières (appartement, maison, duplex, triplex, studio, T1-T5+)
  • Monitoring des exécutions avec alertes email et intégration SOFT Monitor
  • Capacité d'activation/désactivation individuelle par partenaire
  • Algorithme de matching SKU pour les programmes réels vs. programmes crees manuellement dans le PIM
System Architecture
Export Ligneurs - System Architecture Overview
Choix technologiques et justifications

PHP / Symfony

Cohérent avec l'écosystème backend du Groupe Pichet. Le composant Symfony Console offrait un framework solide pour l'exécution de commandes batch planifiees.

Akeneo PIM v2

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

Docker / Kubernetes

Chaque job d'export isolé dans son propre conteneur, evitant les conflits de ressources entre modules partenaires. K8s sur AWS EKS gerait 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 cibles 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
  • 4Gerer 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 debute lors du transfert de connaissances d'Andoni L. (Kariba) en janvier 2019. Le système existant fonctionnait sur l'ancien PIM v1.4 et devait être entièrement migre 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 des ERP Qualiac, G2P et Oraclé alimentant le PIM, tandis qu'en aval les flux étaient connectés a 75+ fournisseurs de leads générant un volume estime a 1 lead toutes les 2 secondes sur l'ensemble des portails.

Enjeux

Les portails immobiliers partenaires (SeLoger, LeBonCoin, BienIci...) sont les principaux canaux d'acquisition de prospects du Groupe Pichet, alimentant un pipeline estime a 400K euros/mois en leads. Toute interruption ou erreur dans les flux se traduit directement en perte de leads et réduction du pipeline commercial. Avec 25+ partenaires a migrer individuellement, le projet exigeait une attention soutenue sur plusieurs années tout en maintenant zero temps d'arret sur les flux actifs.

Risques

Incohérence des données

Risque de publier des prix incorrects, des images erronees 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 partenaire plutôt qu'un moteur générique configurable

Justification: Chaque portail avait des contraintes uniques (ratios d'images, mapping de champs, codes de typologies). Un moteur générique serait devenu un cauchemar monolithique de configuration. L'approche modulaire a fourni une isolation des pannes : un bug dans le module BienIci ne pouvait pas impacter les exports SeLoger. Elle a aussi permis le déploiement et le test indépendant de chaque flux.

Migration progressive plutôt que big-bang

Décision: Migration portail par portail avec validation métier à chaque étape, étalée sur 4 ans

Justification: Avec 25+ partenaires alimentant directement l'acquisition commerciale, une migration simultanee presentait un risque inacceptable. Chaque portail avait des spécifications uniques a verifier. L'approche incrémentale limitait le rayon d'impact à un seul partenaire à la fois et permettait un rollback immédiat 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 temps réel pilotée par événements

Justification: Les portails partenaires consommaient les données via des depots de fichiers FTP/SFTP, pas des webhooks ni des APIs. Ils traitaient les fichiers selon leur propre planning (généralement une ou deux fois par jour). Le traitement temps réel aurait ajoute de la complexité sans bénéfice vu le pattern de consommation en aval.

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

Décision: Pre-générer toutes les variantes de format d'image (4/3, 16/9, carre, panoramique) de façon centralisee plutôt qu'a la demande par partenaire

Justification: Les portails avaient des contraintes strictes sur les images et aucune capacité de redimensionnement de leur cote. La pre-génération à la source permettait de verifier la conformité en amont et de mettre en cache les résultats, evitant le retraitement redondant de la même image sur plusieurs portails.

ETL Data Pipeline
Extract-Transform-Load pipeline for partner feed generation

Les étapes - Ce que j'ai fait

Progression chronologique du projet

Phase 1
Transfert de connaissances et migration initiale
Janvier 2019

Avant d'écrire la moindre ligne de code, j'ai réalisé un audit complet du système existant : cartographie des spécifications de tous les 25+ partenaires, évaluation de la dette technique et définition d'une matrice de priorisation basée sur l'impact commercial. Les portails a fort trafic (SeLoger, LogicImmo) ont été migres en premier pour sécuriser le gros du volume de leads.

  • Prise en main du transfert complet de connaissances d'Andoni L. (Kariba) - devenu le seul referent technique en 2 semaines
  • Obtention de l'accès Master sur le repository GitLab Export Ligneurs
  • Migration du premier lot de portails : SeLoger Neuf, LogicImmo, TULN, Paru Vendu, Mister Bell, Explorimmoneuf
  • Définition des critères de validation avec Leslie A. et Gaetan B. - création de la checklist d'acceptation reutilisée pour toutes les migrations suivantes
Phase 2
Développement de fonctionnalités et nouvelles intégrations
Juin - Septembre 2019

Priorisation de l'intégration BienIci basée sur sa croissance rapide de parts de marché dans l'immobilier français. Choix de construire une adaptation d'image spécifique par partenaire (conversion 16/9 vers 4/3) plutôt qu'un redimensionneur générique, car les contraintes de chaque portail étaient trop différentes pour être abstraites en une seule solution.

  • Développement de feature/add-hermes-lots - ajout des lots Hermes dans les exports avec corrections du pipeline CI
  • Intégration du portail BienIci (feature/add-bienici-in-master) avec adaptation d'images personnalisee
  • Adaptation du flux ImmoNeuf pour la conversion de format d'image 16/9 vers 4/3
  • Debug des flux SeLoger et Knock (hotfix/debug-seloger, hotfix/debug-knock)
Phase 3
Stabilisation et corrections critiques
Janvier 2020

Les erreurs de prix exigeaient une résolution le jour même vu leur impact direct sur le chiffre d'affaires. J'ai implémenté des patterns defensifs : circuit breakers sur les appels API PIM, logique de retry idempotente avec backoff exponentiel, et logging structure pour réduire le temps moyen de diagnostic de plusieurs heures a quelques minutes.

  • Correction des erreurs de prix dans les exports (hotfix/debug-prices) - resolues en quelques heures pour éviter l'impact commercial
  • Résolution des problèmes de connexion à l'API PIM (hotfix/debug-pim-api-connexion)
  • Implémentation du pattern circuit breaker et logique de retry avec backoff exponentiel pour les appels API
  • Ajout de logging structure pour le suivi d'exécution des exports, réduisant le temps de diagnostic des incidents
Phase 4
Nouveaux partenaires et évolution continue
Juin 2020 - 2023

Transition du projet du mode migration au mode plateforme. Mise en place d'un processus standardisé d'intégration de nouveaux partenaires (analyse des spécifications, scaffolding de module, checklist de validation), réduisant le temps d'intégration de plusieurs semaines a quelques jours pour les builds Investimeo et BienIci.

  • Création de l'intégration Investimeo de zero (juin-octobre 2020) via le processus d'onboarding standardise
  • Création du flux BienIci (octobre 2020) - intégration d'un nouveau portail
  • Mise à jour du flux de retargeting Criteo (octobre 2020)
  • Désactivation du partenaire Marketshot (octobre 2020) - retrait propre du module sans affecter les autres flux
  • Évolution du flux NEEDOCS pour le lignage PI (JIRA LIGNEURS-74, février 2022)
  • Résolution de l'anomalie d'export automatique BienIci (KESD-58153, juillet 2022)
  • Correction des lots Green Valley manquants dans les flux (KESD-72984, 2023)
Chronologie cumulative de migration des partenaires
Partner Migration Process
Step-by-step process for each partner migration

Les acteurs et interactions

Écosystème collaboratif

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 (Kariba)

Prise en charge du transfert complet des connaissances. Atteinte de l'autonomie opérationnelle complète du système d'export en 2 semaines, devenant le seul referent technique sur tout le périmètre.

Gaetan B.

Referent métier

Co-définition et application des critères d'acceptation pour chaque migration : précision des données, conformité des images, mapping des typologies. Création d'une checklist de validation réutilisable.

Leslie A.

Referente métier

Pilotage du processus d'acceptation fonctionnelle, coordination entre les corrections techniques et les priorités métier pour maintenir la velocite de migration.

Franck C.

Manager (N+1)

Reporting de l'avancement des migrations, évaluation des risques et besoins en ressources. Recommandations techniques pour les décisions de coordination avec les prestataires.

Sebastien B.

Équipe Kariba

Coordination du planning de déploiement en production. Mise en place d'un protocole de déploiement : validation preprod, validation métier, déploiement prod, fenêtre de monitoring 24h.

Les résultats

Impact pour moi et pour l'entreprise

Pour moi
  • Responsabilite technique complète d'un système critique impactant directement la génération de revenus - canal principal d'acquisition de leads de l'entreprise
  • Décisions d'architecture autonomes sur un périmètre a haute valeur avec responsabilite totale sur la fiabilité du système et la précision des données
  • Capacité prouvee a piloter un projet technique de 4 ans avec de multiples parties prenantes : équipes métier, prestataires externes et 25+ portails partenaires
  • Gestion du cycle de vie complet du système : conception d'architecture, développement, déploiement, monitoring, réponse aux incidents et évolution continue
  • Leadership transverse : définition des processus de validation, coordination des équipes métier et techniques, mise en place des procédures opérationnelles d'onboarding partenaire
Pour l'entreprise
  • 25+ portails partenaires migres du PIM v1.4 vers le PIM v2 Akeneo sans interruption de service - protection d'un pipeline d'acquisition de leads estime a 400K euros/mois
  • 2 nouvelles intégrations partenaires construites de zero (BienIci, Investimeo), élargissant le réseau de diffusion de ~8%
  • ~2 000 annonces traitees quotidiennement sur 27+ portails, alimentant le canal principal de génération de leads commerciaux
  • 99,5%+ de disponibilité du système sur 4 ans de fonctionnement continu, avec un temps moyen de résolution d'incident inférieur a 4 heures
  • Gestion des typologies immobilières standardisée sur tous les flux partenaires, réduisant les signalements d'incohérence des données par les équipes métier
Répartition par type de partenaire
Répartition des formats d'export
Statut de migration des partenaires
Typologies immobilières gerees

Les lendemains du projet

Ce qui s'est passe après la livraison

Suite immédiate : Après la vague initiale de migration (2019), le système est entre dans une phase de maintenance et d'évolution continue. De nouveaux partenaires ont été ajoutes au gre des besoins business, les flux existants ont été mis à jour pour correspondre aux spécifications evoluant des portails, et les anomalies ont été resolues au fur et à mesure de leur détection.

A moyen terme : Le système a prouve sa résilience sur 4 ans d'exploitation continue, gerant les changements de format des partenaires (mises à jour des spécifications BienIci, ajout de champs SeLoger) et les évolutions internes du modèle de données (nouveaux types de biens, changements de structure de prix).

Perspective à long terme : Le système d'export est devenu une pièce d'infrastructure fondamentale chez le Groupe Pichet, alimentant directement le pipeline commercial. Les choix architecturaux - modules individuels par partenaire, gestion solide des erreurs, monitoring automatisé - ont permis au système d'évoluer du lot initial de portails a 27+ sans nécessité de refonte fondamentale. L'architecture modulaire que j'ai choisie a permis à tout développeur d'ajouter une nouvelle intégration partenaire en suivant les patterns etablis, sans nécessité de connaître en profondeur l'ensemble du système.

Répartition de l'effort technique

Mon regard critique

Analyse rétrospective honnete

Ce qui a bien fonctionne
  • La stratégie de migration portail par portail était le bon choix - elle a minimise les risques et permis la validation métier à chaque étape, avec capacité de rollback immédiat
  • La gestion solide des erreurs et les alertes email ont permis de detecter les problèmes avant qu'ils n'impactent les résultats commerciaux - temps moyen de détection inférieur a 30 minutes
  • L'architecture modulaire (un module par partenaire) a facilité l'ajout, la modification ou la désactivation de flux individuels sans effets de bord sur les autres partenaires
  • La mise en place d'un processus standardisé d'onboarding des nouveaux partenaires a réduit le temps d'intégration de plusieurs semaines a quelques jours
Ce qui aurait pu être mieux
  • Un tableau de bord centralise pour le monitoring des flux aurait réduit le temps passe a verifier les alertes email individuelles
  • Des tests d'intégration automatisés pour chaque format partenaire auraient permis de detecter plus tot les regressions de format
  • Une meilleure documentation des exigences spécifiques de chaque partenaire aurait accéléré l'intégration de nouveaux membres dans l'équipe
Si c'était a refaire aujourd'hui
  • J'implementerais un registre de spécifications partenaires des le premier jour : une base structuree des exigences de format, mappings de champs et contraintes d'images de chaque portail. Cela aurait réduit le temps d'onboarding des nouveaux partenaires d'au moins 50%.
  • J'ajouterais des tests d'intégration automatisés générant des exports samples et les validant contre le schema de chaque partenaire avant déploiement. Les cycles de vérification manuelle ajoutaient 1 a 2 jours par migration.
  • Je construirais un tableau de bord de monitoring centralise avec le statut des flux en temps réel au lieu de dependre des alertes email. Le coût en changement de contexte de la vérification des emails individuels était significatif sur 4 ans.
  • Je pousserais pour une couche de notification event-driven au-dessus du batch ETL, pour alerter proactivement l'équipe métier quand un flux termine ou echoue, plutôt que d'attendre des vérifications manuelles periodiques.
Leçons clés apprises
  • Dans les systèmes multi-partenaires, il n'y a pas de "solution universelle" - chaque intégration à des contraintes uniques qui doivent être respectees
  • Les projets de long terme exigent une mentalite de maintenance des le premier jour, pas seulement une approche "construire et livrer"
  • La validation métier à chaque étape de migration est non negociable quand le système impacté directement la génération de revenus
  • En tant que seul responsable technique, l'investissement le plus précieux est dans l'observabilité du système - la capacité a diagnostiquer rapidement les problèmes compte plus que la prévention de chaque défaillance possible

Parcours associe

Experience professionnelle liee a cette realisation

Competences mobilisees

Competences techniques et humaines appliquees

Galerie d'images

Captures et visuels du projet