Frontend vs backend : quelle est la différence?
Le frontend est la partie d'une application qui s'exécute dans le navigateur de l'utilisateur : les pages, les boutons, les formulaires et les animations qu'il voit et sur lesquels il clique. Le backend est la partie qui tourne sur un serveur que l'utilisateur ne voit jamais. Il stocke et récupère les données, applique les règles d'affaires, vérifie qui a le droit de faire quoi et communique avec d'autres services comme les paiements et le courriel. Les deux parties échangent par une API et, avec une base de données, elles forment une application « full stack ».
Pourquoi c'est important quand on construit avec l'IA
Quand vous décrivez une application à un outil de création par IA, vous décrivez les deux moitiés à la fois, que vous le vouliez ou non. « Les clients peuvent réserver un créneau » signifie un formulaire de réservation (frontend), des règles sur les créneaux libres (backend) et un endroit où enregistrer les réservations (base de données).
Connaître cette séparation aide de trois façons concrètes :
- La sécurité. Tout ce qui se trouve dans le frontend peut être vu et modifié par l'utilisateur. Les règles et les secrets doivent se trouver dans le backend.
- Le débogage. « Le bouton ne répond pas » et « le bouton répond, mais rien n'est enregistré » pointent vers des moitiés différentes. Dire ce que vous observez aide l'IA à trouver la cause plus vite.
- L'hébergement et les coûts. Un site uniquement frontend est peu coûteux et simple à héberger. Un backend doit tourner quelque part, ce qui influe sur ce que vous payez et sur le comportement de votre application quand elle est inactive.
Une analogie du quotidien
Pensez à un restaurant.
Le frontend, c'est la salle à manger : le menu, les tables, la décoration, le serveur qui prend votre commande. Elle est conçue pour les clients, qui peuvent tout voir et tout toucher.
Le backend, ce sont la cuisine et le bureau : les cuisiniers qui préparent les plats, la réserve, la caisse, les règles du gérant sur les rabais. Les clients n'y entrent jamais, et ils ne devraient pas pouvoir y entrer.
L'API, c'est le passe-plat entre les deux : le comptoir où les commandes entrent et où les assiettes sortent, dans un format convenu. La base de données, c'est la réserve et le carnet de commandes.
Un client peut réécrire son bon de commande (le frontend est sous son contrôle), mais la cuisine décide toujours de ce qu'elle prépare et de ce qu'elle facture. C'est pourquoi les vérifications importantes doivent se faire à l'arrière.
Le rôle de chaque partie
| Frontend | Backend | |
|---|---|---|
| S'exécute sur | L'appareil de l'utilisateur, dans le navigateur | Un serveur que vous (ou votre hébergeur) contrôlez |
| Rôle principal | Afficher, recueillir les saisies, réagir aux clics | Stocker les données, appliquer les règles, gérer les permissions, appeler d'autres services |
| Les utilisateurs peuvent-ils voir et modifier le code? | Oui : il est téléchargé dans leur navigateur | Non |
| Peut-il contenir des clés API secrètes? | Non | Oui, dans des variables d'environnement |
| Technologies courantes | HTML, CSS, JavaScript/TypeScript, React, Vue, Svelte, Tailwind | Node.js, Python (FastAPI, Django), C#, Java, Go, Ruby |
| Ce qui peut mal tourner | Mise en page cassée sur mobile, bouton inactif, page lente | Données non enregistrées, mauvaises données affichées, erreurs, failles de sécurité |
Certains cadres brouillent la frontière. Next.js, par exemple, permet à un même projet de contenir du code de navigateur et du code serveur. L'idée reste la même : la question est toujours où ce morceau s'exécute-t-il?
Exemple concret : réserver un cours
Voici ce qui se passe quand quelqu'un réserve un cours de yoga, étape par étape.
| Étape | Où | Ce qui se passe |
|---|---|---|
| 1 | Frontend | La page de l'horaire se charge et demande au backend les cours de la semaine. |
| 2 | Backend | Lit les cours et les réservations dans la base de données, calcule les places restantes et renvoie la liste en JSON. |
| 3 | Frontend | Affiche chaque cours avec l'heure, l'enseignant et les places restantes. |
| 4 | Frontend | L'utilisateur choisit un cours et saisit son nom et son courriel. Le formulaire vérifie que le courriel semble valide (une simple courtoisie, pas une garantie). |
| 5 | Frontend vers Backend | Envoie une requête POST /api/bookings par l'API. |
| 6 | Backend | Valide de nouveau les données, vérifie que le cours n'est pas complet, enregistre la réservation et demande au service de courriel d'envoyer une confirmation à l'aide d'une clé secrète. |
| 7 | Backend vers Frontend | Renvoie « réservé » ou « désolé, c'est complet ». |
| 8 | Frontend | Affiche l'écran de confirmation. |
Remarquez les étapes 4 et 6 : les données sont vérifiées deux fois. La vérification du frontend donne une réponse immédiate; celle du backend est la seule qui compte vraiment, parce qu'un utilisateur déterminé peut contourner complètement le frontend.
Termes courants expliqués
| Terme | Signification |
|---|---|
| Client / serveur | Le client est le navigateur (ou l'application) qui envoie les requêtes; le serveur y répond. |
| UI | Interface utilisateur : les écrans et les commandes. |
| API | La façon convenue pour le frontend de demander au backend des données ou des actions. |
| Point de terminaison (endpoint) | Une adresse précise de l'API, comme /api/bookings. |
| Full stack | Frontend, backend et base de données ensemble. Voir ce qu'est une application full stack. |
| Site statique | Un frontend sans backend propre; les mêmes fichiers pour tout le monde. |
| SPA | Application à page unique : un frontend qui met à jour la page dans le navigateur au lieu de charger de nouvelles pages. |
| Rendu côté serveur (SSR) | Le serveur construit le HTML de la page avant de l'envoyer, ce qui peut améliorer la vitesse et le référencement. |
| Variables d'environnement | Réglages et secrets fournis au backend à l'exécution, gardés hors du code. |
Votre application a-t-elle besoin d'un backend?
| Si votre application… | Backend nécessaire? |
|---|---|
| Affiche des informations identiques pour tout le monde | Non |
| Comporte un formulaire de contact qui ne fait que vous envoyer un courriel | Généralement un petit backend, ou un service de formulaires |
| Enregistre des données que d'autres verront | Oui |
| Comporte des connexions et des données privées | Oui |
| Accepte des paiements | Oui, au minimum pour créer les paiements et recevoir les webhooks de paiement |
| Utilise une API d'IA payante ou une autre API avec une clé secrète | Oui, pour garder la clé hors du navigateur |
Erreurs courantes et idées reçues
- Mettre des clés secrètes dans le frontend. Elles deviennent visibles pour quiconque ouvre les outils de développement du navigateur. C'est l'erreur grave la plus fréquente dans les applications créées avec l'IA.
- N'appliquer les règles que dans le frontend. Cacher le bouton « supprimer » aux non-administrateurs ne protège rien : le backend doit refuser la requête.
- Croire que le backend est « juste la base de données ». La base de données stocke les données. Le backend décide qui peut les lire et les modifier, et comment.
- Penser que JavaScript signifie frontend. JavaScript et TypeScript tournent aussi sur les serveurs, avec Node.js.
- Blâmer la mauvaise moitié. Si la page semble correcte mais que les données sont fausses, le problème se trouve généralement dans le backend ou la base de données, et non dans le design.
- Trop construire. Un portfolio n'a pas besoin d'un backend sur mesure. En ajouter un ajoute des coûts et des pièces mobiles.
Ce qu'il faut demander à votre outil de création IA
- « Quelles parties de cette application tournent dans le navigateur et lesquelles sur le serveur? »
- « Déplace toutes les clés API dans le backend et lis-les à partir de variables d'environnement. »
- « Valide chaque formulaire sur le serveur, en plus du navigateur. »
- « Fais en sorte que seuls les administrateurs puissent supprimer des réservations, et applique cette règle dans le backend. »
- « La page semble correcte, mais les données ne sont pas enregistrées : vérifie les journaux du backend pour cette requête. »
- « C'est un simple site vitrine : garde-le uniquement en frontend, sauf si nous avons besoin d'un backend. »
Frontend et backend dans Mythex
Un nouveau projet Mythex démarre avec un frontend Vite, React, TypeScript et Tailwind, et l'agent ajoute un backend quand votre application en a besoin. Vous pouvez aussi demander une API distincte en Node, en Python (FastAPI), en C# ou en Java, qui fonctionne à côté du frontend dans le même projet. Dans l'aperçu, vous pouvez basculer entre le site et le serveur d'API, et la publication déploie les deux, avec une base de données et un stockage de fichiers ajoutés au besoin. La documentation explique les applications multiservices, le guide sur l'hébergement web indique où chaque partie s'exécute une fois en ligne, et les modèles d'applications sont un moyen rapide de voir des exemples full stack.
Questions
Quelle est la différence entre le frontend et le backend?
Le frontend est la partie d'une application qui s'exécute dans le navigateur de l'utilisateur : les pages, les boutons et les formulaires qu'il voit. Le backend s'exécute sur un serveur que l'utilisateur ne voit jamais. Il stocke les données, applique les règles d'affaires, vérifie les permissions et communique avec d'autres services.
Chaque application a-t-elle besoin d'un backend?
Non. Un site vitrine, un portfolio ou une simple page de destination peuvent être uniquement frontend. Dès qu'une application doit enregistrer des données partagées, connecter des utilisateurs, accepter des paiements ou utiliser des clés API secrètes, elle a besoin d'un backend, sous une forme ou une autre.
Le HTML, c'est du frontend ou du backend?
Le HTML, le CSS et le JavaScript qui s'exécutent dans le navigateur relèvent du frontend. Le JavaScript peut aussi tourner sur un serveur avec Node.js, auquel cas c'est du code backend. Ce n'est pas le langage qui décide, mais l'endroit où le code s'exécute.
Que signifie full stack?
Full stack désigne la maîtrise du frontend et du backend, et généralement de la base de données. Une application full stack possède ces trois parties; un développeur full stack travaille sur chacune d'elles.