Stack technologique et justification des choix

Les choix technologiques de QuoteNode sont guides par la securite, la correction et la maintenabilite a long terme, pas par la reduction maximale de la consommation memoire ni par la recherche du framework le plus a la mode.

Cette page explique ce que nous utilisons, pourquoi nous l’avons choisi et ce que cela implique pour le deploiement.

Pourquoi Java 25 et Spring Boot 4

La securite comme moteur principal

QuoteNode traite des donnees commerciales sensibles : fiches clients, strategies tarifaires, negociations d’offres et relations d’affaires. Le stack technologique doit etre eprouve dans des environnements ou un defaut de securite a de vraies consequences.

Java et Spring Boot sont le choix naturel dans la banque, l’assurance, la sante et l’administration, c’est-a-dire des secteurs ou la securite n’est pas optionnelle. Ce n’est pas un hasard :

• Modele de securite mature — Spring Security fournit un cadre eprouve et audite pour l’authentification, l’autorisation, la gestion de session, la protection CSRF et les en-tetes de securite. Nous n’avons pas besoin de reconstruire ces briques nous-memes.
• Type safety — le systeme de types fort de Java elimine a la compilation des categories entieres d’erreurs qui deviendraient des erreurs runtime dans des langages dynamiques. Quand on calcule des totaux d’offre avec plusieurs devises, des taux de TVA et des remises, ce n’est pas du luxe.
• Memory safety — la JVM assure une gestion automatique de la memoire via le garbage collector, ce qui elimine les buffer overflows, use-after-free et autres vulnerabilites de corruption memoire presentes en C/C++ et parfois dans certains contextes Go.
• Ecosysteme mature — des bibliotheques comme Flyway (migrations), Thymeleaf (templates PDF), Hibernate (ORM) et Testcontainers (tests d’integration) sont maintenues par des organisations avec un long historique.

Pourquoi pas Go, Rust ou Node.js ?

Chacune de ces technologies serait raisonnable pour un autre produit. Pour QuoteNode plus precisement :

• Go — excellent pour les services reseau et les outils CLI, mais son systeme de types est plus faible et la modelisation d’un moteur de tarification complexe avec des calculs multi-devises deterministes y est plus fragile. L’ecosysteme enterprise (ORM, migrations, rendu PDF, frameworks de securite) est aussi moins mature.
• Rust — maximise performance et securite memoire, mais au prix d’une vitesse de developpement plus faible et d’un ecosysteme moins mature pour des applications metier. QuoteNode est une plateforme business tres CRUD, pas un projet de systems programming. Les temps de compilation et la courbe d’apprentissage ralentiraient le projet sans gain proportionnel.
• Node.js — tres rapide pour prototyper, mais sa concurrence mono-thread, une discipline de typage plus faible meme avec TypeScript, et un ecosysteme fragmente en font un moins bon choix pour une plateforme de securite critique avec des calculs financiers. La profondeur de l’arbre npm augmente aussi le risque supply-chain.

Ce que cela implique pour la consommation de ressources

Les applications Java consomment plus de memoire que des services equivalents en Go ou Rust. Un backend QuoteNode consomme typiquement 512 MB a 1.5 GB de RAM, selon la charge et la configuration JVM. C’est un compromis assume :

• le compilateur JIT de la JVM optimise les chemins chauds apres warmup, ce qui donne un debit proche des langages natifs pour des charges soutenues,
• les pauses de garbage collection sont negligeables dans une application single-tenant avec des patterns de charge B2B classiques,
• le surcout memoire achete un systeme de types riche, des primitives de securite matures, des bibliotheques battle-tested et une livraison de fonctionnalites plus rapide.

Pour une application self-hosted, single-tenant, qui sert une seule organisation, la difference entre 256 MB et 1 GB de RAM est operationnellement peu importante. Le VPS le moins cher capable d’executer Docker Compose peut faire tourner QuoteNode confortablement.

PostgreSQL 16

PostgreSQL est la seule base supportee. C’est volontaire :

• Conformite ACID — chaque calcul d’offre, chaque transition de statut et chaque ecriture d’audit log se fait dans une transaction correcte. L’implementation MVCC de PostgreSQL apporte de fortes garanties d’isolation.
• Support JSON — les snapshots d’offre sont stockes dans des colonnes JSONB, permettant d’interroger efficacement l’historique sans ajouter un document store separe.
• Extensions — pgcrypto pour le hash cote serveur, pg_trgm pour la recherche plein texte sur noms clients et produits.
• Fiabilite — PostgreSQL a des decennies d’historique en production dans les systemes financiers et commerciaux.
• Outils de sauvegarde — pg_dump au format custom permet des sauvegardes online coherentes sans arreter l’application.

Chiffrement de base

Les champs sensibles sont chiffres au niveau applicatif avec AES-256-GCM.

Toujours chiffres (necessitent DB_ENCRYPTION_KEY) :

• secrets TOTP (codes de secours 2FA)
• credentials SMTP

Optionnellement chiffres (quand ENCRYPT_PII=true) :

• PII clients — noms, email, telephone, NIP / tax ID
• PII des contacts — noms, email, telephone
• PII fournisseurs — tax ID, email, telephone
• PII des contacts fournisseurs — noms, email, telephone
• PII utilisateurs — email, prenom, nom, numero de telephone
• PII des intents de commande — nom client, email, telephone

Lorsque le chiffrement PII est active, les recherches exact-match utilisent des blind indexes HMAC-SHA256 stockes a cote du ciphertext au lieu de lectures directes de colonnes. La recherche plein texte retombe sur des champs non-PII (noms de societe, display names en cache). Les recherches de type LIKE sur colonnes chiffrees sont impossibles par construction ; c’est un compromis volontaire en faveur de la protection des donnees.

La cle de chiffrement est derivee de la variable DB_ENCRYPTION_KEY via SHA-256. La cle ne touche jamais la base et n’existe qu’en memoire applicative. Un validateur de configuration production empeche le demarrage avec la cle de dev par defaut. Un startup validator separe detecte aussi les incoherences entre le flag de chiffrement et l’etat reel de la base, par exemple des donnees chiffrees avec ENCRYPT_PII=false ou une mauvaise cle, et refuse de demarrer afin d’eviter toute corruption silencieuse.

Des outils CLI sont fournis pour les operations bulk : --pii-encrypt (chiffrer l’existant en clair), --pii-decrypt (revenir au clair) et --pii-rekey=<old-key> (rechiffrer avec une nouvelle cle).

Le chiffrement at-rest complet de la base est delegue a l’infrastructure d’hebergement (LUKS, volumes EBS chiffres, etc.), ce qui reste plus performant qu’un chiffrement colonne a colonne pour la masse de donnees.

Frontend Vue 3

Le frontend est une application single-page construite avec Vue 3, Vite, PrimeVue 4 et Tailwind CSS 4 :

• Vue 3 — interface reactive et orientee composants avec un fort support TypeScript et un ecosysteme mature
• PrimeVue 4 — bibliotheque de composants enterprise avec tables, formulaires et dialogues riches et accessibles. Cela evite de reinventer des patterns UI complexes.
• Tailwind CSS 4 — styling utility-first avec design tokens pour maintenir un langage visuel coherent sans inflation CSS
• Vite — tooling de build rapide avec hot module replacement pour la productivite de developpement
• vue-i18n — internationalisation complete avec anglais, polonais, allemand, francais, espagnol, italien et portugais

Le frontend communique exclusivement avec le backend via une API REST typee. Il est servi comme assets statiques par Caddy et n’a aucun acces direct a la base.

Gotenberg (moteur PDF)

La generation PDF utilise Gotenberg, un service HTML-vers-PDF base sur Chromium :

• rendu correct du CSS moderne (flexbox, grid, custom properties),
• execution dans un conteneur Docker separe qui isole le rendu,
• prise en charge de la pagination, des marges personnalisees et des templates d’en-tete/pied de page,
• aucune dependance directe a Chromium dans le backend, la communication se fait via HTTP API.

Le conteneur Gotenberg consomme environ 200-400 MB de RAM. Il n’est actif que pendant la generation PDF et peut etre limite via la configuration Docker.

Caddy (reverse proxy)

Caddy 2 sert de reverse proxy avec HTTPS automatique :

• provisionnement automatique des certificats TLS via Let’s Encrypt,
• support HTTP/2 et HTTP/3,
• configuration simple et declarative,
• empreinte memoire minimale (environ 20 MB de RAM).

Dans les deploiements Coolify, le proxy Caddy de Coolify gere deja TLS et le conteneur applicatif n’a pas besoin d’inclure sa propre couche proxy.

Ressources totales

Composant	RAM (typique)	Disque	CPU
Backend (Java 25)	512 MB – 1.5 GB	minimal	1 coeur
PostgreSQL 16	256 MB – 512 MB	1-10 GB (donnees)	partage
Frontend (statique)	~20 MB	~50 MB	negligeable
Gotenberg	200-400 MB	~500 MB	burst only
Caddy	~20 MB	minimal	negligeable
Total	~1.5 – 2.5 GB	~2-12 GB	2 coeurs

Un VPS avec 4 GB de RAM, 2 coeurs et 20 GB SSD fait tourner confortablement toute la stack QuoteNode pour une equipe de 10 a 20 utilisateurs. Cela correspond approximativement a une instance cloud a 10-20 USD par mois, soit souvent bien moins que de nombreux abonnements CRM SaaS.

Ideal pour les petites et moyennes entreprises

QuoteNode est concu pour des organisations de 1 a 50 utilisateurs :

• Freelances et consultants solo qui ont besoin de documents d’offre professionnels sans payer pour un CRM enterprise
• Petites agences (5-15 personnes) qui veulent centraliser la gestion des clients et des offres avec de la visibilite pour l’equipe
• Entreprises de taille moyenne (15-50 personnes) avec un processus commercial plus structure, qui ont besoin d’analytique pipeline, de roles et de conformite d’audit

Le modele self-hosted supprime les frais mensuels par seat tout en offrant un controle complet sur les donnees, le branding et la configuration de securite. Pour les organisations qui maintiennent deja une infrastructure serveur basique ou utilisent une plateforme Docker geree comme Coolify, le surcout operationnel reste faible.

Roadmap multilingue

QuoteNode prend actuellement en charge l’anglais, le polonais, l’allemand, le francais, l’espagnol, l’italien et le portugais dans l’UI applicative comme sur toutes les surfaces visibles par le client (offres, PDF, liens publics, emails).

L’anglais et le polonais restent les locales de reference completes. Les autres langues sont deja actives dans le produit et continuent de s’etendre dans la couche publique du site.

L’objectif a long terme reste une couverture complete des principales langues europeennes. L’architecture i18n (vue-i18n avec des fichiers de cles structures) est deja prevue pour cette extension sans changement de code : il suffit d’ajouter les fichiers de traduction.

Les PDF d’offre et les pages de liens publics peuvent deja etre rendus dans n’importe quelle locale prise en charge, independamment de la langue de l’interface, ce qui permet de presenter des offres a des clients internationaux dans leur langue preferee.