Développeur·euse Back-end Junior
Fiche de poste, salaire, sourcing, questions d'entretien et plan 30/60/90 pour recruter un·e Développeur·euse Back-end Junior en PME française.
Compilé par l'équipe Join à partir de données publiques et de notre expérience de recrutement.
Mis à jour
En un coup d'œil
- Salaire médian43 000 €36 000 € – 50 000 €
- Délai de recrutement30–55 jours
- Expérience0–2 ans
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), passez au modèle d’annonce ci-dessous.
Modèle de fiche de poste
Développeur·euse Back-end (H / F) PME française
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é].
Fourchette salariale
Salaire fixe annuel brut
- 25e centile
- 36 000 €
- Médiane
- 43 000 €
- 75e centile
- 50 000 €
Fourchette de référence pour un·e Développeur·euse Back-end junior (0 à 2 ans d'expérience, sortie d'école, de bootcamp, ou reconversion) en PME française. Île-de-France et stacks modernes (Go, Python, Node) tirent vers le haut (44 à 50 k€) ; les régions et les stacks plus classiques (PHP, Java legacy) restent en bas de fourchette (36 à 40 k€). Un stage ou une alternance significative et un portfolio visible (GitHub, projets perso déployés) pèsent plus que le diplôme à ce niveau. Comme pour les autres niveaux, pas de variable structurel en PME.
Sources: Cocowork, Guide des salaires développeur back-end France 2026; Glassdoor, Salaires Backend Developer France
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 et A 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.
Questions d'entretien structurées
ComportementaleDebug et observabilité 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 ?
Ce qu'une bonne réponse révèleMé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.
ComportementaleDesign système 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 ?
Ce qu'une bonne réponse révèleCapacité à 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é.
ComportementalePerformance et mesure Parlez-moi d'une fois où votre solution initiale ne tenait plus sous la charge réelle. Comment avez-vous diagnostiqué et corrigé ?
Ce qu'une bonne réponse révèleHumilité 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.
SituationnelleSécurité applicative 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 ?
Ce qu'une bonne réponse révèleCapacité à 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.
SituationnelleCommunication produit 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 ?
Ce qu'une bonne réponse révèleClarification 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.
SituationnellePragmatisme et priorisation 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 ?
Ce qu'une bonne réponse révèleDiagnostic 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 casDesign système 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 ?
Ce qu'une bonne réponse révèleClarifications 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.
Étude de casDebug et observabilité 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 ?
Ce qu'une bonne réponse révèleMé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.
Étude de casPerformance et mesure 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 ?
Ce qu'une bonne réponse révèleMesurer 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.
TechniqueFondamentaux back-end 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 ?
Ce qu'une bonne réponse révèleTransaction 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.
TechniqueFondamentaux back-end 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 ?
Ce qu'une bonne réponse révèleCompré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.
TechniqueQualité du code Stratégie de tests sur un service back-end : pyramide, types, ce que vous mesurez vraiment ? Décrivez l'arbitrage sur votre dernier projet.
Ce qu'une bonne réponse révèleCompré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.
ValeursCoachabilité Comment recevez-vous une review de code critique sur du code que vous étiez convaincu·e d'avoir bien fait ?
Ce qu'une bonne réponse révèleOuverture : 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.
ValeursMentorat et transmission Quel rôle jouez-vous dans la transmission technique aux junior·e·s ou aux nouveaux·elles arrivant·e·s ?
Ce qu'une bonne réponse révèlePosture 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.
ValeursCommunication produit 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.
Ce qu'une bonne réponse révèlePosture 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.
Comment reconnaître un·e excellent·e Sales Manager
| 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. |
Plan 30/60/90 jours
À J+30
- Setup complet de l'environnement local et premier déploiement (PR triviale) validé en production
- Lecture et compréhension du code des 3 services back-end les plus critiques de la stack métier
- Premier 1:1 documenté avec la·le tech lead sur les conventions, la dette opérationnelle identifiée, et les priorités
- Première PR substantive (fix de bug ou petit endpoint) reviewée et mergée
À J+60
- Livraison en autonomie d'un endpoint ou d'un job back-end complet (design, implémentation, tests, observabilité, déploiement)
- Première review de PR d'un·e collègue avec feedback structuré (pas juste « ok merge »)
- Premier on-call ou astreinte avec gestion d'au moins un incident (diagnostic, mitigation, post-mortem partagé)
- Documentation ou ADR rédigé sur une zone récemment touchée
À J+90
- Livraison régulière (1 à 2 PRs par semaine) avec qualité validée par l'équipe en review
- Première décision technique d'architecture en autonomie sur un sujet ambigu (refactor, choix de bibliothèque, design d'un nouveau composant)
- Mentorat informel d'un·e junior ou nouveau·elle arrivant·e (pair-programming, reviews pédagogiques)
- Bilan formel avec la·le tech lead : ramp validé, plan de progression sur 1-2 axes prioritaires (par exemple observabilité ou design système)
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.
Questions fréquentes
Quel est le salaire d'un·e Développeur·euse Back-end en PME française ?
La fourchette de référence pour un·e Développeur·euse Back-end mid-level (3 à 7 ans d'expérience) en PME française est de 45 à 70 k€ bruts annuels (médiane autour de 55 k€). Île-de-France SaaS B2B et fintech tirent vers le haut (60-85 k€), surtout sur les stacks Go, Java ou Kotlin avec composante distribuée. Les régions et stacks plus classiques 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. Ce poste n'a pas de variable structurel en PME, mais peut inclure des BSPCE en scale-up.
Quelle différence entre un·e Back-end, un·e Full-stack et un·e DevOps ou SRE ?
Le·la Back-end conçoit et maintient l'API, la base de données, les jobs asynchrones, l'observabilité applicative ; il·elle vit dans le code applicatif. Le·la Full-stack couvre back-end et front-end à un niveau intermédiaire-avancé ; en PME jeune c'est souvent le profil par défaut. Le·la DevOps ou SRE possède l'infrastructure (Kubernetes, CI / CD, monitoring d'infra, fiabilité) ; il·elle vit dans le code d'infra et les pipelines. Un·e Back-end peut toucher à l'infra mais ne la possède pas. Pour une PME de moins de 10 développeur·euse·s, l'arbitrage typique : 1-2 Full-stack avant le premier·ère Back-end spécialiste, qui arrive quand la complexité produit ou la volumétrie le justifie.
Combien de temps faut-il pour recruter un·e Développeur·euse Back-end en France ?
Comptez 45 à 75 jours entre la publication de l'annonce et la signature pour un·e profil mid-level. Le marché back-end reste tendu en 2025-2026, surtout sur les stacks modernes avec composante distribuée (Go, Kotlin, Rust, Elixir). Les délais s'allongent en septembre et janvier. Réduire le délai en dessous de 45 jours impose en général de sacrifier le system design ou les références, ce qui dégrade fortement la qualité du recrutement pour ce poste.
Quelle stack technique demander pour un poste Back-end en 2026 ?
Cela dépend de votre stack existante ; n'imposez pas une stack que vous n'utilisez pas. Pour une PME qui démarre, les choix les plus sûrs sont : Python (Django ou FastAPI) ou Node (NestJS) sur PostgreSQL pour la productivité, Go pour la performance et la simplicité opérationnelle, Java ou Kotlin si vous avez un contexte enterprise. Évitez de mélanger trop de langages back-end dans une petite équipe (coût de contexte). Demandez surtout des fondamentaux solides (transactions, concurrence, observabilité) plus que la mode du moment ; ces fondamentaux portent à travers les changements de stack.
Faut-il un diplôme spécifique pour recruter un·e Développeur·euse Back-end ?
Non. Le marché tech français accepte largement les profils autodidactes ou issus de bootcamps (42, Le Wagon, OpenClassrooms) dès qu'ils·elles ont 3-5 ans de production solide sur un service back-end. Le diplôme d'école d'ingénieur ou de master informatique est rassurant pour les profils junior mais perd de l'importance après 5 ans d'expérience. Évaluez sur le code, le system design, et la qualité du diagnostic d'incident, pas sur le pedigree académique.
Faut-il faire un test technique systématique ?
Oui, mais court (2-3h max) et réaliste. Un test technique bien construit reste le meilleur prédicteur de performance future, devant le diplôme et le pedigree, à condition d'être paire avec un stade de system design séparé. Évitez les tests algorithmiques académiques sans rapport avec le quotidien (LeetCode hard) ; privilégiez les exercices qui ressemblent au métier : ajout d'un endpoint avec contrainte de concurrence, refactor d'une requête N plus 1, debug d'une race condition simulée. Bornez le temps explicitement et acceptez les solutions incomplètes mais bien argumentées.