Recruter et fidéliser son équipe

Objectif : Maîtriser l’art du recrutement tech

Bon, maintenant qu’on a établi que vous êtes CTO et que vous avez une vision, il faut recruter l’équipe qui va l’exécuter. Et là, petit réveil brutal : recruter des développeurs en 2025, c’est comme essayer d’attraper des licornes avec un filet à papillons.

Le marché est tendu, les bons développeurs ont 15 offres par semaine, et tout le monde promet la même chose : “startup innovante, stack moderne, équipe sympa, machine a smoothie”. Alors, comment vous démarquez-vous ? Comment construire l’équipe de vos rêves sans y laisser votre santé mentale et votre budget ?

Définir ses besoins vs profils disponibles

L’audit de compétences : où vous en êtes vraiment

Avant de recruter, il faut savoir ce que vous avez déjà. Et soyons honnêtes : la plupart des CTOs recrutent au feeling, sans vraiment analyser leurs vrais besoins.

Exercice pratique : la matrice de compétences

Listez vos technologies/domaines clés, puis évaluez chaque membre de l’équipe :

Profil	React	Node.js	DevOps	Mobile	IA/ML
Dev 1 (Senior)	4/5	5/5	2/5	1/5	1/5
Dev 2 (Mid)	3/5	3/5	1/5	4/5	1/5
Dev 3 (Junior)	2/5	2/5	1/5	1/5	1/5

Analyse :

• On a une expertise solide en backend (Node.js)
• On est faible en DevOps (risque de bottleneck)
• Personne ne maîtrise l’IA (alors que c’est dans la roadmap)
• Paul est seul sur le mobile (bus factor = 1)

Conclusion : Il faut recruter un DevOps senior et quelqu’un avec de l’expérience IA. Le mobile peut attendre.

La réalité du marché : offre vs demande

Les profils en tension (difficiles à recruter) :

• DevOps/SRE expérimentés
• Architectes solutions
• Data Engineers
• Experts sécurité
• Développeurs mobiles natifs
• Spécialistes IA/ML

Les profils plus accessibles :

• Développeurs fullstack juniors/mid
• Développeurs frontend React/Vue
• Développeurs backend classiques (PHP, Java, .NET)

Stratégie d’adaptation :

Option 1 : Recruter les profils rares en priorité Même s’ils coûtent cher, ils débloqueront le reste de l’équipe.

Option 2 : Former en interne Prendre des profils junior/mid motivés et les faire monter en compétences.

Option 3 : Externaliser temporairement Freelances ou prestataires pour les compétences très spécialisées.

Les différents types de recrutement

Le recrutement de croissance (90% des cas)

• Objectif : Augmenter la capacité de livraison
• Profil recherché : Développeurs expérimentés dans votre stack
• Urgence : Modérée
• Budget : Standard

Le recrutement de compétence (expertise manquante)

• Objectif : Acquérir une nouvelle compétence
• Profil recherché : Expert dans un domaine spécifique
• Urgence : Variable selon la criticité
• Budget : Élevé

Le recrutement de remplacement (départ imprévu)

• Objectif : Remplacer quelqu’un qui part
• Profil recherché : Similar ou meilleur que le partant
• Urgence : Haute
• Budget : Variable

Le recrutement d’opportunité (perle rare disponible)

• Objectif : Saisir une opportunité
• Profil recherché : Talent exceptionnel
• Urgence : Immédiate
• Budget : À ajuster selon le potentiel

Process de recrutement efficace

Le pipeline de recrutement

Étape 1 : Sourcing (semaine 1-2)

• Diffusion de l’annonce (job boards, réseau, cooptation)
• Réception des candidatures
• Premier tri CV (20 minutes max par CV)

Étape 2 : Pré-qualification (semaine 2-3)

• Appel téléphonique (15-20 minutes)
• Vérification des prérequis
• Évaluation de la motivation

Étape 3 : Évaluation technique (semaine 3-4)

• Test technique à la maison OU
• Live coding en visio OU
• Pair programming

Étape 4 : Entretiens (semaine 4-5)

• Entretien technique approfondi
• Entretien culture/fit
• Rencontre avec l’équipe

Étape 5 : Décision et négociation (semaine 5-6)

• Débriefing interne
• Offre et négociation
• Références et background check

Total : 5-6 semaines max. Au-delà, vous perdez les bons candidats.

L’annonce qui fait la différence

Ce que tout le monde écrit : “Startup innovante cherche développeur passionné pour rejoindre notre équipe dynamique dans un environnement stimulant avec des technologies de pointe.”

Ce que vous devriez écrire :

# Senior Backend Developer - On cherche quelqu'un qui aime résoudre des problèmes complexes

## Qui on est vraiment
- Fintech de 45 personnes, rentable depuis 2 ans
- On traite 100M€ de transactions par mois (ça grandit vite)
- Équipe tech de 12 personnes, 0% de turnover sur les 18 derniers mois
- Remote-friendly, mais on aime se voir à Lyon 2j/semaine

## Le job concrètement
- Tu vas architecturer notre passage de 100M€ à 1Md€ de volume
- Stack : Node.js/TypeScript, PostgreSQL, Redis, AWS
- Challenges : latence sub-100ms, sécurité bancaire, compliance
- Pas de legacy pourri : tout a moins de 3 ans

## Ce qu'on cherche
- 5+ ans sur du Node.js en prod avec de gros volumes
- Tu as déjà optimisé des bases de données sous charge
- Tu connais AWS (ou tu veux apprendre)
- Tu aimes expliquer et partager tes connaissances

## Ce qu'on offre
- 55-75K€ selon expérience + BSPCE
- MacBook Pro M3, setup bureau 2000€
- 2j/semaine en remote
- Budget formation 3000€/an
- Mutuelle 100% prise en charge

## Le process (transparent)
1. Appel de 20min avec moi (Kevin, CTO)
2. Test technique (2h max, qu'on paye 200€)
3. Entretien technique avec l'équipe (1h)
4. Café avec 2-3 personnes de l'équipe
5. Réponse sous 48h

Pas de bullshit, que de la transparence !

Pourquoi ça marche mieux :

• Vous donnez des infos concrètes (chiffres, stack, challenges)
• Vous montrez que vous connaissez le métier (sub-100ms, gros volumes)
• Vous êtes transparents sur le process et la rémunération
• Vous assumez vos contraintes (présence 2j/semaine)

L’évaluation technique : au-delà du code

Test technique à la maison

✅ Les bonnes pratiques :

• 2-3h maximum (et vous payez le temps passé)
• Problème proche de votre réalité métier
• Plusieurs solutions possibles
• Code review comme évaluation finale

❌ Les erreurs à éviter :

• Test générique trouvé sur internet
• Plus de 4h de travail
• Évaluation uniquement sur le résultat final
• Demander du code parfait

Framework de conception de tests techniques :

Principes de design d’un bon test :

• Réalisme : Problème similaire à ceux rencontrés dans le poste
• Scope limité : Faisable dans le temps imparti (2-3h max)
• Évaluation holistique : Architecture, lisibilité, choix techniques
• Respect du candidat : Compensation financière du temps passé

Questions stratégiques pour concevoir vos tests :

• Qu’est-ce qui différencie un bon développeur d’un excellent dans notre contexte ?
• Quelles compétences techniques sont vraiment critiques pour le poste ?
• Comment évaluer la capacité d’apprentissage et d’adaptation ?
• Quel niveau de séniorité nous permet de prendre des risques sur ce recrutement ?

Alternatives aux tests techniques :

• Revue de code : Analyse d’un code existant avec propositions d’amélioration
• Architecture review : Discussion sur un design de système
• Problem-solving : Résolution de problème en live avec justification des choix
• Portfolio review : Analyse approfondie des projets passés du candidat

Live coding / Pair programming

Structure d’une session de 1h :

• 10 min : Présentation du problème et discussion
• 40 min : Coding collaboratif
• 10 min : Debriefing et questions

Ce qu’on évalue :

• Approche du problème (questions, découpage)
• Qualité du code en temps réel
• Capacité à expliquer ses choix
• Réaction aux suggestions
• Gestion du stress

Mon retour d’expérience : Le live coding révèle mieux la personnalité du candidat. J’ai recruté des gens moyens en test technique mais excellents en pair programming (et vice versa).

Grille d’entretien technique

Section 1 : Expérience (15 min)

• Peux-tu me parler de ton projet le plus complexe techniquement ?
• Quel a été ton plus gros échec technique et qu’est-ce que tu en as appris ?
• Comment tu te tiens au courant des évolutions technologiques ?

Section 2 : Architecture (20 min)

• Comment tu architecturerais un système qui doit gérer 1M de requêtes/jour ?
• Quels sont les trade-offs entre microservices et monolithe ?
• Comment tu gères la montée en charge d’une base de données ?

Section 3 : Pratiques (15 min)

• Comment tu organises tes tests ?
• Quel est ton workflow de développement idéal ?
• Comment tu gères la dette technique ?

Section 4 : Collaboration (10 min)

• Comment tu donnes du feedback sur le code d’un collègue ?
• Comment tu gères un désaccord technique avec un collègue ?
• Qu’est-ce qui te motive le plus dans le travail en équipe ?

Red flags techniques :

• Ne sait pas expliquer ses choix techniques
• N’a jamais eu de problèmes ou d’échecs
• Critique violemment ses anciens collègues/projets
• Ne pose aucune question sur votre contexte
• Donne des réponses théoriques sans expérience pratique

Onboarding des développeurs

La première impression compte

J-1 : Avant l’arrivée

• Setup complet du poste de travail
• Accès à tous les outils (Slack, GitHub, AWS, etc.)
• Documentation d’onboarding à jour
• Première mission préparée

Jour 1 : L’accueil

• Petit-déjeuner/déjeuner avec l’équipe
• Tour des locaux et présentation des collègues
• Remise du matériel (qui marche)
• Première mini-mission réalisable en 2h

Exemple de mission J1 : “Corrige ce petit bug dans le code de démo (déjà identifié et facile), pousse ta PR, fais-la reviewer par Sarah. Objectif : que tu fasses ton premier déploiement dès le premier jour.”

Plan d’onboarding 30-60-90 jours

Semaine 1-2 : Découverte

• Objectif : Comprendre le produit et l’architecture
• Actions :
  • Formation produit (1/2 journée)
  • Deep dive architecture avec un senior (1 journée)
  • Lecture de code et documentation
  • 2-3 petites tâches pour prendre ses marques
• Succès : Peut expliquer l’architecture globale et le business model

Semaine 3-4 : Première contribution

• Objectif : Livrer sa première feature
• Actions :
  • Feature complète mais non-critique
  • Pairing avec un développeur expérimenté
  • Participation aux rituels d’équipe (standup, retro)
• Succès : Feature livrée en prod, feedback positif de l’équipe

Mois 2 : Montée en autonomie

• Objectif : Devenir autonome sur les tâches courantes
• Actions :
  • Features plus complexes
  • Participation aux décisions techniques
  • Première intervention sur un bug prod
• Succès : N’a plus besoin d’aide pour les tâches de base

Mois 3 : Intégration complète

• Objectif : Être un membre productif de l’équipe
• Actions :
  • Mentoring d’un nouveau développeur ou stagiaire
  • Proposition d’améliorations techniques
  • Participation aux estimations et planifications
• Succès : L’équipe le considère comme un collègue à part entière

Le buddy système

Chaque nouveau développeur a un “buddy” (parrain) pour les 3 premiers mois.

Rôle du buddy :

• Point de contact privilégié pour toutes les questions
• Pas le manager direct (pour éviter la pression hiérarchique)
• Développeur senior motivé pour transmettre

Responsabilités du buddy :

• 1 point quotidien les 2 premières semaines
• 1 point hebdomadaire le premier mois
• Feedback au manager sur l’intégration
• Aide technique sans faire à la place

Gérer les départs et turnover

Prévenir les départs

Les signaux d’alarme :

• Baisse de motivation visible
• Participation réduite aux discussions
• Négligence dans le code ou les process
• Demandes de formation sur des technos externes
• Questions sur l’évolution de carrière

Les actions préventives :

• 1-on-1 réguliers et de qualité
• Plan de carrière clair pour chacun
• Budget formation utilisé
• Projets stimulants pour les seniors
• Reconnaissance (technique et financière)

L’entretien de départ

Quand quelqu’un annonce son départ, l’entretien de départ est crucial.

Objectifs :

• Comprendre les vraies raisons du départ
• Identifier les améliorations possibles
• Garder de bonnes relations (futur réseau)
• Organiser la transition

Questions qui marchent :

• Qu’est-ce qui t’a donné envie de partir ?
• Qu’est-ce qu’on aurait pu faire différemment ?
• Qu’est-ce que tu vas regretter ici ?
• Qu’est-ce que tu ne regretteras pas ?
• Comment on peut améliorer l’expérience pour tes successeurs ?

Important : Écoutez vraiment, prenez des notes, et agissez sur les feedbacks récurrents.

Organiser la transition

Phase 1 - Annonce (J-30) :

• Communication transparente à l’équipe
• Planification de la passation
• Début du recrutement du remplaçant

Phase 2 - Documentation (J-20) :

• Documentation du code et des processus
• Transfert de connaissance avec l’équipe
• Formation d’un ou plusieurs repreneurs

Phase 3 - Passation (J-10) :

• Finalisation des projets en cours
• Handover des responsabilités
• Pot de départ (toujours)

Règle d’or : Ne jamais prendre un départ personnellement. Les gens partent pour plein de raisons, souvent indépendantes de vous.

Outils

Grille d’entretien technique

# Entretien technique - [Nom du candidat]

## Informations générales
- Poste :
- Date :
- Interviewers :

## 1. Expérience technique (15 min)

### Questions
- [ ] Présentation du parcours technique
- [ ] Projet le plus complexe techniquement
- [ ] Plus gros échec technique et apprentissages
- [ ] Veille technologique

### Évaluation
- Cohérence du parcours : /5
- Profondeur technique : /5
- Capacité d'apprentissage : /5

## 2. Architecture & Design (20 min)

### Questions
- [ ] Design d'un système scalable
- [ ] Trade-offs techniques (ex: microservices vs monolithe)
- [ ] Gestion de la montée en charge
- [ ] Problème d'architecture de votre contexte

### Évaluation
- Vision architecturale : /5
- Compréhension des trade-offs : /5
- Pragmatisme : /5

## 3. Pratiques de développement (15 min)

### Questions
- [ ] Approche des tests
- [ ] Workflow de développement
- [ ] Gestion de la dette technique
- [ ] Code review

### Évaluation
- Rigueur technique : /5
- Bonnes pratiques : /5
- Qualité du code : /5

## 4. Collaboration (10 min)

### Questions
- [ ] Feedback sur le code
- [ ] Gestion des désaccords techniques
- [ ] Motivation dans le travail d'équipe
- [ ] Questions sur notre équipe/contexte

### Évaluation
- Soft skills : /5
- Culture fit : /5
- Motivation : /5

## Synthèse
**Points forts :**

**Points d'amélioration :**

**Recommandation :** ✅ À poursuivre / ❌ À écarter / ⚠️ Mitigé

**Commentaires libres :**

Plan d’onboarding 30-60-90 jours

# Plan d'onboarding - [Nom du nouveau développeur]

## Semaine 1-2 : Découverte

### Jour 1
- [ ] Petit-déjeuner d'accueil avec l'équipe
- [ ] Setup poste de travail et accès
- [ ] Présentation équipe et tour des locaux
- [ ] Première mini-mission (2h max)

### Semaine 1
- [ ] Formation produit (1/2 journée avec [CPO/PM])
- [ ] Deep dive architecture (1 journée avec [Tech Lead])
- [ ] Lecture documentation technique
- [ ] 2-3 petites tâches pour prendre ses marques

### Fin semaine 2 - Checkpoint
- [ ] Peut expliquer l'architecture globale
- [ ] Comprend le business model
- [ ] Connait les outils et processus
- [ ] Feedback buddy + manager

## Semaine 3-4 : Première contribution

### Objectifs
- [ ] Livrer sa première feature complète
- [ ] Participer activement aux rituels
- [ ] Commencer le pairing avec [Senior Dev]

### Tâches
- [ ] Feature : [Description de la première feature]
- [ ] Code review avec [Senior Dev]
- [ ] Participation standups et retro
- [ ] Déploiement en prod

### Fin semaine 4 - Checkpoint
- [ ] Feature livrée et en prod
- [ ] Feedback positif de l'équipe
- [ ] Autonomie sur les tâches simples

## Mois 2 : Montée en autonomie

### Objectifs
- [ ] Features plus complexes en autonomie
- [ ] Participation décisions techniques
- [ ] Première intervention bug prod

### Tâches
- [ ] Feature complexe : [Description]
- [ ] Participation architecture review
- [ ] Formation spécialisée : [Sujet]
- [ ] Astreinte junior avec [Senior]

### Fin mois 2 - Checkpoint
- [ ] Autonome sur tâches courantes
- [ ] Propose des améliorations
- [ ] Intégré aux décisions d'équipe

## Mois 3 : Intégration complète

### Objectifs
- [ ] Mentoring nouveau développeur/stagiaire
- [ ] Participation estimations
- [ ] Proposition d'améliorations techniques

### Tâches
- [ ] Buddy d'un nouveau/stagiaire
- [ ] Présentation tech talk interne
- [ ] Amélioration technique proposée
- [ ] Participation planning poker

### Fin mois 3 - Évaluation finale
- [ ] Considéré comme membre à part entière
- [ ] Feedback 360° (équipe + manager)
- [ ] Plan de développement pour les 6 prochains mois

## Ressources
- [ ] Documentation architecture : [Lien]
- [ ] Guide des bonnes pratiques : [Lien]
- [ ] Slack channels importants : [Liste]
- [ ] Contacts clés : [Liste]

## Suivi
- **Buddy assigné :** [Nom]
- **Manager :** [Nom]
- **Point hebdomadaire :** [Jour/Heure]

Tips : “Red flags en entretien”

Red flags techniques

1. Le développeur “tout-terrain”

• Prétend maîtriser 15 langages et 20 frameworks
• Ne peut pas expliquer en profondeur ses choix
• Réalité : Connaissances superficielles, va peut être galérer sur les sujets complexes

2. Le perfectionniste paralysé

• “On ne peut pas livrer tant que ce n’est pas parfait”
• N’a jamais eu de bugs en production
• Réalité : Over-engineering, livraisons trop lentes, c’est peut être pas le moment dans votre startup

3. L’expert en tout

• Critique tous vos choix techniques
• A toujours une meilleure solution
• Réalité : Ego surdimensionné, va créer des conflits

4. Le suiveur de mode

• Veut utiliser toutes les dernières technos
• Ne comprend pas les contraintes business
• Réalité : Va probablement complexifier votre stack pour la beauté de la stack

Red flags humains

5. Le critique permanent

• “Dans ma boîte précédente, tout était nul”
• Critique ses anciens collègues/managers
• Réalité : Va faire pareil chez vous dans 6 mois

6. L’individualiste

• Préfère travailler seul
• N’aime pas les code reviews
• Réalité : Va créer des silos, difficile à manager

7. Le mercenaire

• Uniquement motivé par l’argent
• Aucune question sur le produit/équipe
• Réalité : Partira à la première offre supérieure

8. Le désengagé

• Répond par monosyllabes
• Ne pose aucune question
• Réalité : Pas motivé, va faire le minimum

Red flags process

9. Le négociateur

• Négocie tout dès l’entretien (horaires, remote, congés)
• Pose des ultimatums
• Réalité : Sera problématique au quotidien

10. L’impatient

• Veut une réponse immédiate
• Presse pour accélérer le process
• Réalité : Risque de mauvaise décision, probablement plusieurs pistes

Comment réagir aux red flags :

• 1 red flag : Creusez avec des questions précises
• 2-3 red flags : Soyez vigilant, référez-vous à d’autres avis
• 4+ red flags : Passez votre chemin, même si techniquement fort

Mon expérience : J’ai recruté une fois quelqu’un avec plusieurs red flags parce qu’il était techniquement bons. Résultat : 6 mois de conflit dans l’équipe avant qu’il parte. Leçon apprise : les soft skills comptent autant que les hard skills.

Points clés à retenir

1. Analysez vos vrais besoins avant de recruter. Matrice de compétences + contexte business + réalité du marché.

2. Votre annonce fait 70% du travail. Soyez spécifiques, transparents et honnêtes sur vos contraintes.

3. Évaluez autant les soft skills que les hard skills. Un bon développeur toxique peut détruire une équipe.

4. L’onboarding commence avant le premier jour. Et dure 3 mois minimum.

5. Prévenez les départs plutôt que de les subir. 1-on-1 de qualité + plans de carrière + projets stimulants.

6. Investissez dans le long terme. Former un junior motivé peut être plus rentable que recruter un senior blasé.

Dans le prochain chapitre, on va parler de développement des talents. Parce que recruter c’est bien, mais faire grandir vos équipes, c’est encore mieux !

---

“Votre équipe n’est aussi forte que son maillon le plus faible. Mais si vous formez bien vos maillons faibles, ils deviennent vos atouts les plus forts.”