Fragments Studio est agréé CII : bénéficiez de 20% de crédit d'impôt sur vos projets innovants 🚀

En savoir plus
Blog
REX Technique : Pourquoi ces choix de stack chez Fragments ?

Blog •Tech 7 min

Fragments Studio

REX Technique : Pourquoi ces choix de stack chez Fragments ?

Jérémy CTO

Jérémy

CTO

06/05/26

Choisir une stack technique n'est jamais un acte neutre. C'est un pari sur l'avenir, un arbitrage entre vélocité immédiate et maintenabilité à long terme. Chez Fragments Studio, nous avons stabilisé en 2026 un écosystème cohérent autour du TypeScript, privilégiant la structure et la prédictibilité sur la pure performance brute.

En 2026, le paysage du développement web n'a jamais été aussi fragmenté. Entre l'explosion des frameworks IA-native et la complexité croissante des outils de rendu, il est facile de se perdre dans la "hype". Pourtant, un studio de développement doit offrir une garantie à ses clients : celle que le code produit sera encore exploitable, performant et recrutable dans cinq ans.

Voici le retour d'expérience (REX) détaillé sur nos choix de stack, nos doutes et les compromis que nous assumons au quotidien.

Note importante : Ce REX décrit nos choix par défaut, pas une stack imposée. Chaque projet que nous accompagnons commence par une phase d'analyse des contraintes : existant technique, équipes en place, budget, objectifs de recrutement, dépendances tierces. Nous adaptons systématiquement nos recommandations au contexte réel du client — choisir la meilleure stack, c'est avant tout choisir la bonne stack pour ce projet.

Frontend : Pourquoi React + Vite plutôt que Next.js ?

C'est sans doute le sujet qui anime le plus nos discussions internes. En 2026, React reste l'outil hégémonique, mais son mode de consommation a divergé.

Le choix de la SPA avec Vite

Nous avons fait le choix de privilégier Vite pour la majorité de nos applications métiers (SaaS, outils internes, dashboards). Contrairement à Next.js, qui pousse de plus en plus vers les Server Components et une architecture hybride complexe, le couple React + Vite nous permet de conserver une séparation claire entre le client et le serveur.

Vite agit comme un build tool ultra-rapide utilisant les ES Modules natifs. Chez Fragments Studio, le passage de Webpack à Vite a réduit nos temps de démarrage de serveur de développement de 85% (passant de 40 secondes à moins de 3 secondes sur nos plus gros projets).

  • Le compromis assumé : Le SEO. Une application purement client-side (SPA) est moins performante sur l'indexation initiale. Pour nos clients nécessitant un SEO agressif, nous basculons sur Next.js, mais nous acceptons la complexité supplémentaire (gestion du cache serveur, hydratation) uniquement quand elle est strictement nécessaire.

Backend : NestJS et PostgreSQL, le duo de la prédictibilité

Pour le backend, nous avons standardisé nos développements sur NestJS couplé à une base de données PostgreSQL.

NestJS : le cadre structurant

Nous avons souvent été tentés par la légèreté d'Express ou la rapidité de Fastify. Cependant, NestJS s'est imposé car il apporte une structure inspirée d'Angular (Modules, Providers, Controllers). Dans un contexte d'agence, cette structure est vitale.

Elle permet à un développeur de Fragments Studio de passer d'un projet à l'autre sans phase de découverte architecturale. Tout est à sa place. Le support de TypeScript est natif et profond, garantissant une sécurité de type de bout en bout.

Le choix de PostgreSQL

En 2026, malgré l'essor des bases de données vectorielles pour l'IA, PostgreSQL reste notre colonne vertébrale. C'est une base relationnelle ACID (Atomicité, Cohérence, Isolation, Durabilité) qui gère désormais nativement le JSON et les vecteurs (via pgvector).

  • Comparaison avec MongoDB : Nous avons délaissé les approches NoSQL pour le noyau de nos applications. La rigueur des schémas relationnels évite 90% des bugs de données à mesure que le produit évolue.

Mobile : Le pari gagnant de React Native et Expo

Pour le mobile, la question ne se pose presque plus : nous utilisons React Native avec l'écosystème Expo.

Pourquoi pas le natif (Swift/Kotlin) ou Flutter ?

Le développement natif coûte deux fois plus cher pour un gain de performance souvent imperceptible pour 95% des applications business. Quant à Flutter, bien que performant, il impose le langage Dart, ce qui casse notre synergie d'équipe 100% TypeScript.

Expo a radicalement changé la donne en 2025-2026. Grâce aux Continuous Native Generations (CNG), nous n'avons plus besoin de manipuler les dossiers iOS et Android manuellement.

  • Bénéfice concret : Nous partageons environ 30% de logique métier (via des packages internes) entre nos applications web React et nos applications mobiles React Native.

Infrastructure : AWS pour le contrôle et la scalabilité

Plutôt que de dépendre de plateformes "tout-en-un" comme Vercel ou Supabase (que nous utilisons parfois pour des MVP), nous privilégions AWS pour nos infrastructures de production.

App Runner et ECS Express Mode

Nous utilisons majoritairement AWS App Runner pour sa simplicité de déploiement de containers, ou ECS (Elastic Container Service) pour des besoins plus complexes. En 2026, la migration vers le ECS Express Mode nous permet de réduire la latence de déploiement tout en gardant un contrôle total sur les coûts.

  • Le doute réel : La complexité d'AWS est un fardeau. Mais le coût de sortie de plateformes propriétaires est souvent plus élevé à long terme. Chez Fragments, nous préférons investir du temps en Infrastructure as Code (Terraform) pour garantir l'indépendance de nos clients.

L'écosystème périphérique : Better Auth, Shadcn et Framer

Au-delà des briques principales, nos outils annexes font la différence sur la Developer Experience (DX).

  1. Better Auth : En 2026, nous avons remplacé NextAuth et Auth0 par Better Auth. C'est une solution d'authentification open-source, agnostique au framework, qui nous permet de garder la main sur les données utilisateurs tout en offrant une expérience moderne (Passkeys, Social Login) sans frais récurrents exorbitants.
  2. Shadcn/UI & Tailwind : Nous avons abandonné les bibliothèques de composants rigides comme MUI pour Shadcn. L'approche "copier-coller le code plutôt qu'importer une lib" nous donne un contrôle total sur le design sans le poids d'une dépendance externe massive.
  3. Framer pour le marketing : Pour les sites vitrines à fort enjeu design, nous utilisons Framer. Cela permet à nos designers de livrer en production sans passer par une phase de développement frontend classique, accélérant le time-to-market par 3.

Questions fréquentes

Est-ce que Fragments Studio impose cette stack à tous ses clients ?

Non. Ce REX décrit notre socle de référence, pas un dogme. Avant toute recommandation, nous auditons l'existant : langage et frameworks déjà maîtrisés par l'équipe interne, contraintes d'hébergement ou de conformité, outils déjà en production, budget de migration. Si un client travaille avec une équipe Laravel expérimentée, nous n'allons pas lui imposer NestJS. Si un projet s'appuie sur une infrastructure Azure existante, nous l'intégrons plutôt que de tout reconstruire sur AWS. Notre rôle est de trouver le meilleur équilibre entre nos standards de qualité et la réalité opérationnelle du client.

Pourquoi ne pas utiliser exclusivement des outils No-Code en 2026 ?

Le No-Code est excellent pour le prototypage, mais nos clients viennent nous voir pour des outils qui doivent durer et s'intégrer à des écosystèmes complexes. Le sur-mesure en code (TypeScript) offre une flexibilité et une propriété intellectuelle que le No-Code ne peut pas encore égaler à grande échelle.

Est-ce que l'unification en TypeScript est vraiment un avantage ?

Oui, absolument. Cela permet à nos développeurs de devenir "Full-Stack" par nature. Un développeur peut corriger un bug sur l'App Mobile le matin et optimiser une requête SQL l'après-midi, car la syntaxe et les outils (ESLint, Prettier, Jest) sont identiques.

PostgreSQL est-il suffisant pour les projets d'IA ?

Avec l'extension pgvector, PostgreSQL est devenu une excellente base de données vectorielle. Pour la majorité des cas d'usage de RAG (Retrieval-Augmented Generation) que nous implémentons chez nos clients, elle est plus que suffisante et évite d'ajouter une brique technologique complexe comme Pinecone.


Besoin d'une expertise technique pour votre projet ?

Choisir la bonne stack est la première étape vers la réussite d'un produit digital. Chez Fragments Studio, nous mettons notre expérience terrain au service de votre vision.

Jérémy CTO

Jérémy

6 mai 2026

Contactez-nous