Pourquoi votre cycle de recrutement tue vos sprints

Tous les engineering managers ont fait le calcul dans leur tête : « On a besoin d'un ingénieur backend mid-level. On poste l'offre, on attend les candidats, quatre tours d'entretiens, on négocie l'offre, puis on leur donne quatre semaines de préavis. » Douze semaines plus tard, vous avez votre ingénieur.

Ce que vous n'avez pas calculé, c'est ce que le reste de l'équipe a fait pendant ces douze semaines en portant ce vide.

Le calcul que personne ne fait

Un ingénieur mid-level dans une équipe de 15 personnes est responsable d'environ 30 à 40 % du débit en story points de l'équipe, selon le rôle. Avec des cycles de sprint de deux semaines, un poste vacant de 90 jours représente six sprints. Si chaque sprint livre 60 story points avec une équipe complète, vous perdez entre 18 et 24 points par sprint — avant même de compter l'overhead que le poste vacant crée pour tous les autres.

Ça fait 108 à 144 story points non livrés. Un à deux trimestres de roadmap planifiée partis en fumée, silencieusement, pendant que vous écrivez des job descriptions et débattez si le score LeetCode de quelqu'un veut dire quelque chose.

Ajoutez maintenant les coûts d'entretien. Un processus de recrutement tech européen typique implique cinq à huit heures de temps candidat par interviewer senior, réparties entre phone screens, entretiens techniques et sessions de debrief. Si deux ingénieurs seniors mènent le processus et que vous interviewez douze candidats pour faire une embauche, vous avez brûlé 120 à 160 heures-ingénieur — environ l'output d'un sprint complet de vos deux personnes les plus expérimentées. Ces heures n'apparaissent nulle part dans votre suivi de projet. Elles sont invisibles.

Les effets de second ordre

Le calcul ci-dessus, c'est la partie facile. Le dommage se compose.

Quand un poste reste ouvert, le travail ne disparaît pas — il se redistribue. Vos ingénieurs seniors l'absorbent. Ils font du context-switch entre le travail qu'ils devraient faire et le travail qui doit être fait. Les deux en pâtissent. Les ingénieurs seniors en mode context-switch livrent plus lentement, reviewent les PRs moins minutieusement, et prennent de pires décisions architecturales. La dette technique qu'ils créent en rushant des décisions pour lesquelles vous les avez embauchés pour réfléchir posément prend des mois à démêler.

Les codebases se figent autour des postes vacants. Les features qui touchent au domaine du rôle vide sont différées. « On fera ça une fois que la nouvelle personne sera à niveau » devient une phrase qui se dit sur des parts de plus en plus larges de votre roadmap. Au moment où votre recrue arrive, elle hérite d'une codebase qui a six mois de décisions différées cuites dedans.

Les lancements glissent. Pas de manière dramatique — rarement un retard catastrophique — mais systématiquement de deux à trois semaines par cycle de sprint. Sur un marché compétitif, c'est souvent suffisant.

Pourquoi le recrutement local est structurellement lent au Benelux

Ce n'est pas un échec de processus. C'est un problème de géographie.

Le Luxembourg compte environ 660 000 personnes. Le vivier d'ingénieurs mid-to-senior avec la stack spécifique dont vous avez besoin — Kubernetes, ou React, ou Laravel, ou quoi que ce soit — se compte en centaines, pas en milliers. La plupart sont employés et ne cherchent pas activement. Ceux qui cherchent ont trois autres offres. Vous êtes en compétition avec les institutions européennes, les firmes de services financiers, et les scale-ups qui payent des salaires européens avec les avantages fiscaux luxembourgeois.

Les Pays-Bas et la Belgique sont mieux, mais « mieux » veut dire que vous attendez six à huit semaines au lieu de douze. Les frictions de visa pour les candidats hors-UE ajoutent encore quatre à huit semaines. La densité de talent structurelle n'est tout simplement pas là.

Ce n'est pas un problème que vous résolvez en écrivant une meilleure job description.

À quoi ressemble le rapide

Le modèle de l'ingénieur embarqué compresse la timeline parce qu'il élimine les étapes qui causent l'essentiel du retard.

Chez PragmaGeeks, nous maintenons un roster actif d'ingénieurs au Maroc — GMT+1, disponibles sous deux à quatre semaines après un brief, déjà vérifiés pour les stacks que nos clients utilisent réellement. La fenêtre brief-au-premier-jour est de deux à quatre semaines. Pas parce qu'on rush quoi que ce soit — parce que le travail de filtrage se fait en continu, pas quand vous avez un poste vacant urgent.

L'ingénieur s'embarque dans votre équipe. Il utilise vos outils, assiste à vos standups, soumet des PRs sur votre repo. Ce n'est pas un consultant qui livre un document. C'est un ingénieur qui livre du code.

La différence, c'est où se situe le risque. Avec une embauche permanente, vous absorbez tout le risque d'avance : le salaire, la période de préavis, les quatre mois de ramp. Avec un ingénieur embarqué, le risque reste partagé jusqu'à ce que vous soyez certain.

Sur quoi optimiser quand vous ne pouvez pas ralentir

Si votre équipe avance et que vous ne pouvez vraiment pas absorber un gap de 90 jours, il y a trois choses qui valent la peine d'être priorisées.

Qualité du brief. La variable la plus importante dans le time-to-hire — que vous recrutiez directement ou via un partenaire — c'est à quel point vous pouvez décrire précisément ce dont vous avez besoin. Pas le paragraphe de job description sur les « ingénieurs passionnés ». Le contexte réel : sur quoi ils vont travailler en semaine un, à quoi ressemble la codebase, ce que « bon » veut dire dans votre équipe. Un brief précis retire des semaines au processus quel que soit le canal.

Infrastructure d'onboarding. L'ingénieur qui arrive le jour un et a un environnement local qui fonctionne, une documentation claire sur comment votre CI marche, et une première tâche qu'il peut fermer dans la première semaine est productif en semaine deux. Celui qui passe le jour trois à attendre des credentials d'accès est productif en semaine quatre. Un onboarding pré-construit n'accélère pas juste le ramp — il signale à l'ingénieur que votre équipe sait comment travailler.

Confiance plutôt que contrôle. L'instinct quand on fait venir un ingénieur externe est d'ajouter de la supervision. Plus de check-ins, plus de gates d'approbation, plus de reporting. Cet instinct est exactement à l'envers. Les ingénieurs qui se sentent en confiance livrent plus vite et restent plus longtemps. L'overhead d'un processus excessif efface l'avantage de vitesse pour lequel vous les avez embauchés.

Le cycle de recrutement de 90 jours n'est pas un standard vers lequel optimiser. C'est un mode de défaillance que la plupart des équipes ont normalisé parce qu'elles n'ont pas d'alternative visible. Le coût du poste vacant est réel, quantifiable, et il atterrit sur les ingénieurs qui peuvent le moins se le permettre.

Si votre équipe porte actuellement un poste ouvert et que la roadmap glisse, ce n'est pas de la malchance. C'est la facture du recrutement lent qui arrive en traites.