Lorkid Infrastructure PaaS Souveraine & Alternative GAFAM

UNE ROADMAP ADAPTÉE À CHAQUE MIGRATION & DEVELOPPEMENT

Étude de cas — anonymisée

Gestimmo : sortir de la fragmentation SaaS sans perdre la logique métier

Comment un acteur immobilier a consolidé quatre outils SaaS dispersés en une plateforme unifiée, reconstruit le cycle de vie complet d’un mandat comme machine à états, et conservé la logique juridique là où le risque de la remplacer dépassait le bénéfice.

Le vrai coût d’un legacy, ce n’est pas l’outil — c’est tout ce qu’il ne fait pas

Un legacy qui fonctionne mal ne pousse pas une entreprise à changer d’outil. Il la pousse à empiler des outils autour. C’est exactement ce qui s’est passé chez cet acteur immobilier : l’outil de gestion de mandats d’origine était fonctionnellement correct sur son cœur de métier, mais incomplet sur le reste — stockage documentaire, visioconférence privée, notifications email transactionnelles.

État des lieux avant migration

Besoin fonctionnelSolution en placeStatut
Gestion des mandats et logique métierLegacy immobilierCœur historique, à conserver
Échange et dépôt de documentsSaaS de stockage tiersAbonnement séparé
Visioconférence privéeSaaS de visio tiersAbonnement séparé
Notifications email + documentsSaaS d’emailing tiersAbonnement séparé
Mise à jour des modèles de documentsSaaS juridique spécialiséAbonnement séparé, conservé

Le legacy, connecté en amont aux flux entrants Leboncoin et SeLoger pour le recoupement vers les mandats, générait une vraie base prospect — mais la couche applicative autour restait fragmentée, sans gestion indépendante du site web de l’agence.

Ce que la cartographie du workflow a révélé

  • Dispersion technique — intégrations hétérogènes vers les portails d’annonces via flux FTP/CSV aux formats disparates
  • Complexité métier dense — des dizaines de formulaires interdépendants, sans documentation structurelle
  • Angle mort réglementaire — aucune gestion RGPD native pour les comptes acheteurs, vendeurs, locataires, propriétaires
  • Contrôle d’accès partiel — filtrage des annonces entre agents, mais sans gestion RH réglementaire du contrôle des pièces

Le choix de la logique métier — Analyse du workflow à optimiser

La structure principale des fonctions métier a été conservée (mandats, baux, cycle de vie des dossiers), sans réinvention du fonctionnement existant. FlexAPI (modèle Flextranet) a été intégré pour gérer les annonces via exports JSON vers le site web, synchronisé et sécurisé. En parallèle, un export dédié alimente un portail de diffusion vers les principales plateformes d’annonces (Le Bon Coin, SeLoger.com, entre autres).

La logique juridique, elle, a été délibérément conservée et renforcée plutôt que remplacée : la gestion des documents légaux implique une responsabilité de conformité (NIS2 / RGPD) qui dépasse le périmètre d’une simple migration technique.
Le stockage et le dépôt de documents des agents, vendeurs et acheteurs ont été optimisés dans le respect du RGPD, avec intégration d’une visioconférence privée et de notifications email (MFT) et documents natives.

Le cycle de vie complet d’un mandat : une machine à états en production

Au-delà de la consolidation SaaS, le projet a couvert la reconstruction du cycle de vie du mandat sous forme de machine à états orchestrée.

Diffusion des annonces

  • Synchronisation vers le site indépendant de l’agence, avec validation N+2 avant diffusion — temps réel ou cron selon le flux
  • Export CSV/JSON + médias vers un portail API centralisé, redistribué vers Le Bon Coin et SeLoger

Profils métier et contrôle d’accès

  • Profils Admin, agent, sous-agent, vendeur, acheteur, notaire, étendus à la location et à la gestion locative
  • RBAC strict par mandat/bail, avec validation RH/juridique préalable des agents avant tout accès
  • Filtrage des mandats et baux par agent pour limiter la cannibalisation interne

Le mandat comme machine à états

Ajout du vendeur → diffusion de l’annonce → intégration de l’acheteur → validation de l’acheteur → phase compromis → signature dans le respect des délais légaux → validation de la signature → déclenchement automatique de la facturation des commissions (agent vers agence, agence vers notaire).

Signature électronique et conformité

Signature électronique de niveau 2, avec contrôle SMS — s’appuyant sur les pièces officielles déjà présentes dans les dossiers utilisateurs, sans ressaisie.

Pilotage financier

Tableau de bord financier pour la direction, ventilé sur 25 critères (TVA, taux de commission par agent ou par duo d’agents).

Interopérabilité ERP

Synchronisation via API pull/push entre le site et l’ERP existant.

Infrastructure : hébergement on-premise et continuité d’activité

La consolidation applicative (stockage, visio, notifications) s’est doublée d’un choix d’hébergement : l’ensemble tourne on-premise, pas sur une infrastructure cloud tierce. Ce choix a des conséquences directes sur trois briques du projet.

  • MFT (Managed File Transfer) on-premise — les échanges de documents liés aux mandats et baux (pièces officielles, modèles signés) transitent par un flux de transfert managé hébergé en interne, plutôt que par un service de partage de fichiers tiers soumis à une juridiction étrangère.
  • Visioconférence privée auto-hébergée — les visites et signatures à distance ne dépendent pas d’un service de visio grand public : le flux reste sur l’infrastructure de l’entreprise.
  • VPN nominatif — les accès distants (agents, notaires, gestion locative) passent par un VPN à clés nominatives et révocables, plutôt qu’un accès web ouvert.
Sur le PRA (Plan de Reprise d’Activité) : pour un métier où un mandat en cours porte des délais légaux de signature, une indisponibilité prolongée n’est pas une simple gêne opérationnelle — elle peut compromettre une transaction. Le PRA n’est pas traité comme une option de fin de projet, mais comme une exigence dimensionnée dès la conception de l’architecture.

Note de périmètre : le déploiement de la couche infrastructure (MFT, visio privée, PRA, VPN) constitue un chantier distinct de la construction applicative détaillée ci-dessous. Un PRA en particulier se dimensionne et se chiffre séparément, en fonction du niveau de criticité retenu (RPO/RTO). Le total de 120 jours-homme présenté plus bas couvre l’analyse et la construction applicative — pas cette couche infrastructure, qui fait l’objet d’un chiffrage propre.

PhaseDuréeContenu
Analyse / cartographie20 jours-hommeAudit de la machine à états legacy, intégrations, angles morts RGPD et RBAC
Construction100 jours-hommeCycle de vie du mandat, RBAC par profil, signature électronique, dashboard, synchro ERP
Total120 jours-hommeConsolidation SaaS + reconstruction complète de la machine à états métier

Le chiffrage indicatif par plateforme (grille de risque interactive) ne couvre que la phase d’analyse. Le volume réel d’un projet de cette ampleur se mesure en plusieurs mois, pas en quelques jours.

Ce que ce cas révèle sur la méthodologie « Application Jumelle »

L’application migrée est un legacy complexe et rigide, pas une migration Power Apps — mais le principe qui en ressort est transposable à toute plateforme source, précisément parce qu’il ne dépend pas de la technologie d’origine.

ApprocheOù se situe le risqueCe qui est perdu si mal exécuté
Migration Power Apps classique Logique dispersée entre Power Automate, Dataverse Triggers, Azure Logic Apps — lisible service par service, jamais reconstituable d’un seul tenant Angles morts entre services non recoupés
Développement complet from scratch Redécouverte à 100% des règles métier par entretiens, sans référence qui fonctionne déjà Règles tacites oubliées ou mal reformulées (ex. validation RH/juridique préalable d’un agent avant accès à un mandat)
Application Jumelle (Gestimmo) Le legacy est traité comme un cahier des charges vivant, validé par l’usage réel — l’effort de conception nouvelle se concentre sur l’infrastructure et la fragmentation SaaS, pas sur la redécouverte des règles Séparation nette : les règles métier sont reproduites à l’identique, l’infrastructure est modernisée
Le legacy, aussi imparfait soit-il comme outil, reste la spécification la plus fiable disponible : il a été testé en production, pas seulement décrit en entretien. L’Application Jumelle exploite cette fiabilité au lieu de la jeter avec l’outil.

Questions fréquentes

Le chiffrage jours-homme de la grille de risque correspond-il au coût total du projet ?

Non. La grille estime uniquement la phase d’analyse et de cartographie du workflow. Sur ce cas, l’analyse a représenté 20 jours-homme ; la construction complète en a représenté 100 de plus. Le périmètre réel dépend de l’ambition du projet au-delà de la simple migration de données.

Pourquoi ne pas avoir aussi remplacé la couche juridique ?

Parce que la valeur ajoutée d’un remplacement était marginale face au risque : une erreur dans un modèle de mandat ou de bail a une portée légale directe, contrairement à une erreur dans un module de stockage ou de notification.

Cette consolidation a-t-elle modifié la logique métier existante ?

Non — la méthodologie Application Jumelle vise à reproduire l’existant fonctionnel sans le réinventer. La consolidation a porté sur l’infrastructure applicative périphérique, pas sur les règles métier internes du legacy.

Ce principe s’applique-t-il à d’autres secteurs que l’immobilier ?

Oui. La fragmentation SaaS autour d’un legacy insuffisant est un phénomène générique — stockage, communication, notifications sont des besoins transverses à la plupart des ETI, quel que soit le secteur.

L’infrastructure on-premise (MFT, visio privée, PRA, VPN) est-elle incluse dans les 120 jours-homme ?

Non. Les 120 jours-homme couvrent l’analyse et la construction applicative (consolidation SaaS, cycle de vie du mandat, RBAC, signature électronique, dashboard). Le déploiement de la couche infrastructure fait l’objet d’un chantier et d’un chiffrage distincts — un PRA en particulier se dimensionne selon le niveau de criticité retenu (RPO/RTO) et ne peut pas être estimé au même forfait qu’un développement applicatif.