Le choix par défaut, et pourquoi il mérite d'être questionné
Quand on démarre un logiciel de bureau en 2025, le chemin le plus balisé est connu : Electron, ou Tauri si on veut paraître raisonnable. La logique est cohérente: HTML, CSS, JavaScript sont des langages que tout le monde maîtrise, le recrutement est facile, et une seule base de code couvre Windows, macOS et Linux.
C'est un argument valide. Ce n'est pas l'argument qui m'a convaincu.
Pour Lumina Showroom, j'ai choisi Qt Quick. Pas par nostalgie, pas par habitude, mais par une décision technique précise, prise après avoir évalué ce que le produit devait faire et ce que chaque approche impliquait réellement.
Le vrai coût d'Electron ne se voit pas dans le code. Il se voit dans la RAM, dans le temps de démarrage, et dans les animations qui sautent à 40fps.
Ce qu'Electron embarque sans vous le dire
Electron, c'est Chromium + Node.js packagés avec votre application. Concrètement, chaque instance lance un navigateur complet en arrière-plan. Ce n'est pas une métaphore, c'est littéralement ce qui se passe. Slack, VSCode, Figma : tous construits dessus, tous réputés pour leur consommation mémoire.
Avant même que votre logique métier ne charge. Le bundle Chromium + Node.js occupe cet espace au repos.
Tauri améliore le tableau en utilisant le moteur de rendu natif du système plutôt qu'un Chromium embarqué. C'est un progrès réel. Mais vous restez dans le paradigme HTML/CSS. ce qui signifie que votre rendu passe par un moteur conçu pour des pages web, pas pour des interfaces applicatives denses avec des animations de données en temps réel.
Ce n'est pas une critique de ces outils. Electron et Tauri sont excellents pour ce pour quoi ils ont été conçus. La question n'est pas "sont-ils bons ?" mais "sont-ils adaptés à ce que je construis ?"
Qt Quick et le scene graph. ce que le GPU change
Qt Quick repose sur un scene graph rendu directement par le GPU via OpenGL, Metal ou Vulkan selon la plateforme. Ce n'est pas un détail d'implémentation. c'est une différence architecturale fondamentale.
Dans un navigateur, chaque animation passe par le compositor CSS, qui lui-même passe par le moteur de layout, qui lui-même est contraint par le modèle de rendu du DOM. Chaque couche ajoute de la latence. Qt Quick court-circuite tout ça : vos composants sont des nœuds dans un arbre de scène, transformés et composités directement sur la carte graphique.
Sans runtime navigateur qui consomme une partie de ce budget avant même que votre code ne s'exécute.
Ce que ça donne en pratique : le configurateur véhicule de Lumina Showroom. bascule avant/côté/arrière, sélection de couleur, image plein écran. s'exécute à 60fps stables sur une machine de bureau ordinaire. Pas parce que j'ai optimisé agressivement. Parce que le pipeline de rendu est conçu pour ça.
Qt Quick utilise QML, un langage déclaratif dont la syntaxe sera immédiatement lisible pour quiconque a fait du CSS ou du JSX. La courbe d'apprentissage est réelle mais moins abrupte qu'on ne le croit.
Le property binding. ce que React a tenté de faire, nativement
Le système de bindings de Qt Quick est l'une de ses forces les plus sous-estimées. Quand une propriété change, toutes les propriétés qui en dépendent se mettent à jour automatiquement, de façon synchrone, dans le même frame. Pas de virtual DOM, pas de reconciliation, pas de cycle de rendu à orchestrer manuellement.
Pour Lumina Showroom, ça se traduit ainsi : quand l'utilisateur bascule entre mode sombre et mode clair, l'intégralité de l'interface. couleurs, ombres, opacités, états de survol. se met à jour en une seule passe. Pas de flash, pas de transition partielle, pas d'état incohérent le temps d'un render.
C'est le genre de détail qui ne se voit pas dans une démo. Il se ressent après six mois d'utilisation quotidienne, quand l'interface répond exactement comme vous l'attendez, à chaque fois.
Ce que ça coûte. et ce que ça rapporte
Qt Quick a un coût réel : l'écosystème est plus petit que celui du web, la documentation demande plus d'effort à naviguer, et certaines bibliothèques courantes n'ont pas d'équivalent direct. Ce serait malhonnête de ne pas le dire.
Mais le retour est mesurable. Lumina Showroom démarre en moins d'une seconde. Son empreinte mémoire au repos est inférieure à un onglet de navigateur vide. Les animations de données. le scatter chart de performance de portefeuille, les compteurs statistiques, les transitions entre modules. sont fluides sans effort particulier d'optimisation.
Sur une machine de bureau standard.
Pour un logiciel de gestion utilisé huit heures par jour par une équipe commerciale, ces chiffres ne sont pas anecdotiques. Un outil qui répond instantanément change la façon dont on l'utilise. La latence, même imperceptible, accumule une friction qui finit par modifier les comportements.
Si vous construisez un logiciel interne ou un SaaS desktop avec des données denses, des visualisations temps réel ou des interactions fréquentes. Qt Quick mérite une évaluation sérieuse avant de prendre Electron par défaut.
Une décision de produit, pas seulement technique
Choisir Qt Quick pour Lumina Showroom n'était pas une décision purement technique. C'était une décision de produit. Un logiciel de gestion pour des importateurs automobiles algériens est utilisé dans des environnements variés . connexions lentes, machines hétérogènes, équipes avec peu de tolérance pour les bugs de rendu.
Un logiciel natif qui démarre vite, consomme peu et répond de façon prévisible est un avantage concurrentiel tangible dans ce contexte. Ce n'est pas visible dans une liste de fonctionnalités. Ça se ressent à l'usage.
La question n'était pas "quelle technologie est à la mode ?". Elle était "quelle technologie sert le mieux les personnes qui utilisent ce logiciel tous les jours ?" La réponse, pour Lumina Showroom, était Qt Quick.
¹ Les chiffres de performance cités sont mesurés sur la version actuelle de Lumina Showroom, sur une configuration matérielle représentative (Intel Core i5, 8Go RAM, Windows 10). Les résultats varient selon l'environnement.