Composer une équipe de développement externe selon le risque

Quand une direction me demande de l’aider à monter une équipe de développement externe, la première question qu’on me pose est presque toujours la même : « Combien de développeurs faut‑il ? ». C’est une question légitime, mais c’est la mauvaise pour commencer. Le nombre de développeurs dit à quelle vitesse on peut produire du code. Il ne dit rien de la probabilité que ce code fasse ce qu’il doit faire, respecte ce qu’il doit respecter et tienne en production.

Sur les équipes que j’ai composées et sur les projets que j’ai repris quand ils dérivaient, le problème venait rarement d’un manque de développeurs. Il venait d’un profil absent : personne pour tester sérieusement, personne pour arbitrer le périmètre, personne qui connaissait vraiment la règle métier ou la contrainte réglementaire. Le code avançait vite, dans la mauvaise direction.

Voici la méthode que j’applique pour composer une équipe externe à partir du risque du produit. Les proportions données plus bas sont des repères usuels, pas des normes : elles sont à ajuster à votre contexte.

1. Partir du risque, pas du volume de code

Deux produits de même taille, en nombre d’écrans ou de fonctionnalités, peuvent demander des équipes radicalement différentes. Un outil interne de suivi de stock utilisé par quinze personnes et une application de gestion de dossiers patients peuvent avoir un volume de code comparable. Le second a un risque d’erreur, de fuite et de non-conformité sans commune mesure avec le premier.

Je raisonne donc dans cet ordre :

1. quels sont les risques qui, s’ils se réalisent, coûtent le plus cher à l’entreprise ;
2. quel profil réduit chacun de ces risques ;
3. combien de capacité de développement il faut pour livrer au rythme voulu, une fois ces profils en place.

Le volume de code n’arrive qu’en troisième position. C’est lui qui fixe le nombre de développeurs, mais ce n’est pas lui qui fixe la composition.

2. Cartographier les risques du produit

Avant de parler de profils, je fais remplir une grille simple avec la direction et les métiers concernés. Pour chaque type de risque, on note s’il est faible, moyen ou fort, et surtout pourquoi.

Cette grille a un effet immédiat : elle fait apparaître les désaccords internes. Il arrive souvent que la direction pense le besoin stable alors que les métiers ne sont pas d’accord entre eux sur les règles. Mieux vaut le découvrir avant de signer avec un prestataire qu’au troisième sprint.

3. Les profils et le risque que chacun couvre

Je présente toujours les profils par le risque qu’ils réduisent, pas par leur intitulé. Les intitulés varient d’un prestataire à l’autre ; le risque couvert, lui, ne varie pas.

• Les développeurs couvrent le risque de ne pas livrer. Ils transforment des besoins précis en logiciel qui fonctionne. Ils ne couvrent pas le risque de mal comprendre le besoin, sauf à leur demander un travail d’analyse qu’ils n’ont ni le temps ni toujours la légitimité de faire.
• Le tech lead couvre le risque d’architecture et de dette : choix techniques, revue de code, cohérence d’ensemble, estimation. Dans une équipe de plus de trois ou quatre développeurs, son absence se paie en quelques mois.
• Le QA (ingénieur qualité, testeur) couvre le risque de régression et d’erreur en production. Il écrit les scénarios de test, automatise les parcours critiques, vérifie les cas limites que les développeurs n’ont pas en tête. Il est indispensable dès que l’exactitude métier ou l’exposition publique est forte.
• Le Product Owner couvre le risque de construire la mauvaise chose. Il priorise, découpe, accepte ou refuse ce qui est livré. C’est le profil dont l’absence se voit le moins au début et coûte le plus à la fin.
• L’AMOA (assistance à maîtrise d’ouvrage) couvre le risque de spécification et de recette, en particulier dans les contextes réglementés ou fortement intégrés au système d’information : expression formelle des besoins, règles de gestion écrites, cahiers de recette, traçabilité entre exigence et test.
• Les experts métier couvrent le risque d’erreur de règle. Ils ne sont pas forcément à temps plein, mais ils doivent être disponibles, identifiés et engagés sur des délais de réponse.
• Les profils d’exploitation et de sécurité (DevOps, sécurité applicative) couvrent le risque de production : déploiement, supervision, sauvegardes, gestion des accès, revue de sécurité. Souvent à temps partiel, rarement optionnels.

Un point que je vérifie systématiquement : qui, dans la composition proposée, porte chacun de ces risques. Si la réponse est « l’équipe », c’est que personne ne le porte.

4. Les proportions selon le type de produit

Une fois la grille de risques remplie, la composition se déduit assez naturellement. Voici les configurations que je retrouve le plus souvent, avec des repères qui servent de point de départ à la discussion.

Ces configurations se combinent. Une application grand public qui manipule des données de santé cumule les deux colonnes de risques, et donc les deux jeux de profils. C’est précisément là que les propositions commerciales « au volume » se trompent : elles chiffrent des développeurs et ajoutent un chef de projet, sans tenir compte de ce que le produit expose.

Un repère que j’utilise souvent : sur un produit à risque fort, si la proposition comporte moins d’un profil non développeur (QA, PO, AMOA, sécurité) pour trois ou quatre développeurs, je demande comment les risques seront couverts. Il y a parfois une bonne réponse. Souvent, il n’y en a pas.

5. Équipe intégrée ou équipe autonome qui livre

Deux modèles coexistent, et le choix entre les deux dépend moins de la préférence du prestataire que de la maturité du client.

L’équipe intégrée : les profils externes rejoignent les équipes du client, travaillent avec ses outils, ses rituels, son tech lead ou son architecte. Le client pilote au quotidien. Ce modèle convient quand le client dispose déjà d’une direction technique solide, d’un PO légitime et d’une organisation qui sait absorber des renforts.

L’équipe autonome qui livre : le prestataire fournit une équipe complète, avec son tech lead, son QA et parfois son PO délégué, et s’engage sur des livraisons. Le client pilote par les résultats. Ce modèle convient quand le client n’a pas la capacité de piloter une équipe au quotidien, à condition que la gouvernance reste chez lui (section suivante).

Le piège que j’observe le plus souvent est un modèle hybride non assumé : une équipe dite autonome, mais sans tech lead côté prestataire, qui attend les arbitrages d’un client qui pensait ne pas avoir à les donner. Chacun croit que l’autre pilote. Il faut écrire noir sur blanc qui décide de quoi.

6. Ce qui doit rester chez le client

Quel que soit le modèle, certaines responsabilités ne se délèguent pas. Je les liste dans le contrat ou dans la charte de pilotage, et je vérifie qu’un nom côté client figure en face de chacune.

• La priorisation finale. Un PO délégué peut préparer, proposer, découper. La décision de ce qui passe en premier appartient au client.
• L’acceptation des livraisons. Les critères d’acceptation sont écrits avant le développement, et la recette est validée par quelqu’un du client, pas par le prestataire seul.
• La propriété du code et des accès. Dépôt de code, hébergement, comptes cloud, nom de domaine, comptes des services tiers : au nom du client, avec des accès donnés au prestataire. C’est exactement ce qui manque dans les situations que je décris dans l’article sur le prestataire injoignable.
• Les décisions d’architecture structurantes. Le prestataire propose, le client valide, idéalement avec un regard technique indépendant. Chaque décision importante est consignée dans un registre court (contexte, options, choix, raison).
• Les indicateurs de pilotage. Le client définit ce qu’il regarde : fréquence de livraison, défauts trouvés en recette et en production, délai de correction, respect des engagements de lot. Il ne se contente pas du rapport d’activité du prestataire.

Pour le client sans direction technique, c’est le point où un regard extérieur est le plus utile : non pas pour piloter à la place du prestataire, mais pour vérifier que les livraisons, le code et les décisions tiennent la route. La même logique s’applique quand on cherche à recruter un responsable technique interne, comme je le détaille dans le guide sur le recrutement d’un CTO.

7. Monter en charge sans casser l’équipe

Ajouter des développeurs à une équipe qui fonctionne ne rend pas l’équipe proportionnellement plus productive. Chaque nouvel arrivant consomme du temps des plus anciens pendant ses premières semaines, et chaque personne supplémentaire ajoute des échanges, des conflits de fusion et des besoins de coordination.

Ma règle de montée en charge :

1. Commencer petit et complet. Un premier noyau avec tous les profils nécessaires au risque, même à temps partiel, plutôt qu’une grosse équipe de développeurs seuls. C’est ce noyau qui pose les conventions, le pipeline, les tests et la documentation.
2. Stabiliser avant d’élargir. Tant que l’équipe ne livre pas de façon régulière et prévisible, ajouter du monde aggrave le problème.
3. Élargir par équipes, pas par individus. Au-delà d’une taille d’équipe d’environ six à huit personnes, je préfère créer une deuxième équipe avec son propre périmètre, son tech lead et son QA, plutôt que de gonfler la première.
4. Faire suivre les profils non développeurs. Si l’on double le nombre de développeurs sans renforcer le QA et le PO, la recette devient le goulot, puis la qualité s’effondre.
5. Exiger un parcours d’intégration écrit. Un nouvel arrivant doit pouvoir installer l’environnement, comprendre l’architecture et livrer un premier correctif en quelques jours. Si ce n’est pas possible, c’est la documentation qu’il faut renforcer avant d’embaucher.

Je demande aussi au prestataire, dès la proposition, comment il gère la rotation de ses équipes : préavis en cas de départ, période de recouvrement entre la personne qui part et celle qui arrive, maintien des profils clés. La stabilité des personnes compte autant que leur niveau.

8. Préparer la passation dès le premier jour

Toute équipe externe finira par être réduite, remplacée ou reprise en interne. La qualité de cette passation se décide au début du contrat, pas à la fin.

Les éléments que j’exige en continu, et non au moment de la sortie :

• un dépôt de code au nom du client, avec un historique lisible et des revues de code tracées ;
• un environnement de développement reproductible (conteneurs, scripts d’installation, données de test anonymisées) ;
• un pipeline de déploiement documenté, que le client peut lancer sans le prestataire ;
• des tests automatisés sur les parcours critiques, qui servent de spécification vivante ;
• un registre des décisions d’architecture et une documentation des règles métier non évidentes ;
• l’inventaire des comptes tiers, des clés et des tâches planifiées.

Côté contrat, je vérifie trois clauses : la cession des droits sur le code au fur et à mesure des paiements, une clause de réversibilité qui décrit la période de transfert (durée, livrables, temps de recouvrement entre anciens et nouveaux intervenants) et la non-sollicitation, qui doit rester raisonnable si l’on envisage de reprendre certains profils.

Un bon test, à faire une fois par an : demander à quelqu’un qui n’a jamais vu le projet d’installer l’environnement et de déployer une modification mineure en s’appuyant uniquement sur la documentation. Ce qu’il ne parvient pas à faire est la liste de ce qu’il faudra traiter avant toute passation. C’est aussi ce qu’un acheteur regardera en cas d’opération, comme je l’explique dans l’article sur la due diligence technique.

Les leçons

• Le risque fixe la composition, le volume fixe la taille. On décide d’abord des profils qui couvrent les risques, ensuite du nombre de développeurs.
• Chaque risque doit avoir un nom en face. Si personne ne porte la qualité, la conformité ou la priorisation, elles ne sont pas portées.
• Les profils non développeurs ne sont pas un surcoût. Sur un produit à risque fort, ce sont eux qui évitent les retours en arrière les plus chers.
• Choisissez le modèle selon votre capacité de pilotage. Équipe intégrée si vous savez piloter au quotidien, équipe autonome si vous pilotez par les résultats.
• La gouvernance ne se délègue pas. Priorités, acceptation, propriété, architecture et indicateurs restent chez le client.
• On monte en charge par équipes complètes. Doubler les développeurs sans le QA et le PO déplace le goulot vers la recette.
• La passation se prépare au premier jour. Code, accès, documentation et tests au nom du client, en continu.