Un mandat signé à 18h.
Visible sur LeBonCoin à 18h01.

Le mandat du soir

Un agent immobilier signe un nouveau mandat à 17h30. Il rentre la fiche dans son logiciel, coche LeBonCoin, enregistre. Sur son écran, tout est en ordre. Pourtant, le lendemain matin à 9h, l'annonce n'est toujours pas visible sur le portail. Pas de bug. Pas d'erreur. Juste le cycle normal d'un système de diffusion qui tourne la nuit.

C'est la réalité de la plupart des solutions immobilières qui passent par un agrégateur intermédiaire. Ubiflow, Hektor et leurs équivalents collectent les annonces de votre logiciel puis les transmettent aux portails selon leur propre calendrier, en général une fois par nuit. Le lendemain matin, tout est là. Mais le lendemain matin, c'est parfois trop tard : un acquéreur actif a pu passer entre-temps, votre annonce n'était pas là, celle du concurrent si.

C'est le point de départ du projet que nous avons réalisé pour un réseau d'agences immobilières multi-agences. La demande initiale était simple à formuler : "On veut que nos annonces soient sur LeBonCoin dès qu'on les enregistre." La réalisation, elle, l'était un peu moins.

Ce que "temps réel" implique vraiment

Intégrer directement l'API LeBonCoin depuis un logiciel métier, c'est d'abord sortir de la délégation confortable que représente un agrégateur. L'agrégateur gère pour vous les particularités de chaque portail : formats de données, règles de validation, gestion des erreurs, reconnexions. En passant direct, on reprend tout ça à notre charge.

L'API LeBonCoin Immobilier a ses propres exigences. Chaque type de bien a ses champs obligatoires spécifiques : une surface est requise pour un terrain, pas forcément pour un appartement. Les catégories et types de transaction suivent une matrice précise : on ne peut pas publier une colocation en "vente", ni un viager en "location". Le DPE, les honoraires, le statut de copropriété obéissent à des règles de présence conditionnelles selon la nature du bien. Tout ça, il faut le mapper proprement depuis les données internes du logiciel.

Mais la difficulté principale n'était pas là. Elle était dans la gestion des quotas.

Le vrai problème : la logique de quota entre agents

LeBonCoin n'autorise pas la publication illimitée d'annonces. Chaque agence dispose d'un quota, c'est-à-dire un nombre maximum d'annonces simultanément actives sur le portail. Jusque-là, c'est connu. La complexité arrive quand ce quota est partagé entre plusieurs agents au sein d'une même agence, ou entre plusieurs agences d'un même réseau.

Le premier réflexe serait de diviser le quota total par le nombre d'agents et de bloquer la publication dès qu'un agent dépasse sa part. Simple, mais inutilisable en pratique : un agent absent ne "libère" pas ses slots pour ses collègues, et un nouvel arrivant bloque immédiatement tout le monde le temps de recalculer les quotas. On a opté pour une approche différente.

Le système fonctionne sur un principe d'équité dynamique. Chaque agent a un quota cible calculé en temps réel selon le nombre d'agents actifs. Ce quota n'est pas un plafond strict : un agent peut temporairement dépasser sa part si ses collègues sont en dessous de la leur. En revanche, quand le quota global de l'agence est atteint et qu'un agent publie une nouvelle annonce, le système identifie automatiquement l'agent qui dépasse le plus son quota cible et retire sa plus ancienne annonce pour libérer un slot. Résultat : le catalogue se renouvelle naturellement, les annonces récentes prennent la place des plus anciennes, et chaque agent peut atteindre sa part sans que personne ne soit bloqué.

Ce mécanisme se recalcule en permanence. Si un agent quitte l'équipe, les parts se rééquilibrent progressivement : les excédents se résorbent au fil des prochaines publications sans intervention manuelle. Si un agent n'utilise pas tous ses slots, ses collègues peuvent temporairement en bénéficier. La direction n'a pas à gérer des attributions de quota, le système s'en charge.

La robustesse avant la rapidité

Un système temps réel qui tombe en panne au mauvais moment est plus frustrant qu'un système lent mais fiable. On a donc accordé autant d'attention à la gestion des erreurs qu'à la rapidité de publication.

L'API LeBonCoin peut être momentanément indisponible : surcharge, maintenance, problème réseau. Plutôt que de simplement logger l'erreur et passer à autre chose, le système mémorise les publications en échec et les rejoue automatiquement selon un calendrier de retry exponentiel : immédiatement, puis 2 minutes après, 8 minutes, 30 minutes, 2 heures. Dans la grande majorité des cas, l'annonce finit par passer sans intervention humaine, avec un délai maximal de 2 heures.

En complément, un programme automatique tourne toutes les heures pour détecter d'éventuelles annonces restées "en attente", celles qui auraient pu passer entre les mailles du filet de retry. C'est une sécurité supplémentaire, pas un mode de fonctionnement normal. Le système temps réel gère 99% des cas, le programme horaire rattrape le reste.

Ce qu'on a appris

Travailler directement avec une API de portail immobilier, c'est rentrer dans les détails d'un modèle de données que les agrégateurs ont l'habitude d'absorber à votre place. La documentation est là, mais elle ne couvre pas tous les cas limites, notamment les règles de présence conditionnelle des champs selon la combinaison type/catégorie/partenaire. On s'est appuyé sur les retours d'erreur de l'API pendant les phases de test pour identifier tout ce que la documentation ne mentionnait pas explicitement.

Sur la logique quota, la leçon principale est qu'une règle simple en apparence ("chaque agent a sa part") devient rapidement complexe dès qu'on introduit du mouvement : agents qui arrivent, agents qui partent, slots temporairement inutilisés, publications simultanées. La robustesse du système vient d'une réflexion en amont sur tous ces cas de figure, pas d'une implémentation de la règle simple et d'un traitement des cas limites au fur et à mesure.

Enfin, la communication vers les utilisateurs finaux, les agents, a été un travail à part entière. Un système aussi automatique génère des questions : pourquoi mon annonce a-t-elle disparu ? Est-ce que mon quota a changé ? Que se passe-t-il si LeBonCoin est en panne ? La documentation utilisateur et la formation à la prise en main font partie du projet au même titre que le code.

Pour quel type de réseau ce type d'intégration fait sens

Si votre réseau publie une dizaine d'annonces par mois sur LeBonCoin, un agrégateur suffit largement. Le délai J+1 n'a pas d'impact mesurable à ce volume, et la délégation technique a une vraie valeur.

L'intégration directe prend tout son sens quand le volume d'annonces en rotation est significatif, quand les agents travaillent en décalé (saisie en fin de journée, visites tôt le matin), et quand la gestion du quota entre plusieurs agents génère des frictions au quotidien. C'est également pertinent quand vous avez besoin de contrôle précis sur ce qui est publié, comment, et à quel moment, sans dépendre du cycle de traitement d'un intermédiaire.

Ce n'est pas une solution universellement meilleure. C'est une solution qui correspond à des contraintes spécifiques, et qui demande une intégration soignée pour être réellement fiable.