Intégrer une équipe externe sans faire chuter la vélocité de l'équipe interne

Une DSI décide de renforcer une équipe produit avec quatre développeurs externes. Le besoin est réel, le budget est validé, les profils sont bons. Trois mois plus tard, la vélocité globale est inférieure à ce qu'elle était avant le renfort.

Ce n'est pas un échec de recrutement. C'est un problème d'arithmétique que tout le monde connaît et que peu appliquent.

Pourquoi ajouter des développeurs ralentit d'abord

Chaque arrivant consomme du temps de l'équipe existante : questions, revue de code, contexte métier, décisions d'architecture à réexpliquer. Ce coût est payé par les personnes les plus productives de l'équipe, qui sont aussi les seules capables de répondre.

Quatre arrivants simultanés sur une équipe de sept saturent immédiatement la capacité de revue. Les demandes de fusion s'accumulent, les retours arrivent tard, les arrivants attendent — et pendant ce temps ils sont facturés.

Le démarrage progressif

Semaines 1 à 8 : deux personnes, sur un domaine isolé. Choisissez un périmètre fonctionnel avec peu de dépendances vers le reste du produit. L'objectif de cette phase n'est pas la production, c'est de rendre l'équipe autonome sur un morceau.

Une bonne première mission est délibérément peu risquée : écrire les tests manquants sur le domaine repris, corriger des anomalies connues, documenter ce qui ne l'est pas. Cela produit de la valeur réelle, cela oblige à lire le code, et cela ne met rien en danger.

Semaines 9 à 12 : montée à l'effectif complet. Une fois que les deux premiers relisent le code des suivants, la capacité de revue de l'équipe interne n'est plus le facteur limitant.

Le mécanisme qui change tout : la revue en deux temps

Un tech lead côté prestataire relit le code de son équipe avant qu'il n'arrive à l'équipe interne. Celle-ci ne voit que du code déjà relu, correctement découpé, avec une description compréhensible.

Cela divise par deux ou trois la charge de revue perçue côté client, et c'est probablement le facteur le plus déterminant du succès d'une équipe dédiée. Vérifiez que votre prestataire le prévoit ; s'il n'en parle pas dans sa proposition, posez la question.

Les conditions côté client

Un référent technique disponible. Pas à temps plein, mais joignable et capable de répondre dans la journée sur les questions d'architecture et d'intégration.

Un product owner qui priorise. Une équipe externe sans backlog priorisé développe ce qu'elle croit utile, ce qui est le pire des scénarios.

Les mêmes outils, les mêmes rituels. Pas de canal séparé, pas de réunion parallèle, pas de suivi dans un autre outil. Une équipe externe traitée comme externe le restera.

Le signal d'alerte à surveiller

Si, au bout de six semaines, les arrivants posent encore les mêmes questions, ce n'est pas un problème de profil : c'est que la documentation d'onboarding n'existe pas. Faites-la écrire par eux, relire par l'équipe interne. C'est la seule documentation qui soit systématiquement utile, parce qu'elle est écrite par quelqu'un qui ne savait pas.