Développeur·euse Back-end : questions d'entretien et salaire
En France, un poste de Développeur·euse Back-end est rémunéré 55 000 € brut par an en médiane ; la moitié des salaires se situe entre 45 000 € et 70 000 €.
En un coup d'œil
- Salaire médian55 000 €
- Délai de recrutement45–75 jours
- Expérience3–7 ans
Salaire Développeur·euse Back-end en France
Salaire fixe brut annuel
- 25e centile
- 45 000 €
- Médiane
- 55 000 €
- 75e centile
- 70 000 €
| Niveau | 25e centile | Médiane | 75e centile |
|---|---|---|---|
| Junior | 36 000 € | 43 000 € | 50 000 € |
| Confirmé·e | 45 000 € | 55 000 € | 70 000 € |
| Senior | 68 000 € | 78 000 € | 90 000 € |
Pour référence : le SMIC brut s'élève, depuis le 1er juin 2026, à 12,31 € de l'heure, soit 1 867,02 € par mois pour un temps plein (35 h). (service-public.gouv.fr : revalorisation du SMIC au 1er juin 2026)
Fourchette de référence pour un·e Développeur·euse Back-end mid-level (3 à 7 ans d'expérience pro) en PME française. Île-de-France SaaS B2B et fintech tirent vers le haut (60-85 k€), surtout sur stacks Go / Java / Kotlin avec forte composante distribuée. Les régions et stacks plus classiques (Node, Python, Ruby, PHP moderne) restent dans le cœur de fourchette. Les profils avec expertise observabilité, performance, ou sécurité applicative démontrée ajoutent généralement 5 à 10 k€ sur la médiane.
Sources: APEC, Baromètre 2025 de la rémunération des cadres tech; INSEE, DADS 2024 (PCS 388a, Ingénieurs informatiques); Talent.io, Étude rémunération tech France 2025
Comment recruter un·e Développeur·euse Back-end pour votre PME
Avant de rédiger l’annonce, posez-vous trois questions de cadrage. Elles déterminent le profil que vous cherchez réellement et évitent les confusions de poste fréquentes en PME tech.
Question 1 : Back-end, Full-stack ou DevOps ? Les trois rôles se touchent mais ne se substituent pas. Le·la Back-end vit dans le code applicatif : API, base de données, jobs asynchrones, observabilité applicative. Le·la Full-stack couvre back et front à un niveau intermédiaire-avancé ; c’est souvent le profil par défaut en PME jeune (moins de 10 développeur·euse·s). Le·la DevOps ou SRE possède l’infrastructure : Kubernetes, CI / CD, monitoring d’infra, fiabilité. Si votre besoin réel est un·e Full-stack qui penche back, dites-le ; ne maquillez pas le poste pour attirer des spécialistes (vous les perdrez à 6 mois). Si votre besoin est de stabiliser l’infra et le déploiement, cherchez un·e DevOps, pas un·e Back-end.
Question 2 : Quelle est votre stack et quel niveau de complexité système porte-t-elle ? Un·e Back-end solide en Node ou Python ne devient pas immédiatement productif·ve sur Go ou Java sans 4 à 8 semaines de prise en main. La fit stack compte plus que la séniorité absolue pour un·e mid-level. Soyez explicite sur votre stack dans l’annonce (langage, framework, base de données, infra, observabilité) ; vous filtrerez naturellement les profils mal-fittés. Si votre stack est rare (Elixir, Rust, Clojure), assumez la rareté du vivier et chassez activement via les communautés de niche ; ne comptez pas sur les Job Posts seuls.
Question 3 : Quelle complexité système votre produit porte-t-il réellement ? Un·e Back-end en PME early-stage qui sert 100 requêtes par seconde sur une stack Django plus Postgres a un poste très différent d’un·e Back-end en scale-up qui gère 10 000 requêtes par seconde avec file de messages, cache distribué, et latence p99 critique. Cadrez honnêtement ce que sont vos contraintes (volume, latence, criticité, observabilité actuelle) dans l’annonce et l’entretien. Les profils expérimenté·e·s sondent ce sujet ; un·e candidat·e qui découvre la réalité après embauche partira dans les 12 mois.
Si les trois réponses convergent vers un·e Back-end à temps plein (et non un·e Full-stack ou un·e DevOps), retrouvez le modèle prêt à l’emploi dans la section Fiche de poste ci-dessous.
Modèle de fiche de poste Développeur·euse Back-end
Mission. Concevoir, développer et maintenir les services back-end du produit (API, base de données, jobs asynchrones, observabilité applicative), en autonomie sur les sujets familiers et en collaboration sur les décisions structurantes. Vous reportez au·à la [Tech Lead / CTO / Dirigeant·e technique].
Responsabilités.
- Livrer des fonctionnalités back-end bout en bout : compréhension du besoin produit, design technique, implémentation, tests, déploiement, observabilité, suivi en production.
- Concevoir et faire évoluer les API internes et externes (REST, GraphQL, ou gRPC selon contexte) avec attention à la cohérence, l'idempotence, et la rétrocompatibilité.
- Maintenir et faire évoluer le schéma de base de données : migrations sûres, optimisation des requêtes critiques, choix d'indexation.
- Participer aux décisions d'architecture sur votre périmètre (choix de bibliothèque, refactor, design d'un nouveau service ou d'une file de messages).
- Participer à l'astreinte ou à l'on-call : diagnostic d'incident, mitigation, post-mortem partagé, action systémique de prévention.
- Maintenir la qualité du code : revue des PRs des collègues, application des conventions, refactor au passage quand pertinent.
- Documenter les décisions techniques importantes (ADR) et les zones de complexité non triviales.
- Collaborer avec le·la PM, designer, front-end, ou directement avec un·e dirigeant·e sur les briefs produit ; challenger constructivement les contraintes infaisables ou contre-productives.
Profil recherché.
- Indispensable : 3 à 7 ans d'expérience en développement back-end pro ; maîtrise solide d'au moins un langage back-end moderne (Node, Python, Go, Ruby, Java, Kotlin, ou équivalent) et d'au moins une base de données relationnelle (Postgres, MySQL) ; expérience d'ownership d'un service en production (déploiement, monitoring, incident).
- Apprécié : familiarité avec la stack [langage et framework, base de données, infra, observabilité] de notre produit ; expérience en PME ou scale-up (autonomie élevée) ; expertise sur un sujet précis (observabilité, performance, sécurité applicative, files de messages, search) ; contributions open source ou side-projects publics.
- Disqualifiant : aucune expérience d'ownership en production en autonomie ; refus de participer à l'astreinte ou de toucher à l'observabilité ; absence totale de pratique de tests automatisés.
Conditions.
- Rémunération brute annuelle : fixe [45-70] k€ selon expérience. Pas de variable structurel ; BSPCE éventuels selon le stade de la société.
- Modalité : [temps plein, hybride 2-3 jours / semaine sur site, base à [ville] / remote-friendly].
- Astreinte : [rythme, compensation financière ou en récupération, runbooks et observabilité existante].
- Avantages : [mutuelle, tickets resto, RTT, BSPCE, télétravail policy, budget matériel, budget formation et conférences].
- Stack : [à compléter : langage et framework, base de données, file de messages, infra, CI / CD, observabilité].
Vous recrutez pour ce poste ? Job Studio transforme ce modèle en offre d’emploi prête à publier, avec une fourchette de salaire suggérée et le formulaire de candidature.
Questions d'entretien pour Développeur·euse Back-end
15 questions structurées, regroupées par type. Chacune indique la compétence évaluée ; dépliez-la pour voir ce que révèle une bonne réponse.
Comportementale 3
Décrivez l'incident de production le plus sérieux que vous avez piloté. Quel était le symptôme, le diagnostic, la résolution, et le suivi systémique ?
Debug et observabilitéCe qu'une bonne réponse révèle
Méthode structurée : reproduction ou observation directe, formulation d'hypothèses, validation par logs, métriques, ou expérimentation ciblée. Honnêteté sur la durée et les fausses pistes. Bonus : la·le candidat·e cite la cause profonde (pas seulement le hotfix) et la mesure préventive mise en place après (post-mortem, alerte ajoutée, test de régression). Les réponses « j'ai redémarré le service et tout est rentré dans l'ordre » sans diagnostic révèlent une faiblesse d'investigation.
Décrivez une décision d'architecture importante que vous avez prise sur votre dernier poste. Pourquoi était-elle difficile et comment l'avez-vous tranchée ?
Design systèmeCe qu'une bonne réponse révèle
Capacité à structurer une décision sous incertitude : clarification des contraintes, alternatives évaluées, arbitrages explicites entre simplicité et flexibilité future, consultation des parties concernées, validation a posteriori. Bonus : la·le candidat·e mentionne une décision dont il·elle reviendrait aujourd'hui, ou un ADR écrit pour la postérité. Les candidat·e·s qui décrivent une décision « évidente » avec recul n'ont pas vraiment arbitré.
Parlez-moi d'une fois où votre solution initiale ne tenait plus sous la charge réelle. Comment avez-vous diagnostiqué et corrigé ?
Performance et mesureCe qu'une bonne réponse révèle
Humilité face aux hypothèses initiales : la·le candidat·e reconnaît la limite, mesure avant d'agir (profiling, métriques, charge réelle vs synthétique), arbitre entre optimisation locale et refonte. Bonus : la·le candidat·e identifie en rétrospective le signal qu'il·elle aurait pu lire plus tôt. Les profils qui « n'ont jamais eu de problème de charge » mentent ou n'ont pas servi de trafic réel.
Situationnelle 3
Vous découvrez une vulnérabilité de sécurité (injection SQL, secret en clair dans un repo, IDOR sur un endpoint) en revue de code d'un·e collègue senior. Comment réagissez-vous ?
Sécurité applicativeCe qu'une bonne réponse révèle
Capacité à pointer une faiblesse sans braquer : commentaire factuel sur la PR (« voici le risque concret, voici un correctif suggéré »), proposition d'une solution chiffrée, escalade à la·au lead ou à la sécurité si la PR est mergée malgré le commentaire. Les candidat·e·s qui « laissent passer parce que c'est un·e senior » révèlent une faiblesse de courage technique critique sur un poste back-end.
Un·e PM vous demande d'ajouter un endpoint de recherche full-text sur la base. Vous estimez 3 semaines ; le·la PM en veut 1. Comment réagissez-vous ?
Communication produitCe qu'une bonne réponse révèle
Clarification du besoin réel avant de négocier la timeline : quel volume de données, quelle latence acceptable, quelles fonctionnalités vraiment indispensables (filtres, scoring, surlignage). Proposition d'options explicites : MVP via ILIKE Postgres en 1 semaine puis vraie indexation en V2, ou périmètre coupé. Les réponses « je peux le faire en 1 semaine en travaillant les week-ends » sont un drapeau rouge.
Vous arrivez sur un service back-end avec dette opérationnelle élevée : pas de métriques, déploiements manuels, alertes silencieuses, tests d'intégration cassés depuis 6 mois. Quel est votre plan en 30 jours ?
Pragmatisme et priorisationCe qu'une bonne réponse révèle
Diagnostic d'abord, pas de grand soir : priorisation par risque opérationnel. Typiquement : (1) observabilité minimale pour voir avant d'agir (métriques de base, logs structurés, dashboard d'incident), (2) sécuriser le pipeline de déploiement (rollback rapide, un environnement de staging fiable), (3) remettre les tests critiques au vert sur les zones métier sensibles, (4) plan plus long pour le reste. Validation explicite avec l'équipe et la·le lead avant d'engager.
Étude de cas 3
Conception : on veut un système de webhooks fiables vers les clients ; livraison garantie, ordre raisonnable, gestion des clients lents ou indisponibles. Comment concevez-vous cela ?
Design systèmeCe qu'une bonne réponse révèle
Clarifications avant de proposer : volume attendu, criticité, contraintes de latence, SLA promis aux clients. Architecture cohérente : file de messages persistante, retries exponentiels bornés, dead-letter queue, idempotence côté récepteur, signature HMAC, isolation des clients lents (rate-limit ou worker dédié). Observabilité : taux de succès par client, latence p99, taille de la file. Bonus : reconnaissance des zones d'incertitude (« je prototypierais Kafka vs RabbitMQ vs SQS selon le volume réel avant de m'engager »). Les profils qui plongent dans le code sans clarifier les contraintes révèlent une faiblesse de design.
Debug : votre API renvoie une 500 sur 1 à 2 % des requêtes en heures de pointe. Les logs applicatifs ne montrent rien de net. Comment investiguez-vous ?
Debug et observabilitéCe qu'une bonne réponse révèle
Méthode structurée : (1) augmenter temporairement le niveau de log et activer le tracing sur les endpoints concernés, (2) corréler avec les métriques (latence p99, taille de payload, connexions DB, mémoire, GC), (3) chercher un pattern (heure, type de requête, utilisateur·rice spécifique, ratio sur un pod précis), (4) hypothèses ordonnées : pool DB saturé, timeout amont, race condition, OOM, panic non récupérée. Les candidat·e·s qui se précipitent sur « c'est sûrement la DB » sans investiguer révèlent un biais d'investigation.
Performance : une requête de listing met 4 secondes p95 avec 200 ms de p50. Vous avez 1 semaine pour ramener le p95 sous 800 ms. Plan d'action ?
Performance et mesureCe qu'une bonne réponse révèle
Mesurer avant d'optimiser : EXPLAIN ANALYZE sur la requête, profilage côté application, vérification du pool de connexions. Identifier le bottleneck réel : index manquant, N plus 1, payload énorme, sérialisation coûteuse, lock de table. Hiérarchiser par effort fois impact. Les réponses « j'ajoute Redis devant » sans diagnostic révèlent un réflexe d'optimisation prématurée. Bonus : la·le candidat·e note qu'un écart p50 vs p95 aussi violent suggère un comportement par cas (utilisateur·rice avec gros dataset, lock occasionnel) plutôt qu'une lenteur uniforme.
Technique 3
Différence pratique entre une transaction DB (avec niveau d'isolation REPEATABLE READ ou SERIALIZABLE) et un lock applicatif distribué (Redis, Zookeeper) ? Quand utiliser l'un plutôt que l'autre ?
Fondamentaux back-endCe qu'une bonne réponse révèle
Transaction DB : atomicité plus isolation gérées par la base, bornée à une seule DB ; isolation forte au prix de conflits visibles (serialization failures à retry côté applicatif). Lock applicatif : coordination entre processus ou instances quand la coordination dépasse une seule DB (microservices, déduplication de jobs, leader election). Risques distincts : deadlock vs lock perdu en cas de crash du détenteur (d'où les TTL et le fencing token). Les candidat·e·s qui ne savent pas distinguer ces deux mécanismes vont créer des race conditions en production.
Idempotence d'un endpoint qui crée une ressource (par exemple un paiement). Comment l'implémentez-vous concrètement en PostgreSQL plus un service stateless ?
Fondamentaux back-endCe qu'une bonne réponse révèle
Compréhension claire : la·le client·e fournit une clé d'idempotence (entête HTTP), le serveur la persiste avec la requête et la réponse, et toute requête ultérieure avec la même clé renvoie la réponse stockée sans re-jouer l'effet de bord. Détails attendus : contrainte UNIQUE sur la clé en DB, gestion du conflit (renvoyer la réponse cachée, pas une 409), TTL raisonnable (24-48h typique), interaction propre avec la transaction métier (idéalement même transaction ou compensation). Les profils qui répondent « je vérifie si ça existe déjà avant d'insérer » créent une race condition classique.
Stratégie de tests sur un service back-end : pyramide, types, ce que vous mesurez vraiment ? Décrivez l'arbitrage sur votre dernier projet.
Qualité du codeCe qu'une bonne réponse révèle
Compréhension de la pyramide : beaucoup d'unitaires sur la logique métier, moins d'intégration ciblées sur les frontières (DB, files de messages, API externes), peu d'end-to-end. Distinction entre couverture et utilité : 90 % sur du code trivial vaut moins que 60 % sur le cœur métier. Bonus : la·le candidat·e cite une fois où un test a évité une régression réelle, ou un type de bug que les tests n'attrapent pas (race conditions, problèmes de configuration prod). Les profils qui répondent « je teste à 100 % » sans nuancer manquent de jugement.
Valeurs 3
Comment recevez-vous une review de code critique sur du code que vous étiez convaincu·e d'avoir bien fait ?
CoachabilitéCe qu'une bonne réponse révèle
Ouverture : capacité à dissocier le code de l'ego personnel. Bonus : la·le candidat·e cite une fois où il·elle a changé d'avis grâce à une review et explique ce qui l'a fait basculer. Les candidat·e·s qui décrivent surtout avoir « expliqué leur logique » au reviewer au lieu de l'écouter révèlent une faiblesse de coachabilité critique pour un poste où la qualité du code est partagée.
Quel rôle jouez-vous dans la transmission technique aux junior·e·s ou aux nouveaux·elles arrivant·e·s ?
Mentorat et transmissionCe qu'une bonne réponse révèle
Posture de mentorat actif : pair-programming, reviews pédagogiques (pas juste « ok merge »), documentation des décisions importantes (ADR), partage en réunion d'équipe ou en lunch and learn. En PME où l'équipe back-end est souvent petite (3-8 personnes), la capacité à transmettre est essentielle pour la pérennité du code. Les candidat·e·s qui répondent « j'aide quand on me demande » sans plus de précision révèlent une posture passive.
Comment travaillez-vous avec un·e PM ou un·e front-end ? Décrivez une fois où vous avez poussé en arrière sur un brief produit.
Communication produitCe qu'une bonne réponse révèle
Posture de partenariat : challenge constructif basé sur la faisabilité, la complexité, ou le coût opérationnel à long terme (le·la back-end vit avec les schémas et les contrats d'API qu'il·elle expose). Proposition d'alternatives. Bonus : la·le candidat·e cite un cas où il·elle a accepté le brief initial après échange. Les profils qui décrivent les PMs ou front-end comme « ne comprenant pas la complexité technique » révèlent une faiblesse de jeu d'équipe.
Salaire et recrutement par niveau
Le même poste à chaque niveau : la rémunération, l'expérience attendue et la durée habituelle du recrutement.
Développeur·euse Back-end Junior
- Salaire fixe brut annuel
- 43 000 €36 000 € – 50 000 €
- Expérience
- 0–2 ans
- Délai de recrutement
- 30–55 jours
Développeur·euse Back-end (Confirmé·e)
- Salaire fixe brut annuel
- 55 000 €45 000 € – 70 000 €
- Expérience
- 3–7 ans
- Délai de recrutement
- 45–75 jours
Développeur·euse Back-end Senior
- Salaire fixe brut annuel
- 78 000 €68 000 € – 90 000 €
- Expérience
- 7–12 ans
- Délai de recrutement
- 60–95 jours
Salaire Développeur·euse Back-end par pays
Le même poste, au même niveau, dans chacun des pays que nous couvrons ; les montants proviennent de sources du pays concerné.
| Pays | Bas de fourchette | Valeur centrale | Haut de fourchette |
|---|---|---|---|
| FranceCette page | 45 000 € | 55 000 € | 70 000 € |
| AllemagneDeutsch | 52 000 € | 62 000 € | 78 000 € |
| EspagneEspañol | 40 000 € | 50 000 € | 62 000 € |
| Pays-BasNederlands | 53 160 € | 63 060 € | 72 960 € |
| ItalieItalianoItalia · sondaggio Crebs · Back-end Developer Mid-weight, anni non indicati | 35 000 € | — | 45 000 € |
Sources
- Allemagne (consulté en mai 2026) : Stepstone Gehaltsdaten Backend-Entwickler:in Deutschland 2026 · Stepstone Gehaltsreport 2026 · Honeypot State of Software Engineering Germany 2025 · Destatis Verdiensterhebung (April 2025), Berufsgruppe 43 IKT-Berufe
- Espagne (consulté en mai 2026) : INE, Encuesta de Estructura Salarial 2024 (CNO 271, Analistas y diseñadores de software) · InfoJobs, Estado del Mercado Laboral en España 2025 · Honeypot State of Software Engineering Spain 2025
- Pays-Bas (consulté en août 2026) : Intermediair — salaris backend developer
- Italie (consulté en octobre 2026) : Crebs, Guida Stipendi 2026: Media stipendi Back-end Developer in Italia (livelli Junior, Mid-weight e Senior; metodo del sondaggio) · Hays Italia Salary Guide 2026, Technology, Digital & New Media — Software Development, p. 70 (PDF Hays ospitato da QualEnergia; solo confronto) · Hays Italia Salary Guide 2026 (pagina ufficiale dell’edizione)
Où sourcer ce profil
LinkedIn
800-1 200 € / mois (Recruiter Lite, sourcing actif)Canal le plus profond pour les profils back-end en France. Le sourcing actif (Recruiter Lite ou Premium plus InMails ciblés) bat largement les Job Posts seuls : les bon·ne·s back-end avec 3-7 ans d'expérience sont presque toujours en poste et ne consultent pas le feed Jobs. Filtrez précisément sur la stack (« Go plus PostgreSQL plus Kubernetes » rend bien mieux que « back-end senior »), la séniorité, et la taille de boîte précédente. Personnalisez le premier message en citant un projet ou une stack précise ; les InMails génériques restent en dessous de 5 % de taux de réponse.
Welcome to the Jungle
Dès 990 € HT / offreForte audience tech scale-up et PME modernes à Paris, Lyon, Bordeaux, Nantes, Toulouse. Les candidat·e·s WTTJ regardent en premier la stack, l'architecture du produit, les pratiques (tests, CI, on-call, post-mortems), et la culture technique de l'équipe. Bien adapté pour les marques employeur jeunes ou les produits qui ont une vraie complexité système à raconter. Moins efficace pour stacks legacy ou pour les profils sur des langages de niche.
GitHub et communautés back-end de niche
Variable ; budget temps d'un·e ingénieur·e plus que budget cashGitHub Jobs est fermé depuis 2021 mais GitHub reste le meilleur canal de sourcing actif pour les profils spécialisés : contributions open source, projets perso, organisations suivies révèlent davantage que les CV. Complétez avec les communautés de niche par stack (Reddit r/golang, r/django, r/rails ; serveurs Discord Rust, Elixir ; groupes Slack tech français comme StaffEng.fr). À combiner avec une présence active de votre équipe technique sur ces communautés ; un message « cold » d'une recruteuse aura peu de retour, un message d'un·e ingénieur·e de l'équipe en aura beaucoup plus.
Playbook d'évaluation
Le rôle de Développeur·euse Back-end se signale à travers cinq stades d'évaluation. Le system design (stade 4) est le plus prédictif pour ce poste : c'est là que se révèle la capacité à raisonner sur les contraintes distribuées, la persistance, et l'observabilité dont une PME a besoin pour ne pas accumuler de dette opérationnelle.
Stade 1: Lecture du CV
Cherchez la cohérence stack et la profondeur back-end réelle : un·e profil annoncé « back-end » qui a passé 80 % de son temps sur l'UI n'est pas le·la candidat·e visé·e. Indices forts : ownership d'un service en production (déploiement, monitoring, incidents), exposition à au moins une base de données relationnelle bien comprise, présence de mots-clés concrets (Postgres, Redis, message queue, OpenTelemetry, profiling). Stabilité minimale 18-24 mois par poste. Un·e autodidacte avec 4 ans d'ownership en production vaut largement un·e diplômé·e top école avec 2 ans de tickets fermés sans vrai contexte.
Stade 2: Phone screen (30 min)
Trois questions ciblées : (1) « Décrivez le service back-end le plus complexe que vous avez possédé ; QPS, taille des données, contraintes ? », (2) « Décrivez un incident de production que vous avez piloté ; symptôme, diagnostic, résolution, suivi ? », (3) « Pourquoi un changement maintenant ? ». Sortie : go ou no-go en 5 min, pas plus. À ce stade évitez les pièges techniques ; cherchez la solidité du vécu produit.
Stade 3: Entretien technique (60-90 min)
Pair-programming sur un exercice borné (45-60 min) qui ressemble au quotidien : ajout d'un endpoint avec contrainte de concurrence, refactor d'une requête N plus 1, debug d'une race condition simulée. Puis 15-30 min de Q&R sur les choix techniques. Évaluez le raisonnement à voix haute, la capacité à demander des clarifications, et l'instinct sur les pièges de production (idempotence, timeouts, retries, isolation transactionnelle).
Stade 4: System design (60 min)
Discussion d'architecture sur un cas concret proche de votre produit : conception d'un système de webhooks fiables, d'une file de traitement asynchrone, d'un endpoint de recherche, ou d'un pipeline d'agrégation. Évaluez la clarification des contraintes (QPS, latence cible, volumétrie, criticité), les arbitrages explicites (synchrone vs asynchrone, push vs pull, fort vs cohérence éventuelle), la pensée observabilité dès le design (métriques, logs structurés, traces, alertes), et la reconnaissance honnête des zones d'incertitude. C'est le stade le plus prédictif pour ce poste.
Stade 5: Références (vérification structurée)
Appelez deux références : un·e ancien·ne tech lead ou manager direct et un·e ancien·ne collègue back-end. Posez les mêmes 4 questions à chaque référence : « Sur quoi est-il·elle le plus fort·e ? », « Sur quoi recruteriez-vous quelqu'un de complémentaire ? », « Le·la reprendriez-vous demain ? », « Un exemple précis de décision technique difficile prise en autonomie ? ». La 4e question révèle le vrai signal d'autonomie sur un poste back-end.
Comment reconnaître une excellente recrue
| Compétence | Sous la barre | Au niveau | Au-dessus |
|---|---|---|---|
| Solidité technique back-end | Bute sur les fondamentaux (HTTP, transactions, asynchrone, concurrence). Choisit par habitude ou par mode plutôt que par adéquation. Difficile à charger sur un nouveau langage back-end. | Maîtrise la stack actuelle en autonomie. Comprend les fondamentaux suffisamment pour déboguer en profondeur. Sait apprendre un nouveau langage ou framework back-end en 4-8 semaines productivement. | Référent·e technique sur sa stack, capable de basculer sur une autre stack back-end en quelques semaines. Anticipe les pièges classiques (race conditions, fuites de connexions, dégradation par lock). Construit des abstractions utiles, pas prématurées. |
| Design système | Plonge dans le code sans clarifier les contraintes (volume, latence, criticité). Sur-conçoit (microservices pour un MVP) ou sous-conçoit (monolithe spaghetti à 50 k LOC). Difficile à arbitrer entre simplicité et scalabilité. | Clarifie le besoin avant de coder. Pragmatique sur les arbitrages synchrone vs asynchrone, push vs pull, cohérence forte vs éventuelle. Reconnaît ses zones d'incertitude et propose un POC ciblé quand pertinent. | Conçoit des systèmes qui vieillissent bien : abstractions justes, dépendances minimales, frontières métier claires, observabilité dès le design. Forme l'équipe sur la pensée systèmes et écrit des ADRs lisibles par les nouveaux·elles arrivant·e·s. |
| Observabilité et debug | Diagnostique par essai-erreur sans modèle mental. N'instrumente pas le code en production (logs anémiques, pas de métriques métier, alertes silencieuses). Réagit à l'incident, n'anticipe rien. | Méthode de debug structurée : reproduction, hypothèses, validation par logs ou métriques. Ajoute l'observabilité nécessaire au passage. Sait piloter un incident de prod sans paniquer. | Pense observabilité dès le design : SLI / SLO définis, dashboards lisibles, alertes signifiantes (pas de bruit), post-mortems honnêtes. Reconstruit l'historique d'un incident à partir des logs ou traces et propose une action systémique. |
| Sécurité applicative | Pas conscient·e des risques courants (OWASP Top 10, secrets en clair, IDOR, désérialisation). Code sans validation d'entrée systématique. Considère la sécurité comme « pas son problème ». | Connaît les principaux risques applicatifs et les évite par défaut : requêtes paramétrées, validation côté serveur, gestion saine des secrets (vault ou env vars), revue de PR avec œil sécurité. Sait pointer une vulnérabilité chez un·e collègue. | Référence sécurité dans l'équipe : revue de modèle de menaces, choix de bibliothèques crypto sûres, gestion des dépendances vulnérables (CVE monitoring), tests de sécurité automatisés en CI. Coordonne avec l'équipe sécurité ou DPO sur les sujets sensibles. |
| Qualité et hygiène du code | Pas de stratégie de test claire ; ajoute des tests « pour la couverture ». Code mal structuré (fonctions à 300 lignes, magic numbers, duplication). Reviews superficielles. | Pyramide de tests pertinente sur la logique métier. Code lisible avec naming clair et fonctions courtes. Reviews structurées avec feedback actionnable. Refactor au passage quand pertinent. | Référence qualité de l'équipe : conventions documentées, automatisation des contrôles (linters, type-checkers, CI). Reviews pédagogiques qui font progresser les junior·e·s. Sait dire non à du code qui passe les tests mais qui vieillira mal. |
| Communication produit | Explique mal son travail à un·e PM ou un·e dirigeant·e. Posture défensive (« c'est trop complexe ») ou d'opposition systématique. Communique mal les délais et les risques. | Sait expliquer un arbitrage technique à un·e PM en langage clair. Challenge constructivement les briefs et propose des alternatives. Communique les délais et risques de manière transparente. | Pont entre le back-end et les autres fonctions. Anime les discussions techniques produit, vulgarise les arbitrages, négocie les périmètres de manière transparente. Écrit des spécifications techniques lisibles par les non-techniques. |
Erreurs de recrutement courantes pour ce poste
Confondre back-end et full-stack au moment du brief
Un·e Back-end et un·e Full-stack ne couvrent pas le même besoin. Le·la Back-end passe 80 à 100 % de son temps sur l'API, la base de données, les jobs asynchrones, l'observabilité. Cherchez un·e Full-stack pour un·e profil qui doit aussi livrer de l'UI et vous obtiendrez un·e Back-end frustré·e ou des features front bâclées. Si votre vrai besoin est un·e Full-stack qui penche back, dites-le explicitement dans l'annonce ; ne maquillez pas un poste Full-stack en Back-end pour attirer des profils spécialistes (vous les perdrez à 6 mois).
Sur-évaluer les fondamentaux algorithmiques pour un poste produit
Un·e Back-end en PME n'a quasi jamais besoin de réimplémenter un B-tree ou de résoudre un problème de graphe pondéré. Les tests « LeetCode » filtrent les profils académiques au détriment des profils opérationnels qui sauront tenir un service en production. Privilégiez les exercices qui ressemblent au quotidien : ajout d'un endpoint avec contrainte de concurrence, refactor d'une requête N plus 1, debug d'une race condition, design d'une file de messages.
Sauter le system design en pensant gagner du temps
Pour un poste back-end mid-level, le system design est le stade le plus prédictif de la performance future. Une PME qui saute ce stade pour gagner une semaine sur le délai de recrutement embauche typiquement quelqu'un qui code propre mais qui ne sait pas anticiper les pièges distribués (cohérence, idempotence, observabilité, dégradation gracieuse) et accumulera de la dette opérationnelle pendant 18 mois. Le coût d'un mauvais recrutement back-end est bien supérieur à 60 minutes de system design en entretien.
Ignorer la fit stack et l'écosystème
Un·e Back-end solide en Node ou Python ne devient pas immédiatement productif·ve sur Go ou Java sans 4 à 8 semaines de prise en main, et inversement. La fit stack compte beaucoup plus que la séniorité absolue pour un·e mid-level. Précisez votre stack en bonne place dans l'annonce (langage, framework, base de données, infra). Si vous êtes sur une stack rare (Elixir, Rust, Clojure), assumez la rareté du vivier et chassez activement ; ne comptez pas sur les Job Posts seuls.
Sous-estimer le coût de l'astreinte et de l'on-call
Un·e Back-end en PME participe quasi systématiquement à l'astreinte ou à l'on-call. Une rotation mal cadrée (fréquence trop élevée, alertes bruyantes, absence de runbooks, pas de compensation) provoque du burnout en 6 à 12 mois et de la rotation. Annoncez clairement votre dispositif d'astreinte dans l'annonce, son rythme, sa compensation (financière ou en récupération), et l'état réel de votre observabilité. Les candidat·e·s expérimenté·e·s sondent ce sujet en entretien ; soyez prêt·e à répondre honnêtement.