31 entretiens Go en 4 mois — les 7 étapes qui ont fait passer notre taux d’échec de 40 % à 8 %

Nous avons longtemps cru que recruter en Go était difficile parce que le vivier français était trop petit. C’est partiellement vrai, et c’est surtout une explication commode. Après avoir perdu quatre personnes en dix-huit mois sur des postes backend Go, nous avons refait le processus de zéro. Voici ce qui a changé, étape par étape, et les chiffres correspondants.

Étape 1 — Vérifier que vous avez réellement besoin de Go

La question paraît saugrenue dans un article sur le recrutement Go. Elle est pourtant à l’origine de la moitié de nos échecs passés. Deux de nos départs concernaient des postes où Go avait été choisi par préférence d’équipe, pas par contrainte technique — et où le quotidien réel consistait à écrire des points d’entrée HTTP sans aucune difficulté de concurrence.

Go est structurant dans trois situations : quand vous avez besoin de concurrence massive avec une empreinte mémoire prévisible, quand vous distribuez des binaires autonomes sans dépendance d’exécution, ou quand des temps de démarrage très courts comptent pour votre modèle de déploiement.

En dehors de ces cas, Go reste un choix parfaitement défendable — mais alors, ne construisez pas votre recrutement autour du langage. Vous rétrécissez votre vivier de 80 % pour un bénéfice qui n’existe pas dans le poste, et vous attirez des candidats qui découvriront un quotidien plus terne que l’offre.

Étape 2 — Rédiger une offre qui filtre au lieu de séduire

Notre ancienne offre listait onze technologies et promettait des « défis techniques passionnants ». Elle générait 60 à 90 candidatures par mois, dont environ cinq pertinentes. Le tri consommait plus de temps que tout le reste du processus.

La nouvelle offre tient en trois blocs. Ce que le service fait réellement, avec des ordres de grandeur : nombre de requêtes par seconde, volume de données, contrainte de latence. Ce que la personne fera les trois premiers mois, au niveau du ticket, pas de la mission. Ce que le poste implique de désagréable : astreinte, dette technique identifiée, domaine métier aride.

Ce troisième bloc a divisé le volume de candidatures par quatre et multiplié par trois le taux de candidatures pertinentes. Les développeurs expérimentés lisent la contrainte comme un signe d’honnêteté ; ceux qui fuient sont exactement ceux qui seraient partis au sixième mois.

Étape 3 — Sourcer là où les développeurs Go se trouvent vraiment

Le vivier Go français ne se trouve pas majoritairement sur les plateformes de dépôt de CV. Nos six recrutements de 2026 se répartissent ainsi : deux par cooptation interne, deux via des contributions repérées sur des dépôts open source liés à notre domaine, un après une conférence spécialisée, un seul par candidature spontanée.

L’approche par contribution open source demande un investissement réel — comptez deux à trois heures par semaine pour un responsable technique — mais elle a une propriété que rien d’autre ne reproduit : vous avez lu le code de la personne avant de lui parler. Sur les deux recrutements issus de ce canal, l’entretien technique n’a servi qu’à confirmer.

Attention au piège inverse : ne réduisez pas votre vivier aux profils déjà experts en Go. Nous y revenons à l’étape 4, mais c’est la décision qui a le plus élargi notre marge de manœuvre. Pour un raisonnement comparable côté freelance, notre article sur la construction d’un TJM en mission Go éclaire l’autre versant du marché — celui du candidat.

Étape 4 — Filtrer en 20 minutes sur trois questions, pas sur une liste de mots-clés

Le premier échange dure vingt minutes et repose sur trois questions ouvertes. Elles sont volontairement indépendantes du langage.

Question 1 — la concurrence. « Racontez-moi un bug de concurrence que vous avez diagnostiqué. » Un candidat qui n’en a jamais rencontré n’a probablement jamais exploité de service sous charge. Un candidat qui en raconte un avec la démarche de diagnostic — comment il l’a reproduit, ce qu’il a instrumenté — vous dit tout ce que vous avez besoin de savoir.

Question 2 — la gestion des erreurs. « Comment décidez-vous qu’une erreur doit remonter, être réessayée ou être ignorée ? » C’est le cœur du style Go, et c’est une question de conception qu’un développeur Java ou Python solide traite très bien.

Question 3 — l’exploitation. « Décrivez la dernière fois où vous avez été réveillé par un service que vous aviez écrit. » Question la plus prédictive des trois, de très loin. Elle sépare instantanément ceux qui ont écrit du code de ceux qui l’ont porté.

Sur nos 31 entretiens, ces vingt minutes ont éliminé 17 candidatures. Aucune de celles retenues n’a échoué à l’exercice technique de manière rédhibitoire — le filtre travaille bien en amont.

Étape 5 — Concevoir un exercice technique réaliste et court

Notre ancien exercice était un problème algorithmique classique, à résoudre en une heure sous observation. Nous l’avons abandonné après avoir constaté qu’il ne prédisait rien : deux des personnes ayant obtenu les meilleurs scores figuraient parmi les quatre départs.

Le nouvel exercice tient en une phrase : écrire un service qui consomme une file de messages, applique une limitation de débit et écrit dans une base de données, avec un arrêt propre attendu. Deux heures, à faire chez soi, avec toute la documentation et tous les outils d’assistance souhaités.

Ce format teste exactement ce qui différencie les candidats sur un poste Go réel : propagation du contexte d’annulation, arrêt propre sans perdre de message en vol, traitement des erreurs partielles, et lisibilité du résultat. Aucun de ces points ne se mesure sur un exercice algorithmique.

Nous rémunérons cet exercice. Deux heures du temps d’un professionnel ont une valeur, le dire change la nature de la relation, et cela nous a coûté moins cher qu’une seule erreur de recrutement.

Étape 6 — Évaluer avec une grille écrite avant l’entretien

La règle est simple : deux évaluateurs remplissent la grille indépendamment, avant de se parler. C’est inconfortable et c’est ce qui a le plus amélioré nos décisions.

Cinq critères, pondérés : raisonnement sur la concurrence (25 %), discipline de gestion des erreurs (25 %), lisibilité et testabilité du code rendu (20 %), réflexe d’exploitation — journalisation, métriques, arrêt propre (20 %), clarté d’explication à l’oral (10 %).

Un écart de plus de deux points entre les deux évaluateurs déclenche une discussion obligatoire avant décision. Dans trois cas sur 31, cette discussion a inversé une décision négative — et les trois personnes concernées sont toujours en poste.

Étape 7 — Sécuriser les 30 premiers jours

Deux de nos quatre échecs passés n’étaient pas des erreurs de sélection : c’étaient des échecs d’intégration. La personne était bonne et n’a jamais eu l’occasion de le démontrer.

Trois règles, désormais non négociables. Une mise en production réelle dans les cinq premiers jours, même minuscule — une correction, un ajout de métrique. Elle prouve que la chaîne complète est accessible et fait tomber la moitié des blocages implicites.

Un binôme nommé, pas une porte ouverte. « Viens me voir si tu as des questions » ne fonctionne pas les deux premières semaines. Une personne identifiée, avec du temps explicitement réservé, fonctionne.

Un point à J+30 qui parle du poste, pas de la personne. Trois questions : qu’est-ce qui t’a surpris, qu’est-ce qui te ralentit encore, qu’est-ce que l’offre décrivait mal ? La troisième question a amélioré notre offre trois fois de suite. C’est aussi le moment où l’on détecte les écarts d’attente, exactement comme dans notre méthode de recrutement TypeScript fullstack, dont la structure d’intégration est identique.

Ce que ça coûte, et pourquoi c’est rentable

Ce processus consomme environ 14 heures de temps d’ingénierie par recrutement : deux heures de sourcing hebdomadaire mutualisées, cinq entretiens de filtrage, deux relectures d’exercice, deux entretiens approfondis et l’accompagnement de l’intégration.

À comparer au coût d’une erreur : sur nos échecs passés, entre le salaire versé, le temps d’encadrement consommé et le recrutement à refaire, nous estimons le coût moyen d’un départ dans l’année à l’équivalent de six à neuf mois de salaire chargé. Le calcul ne demande pas d’être poussé loin.

Deux sujets adjacents reviennent systématiquement chez nos clients quand ce recrutement aboutit. Le premier est la sécurisation de la chaîne d’intégration continue que le nouvel arrivant va utiliser — un terrain que WebGuard Agency documente en détail. Le second est l’arbitrage entre développement interne et outillage assisté par IA, que Plug-Tech traite régulièrement du point de vue des PME françaises.

FAQ : recruter un développeur Go backend en France