Le même châssis, de la citadine au poids lourd
Cet article approfondit notre approche de plateforme — voir aussi : Migrer ou développer vos évolutions avec agilité et modularité
Dans l’industrie automobile, un même châssis peut porter une petite citadine légère et, à l’autre extrême, un poids lourd chargé de contraintes. Ce n’est pas un compromis technique : c’est une stratégie industrielle. Le coût de conception du châssis est financé une fois, puis amorti sur chaque véhicule qui en hérite — chacun calibré différemment, mais tous issus du même socle d’ingénierie.
Un socle qui se déploie, pas un projet qui se refabrique
Trois réalisations distinctes, un seul châssis :
| Réalisation | Calibrage du véhicule | Reconstruit depuis zéro | Hérité du châssis |
|---|---|---|---|
| Gestimmo (application immobilière) |
Poids lourd — charge métier complète | La logique métier spécifique au secteur | Le moteur de calcul, d’habilitation et de cohérence de workflow |
| Minispace (espace sécurisé) |
Citadine — un seul usage, léger et rapide | L’interface et le paramétrage propre à l’usage | L’authentification, le RBAC, l’infrastructure de déploiement |
| Toomyhub (calendrier / visio chiffrée) |
Utilitaire — calibré pour un besoin précis | Le module de visioconférence et de calendrier lui-même | La même infrastructure sécurisée et le même socle d’hébergement |
Chaque nouveau véhicule n’a pas nécessité de reconcevoir le châssis. C’est la différence entre un carrossier qui reconstruit un véhicule entier à chaque commande, et un constructeur dont le châssis se décline.
Une carrosserie sur mesure, sans jamais toucher au châssis
Dans l’automobile, un même châssis peut recevoir des carrosseries et des finitions très différentes selon la gamme ou le client, sans que l’ingénierie sous-jacente soit remise en cause à chaque fois. Le moteur Flextranet suit le même principe pour l’identité visuelle : chaque déploiement peut avoir son propre design, ses propres codes graphiques, adaptés à l’espace de travail ou au groupe d’utilisateurs concerné — sans dupliquer le moteur, et sans que la personnalisation d’un client vienne complexifier celle d’un autre.
Ce que l’extension pro-code change dans la trajectoire du châssis
Quand un besoin dépasse la configuration standard du moteur, l’extension se fait sur une branche de développement dédiée au client — mais avec une intégration continue à la base commune de la plateforme. Concrètement : une évolution développée pour un client (comme une connexion à un service de paiement externe, déjà réalisée) peut enrichir le châssis disponible pour les véhicules suivants, plutôt que de rester une pièce sur mesure qui ne profite qu’à un seul modèle.
Chaque nouveau projet ne part donc pas du même châssis que le précédent : il part d’un châssis légèrement plus abouti que celui du projet d’avant.
Ce que ça signifie pour la trajectoire de la plateforme
| Carrosserie sur mesure à chaque commande | Modèle Flextranet (châssis partagé) | |
|---|---|---|
| Effort du 1er véhicule | Élevé | Élevé (conception du châssis) |
| Effort du 2e véhicule sur un besoin proche | Élevé, largement reconstruit | Réduit, hérite du châssis existant |
| Effort du 3e véhicule | Élevé, largement reconstruit | Réduit, hérite d’un châssis enrichi par les deux premiers |
| Ce que le client final finance | Une carrosserie isolée, propre à lui seul | L’usage d’un châssis déjà éprouvé, enrichi à chaque déploiement |
| Ce qui reste après la mission | Un véhicule isolé | Un châssis plus abouti, réutilisable au projet suivant |
Cette trajectoire est directement illustrée par l’enchaînement Gestimmo → Minispace → Toomyhub : trois véhicules de gabarits différents, un seul châssis qui s’est amélioré à chaque étape plutôt que trois carrosseries construites isolément.
Pourquoi la souveraineté renforce cette dynamique plutôt que de la freiner
Un châssis propriétaire fermé (langage exclusif, hébergement imposé par l’éditeur) limite la capacité d’un prestataire à réutiliser ce qu’il construit pour un client au bénéfice d’un autre, sans l’accord et la dépendance de l’éditeur tiers. Un châssis en Python/Django, déployable on-premise, en cloud souverain ou en hébergement certifié selon le secteur, reste sous le contrôle de Lorkid à chaque étape — ce qui est la condition structurelle pour que la logique de plateforme partagée décrite plus haut reste possible dans la durée, véhicule après véhicule.
Concrètement, l’hébergement de chaque déploiement se choisit selon l’exigence réglementaire réelle du client, pas selon une offre unique imposée :
On-premise, par projet
Lorsque la donnée doit rester physiquement dans l’infrastructure du client — le châssis se déploie chez lui, projet par projet, pas seulement chez Lorkid ni de façon mutualisée entre plusieurs clients.
Cloud souverain (OVHcloud)
Pour répondre aux exigences des secteurs soumis à NIS2 ou DORA. Une qualification SecNumCloud est en cours d’obtention chez le partenaire à ce jour — à vérifier précisément pour tout besoin nécessitant explicitement cette qualification.
Hébergement certifié HDS
Pour les données de santé, via un fournisseur certifié — la même logique de châssis adapté à la charge réglementaire, appliquée à l’hébergement.
Questions fréquentes
Gestimmo, Minispace et Toomyhub sont-ils trois projets séparés ou un seul écosystème ?
Un seul écosystème technique. Chacun a sa propre finalité métier, mais tous trois s’appuient sur le même socle Flextranet, déployé industriellement dans le PaaS Lorkid plutôt que reconstruit à chaque fois. Voir l’étude de cas consolidation SaaS immobilier.
Le pro-code développé pour un client profite-t-il uniquement à ce client ?
Pas nécessairement — une évolution développée sur une branche dédiée peut être réintégrée à la base commune de la plateforme lorsqu’elle est pertinente pour d’autres déploiements, enrichissant le socle disponible pour les projets suivants. Voir migrer ou développer vos évolutions avec agilité et modularité.
Cette dynamique dépend-elle d’un éditeur tiers ou reste-t-elle sous contrôle de Lorkid ?
Elle reste sous contrôle de Lorkid à chaque étape — le socle technique (Python/Django) et les options d’hébergement (on-premise, cloud souverain, HDS) ne dépendent pas d’un écosystème propriétaire fermé imposant ses propres conditions. Voir Flextranet et conformité NIS2 et l’exit plan low-code lock-in.
L’hébergement peut-il rester en France ou chez le client, pour répondre à NIS2 ou DORA ?
Oui — le mode d’hébergement (on-premise, cloud OVHcloud, ou hébergement HDS pour le médical) se choisit selon l’exigence réglementaire du secteur et du client. La qualification SecNumCloud du cloud OVHcloud utilisé est en cours d’obtention à ce jour — à vérifier précisément pour tout besoin nécessitant explicitement cette qualification.
