Pas de théorie dans cet article. Juste les faits : un vrai projet, un vrai problème, une vraie solution construite en 7 jours. Avec les choix qu’on a faits, ceux qu’on a écartés, et les résultats mesurés après 3 mois d’utilisation.
Le client et son problème
Le contexte
ImmoPlus (nom modifié) est une agence immobilière indépendante de 8 personnes basée en Île-de-France. 4 agents commerciaux, 1 assistante administrative, 1 photographe, 1 responsable marketing, 1 directeur.
Leur activité : Transaction résidentielle. 60 mandats actifs en moyenne, 400 acquéreurs en base, 25 à 30 ventes par an. Chiffre d’affaires : environ 450 000 € de commissions annuelles.
Leurs outils avant notre intervention :
- Hektor (CRM immobilier du marché) pour les fiches biens et la multidiffusion sur les portails
- Excel pour le suivi des acquéreurs (un fichier par agent, non partagé)
- Gmail pour les relances (manuelles, non trackées)
- WhatsApp pour la coordination interne
Le problème précis
Le directeur nous a contactés avec une frustration simple :
« On perd des ventes parce qu’on ne fait pas le rapprochement entre nos acquéreurs et nos biens. Un T3 rentre en mandat lundi, et le mercredi je découvre qu’on avait un acquéreur parfait dans notre base depuis 2 mois — mais personne n’y a pensé. »
En creusant, on a identifié 3 problèmes liés :
- Pas de base acquéreurs centralisée. Chaque agent avait « ses » acquéreurs dans un Excel perso. Les autres agents ne les voyaient pas.
- Rapprochement 100 % mental. Quand un nouveau mandat entrait, les agents fouillaient dans leur mémoire (et parfois leur Excel). Résultat : aléatoire, dépendant de qui est au bureau ce jour-là.
- Zéro relance automatique des acquéreurs. Un acquéreur qui n’avait pas trouvé son bien en 3 semaines tombait dans l’oubli. Pas de séquence de suivi, pas de rappel.
Le coût du problème
On a fait le calcul ensemble :
| Indicateur | Donnée |
|---|---|
| Biens vendus à un acquéreur déjà en base | ~30 % des ventes |
| Délai moyen de vente (mandat → compromis) | 94 jours |
| Acquéreurs « perdus » (aucun contact depuis 30+ jours) | ~45 % de la base |
| Commission moyenne par vente | 15 000 € |
| Ventes « ratées » estimées par an (acquéreur existant non identifié) | 4-6 ventes |
Manque à gagner estimé : 60 000 à 90 000 € par an en ventes qui auraient pu se faire plus vite — ou qui ne se sont pas faites du tout.
Face à ça, un investissement de 4 000 € était une évidence.
Le Sprint : jour par jour
Jour 1 — Cadrage
Participants : Le directeur + notre développeur. 1h30 de call.
Ce qu’on a décidé :
Fonctionnalités MVP (Must Have) :
- Base acquéreurs unifiée — import des 4 fichiers Excel + formulaire de saisie
- Matching automatique — à chaque nouveau mandat, comparaison avec tous les acquéreurs actifs
- Score de compatibilité — classement des matchs par pertinence (0-100)
- Notification agent — alerte quand un match > 70 % est détecté
- Email acquéreur — envoi automatique de la fiche bien personnalisée
Ce qu’on a écarté (Won’t Have pour le MVP) :
- Intégration bidirectionnelle avec Hektor (trop complexe pour 7 jours)
- Séquence de relance automatique (itération 2)
- Application mobile (responsive web suffit)
- Reporting et analytics (post-MVP)
Livrable du jour : Document de cadrage d’une page, validé par le directeur.
Jour 2 — Architecture et import de données
Le défi principal : 4 fichiers Excel, 4 formats différents, 400 lignes au total, ~20 % de doublons.
Ce qu’on a fait :
- Script d’import avec nettoyage automatique (normalisation des noms, dédoublonnage par email + téléphone, standardisation des critères de recherche)
- Modèle de données : Acquéreur (nom, contact, critères de recherche, agent assigné, statut, date dernier contact)
- Architecture : Next.js + Supabase (PostgreSQL) + Vercel
- Setup du repo Git, CI/CD, environnement de dev
Résultat : 347 acquéreurs uniques importés (53 doublons supprimés), base propre et exploitable.
Jour 3 — Interface et algorithme de matching
L’interface :
- Dashboard agent : liste de ses acquéreurs, filtres par statut et critères
- Vue directeur : tous les acquéreurs, tous les agents, métriques globales
- Fiche acquéreur : critères détaillés, historique des biens envoyés, notes
L’algorithme de matching :
C’est le cœur du produit. On a défini 6 critères avec le directeur, chacun pondéré selon son importance :
| Critère | Poids | Exemple |
|---|---|---|
| Localisation (commune/quartier) | 30 % | Match exact = 100 %, même ville = 70 %, ville adjacente = 40 % |
| Budget | 25 % | Prix du bien dans la fourchette acquéreur = 100 %, jusqu’à +10 % au-dessus = 60 % |
| Type de bien | 20 % | Match exact = 100 % (T3 cherché = T3 trouvé) |
| Surface | 10 % | Dans la fourchette = 100 %, ±10 m² = 70 % |
| Nombre de pièces | 10 % | Match exact = 100 %, ±1 = 70 % |
| Critères bonus (balcon, parking, étage) | 5 % | Chaque critère bonus matché = points supplémentaires |
Score final : Moyenne pondérée sur 100. Un score > 70 déclenche une notification.
Jour 4 — Développement core (matching + notifications)
Ce qu’on a livré en fin de journée :
- L’algorithme de matching fonctionnel (testé sur les 347 acquéreurs × 5 biens test)
- Le trigger automatique : quand un bien est ajouté dans le système → calcul du matching en < 3 secondes
- Les notifications par email à l’agent : « Nouveau match 87 % — [Acquéreur] pour [Bien] » avec lien vers la fiche
Premiers tests : On a importé 5 biens réels du portefeuille. Le système a identifié 12 matchs > 70 %, dont 3 que le directeur ne connaissait pas (« Ah oui, celui-là ! On l’avait oublié »).
Jour 5 — Email acquéreur + polish interface
L’email automatique :
- Template personnalisé avec le nom de l’acquéreur, les caractéristiques du bien, les photos principales, et un bouton « Je suis intéressé »
- Déclenché par l’agent (pas automatique — le directeur voulait garder le contrôle)
- Tracking : ouverture, clic sur le bouton, réponse
Polish de l’interface :
- Tri des matchs par score (les meilleurs en haut)
- Filtres rapides : « Mes acquéreurs », « Matchs non traités », « Score > 80 »
- Badge de notification : pastille rouge quand un nouveau match est disponible
Jour 6 — Formulaire de saisie + intégration manuelle Hektor
Formulaire de saisie acquéreur :
- Champs structurés pour les critères de recherche (pas de texte libre → données propres)
- Validation automatique (budget min < budget max, surface cohérente)
- Assignation automatique à l’agent connecté
Intégration Hektor (manuelle mais efficace) :
- Pas d’API bidirectionnelle (hors scope MVP)
- Solution : formulaire d’ajout de bien dans notre outil, avec les champs essentiels copiés depuis Hektor
- Le directeur saisit le bien en 2 minutes → le matching se lance automatiquement
Jour 7 — Tests, démo, livraison
Matin — Tests :
- Parcours complet : ajout d’un bien → matching → notification → envoi email → tracking
- Test avec les 4 agents en simultané (multi-utilisateur)
- Test mobile (responsive — fonctionne sur les téléphones des agents en visite)
- Correction de 3 bugs mineurs (affichage du score, tri des résultats, formatage email)
Après-midi — Démo et livraison :
- Démonstration à toute l’équipe (45 minutes)
- Chaque agent a importé ses acquéreurs et testé le matching en live
- Mise en production sur Vercel (URL personnalisée : crm.immoplus.fr)
- Remise des accès admin + documentation technique
Les résultats après 3 mois
On a mesuré les indicateurs clés 90 jours après la mise en production.
Les métriques
| Indicateur | Avant | Après 3 mois | Évolution |
|---|---|---|---|
| Base acquéreurs centralisée | 4 fichiers Excel séparés | 1 base partagée (412 acquéreurs) | ✅ Centralisé |
| Temps de rapprochement par bien | 15-30 min (quand c’est fait) | 3 secondes (automatique) | -99 % |
| Matchs identifiés par semaine | 2-3 (manuels, aléatoires) | 8-12 (automatiques, exhaustifs) | ×4 |
| Visites déclenchées via matching | Non mesuré | 34 en 3 mois | Nouveau |
| Délai moyen de vente | 94 jours | 71 jours | -24 % |
| Acquéreurs « perdus » (aucun contact 30+ jours) | ~45 % | ~18 % | -60 % |
| Ventes sur la période | 7 | 9 | +29 % |
Le calcul du ROI
| Poste | Montant |
|---|---|
| Investissement (Sprint 7 jours) | 4 000 € |
| Coûts récurrents (3 mois : hébergement + Supabase) | 90 € |
| Coût total | 4 090 € |
| Ventes supplémentaires (2 ventes × 15 000 € commission) | 30 000 € |
| ROI sur 3 mois | ×7,3 |
L’outil s’est rentabilisé dès la première vente accélérée par le matching automatique — soit environ 5 semaines après le lancement.
Ce qu’on ferait différemment
Aucun projet n’est parfait. Voici ce qu’on a appris :
1. On aurait dû intégrer les relances automatiques dès le MVP.
Le directeur nous l’a demandé 3 semaines après le lancement. Ça aurait pu être la 5e fonctionnalité du sprint initial — on l’avait écarté par prudence, mais le besoin était immédiat.
2. L’import Excel a pris plus de temps que prévu.
4 formats différents, des données sales (adresses avec fautes, budgets en texte libre « environ 300k », critères mélangés). On a passé presque tout le Jour 2 là-dessus. Leçon : toujours prévoir du buffer pour le nettoyage de données.
3. La saisie manuelle des biens est un point de friction.
Sans intégration API avec Hektor, le directeur doit saisir les biens dans deux outils. C’est le premier point à résoudre en itération 2.
La suite : les itérations post-MVP
Après le Sprint initial, ImmoPlus a commandé 2 itérations supplémentaires :
Itération 2 (Semaine 5) — Relances automatiques :
- Séquence email automatique pour les acquéreurs sans contact depuis 14 jours
- 3 emails progressifs (nouveau bien similaire → point sur la recherche → demande de mise à jour des critères)
- Budget : 2 000 € (3 jours de développement)
Itération 3 (Semaine 9) — Connexion Hektor :
- Import automatique des nouveaux biens depuis Hektor (via leur API)
- Plus besoin de double saisie
- Budget : 3 000 € (5 jours de développement, API complexe)
Total investi sur 3 mois : 9 000 € — pour un outil qui génère 30 000+ € de commissions supplémentaires par trimestre.
Ce que cette étude de cas montre
1. Un MVP à 4 000 € peut avoir un impact massif.
Pas besoin de 50 000 € et 6 mois de développement. Un outil ciblé, qui résout UN problème bien identifié, suffit pour changer la donne.
2. Le sur mesure bat le standard quand le besoin est spécifique.
Le matching acquéreurs/biens d’Hektor existe — mais il est basique (critères fixes, pas de pondération, pas de scoring). La fonctionnalité custom a fait la différence.
3. Itérer est plus intelligent que tout planifier.
Le MVP a prouvé la valeur. Les itérations ont ajouté de la profondeur. Si on avait tout spécifié dès le départ, on aurait passé 2 mois en specs et le directeur attendrait encore.
4. Les données sales sont le vrai ennemi.
Le plus gros défi n’était pas le code — c’était de transformer 4 fichiers Excel chaotiques en une base propre. Si vous préparez un projet similaire, nettoyez vos données AVANT.
—
Vous avez un problème similaire dans votre entreprise ? Réservez un call de cadrage gratuit →
On fait comme avec ImmoPlus : on identifie LE problème qui vous coûte le plus cher, et on construit la solution en 7 jours. Premiers résultats mesurables en quelques semaines.
