Extranet B2B
Deux métiers, trois plateformes, un seul code — et des formulaires que le métier fait évoluer sans redéployer.
Un acteur du financement locatif faisait transiter son activité par le mail et le téléphone. Cet extranet la déplace vers un canal en libre-service : les partenaires montent leurs dossiers de financement, les locataires suivent leurs contrats, et tout se passe au même endroit — sur le web, sur iOS et sur Android.
- Catégorie
- Plateforme métier multiplateforme
- Plateformes
- Web · iOS · Android
Le point de départ
Certains détails de ce projet sont confidentiels et ne sont pas présentés ici.
Le métier du financement locatif fait travailler ensemble deux populations qui ne se ressemblent pas. D’un côté les partenaires — revendeurs et apporteurs d’affaires — qui montent des dossiers et attendent une réponse rapide. De l’autre les locataires, clients finaux, qui veulent simplement savoir où en sont leurs contrats. Les deux passaient par les mêmes canaux : un mail, un appel, une pièce jointe qui se perd.
Servir ces deux publics correctement voulait dire deux produits. En construire deux, puis les décliner chacun sur le web, iOS et Android, aurait demandé plusieurs équipes et multiplié les endroits où corriger le même bug. Il fallait aussi tenir compte d’un métier qui bouge : les formulaires, les barèmes et les règles de validation évoluent, et chaque évolution ne pouvait pas signifier une nouvelle version à publier sur trois plateformes.
Ce qui a été construit
Une seule base de code Flutter sert les trois plateformes et les deux espaces métier, qui partagent leur ossature et divergent là où le métier l’exige : droits, écrans, règles. Les partenaires simulent un financement, montent un dossier, envoient un contrat en signature électronique. Les locataires consultent leurs contrats, leurs échéances et leurs factures. Et surtout, les formulaires sont décrits par le serveur : le métier les fait évoluer sans qu’une seule ligne de l’application ne change.
Ce que le produit fait
Simulation et montage de dossier
Montant, durée, périodicité, barème, maintenance : le partenaire simule un financement puis transforme la simulation en dossier.
Signature électronique
Envoi du contrat au bon signataire et suivi du cycle de signature, jusqu’à la vérification du mobile du signataire.
Suivi des contrats
Liste recherchable, détail financier, échéances, matériels, factures et suivi des impayés.
Deux espaces, un compte
Un même utilisateur bascule entre l’espace partenaire et l’espace locataire, avec des droits fins par fonctionnalité.
Gestion documentaire
Pièces jointes, bibliothèque de documents et relances automatiques sur les pièces manquantes.
Tableaux de bord
Activité, annonces et indicateurs : dossiers, impayés, performance par vendeur.
Les décisions qui comptent
Des formulaires que le métier change sans développeur
Les champs ne sont pas écrits dans l’application : ils sont décrits par un schéma fourni par le serveur, et l’application les construit à la volée. Concrètement, ajouter un champ ou modifier une règle de saisie ne demande ni développement, ni recette, ni publication sur trois plateformes — le métier fait évoluer son formulaire et le changement est immédiat, partout. C’est la décision qui a le plus d’effet sur le coût de possession du produit.
Deux produits dans une seule application
Partenaires et locataires partagent l’ossature mais divergent sur les droits, les écrans et les règles. Le piège classique est d’empiler les conditions jusqu’à obtenir un code que personne n’ose plus toucher. La réponse a été la généricité : un moteur de formulaires commun, paramétré par type, et des composants partagés — champs, listes paginées, structures responsive. Un bug se corrige à un seul endroit, pour les deux métiers et les trois plateformes.
Une interface découplée de l’API
Les couches sont strictement séparées : l’interface ignore d’où viennent les données. La conséquence est concrète — une fonctionnalité a pu être développée entièrement sur des données simulées, puis branchée à l’API réelle en changeant un seul fichier. Les modèles de données de l’API sont convertis explicitement en objets métier, si bien qu’un changement de contrat côté serveur ne se propage pas dans tout le produit.
Du vrai responsive, pas un redimensionnement
Un tableau triable de plusieurs centaines de contrats n’a aucun sens sur un téléphone. Chaque écran existe donc en deux formes : colonnes triables et tableaux sur le web, listes et défilement continu sur mobile. La recherche est paginée côté serveur, parce qu’à cette volumétrie, tout charger n’est pas une option.
La saisie financière, là où les bugs se cachent
Des montants, des taux, des durées : une virgule au lieu d’un point, une décimale de trop, et le dossier est faux. Les champs financiers sont donc contraints par des formatteurs dédiés, et les règles de barème, de maintenance et de validation sont testées — parce que sur un dossier de financement, une erreur de saisie n’est pas un détail cosmétique.
Comment c’est assemblé
Flutter
Une base de code pour le web, iOS et Android — deux espaces métier
Cubit
L’état de l’écran, isolé de l’interface et testable
Use cases & repositories
Les règles métier, indépendantes de la provenance des données
API REST
Le système de gestion existant, derrière une passerelle d’entreprise
Les technologies utilisées
Frontend
- Flutter
- Dart
- BLoC
- Freezed
- go_router
Backend
- API REST
- JWT
Infrastructure
- Docker
- GitLab CI
- Fastlane
Services
- Firebase Cloud Messaging
Ce qui a été livré
Extranet livré sur le web, iOS et Android depuis une base de code unique, couvrant la simulation, le montage de dossier, la signature électronique, le suivi des contrats et des impayés et la gestion documentaire, pour deux espaces métier distincts. La chaîne de livraison est automatisée sur quatre environnements, du web conteneurisé jusqu’à la publication sur les stores. Certains détails de ce projet restent confidentiels.
- Web
- iOS
- Android
Besoin d’un produit similaire ?
Parlons de ce que vous voulez construire. Je vous réponds personnellement, généralement sous 24 heures.