Backend : tout ce qui se passe derrière le rideau
Ou : Pourquoi le code le plus important est celui que personne ne voit
Quand vous cliquez sur « Se connecter » sur un site web, il se passe quelque chose de visible : un spinner apparaît, puis vous êtes redirigé vers votre tableau de bord. Ce que vous ne voyez pas : votre mot de passe est envoyé au serveur via HTTPS, hashé avec bcrypt, comparé à un hash stocké en base de données, un token JWT est généré, une session est créée, vos préférences sont chargées, et la réponse est renvoyée — le tout en 200 millisecondes.
Le backend, c’est tout ça. C’est la partie serveur d’une application — la logique métier, l’accès aux données, l’authentification, les API, la sécurité. Tout ce qui se passe entre le moment où le navigateur envoie une requête et le moment où il reçoit une réponse. Le frontend est la vitrine. Le backend est l’usine.
Ce que fait réellement un développeur backend
Les composants du backend
Une application backend typique se compose de plusieurs couches :
Le serveur web — Nginx, Apache, Caddy — reçoit les requêtes HTTP et les route vers l’application. C’est le portier.
L’application — le code métier écrit en Python (Django, Flask), Go, Node.js, PHP (Laravel), Java (Spring), C# (.NET), ou un des dizaines d’autres langages et frameworks qui existent. C’est ici que vivent les règles métier : « un utilisateur ne peut pas commander plus de 5 articles en promotion », « un remboursement nécessite une approbation si le montant dépasse 100 € ».
La base de données — PostgreSQL, MySQL, MongoDB, Redis — stocke les données de façon persistante. Le choix entre SQL (relationnel) et NoSQL (document, clé-valeur, graphe) est une des premières décisions architecturales, et une des plus conséquentes.
Les services externes — passerelle de paiement (Stripe), envoi d’emails (SendGrid), stockage de fichiers (S3), services d’authentification — le backend orchestre les interactions avec des systèmes tiers.
Les architectures
Le backend n’est pas monolithique — enfin, il l’est souvent, mais il ne devrait pas l’être (ou si, selon à qui vous demandez).
| Architecture | Principe | Quand l’utiliser |
|---|---|---|
| Monolithe | Tout dans une seule application | MVP, petites équipes, complexité faible |
| Microservices | Services indépendants communiquant via API | Grandes équipes, domaines distincts, scaling indépendant |
| Serverless | Fonctions exécutées à la demande (Lambda, Cloud Functions) | Trafic imprévisible, événementiel |
| Architecture hexagonale | Logique métier isolée des dépendances externes | Applications complexes, testabilité critique |
Le monolithe est un choix parfaitement valide pour la majorité des projets. Les microservices résolvent un problème d’organisation d’équipe autant qu’un problème technique. Et le serverless est génial jusqu’au moment où votre facture AWS vous donne des sueurs froides1.
Le dialogue du déploiement raté
DevOps Dave : Le site est down.
Security Sarah : Qu’est-ce qui s’est passé ?
DevOps Dave : J’ai déployé le nouveau backend. La migration de base de données a cassé la table utilisateurs.
Security Sarah : Tu avais un rollback plan ?
DevOps Dave : … Le plan, c’était que ça marche.
Security Sarah : Le backend, c’est pas le frontend. Quand le frontend casse, l’utilisateur voit un bouton mal aligné. Quand le backend casse, les données sont corrompues, les transactions échouent, et le directeur t’appelle à 3h du matin.
Tableau récapitulatif
| Concept | En une phrase |
|---|---|
| Backend | Partie serveur qui traite les requêtes, gère les données et applique la logique métier. |
| API | Interface par laquelle le frontend communique avec le backend. |
| Base de données | Système de stockage persistant des données (SQL ou NoSQL). |
| Microservices | Architecture où le backend est découpé en services indépendants. |
| ORM | Couche d’abstraction qui permet de manipuler la BDD en code au lieu de SQL. |
Le mot de la fin
Le backend est ingrat. Quand il fonctionne, personne ne le remarque. Quand il casse, tout le monde le remarque. C’est le métier où le succès est invisible et l’échec est public.
C’est aussi le métier où les décisions prises au jour 1 vous suivent pendant des années. Le choix de la base de données, le schéma des tables, l’architecture des API — tout ça se cristallise et devient de plus en plus coûteux à changer avec le temps. Le frontend peut être réécrit en six mois. Le backend, c’est l’ADN de l’application.
Le piège classique du serverless : c’est gratuit pour les premiers millions de requêtes, donc vous ne pensez pas aux coûts. Puis votre application scale, et vous découvrez que 100 millions d’invocations Lambda par mois, ça coûte plus cher qu’un serveur dédié qui tourne 24/7. Le serverless est excellent pour le trafic sporadique. Pour le trafic constant et prévisible, un bon vieux serveur est souvent plus économique. ↩︎