La taille critique de l'équipe : bien dimensionner une équipe en run

Une application livrée n’est pas une application terminée. Une fois en production, elle doit être maintenue, corrigée, exploitée — et cela a un coût, en personnes comme en compétences. La question se pose alors, souvent trop tard : combien faut-il de personnes, chaque mois, pour que le projet tienne la route ?

Pour y répondre de façon moins intuitive et plus outillée, nous expérimentons chez Red Froggy une notion que nous appelons la taille critique de l’équipe (TCE).

La méthode décrite ici est propre à Red Froggy et est en cours d’expérimentation. Elle a vocation à être affinée projet après projet.

Définir la taille critique

La taille critique de l’équipe est le nombre d’équivalents temps plein (ETP) nécessaire, chaque mois, pour maintenir une application et réaliser les ajustements nécessaires à son exploitation : assistance de niveau 3, corrections, exploitation.

On parle de taille critique car en dessous de ce seuil, la pérennité du projet est menacée. Ces ETP peuvent être internalisés ou externalisés, peu importe : c’est le volume et la qualification qui comptent.

Point important : la TCE ne tient pas compte des évolutions et des nouvelles fonctionnalités. Leur impact dépend de la stratégie d’innovation du projet. Un produit très innovant, ou qui cherche à rattraper un retard fonctionnel, devra pondérer sa TCE en conséquence et renforcer l’équipe, même temporairement.

Les facteurs qui font bouger le curseur

La TCE n’est pas une constante universelle : elle dépend de plusieurs facteurs, à raffiner pour chaque projet.

• La complexité technique et/ou fonctionnelle. Une complexité fonctionnelle touche autant la conception que le développement ; une complexité technique pèse surtout sur le développement. Dans les deux cas, elle alourdit les charges de correction comme de réalisation.
• La maintenabilité. Dissociée de la complexité, c’est la capacité d’une application à être appréhendée, déployée, auditée, et à évoluer sans remise en cause profonde. Plus une application est maintenable, moins elle génère de coûts cachés. On l’évalue à la complétude de la documentation, aux bonnes pratiques de développement, à une méthodologie claire, à de la documentation auto-générée…
• La qualité. Tests et leur couverture, documentation, traçabilité des spécifications. Plus une application est de qualité, moins les développements sont onéreux : les tests guident le développeur et détectent les régressions, la documentation accélère la prise en main.
• La diversité et la maturité des utilisateurs. En phase de run, les utilisateurs manipulent l’application. Plus ils sont nombreux, variés et hétérogènes dans leur maîtrise, plus la pression sur l’assistance de niveau 3 est forte.

Les conséquences d’un mauvais dimensionnement

Se tromper sur la TCE coûte cher, dans les deux sens.

En dessous de la TCE, l’équipe ne peut plus absorber la charge de base — exploitation, accompagnement, corrections. La qualité de service se dégrade, les corrections s’allongent. Premier sacrifié : la qualité de l’application elle-même (documentation et tests laissés de côté), ce qui… augmente mécaniquement la TCE nécessaire. L’impact est aussi humain : les équipes s’essoufflent, le turn-over grimpe, la connaissance se perd.

Au-dessus de la TCE, le problème est plus discret mais réel. L’équipe est sous-sollicitée, un « faux rythme » s’installe et ankylose la productivité. Le coût devient démesuré par rapport aux besoins, et revenir en arrière peut impliquer des décisions douloureuses. Là encore, le turn-over peut augmenter : les profils les plus dynamiques s’ennuient.

Au-delà de la quantité : la qualification

Le bon nombre d’ETP ne suffit pas : leur qualification est tout aussi importante. Il faut veiller à conserver l’ensemble des compétences nécessaires — quitte à maintenir certaines expertises à temps partiel. Garder un architecte, même partiellement, évite une dérive lente de la maintenabilité et de la qualité. On veillera aussi au maintien des connaissances et de l’histoire du projet.

Une méthode d’estimation

Nous estimons la TCE en quelques étapes.

1. Le ratio projet (Rp) : le rapport entre la charge totale d’une tâche (conception, développement, documentation, tests, livraisons, corrections…) et sa seule charge de développement/test. Exemple : 10 jours de projet pour 3 jours de développement donnent un Rp de 3,33.
2. La charge récurrente : le pourcentage de la charge de développement consacré à des tâches qui perdureront en run (corrections, ajustements, tests) et sa charge mensuelle moyenne.

Une difficulté se présente : entre le build et le run, la nature du projet change. On passe d’une production massive de fonctionnalités, pour atteindre le MVP, à un développement plus raisonné. Pour simplifier, nous retenons une règle pratique : pour un MVP, conserver environ 60 % de l’équipe de build donne une TCE viable. Pour une équipe de build composée d’un concepteur/PO et de trois développeurs, cela donne une TCE non pondérée de 4 × 0,6 = 2,4.

Reste à pondérer cette valeur en fonction du projet. Chaque facteur (complexité, maintenabilité, qualité, diversité et maturité des utilisateurs) est noté entre 0 et 2 — 0 pour une influence positive, 1 neutre, 2 négative. La moyenne de ces notes ajuste la TCE à la hausse ou à la baisse selon la réalité du terrain.

Pourquoi nous nous y intéressons

Dimensionner une équipe de run « au doigt mouillé » expose à deux dangers symétriques : l’étouffement ou le gaspillage. La TCE n’a pas la prétention d’être une science exacte — elle est en cours d’expérimentation — mais elle nous donne un cadre commun pour discuter du bon dimensionnement avec nos clients, de façon transparente et argumentée.

C’est dans cet esprit que nous l’affinons, projet après projet : non pour produire un chiffre magique, mais pour rendre visible et discutable ce qui reste trop souvent une décision prise à l’instinct.