Table des matières
Quand j'ai commencé à coder, je ne comprenais pas comment tout s'assemblait.
JavaScript, TypeScript, React, Next.js, Supabase, Prisma... C'était du jargon. Des mots que les devs utilisaient comme si c'était évident. Mais personne n'expliquait comment ça s'imbriquait.
J'ai évité le sujet pendant des mois. Trop technique. Pas assez vulgarisé.
Voici l'explication que j'aurais aimé avoir.
Tu arrives ici sans savoir ce qu'est le vibecoding ? Commence par cet article, ça prend cinq minutes.
Vue d'ensemble : le restaurant
Imagine une application web comme un restaurant :
┌─────────────────────────────────────────────────────────────┐
│ LE RESTAURANT │
├─────────────────────────────────────────────────────────────┤
│ │
│ 🍽️ SALLE 🧑🍳 CUISINE │
│ (Frontend) (Backend) │
│ │
│ • Le menu affiché • Préparation des plats │
│ • Les tables • Recettes secrètes │
│ • L'interaction client • Calcul de l'addition │
│ │
│ Ce que voit le client Ce qui est caché │
│ (ton navigateur) (le serveur) │
│ │
│ 🗄️ RÉSERVE │
│ (Base de données) │
│ │
│ • Ingrédients stockés │
│ • Inventaire │
│ • Historique des commandes │
│ │
│ Stockage permanent │
│ (PostgreSQL) │
│ │
└─────────────────────────────────────────────────────────────┘Le Frontend (la salle), c'est ce que tu vois. Les boutons, les formulaires, les images. Ça tourne dans ton navigateur.
Le Backend (la cuisine), c'est la logique cachée. Vérifier un mot de passe, calculer un prix, envoyer un email. Ça tourne sur un serveur.
La Base de données (la réserve), c'est le stockage permanent. Sans elle, tout disparaît quand le serveur redémarre.
Maintenant, voyons chaque ingrédient.
JavaScript : le langage du web
JavaScript, c'est le seul langage que les navigateurs comprennent.
Quand tu ouvres Chrome, Firefox ou Safari, ces navigateurs savent exécuter du JavaScript. C'est comme ça depuis 1995. Tous les sites web utilisent JavaScript.
En 2009, un dev nommé Ryan Dahl a eu une idée : "Et si on pouvait aussi utiliser JavaScript côté serveur ?" C'est Node.js. Avant ça, il fallait apprendre un autre langage (PHP, Java, Python) pour le backend.
Aujourd'hui, tu peux utiliser JavaScript partout. Frontend et backend. Un seul langage à apprendre.
Le problème ? JavaScript est trop gentil. Il accepte tout, même les erreurs :
Tu lui demandes de multiplier des heures par un taux horaire. Tu lui passes le mot "quarante" au lieu du chiffre 40. Il te répond sans broncher, avec un résultat vide. Aucune alerte, aucune erreur.
JavaScript ne prévient pas. L'erreur apparaît quand un utilisateur utilise ton app. C'est trop tard.
C'est là qu'arrive TypeScript.
TypeScript : le correcteur orthographique
TypeScript, c'est JavaScript avec un correcteur intégré.
Tu sais quand tu écris un email et que le correcteur souligne en rouge avant d'envoyer ? TypeScript fait pareil, mais pour le code.
Le même calcul écrit en TypeScript se fait souligner en rouge dans ton éditeur, avant même que tu lances l'app : "quarante" n'est pas un nombre.
L'erreur apparaît dans ton éditeur. Avant même de lancer l'application. Tu corriges tout de suite, pas en production.
Le truc important : TypeScript n'existe pas vraiment. Les navigateurs ne le comprennent pas. Avant d'être exécuté, TypeScript est transformé en JavaScript. Les vérifications disparaissent. C'est juste un outil pour t'aider pendant que tu codes.
Maintenant qu'on a le langage, comment construire l'interface ?
React : les LEGO
React, c'est une façon de construire des interfaces en blocs réutilisables.
Imagine une page web. Sans React, tu écris tout dans un seul fichier. Le header, le menu, les cartes, le footer. Tout mélangé.
Avec React, tu découpes en "composants". Chaque bloc est indépendant :
┌─────────────────────────────────────────────────────────────┐
│ UNE PAGE │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ <Header /> │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ <Card /> │ │ <Card /> │ │ <Card /> │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ ┌──────────────────┐ ┌────────────────────────────────┐ │
│ │ <Sidebar /> │ │ <Content /> │ │
│ └──────────────────┘ └────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ <Footer /> │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘Un bouton = un composant. Une carte = un composant. Un formulaire = un composant.
Tu crées une fois, tu réutilises partout. Tu modifies le composant <Card />, toutes les cartes de ton site changent.
Attention : React ne te donne pas des composants tout faits. C'est juste la méthode pour les créer. Pour avoir des boutons et des formulaires stylés, tu utilises une bibliothèque comme shadcn/ui.
React c'est les briques. Mais qui organise le chantier ?
Next.js : Microsoft Word du développeur
Voici une analogie qui m'a aidé :
| Écrire un document | Développer une app web |
|---|---|
| La langue française | TypeScript |
| La grammaire, le vocabulaire | La syntaxe, les types |
| Un style d'écriture | React |
| Écrire en paragraphes structurés | Écrire en composants réutilisables |
| Microsoft Word | Next.js |
| Mise en page automatique | Routing automatique |
| Export PDF | Build de production |
| Correction orthographique | Compilation TypeScript |
| Gestion des images | Optimisation des images |
Next.js, c'est le cadre qui organise tout.
Sans Next.js, tu dois configurer plein de trucs toi-même. Comment créer les pages ? Comment compiler le TypeScript ? Comment optimiser les images ? Comment gérer le serveur ?
Avec Next.js, tu crées un fichier → la page existe :
app/
├── page.tsx → URL: /
├── about/
│ └── page.tsx → URL: /about
├── blog/
│ ├── page.tsx → URL: /blog
│ └── [slug]/
│ └── page.tsx → URL: /blog/mon-articleTu te concentres sur ton code. Next.js gère le reste.
L'interface c'est fait. Où on stocke les données ?
PostgreSQL : l'entrepôt
Sans base de données, tout disparaît.
Tu crées un utilisateur → il existe. Tu redémarres le serveur → il n'existe plus. Comme un tableau Excel que tu n'aurais pas sauvegardé.
PostgreSQL, c'est l'entrepôt. Le stockage permanent. Tu y mets des données, elles restent.
Une base de données, c'est des tables. Comme des tableaux Excel :
Table "users" Table "jobs"
┌────┬──────────┬─────────┐ ┌────┬────────────┬────────┐
│ id │ name │ email │ │ id │ title │ salary │
├────┼──────────┼─────────┤ ├────┼────────────┼────────┤
│ 1 │ Jean │ j@x.com │ │ 1 │ Développeur│ 3500 │
│ 2 │ Marie │ m@x.com │ │ 2 │ Designer │ 3000 │
└────┴──────────┴─────────┘ └────┴────────────┴────────┘Pour parler à la base, il existe un langage dédié, le SQL. Tu lui dis "donne-moi la ligne de la table users dont le nom est Jean", en plus sec et en anglais.
Mais tu ne vas pas écrire du SQL partout dans ton code. C'est là qu'arrivent les intermédiaires.
Supabase et Prisma : les intermédiaires
Supabase, c'est un service qui simplifie PostgreSQL.
Au lieu d'écrire du SQL, tu lui demandes la même chose dans le langage que tu utilises déjà pour le reste de ton app. Il traduit pour toi.
Prisma, c'est un ORM (Object-Relational Mapping). Il fait la même traduction, et il va plus loin.
Il prévient ton éditeur de ce que contient ta base. Tu commences à taper le nom d'un champ, il te le propose. Tu te trompes de nom, il te le souligne. Souviens-toi du correcteur orthographique : c'est le même principe, appliqué à tes données.
┌──────────────┐ ┌─────────────────┐ ┌────────────┐
│ Ton code │ ───► │ Supabase/Prisma │ ───► │ PostgreSQL │
│ (TypeScript) │ │ (traducteur) │ │ (stockage) │
└──────────────┘ └─────────────────┘ └────────────┘Les deux marchent. Mon conseil : si tu démarres, prends Supabase, tu as la base, l'auth et le stockage en dix minutes. Si ton projet grossit et que tu veux que TypeScript te prévienne quand tu te trompes de champ, passe à Prisma.
Maintenant, la question clé...
Qui fait quoi ?
Voici le récap :
┌─────────────────────────────────────────────────────────────┐
│ ARCHITECTURE COMPLÈTE │
├─────────────────────────────────────────────────────────────┤
│ │
│ NAVIGATEUR (ce que voit l'utilisateur) │
│ ────────────────────────────────────── │
│ │ React + TypeScript │
│ │ • Boutons, formulaires, cartes │
│ │ • Interactions (clics, saisie) │
│ │ │
│ └──────────────────────┬────────────────────────────── │
│ │ appelle │
│ ▼ │
│ SERVEUR (caché) │
│ ─────────────── │
│ │ Next.js + TypeScript │
│ │ • Logique métier (validations, calculs) │
│ │ • Sécurité │
│ │ │
│ └──────────────────────┬────────────────────────────── │
│ │ requête │
│ ▼ │
│ BASE DE DONNÉES │
│ ─────────────── │
│ │ PostgreSQL (via Supabase ou Prisma) │
│ │ • Stockage permanent │
│ │ • Tables et relations │
│ │
└─────────────────────────────────────────────────────────────┘| Technologie | C'est quoi | Son rôle |
|---|---|---|
| JavaScript | Langage | Le seul que les navigateurs comprennent |
| TypeScript | Sur-langage | JavaScript + correcteur orthographique |
| React | Bibliothèque | Construire l'interface en composants |
| Next.js | Framework | Organiser et faire tourner l'app |
| PostgreSQL | Base de données | Stocker les données |
| Supabase/Prisma | Interface | Parler à la base facilement |
Une question que tout le monde tranche trop vite : où mettre la logique métier ?
Les validations, les calculs, les conditions : ça va dans ton code, ou dans ta base ? La réponse a l'air évidente et elle ne l'est pas.
J'ai fait l'erreur de mettre ma logique au mauvais endroit. 226 fonctions SQL plus tard, je galère à faire évoluer mon app. J'en parle en détail dans cet article.
La stack moderne, c'est chaque outil à sa place.
Si tu débutes, commence par JavaScript. Puis TypeScript. Puis React. Le reste viendra naturellement.
L'important, c'est de comprendre comment ça s'assemble. Le reste, tu l'apprends en construisant un truc qui marche.
Alors ouvre un projet ce soir. Une page, un bouton, une ligne en base. Tu comprendras plus en deux heures qu'en dix articles.
Maintenant que tu sais qui fait quoi, installe l'outil qui va écrire tout ça avec toi. Et si tu hésites encore sur ton éditeur, le choix compte plus qu'on ne croit.
Commentaires