Le Vrai Cout d'un Mauvais Recrutement Technique
L'estimation standard de l'industrie dit qu'un mauvais recrutement coute entre 1,5x et 3x le salaire annuel du poste. Si vous recrutez un ingenieur senior a 80 000 euros par an et que ca ne fonctionne pas, vous regardez un trou de 120 000 a 240 000 euros.
Mais ce chiffre ne capture que le visible. La partie que vous pouvez mettre dans un tableur. Ce qui detruit vraiment une startup, ce n'est pas l'argent qui est parti — c'est le temps qui ne revient pas et les degats laisses derriere.
Les couts visibles : ce que vous pouvez calculer
Commencons par l'evident, parce que ca fait deja assez mal :
- Salaire cumule. Les mois que vous avez payes avant de realiser l'erreur. Generalement 3 a 6 mois.
- Couts de recrutement. Si vous avez utilise un cabinet, vous avez paye entre 15% et 25% du salaire annuel. Si vous l'avez fait en interne, le temps investi en screening, entretiens et negociation.
- Indemnite. Selon le pays et le contrat, cela peut aller d'un mois a plusieurs mois de salaire.
- Cout de remplacement. Vous repartez de zero. Nouveau cycle de publication d'offres, tri de CV, entretiens techniques, negociation. Si vous avez de la chance, 2 a 3 mois. Si non, 6.
Additionnez tout cela et vous arrivez facilement a cette estimation de 1,5-3x. Mais c'est la que la plupart des analyses s'arretent. Et c'est la que commencent les vrais degats.
Les couts invisibles : ce qui n'apparait dans aucun tableur
Dette technique heritee
Un mauvais ingenieur ne fait pas que ne pas construire ce qu'il devrait. Il construit mal ce qu'il touche. Du code sans tests, une architecture qui ne scale pas, des dependances inutiles, des abstractions que personne ne comprend. Quand il part, ce code reste. Et quelqu'un doit gerer ca.
J'ai vu des cas ou un ingenieur est reste 4 mois dans une startup et a laisse un codebase que le senior suivant a mis 6 semaines a reecrire avant de pouvoir avancer. Ces 6 semaines sont du pur cout irrecuperable — vous ne construisez pas de nouvelles features, vous defaites le travail de quelqu'un qui est parti.
Impact sur le moral de l'equipe
C'est ce qui se mesure le moins et impacte le plus. Quand un membre de l'equipe ne performe pas, le reste le sait. Avant vous, generalement. Et chaque semaine qui passe sans que vous agissiez, votre credibilite en tant que leader s'erode.
Les bons ingenieurs ne veulent pas travailler avec de mauvais ingenieurs. Si vous tardez trop a agir, le risque n'est pas seulement de perdre celui qui ne fonctionne pas — c'est que ceux qui fonctionnent commencent a chercher ailleurs.
Deadlines non tenus
Vous avez recrute cet ingenieur parce que vous aviez besoin de livrer quelque chose. Une feature critique, une integration, un MVP. Chaque mois qui passe avec quelqu'un qui n'execute pas est un mois de retard sur votre produit. Dans une startup, cela peut signifier :
- Perdre une fenetre de marche. Votre concurrent a lance en premier.
- Perdre la confiance des investisseurs. Vous n'avez pas tenu la roadmap presentee lors de la levee.
- Perdre des clients. Vous avez promis une feature pour le Q1 et elle n'est pas arrivee.
Perte de connaissance institutionnelle
Quand quelqu'un part — meme quelqu'un qui ne performait pas bien — il emporte du contexte. Des decisions qu'il a prises, des conversations qu'il a eues avec d'autres membres de l'equipe, une comprehension du domaine metier. Une partie de ce contexte est perdue a jamais. L'ingenieur suivant commence avec un deficit d'information qui prend des semaines a combler.
La chronologie du desastre
Mettons des chiffres sur le temps :
- Mois 0-3 : Recrutement. Vous publiez l'offre, filtrez, passez les entretiens, negociez, onboarding. Si tout va bien, 2 a 3 mois. Si le marche est tendu — et en tech il l'est — ca peut etre 4 a 6.
- Mois 3-6 : Lune de miel. Le nouvel ingenieur integre l'equipe. Les premiers mois sont du ramp-up. C'est normal qu'il ne produise pas a 100%. Vous lui accordez le benefice du doute.
- Mois 6-9 : Le soupcon. Vous commencez a voir des signaux. Des code reviews qui reviennent avec beaucoup de commentaires. Des taches en retard. D'autres ingenieurs qui commencent a se plaindre en prive. Mais vous pensez : "Peut-etre qu'il a besoin de plus de temps."
- Mois 9-11 : La certitude. Vous savez que ca ne fonctionne pas. Mais maintenant vous devez gerer le depart. Conversations difficiles, documentation de la performance, processus d'offboarding.
- Mois 11-14 : Retour a la case depart. Vous recrutez a nouveau.
Resultat : jusqu'a 14 mois perdus. Pour une startup qui essaie d'atteindre le product-market fit, ca peut etre fatal.
Pourquoi ca arrive : les erreurs les plus courantes
Les mauvais recrutements ne sont pas de la malchance. C'est le resultat d'un processus casse. Voici les erreurs que je vois le plus souvent :
Recruter dans l'urgence, pas avec du critere
"On a besoin d'un backend developer pour hier." Ca vous dit quelque chose. La pression de livrer fait baisser le niveau d'exigence. Vous acceptez le candidat qui est "correct" au lieu d'attendre celui qui est "excellent". Ce raccourci coute toujours plus cher.
Faire trop confiance au CV
Un CV impressionnant ne garantit rien. J'ai passe des entretiens avec des candidats ayant de l'experience chez Google et Amazon qui ne pouvaient pas resoudre un probleme basique de design de systemes. Et j'ai vu des ingenieurs d'entreprises que vous ne connaissiez pas ecrire du code impeccable. Le CV vous dit ou quelqu'un a ete. Il ne vous dit pas comment il travaille.
Ne pas faire d'evaluation technique reelle
Une conversation de 30 minutes n'est pas une evaluation technique. Si vous ne faites pas de code reviews de code reel, d'exercices de design de systemes, ou au moins une session de pair programming, vous devinez. Et deviner sur des recrutements de 60 000 a 100 000 euros par an est un risque absurde.
Evaluer l'entretien, pas la production
Il y a des gens qui passent incroyablement bien en entretien et produisent mediocrement. Et inversement. Si votre processus selectionne sur la capacite a passer des entretiens plutot que sur la capacite a executer, vous optimisez la mauvaise chose.
Comment le prevenir : le framework qui fonctionne
Il n'y a pas de garantie a 100%, mais vous pouvez reduire drastiquement le risque :
1. Validation technique rigoureuse. Pas seulement algorithmes et structures de donnees. Evaluation de code reel. Comment structure-t-il un projet ? Comment gere-t-il les erreurs ? Comment pense-t-il le testing ? Peut-il expliquer des decisions d'architecture prises sur des projets precedents ?
2. Evaluation par des ingenieurs, pas par des recruteurs. Un recruteur peut evaluer les soft skills et le fit culturel. Il ne peut pas evaluer si quelqu'un sait concevoir un systeme de files d'attente distribuees. Vos ingenieurs senior — ou votre CTO — doivent participer au processus.
3. Periode d'essai reelle. Pas une periode d'essai ou vous regardez si la personne "s'integre". Une periode ou vous lui confiez du travail reel avec des livrables concrets et evaluez la qualite du resultat. 2 a 4 semaines suffisent generalement pour savoir si quelqu'un execute vraiment.
4. References techniques, pas seulement professionnelles. N'appelez pas seulement son ancien manager. Parlez a quelqu'un qui a revu son code ou travaille dans la meme equipe technique. Les questions qui comptent : "Travailleriez-vous de nouveau avec cette personne ? Lui confieriez-vous un projet critique ?"
Comment nous resolvons cela chez Conectia
Tout ce qui precede necessite du temps, de l'expertise technique et un processus bien defini. La plupart des startups en phase initiale n'ont pas les trois. Elles sont pressees, elles ont un fondateur technique deja au maximum de sa capacite, et elles n'ont pas de processus de recrutement eprouve.
C'est exactement pour cela que nous avons cree Conectia. Notre processus de validation a un taux d'acceptation de 8%. Ce n'est pas un filtre de CV — c'est une evaluation technique menee par des CTOs avec de l'experience en production. Nous evaluons du code reel, la capacite de conception de systemes et l'experience demontrable dans des environnements de startup.
Si un ingenieur ne convient pas, nous le remplacons dans les 30 premiers jours sans cout supplementaire. Non pas parce que nous nous attendons a ce que ca arrive — notre taux de retention est de 95% — mais parce que nous comprenons que pour un fondateur, la confiance dans le processus compte autant que le resultat.
Le cout d'un mauvais recrutement n'est pas un chiffre dans un tableur. C'est du temps que vous ne recuperez pas, du code que vous devez reecrire, et un moral d'equipe qui met des mois a se reconstruire. Le meilleur investissement que vous puissiez faire n'est pas de recruter vite — c'est de recruter bien.
Vous en avez assez des processus de recrutement qui ne filtrent pas vraiment ? Parlez a un CTO — des ingenieurs senior pre-valides avec garantie de remplacement sous 30 jours.
