Qu'est-ce qu'un backend ? Le côté serveur d'une application, expliqué

Un backend est un système côté serveur : le code, la base de données et l’infrastructure qui traitent les requêtes d’une app et stockent ses données. Tout logiciel qui a des utilisateurs a deux moitiés. Celle qu’ils voient et touchent — écrans, boutons, formulaires — est le frontend.

Celle qu’ils ne voient jamais, celle qui décide de ce que les boutons ont le droit de faire et se souvient de ce qui s’est passé une fois l’app fermée, est le backend. La vieille analogie du mécanicien tient toujours : le conducteur manie le tableau de bord, le mécanicien s’occupe du moteur.

Cette entrée parle du moteur.

Points clés

Une requête, de bout en bout

La façon la plus claire de voir un backend est de regarder une requête le traverser. Un utilisateur touche « afficher mes tâches en cours » ; voici ce qui se passe de l’autre côté de l’API :

GET /classes/Todo?where={"done":false} HTTP/1.1    ← le frontend demande
Authorization: Bearer eyJhbGci…                     ← qui demande

  backend ─┬─ couche API       parser la requête, vérifier le token
           ├─ autorisation     cet utilisateur peut-il lire ces lignes ?
           ├─ logique métier   appliquer les règles (seules les tâches de l'appelant)
           ├─ couche données   interroger la base, mettre en forme le résultat
           └─ réponse          200 OK + JSON, en moins de 100 ms

{ "results": [ { "objectId": "xKd91m", "title": "Ship the release", "done": false } ] }

La même conversation vue du côté du frontend, à travers un SDK qui la réduit à une ligne par plateforme :

// JavaScript / Node.js — Back4app JS SDK
// The frontend asks the backend a question; the backend answers from the database
const query = new Parse.Query('Todo');
query.equalTo('done', false);
const open = await query.find();
// Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
console.log(`${open.length} open todos`);

// Flutter / Dart — Back4app Flutter SDK
// The frontend asks the backend a question; the backend answers from the database
final query = QueryBuilder<ParseObject>(ParseObject('Todo'))
  ..whereEqualTo('done', false);
final response = await query.query();
// Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
print('${response.results?.length ?? 0} open todos');

// iOS / Swift — Back4app Swift SDK
// The frontend asks the backend a question; the backend answers from the database
let query = Todo.query("done" == false)
query.find { result in
    // Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
    if case .success(let open) = result { print("\(open.count) open todos") }
}

// Android / Kotlin — Back4app Android SDK
// The frontend asks the backend a question; the backend answers from the database
val query = ParseQuery.getQuery<ParseObject>("Todo")
query.whereEqualTo("done", false)
query.findInBackground { open, e ->
    // Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
    if (e == null) println("${open.size} open todos")
}

Frontend vs. backend

La distinction la plus recherchée, en un tableau :

Cette dernière ligne est celle qui compte pour la sécurité : tout ce qui se trouve dans le frontend peut être lu et modifié par l’utilisateur. C’est pourquoi la validation, les permissions et les secrets appartiennent au backend, et pourquoi chaque appel d’API est traité comme non fiable tant que le serveur ne l’a pas vérifié.

Côté client et côté serveur

Ces deux termes ne désignent pas deux sortes de backend ; ce sont les deux extrémités de chaque requête. Le côté client, c’est tout code qui s’exécute sur l’appareil de l’utilisateur — afficher l’interface, conserver un état temporaire, envoyer des requêtes.

Le côté serveur, c’est tout code qui s’exécute sur des machines que l’utilisateur ne peut pas atteindre — recevoir ces requêtes, exécuter la vraie logique, lire et écrire la base de données, et répondre. « Backend » et « côté serveur » s’emploient indifféremment pour cette seconde moitié, et cette entrée fait de même.

De quoi un backend est fait

La présentation classique appelle le frontend la couche de présentation et le backend la couche d’accès aux données, et décrit le backend comme trois choses qui travaillent ensemble : les ressources matérielles, le logiciel qui tourne dessus et l’infrastructure réseau entre elles et l’utilisateur.

C’est toujours vrai, mais il est plus utile de lire un backend comme un empilement de responsabilités, dont la plupart existent dans chaque produit quelle que soit sa taille :

• Couche API — le contrat public : des endpoints REST ou GraphQL que le frontend et d’autres systèmes appellent.
• Logique métier — les règles qui font du produit ce qu’il est : ce qu’est une commande valide, qui peut approuver quoi, comment un score se calcule.
• Couche de données — la base de données et le code qui la modélise, l’interroge et la migre.
• Authentification et autorisation — qui est l’appelant et ce qu’il a le droit de faire, appliqué à chaque requête.
• Travail en arrière-plan — des jobs et des planifications pour tout ce qui ne doit pas bloquer une requête : e-mails, rapports, synchronisations, nettoyages.
• Infrastructure — les serveurs, conteneurs ou fonctions sur lesquels tout cela tourne, plus le déploiement, la journalisation, le monitoring, les sauvegardes et la mise à l’échelle.

Les cinq premières relèvent du produit. La sixième relève des opérations, et c’est la part que les modèles d’hébergement modernes existent pour supprimer.

Les architectures backend

La version originale de ce sujet décrivait trois familles — serverless, orientée serveur et décentralisée — et la taxonomie tient toujours. Ce qui a changé, c’est le choix par défaut : en 2026, la famille serverless est celle où démarrent la plupart des nouveaux produits, et « orientée serveur » désigne de plus en plus des conteneurs plutôt que des machines.

Backends sur serveurs (server-based). Votre équipe provisionne des machines, des machines virtuelles ou des conteneurs, installe un runtime et une base de données, et les exploite. Contrôle maximal, responsabilité maximale : la capacité, les correctifs, la disponibilité et l’astreinte sont à vous.

Les arguments classiques en sa faveur restent valables — un endroit unique qui partage les données entre plusieurs applications, des intégrations directes, un seul point d’accès à sécuriser — et la forme à l’intérieur peut être un monolithe ou des microservices ; le modèle d’exploitation est le même.

Backends serverless. Un fournisseur fait tourner l’infrastructure et facture à l’usage. Deux variantes : le Function as a Service, où vous déployez du code sur mesure sous forme de fonctions qui montent en charge depuis zéro, et le Backend as a Service, où la base de données, l’auth, les API, le stockage et les fonctions arrivent sous forme de plateforme gérée.

Le gain, c’est la vitesse — aucun serveur à monter avant la première feature — et la contrepartie, c’est le contrôle sur les couches les plus basses. L’échelle complète des modèles d’hébergement est comparée dans IaaS vs. PaaS vs. BaaS vs. FaaS.

Backends décentralisés. Aucun opérateur unique ; l’état vit sur un réseau pair-à-pair, généralement open-source, comme dans les blockchains et le stockage adressé par contenu. Bitcoin et Ethereum en sont les exemples canoniques, et le frontend d’une telle app est souvent hébergé de la même manière, sur des réseaux comme IPFS ou Swarm plutôt que sur un serveur.

Résistance à la censure et aucun point de contrôle central, au prix de la latence, du débit et d’un modèle de programmation très différent. Une niche avec de vrais usages, pas un remplacement généraliste des deux autres.

Sur serveurs vs. serverless vs. BaaS vs. décentralisé

Cas d’usage courants

• Apps mobiles et web — comptes, données qui survivent à la session et synchronisation entre appareils ont tous besoin d’un côté serveur.
• Produits multi-utilisateurs — tout cas où l’action d’un utilisateur doit être vue par un autre : collaboration, places de marché, chat.
• Paiements et opérations sensibles — les secrets et l’argent n’ont rien à faire sur l’appareil ; le backend détient les clés et dialogue avec les fournisseurs.
• Intégrations et automatisation — webhooks, jobs planifiés et pipelines qui tournent qu’un utilisateur soit en ligne ou non.
• Fonctionnalités d’IA — appels de modèles, récupération et exécution d’outils tournent côté serveur, où les clés restent privées et où les résultats peuvent être mis en cache et audités.

Quelle approche backend devriez-vous choisir ? Matrice de décision

Limites et trade-offs

• Le backend est l’endroit où les erreurs deviennent le problème de tous. Un bug frontend casse un écran ; un bug backend corrompt des données ou les expose. La validation, les permissions et les tests pèsent plus lourd ici que partout ailleurs dans la base de code.
• Les opérations ne disparaissent jamais — elles se déplacent. Les plateformes gérées absorbent les serveurs, la mise à l’échelle et les sauvegardes, mais quelqu’un reste propriétaire du modèle de données, des règles d’accès et du budget. Choisissez un modèle pour les responsabilités que vous voulez garder, pas pour celles que vous voulez oublier.
• Contrôle et vitesse tirent dans des directions opposées. Plus vous faites tourner de couches du stack vous-même, plus vous pouvez personnaliser et plus tout prend de temps ; moins vous en faites tourner, plus vite vous livrez et plus vous dépendez de la feuille de route et du pricing d’un fournisseur.
• Le réseau fait partie du contrat. Chaque appel du frontend au backend peut être lent, échouer à mi-chemin ou arriver deux fois ; budgets de latence, retries et idempotence sont des préoccupations backend dès le premier endpoint.
• « Serverless » a toujours des serveurs. Cold starts, limites d’exécution et facturation à l’usage sont de vraies contraintes ; ce sont simplement les machines de quelqu’un d’autre, avec une courbe de coût différente.

Le backend sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code.

Projeté sur les couches ci-dessus : la couche de données et la couche API sont générées à partir de votre modèle de données, l’authentification et les permissions au niveau de la classe font respecter qui peut faire quoi à chaque requête, Cloud Code héberge la logique métier et les jobs en arrière-plan propres à votre produit, et la couche d’infrastructure — hébergement, mise à l’échelle, sauvegardes, monitoring — est le travail de la plateforme.

La requête disséquée en haut de cette page est le vrai format échangé par Back4app sur le réseau, et les SDK qui l’ont envoyée sont la façon dont le frontend parle à ce backend depuis chaque grande plateforme.