Parent : [[INDEX-DEV-GENERAL]]
Choisir une stack depuis les contraintes du produit
Problème
Choisir par popularité, habitude ou liste « meilleure stack de l'année » produit des dépendances inutiles. Un framework, un ORM ou un hébergeur n'est jamais une réponse avant d'avoir défini le rendu, les données, l'exploitation et les compétences disponibles.
Méthode
Étape 1 — Écrire les contraintes
- Pages publiques indexables ou application authentifiée ?
- Rendu statique, serveur, client ou mélange documenté par route ?
- Volume et durée de vie des données, transactions, recherche et travail hors ligne ?
- Temps réel réellement nécessaire ou simple actualisation périodique ?
- APIs système, fichiers locaux, mobile natif ou navigateur suffisant ?
- VPS existant, plateforme managée, exigences de région, sauvegarde et réversibilité ?
- Qui maintient le produit et quelles technologies cette personne sait diagnostiquer ?
Étape 2 — Retenir le socle le plus petit
| Besoin dominant | Point de départ à évaluer | Ne l'ajouter que si… |
|---|---|---|
| Contenu public majoritairement statique | HTML/CSS ou générateur statique | le framework réduit réellement la maintenance |
| Application React avec rendu serveur | Framework React compatible avec l'hébergement retenu | SSR, routage ou mutations serveur sont nécessaires |
| API métier | Runtime déjà maîtrisé + framework HTTP minimal | le framework plus lourd apporte conventions utiles à l'équipe |
| Données relationnelles | PostgreSQL ou SQLite selon concurrence et exploitation | l'ORM simplifie les migrations/requêtes sans cacher les coûts |
| Application locale/desktop | Web/PWA d'abord si les APIs nécessaires existent | Tauri/Electron est requis par l'intégration système ou la distribution |
| Mobile | Web responsive/PWA, puis cross-platform | les capacités natives et la distribution magasin sont réellement requises |
| Temps réel | Requête classique ou SSE avant canal bidirectionnel | l'utilisateur et le serveur émettent tous deux en continu |
| Calcul média ou graphique lourd | JavaScript/Canvas mesuré | Worker, GPU ou WASM corrige un goulot prouvé |
Étape 3 — Comparer par prototype vertical
Construire le parcours le plus risqué : une route, une écriture, un déploiement, une sauvegarde et une observation d'erreur. Comparer temps de développement, taille, latence, mémoire, diagnostic, coût mensuel et procédure de restauration. Une statistique de popularité aide à estimer l'écosystème ; elle ne décide jamais seule.
Règles de choix
- Aucune version majeure n'est inscrite comme défaut durable : vérifier la documentation et le support au moment du projet.
- Aucun fournisseur d'hébergement n'est imposé. Un VPS/Nginx, un hébergement statique ou une plateforme managée sont comparés selon exploitation, coût et réversibilité.
- Éviter Redis, une file, des microservices ou un moteur de recherche tant qu'une mesure ou une contrainte ne les exige pas.
- L'authentification externalisée est une décision sécurité/exploitation, pas un raccourci automatique.
- Documenter le choix, l'alternative rejetée, le signal qui déclencherait une migration et le plan de sortie.
Anti-patterns
KNOW-ANT-020— coder avant de décider.KNOW-ANT-WEB-001— hardcoder des couleurs sans tokens.KNOW-ANT-DEV-001— ship sans bootstrap ni gate.
Références
- [[KNOW-REF-001]] — Références externes 2025
- [[KNOW-PAT-198]] — Deployment & Infra 2026
- [[ACT-ALW-007]] — Solution Factory