La conversation que je n'oublierai pas
Un CEO m'a dit l'an dernier : « J'ai besoin de huit ingénieurs, je recrute depuis quatre mois. » Avant que je réponde, son CTO l'a interrompu : « Et si on n'avait pas besoin de huit ? »
La pièce a changé d'ambiance. On est passés de « combien vous coûteraient huit développeurs ? » à « qu'est-ce qu'on essaie vraiment de produire dans les six prochains mois ? »
C'est la conversation que je voudrais que toutes les équipes aient avant de poster huit fiches de poste.
Le coût caché du recrutement
Recruter une équipe d'ingénierie complète en mid-market européen, en 2026, n'est pas un problème de salaires. C'est un problème de temps et d'opportunité.
Le processus typique :
- Trois mois pour rédiger les fiches, lancer les annonces, trier, faire passer les premiers entretiens.
- Trois à six mois de préavis cumulé selon les pays.
- Trois mois d'onboarding avant que la personne soit autonome sur votre produit.
Neuf mois pour une seule personne dans le meilleur des cas. Pour une équipe de huit, comptez plus. Pendant ce temps, votre projet est figé. Vos concurrents ne le sont pas.
Le coût n'est pas le salaire. Le coût est l'année que vous perdez.
La composition d'équipe qu'on assume
Quand on étend votre équipe, on ne vous envoie pas huit seniors. Ce serait un mensonge, et un mauvais calcul pour vous.
Une équipe entièrement composée de seniors a deux problèmes. Elle coûte cher au point que le ratio valeur-prix bascule. Et elle est inefficace : un senior expérimenté passe la moitié de son temps à faire des tâches qu'un ingénieur formé ferait aussi bien, mais en moins de temps si on lui laissait le bon périmètre.
La composition qu'on assume :
- Un ou deux leads seniors qui portent l'architecture et les arbitrages.
- Des builders expérimentés qui livrent les fonctionnalités cœur.
- Des ingénieurs formés sur des périmètres bien cadrés.
- Une couche IA sur tout le cycle : revue de PR, génération de tests, scaffolding, documentation, détection de régressions.
C'est le bon équilibre coût-qualité, et c'est ce qu'on défend même quand un client demanderait l'inverse.
Ce qu'on ne prétend pas
On ne prétend pas que tous nos ingénieurs ont quinze ans d'expérience. On ne prétend pas non plus livrer comme une équipe deux fois plus grosse. On prétend livrer à la qualité d'une équipe senior, pour le coût d'une équipe équilibrée, parce qu'on a investi dans deux choses :
- Des standards écrits, pas des standards de couloir. Conventions de code, structure de PR, exigences de tests, observabilité. Un ingénieur formé qui suit ces standards livre comme un senior dans 80 % des cas.
- Une couche IA dans tout le SDLC. Pas un gadget. Un agent qui revoit chaque PR avant qu'un humain regarde, qui génère les tests pour les cas que les humains oublient, qui propose des refactorings ciblés. C'est ce qui élève le plancher.
L'IA augmente le plancher, pas le plafond
Une idée fausse que j'entends souvent : « l'IA va faire baisser la qualité ». C'est l'inverse, mais à condition de l'utiliser comme un outil, pas comme une béquille.
L'IA n'écrit pas un meilleur code que votre meilleur ingénieur. Elle écrit un code plus consistant que votre ingénieur le moins expérimenté un vendredi après-midi à 17 h. C'est exactement la zone où la qualité d'une équipe se joue.
Nos ingénieurs formés livrent du code que je n'aurais pas distingué d'un senior il y a trois ans. Pas parce qu'ils sont devenus seniors en six mois (c'est impossible) mais parce que l'IA et les standards écrits absorbent les erreurs basiques avant qu'elles arrivent en production.
Une équipe 100 % senior n'est ni honnête ni le bon équilibre coût-qualité pour vous.
Code factory ou partenaire étendu
Étendre une équipe, ce n'est pas la même chose que sous-traiter. La sous-traitance classique, le modèle code factory, découple complètement votre équipe interne de l'équipe externe. Vous donnez un cahier des charges, vous recevez du code, vous priez pour qu'il fonctionne.
Une équipe étendue travaille comme votre équipe. Mêmes outils, mêmes rituels, mêmes standards. La différence avec une vraie embauche, c'est que vous n'avez pas attendu neuf mois et vous pouvez réajuster la taille de l'équipe selon vos besoins.
Le test simple : nos ingénieurs participent à vos dailys, écrivent dans votre Slack, sont taggués sur vos issues. S'ils ne le sont pas, ce n'est pas une équipe étendue. C'est un sous-traitant.
Ce que ça donne sur six mois
Sur les douze derniers projets où on a étendu une équipe interne, voici ce qu'on observe en moyenne :
- Trois semaines entre le contrat signé et la première PR mergée.
- Six à dix semaines pour atteindre la pleine vitesse de livraison.
- Une rétention de l'équipe étendue au-delà du contrat initial dans deux cas sur trois, parce que le client a vu l'effet et a choisi de prolonger.
- Une transmission complète des standards à l'équipe interne au sixième mois, vérifiable par audit.
C'est lent ? Non, comparé à recruter en interne. C'est aussi le rythme dans lequel on accepte que la qualité tienne sur six mois plutôt que de péter au troisième.
Si c'est votre besoin
Si vous avez un projet qui demande six à douze ingénieurs et que vous savez que le recrutement classique vous coûte l'année, on peut vous proposer une revue produit de trente minutes. À la fin, vous aurez un plan d'action chiffré sous 72 heures, sans devis figé, sans engagement.