Deux équipes, un même projet… mais pas nécessairement le même effort
Une DSI lance deux projets de taille et de complexité comparables. Les technologies sont similaires, les exigences de qualité également. Pourtant, quelques mois plus tard, l’une des équipes avance sensiblement plus rapidement que l’autre.
Le premier réflexe consiste parfois à chercher l’explication dans les technologies, l’organisation du projet ou la qualité des spécifications.
Mais une autre variable joue un rôle majeur : la capacité de l’équipe de développement elle-même.
COCOMO II prend explicitement en compte ce phénomène à travers le facteur PCAP — Programmer Capability.
Ce facteur est issu du modèle international COCOMO II, utilisé depuis de nombreuses années pour l’estimation des projets logiciels.
Et son impact est loin d’être marginal.
Qu’est-ce que la capacité des programmeurs ?
PCAP mesure la capacité globale de l’équipe de programmeurs chargée de réaliser le logiciel.
COCOMO II précise que l’évaluation doit porter sur l’équipe et non sur les individus. Les principaux éléments considérés sont :
- la capacité ;
- l’efficacité ;
- la rigueur ;
- la capacité à communiquer ;
- la capacité à coopérer.
Le modèle souligne également qu’il ne faut pas confondre capacité et expérience.
Un développeur peut connaître parfaitement une technologie sans nécessairement présenter le même niveau d’efficacité, de rigueur ou de coopération qu’un autre.
Inversement, une équipe très performante peut avoir besoin d’acquérir de l’expérience sur un nouveau domaine.
COCOMO II traite donc séparément l’expérience applicative, celle de la plateforme et celle des langages et outils.
Les cinq niveaux de capacité
COCOMO II positionne l’équipe par rapport à une distribution de référence.
| Niveau | Position indicative | Coefficient d’effort |
| Très faible | 15e percentile | 1,34 |
| Faible | 35e percentile | 1,15 |
| Nominal | 55e percentile | 1,00 |
| Élevé | 75e percentile | 0,88 |
| Très élevé | 90e percentile | 0,76 |
Ces valeurs sont celles du manuel COCOMO II 2.1 fourni.
Il ne s’agit donc pas de catégories telles que « junior », « confirmé » ou « senior ». Une telle assimilation serait trop simplificatrice.
C’est bien la capacité collective à produire efficacement et rigoureusement qui doit être appréciée.
Que représentent ces coefficients ?
Le coefficient PCAP agit directement sur l’effort estimé.
Prenons un projet nécessitant 1 000 jours-homme avec une hypothèse nominale, toutes les autres caractéristiques restant identiques.
| Capacité | Coefficient | Effort obtenu | Écart / nominal |
| Très faible | 1,34 | 1 340 j.h | +340 j.h |
| Faible | 1,15 | 1 150 j.h | +150 j.h |
| Nominale | 1,00 | 1 000 j.h | — |
| Élevée | 0,88 | 880 j.h | −120 j.h |
| Très élevée | 0,76 | 760 j.h | −240 j.h |
Entre les deux extrêmes, l’écart atteint donc 580 jours-homme.
Cela ne signifie pas qu’une équipe « très élevée » réalisera systématiquement un projet 580 jours plus tôt : PCAP est avant tout un multiplicateur d’effort. Le délai dépend également de l’organisation, des dépendances, des contraintes de calendrier et des autres caractéristiques du projet.
Exemple : la refonte d’un portail client
Prenons une entreprise qui souhaite refondre son portail client.
Deux prestataires proposent des équipes de taille comparable.
L’équipe A dispose de développeurs techniquement compétents, mais la qualité des réalisations est irrégulière. Les revues révèlent fréquemment des défauts, certaines décisions doivent être reprises et la coopération entre développeurs est difficile.
L’équipe B travaille de manière plus homogène. Les développeurs anticipent davantage les difficultés, produisent des composants plus robustes, communiquent rapidement lorsqu’un problème apparaît et effectuent des revues efficaces.
Même avec les mêmes spécifications et la même architecture, les efforts peuvent être sensiblement différents.
C’est précisément ce que PCAP cherche à représenter.
Pourquoi la capacité des programmeurs a-t-elle autant d’impact ?
Le développement logiciel comporte une multitude de décisions quotidiennes.
Une équipe performante identifie plus rapidement une solution appropriée, produit généralement moins de défauts, détecte plus tôt les incohérences et limite les reprises.
L’effet est cumulatif.
Une différence de quelques heures sur une tâche isolée paraît négligeable. Multipliée par des centaines de tâches, de décisions, de tests, de corrections et d’intégrations, elle devient significative.
La communication joue également un rôle important. Une information mal comprise peut provoquer plusieurs jours de reprise. Une difficulté signalée rapidement peut au contraire être résolue avant d’affecter plusieurs composants.
La capacité collective influence ainsi l’effort de construction, mais aussi indirectement les risques de dérive et la qualité des réalisations.
Quels symptômes doivent attirer l’attention ?
Certains signes peuvent révéler un niveau PCAP défavorable :
- beaucoup de reprises après développement ;
- forte dispersion des performances entre membres de l’équipe ;
- difficultés récurrentes lors des revues ;
- défauts détectés tardivement ;
- solutions inutilement complexes ;
- difficultés de coopération ;
- problèmes identiques réapparaissant régulièrement ;
- faible autonomie face aux problèmes techniques ;
- qualité très variable des livrables.
Aucun de ces symptômes ne suffit isolément à déterminer un niveau PCAP. Leur accumulation constitue en revanche un signal à analyser.
Quelles conséquences sur le chiffrage ?
Une erreur fréquente consiste à chiffrer un projet comme si l’équipe était une constante.
Elle ne l’est pas.
Lors d’un chiffrage, plusieurs questions peuvent être posées :
| Question | Objectif |
| L’équipe est-elle déjà constituée ? | Savoir si PCAP peut être évalué réellement |
| Dispose-t-on de données sur des projets précédents ? | Objectiver la performance |
| Quel est le niveau de reprises ou de défauts ? | Identifier les pertes d’efficacité |
| Comment fonctionnent les revues et la coopération ? | Apprécier la rigueur collective |
| L’équipe sera-t-elle la même pendant le projet ? | Évaluer la stabilité de l’hypothèse |
Lorsque l’équipe n’est pas encore connue, il est prudent de conserver une hypothèse nominale ou d’étudier plusieurs scénarios plutôt que de supposer arbitrairement une équipe très performante.
C’est particulièrement important lors d’un appel d’offres : le prix journalier et le nombre de jours nécessaires sont deux variables différentes.
Une équipe moins chère à la journée peut finalement coûter davantage si l’effort nécessaire est sensiblement supérieur.
Comment améliorer ce facteur ?
PCAP n’est pas figé.
Plusieurs leviers peuvent améliorer la capacité collective d’une équipe.
Mieux composer les équipes
L’objectif n’est pas nécessairement de réunir uniquement les meilleurs profils individuels. Il faut rechercher un équilibre entre capacité technique, rigueur, autonomie et coopération.
Généraliser les pratiques de revue
Revues de conception, revues de code, analyse collective des défauts et retours d’expérience permettent de diffuser les bonnes pratiques.
Réduire les tâches sans valeur ajoutée
Une équipe compétente dont une part importante du temps est consacrée à contourner des problèmes d’environnement ou de processus ne peut exprimer pleinement sa capacité.
Favoriser la coopération
Une équipe dans laquelle les problèmes sont rapidement partagés limite les erreurs et les reprises.
Mesurer les résultats
Les données issues des projets précédents permettent progressivement de remplacer une appréciation subjective par des observations : effort réel, qualité, reprises, défauts ou respect des engagements.
Et les IA génératives ?
Les assistants de développement basés sur l’IA modifient progressivement la question de la capacité des programmeurs, mais ils ne la font pas disparaître.
Ils peuvent accélérer certaines tâches : génération de code, documentation, recherche de solutions, création de tests, analyse ou refactoring.
Ils peuvent donc réduire certains écarts d’exécution entre développeurs.
Mais leur utilisation efficace exige elle-même de nouvelles compétences : savoir formuler le problème, évaluer une proposition, détecter une solution incorrecte, contrôler la qualité et intégrer le résultat dans l’architecture existante.
Une équipe expérimentée dans l’utilisation de l’IA peut ainsi bénéficier davantage de ces outils qu’une équipe qui accepte leurs propositions sans recul.
Il devient donc pertinent de distinguer deux questions :
Que peut produire l’outil ?
et
Quelle est la capacité de l’équipe à utiliser, contrôler et intégrer ce qu’il produit ?
L’IA ne supprime donc probablement pas PCAP. Elle modifie progressivement ce que signifie être une équipe de développement performante.
Trois erreurs fréquentes
1. Confondre capacité et ancienneté
Dix années d’expérience ne garantissent pas automatiquement un niveau PCAP élevé.
L’expérience est importante, mais COCOMO II la traite avec d’autres paramètres.
2. Évaluer les individus plutôt que l’équipe
Une équipe constituée de très bons développeurs peut fonctionner médiocrement si la coopération est mauvaise.
Inversement, une équipe bien organisée peut produire une performance collective supérieure à ce que laisserait penser l’évaluation individuelle de ses membres.
3. Considérer PCAP comme constant
La composition d’une équipe peut changer.
Le manuel COCOMO II souligne d’ailleurs que les facteurs liés au personnel peuvent évoluer pendant le projet, notamment avec l’acquisition d’expérience ou les mouvements de personnes dans l’équipe.
L’hypothèse utilisée pour le chiffrage doit donc rester cohérente avec l’équipe réellement mobilisée.
À retenir
Capacité des programmeurs — PCAP
- COCOMO II évalue la capacité de l’équipe, pas celle d’un développeur isolé.
2. Le coefficient d’effort varie de 1,34 à 0,76.
3. Sur une référence de 1 000 jours-homme, cela représente 580 jours-homme d’écart entre les deux niveaux extrêmes.
4. Capacité et expérience sont deux notions différentes.
5. L’arrivée des IA génératives ne supprime pas ce facteur : elle en fait évoluer la nature.
Quelles décisions pour un DSI ?
La première décision consiste à ne plus considérer implicitement toutes les équipes comme interchangeables dans les estimations.
La deuxième consiste à documenter l’hypothèse de capacité utilisée lors du chiffrage.
La troisième consiste à utiliser les données des projets réalisés pour objectiver progressivement cette hypothèse.
Enfin, dans une relation de sous-traitance, PCAP rappelle une règle économique importante : comparer uniquement les tarifs journaliers peut conduire à de mauvaises décisions.
Ce qui compte pour la DSI n’est pas seulement combien coûte une journée de développement, mais combien de journées seront nécessaires pour produire le logiciel attendu.
« Le coût d’une équipe ne dépend pas seulement de son prix par jour, mais du nombre de jours dont elle aura besoin. »
Le conseil Estimancy
Lors d’un chiffrage, séparez systématiquement la taille du logiciel et les conditions dans lesquelles il sera réalisé.
La taille fonctionnelle permet de quantifier ce qu’il faut produire. Les facteurs tels que PCAP permettent ensuite d’estimer l’effort nécessaire pour le produire dans un contexte donné.
Si l’équipe n’est pas encore connue, ne transformez pas une hypothèse optimiste en certitude : chiffrez plusieurs scénarios de capacité et rendez cette hypothèse visible dans l’estimation.
C’est particulièrement utile pour comparer des scénarios internes ou des propositions de prestataires.
