L'architecture de Lumina Showroom. chaque couche, chaque raison

La plupart des éditeurs de logiciels ne parlent pas de leur stack. C'est compréhensible. ça semble technique, ça semble interne, ça semble ne concerner que les développeurs. Mais pour Lumina Showroom, l'architecture n'est pas un détail d'implémentation. C'est la raison pour laquelle le logiciel se comporte comme il se comporte.

Pourquoi démarre-t-il en moins d'une seconde ? Pourquoi la recherche dans 500 fiches véhicules est-elle instantanée ? Pourquoi l'interface reste-t-elle opérationnelle quand la connexion internet coupe ? Ces comportements ne sont pas des optimisations ajoutées après coup. Ils découlent directement de décisions architecturales prises dès le départ.

Ce post les explique. couche par couche.

Lumina Showroom n'est pas une interface qui affiche ce que le serveur lui dit. C'est un thick client. un client épais qui embarque sa propre intelligence, son propre cache, et sa propre logique de performance. Le backend n'est pas le cerveau du système. Il en est la colonne vertébrale.

La distinction est importante. Dans une architecture thin client classique, toute la logique vit sur le serveur et le client ne fait qu'afficher. C'est simple à construire, difficile à rendre rapide. Dans Lumina Showroom, la logique est délibérément répartie : le backend détient ce qui doit être centralisé, le client détient ce qui doit être instantané.

Ce qui relie ces couches n'est pas une convention choisie par défaut. C'est une décision consciente : ce qui doit être rapide vit dans le C++, ce qui doit être beau et réactif vit dans QML, ce qui doit être fiable et coordonné vit dans Go, ce qui doit persister avec intégrité vit dans PostgreSQL.

L'interface de Lumina Showroom est entièrement écrite en QML. le langage déclaratif de Qt Quick. QML décrit ce que l'interface est et comment elle réagit, pas comment elle se dessine. Le rendu lui-même est délégué au scene graph Qt, qui passe directement par le GPU via OpenGL, Metal ou Vulkan.

Ce que ça donne concrètement : le configurateur véhicule, le scatter chart de performance portefeuille, les transitions entre modules, le changement de thème global. tout ça tourne à 60fps sans optimisation manuelle, parce que le pipeline de rendu est conçu pour ça dès le départ.

QML s'occupe de l'apparence. C++ s'occupe de la vitesse. La séparation est nette et intentionnelle. et la nuance ici est critique.

Le C++ côté client gère le cache local des entités récemment chargées ou modifiées, le moteur de filtrage qui trie des centaines de fiches véhicules ou d'entrées clients sans latence perceptible, et la recherche floue qui trouve "Jetour Dashing" même si l'utilisateur tape "jetur dashng". Ces opérations s'exécutent entièrement sur les données en cache, sans aller-retour réseau.

Mais. et c'est essentiel. le filtrage et la recherche côté client sont des optimisations de performance et d'UX, pas de l'enforcement de règles métier. La validation des données, l'authentification, la cohérence multi-utilisateurs : tout ça reste sur le backend Go. Le client ne contourne pas le serveur. Il l'allège.

Pour des applications desktop métier qui manipulent des dizaines de milliers d'entités, les utilisateurs attendent des temps de réponse quasi-instantanés pour la recherche et le filtrage. Un aller-retour serveur à chaque frappe tuerait cette réactivité native qu'on attend d'un vrai logiciel desktop. C++ donne la marge de performance pour des opérations client sophistiquées qui gardent l'interface fluide. sans compromettre l'intégrité des données.

La communication entre le client et le backend passe par Qt Network. la bibliothèque réseau native de Qt. Le protocole choisi dépend des besoins de chaque flux : HTTP via QNetworkRequest pour les opérations REST classiques, gRPC quand les exigences de performance ou de contrat d'interface le justifient.

Toutes les requêtes sont gérées de façon asynchrone, sans bloquer le thread UI. L'interface reste fluide pendant qu'une synchronisation se fait en arrière-plan. Qt Network gère aussi nativement les timeouts, les retries, et la détection de connectivité. ce qui est particulièrement utile dans un contexte où la connexion peut être intermittente.

Certaines données dans Lumina Showroom doivent se mettre à jour en temps réel : l'état d'un conteneur qui change de statut, un paiement qui arrive, un véhicule qui passe de "disponible" à "réservé" pendant qu'un commercial est en train de le présenter à un client.

Ces mises à jour passent par WebSockets. une connexion persistante entre le client et le serveur Go. Quand le backend émet un événement, l'interface se met à jour immédiatement, sans polling, sans délai artificiel, sans rechargement.

Le backend de Lumina Showroom est écrit en Go, avec Gin comme framework HTTP. Son rôle est précis : il détient tout ce qui concerne l'intégrité des données et la coordination entre utilisateurs. Les règles métier, la validation, l'authentification, la synchronisation temps réel, la résolution de conflits. tout ça vit sur le serveur Go, pas sur le client.

Cette séparation n'est pas négociable. Le client C++ peut filtrer et chercher sur ses données en cache aussi vite qu'il veut. mais quand une opération doit persister, elle passe par le backend, qui valide, qui coordonne, et qui écrit en base. Le client ne contourne jamais cette étape.

Go s'impose naturellement pour ce rôle. Il compile en un binaire unique sans dépendances externes, ce qui simplifie le déploiement. Son modèle de concurrence basé sur les goroutines gère efficacement des connexions simultanées avec une empreinte mémoire faible. Et Go est rapide. pas "assez rapide", vraiment rapide. ce qui compte quand le backend tourne potentiellement sur du matériel modeste en environnement local.

Le choix de PostgreSQL pour Lumina Showroom est le moins original de la liste. et c'est voulu. PostgreSQL est la base de données relationnelle la plus complète disponible en open source. Pour des données métier structurées. véhicules, conteneurs, clients, commandes, TVA sur marge. une base relationnelle avec des contraintes d'intégrité fortes est le bon outil.

Les données d'un importateur automobile ne sont pas des données flexibles. Un VIN est unique. Un conteneur a un statut à un instant donné. Ces relations strictes sont mieux servies par un schéma rigide que par un document store flexible.

Lumina Showroom fonctionne sans connexion internet. Ce n'est pas un mode dégradé, ce n'est pas une fonctionnalité bonus. c'est le comportement normal du logiciel, et la connexion réseau est ce qui permet la synchronisation, pas ce qui permet le fonctionnement.

Cette décision est directement liée au contexte algérien. La connectivité internet dans les zones industrielles et commerciales où opèrent les importateurs automobiles est hétérogène. Une coupure réseau au milieu d'une vente, d'une réception de conteneur ou d'une clôture mensuelle n'est pas un scénario hypothétique. C'est une réalité opérationnelle.

L'architecture offline-first de Lumina Showroom repose sur le cache C++ côté client. Toutes les données nécessaires aux opérations courantes sont synchronisées localement au démarrage et maintenues à jour via WebSockets quand la connexion est disponible. Quand elle ne l'est pas, le client continue à fonctionner sur le cache local. La synchronisation reprend automatiquement à la reconnexion.

Ce choix a un coût : la gestion des conflits de synchronisation est plus complexe qu'une architecture purement connectée. Mais dans un contexte où la fiabilité opérationnelle prime sur la simplicité technique, c'est le bon compromis.

Le débat classique en architecture desktop est binaire : soit toute la logique vit sur le serveur et le client est un terminal, soit le client est autonome et le serveur est un simple stockage. Lumina Showroom n'est ni l'un ni l'autre.

La logique est répartie selon sa nature. Ce qui touche à l'intégrité des données, à la cohérence multi-utilisateurs, à la validation fiscale. ça reste sur le backend Go, toujours. Ce qui touche à la vitesse de réponse, au filtrage, à la recherche, aux workflows UI. ça vit sur le client C++, sur les données en cache. Les deux couches font leur travail sans empiéter sur celui de l'autre.

La rapidité de l'interface vient du C++ et du GPU, pas de l'optimisation de JavaScript. La fiabilité en conditions réseau dégradées vient du cache local et de l'architecture offline-first. La scalabilité vient du modèle de concurrence Go. La cohérence des données vient des contraintes PostgreSQL et de la validation backend. pas de la discipline du développeur client.

Chaque couche fait ce qu'elle fait le mieux. C'est ça, une architecture délibérée.