Exposer une API REST, la brancher sur PostgreSQL, MySQL ou Oracle, ajouter un cache Redis, confier les traitements longs à une file de messages et livrer le tout en conteneur par une CI : les offres de développeur back-end, ou d'ingénieur études et développement, décrivent souvent ce même travail. Des questions d'entretien pour un développeur back-end doivent vérifier ces gestes, quel que soit le langage demandé.
Les CV mettent un framework en avant : Spring Boot, Django, Symfony, NestJS ou ASP.NET Core. On peut bien le connaître sans avoir jamais lu un plan d'exécution SQL, géré deux requêtes qui modifient la même ligne ou traité un message reçu deux fois. Ce sont pourtant ces cas qui cassent en production. Faites écrire du code dans le langage du poste, et gardez des sujets indépendants du framework pour juger le raisonnement.
Pour un junior, attendez des bases propres en HTTP, en SQL et en tests. À partir du niveau confirmé, la personne parle d'index, de transactions, d'idempotence et de logs lus pendant un incident réel. Le PDF contient 30 questions sur six axes, un cas de 20 minutes et une grille de 1 à 4.
Les briques techniques qu'un développeur back-end assemble
API REST et OpenAPI
La porte d'entrée du back-end : des URL qui représentent des ressources, des méthodes HTTP et des codes de retour. Le contrat est décrit dans un fichier OpenAPI, qui sert de documentation aux équipes front et partenaires. Certaines équipes ajoutent GraphQL ou gRPC, mais REST reste le format le plus courant.
Bases relationnelles (PostgreSQL, MySQL, Oracle, SQL Server)
Les données métier vivent presque toujours dans une base SQL. Le développeur back-end écrit les requêtes, crée les index et gère les transactions. Une bonne partie des lenteurs et des incohérences de données se règle à cet endroit, c'est donc le premier sujet technique à creuser.
ORM (Hibernate, Doctrine, Entity Framework, SQLAlchemy, Prisma)
La couche qui transforme les tables en objets du langage. Elle fait gagner du temps et cache aussi les requêtes réellement envoyées. Un profil solide sait lire ce que l'ORM génère et repasser au SQL quand c'est nécessaire.
Redis et cache
Redis garde en mémoire des données lues souvent : sessions, fiches produits, compteurs, limites de débit. Le cache accélère les réponses et pose une question simple à poser en entretien : comment la donnée en cache reste-t-elle à jour ?
Files de messages (RabbitMQ, Kafka, SQS)
Elles servent à sortir de la requête HTTP les traitements longs ou fragiles : envoi d'e-mails, génération de PDF, synchronisation avec un autre système. Un message peut arriver deux fois ou dans le désordre, et le code qui le traite doit le supporter.
OAuth 2.0, OpenID Connect et JWT
Les standards de connexion et de délégation d'accès. L'utilisateur se connecte chez un fournisseur d'identité (Keycloak, Microsoft Entra ID, Auth0, Okta), l'API reçoit un jeton et doit le vérifier. Le contrôle des droits sur chaque ressource reste du ressort du développeur back-end.
Tests et Testcontainers
Tests unitaires pour les règles métier, tests d'intégration pour la base, la sérialisation et la sécurité. Testcontainers lance une vraie base PostgreSQL ou un vrai Kafka dans un conteneur le temps des tests, ce qui évite les écarts entre une base de test simplifiée et la production.
Docker et CI/CD
Le service est empaqueté en image Docker, construit et testé par une chaîne d'intégration continue (GitLab CI, GitHub Actions, Jenkins), puis déployé sur Kubernetes ou une plateforme managée. On attend du développeur qu'il sache écrire un Dockerfile correct et lire un pipeline en échec.
Observabilité (OpenTelemetry, Prometheus, logs structurés)
Logs, métriques et traces permettent de savoir ce qui se passe en production. OpenTelemetry est devenu le standard pour instrumenter un service et suivre une requête d'un service à l'autre. Demandez comment la personne a trouvé la cause de son dernier incident.
Le poste change surtout avec la taille de l'équipe et l'architecture. Dans une petite équipe, le développeur back-end gère aussi la base, le déploiement et une partie de l'exploitation. Dans une organisation plus grande, une équipe plateforme fournit la CI, Kubernetes et l'observabilité, et le développeur se concentre sur le code métier et les API. Un monolithe demande surtout de la rigueur sur les modules et la base partagée. Des microservices ajoutent les appels réseau, les messages et les données réparties. Le langage (Java, Python, PHP, Node.js, C#, Go) se juge dans un second temps, sur un exercice de code. Les fondamentaux du métier, eux, se vérifient en entretien.
Six compétences back-end à couvrir, quel que soit le langage
- Conception d'API HTTP
- SQL, index et transactions
- Concurrence et idempotence
- Sécurité des API et authentification
- Cache et messagerie asynchrone
- Tests, déploiement et observabilité
Cinq situations de production à soumettre au développeur back-end
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Une page qui liste les commandes d'un client met trois secondes à répondre. Comment trouvez-vous la cause ?
Une bonne réponseIl mesure d'abord où passe le temps : la requête SQL, le code ou un appel externe. Côté base, il lance un EXPLAIN ANALYZE (ou l'équivalent du moteur) et cherche un parcours complet de table, un tri en mémoire ou un index absent sur la colonne client. Il pense aussi à l'ORM qui envoie une requête par ligne pour charger les produits, et à une pagination absente qui ramène tout l'historique. Il corrige une cause à la fois et mesure de nouveau.
Signal d'alerte« J'ajoute un cache » ou « on met un plus gros serveur » avant d'avoir regardé le plan d'exécution. Un index posé sur chaque colonne de la table.
Question 2 · confirmé
Deux utilisateurs réservent la dernière place disponible au même moment. Comment garantissez-vous qu'une seule réservation passe ?
Une bonne réponseC'est la base qui doit garantir qu'une seule écriture passe. Plusieurs réponses tiennent : un UPDATE conditionnel atomique (décrémenter seulement si le stock est positif, puis vérifier le nombre de lignes modifiées), un verrou de ligne avec SELECT ... FOR UPDATE dans une transaction courte, une contrainte d'unicité sur le couple place et créneau, ou un verrouillage optimiste avec une colonne de version. Il explique ce que voit le second utilisateur : un refus clair (409), plutôt qu'une erreur 500.
Signal d'alerteLire le stock, tester en Java ou en Python s'il reste une place, puis écrire : deux requêtes simultanées passent le test toutes les deux. Ou un verrou en mémoire qui ne protège rien dès qu'il y a deux instances du service.
Question 3 · confirmé
Le réseau d'un client mobile coupe pendant un paiement, et l'application renvoie la même requête. Comment évitez-vous le double débit ?
Une bonne réponseUne clé d'idempotence envoyée par le client dans un en-tête, enregistrée côté serveur avec le résultat de la première requête. Une seconde requête avec la même clé reçoit la même réponse sans nouveau traitement. La clé est stockée avec une contrainte d'unicité pour résister à deux requêtes simultanées, et elle expire après un délai. Il cite souvent les API de paiement du marché, qui fonctionnent de cette façon.
Signal d'alerte« Le client ne doit pas renvoyer la requête », ou un contrôle sur le montant et la date qui bloquerait deux achats légitimes identiques.
Question 4 · confirmé à senior
Vous devez retirer un champ d'une API utilisée par trois applications que vous ne maintenez pas. Comment procédez-vous ?
Une bonne réponseIl distingue les changements compatibles (ajouter un champ optionnel) de ceux qui cassent (retirer, renommer, changer un type). Pour un retrait : marquer le champ comme déprécié dans le contrat OpenAPI, prévenir les équipes avec une date, mesurer dans les logs ou les métriques qui l'utilise encore, puis le retirer dans une nouvelle version de l'API si des clients en dépendent. Il connaît les options de versioning (dans l'URL, dans un en-tête) et leurs limites.
Signal d'alerteRetirer le champ et attendre les tickets. Ou créer une version complète de l'API à chaque modification, même compatible.
Question 5 · confirmé
Votre API reçoit un jeton JWT dans l'en-tête Authorization. Que vérifiez-vous avant de faire confiance à son contenu ?
Une bonne réponseLa signature, avec un algorithme attendu fixé côté serveur (pas celui annoncé dans le jeton) et une clé publique récupérée chez le fournisseur d'identité via son JWKS, avec gestion de la rotation des clés. Puis l'émetteur (iss), le destinataire (aud) et la date d'expiration (exp). Ensuite seulement les droits : le jeton dit qui appelle, le code vérifie à chaque requête que cette personne a le droit sur la ressource demandée. Il sait qu'un JWT est lisible par tous et ne doit pas contenir de données sensibles.
Signal d'alerteDécoder le jeton et lire le rôle sans vérifier la signature. Croire qu'un JWT est chiffré. Accepter l'algorithme « none ».
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Recrutement d'un développeur back-end : vos questions
Un développeur back-end doit-il connaître le langage exact de l'offre ?
Pour un poste confirmé ou senior, oui, au moins dans sa version récente et avec son framework principal, car la montée en compétence sur un nouvel écosystème prend du temps. Pour un junior, un bon niveau dans un langage proche se transpose assez vite. Les fondamentaux, eux, ne dépendent pas du langage : HTTP, SQL, transactions, sécurité des API, tests. Un candidat solide sur ces sujets et faible sur un framework se forme plus facilement que l'inverse.
Quelles attentes fixer pour un junior et pour un senior back-end ?
Un junior doit écrire une API propre, des requêtes SQL justes et des tests, et savoir dire ce qu'il ne connaît pas. Un confirmé explique un plan d'exécution, gère la concurrence et a déjà diagnostiqué un incident. Un senior arbitre entre des architectures, conçoit des migrations sans coupure, prépare un service à la charge et relit le code des autres. Posez les mêmes thèmes à tous et notez la profondeur de la réponse sur une grille commune.
Exercice à la maison ou en direct pour un poste back-end ?
Un test technique à la maison de plusieurs heures fait fuir les bons profils en poste et se fait de plus en plus avec un assistant de code. Un exercice d'une heure en direct dit souvent plus : écrire un endpoint avec sa validation et son test, corriger une requête lente, ou relire une pull request qui contient une faille. Demandez à la personne de commenter ses choix au fur et à mesure.
Où s'arrête le back-end et où commence le travail DevOps ?
Le développeur back-end livre un service qui se déploie et s'observe : un Dockerfile correct, une configuration par variables d'environnement, des sondes de santé, des logs et des métriques utiles. L'ingénieur DevOps ou l'équipe plateforme construit la chaîne autour : clusters, réseau, pipelines partagés, supervision commune. La frontière varie selon les équipes. Précisez-la dans l'offre et posez les questions d'exploitation qui correspondent au périmètre réel du poste.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
