Feuille de route des compétences backend engineer pour 2026

Le backend est la couche qui décide si votre produit est correct, rapide et en ligne à 3 h du matin. Cette feuille de route couvre les langages, les bases de données, les systèmes distribués et les compétences d'observabilité que les responsables du recrutement backend de 2026 examinent réellement — ainsi qu'un plan sur 12 mois pour y parvenir.

L'ingénierie backend s'est divisée en trois variantes ces dernières années : backend API/produit, plateforme/infra, et données/streaming. La majorité des recrutements concernent encore le backend API/produit — les ingénieurs qui construisent les services dont dépendent les fonctionnalités produit. Cette feuille de route se concentre sur ce volet, avec des notes complémentaires sur la manière de basculer plus tard vers la plateforme ou les données.

Qu'est-ce qu'un backend engineer en 2026

Un backend engineer est responsable des services derrière l'interface. Concrètement :

• Conçoit des API REST ou gRPC et le modèle de données qui les sous-tend.
• Écrit des services qui traitent des milliers ou des millions de requêtes, avec une gestion des erreurs et des relances raisonnée.
• Est responsable du schéma de base de données, des migrations, des requêtes lentes et des index.
• Met en place l'authentification, la limitation de débit, l'observabilité et les workers en arrière-plan.
• Assure l'astreinte du service dont il a la charge. À partir du niveau mid.

Backend junior : livre des endpoints à partir d'un template, écrit des tests, fait passer ses PR en review. Mid : conçoit l'API d'une nouvelle fonctionnalité avec un accompagnement minimal. Senior : prend en charge un service de bout en bout, y compris ses modes de dégradation et son plan de capacité.

Stack de base — ce qu'il faut réellement apprendre

Compétences transverses et pensée systémique

• Empathie dans la conception d'API. Les bons backend engineers conçoivent des API que les frontend engineers aiment utiliser. Un aller-retour pour une action utilisateur.
• Pensée par le modèle de données. Commencez par le modèle de données, pas par les endpoints. Le schéma est le contrat le plus difficile à changer.
• Conscience des modes de défaillance. Avant de livrer une fonctionnalité, listez les trois façons dont elle échouera en production et ce qui se passe alors.
• Articulation des compromis. Cohérence forte vs disponibilité, synchrone vs asynchrone, BDD unique vs distribuée. Nommez le compromis que vous faites, à chaque fois.
• Honnêteté des post-mortems. Les pannes sont systémiques. « Erreur de l'opérateur » est une cause racine qui signifie « nous n'avons pas encore trouvé la cause racine ».

Plan suggéré sur 3 / 6 / 12 mois

Mois 1–3 : langage + HTTP + SQL

• Choisissez un langage et un framework. Construisez une API CRUD avec authentification et tests.
• Apprenez le SQL correctement. Lisez 10 plans EXPLAIN ANALYZE. Ajoutez les index manquants.
• Conteneurisez tout dans Docker dès le premier jour.

Mois 4–6 : un vrai service

• Construisez un service de type production : authentification, base de données, worker en arrière-plan, déployé, avec Sentry et Prometheus branchés.
• Ajoutez des tests sérieux — pytest/Vitest plus au moins un test d'intégration avec testcontainers.
• Lisez « Designing Data-Intensive Applications » (toujours le texte de référence).
• Commencez à instrumenter votre service : logs structurés, métriques de base, un tableau de bord Grafana.

Mois 7–12 : profondeur et entretiens

• Prenez l'un de vos endpoints et optimisez-le. Documentez le p95 avant et après avec un profiler.
• Ajoutez une file d'attente et un worker. Apprenez ce qui se passe quand le worker crashe au milieu d'un job.
• Entraînez-vous au system design : concevez un raccourcisseur d'URL, un système de paiements, un fil d'actualité. Commencez par les exigences fonctionnelles + non fonctionnelles.
• Postulez avec un portfolio qui inclut un service déployé avec des tableaux de bord.

Projets personnels à construire

• Un service de type paiements. Idempotence, transactional outbox, livraison de webhooks avec relances. Démontre l'obsession de la justesse.
• Un endpoint d'ingestion à haut débit. Accepter des événements, les regrouper en lots, écrire dans ClickHouse ou Postgres. Démontre la pensée en débit.
• Un petit SaaS avec authentification et Stripe (ou Paddle). De bout en bout : inscription, plans, webhooks, tableau de bord. Montre que vous savez livrer un vrai produit.
• Une passerelle IA. Backend qui diffuse les réponses de LLM, gère les limites de débit et les relances entre fournisseurs, met en cache les prompts identiques.

Les compétences PostgreSQL qui distinguent le mid du senior

La plupart des backend engineers cessent d'apprendre PostgreSQL après « SELECT, JOIN, INDEX ». L'écart mid-senior se situe dans la couche en dessous.

• Lire les plans EXPLAIN ANALYZE. Reconnaître seq scan vs index scan vs index-only scan, repérer la mauvaise estimation de lignes qui tue la performance, savoir quand lancer ANALYZE.
• Choisir le bon index. B-tree pour l'égalité et les plages, GIN pour le full-text et JSONB, BRIN pour les tables de séries temporelles, index partiels pour les données déséquilibrées, index sur expression pour les recherches normalisées.
• Comprendre MVCC. Pourquoi une table avec beaucoup de suppressions gonfle, quand exécuter VACUUM, comment les transactions longues bloquent l'autovacuum, pourquoi SELECT FOR UPDATE est dangereux sur les chemins à haut débit.
• Niveaux d'isolation en production. Read committed est la valeur par défaut. Repeatable read pour la cohérence inter-lignes. Serializable quand vous en avez besoin — et la boucle de relance qui l'accompagne.
• Utiliser JSONB correctement. Chemins JSON indexés pour les charges majoritairement en lecture, tables normalisées pour celles majoritairement en écriture. Ne mettez pas tout dans JSONB « pour la flexibilité » — vous le regretterez à l'échelle.
• Pooling de connexions. PgBouncer ou RDS Proxy en mode transaction, les pièges avec les prepared statements, pourquoi votre application ne devrait pas ouvrir une connexion par requête.
• Des sauvegardes que vous pouvez réellement restaurer. Une sauvegarde que vous n'avez jamais restaurée est un espoir, pas une sauvegarde.

En entretien, « j'ai fait passer une requête critique de 800 ms à 12 ms en remplaçant un index GIN JSONB manquant par un B-tree partiel sur la même expression » est le genre de réponse qui ferme les boucles senior.

Comment décrocher le poste de backend

• Mots-clés du CV. Votre langage principal, le framework, PostgreSQL, Redis, Kafka le cas échéant, Docker, Kubernetes le cas échéant, un cloud, les outils d'observabilité.
• Un lien vers un service déployé. Les candidats backend avec un service public fonctionnel se démarquent de ceux qui n'ont que des captures d'écran.
• Manches d'entretien : coding (algorithmique ou pratique), conception d'API, manche SQL/base de données, system design, comportemental. Entraînez-vous aux cinq.
• La manche SQL. De nombreuses boucles backend incluent 30 à 60 minutes de SQL. Entraînez-vous aux fonctions de fenêtrage, aux jointures et à la lecture d'EXPLAIN.
• System design. 1 à 2 manches pour le niveau mid/senior. Entraînez-vous à 15+ designs à voix haute. Ayez une structure : exigences → API → modèle de données → architecture → mise à l'échelle → compromis.

FAQ