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, boutons, formulaires et 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 métier, vérifie qui a le droit de faire quoi, et communique avec d'autres services comme les paiements et l'e-mail. Les deux échangent via une API et, avec une base de données, 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 réalisiez 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 répartition aide de trois façons concrètes :
- 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.
- Débogage. « Le bouton ne répond pas » et « le bouton répond mais rien n'est enregistré » pointent vers deux moitiés différentes. Dire laquelle vous observez aide l'IA à trouver plus vite la cause.
- Hébergement et coût. Un site purement frontend est peu coûteux et simple à héberger. Un backend doit tourner quelque part, ce qui influence ce que vous payez et le comportement de votre application quand elle est inactive.
Une analogie du quotidien
Pensez à un restaurant.
Le frontend, c'est la salle : la carte, les tables, la décoration, le serveur qui prend la commande. Elle est conçue pour les clients, qui voient et touchent tout ce qui s'y trouve.
Le backend, ce sont la cuisine et le bureau : les cuisiniers, le stock, la caisse, les règles du gérant sur les remises. Les clients n'y entrent jamais, et ils ne doivent pas pouvoir y entrer.
L'API, c'est le passe-plat entre les deux : le comptoir où les commandes entrent et les plats 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 contrôles importants doivent se faire côté arrière.
Ce que fait chaque côté
| 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 autorisations, 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 sans effet, page lente | Données non enregistrées, données erronées affichées, erreurs, failles de sécurité |
Certains frameworks brouillent la frontière. Next.js, par exemple, permet à un même projet de contenir du code de navigateur et du code serveur. Le principe reste le même : la question est toujours où s'exécute cette partie ?
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 du planning 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'horaire, le professeur et les places restantes. |
| 4 | Frontend | L'utilisateur choisit un cours et saisit son nom et son e-mail. Le formulaire vérifie que l'e-mail semble valide (une simple aide, pas une garantie). |
| 5 | Frontend → Backend | Envoie une requête POST /api/bookings via 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 d'e-mail d'envoyer une confirmation à l'aide d'une clé secrète. |
| 7 | Backend → Frontend | Renvoie « réservé » ou « désolé, c'est complet ». |
| 8 | Frontend | Affiche l'écran de confirmation. |
Remarquez les étapes 4 et 6 : la saisie est vérifiée deux fois. La vérification côté frontend donne un retour immédiat ; celle du backend est la seule qui compte vraiment, car 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 fait les requêtes ; le serveur y répond. |
| UI | Interface utilisateur : les écrans et les contrôles. |
| API | La manière convenue dont le frontend demande des données ou des actions au backend. |
| Endpoint | Une URL précise de l'API, comme /api/bookings. |
| Full stack | Frontend + backend + base de données réunis. 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 monopage : 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 |
| Propose un formulaire de contact qui ne fait qu'envoyer un e-mail | En général un petit backend, ou un service de formulaires |
| Enregistre des données que d'autres vont voir | Oui |
| Propose des connexions et des données privées | Oui |
| Encaisse des paiements | Oui, au minimum pour créer les paiements et recevoir les webhooks de paiement |
| Utilise une API d'IA ou une autre API payante 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 seront visibles par 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. Masquer le bouton « supprimer » pour les non-administrateurs n'est pas une protection ; le backend doit refuser la requête.
- Croire que le backend se résume à la base de données. La base 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.
- Accuser la mauvaise moitié. Si la page semble correcte mais que les données sont fausses, le problème vient en général du backend ou de la base, pas du 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 par IA
- « Quelles parties de cette application s'exécutent dans le navigateur et lesquelles sur le serveur ? »
- « Déplace toutes les clés API vers le backend et lis-les depuis des variables d'environnement. »
- « Valide chaque formulaire côté serveur, en plus du navigateur. »
- « Impose côté backend que seuls les administrateurs puissent supprimer des réservations. »
- « 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 lorsque votre application en a besoin. Vous pouvez aussi demander une API séparée en Node, Python (FastAPI), C# ou Java, qui fonctionne aux côtés du frontend dans le même projet. Dans l'aperçu, vous pouvez passer du site au serveur API, et la publication déploie les deux, avec une base de données et un stockage de fichiers ajoutés si nécessaire. La documentation présente les applications multi-services, le guide hébergement web explique où tourne chaque moitié 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 frontend et backend ?
Le frontend est la partie d'une application qui s'exécute dans le navigateur de l'utilisateur : les pages, boutons et formulaires qu'il voit. Le backend tourne sur un serveur que l'utilisateur ne voit jamais ; il stocke les données, applique les règles métier, vérifie les autorisations et communique avec d'autres services.
Toute application a-t-elle besoin d'un backend ?
Non. Un site vitrine, un portfolio ou une simple page d'accueil peuvent être uniquement frontend. Dès qu'une application doit enregistrer des données partagées, connecter des utilisateurs, encaisser des paiements ou utiliser des clés API secrètes, elle a besoin d'un backend, quel qu'il soit.
HTML, c'est du frontend ou du backend ?
Le HTML, le CSS et le JavaScript exécutés 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 le fait de couvrir à la fois le frontend et le backend (et généralement la base de données). Une application full stack comprend ces trois parties ; un développeur full stack travaille sur chacune d'elles.