Une personne ou une équipe ? Comment définir l'effectif minimal d'un projet selon les compétences, dépendances et risques

La recherche ne confirme pas une règle simple comme "les petites équipes sont toujours meilleures" ou "les grandes équipes produisent toujours davantage".

Une méta-analyse publiée en 2023, portant sur 208 effets indépendants et 21 435 équipes, a trouvé une relation globale pratiquement nulle entre la taille de l'équipe et la performance à la tâche, tout en montrant une forte variabilité selon le contexte. Les auteurs indiquent notamment que l'effet de la taille change avec la complexité des tâches et les besoins de coordination. [4]

Une expérience sur une tâche complexe de cartographie de crise a également montré des avantages et des coûts liés aux équipes plus grandes : la collaboration augmentait avec la taille de l'équipe, tandis que les comportements d'effort individuel évoluaient. Dans cette expérience précise, les équipes les plus grandes ont obtenu de meilleurs résultats qu'un nombre équivalent de personnes travaillant séparément. Cela ne constitue pas une règle universelle pour tous les types de travail. [5]

La conclusion pratique est simple : le nombre de personnes doit découler de la nature du travail, pas d'un chiffre magique.

Le Scrum Guide 2020 décrit une Scrum Team comme une petite équipe pluridisciplinaire et autonome dans l'organisation de son travail. Il indique aussi qu'elle compte généralement 10 personnes ou moins. [3]

C'est une indication utile dans le contexte de Scrum, mais pas une loi universelle pour tous les projets, services, secteurs et modes de réalisation.

Un projet de construction, une campagne marketing, un audit de sécurité, un système financier et un petit site d'information ont des besoins très différents. Il ne faut pas transférer directement un seul chiffre d'un contexte à l'autre.

Le Service Standard britannique exige que les équipes de services numériques soient pluridisciplinaires et aient accès à un éventail approprié de compétences. Il précise aussi que la composition doit dépendre de ce que l'équipe doit accomplir à l'étape concernée. [1]

Une autre recommandation GOV.UK indique que la taille de l'équipe et les rôles nécessaires changent au fil des phases de construction d'un service. [2]

On peut en tirer une règle pratique :

commencez par cartographier le travail et les responsabilités, identifiez ensuite les compétences, puis seulement après affectez des personnes précises.

On ne peut pas dimensionner une équipe sur un périmètre flou.

Notez au minimum :

• le résultat attendu,
• ce qui fait partie du périmètre,
• ce qui en est exclu,
• les principales exigences de qualité,
• les contraintes de temps et de budget,
• qui acceptera le résultat,
• si l'équipe doit seulement livrer la solution ou aussi l'exploiter.

Un projet "construire une application" et un projet "concevoir, construire, sécuriser, déployer et exploiter une application pendant un an" nécessitent une couverture de travail très différente.

Au lieu de commencer par des intitulés de postes, listez les types de travail qui doivent réellement être réalisés.

Pour un service numérique, cela peut inclure :

• comprendre les besoins des utilisateurs,
• concevoir la solution,
• réaliser la partie visible par les utilisateurs,
• développer la logique côté serveur et les intégrations,
• tester,
• assurer la sécurité,
• garantir l'accessibilité,
• déployer et exploiter,
• coordonner le périmètre et les décisions.

Pour un autre type de projet, la liste sera différente.

GOV.UK indique qu'une équipe qui construit et exploite un service numérique doit disposer d'un ensemble large de compétences couvrant notamment les besoins utilisateurs, la conception, la réalisation, les tests, la sécurité, le déploiement et l'exploitation. [2]

Toutes les compétences nécessaires ne justifient pas une personne à plein temps dans l'équipe.

Pour chaque domaine, classez le besoin :

Permanent - nécessaire régulièrement et influençant directement les décisions quotidiennes.
Ponctuel - nécessaire à certaines étapes ou à certains points de contrôle.
Disponible à l'extérieur - fourni par une autre personne ou équipe si le délai de réponse et la responsabilité sont assez clairement définis.

GOV.UK autorise explicitement l'accès à une expertise spécialisée sans que le spécialiste soit nécessairement membre permanent de l'équipe. [1]

Cela permet souvent d'éviter de grossir artificiellement l'équipe sans perdre une compétence importante.

Deux personnes peuvent posséder ensemble toutes les compétences nécessaires et former malgré tout une mauvaise configuration si tout le travail dépend d'une seule chaîne étroite.

Vérifiez :

• quelles tâches peuvent avancer en parallèle,
• lesquelles doivent attendre d'autres travaux,
• qui prend les décisions qui bloquent la suite,
• de quelles équipes ou fournisseurs externes dépend le projet,
• où l'absence d'une seule personne arrêterait plusieurs domaines en même temps.

GOV.UK cite la gestion des dépendances avec d'autres équipes parmi les capacités nécessaires à la construction de services numériques. [2]

Lorsque plusieurs équipes travaillent sur un service, il faut en plus coordonner les plans et l'avancement entre elles. [8]

Certaines expertises indispensables ne sont pas visibles dans la liste des fonctionnalités, mais leur absence peut coûter cher.

Selon le projet, il peut s'agir notamment de :

• sécurité,
• protection des données,
• accessibilité,
• exigences juridiques ou sectorielles,
• fiabilité,
• migration de données,
• intégrations avec des systèmes critiques,
• technologie que l'équipe n'a jamais utilisée.

GOV.UK recommande l'accès à une expertise spécialisée lorsque le projet en a besoin et indique que la composition doit aussi refléter les hypothèses les plus risquées de la phase en cours. [1]

Cela ne signifie pas automatiquement un poste à temps plein pour chaque risque. Cela signifie que quelqu'un de compétent doit avoir une responsabilité explicite et une réelle capacité d'influencer les décisions.

Une personne peut connaître la conception, le développement, les tests et le déploiement. Cela ne signifie pas qu'elle peut réaliser tous ces travaux simultanément, quel que soit le délai.

Les ressources PMI sur la planification mettent l'accent sur l'adéquation entre compétences, disponibilité, coût, expérience et besoins du projet. [7]

Pour chaque personne, vérifiez :

• le temps réellement disponible,
• les tâches qui se disputent son attention,
• si certains travaux doivent avancer en parallèle,
• si le délai suppose des changements de contexte irréalistes entre plusieurs types de travail,
• si quelqu'un doit continuer à exploiter la solution après son lancement.

Couvrir les compétences sans couvrir le temps disponible ne revient pas à couvrir tout le projet.

L'effectif minimal doit aussi tenir compte de la continuité.

Demandez-vous :

• que se passe-t-il si une personne clé est indisponible,
• si une seule personne comprend un élément critique de la solution,
• si les décisions et les connaissances sont documentées,
• si quelqu'un d'autre peut reprendre les tâches essentielles,
• si le projet peut s'arrêter sans danger pendant une absence.

Tous les petits projets n'ont pas besoin d'une redondance complète. Pour un projet court et peu risqué, accepter consciemment ce risque peut être raisonnable.

Dans un projet critique, la même dépendance envers une seule personne peut être inacceptable.

Un projet n'a pas besoin d'une personne distincte pour chaque intitulé de rôle.

Si une personne possède réellement les compétences nécessaires, dispose d'une capacité suffisante et ne crée pas un risque inacceptable, elle peut couvrir plusieurs domaines de façon responsable.

Par exemple, dans un petit projet, une personne peut combiner la conception d'interface et sa réalisation. Dans un autre, elle peut combiner l'analyse métier et la coordination du périmètre.

Il ne faut pas fusionner des responsabilités uniquement parce que "quelqu'un doit bien le faire". La combinaison n'a de sens que si la personne peut assurer les deux responsabilités au niveau attendu et dispose du temps nécessaire.

Une seule personne peut constituer une configuration rationnelle lorsque toutes ces conditions sont réunies :

• le périmètre est réduit et bien défini,
• les compétences nécessaires correspondent réellement à ses capacités,
• les tâches exigent peu de travail en parallèle,
• les dépendances externes sont limitées,
• le risque est acceptable,
• le délai correspond à la capacité réelle,
• l'absence de remplaçant est acceptée consciemment.

Cela peut correspondre à un petit support d'information, une analyse simple, une consultation ponctuelle ou une mise en place limitée dans un environnement familier.

Tout dépend néanmoins du périmètre précis. L'étiquette "petit projet" ne suffit pas à trancher.

Une équipe devient plus justifiée lorsque plusieurs de ces conditions apparaissent :

• les compétences requises sont trop larges pour une seule personne,
• plusieurs travaux doivent avancer en parallèle,
• le délai est plus court qu'une réalisation séquentielle réaliste,
• le projet comporte de nombreuses dépendances et interfaces,
• le risque exige une expertise spécialisée indépendante,
• la solution doit être construite et exploitée en même temps,
• une seule personne deviendrait un point critique pour tout le projet,
• la responsabilité couvre plusieurs disciplines très différentes.

Dans ces conditions, ajouter les compétences manquantes est plus important que simplement ajouter des personnes.

Ajouter des personnes augmente la réserve de connaissances et la capacité potentielle, mais peut également multiplier les dépendances, les transferts de travail et le besoin d'aligner les décisions.

Une étude de projets logiciels publiée dans le Journal of Systems and Software a montré que les relations entre taille d'équipe, productivité, effort et durée sont complexes et ne correspondent pas toujours aux intuitions. [6]

La méta-analyse sur la taille des équipes montre également que les résultats dépendent du contexte de la tâche et du coût des processus collectifs. [4]

La bonne question n'est donc pas "combien de personnes pouvons-nous ajouter ?", mais "la personne suivante supprime-t-elle une contrainte réelle du projet plus qu'elle n'augmente le coût de coordination ?"

Toutes les compétences importantes n'ont pas besoin d'être présentes chaque jour.

Une présence permanente est plus pertinente lorsque la personne prend régulièrement des décisions, que son travail dépend fortement d'autres domaines ou qu'une réaction rapide est nécessaire.

Un soutien ponctuel peut suffire lorsque l'expertise est requise à certains moments, par exemple pour une revue, une consultation, une évaluation des risques ou une validation spécialisée.

Une condition reste essentielle : la disponibilité doit être réelle. Il faut savoir :

• qui est responsable,
• quand la personne est disponible,
• quel délai de réponse est prévu,
• quelles décisions elle peut prendre,
• ce qui se passe si elle détecte un problème.

Un accès théorique à un spécialiste sans responsabilité définie peut être rassurant sur un organigramme et inefficace dans un projet réel.

Supposons que l'objectif soit de lancer un système de réservation en ligne.

Variante A : prototype simple pour tester l'idée
Le périmètre est limité, sans paiement ni données particulièrement sensibles, et l'objectif est de tester le parcours avec un petit groupe d'utilisateurs. Une personne polyvalente peut éventuellement couvrir la conception et la réalisation, avec une consultation ponctuelle si nécessaire.

Variante B : service public avec comptes, paiements et intégrations
Il faut davantage de spécialisation, de tests, de gestion des risques, de dépendances et de travaux parallèles. Une équipe de plusieurs personnes devient nettement plus justifiée.

Variante C : service en fonctionnement continu avec réponse rapide aux incidents
À la construction s'ajoutent l'exploitation, la surveillance, la réponse aux incidents et la continuité des connaissances. L'effectif nécessaire au lancement peut ne pas suffire pour une exploitation durable.

Il s'agit du même type général de produit, mais un périmètre, un risque et un modèle d'exploitation différents créent des besoins d'équipe différents.

1. Vous partez d'une liste de postes prédéfinie au lieu du travail à accomplir.

2. Vous supposez que chaque rôle nécessite une personne distincte.

3. Vous regardez uniquement les compétences et ignorez le temps disponible.

4. Vous ajoutez des personnes sans supprimer les dépendances et les goulets d'étranglement.

5. Vous négligez les compétences liées aux risques parce qu'elles ne produisent pas une fonctionnalité visible.

6. Vous faites dépendre plusieurs domaines critiques d'une seule personne sans accepter consciemment le risque.

7. Vous considérez la composition initiale comme figée jusqu'à la fin du projet.

GOV.UK indique explicitement que la taille et les rôles d'une équipe évoluent au fil des phases de développement d'un service. [2]

C'est aussi une règle raisonnable en dehors des services publics :

• au début, davantage de recherche et de clarification du problème peuvent être nécessaires,
• pendant la réalisation, les compétences de production et de test prennent plus de poids,
• avant le lancement, sécurité, qualité et préparation opérationnelle peuvent demander plus d'attention,
• après le lancement, l'équilibre se déplace entre évolution et exploitation.

L'effectif minimal dépend de la phase et du périmètre, ce n'est pas un nombre fixé une fois pour toutes.

Pour chaque domaine important, notez cinq éléments :

Domaine de travail - que faut-il réaliser ?
Compétence - quels savoirs et savoir-faire sont nécessaires ?
Responsabilité - qui décide et répond du résultat ?
Disponibilité - la compétence est-elle permanente, ponctuelle ou externe ?
Risque d'absence - que se passe-t-il si la compétence manque ou si la personne est indisponible ?

Affectez ensuite seulement des personnes précises.

Si une personne couvre plusieurs lignes, vérifiez son temps et ses dépendances. Si une ligne nécessite plusieurs personnes, vérifiez si la raison est la capacité, un contrôle indépendant ou le besoin de travail parallèle.

1. Chaque domaine de travail obligatoire a-t-il un responsable ?
2. Chaque responsabilité critique est-elle portée par une personne compétente ?
3. Une personne cumule-t-elle plusieurs rôles, et a-t-elle réellement le temps nécessaire ?
4. Le projet exige-t-il du travail parallèle que l'équipe actuelle ne peut pas soutenir ?
5. Connaissons-nous les principales dépendances envers d'autres personnes, équipes et fournisseurs ?
6. Les risques importants disposent-ils de la bonne expertise spécialisée ?
7. L'absence d'une seule personne peut-elle arrêter tout le projet ?
8. La composition suffit-elle non seulement pour construire, mais aussi pour lancer et exploiter la solution si cela fait partie du périmètre ?
9. Savons-nous quelles compétences peuvent être ponctuelles plutôt que permanentes ?
10. Avons-nous défini des moments où la composition sera réévaluée après un changement de périmètre ou de phase ?

La composition d'une équipe ne devrait pas commencer par la question :

"combien de personnes faut-il habituellement pour ce type de projet ?"

Un meilleur ordre est :

résultat -> travail -> compétences -> dépendances -> risque -> capacité -> personnes.

Si, après cette analyse, une seule personne couvre réellement tout, elle peut être le bon choix.

S'il manque des compétences, du temps, un contrôle indépendant, de la continuité ou la capacité à travailler en parallèle, il faut ajouter des personnes ou assurer un accès fiable à des spécialistes.

L'objectif n'est pas d'avoir l'équipe la plus petite. L'objectif est d'avoir la plus petite composition capable de livrer réellement le résultat attendu au niveau de risque et de qualité requis.

[1] GOV.UK Service Standard - Have a multidisciplinary team
Ouvrir la source

[2] GOV.UK Service Manual - Set up a service team at each phase
Ouvrir la source

[3] The Scrum Guide, 2020 - Scrum Team
Ouvrir la source

[4] Bernerth, Beus, Helmuth, Boyd - The more the merrier or too many cooks spoil the pot? A meta-analytic examination of team size and team effectiveness, Journal of Organizational Behavior, 2023
Ouvrir la source

[5] Mao, Mason, Suri, Watts - An Experimental Study of Team Size and Performance on a Complex Task, PLOS ONE, 2016
Ouvrir la source

[6] Rodríguez, Sicilia, García, Harrison - Empirical findings on team size and productivity in software development, Journal of Systems and Software, 2012
Ouvrir la source

[7] Project Management Institute - Solving The Resource Puzzle
Ouvrir la source

[8] GOV.UK Service Manual - Running more than one service team
Ouvrir la source

Note méthodologique : certaines sources concernent les services publics numériques, d'autres les équipes Scrum, la gestion de projet ou la recherche sur les équipes et le développement logiciel. Ce guide n'utilise chaque source que pour les points qu'elle soutient. La méthode en sept étapes est une synthèse éditoriale de ces principes, et non une norme formelle des organisations citées.