Un projet peut réunir d’excellents experts, disposer des technologies appropriées et bénéficier d’un budget suffisant… tout en consommant beaucoup plus d’effort que prévu.
La cause n’est pas nécessairement technique.
Dans les grands projets SI, une part importante de l’effort peut être absorbée par les interactions : objectifs contradictoires, décisions difficiles à obtenir, arbitrages répétés, incompréhensions entre métiers et IT, relations complexes entre équipes internes et prestataires.
La cohésion de l’équipe devient alors une véritable variable économique du projet.
Ce que mesure la cohésion de l’équipe
Dans COCOMO II, la cohésion ne désigne pas simplement la bonne entente entre développeurs.
Elle concerne l’ensemble des parties prenantes : utilisateurs, clients ou métiers, développeurs, mainteneurs, équipes d’interface et autres acteurs impliqués.
Le modèle examine notamment quatre dimensions :
- la cohérence entre les objectifs et les cultures des parties prenantes ;
- leur capacité et leur volonté à prendre en compte les objectifs des autres ;
- leur expérience du travail en équipe ;
- les actions réalisées pour construire une vision et des engagements communs.
Une équipe peut donc être techniquement excellente et présenter néanmoins une cohésion faible.
Ce facteur est issu du modèle international COCOMO II, utilisé depuis de nombreuses années pour l’estimation des projets logiciels.
Les différents niveaux
COCOMO II distingue six niveaux.
| Niveau | Situation caractéristique |
| Très faible | Interactions très difficiles |
| Faible | Certaines interactions difficiles |
| Nominal | Relations globalement coopératives |
| Élevé | Coopération importante |
| Très élevé | Coopération très forte |
| Exceptionnel | Interactions pratiquement sans friction |
Le classement ne repose pas sur une impression générale. Il résulte de l’évaluation des objectifs, de la capacité à faire des compromis, de l’expérience collective et de la construction d’une vision commune.
Les coefficients COCOMO II
La cohésion de l’équipe est un facteur d’échelle. Elle ne fonctionne donc pas comme un simple coefficient multiplicateur appliqué directement à l’effort.
| Niveau | Coefficient TEAM |
| Très faible | 5,48 |
| Faible | 4,38 |
| Nominal | 3,29 |
| Élevé | 2,19 |
| Très élevé | 1,10 |
| Exceptionnel | 0,00 |
Plus le coefficient est élevé, plus il contribue aux déséconomies d’échelle du projet.
Cette particularité est essentielle : l’effet de la cohésion augmente avec la taille du projet.
Exemple chiffré
Prenons un projet dont l’effort de référence est de 1 000 jours-homme avec une cohésion nominale.
Pour illustrer l’effet propre du facteur TEAM, considérons un projet de taille significative, équivalent à 100 KSLOC dans le modèle COCOMO II, toutes les autres hypothèses restant inchangées.
| Cohésion | Effort relatif | Écart |
| Très faible | ≈ 1 106 j.h | +106 j.h |
| Faible | ≈ 1 052 j.h | +52 j.h |
| Nominale | 1 000 j.h | Référence |
| Élevée | ≈ 951 j.h | –49 j.h |
| Très élevée | ≈ 904 j.h | –96 j.h |
| Exceptionnelle | ≈ 859 j.h | –141 j.h |
L’écart entre les deux situations extrêmes atteint ainsi environ 247 jours-homme.
Ces valeurs sont une illustration du fonctionnement du modèle, et non un coefficient universel applicable à tous les projets. TEAM étant un facteur d’échelle, son impact dépend de la taille du logiciel.
Cas concret : un projet de portail client
Imaginons la refonte du portail client d’une grande entreprise.
Le projet réunit le marketing, les métiers, la DSI, l’équipe UX, la cybersécurité, l’architecture, plusieurs équipes de développement et un intégrateur externe.
Individuellement, chacune de ces équipes est compétente.
Mais leurs objectifs diffèrent.
Le marketing souhaite lancer rapidement de nouvelles fonctionnalités. La sécurité impose des contrôles supplémentaires. L’architecture souhaite standardiser les composants. Le métier demande des adaptations spécifiques. Le prestataire cherche à respecter son périmètre contractuel.
Les décisions deviennent longues.
Une fonctionnalité validée par le métier peut être remise en cause par l’architecture. Une solution proposée par les développeurs peut être rejetée par la sécurité. Des exigences évoluent après le début du développement.
L’effort supplémentaire ne vient pas d’une difficulté intrinsèque à programmer le portail.
Il vient de la difficulté à synchroniser ses acteurs.
Pourquoi un tel impact ?
La cohésion influence plusieurs mécanismes.
Les communications augmentent.
Plus les acteurs sont nombreux et mal alignés, plus il faut organiser de réunions, expliquer les décisions et gérer les interfaces.
Les décisions prennent davantage de temps.
Lorsque les objectifs divergent, les arbitrages remontent plus haut dans l’organisation.
Les reprises augmentent.
Une décision insuffisamment partagée peut entraîner une modification des exigences, de l’architecture, du développement ou des tests.
Les interfaces deviennent plus coûteuses.
Chaque équipe peut optimiser son propre périmètre sans optimiser le système global.
C’est précisément pour cette raison que COCOMO II classe TEAM parmi les facteurs d’échelle plutôt que parmi les simples multiplicateurs d’effort.
Symptômes observables
Plusieurs signes doivent attirer l’attention :
- réunions fréquentes sans décisions claires ;
- décisions régulièrement remises en cause ;
- objectifs différents selon les équipes ;
- arbitrages systématiquement remontés au management ;
- incompréhensions récurrentes entre métiers et IT ;
- responsabilités mal définies ;
- équipes qui travaillent essentiellement par silos ;
- relations contractuelles tendues avec les fournisseurs ;
- nombreuses reprises après validation ;
- faible expérience de travail commun entre les principaux acteurs.
Un seul de ces symptômes ne suffit pas à conclure à une faible cohésion. Leur accumulation constitue en revanche un signal important.
Conséquences sur le chiffrage
Une estimation fondée uniquement sur la taille fonctionnelle et la technologie risque de sous-estimer l’effort si elle suppose implicitement une organisation parfaitement fluide.
Quelques questions simples permettent de qualifier la situation :
Les principales parties prenantes ont-elles déjà travaillé ensemble ?
Leurs objectifs sont-ils clairement identifiés et compatibles ?
Les responsabilités de décision sont-elles définies ?
Existe-t-il des divergences importantes entre métiers, DSI, architecture, sécurité ou fournisseurs ?
Des mécanismes d’arbitrage sont-ils opérationnels ?
Une vision commune du produit a-t-elle été formalisée ?
L’objectif n’est pas de transformer le chiffrage en audit organisationnel.
Il s’agit d’éviter qu’une hypothèse implicite — « les équipes travailleront normalement ensemble » — masque un risque d’effort significatif.
Comment améliorer ce facteur ?
La cohésion n’est pas totalement subie. COCOMO II la considère justement parmi les facteurs sur lesquels le management peut agir.
Clarifier les objectifs
Les objectifs du projet doivent être partagés, mais également hiérarchisés.
Coût, délai, sécurité, qualité, évolutivité et richesse fonctionnelle ne peuvent pas toujours être maximisés simultanément.
Clarifier les responsabilités de décision
Un projet perd beaucoup de temps lorsqu’il est impossible de déterminer qui peut arbitrer.
Les responsabilités doivent être explicites avant que les conflits apparaissent.
Construire une vision commune
Les ateliers de cadrage, prototypes, scénarios utilisateurs et revues d’architecture peuvent contribuer à construire une représentation commune du produit.
Stabiliser les interfaces organisationnelles
Changer continuellement d’interlocuteurs oblige les acteurs à reconstruire leurs relations et leurs modes de fonctionnement.
Mesurer les reprises
Les reprises liées à des décisions tardives constituent un excellent indicateur du coût réel du manque d’alignement.
Et les IA génératives ?
Les IA génératives peuvent améliorer certains mécanismes de collaboration.
Elles peuvent faciliter la synthèse de réunions, reformuler des exigences, détecter des incohérences, comparer plusieurs versions d’un besoin ou rendre une documentation plus accessible aux différentes parties prenantes.
Elles peuvent donc réduire certains coûts de communication.
Mais elles ne résolvent pas une divergence d’objectifs.
Une IA peut identifier que deux exigences sont contradictoires. Elle ne peut pas décider à la place de l’organisation si la priorité doit être donnée au métier, à la sécurité, au délai ou au coût.
L’IA modifie donc davantage la manière de gérer la cohésion qu’elle ne supprime son importance.
Elle peut rendre les désaccords visibles plus tôt. La décision et l’alignement restent cependant des responsabilités humaines et organisationnelles.
Les erreurs fréquentes
Confondre cohésion et compétence.
Une équipe composée d’experts n’est pas nécessairement une équipe cohérente.
Limiter l’analyse aux développeurs.
COCOMO II considère l’ensemble des parties prenantes.
Confondre absence de conflit et cohésion.
Une équipe peut éviter les conflits tout en conservant des objectifs divergents.
Considérer ce facteur comme intangible.
La gouvernance, les mécanismes d’arbitrage et la construction d’une vision commune permettent d’agir dessus.
L’évaluer trop tard.
Lorsque les difficultés deviennent visibles pendant le développement, une partie du surcoût est déjà engagée.
À retenir
5 idées essentielles
- La cohésion concerne toutes les parties prenantes, pas seulement les développeurs.
- Elle dépend notamment de la convergence des objectifs et de la capacité à travailler collectivement.
- Une faible cohésion génère communication supplémentaire, arbitrages et reprises.
- Son impact augmente avec la taille du projet : c’est un facteur d’échelle.
- Elle doit donc être évaluée dès le chiffrage, et non lorsque les difficultés apparaissent.
Quelles décisions pour un DSI ?
La première décision consiste à ne plus considérer la cohésion comme un simple sujet de management humain déconnecté du chiffrage.
Sur les projets importants, elle constitue une hypothèse économique.
Un DSI peut donc demander que les estimations des projets stratégiques qualifient explicitement l’alignement des principales parties prenantes.
Il peut également renforcer les dispositifs de cadrage et d’arbitrage sur les projets présentant une faible cohésion initiale.
Enfin, il peut décider de ne pas répondre automatiquement aux difficultés par l’ajout de ressources.
Ajouter des personnes augmente aussi le nombre d’interactions à gérer. Si le problème initial est un manque d’alignement, renforcer l’équipe sans traiter la gouvernance peut aggraver la situation.
« La performance d’un projet dépend moins du nombre d’experts que de leur capacité à avancer dans la même direction. »
Le conseil Estimancy
Lors d’un chiffrage, ne demandez pas seulement « de quelles compétences disposons-nous ? »
Demandez également :
« Ces acteurs ont-ils des objectifs compatibles et savent-ils déjà travailler ensemble ? »
Sur un projet important, cette question peut expliquer une part significative de l’écart entre l’effort théorique et l’effort réellement nécessaire.
Les six coefficients utilisés ci-dessus — 5,48 ; 4,38 ; 3,29 ; 2,19 ; 1,10 ; 0,00 — sont ceux du manuel COCOMO II.2000. Les quatre dimensions proposées pour apprécier TEAM viennent également directement de la définition détaillée du modèle.
