Scorecard Développeur back end
Voici comment évaluer un Développeur back end en entretien : les compétences à noter, les questions à poser et les signaux d'alerte. Une grille de base, à ajuster selon votre contexte et vos priorités.
Un exemple à adapter. Cette scorecard est un modèle, pas une grille à appliquer telle quelle. Gardez les critères qui correspondent à votre poste et à votre équipe, ajustez ou retirez les autres. Le bon profil dépend de votre contexte.
Développeur back end
La mission en une phrase
Des API robustes en production
Le candidat livre des endpoints documentés, versionnés et testés, qui tiennent leurs engagements de contrat sans régression d'une version à l'autre.
Un modèle de données maîtrisé
Il choisit le bon stockage selon le besoin, structure ses schémas et écrit des requêtes efficaces, en arbitrant entre SQL et NoSQL de façon argumentée.
Une plateforme qui tient la charge
Il identifie les points de contention, instrumente ses services et met en place caching, pagination ou traitement asynchrone pour absorber la montée en charge.
Du code sûr et durable
Il intègre la sécurité dès la conception, couvre son code par des tests et laisse une base lisible que l'équipe peut reprendre sans frein.
✗ Faible · Empile des endpoints sans cohérence, ne pense ni au versionnage ni à la gestion d'erreurs, mélange logique métier et accès aux données.
✓ Excellent · Conçoit des contrats d'API clairs, gère le versionnage et les codes d'erreur, structure ses services en couches lisibles.
✗ Faible · Ignore l'indexation, génère des requêtes coûteuses, ne distingue pas les cas d'usage SQL et NoSQL au-delà des étiquettes.
✓ Excellent · Modélise des schémas adaptés, écrit des requêtes optimisées, sait quand préférer un store relationnel ou documentaire et justifie son choix.
✗ Faible · Optimise au hasard sans métrique, n'a jamais profilé un service, découvre les problèmes de charge en production.
✓ Excellent · Mesure avant d'optimiser, repère les requêtes lentes, met en place caching, pagination et traitements asynchrones quand c'est pertinent.
✗ Faible · Considère la sécurité comme un sujet d'infrastructure, fait confiance aux données entrantes, stocke des secrets en clair.
✓ Excellent · Maîtrise authentification, autorisation, validation des entrées et protection contre les injections, traite les secrets avec rigueur.
✗ Faible · Teste rarement ou seulement le chemin nominal, livre du code que personne ne souhaite reprendre, fuit la revue.
✓ Excellent · Écrit des tests unitaires et d'intégration utiles, vise une couverture pertinente plutôt que cosmétique, soigne lisibilité et revue.
✗ Faible · Reproduit un seul pattern quel que soit le contexte, ne sait pas expliquer un découpage ni ses compromis.
✓ Excellent · Sait découper en services, raisonner sur le couplage et les frontières de domaine, choisir entre synchrone et événementiel selon le besoin.
✗ Faible · Déploie sans visibilité sur le comportement réel, dépend d'un tiers pour livrer, ne consulte jamais les logs.
✓ Excellent · Instrumente logs, métriques et traces, intègre ses changements dans une chaîne d'intégration continue et suit ses services après mise en ligne.
Rigueur et sens du détail
✗ Faible · Laisse traîner des cas non gérés, néglige les retours de revue, multiplie les corrections de dernière minute.
✓ Excellent · Anticipe les cas limites, vérifie ses hypothèses, livre du travail propre dès le premier passage.
Communication technique
✗ Faible · Reste vague sur ses décisions, laisse les autres deviner ses intentions, ne documente rien.
✓ Excellent · Explique un choix d'architecture à un pair comme à un profil non technique, documente ce qui mérite de l'être.
Esprit de résolution de problèmes
✗ Faible · Corrige les symptômes au hasard, s'enlise sans cadre, ne sait pas reproduire un bug.
✓ Excellent · Décompose un incident méthodiquement, formule des hypothèses, isole la cause avant de corriger.
Collaboration et autonomie
✗ Faible · Travaille en silo ou reste bloqué sans demander d'aide, garde l'information pour lui.
✓ Excellent · Avance seul sur un sujet cadré tout en sollicitant l'équipe au bon moment, partage le contexte sans rétention.
Compétences techniques
Sur un même besoin, qu'est-ce qui vous fait pencher pour une base relationnelle plutôt qu'un store NoSQL, et inversement ?
→ Le candidat raisonne sur la nature des données, les patterns d'accès et la cohérence, sans réciter une opposition simpliste.
Quels réflexes de sécurité appliquez-vous systématiquement quand vous exposez un service côté serveur ?
→ Validation des entrées, authentification et autorisation, gestion des secrets, protection contre les injections : la sécurité doit être un réflexe, pas une option.
Comment décidez-vous quoi tester sur un service, et comment évitez-vous une couverture cosmétique ?
→ Le candidat distingue tests unitaires et d'intégration, vise les zones à risque et le comportement métier plutôt qu'un pourcentage affiché.
Réalisations & expérience
Décrivez une API que vous avez conçue de bout en bout. Comment avez-vous défini le contrat et géré son évolution dans le temps ?
→ Cherchez une démarche structurée : contrat pensé en amont, versionnage, gestion des erreurs et compatibilité ascendante, pas seulement une liste d'endpoints.
Mise en situation
Un endpoint devient lent en production. Comment procédez-vous pour comprendre et résoudre le problème ?
→ Attendez une démarche outillée : mesure, profilage, identification de la requête ou du goulot, puis correction ciblée plutôt qu'optimisation à l'aveugle.
Motivation & fit
Qu'est-ce qui vous attire dans le travail côté serveur plutôt que sur la partie visible d'une application ?
→ Cherchez un goût sincère pour la logique métier, les données et la fiabilité, pas un choix par défaut ou par évitement du front.
Savoir-être & collaboration
Racontez un désaccord technique sur une décision d'architecture. Comment l'avez-vous tranché avec l'équipe ?
→ Observez l'écoute, la capacité à argumenter sur des compromis et à se rallier à une décision collective sans rancune.
Ne sait pas expliquer comment il diagnostique un problème de performance
Sur un back end, la montée en charge est inévitable. Sans méthode de mesure, le candidat subira les incidents au lieu de les anticiper.
Traite la sécurité comme la responsabilité d'une autre équipe
La majorité des failles applicatives naissent dans le code serveur. Déléguer ce sujet expose directement les données et les utilisateurs.
Considère les tests comme une perte de temps
Sans filet de tests, chaque évolution devient risquée et le coût de maintenance explose à mesure que le service grandit.
Choisit toujours la même base de données sans pouvoir le justifier
Un choix de stockage non réfléchi se paie longtemps en performance et en dette. La capacité à arbitrer est au cœur du métier.
Livre du code que personne d'autre ne peut reprendre
Le back end est un travail d'équipe sur la durée. Un code illisible ou non documenté ralentit tout le monde et crée une dépendance fragile.
Lecture du score
Notez chaque compétence et savoir-être de 1 à 5. Repère de décision : moyenne supérieure ou égale à 4 sur les must-have et aucun red flag majeur = go ; 3 à 4 avec réserves = à challenger en second tour ; un must-have sous 3 ou un red flag majeur = no-go. Un nice-to-have faible ne doit jamais éliminer un bon profil.
Qu'est-ce qu'une scorecard pour recruter un Développeur back end ?
Une scorecard développeur back end est une grille d'évaluation structurée : elle liste les compétences et savoir-être à noter de 1 à 5, les questions d'entretien à poser et les signaux d'alerte. Elle permet de comparer les candidats sur des critères objectifs plutôt que sur une impression. On parle aussi de scorecard développeur backend, scorecard dev back, scorecard ingénieur backend.
Comment utiliser cette scorecard Développeur back end ?
Téléchargez-la en PDF, Excel ou Notion, notez chaque critère de 1 à 5 pendant l'entretien, puis additionnez les scores du panel pour décider sur des faits. La version Excel calcule la moyenne et la décision automatiquement.
Quelle différence entre un développeur back end et un développeur fullstack ?
Le développeur back end se concentre sur la partie serveur : API, logique métier, données, performance et sécurité. Le développeur fullstack couvre à la fois le serveur et l'interface visible, au prix d'une profondeur souvent moindre sur chaque versant. Pour un poste où la complexité se situe dans les données, la scalabilité ou l'architecture des services, un profil back end dédié apporte une maîtrise plus poussée. Le fullstack reste pertinent sur des équipes réduites ou des produits où la polyvalence prime sur la spécialisation.
Quelle différence entre un développeur back end et un développeur front end ?
Le développeur front end construit ce que l'utilisateur voit et manipule dans son navigateur : interface, interactions, rendu. Le développeur back end construit ce qui se passe côté serveur : il expose les données, applique les règles métier et garantit que tout reste rapide, sûr et cohérent. Les deux dialoguent à travers les API, mais leurs réflexes diffèrent. On évalue le front sur l'expérience et l'accessibilité, le back sur la fiabilité, la modélisation des données et la tenue en charge.