Architecture 101 : frameworks, monorepos et comment les applications modernes s'imbriquent

Vue d'ensemble

Vous avez terminé le Cours 1 en shippant un vrai site et le Cours 2 en transformant votre agent en outil puissant. Maintenant vous montez d'une simple page statique à une vraie application avec des utilisateurs, des données et des paiements. Avant tout cela, il vous faut la carte. Cette leçon est cette carte : ce qu'un framework fait vraiment pour vous, les trois couches dont chaque app est bâtie, pourquoi les équipes sérieuses séparent un site marketing rapide de l'app plus lourde et quand un monorepo est un cadeau versus une taxe. Rendez cela clair, et chaque décision ultérieure de ce cours cesse de paraître arbitraire.

Ce que vous allez apprendre

Vous allez apprendre la différence entre frontend, backend et base de données en mots clairs, comment se comparent les principaux frameworks 2026 et quand chacun convient, pourquoi des sociétés comme Clerk et Convex font tourner un site marketing séparé de leur app, et la règle honnête pour savoir quand un monorepo paie. À la fin, vous saurez esquisser l'architecture de n'importe quel SaaS sur une serviette et expliquer pourquoi elle a cette forme.

Prérequis

Le Cours 1, surtout les leçons sur le setup de projet et le déploiement, car les décisions d'architecture s'appuient sur une boucle construire-et-shipper qui fonctionne. Vous devez être à l'aise pour exécuter des commandes de terminal et avoir déployé au moins une page. Si les mots « framework » ou « TypeScript » sont encore flous, survolez d'abord les pages de fondamentaux sur ce qu'est un framework et ce qu'est TypeScript, puis revenez.

Le problème

La plupart des débutants collent une app en copiant ce qu'un tutoriel a fait, sans modèle de la façon dont les pièces s'articulent. Puis ils heurtent un mur : le site marketing est lent parce qu'il est empaqueté avec toute l'app, l'auth et les données sont enchevêtrées dans l'UI, et personne ne sait dire où vit une responsabilité donnée. Le résultat est une app difficile à changer et impossible à raisonner. Rien de tout cela n'est un problème de compétence en coding. C'est un modèle mental manquant. Cette leçon installe le modèle, pour que votre agent construise sur un sol ferme au lieu d'un tas de snippets copiés.

Les trois couches : frontend, backend, base de données

Chaque app web, aussi élégante soit-elle, ce sont trois couches qui se passent le travail. Le frontend est ce qui tourne dans le navigateur : le HTML, le CSS et le JavaScript qui dessinent l'écran et réagissent aux clics. Le backend est le code qui tourne sur un serveur, loin de l'utilisateur, où vous mettez la logique et les secrets que le navigateur ne doit pas voir. La base de données est où les données vivent durablement, pour qu'elles survivent à un rafraîchissement de page et soient partagées entre utilisateurs. Une requête suit un chemin aller-retour : le navigateur demande quelque chose au backend, le backend lit ou écrit la base de données et renvoie une réponse que le navigateur rend. La plupart de la confusion sur « où va ce code » se dissout dès que vous savez nommer à laquelle de ces trois couches appartient un morceau de travail.

• Frontend : tourne dans le navigateur, dessine l'UI, ne tient jamais de secrets, tout le monde peut le lire.
• Backend : tourne sur un serveur, tient la logique métier et les clés API, parle à la base de données.
• Base de données : stocke les données durablement et les partage entre utilisateurs et sessions.
• Règle d'or : un secret (clé API, mot de passe) appartient au backend, jamais au code frontend, car le navigateur livre son code à chaque visiteur.

Ce qu'un framework vous donne

Un framework vous donne structure, routing et conventions, pour que vous n'assembliez pas une app à partir de fichiers bruts. Il décide comment les URL sont mappées vers les pages, comment les pages récupèrent des données, comment l'app est empaquetée et livrée, et cent petites choses que vous réinventeriez sinon. Les options 2026 penchent chacune dans une direction différente, et le bon choix dépend de la part de contenu versus app dans votre produit.

• Astro : bâti pour des sites rapides et riches en contenu - blogs, docs, sites marketing. Livre presque aucun JavaScript par défaut, donc les pages chargent vite et rankent bien. Saisissez-le quand l'essentiel de votre produit est du contenu.
• Next.js : le framework React poids lourd pour les apps riches et interactives. Écosystème énorme, rendu serveur et le défaut que beaucoup d'équipes choisissent pour une vraie app produit.
• TanStack Start : un framework React full-stack plus récent, bâti sur TanStack Router, avec une excellente type safety et une sensation plus légère et transparente. C'est cette plateforme même qui tourne sur TanStack Start.
• Vue (avec Nuxt) : la principale alternative à React. Même job, syntaxe et philosophie différentes. Choisissez-le si vous ou votre équipe pensez déjà en Vue.

Vous n'avez pas à maîtriser les quatre. Choisissez un framework d'app et un framework de contenu et tenez-vous-y. Une combinaison courante et sensée est Astro pour le site marketing et un framework React (Next.js ou TanStack Start) pour l'app. Les noms exacts comptent moins que la compréhension de l'axe : contenu-rapide versus app-riche.

Le split site marketing versus app

Voici le schéma qui embrouille les débutants jusqu'à ce que quelqu'un le nomme : les produits sérieux font tourner leur site marketing public et leur app connectée comme deux choses séparées, souvent sur deux sous-domaines. Regardez Clerk et Convex eux-mêmes - la homepage sur le domaine nu est un site marketing rapide, et le dashboard vit à une adresse séparée. Ce n'est pas la même codebase qui sert les deux. La raison est que les deux surfaces ont des besoins opposés. Les sites marketing publics doivent être ultra-rapides et pleinement indexables par Google et les crawlers d'IA, car c'est ainsi qu'on vous trouve. L'app connectée peut être plus lourde et richement interactive, car l'utilisateur est déjà arrivé et connecté, et le SEO ne compte plus. Les empaqueter ensemble force un mauvais compromis : soit votre site marketing traîne toute l'app et charge lentement, soit votre app est bridée par les contraintes du site marketing. Les séparer laisse chacun s'optimiser pour son vrai job.

• Site marketing : domaine nu (yoursite.com), rapide, optimisé SEO et GEO, souvent Astro. Son job est d'être trouvé et de convertir les visiteurs.
• App : un sous-domaine (app.yoursite.com), plus lourde, interactive, derrière l'auth. Son job est de livrer le produit. Le SEO ne compte pas ici.
• L'auth et les dashboards (Clerk) et votre base de données (Convex) vivent côté app, jamais empaquetés dans les sites marketing.
• Ce split est la raison pour laquelle votre homepage peut atteindre 100 sur Lighthouse tandis que votre app est une expérience React riche et à état.

Ce qu'est un monorepo et quand il aide

Un monorepo est un unique repository Git qui contient plusieurs projets liés - disons votre site marketing, votre app et un paquet partagé de composants - au lieu d'un repo par projet. L'attrait est réel : vous partagez du code (types, composants UI, utilitaires) entre surfaces sans publier de paquets, et un pull request peut changer tout ce qui doit changer ensemble. Les coûts sont réels aussi : les monorepos ajoutent de l'overhead d'outillage (gestionnaire de workspace, builds plus complexes, CI plus lente si vous êtes négligent) dont un débutant en solo n'a pas besoin le premier jour. La règle honnête : saisissez un monorepo quand vous partagez vraiment du code significatif entre deux surfaces ou plus et que la duplication vous fait mal. Jusque-là, des repos séparés sont plus simples et parfaitement bien. N'adoptez pas un monorepo parce qu'une grande société le fait - eux ont des centaines d'ingénieurs et vous avez un agent et un laptop.

• Monorepo : un repo, plusieurs projets, code partagé, changements coordonnés.
• Vaut le coup quand : le site marketing et l'app partagent des types ou des composants et que vous les changez souvent ensemble.
• Sautez-le quand : vous avez une seule app ou deux surfaces qui partagent à peine du code. L'overhead n'est pas gratuit.
• Vous pouvez toujours démarrer avec des repos séparés et fusionner en monorepo plus tard, quand la douleur est réelle.

Erreurs fréquentes

Les erreurs récurrentes à cette phase : empaqueter site marketing et app dans un projet puis se demander pourquoi la homepage est lente et le SEO souffre ; mettre une clé API secrète dans le code frontend, où chaque visiteur peut la lire ; adopter un monorepo le premier jour parce que ça a l'air pro et se noyer dans la config de build ; et choisir un framework par hype au lieu de savoir si votre produit est riche en contenu ou en app. Chacune vient du fait de sauter le modèle mental. Nommez la couche, nommez la surface, et la bonne structure suit.

ROI business

Une architecture bien décidée au départ est quasi gratuite ; mal décidée, elle taxe chaque changement futur. Un split propre marketing versus app signifie que votre homepage reste rapide et est trouvée, ce qui est le haut de tout votre funnel - les sites marketing lents vous coûtent silencieusement des clients et du rang de recherche pour toujours. Savoir quelle couche possède quelle responsabilité signifie que vous (et votre agent) shippez des features sans créer d'enchevêtrements qui nécessitent plus tard de coûteuses réécritures. Les fondateurs qui bougent le plus vite ne sont pas ceux qui ont choisi le framework le plus tendance ; ce sont ceux dont l'architecture leur permet de changer une chose sans en casser trois autres.

Checklist

Avant d'avancer, assurez-vous de pouvoir répondre à ceci sans revenir en arrière. Cette carte est sous toutes les autres leçons du cours.

• Savez-vous expliquer frontend, backend et base de données et laquelle tient les secrets ?
• Savez-vous dire quand choisir Astro versus Next.js ou TanStack Start ?
• Savez-vous expliquer pourquoi les équipes séparent le site marketing de l'app ?
• Savez-vous énoncer la règle honnête sur quand un monorepo vaut le coup ?

Ressources

Gardez en favoris les docs officielles de vos frameworks choisis - Astro, Next.js, TanStack Start et Nuxt ont tous d'excellents guides de démarrage. Les pages de fondamentaux sur ce qu'est un framework et ce qu'est TypeScript étayent cette leçon si un concept est resté flou. Les trois prochaines leçons remplissent les trois couches une par une : auth, puis données, puis les secrets qui les relient.

Votre mission

Esquissez votre propre produit (ou un produit que vous admirez) sous forme de diagramme à trois boîtes - frontend, backend, base de données - avec une flèche montrant une requête les traverser. Marquez ensuite quelles parties sont le site marketing et lesquelles sont l'app. Cinq minutes avec un stylo rendent le reste de ce cours concret, car vous avez désormais une vraie forme à laquelle accrocher chaque nouveau morceau.

Prochaine leçon

Avec une architecture claire, la prochaine leçon ajoute le premier vrai bloc de construction : l'authentification avec Clerk, y compris ce qu'est vraiment OAuth, pourquoi vous ne devez jamais bâtir l'auth vous-même et un parcours Google OAuth complet, d'une instance de development à la production.