Aller au contenu

Réalisations / Proptech · SaaS

Refonte marketplace flex office

Reconstruction d’une marketplace de bureaux flexibles paralysée par la dette NoCode — DDD, TDD, CQRS.

Refonte DDD TDD Marketplace

Contexte

De quoi il s’agit

Ce cas, c’est l’histoire classique du NoCode qui sauve le lancement… puis devient la cage. Une marketplace flex office (bureaux, coworking, salles) avec plus de 500 espaces dans une quatre-vingtaine de villes : le produit avait trouvé son marché. Le socle technique, lui, n’avait pas suivi. Chez Innovation Digitale, on l’aborde comme un build de modernisation : pas un patch cosmétique, une reconstruction maîtrisée.

01 · Problématique

Le problème

Une marketplace flex office (500+ espaces, 80 villes) construite en NoCode (Xano / WeWeb) a tenu le lancement, puis s’est figée : pannes récurrentes, dette technique, dépendance à un éditeur, Excel de secours. L’outil critique n’était plus maîtrisé.

Au départ, Xano côté backend et WeWeb côté front avaient permis d’aller vite. Puis les pannes sont devenues récurrentes, la dette s’est accumulée, et l’équipe s’est retrouvée dépendante d’un éditeur pour faire évoluer l’outil critique. Le Excel de secours est revenu — signe que le système n’était plus digne de confiance.

Le vrai sujet n’était pas « il faut plus de features ». C’était : qui possède le code, qui peut le tester, qui peut le déployer sans magie ? Sans architecture (domaine, ports, CI), chaque évolution devenait un risque. La marketplace ne pouvait plus grandir sereinement.

Pour un dirigeant, le symptôme se lit en cash et en réputation : portail client instable, suivi d’activité fragmenté, impossibilité de recruter un développeur « classique » pour reprendre la stack. C’est exactement le moment où iD intervient : cadrer le risque, proposer une refonte, sécuriser la migration des données.

02 · Solution

Ce que nous avons construit

Refonte totale — pas un patch : reconstruction sur fondations DDD, TDD et CQRS, agents IA pour accélérer sans sacrifier la qualité, infrastructure Docker, tests Vitest/PHPUnit, conformité RGPD dès la conception.

On a tranché : reconstruction from scratch sur des fondations DDD, TDD et CQRS — pas une migration progressive qui aurait prolongé la double vie NoCode / legacy. Les agents IA ont accéléré le scaffolding et les tâches répétitives, sans remplacer la revue humaine ni les critères métier.

Stack cible : backend structuré, front React, PostgreSQL, Docker, tests Vitest/PHPUnit, pipeline CI. RGPD dès la conception (consentement, droits, registre) — pas un add-on collé après coup. Objectif : une plateforme que l’équipe cliente peut comprendre et faire évoluer.

La migration des 500+ espaces a été traitée comme un projet à part entière : mapping, contrôles, bascule. Sans ça, la plus belle architecture reste un PowerPoint.

03 · Résultat

Ce que ça change

Plateforme reconstruite en quelques semaines ; 500+ espaces migrés sans perte ; fin des pannes récurrentes ; autonomie technique retrouuvée — l’équipe peut faire évoluer l’outil sans éditeur NoCode.

Résultat : plateforme reconstruite en quelques semaines, données migrées, pannes récurrentes derrière, autonomie technique retrouvée. Fin du mode « on attend l’éditeur ». L’outil critique redevient un actif.

Au-delà des métriques, le gain stratégique est la transmissibilité : on peut recruter, auditer, documenter. C’est la définition opérationnelle de la souveraineté numérique sur un produit SaaS.

Tech

Angle technique

Le NoCode accélère le MVP. Sans architecture (ports, tests, domaine), il devient une cage. Ici, le passage à un socle testable et documenté a transformé une plateforme fragile en actif logiciel durable.

Leçon technique : le NoCode est excellent pour valider. Il devient dangereux quand il porte le cœur de métier sans tests, sans ports, sans CI. DDD clarifie le langage ; TDD protège les comportements ; CQRS sépare les lectures gourmandes des écritures critiques.

Si vous êtes dans la même situation — marketplace ou app critique sur une base NoCode figée — le Brief 45 min permet de voir s’il faut un audit build avant d’empiler encore une feature.

Aujourd’hui, ce type de refonte NoCode → socle testable est l’un des motifs les plus fréquents chez iD : le produit a trouvé son marché, l’architecture non. On documente le parcours problématique → solution → résultat pour que les décideurs comprennent l’enjeu sans jargon inutile. Symfony, React, PostgreSQL, Docker, TDD, DDD, CQRS, CI : chaque brique du socle a une fiche dédiée si vous voulez le détail.

Prochaine étape possible : Brief 45 min pour évaluer si votre outil critique est dans la même zone rouge — pannes, Excel parallèle, dépendance éditeur — et si un audit build 5 jours est le bon sas avant le MVP de reconstruction.

Next · Loading

Un outil qui coince ?

Un Brief de 45 minutes, gratuit. On clarifie le périmètre — puis un audit build si ça tient la route.

STATUS: READY SIGNAL: OPEN WHOAMI → BRIEF
Réserver un Brief 45 min