Team augmentation vs externalisation complète : comment choisir pour une software house

Le problème concret

Une software house de 12 développeurs remporte un appel d'offres nécessitant trois profils seniors React/Node qu'elle n'a pas en interne. La livraison est dans 90 jours. Le CEO demande : « On fait appel à du staff augmentation ou on confie le module à un partenaire externe ? »

La mauvaise réponse ne dépend pas du modèle en lui-même. Elle vient du fait de ne pas avoir analysé trois variables : le couplage architectural, la propriété du code et la vitesse de feedback requise.

---

Définir les termes sans ambiguïté

Team augmentation (ou staff augmentation) : des ressources externes qui travaillent à l'intérieur de vos processus, avec vos outils, sous votre direction technique. Votre CTO assigne les tickets, fait les code reviews, décide de l'architecture. Le partenaire fournit la capacité d'exécution.

Externalisation complète : vous déléguez un périmètre fonctionnel à une équipe externe. Celle-ci gère le backlog de ce périmètre, décide de l'architecture interne et livre des livrables convenus. Vous définissez les exigences et validez le résultat.

Ce ne sont pas deux variantes du même modèle. Leurs structures de communication, leurs profils de risque et leurs dynamiques de coût sont radicalement différents.

---

Quand le team augmentation est pertinent

1. Le code est fortement couplé

Si le module à développer appelle directement des services internes non documentés, accède à des bases de données partagées ou repose sur des conventions non écrites connues seulement de l'équipe cœur, découper ce travail dans un périmètre externalisé est coûteux. Chaque décision nécessite une réunion d'alignement.

Dans ce cas, un développeur externe qui rejoint votre Jira, participe aux daily stand-ups et ouvre des PR sur GitHub en suivant vos conventions de branches est bien plus productif.

2. Vous avez déjà une architecture définie

Si vous disposez d'ADR (Architecture Decision Records) écrits, d'un tech lead disponible pour l'onboarding et les code reviews, et d'une suite de tests faisant office de filet de sécurité, le coût d'intégration d'une ressource externe est faible. Le risque de dérive qualitative est contenu.

3. Le besoin est temporaire et mesurable

« J'ai besoin de 2 développeurs React seniors pour 4 mois » est un cas d'école pour l'augmentation. Le périmètre est clair, la fin est définie, et vous ne souhaitez pas transférer de savoir-faire architectural à un tiers.

---

Quand l'externalisation complète est pertinente

1. Le module est découplé ou peut l'être

Un service de notifications, un système de reporting, une intégration ERP tierce : tous sont des candidats naturels à l'externalisation car ils communiquent via des API bien définies. Si vous pouvez écrire un contrat d'interface (une spec OpenAPI, un contrat Pact, un schéma GraphQL), vous pouvez externaliser le module.

# Exemple : contrat minimum pour un service de notifications externalisé
openapi: 3.1.0
info:
  title: Notification Service
  version: 1.0.0
paths:
  /notifications:
    post:
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required: [userId, channel, payload]
              properties:
                userId: { type: string }
                channel: { type: string, enum: [email, sms, push] }
                payload: { type: object }
      responses:
        '202': { description: Accepted }

Si vous parvenez à écrire cette spec avant d'engager le partenaire, l'externalisation fonctionnera. Dans le cas contraire, le module n'est probablement pas suffisamment découplé.

2. Vous n'avez pas de bande passante managériale

L'augmentation exige que quelqu'un en interne gère les ressources externes : onboarding, code reviews, feedback quotidien. Si votre tech lead est déjà à 100 % sur le projet principal, ajouter des personnes à gérer ne passe pas à l'échelle. Déléguer la gestion à un partenaire externe est alors judicieux.

3. Vous souhaitez transférer le risque opérationnel

Avec un contrat d'externalisation bien rédigé (SLA, définition de terminé, propriété des bugs post-livraison), le risque de glissement se déplace sur le partenaire. Avec l'augmentation, le risque reste le vôtre car les ressources travaillent sous votre direction.

---

La matrice de décision

| Critère | Team Augmentation | Externalisation Complète | |---|---|---| | Couplage du code | Élevé | Faible / API-first | | Disponibilité du tech lead | Disponible | Rare ou absente | | Propriété du code | Vous souhaitez la conserver | Vous acceptez de la partager | | Type de besoin | Pic temporaire | Périmètre fonctionnel stable | | Risque qualité | Contrôlé en interne | Encadré par contrat | | Vitesse de feedback | Élevée (quotidienne) | Moyenne (sprint review) |

---

L'erreur la plus fréquente

Choisir l'externalisation complète sur un module fortement couplé parce que « je ne veux pas gérer des personnes ». Résultat : le partenaire livre un code qui ne s'intègre pas, les réunions d'alignement se multiplient, les coûts explosent. On finit par payer le pire des deux modèles.

L'erreur inverse : utiliser l'augmentation sur un périmètre qui pourrait être autonome, sans jamais investir dans le découplage. L'équipe externe devient dépendante des décisions de l'équipe interne pour chaque détail, et la vélocité s'effondre.

---

Points d'action opérationnels

Avant de choisir le modèle, effectuez cette vérification :

1. Rédigez l'interface du module avant de commencer. Si vous y parvenez en moins d'une heure, le module est candidat à l'externalisation. Sinon, vous avez probablement besoin d'augmentation.
2. Comptabilisez les heures hebdomadaires que votre tech lead peut consacrer à la supervision externe. En dessous de 5 heures/semaine, l'augmentation n'est pas viable sans dégradation de la qualité.
3. Définissez qui possède le backlog : si vous souhaitez le conserver, optez pour l'augmentation. Si vous êtes prêt à le déléguer avec des critères d'acceptation, choisissez l'externalisation.

Il n'existe pas de modèle universellement meilleur. Il existe celui qui est adapté au contexte spécifique de votre projet, maintenant.

---

Evviva Group travaille avec des software houses selon les deux modèles, en white-label. Si vous évaluez quelle approche convient à votre prochain projet, nous pouvons vous aider à mener l'analyse.