Tu connais maintenant le frontend, le backend, HTTP et la base de données. La plupart des développeurs s'arrêtent là, et c'est pour ça qu'ils passent des heures à déboguer des couplages qu'ils n'avaient pas vus. Un schéma d'architecture oblige à mettre à plat le qui-parle-à-qui et le où-vit-la-donnée, en deux minutes, avant d'écrire une seule ligne de code.
Pourquoi un schéma
Les décisions d'architecture sont souvent prises à l'oral, dans un Slack ou "dans la tête". Résultat : chaque développeur a une représentation légèrement différente du système, et les bugs viennent des zones grises entre ces représentations.
Un schéma force trois choses utiles :
- Expliciter les flux : tu ne peux pas dessiner une flèche sans décider qui initie la communication et dans quel sens.
- Nommer les composants : "le backend" n'est plus une boîte noire, c'est
Next.js App,Worker Node.js, ouSupabase Edge Function. - Repérer les dépendances cachées : si ton frontend appelle directement ta base de données, ça se voit sur le schéma. C'est impossible de l'ignorer.
Les 4 éléments d'un schéma d'app
Tout schéma d'application web contient au minimum quatre types de blocs. Mémorise-les.
Users / Clients : qui consomme l'application. Typiquement un navigateur, une application mobile, ou une autre API externe.
Entry point : le premier composant que frappe la requête après avoir quitté le client. Sur le web moderne, c'est souvent un CDN (Vercel Edge, Cloudflare) ou un load balancer. Ce bloc est crucial parce qu'il est l'unique porte d'entrée publique.
Services : le code métier. Frontend statique, serveur Next.js, workers de traitement asynchrone, tâches planifiées (cron jobs). Chaque service a une responsabilité distincte.
Storage : ce qui persiste au-delà du cycle requête/réponse. Base de données relationnelle (PostgreSQL), cache (Redis), stockage de fichiers (S3, Supabase Storage), file de messages (Queue).
Méthode de lecture en 5 étapes
Face à un schéma que tu n'as jamais vu, voici comment l'aborder systématiquement.
Identifier l'utilisateur
Cherche le bloc "humain" ou "navigateur" en haut à gauche. C'est toujours le point de départ du flux principal. Si le schéma n'a pas d'utilisateur visible, il manque quelque chose.
Suivre une requête de bout en bout
Trace mentalement le chemin d'une requête typique : de l'utilisateur jusqu'au stockage et retour. Chaque flèche que tu traverses est une communication réseau avec sa latence, ses erreurs possibles, ses contrats d'interface.
Repérer les flux asynchrones
Les flèches en pointillé ou les queues indiquent des traitements qui ne bloquent pas la requête principale. Exemple : envoyer un email de confirmation après une inscription. Le serveur répond "201 Created" immédiatement, et un worker traite l'email en arrière-plan. Si ce flux asynchrone tombe, l'utilisateur ne le voit pas directement - c'est un piège.
Repérer les points de défaillance uniques
Un single point of failure (SPOF) est un composant dont la panne arrête tout le service. Concrètement sur un schéma : un nœud sans redondance que toutes les flèches traversent obligatoirement. Une seule base de données sans réplica en lecture ? SPOF. Un seul service d'authentification sans fallback ? SPOF.
Repérer les frontières de confiance
Où finit le réseau interne et où commence l'internet public ? Quels composants traitent des données sensibles (tokens, mots de passe, PII) ? Ces frontières doivent être visibles, soit par des zones délimitées sur le schéma, soit par des annotations explicites sur les flèches.
Exemple : l'architecture de Blokby
Voici le schéma de l'application Blokby website, avec ses cinq composants principaux.
Architecture du site Blokby (schéma simplifié).
Chaque flèche, expliquée :
- User → CDN (HTTPS) : toutes les requêtes passent d'abord par l'edge Vercel. Les assets statiques (HTML pré-rendu, CSS, JS) sont servis depuis le cache CDN sans jamais atteindre le serveur Next.js. Latence : 10-50ms selon le datacenter le plus proche.
- CDN → Next.js (cache miss) : quand la page n'est pas en cache (première visite, page dynamique, revalidation), la requête remonte jusqu'au serveur Next.js. C'est là que se passe le rendu côté serveur.
- Next.js → Supabase (SQL) : le serveur Next.js interroge Supabase via le client JavaScript officiel. Les Server Components exécutent ces requêtes côté serveur, donc les credentials Supabase ne sont jamais exposés au navigateur.
- Next.js → Claude API (stream pointillé) : la flèche en pointillé signale un flux asynchrone. Les tokens arrivent en streaming, pas en une seule réponse bloquante. Si Claude API est indisponible, cette feature tombe mais le reste du site continue.
Exercice : lis ce schéma
Voici un schéma d'une application e-commerce simplifiée. Réponds aux trois questions avant de déplier la réponse.
Architecture e-commerce, à utiliser pour l'exercice de lecture qui suit.
Trois questions :
- Quel est le single point of failure le plus évident ?
- Où se trouve la frontière d'authentification ?
- Quelle étape concentre la latence critique sur le chemin d'une commande ?
Voir les réponses
1. Single point of failure : la base de données PostgreSQL est le SPOF le plus visible. Tous les services (Auth, Catalogue, Commandes) pointent vers la même instance. Si la DB tombe, l'ensemble de l'application s'arrête. Solution courante : un réplica en lecture + backups automatisés.
2. Frontière d'authentification : l'API Gateway est censée vérifier les tokens avant de router vers les services. Mais ici, le schéma montre que API → Auth est un appel direct - l'API Gateway délègue la vérification au service Auth. Ce qui veut dire que si quelqu'un contourne l'API Gateway et appelle Service Catalogue directement (si les ports sont mal configurés), il n'y a pas de second verrou. La frontière de confiance devrait être tracée autour du réseau interne.
3. Latence critique : le chemin d'une commande traverse Browser → API Gateway → Service Commandes → PostgreSQL en synchrone. Chaque saut ajoute de la latence. La DB est souvent le goulot d'étranglement : une transaction lente dans Orders bloque la réponse HTTP vers le navigateur. C'est pourquoi les commandes utilisent souvent une queue (ici présente) pour déplacer le traitement lourd hors du chemin synchrone.
Les mauvais signaux à reconnaître
Quand tu lis ou produis un schéma, voici les anti-patterns qui signalent un schéma incomplet ou trompeur.
Boîtes trop vagues - "Backend", "Services", "Le cloud" ne disent rien. Un schéma utile nomme les technologies : Next.js 15, Supabase (Postgres 16), Redis 7. La précision technique révèle les contraintes réelles.
Boîtes sans flèches - Un schéma qui liste des composants sans dessiner les flux est une liste de courses, pas un schéma d'architecture. Le quoi-fait-quoi reste caché.
Toutes les flèches pleines - Si tout est synchrone sur le papier, c'est suspect. La plupart des apps modernes ont au moins un flux asynchrone (email, webhook, job en arrière-plan). Représente-les avec des flèches en pointillé ou un symbole de queue.
Pas d'ancrage au stockage - Un schéma sans base de données visiblement placée est probablement incomplet. Où vivent les données ? Qui y accède directement ? C'est souvent là que se cachent les couplages dangereux.
Quand dessiner un schéma
Trois moments où un schéma fait gagner du temps :
- Avant de coder une nouvelle feature : dessine les composants que tu vas toucher et les nouvelles flèches que tu vas créer. Tu verras tout de suite si ta feature crée un couplage inattendu ou un SPOF.
- Après avoir codé : mets à jour le schéma existant. C'est ta documentation vivante. Deux semaines plus tard, toi-même ou quelqu'un d'autre comprendra le système en 5 minutes.
- Pendant un debug : quand tu ne sais plus pourquoi un bug se produit, dessine le flux réel du problème. Le schéma te forcera à vérifier chaque saut réseau et souvent, l'erreur devient évidente.
Outils recommandés
Mermaid (utilisé dans ce cours) : syntaxe texte, compatible GitHub, Notion, Obsidian. Idéal pour les schémas que tu versionnes avec ton code.
Excalidraw : main levée, collaboratif en temps réel, gratuit. Parfait pour les sessions de brainstorm à deux ou trois. Prévu pour la V2 de ce cours.
draw.io : outil précis avec bibliothèques de shapes AWS/GCP/Azure. Adapté aux architectures cloud complexes.
Figma : pour les schémas "présentables" destinés à des clients ou des investisseurs. Plus de mise en forme, moins de rapidité.
Le plus important n'est pas l'outil choisi : c'est de choisir un seul outil et de l'utiliser systématiquement. Un schéma dans Mermaid versionné dans le repo vaut dix fois un beau Figma perdu dans un Drive partagé.