Choisir une stack technique, c'est prendre une décision qui va peser sur chaque projet livré pendant deux ou trois ans. Chez Lucid-Lab, on ne change pas de stack à chaque projet pour paraître modernes : on a stabilisé un socle éprouvé, et on en assume les choix devant chaque client.
Pourquoi une stack par défaut plutôt que du "cas par cas"
La tentation est réelle : adapter l'outillage à chaque projet, suivre les tendances, empiler des nouveautés. En pratique, ça produit des bases de code hétérogènes, des onboardings compliqués et des bugs d'intégration qu'on aurait évités.
Une stack par défaut, ce n'est pas du dogmatisme. C'est de la rigueur opérationnelle. Quand chaque développeur chez Lucid-Lab connaît le socle sur le bout des doigts, le temps de setup passe de deux semaines à deux jours, les revues de code vont plus vite, et les clients héritent d'une base qu'on peut maintenir sans les prendre en otage.
Les critères qui ont guidé notre sélection :
- Maturité réelle : chaque composant est en production chez des milliers d'équipes, pas en bêta publique
- Interopérabilité : les briques se parlent sans colle excessive
- Portabilité : le client peut reprendre son repo et changer de prestataire demain matin
- Observabilité native : logs, alertes et métriques disponibles sans plugin maison
- TypeScript first : le typage strict réduit les régressions en production plus que n'importe quel process manuel
Le golden stack Lucid-Lab : les quatre briques
Next.js App Router : le frontend qui fait le backend
Next.js 14+ avec l'App Router est notre point d'entrée pour toute interface web et toute API REST ou webhook. Ce n'est pas un choix par défaut de paresse : c'est le seul framework React qui gère de manière native le rendu serveur, les routes API, le streaming et le cache de requêtes dans un seul repo cohérent.
Ce que ça change concrètement :
- Une seule codebase pour l'interface et la logique métier légère : pas de micro-services inutiles pour un MVP ou une application PME
- Les Server Components réduisent la quantité de JavaScript envoyée au navigateur, ce qui améliore les Core Web Vitals sans configuration manuelle
- Les Route Handlers remplacent un backend Express basique dans 80 % des cas
On compile toujours en TypeScript strict, avec ESLint configuré pour interdire les any implicites et Vitest pour les tests unitaires. Ce n'est pas de la bureaucratie : un type manquant en développement devient un bug silencieux en production.
Supabase : la base de données qui remplace quatre services
Supabase est notre couche données. Elle repose sur PostgreSQL, ce qui signifie qu'il n'y a rien de propriétaire sous le capot : le client peut migrer vers n'importe quel hébergeur Postgres si besoin.
Ce qu'on utilise dans chaque projet :
| Fonctionnalité Supabase | Ce qu'elle remplace | Économie estimée |
|---|---|---|
| PostgreSQL géré | RDS + configuration manuelle | 4 à 8h de setup |
| Auth (JWT + OAuth) | Auth0 ou service custom | 300 à 600 €/an selon usage |
| Storage (S3-compatible) | Bucket AWS configuré à la main | 2 à 4h de setup |
| pgvector | Pinecone ou Weaviate externe | 100 à 400 €/mois selon volume |
L'extension pgvector mérite un paragraphe à part. Pour les projets avec des agents IA, la recherche sémantique ou la gestion de contexte conversationnel, stocker les embeddings directement dans PostgreSQL évite d'ajouter une base vectorielle externe. Si vous construisez un pipeline de prospection automatisée, cette architecture simplifie considérablement la gestion des données d'enrichissement.
La Row Level Security de Supabase permet aussi de gérer la conformité RGPD au niveau de la base elle-même : chaque utilisateur ne peut accéder qu'aux lignes qui lui appartiennent, sans que la logique applicative ait à porter ce poids. C'est un point non négociable pour les projets avec données personnelles, comme on l'explique dans notre article sur la gouvernance IA et les obligations RGPD.
Vercel : le déploiement qui s'efface
Vercel héberge les applications Next.js. Le choix est pragmatique : le couple Next.js + Vercel est la combinaison la mieux optimisée du marché. Les prévisualisations par pull request, le rollback en un clic, les analytics de performance intégrés et les logs en temps réel sont disponibles sans configuration.
Ce qu'on obtient sans effort supplémentaire :
- Preview URLs automatiques : chaque branche a son environnement de test accessible via une URL publique, ce qui accélère les validations client
- Edge Functions : pour les cas où la latence compte (redirections géographiques, A/B testing), les fonctions s'exécutent au plus près de l'utilisateur
- Rollback immédiat : en cas de régression, on revient au déploiement précédent en moins de 30 secondes
Un point important sur le lock-in : le code Next.js est du code Next.js, pas du code Vercel. L'application peut être migrée vers AWS App Runner, Railway ou un VPS classique. Le repo appartient au client dès le premier commit.
Cloudflare : la couche de protection invisible
Cloudflare gère le DNS et le WAF (pare-feu applicatif web) de toutes nos livraisons. Ce n'est pas optionnel.
Le WAF bloque les attaques courantes (injections, scraping agressif, DDoS applicatif) avant que les requêtes n'atteignent Vercel ou Supabase.
Les règles de protection qu'on active par défaut :
- Blocage des bots malveillants connus
- Rate limiting par IP sur les endpoints sensibles (auth, upload, webhooks)
- HTTPS forcé avec HSTS
- Géoblocage optionnel selon le contexte réglementaire du client
Le plan gratuit de Cloudflare couvre 95 % des besoins d'une PME. Pour les projets avec des contraintes de compliance sectorielles, on monte sur les plans payants.
Ce qu'on n'utilise pas par défaut, et pourquoi
Pas de n8n en socle principal
n8n est un outil sérieux que nous comparons objectivement dans notre analyse des plateformes d'automatisation no-code. Notre choix de ne pas en faire le coeur de nos livraisons répond à une logique simple : les workflows visuels créent une dette de maintenance difficile à tester automatiquement.
Quand la logique métier est dans du code TypeScript versionné et testé avec Vitest, on peut détecter une régression avant le déploiement. Un workflow n8n complexe, lui, se teste manuellement ou pas du tout. Pour des automatisations autonomes en production, ce compromis n'est pas acceptable.
Ça ne veut pas dire qu'on exclut n8n de tous les projets : pour des intégrations rapides entre outils SaaS existants, il reste pertinent. Mais il ne fait pas partie du socle garanti.
Pas de monorepo par défaut
Les monorepos (Turborepo, Nx) ajoutent de la complexité de build sans valeur ajoutée pour la plupart des projets PME. On y recourt uniquement quand plusieurs applications partagent des packages métier significatifs.
Les garanties concrètes pour chaque client
Livrer sur ce stack, c'est livrer avec un niveau de garantie explicite :
Portabilité : le repo Git appartient au client. Les credentials Supabase et Vercel sont dans son compte. Changer de prestataire ne nécessite aucune migration de plateforme.
Observabilité : logs applicatifs sur Vercel, métriques base de données sur Supabase, alertes WAF sur Cloudflare. Tout est visible sans outil de monitoring supplémentaire à configurer.
Testabilité : TypeScript strict bloque les erreurs de type à la compilation. ESLint enforce les conventions. Vitest couvre la logique métier critique. Un nouveau développeur peut onboarder en confiance.
Scalabilité prévisible : Vercel et Supabase scalent horizontalement sans intervention manuelle jusqu'à des volumes que 99 % des PMEs n'atteignent jamais. Quand on approche des limites, les signaux sont visibles bien à l'avance.
Pour un projet comme BSP37, un artisan en signalétique qui avait besoin d'une refonte web avec espace client, ce stack a permis de livrer en six semaines une application avec authentification, espace de suivi des commandes et stockage des fichiers de production, sans aucune infrastructure à gérer côté client.
Ce stack est un point de départ, pas un plafond
La stack par défaut couvre 80 % des projets. Pour les 20 % restants, on dévie de manière consciente et documentée : base de données relationnelle différente si le schéma l'exige, hébergement alternatif si la souveraineté des données l'impose, infrastructure Kubernetes si les volumes le justifient.
Ces déviations font partie de la Roadmap d'Exécution que Lucid-Lab produit avant chaque développement : chaque choix technique est argumenté, chaque alternative écartée est expliquée. Aucune surprise en milieu de projet.
Si vous voulez évaluer si ce socle correspond à votre besoin, une session de diagnostic technique de 45 minutes permet de le vérifier sans engagement.
Questions fréquentes
Pourquoi choisir Next.js plutôt que Nuxt ou Remix pour une application PME en 2026 ?
Next.js est le framework React avec le plus large écosystème, la documentation la plus complète et le meilleur support natif des patterns modernes (Server Components, streaming, cache). Pour une PME, cela signifie moins de temps passé à chercher des solutions à des problèmes déjà résolus et un plus grand nombre de développeurs capables de reprendre le projet. Nuxt est excellent pour les équipes Vue.js, Remix reste pertinent pour des cas d'usage très orientés formulaires : ce ne sont pas de mauvais choix, mais ils impliquent un écosystème plus restreint.
Supabase est-il conforme au RGPD pour des données de clients européens ?
Supabase propose des régions d'hébergement en Europe (Frankfurt) et publie un DPA (Data Processing Agreement) conforme aux exigences européennes. La Row Level Security de PostgreSQL permet de contrôler finement qui accède à quelles données. Pour des données sensibles (santé, données financières), des vérifications complémentaires sur la sous-traitance et les transferts hors UE restent nécessaires : Supabase n'est pas une garantie de conformité automatique, mais c'est une base solide.
Peut-on vraiment quitter Vercel sans tout reconstruire ?
Oui, à condition que le projet n'utilise pas des fonctionnalités strictement propriétaires à Vercel (certaines configurations d'Edge Middleware très spécifiques). Une application Next.js standard se déploie sur Railway, Render, AWS App Runner ou un VPS avec Docker sans modifier une ligne de code applicatif. C'est précisément pourquoi on évite de dépendre des fonctionnalités exclusives à une plateforme.
Quelle est la différence entre une stack no-code et ce type de stack technique pour une PME ?
Une stack no-code (Make, Zapier, Webflow) permet de démarrer très vite mais atteint ses limites dès que la logique métier devient complexe ou que les volumes augmentent. Une stack code-first comme Next.js + Supabase demande un investissement initial plus élevé, mais chaque fonctionnalité est testable, versionnée et modifiable sans contourner les limites d'une plateforme. Pour des opérations critiques ou des systèmes qui doivent absorber de forts volumes, le code reste la seule approche qui ne génère pas de plafond arbitraire.