Développeur·euse Full-stack
Fiche de poste, salaire, sourcing, 15 questions d'entretien et plan 30/60/90 pour recruter un·e Développeur·euse Full-stack 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édian 55 000 € 45 000 € – 70 000 €
- Délai de recrutement 45–75 jours
- Expérience 3–6 ans
Comment recruter un·e Développeur·euse Full-stack 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 erreurs courantes en PME tech.
Question 1 : Full-stack ou spécialiste ? Le·la Full-stack couvre front-end et back-end à un niveau intermédiaire-avancé ; les spécialistes (Front pur, Back pur) sont plus forts dans leur domaine. En PME tech de moins de 10 développeur·euse·s, le·la Full-stack est presque toujours le bon choix : la spécialisation n’est justifiée qu’à partir d’un certain volume d’équipe et de complexité produit. Si vous hésitez, optez pour Full-stack avec une coloration légère (« plutôt orienté front » ou « plutôt orienté back ») selon le besoin du moment.
Question 2 : Quelle est votre stack et son niveau de maturité ? Un·e développeur·euse expérimenté·e sur React + Node + Postgres ne devient pas immédiatement productif·ve sur Vue + Python + MongoDB sans 2-4 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 ; vous filtrerez naturellement les profils mal-fittés. Si votre stack est legacy (PHP procédural, jQuery, ColdFusion), assumez-le et cherchez des profils qui aiment la rénovation de codebase plutôt que d’attirer des profils déçus à l’embauche.
Question 3 : Quel pourcentage du temps sera consacré à des décisions techniques en autonomie ? En PME early-stage (moins de 5 développeur·euse·s), un·e Full-stack mid-level prend régulièrement des décisions d’architecture (choix de librairie, design d’un nouveau service, refactor de zone critique). En PME plus établie (plus de 15 développeur·euse·s), il·elle exécute davantage dans un cadre déjà posé par un·e tech lead. Le profil idéal diffère : autonomie + débrouillardise pour la première, qualité d’exécution + collaboration pour la seconde. Cadrez cette dimension dès l’annonce.
Si les trois réponses convergent vers un·e Full-stack à temps plein (et non un·e spécialiste ou un·e tech lead), passez au modèle d’annonce ci-dessous.
Modèle de fiche de poste
Développeur·euse Full-stack (H / F) — PME française
Mission. Concevoir, développer et maintenir les fonctionnalités produit sur l’ensemble de la stack ([front + back + base de données]), 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 features bout en bout : compréhension du besoin produit, design technique, implémentation front + back, tests, déploiement, suivi en production.
- Participer aux décisions d’architecture sur votre périmètre (choix de librairie, refactor, design d’un nouveau service).
- Maintenir la qualité du code : revue des PRs des collègues, application des conventions, refactor au passage quand pertinent.
- Contribuer à la résolution des incidents de production (on-call ou astreinte selon l’organisation).
- Documenter les décisions techniques importantes et les zones de complexité non triviales.
- Collaborer avec le·la PM / designer / dirigeant·e sur les briefs produit ; challenger constructivement les contraintes infaisables ou contre-productives.
Profil recherché.
- Indispensable : 3 à 6 ans d’expérience en développement web pro ; maîtrise solide d’au moins un framework moderne front (React, Vue, Svelte) et back (Node, Python, Ruby, Go, ou équivalent) ; expérience de mise en production (déploiement, monitoring, gestion d’incident).
- Apprécié : familiarité avec la stack [React + Node / Python / autre] de notre produit ; expérience en PME ou startup (autonomie élevée) ; contributions open source ou side-projects publics.
- Disqualifiant : aucune expérience de mise en production en autonomie ; refus de toucher au front ou au back ; rejet systématique des frameworks modernes.
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].
- Avantages : [mutuelle, tickets resto, RTT, BSPCE, télétravail policy, budget matériel, budget formation / conférences].
- Stack : [à compléter : front, back, DB, infra, CI/CD, monitoring].
Fourchette salariale
Salaire fixe annuel brut
Fourchette de référence pour un·e Développeur·euse Full-stack mid-level (3 à 6 ans d'expérience pro) en PME française. Île-de-France SaaS / scale-up tirent vers le haut (60-80 k€) ; les régions et secteurs traditionnels tirent vers le bas (40-50 k€). Stack moderne (React + Node ou Python, Postgres, Kubernetes) tire vers le haut ; stack legacy (PHP procédural, jQuery, MySQL non versionné) tire vers le bas.
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
Où sourcer ce profil
-
LinkedIn
800-1 200 € / mois (Recruiter Lite, sourcing actif)Canal principal pour les profils tech en France. Le sourcing actif (Recruiter Lite + InMails ciblés) est nettement plus efficace que les Job Posts seuls : les bon·ne·s développeur·euse·s ne consultent quasi jamais le feed Jobs. Filtrez précisément sur la stack technique (« React + Node » vs « TypeScript » seul ramène trop de bruit) et la séniorité avant de contacter. Personnalisez systématiquement le premier message ; les messages génériques ont un taux de réponse < 5 %.
-
Welcome to the Jungle
Dès 990 € HT / offreForte audience tech scale-up et PME modernes, surtout à Paris, Lyon, Bordeaux, Nantes. Les candidat·e·s WTTJ valorisent la mission, la stack, et la culture de l'équipe technique (vidéos, photos d'équipe, témoignages). Bien adapté pour les marques employeur jeunes ou si vous recrutez sur un produit nouveau. Moins efficace en région ou pour les stacks legacy.
-
Stack Overflow Jobs / autres niches tech
Variable selon plateforme ; sponsoring 200-600 € / offreStack Overflow Talent (fermé fin 2024 mais l'audience reste présente sur d'autres plateformes), HelloTalent, et les communautés Discord / Slack tech sont des canaux de niche utiles pour les profils seniors qui ne sont plus sur LinkedIn. Plus efficace pour stacks spécifiques (Rust, Elixir, Go) que pour les stacks mainstream. À combiner avec une présence active de l'équipe technique sur ces communautés.
Playbook d'évaluation
Le rôle de Développeur·euse Full-stack se signale à travers cinq stades d'évaluation. Le test technique (stade 4) doit être réaliste et borné dans le temps : un test de 8h prend 24h en pratique, démotive les bon·ne·s candidat·e·s et n'évalue pas mieux qu'un test de 2-3h bien construit.
-
Stade 1: Lecture du CV
Cherchez la cohérence stack (un·e profil React + Python ne se replonge pas dans Java sans 3-6 mois de réadaptation), la stabilité (durée minimale 18-24 mois sur les postes précédents), et les signaux d'autonomie (projets perso, contributions open source, side-projects). Le diplôme compte moins que les 3-5 dernières années d'expérience : un·e autodidacte avec 5 ans de production solide vaut plus qu'un·e diplômé·e top école avec 2 ans de stage prolongé.
-
Stade 2: Phone screen (30 min)
Trois questions seulement : (1) « Décrivez le projet le plus récent dont vous êtes le·la plus fier·ère ; quelle a été votre contribution exacte ? », (2) « Quelle décision technique avez-vous prise récemment dont vous doutez encore ? » (humilité et rétrospection), (3) « Pourquoi un changement maintenant ? ». Sortie : go / no-go en 5 min, pas plus. Évitez les questions « gotcha » techniques à ce stade.
-
Stade 3: Entretien technique (60-90 min)
Pair-programming ou code review sur un exercice borné (45-60 min), suivi de 15-30 min de Q&A sur l'architecture et les décisions techniques. Évaluez la capacité à raisonner à voix haute, à demander des clarifications, à itérer. Évitez les algorithmes purement académiques sans rapport avec le métier ; privilégiez un exercice qui ressemble au quotidien (refactoring, ajout d'une feature, debug d'un cas non couvert).
-
Stade 4: Mise en situation système (60 min)
Discussion d'architecture sur un cas concret : « Comment concevriez-vous un système de [feature spécifique au produit] ? » Évaluez la capacité à clarifier les contraintes avant de proposer, à arbitrer entre simplicité et scalabilité, à reconnaître les zones d'incertitude. C'est le stade le plus prédictif pour un·e Full-stack qui devra prendre des décisions techniques en autonomie en PME.
-
Stade 5: Références (vérification structurée)
Appelez deux références : un·e ancien·ne lead tech ou manager direct et un·e ancien·ne collègue développeur·euse. Posez les mêmes 4 questions : « 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 de décision technique difficile prise en autonomie ? ». La 4e question révèle le vrai signal d'autonomie.
Questions d'entretien structurées
-
Comportementale Décision technique Décrivez la décision technique la plus difficile 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 : identification des contraintes, arbitrages explicites, consultation des parties concernées, validation a posteriori avec données. Bonus : la·le candidat·e mentionne avoir changé d'avis en cours de route ou avoir documenté la décision pour les futur·e·s. Les candidat·e·s qui décrivent une décision « évidente » avec recul révèlent qu'ils·elles n'ont jamais vraiment arbitré.
-
Comportementale Debug et investigation Parlez-moi d'un bug en production que vous avez résolu. Quel était le symptôme, comment avez-vous diagnostiqué, et combien de temps a-t-il fallu ?
Ce qu'une bonne réponse révèleMéthode de debug structurée : reproduction, logs, instrumentation, hypothèses validées par expérimentation. Honnêteté sur la durée (un vrai bug de prod dure rarement < 30 min). Bonus : la·le candidat·e cite la cause profonde et le correctif systémique (pas seulement le hotfix). Les réponses « j'ai redémarré le service » sans diagnostic révèlent une faiblesse d'investigation.
-
Comportementale Apprentissage et humilité Décrivez un moment où vous avez dû refactorer ou réécrire du code que vous aviez vous-même écrit quelques mois auparavant. Que s'était-il passé entre-temps ?
Ce qu'une bonne réponse révèleHumilité technique et capacité à apprendre. Bonus : la·le candidat·e identifie ce qu'il·elle aurait fait différemment dès le départ. Les candidat·e·s qui n'ont « jamais vraiment dû refactorer leur code » mentent ou n'ont pas porté de code en production sur la durée.
-
Situationnelle Courage technique Vous découvrez en revue de code une vulnérabilité de sécurité (injection SQL, secret en clair, etc.) dans une PR d'un·e collègue senior. Comment réagissez-vous ?
Ce qu'une bonne réponse révèleCapacité à pointer une faiblesse technique sans braquer : commentaire factuel sur la PR (« voici le risque, voici comment je propose de le résoudre »), proposition d'une solution, escalade à la·au lead 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.
-
Situationnelle Communication produit Un·e Product Manager vous demande une feature qui prendrait 3 semaines selon votre estimation. Le·la PM veut la livrer en 1 semaine. Comment réagissez-vous ?
Ce qu'une bonne réponse révèleClarification du besoin avant de négocier la timeline (peut-être que la feature peut être livrée en 2 phases, ou simplifiée). Proposition d'options : MVP en 1 semaine + V2 en 2 semaines ; coupes explicites de scope ; ajout de personnel. Les réponses « je peux le faire en 1 semaine si je travaille les week-ends » sont un drapeau rouge (signal de mauvaise gestion de soi).
-
Situationnelle Pragmatisme et priorisation Vous rejoignez une équipe avec une dette technique importante : tests insuffisants, déploiements manuels, monitoring quasi-absent. Quel est votre plan en 30 jours ?
Ce qu'une bonne réponse révèleDiagnostic d'abord : ne pas tout vouloir réparer en même temps. Priorisation par risque / impact (typiquement : monitoring d'abord pour voir, puis tests sur les zones critiques, puis automatisation du déploiement). Validation avec l'équipe et la·le lead avant d'engager. Les candidat·e·s qui se lancent dans la refonte complète révèlent un manque de pragmatisme.
-
Étude de cas Design système Conception : nous voulons ajouter à notre application un système de notification temps réel (par exemple : « un·e collègue a commenté votre document »). Comment concevez-vous cela ?
Ce qu'une bonne réponse révèleClarifications avant de proposer (volume attendu, contraintes de latence, devices supportés, persistance des notifs non vues). Architecture cohérente : push (WebSocket ou Server-Sent Events) vs pull (polling), persistence (DB de notifs), idempotence des envois, fallback email. Bonus : reconnaissance des zones d'incertitude (« je ferais un POC avant de m'engager sur WebSocket vs SSE »). Les candidat·e·s qui plongent dans le code sans clarifier les contraintes révèlent une faiblesse de design.
-
Étude de cas Debug et investigation Debug : votre API renvoie une réponse 500 sur 2 % des requêtes. Les logs ne montrent pas d'erreur particulière. Comment investiguez-vous ?
Ce qu'une bonne réponse révèleMéthode structurée : (1) augmenter le niveau de log temporairement sur les endpoints concernés, (2) corréler avec les métriques (latence, taille de payload, source), (3) identifier un pattern (heure de la journée, type de requête, utilisateur·rice spécifique), (4) hypothèses ordonnées (timeout DB, race condition, mémoire). Les candidat·e·s qui se précipitent sur « c'est sûrement la DB » sans investiguer révèlent un biais.
-
Étude de cas Optimisation Performance : une page de votre application met 8 secondes à charger. Vous avez 1 semaine pour la passer sous 2 secondes. Plan d'action ?
Ce qu'une bonne réponse révèleMesurer avant d'optimiser : DevTools, Lighthouse, profiler côté serveur. Identifier le bottleneck (rendering, requêtes DB, payload, CDN). Hiérarchiser par effort × impact. Les réponses « je vais ajouter du cache » sans diagnostic révèlent un réflexe d'optimisation prématurée. Bonus : la·le candidat·e mentionne qu'une page à 8s en prod indique souvent un problème systémique (N+1 queries, payload énorme) plus qu'une optimisation locale à faire.
-
Technique Qualité du code Quelle est votre approche du testing ? Décrivez votre dernier projet : combien de tests, quels types, quelle couverture, et que mesurez-vous vraiment ?
Ce qu'une bonne réponse révèleCompréhension de la pyramide de tests (beaucoup d'unitaires, moins d'intégration, peu d'e2e). Distinction entre couverture et utilité (90 % de couverture sur du code trivial vaut moins que 60 % sur la logique métier critique). Bonus : la·le candidat·e cite une fois où un test a évité une régression réelle. Les candidat·e·s qui répondent « je teste à 100 % » sans nuancer révèlent une faiblesse de jugement.
-
Technique Fondamentaux back-end Différence entre une transaction DB et un lock applicatif ? Dans quel cas utiliseriez-vous l'un plutôt que l'autre ?
Ce qu'une bonne réponse révèleTransaction DB = atomicité + isolation gérées par la DB (ACID), bornée à la durée de la transaction. Lock applicatif = coordination entre processus / instances via Redis, Zookeeper, ou similaire ; utile quand la coordination dépasse une seule DB (microservices, queue de tâches). Risque de deadlock pour les deux. Les candidat·e·s qui ne savent pas distinguer ces deux mécanismes vont créer des race conditions en production.
-
Technique Pragmatisme et priorisation Vous arrivez sur un codebase React mal organisé : composants à 500 lignes, props drilling 5 niveaux, pas de séparation logique / présentation. Plan d'action en 60 jours sans tout casser ?
Ce qu'une bonne réponse révèleApproche progressive : (1) cartographier les composants critiques et les patterns récurrents, (2) extraire les hooks et la logique métier d'abord (impact massif, risque faible), (3) découper les gros composants par boundary métier (pas par contrainte technique), (4) introduire un state-manager si nécessaire (Context ou Zustand pour PME, Redux si volume) seulement sur les zones où le props drilling est réellement douloureux. Les candidat·e·s qui veulent tout réécrire en React Server Components dès le jour 1 manquent de pragmatisme.
-
Valeurs Coachabilité 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. Les candidat·e·s qui décrivent avoir « expliqué leur logique » au reviewer au lieu de l'écouter révèlent une faiblesse de coachabilité critique pour le travail en équipe.
-
Valeurs Mentorat 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, partage de bonnes pratiques. Les candidat·e·s qui répondent « j'aide quand on me demande » sans plus de précision révèlent une posture passive. En PME où l'équipe technique est petite, la capacité à transmettre est essentielle pour la pérennité.
-
Valeurs Jeu d'équipe produit Comment travaillez-vous avec un·e Product Manager ou un·e designer ? Décrivez une situation où vous avez poussé en arrière sur un brief.
Ce qu'une bonne réponse révèlePosture de partenariat : challenge constructif basé sur la faisabilité ou la complexité, proposition d'alternatives. Bonus : la·le candidat·e cite un cas où il·elle a accepté le brief initial après échange (n'est pas en mode opposition systématique). Les candidat·e·s qui décrivent les PMs / designers comme « ne comprenant pas la 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 | Bute sur les fondamentaux (HTTP, transactions DB, asynchrone). Cherche les solutions par essai-erreur sans modèle mental clair. Difficile à charger sur un nouveau langage ou framework. | Maîtrise la stack actuelle en autonomie. Sait apprendre un nouveau framework en 2-4 semaines. Comprend les fondamentaux suffisamment pour déboguer en profondeur quand nécessaire. | Référent·e technique sur sa stack et capable de basculer sur une nouvelle stack en quelques semaines. Anticipe les pièges classiques (race conditions, fuites mémoire, edge cases). Construit des abstractions utiles, pas prématurées. |
| Design système et pragmatisme | Plonge dans le code sans clarifier les contraintes. 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 : ne sur-conçoit pas pour le futur incertain, mais identifie les zones où un peu de structure paiera. Sait pivoter quand l'hypothèse initiale ne tient pas. | Conçoit des systèmes qui vieillissent bien : abstractions justes, dépendances minimales, frontières métier claires. Reconnaît ses zones d'incertitude et propose des POCs ciblés. Forme l'équipe sur la pensée systèmes. |
| Qualité et hygiène du code | Pas de stratégie de test claire ; ajoute des tests « pour faire couverture ». Code mal structuré (composants à 500 lignes, copier-coller, magic numbers). Reviews superficielles. | Pyramide de tests pertinente sur les zones métier. Code lisible avec naming clair et fonctions courtes. Reviews structurées avec feedback actionnable. Refactor au passage quand pertinent. | Référence de l'équipe sur la qualité : 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. |
| Autonomie et débrouillardise | Bloque sur un sujet inconnu sans demander d'aide pendant des heures, ou demande de l'aide au moindre obstacle. Pas de stratégie de debug structurée. | Sait diagnostiquer en autonomie sur les sujets familiers, demande de l'aide après une investigation préalable (résumé du problème, hypothèses, ce qui a déjà été essayé). | Débrouillardise élevée sur des sujets non familiers : lit le code source des dépendances, instrumente le runtime, isole les causes profondes. Documente les apprentissages pour l'équipe. |
| Communication et jeu d'équipe | Explique mal son travail aux non-techniques. Posture défensive en review. Travaille en silo, partage peu son contexte. Posture d'opposition systématique face aux PMs / designers. | Sait expliquer son travail à un·e PM ou un·e dirigeant·e en langage clair. Reçoit la review constructivement. Partage son contexte en revues d'équipe et 1:1. | Pont entre la tech et les autres fonctions. Anime les debriefs techniques, vulgarise les arbitrages, négocie les timelines de manière transparente. Référence dans l'équipe pour la communication transverse. |
Plan 30/60/90 jours
À J+30
- Setup complet de l'environnement local et déploiement d'une PR en production (même triviale) validée
- Lecture et compréhension du code des 3 modules les plus critiques de la stack métier
- Premier 1:1 documenté avec la·le tech lead sur les conventions, la dette identifiée, et les priorités
- Première PR substantive (fix de bug ou petite feature) reviewée et mergée
À J+60
- Livraison d'une feature complète bout en bout (front + back + déploiement) en autonomie
- Première review de PR d'un·e collègue avec feedback structuré, sans juste cliquer approve
- Premier on-call ou astreinte (si applicable) avec gestion d'au moins un incident
- Documentation rédigée ou mise à jour sur un module récemment touché
À 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 en autonomie sur un sujet ambigu (refactor, choix de librairie, design)
- 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
Erreurs de recrutement courantes pour ce poste
-
Embaucher sur le diplôme ou la prestige de la boîte précédente plutôt que sur le code
Un·e diplômé·e d'une grande école avec 2 ans dans une grosse boîte n'est pas forcément plus opérationnel·le qu'un·e autodidacte avec 5 ans en production en startup. Les grandes structures alimentent leurs développeur·euse·s en specs claires, code reviews exigeantes, et tooling solide ; ils·elles n'ont pas forcément l'autonomie nécessaire pour une PME où il faut tout faire. Privilégiez le test technique et la mise en situation système au CV.
-
Sur-évaluer les fondamentaux algorithmiques pour un poste produit
Un·e Full-stack en PME n'a quasi jamais besoin d'optimiser un algorithme de graphe ou de réimplémenter un B-tree. Les tests « LeetCode » filtrent les profils académiques au détriment des profils opérationnels (qui sauront livrer une feature complète en autonomie). Privilégiez les exercices qui ressemblent au quotidien : ajouter une feature, débuguer un cas non couvert, refactorer un composant trop chargé.
-
Faire des tests techniques de 8h ou plus
Un test de 8h prend 24h en pratique pour un·e candidat·e (avec investissement émotionnel), démotive les meilleur·e·s profils (qui ont d'autres pistes en parallèle), et n'évalue pas mieux qu'un test bien construit de 2-3h. Cherchez à mesurer la qualité du raisonnement, pas la complétude. Bornez explicitement le temps attendu et acceptez les solutions incomplètes mais bien argumentées.
-
Ignorer la fit avec la stack et l'écosystème
Un·e développeur·euse React + Node solide ne devient pas immédiatement productif·ve sur Vue + Python sans 2-4 semaines de prise en main. Un·e profil avec stack proche (React + TypeScript + Postgres pour une PME sur même stack) sera productif·ve en 1-2 semaines. La fit stack compte plus que la séniorité absolue pour un·e Full-stack mid-level. Précisez votre stack en bonne place dans l'annonce.
-
Sous-estimer l'importance de la communication transverse
Un·e Full-stack en PME parle quasi quotidiennement avec un·e PM, un·e designer, parfois directement avec la·le dirigeant·e ou un·e client·e. Recruter un·e profil techniquement solide mais peu à l'aise avec la communication transverse produit des frictions : briefs mal compris, timelines opaques, conflits avec le Produit. Évaluez explicitement la communication en entretien (questions situationnelles avec un·e PM, vulgarisation d'un sujet technique).
Questions fréquentes
-
Quel est le salaire d'un·e Développeur·euse Full-stack en PME française ?
La fourchette de référence pour un·e Développeur·euse Full-stack mid-level (3 à 6 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 / scale-up tirent vers le haut (60-80 k€) ; les régions et secteurs traditionnels tirent vers le bas. Ce poste n'a généralement pas de variable structurel en PME, mais peut inclure des BSPCE (stock-options) dans les scale-up.
-
Quelle est la différence entre Développeur·euse Full-stack, Front-end et Back-end ?
Le·la Front-end se concentre sur l'interface utilisateur (React, Vue, CSS, accessibilité, performance perçue). Le·la Back-end se concentre sur l'API, la base de données, la scalabilité, la sécurité. Le·la Full-stack couvre les deux à un niveau intermédiaire-avancé ; en PME, le·la Full-stack est souvent le profil par défaut car la spécialisation pure n'est pas justifiée par le volume. Pour des PME > 30 développeur·euse·s, la spécialisation devient plus pertinente.
-
Combien de temps faut-il pour recruter un·e Développeur·euse Full-stack en France ?
Comptez 45 à 75 jours entre la publication de l'annonce et la signature pour un·e profil mid-level. Le marché tech reste tendu en 2025-2026, surtout pour les profils avec stack moderne (React + Node ou Python, Postgres, Kubernetes). Les délais s'allongent en septembre / janvier. Réduire le délai en dessous de 45 jours impose en général de sacrifier le test technique, ce qui dégrade fortement la qualité du recrutement.
-
Faut-il un diplôme spécifique pour recruter un·e Développeur·euse Full-stack ?
Non. Le marché tech français accepte largement les profils autodidactes ou issus de bootcamps (Le Wagon, 42, OpenClassrooms) dès qu'ils·elles ont 3-5 ans de production solide. Le diplôme (école d'ingénieur, master informatique) est rassurant pour les profils junior mais perd de l'importance après 5 ans d'expérience. Évaluez sur le code et la résolution de problèmes, pas sur le pedigree académique.
-
Quelles sont les obligations légales d'une annonce Développeur·euse en France ?
Trois obligations principales : (1) intitulé neutre ou avec mention H / F (article L. 1142-1 du Code du travail), (2) affichage de la fourchette salariale ou communication avant le premier entretien (directive 2023 / 970, transposition au 7 juin 2026), (3) transparence sur tout outil d'IA utilisé pour le tri des candidatures et supervision humaine garantie (EU AI Act, applicable au 2 août 2026).
-
Faut-il faire un test technique systématique ?
Oui, mais court (2-3h max) et réaliste. Un test technique bien construit est le meilleur prédicteur de performance future, devant le diplôme et le pedigree. Évitez les tests algorithmiques académiques sans rapport avec le quotidien (LeetCode hard) ; privilégiez les exercices qui ressemblent au métier (ajouter une feature, débuguer, refactorer). Bornez le temps explicitement et acceptez les solutions incomplètes mais bien argumentées.