Staff augmentation : quand c’est la bonne réponse, quand c’est un piège, et comment trancher

Un guide pour le fondateur non-technique sur le modèle que toutes les agences vendent et dont peu de fondateurs ont vraiment besoin.

Un fondateur avec qui nous discutions depuis trois mois a appelé un mercredi et a sorti la phrase que nous entendons au moins une fois par trimestre : « Je pense que ce qu’il me faut, c’est du staff augmentation. Vous pouvez me trouver deux devs seniors pour six mois ? »

Nous avons renvoyé une seule question. Qui pilote le projet ?

Long silence.

Le staff augmentation est un modèle contractuel où vous louez des ingénieurs individuels à une agence extérieure pour qu’ils s’intègrent à votre équipe, sous votre gestion, sur une période définie. C’est le modèle de delivery le plus vendu et le moins compris du marché des services logiciels. Chaque agence le vend parce que le calcul est facile de leur côté. Chaque fondateur qui s’est brûlé sur un contrat au forfait y arrive un jour parce qu’il paraît être le juste milieu le plus sûr. Et la plupart du temps, pour la plupart des fondateurs non-techniques, c’est la mauvaise réponse déguisée en réponse raisonnable.

Ce n’est pas une charge contre le staff augmentation. C’est un modèle qui fonctionne dans des cas précis, sur des équipes qui savent déjà s’en servir. Le problème, c’est que les personnes qui ont besoin de lire cet article ne sont presque jamais cette équipe-là, et la SERP ne le dit pas. Nous, si.

Ce qu’est vraiment le staff augmentation

Le staff augmentation est un modèle contractuel dans lequel vous recrutez des ingénieurs individuels (ou des designers, ou des PMs) via une agence pour travailler à l’intérieur de votre équipe sur une période définie, sous votre direction. Ils utilisent vos outils, participent à votre daily, prennent leurs tickets auprès de votre lead, et facturent à l’heure ou à la journée. Ce ne sont pas des employés. Ce n’est pas un prestataire livrant un projet. C’est de la capacité supplémentaire louée à la paie de quelqu’un d’autre.

Le trait qui définit le staff augmentation, celui qui le sépare de tout modèle voisin, est le suivant : vous restez le chef de projet. L’agence fournit des corps. Vous fournissez la direction, la priorisation, le standard de code review, le déploiement et la responsabilité du résultat. Si le projet glisse, c’est sur vous. Si une feature est ratée, c’est vous qui avez écrit la spec.

La plupart des fondateurs non-techniques lisent ce paragraphe et se disent ça me va. Ça ne va pas. C’est le piège. On y revient.

Le spectre que personne ne vous dessine

Tout fondateur finit par découvrir qu’il existe plus de deux options pour construire du logiciel. Il en existe au moins quatre. Les aligner selon la part de responsabilité de delivery transférée à l’extérieur rend les différences évidentes :

In-house. Vous embauchez des employés. Vous possédez tout : code, processus, recrutement, fidélisation, paie, toute la pile de coûts. Contrôle maximum, overhead maximum, ramp-up le plus lent.

Staff augmentation. Des individus extérieurs s’intègrent à votre équipe. Vous portez le delivery ; l’agence porte le recrutement, la paie et le banc. Vous les gérez comme des employés mais ils ne sont pas sur votre paie.

Managed services / équipe dédiée. Un partenaire externe livre une équipe (ingénieurs + tech lead + PM) qui fonctionne comme une unité. La responsabilité du delivery est partagée. Le partenaire dirige l’équipe ; vous donnez la direction et priorisez. (C’est le modèle que la plupart appellent « software house » quand c’est bien fait.)

Outsourcing / forfait. Vous remettez un périmètre et une échéance. Le prestataire livre un produit contre un contrat. Vous ne touchez quasiment pas à l’équipe. La responsabilité est intégralement chez le prestataire.

En glissant de gauche à droite, vous cédez du contrôle et gagnez en expertise extérieure pour piloter de l’ingénierie. Plus vous allez à droite, moins vous passez de temps en daily ; plus vous allez à gauche, plus vous avez de prise sur ce qui se construit et comment.

Le staff augmentation est un cran à droite du in-house. Pas trois. Il est plus proche d’embaucher que d’externaliser. Les fondateurs qui n’ont pas dessiné ce spectre traitent souvent le staff aug comme « de l’outsourcing en moins cher », et cette lecture est exactement là où les ennuis commencent.

Le seul cas où le staff augmentation fonctionne

Le staff augmentation est la bonne réponse quand trois choses sont vraies en même temps :

Vous avez déjà une équipe d’ingénierie qui tourne. Pas « un dev ». Une équipe. Il y a un tech lead ou un ingénieur senior qui anime le planning, fixe les standards de code, tranche les décisions d’architecture et review les PRs. L’équipe a un produit en production.

Vous avez un manque de compétence précis et cadré. Votre ingénieur iOS est parti et vous devez livrer la v2 dans les temps. Vous migrez de MongoDB vers Postgres et personne dans l’équipe ne l’a déjà fait. Vous voulez tester une feature de machine learning sur deux mois sans recruter un ingénieur ML à temps plein.

Le travail a une date de fin définie. Vous n’« ajoutez pas un dev permanent ». Vous résolvez un problème qui a une forme et un délai. Trois mois. Jusqu’à la fin de la migration. Jusqu’à ce que l’intégration soit en production.

Quand les trois conditions sont réunies, le staff augmentation est excellent. L’agence fait le recrutement que votre équipe interne n’a pas le temps de faire. Le prestataire s’intègre vite parce que l’équipe dans laquelle il se branche existe déjà. Le coût est variable ; l’engagement est borné ; tout le monde rentre à la maison quand le travail est fini.

Si vous avez déjà lu un case study élogieux sur le staff augmentation, c’était presque sûrement une boîte dans laquelle ces trois conditions étaient réunies.

Le piège pour le fondateur non-technique

Maintenant la version de l’histoire que nous voyons le plus souvent.

Un fondateur non-technique est post-seed, en train de construire un produit, et le développeur freelance qu’il a recruté il y a six mois l’a soit grillé, soit ghosté, soit demande trois fois le tarif pour continuer. Il ne veut pas « recruter un CTO ». Il a entendu trop d’horror stories sur les agences. Un ami, un LLM, ou un article sur la deuxième page de Google lui suggère le staff augmentation. Prends deux devs seniors pour six mois. Pilote-les toi-même. Économise le markup de l’agence.

Ça paraît raisonnable en surface. C’est un désastre en dessous. Voilà ce qui se passe vraiment.

Mois un. Deux prestataires seniors arrivent. Ils sont bons. L’agence n’a pas menti là-dessus. Premier jour, ils demandent : Où est la file de tickets ? Qui review les PRs ? C’est quoi le process de déploiement ? Où est l’environnement de staging ? C’est quoi la définition de « done » ?

Personne n’a la réponse. Le fondateur croyait que recruter les ingénieurs était le problème. Le travail que les ingénieurs font vraiment (planifier, reviewer, trancher) s’avère être le problème dur, et il n’y a personne pour le faire. Les prestataires improvisent. Ils inventent du processus. Ils s’écrivent leurs propres tickets et se notent eux-mêmes.

Mois deux. La vélocité est correcte. Le code sort. Le fondateur est en daily quarante minutes chaque matin parce qu’il est le seul à savoir ce que la boîte essaie de construire. Il prend des décisions d’architecture qu’il n’est pas qualifié pour prendre. Il approuve des PRs qu’il ne sait pas évaluer. Il travaille plus qu’avant d’avoir recruté les prestataires.

Mois trois. Les prestataires butent sur un désaccord. Pas d’ingénieur senior dans la pièce pour trancher. Le fondateur tranche, mal. Une semaine plus tard, il détranche dans l’autre sens, mal aussi. Les deux prestataires, en silence, commencent à passer des entretiens ailleurs, fatigués de travailler sans tech lead.

Mois six. Le code est livrable mais fragile. Pas de documentation. Les prestataires partent à la fin du contrat. Le fondateur est revenu à la case départ, sauf qu’il a maintenant une base de code qu’il n’a pas écrite et qu’il ne sait pas maintenir. Il s’assoit avec son advisor et demande s’il devrait recruter un CTO fractional ou s’il est temps de chercher un partenaire de delivery qui sache vraiment diriger l’équipe.

Nous avons vu cet arc précis, sous différents costumes, une bonne demi-douzaine de fois. Le piège est structurel, pas personnel. Le fondateur a fait ce qu’on lui a dit. Les prestataires ont fait du bon travail. Le modèle n’allait pas avec la situation. La pièce de Lenny Rachitsky sur le recrutement en early-stage arrive au même point par le chemin long : la première question d’un recrutement n’est presque jamais « quel rôle » mais « qui porte le travail ensuite ». Le staff augmentation saute cette question et fait comme si la question était le rôle.

Le staff augmentation suppose qu’il existe une équipe pour absorber les nouvelles personnes. Si l’équipe se réduit à un fondateur non-technique surchargé, les nouvelles personnes ne sont pas absorbées. Elles dérivent.

Le test des quatre questions avant de signer

Avant de signer un contrat de staff augmentation, répondez aux quatre. Si vous ne pouvez pas dire oui aux quatre, vous n’avez pas besoin de staff aug. Vous avez besoin d’autre chose.

1. Y a-t-il une personne dans mon équipe, autre que moi, qui va porter le quotidien des prestataires ? Cette personne doit être techniquement crédible, disponible pour les code reviews, et habilitée à trancher. « Je m’en charge » ne compte pas, sauf si vous écrivez du code de production dans votre stack.

2. Suis-je capable de décrire, en deux phrases, le périmètre précis et la date de fin de ce qu’ils vont faire ? Pas « construire le produit ». Pas « nous aider à scaler ». Quelque chose comme : Migrer le billing de Stripe Checkout vers un flux de facturation custom d’ici le 15 septembre. Si votre périmètre est un paragraphe, vous achetez un partenaire de delivery déguisé en staff aug.

3. Ai-je déjà un processus de développement qui tourne : tickets, PRs, déploiements, une définition claire de « done » ? S’il faudrait l’inventer pour les prestataires, vous n’augmentez pas une équipe. Vous en louez une sans la couche de leadership.

4. Le travail va-t-il survivre aux prestataires ? Si la réponse est « oui, à condition qu’ils documentent », vous pariez votre code sur la discipline de prise de notes de l’agence. Reconsidérez.

Quatre oui : le staff aug est le bon outil. Trois ou moins : vous regardez le mauvais modèle. La plupart des fondateurs non-techniques avec qui nous travaillons sortent zéro ou un au premier passage. Ce n’est pas l’échec du fondateur. C’est l’échec de la situation, et la situation demande un autre modèle : généralement un partenaire de delivery qui apporte son propre tech lead et son propre processus.

À quoi ressemble un vrai contrat de staff augmentation

Les clauses qui distinguent une agence sérieuse d’une fabrique de corps sont prévisibles. Si malgré tout vous utilisez le staff aug, voici ce qu’il faut exiger.

Individus nommés. Le contrat nomme les personnes qui feront le travail, avec leur séniorité et leur tarif. « Deux ingénieurs seniors à définir » est un signal fabrique de corps. Une agence sérieuse met des noms sur le papier parce qu’elle veut placer ses meilleurs profils sur la mission pour construire la relation.

Clause de remplacement avec un vrai critère. Si le prestataire ne tient pas ou démissionne, l’agence remplace au même tarif dans une fenêtre définie, en général deux semaines. Regardez le critère de « ne tient pas ». S’il est défini comme « insatisfaction du client à sa seule discrétion », vous avez une clause utile. S’il est muet, l’agence va discuter quand vous demanderez le remplacement.

IP en votre faveur. Le produit du travail est à vous, point. Pas de « IP partagée », pas de « licence retour au portfolio de l’agence ». Nous avons vu des agences tenter de conserver le droit de réutiliser du code de votre mission. Refusez.

Confidentialité et non-sollicitation, mutuelles. Classique. Assurez-vous que c’est mutuel, parce que vous ne voulez pas que le prestataire soit récupéré par un concurrent qu’une même agence sert aussi.

Résiliation pour convenance. Avec un préavis raisonnable, en général 30 jours. Si le contrat vous bloque six mois quoi qu’il arrive, l’agence vous vend une certitude qu’elle n’a pas.

Plafond d’heures ou cadence par sprint. Du T&M pur sans plafond, c’est comme ça que les factures s’envolent. Un plafond mensuel ou des allocations fixes par sprint maintiennent la trajectoire raisonnable.

L’essentiel recoupe ce que vous mettriez dans n’importe quel contrat de développement logiciel. Les spécifiques du staff augmentation, ce sont les individus nommés, la clause de remplacement et la cadence.

Comment savoir si vous parlez à un partenaire ou à une fabrique de corps

Un petit test que nous nous appliquons à nous-mêmes et que nous recommandons aux fondateurs de faire passer à toute agence qui leur pitche du staff aug.

Demandez au partenaire : Compte tenu de ce que je viens de vous dire sur ma boîte, est-ce que le staff augmentation est le bon modèle pour moi ?

La fabrique de corps répond oui, parce que c’est ce qu’elle vend. Un vrai partenaire répond : Probablement pas. Voici pourquoi, et voici ce dont vous avez besoin en réalité. On en parle plutôt ?

Si la réponse est « oui, c’est certain, on démarre quand ? », vous ne parlez pas à un partenaire. Vous parlez à un fournisseur dont les incitations ne sont pas les vôtres. Partez.

FAQ

Que veut dire staff augmentation ?
Cela signifie recruter des individus externes via une agence pour qu’ils travaillent à l’intérieur de votre équipe sur une période définie, sous votre gestion. Ce ne sont pas des salariés de votre entreprise. L’agence gère leur recrutement, leur paie et leur banc ; vous gérez leur quotidien.

Un exemple de staff augmentation ?
Une boîte SaaS avec une équipe interne de huit ingénieurs doit livrer une app iOS en quatre mois. Elle ne veut pas recruter un ingénieur iOS à temps plein. Elle prend un ingénieur iOS senior via une agence, qui rejoint l’équipe pendant le projet, participe au daily, reporte au tech lead, et s’en va quand l’app est sur l’App Store.

Staff augmentation vs outsourcing, quelle différence ?
Le staff augmentation loue des individus qui travaillent à l’intérieur de votre équipe pendant que vous gérez le delivery. L’outsourcing loue un prestataire qui livre un produit fini contre un périmètre et vous ne touchez quasiment pas à l’équipe. Le partage : qui répond du résultat ? Vous en staff aug, le prestataire en outsourcing.

Qu’est-ce qu’un contrat de staff augmentation ?
Un contrat qui définit qui sont les prestataires (idéalement nommés), combien ils coûtent (tarif horaire ou journalier), la fenêtre de la mission, l’IP en votre faveur, une clause de remplacement si le prestataire ne tient pas ou s’en va, et les conditions de résiliation. La clause de nomination est le meilleur indicateur d’un contrat sérieux.

Le staff augmentation est-il moins cher que recruter ?
À l’heure, presque jamais. L’agence ajoute un markup sur ce que le prestataire perçoit. Ce que vous économisez, c’est le temps et le risque de recruter (mois de recherche, coût d’un mauvais recrutement, indemnités, fidélisation) et l’overhead de porter un salarié. Si l’échange est rentable dépend de la durée du travail. Missions courtes : en général oui. Postes permanents : en général non.

Quand ne pas utiliser le staff augmentation ?
Quand vous n’avez pas d’équipe en place pour que les prestataires s’y branchent. Quand vous n’avez pas un morceau de travail cadré et borné dans le temps. Quand vous n’avez personne d’autre que vous pour gérer leur quotidien. S’il manque deux de ces trois éléments, regardez plutôt du côté du managed services ou d’un partenaire de delivery.

Le staff augmentation n’est pas une arnaque. C’est un outil. Entre les mains d’une équipe qui a la couche de leadership pour le diriger, c’est l’un des moyens les plus propres d’avancer vite sur un problème borné sans la traîne d’une embauche permanente. Entre les mains d’un fondateur qui espère que les prestataires, d’une manière ou d’une autre, finiront par former une équipe, c’est la façon la plus chère d’apprendre ce qu’il fallait apprendre de toute façon : diriger des ingénieurs est un métier à part entière, et les louer ne l’inclut pas.

Avant de signer, faites passer le test des quatre questions. Si vous arrivez à quatre oui, recrutez et avancez. Sinon, trouvez un partenaire qui vous dira la vérité sur le modèle qui colle, et choisissez celui-là.