Développement multisite : combien la dispersion des équipes peut-elle réellement coûter à un projet logiciel ?

Une application peut être développée par une équipe installée dans le même bâtiment. Mais elle peut aussi mobiliser une maîtrise d’ouvrage à Paris, une équipe d’architecture à Lyon, un centre de développement en Europe de l’Est et une équipe de tests en Inde.

Sur le papier, le périmètre fonctionnel reste identique. Pourtant, l’effort nécessaire pour réaliser le projet peut être sensiblement différent.

Les raisons sont nombreuses : échanges plus complexes, délais dans les décisions, incompréhensions, différences de contexte, multiplication des interfaces organisationnelles ou difficultés à résoudre rapidement un problème.

Pour une DSI, la question est donc importante : comment intégrer l’organisation géographique des équipes dans le chiffrage d’un projet ?

Que mesure le facteur « Développement multisite » ?

Le facteur SITE – Multisite Development mesure les conditions dans lesquelles des équipes réparties géographiquement collaborent pour développer un logiciel.

Il ne mesure pas uniquement la distance.

COCOMO II combine deux éléments :

  • la colocalisation des équipes, depuis une distribution internationale jusqu’à une équipe totalement regroupée ;
  • les moyens de communication, depuis des moyens très limités jusqu’à des outils multimédias interactifs.

Cette distinction est essentielle.

Une équipe distribuée disposant d’excellents moyens et pratiques de collaboration peut fonctionner plus efficacement qu’une équipe géographiquement proche mais communiquant mal.

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

Le manuel COCOMO II distingue six niveaux.

Niveau Localisation indicative Communication indicative
Très faible Distribution internationale Téléphone limité, courrier
Faible Plusieurs villes et plusieurs entreprises Téléphone individuel, fax
Nominal Plusieurs villes ou plusieurs entreprises E-mail à bande étroite
Élevé Même ville ou zone métropolitaine Communications électroniques à large bande
Très élevé Même bâtiment ou complexe Communications électroniques performantes et visioconférence occasionnelle
Extra élevé Équipe totalement colocalisée Communication multimédia interactive

Il ne faut toutefois pas appliquer mécaniquement cette correspondance. Le manuel précise que l’évaluation résulte d’une appréciation combinée des deux dimensions. Une équipe totalement colocalisée n’a, par exemple, pas besoin des moyens de communication les plus sophistiqués pour obtenir une excellente notation.

Les coefficients COCOMO II

Les multiplicateurs d’effort associés sont :

Niveau SITE Coefficient
Très faible 1,22
Faible 1,09
Nominal 1,00
Élevé 0,93
Très élevé 0,86
Extra élevé 0,80

Un coefficient supérieur à 1 augmente l’effort estimé. Un coefficient inférieur à 1 traduit des conditions plus favorables que la situation nominale.

Exemple sur un projet de 1 000 jours-homme

Prenons un projet nécessitant 1 000 jours-homme dans des conditions nominales, toutes choses égales par ailleurs.

Niveau Coefficient Effort résultant Écart / nominal
Très faible 1,22 1 220 j.h. +220
Faible 1,09 1 090 j.h. +90
Nominal 1,00 1 000 j.h.
Élevé 0,93 930 j.h. -70
Très élevé 0,86 860 j.h. -140
Extra élevé 0,80 800 j.h. -200

Entre les deux situations extrêmes, l’écart atteint donc 420 jours-homme.

Il ne faut pas interpréter ces valeurs comme une règle universelle applicable directement à tous les projets. Elles représentent l’effet du facteur SITE dans le modèle COCOMO II, les autres facteurs étant supposés inchangés.

Cas concret : déploiement d’un nouveau CRM

Imaginons une entreprise qui développe un nouveau CRM international.

L’équipe fonctionnelle travaille en France. L’intégrateur pilote le projet depuis Paris. Une partie du développement est réalisée en Europe de l’Est et les tests sont effectués par une équipe située en Asie.

Les compétences individuelles peuvent être excellentes. Pourtant, plusieurs difficultés apparaissent : une question fonctionnelle posée en fin de journée reste sans réponse jusqu’au lendemain, certains arbitrages nécessitent plusieurs réunions et les équipes n’interprètent pas toujours les exigences de la même manière.

Une anomalie qui aurait pu être réglée en quelques minutes dans une équipe colocalisée peut ainsi nécessiter plusieurs échanges.

Pris isolément, chacun de ces événements paraît insignifiant. Multiplié par des centaines de décisions et d’interactions pendant toute la durée du projet, leur impact devient significatif.

Pourquoi un tel impact ?

Le développement logiciel nécessite de nombreuses interactions.

Les analystes précisent les besoins avec les métiers. Les architectes échangent avec les développeurs. Les développeurs sollicitent les testeurs. Des arbitrages doivent être réalisés en permanence.

Lorsque les équipes sont dispersées, plusieurs phénomènes peuvent augmenter l’effort :

  • multiplication des échanges formels ;
  • temps nécessaire pour trouver le bon interlocuteur ;
  • décisions retardées ;
  • perte d’informations entre équipes ;
  • difficultés de compréhension ;
  • augmentation des besoins de documentation ;
  • reprises liées aux interprétations divergentes.

La dispersion géographique n’est donc pas le problème en elle-même. C’est principalement la friction qu’elle peut introduire dans les interactions.

Les symptômes observables

Certains signes doivent alerter un responsable de projet ou un PMO :

  • nombreuses réunions de coordination ;
  • délais importants pour obtenir une décision ;
  • multiplication des mails pour résoudre des questions simples ;
  • responsabilités mal comprises entre sites ;
  • informations différentes selon les équipes ;
  • reprises fréquentes liées à des incompréhensions ;
  • difficultés à organiser des plages de travail communes ;
  • dépendance à quelques personnes servant d’intermédiaires entre les équipes.

Ces symptômes peuvent révéler un coût de coordination insuffisamment pris en compte dans le chiffrage initial.

Conséquences sur le chiffrage

Lors du chiffrage, indiquer simplement que le projet est réalisé « en offshore » ou « en multisite » est insuffisant.

Il faut notamment demander :

Où seront situées les équipes ?

Même bâtiment, plusieurs établissements, plusieurs villes, plusieurs pays ?

Combien d’organisations interviennent ?

Une dispersion entre établissements d’une même entreprise n’est pas nécessairement comparable à une organisation associant plusieurs fournisseurs.

Quels sont les moyens de collaboration ?

Visioconférence, messagerie instantanée, espaces documentaires partagés, backlog commun, outils de conception collaborative ?

Quelles plages horaires sont réellement communes ?

La distance géographique peut devenir beaucoup plus pénalisante lorsqu’elle s’accompagne d’un décalage horaire important.

Comment sont prises les décisions ?

Une organisation claire peut réduire considérablement les délais de coordination.

L’erreur serait donc de définir SITE uniquement à partir de l’adresse des développeurs.

Comment améliorer ce facteur ?

Trois familles d’actions peuvent être envisagées.

Améliorer les moyens de collaboration. Un environnement commun de gestion des exigences, du backlog, des documents et des décisions réduit la perte d’information.

Structurer les interactions. Les responsabilités, circuits de décision, rituels et plages de disponibilité doivent être explicites.

Réduire les interfaces inutiles. Lorsque cela est possible, constituer des équipes relativement autonomes limite le nombre d’interactions nécessaires entre sites.

L’objectif n’est donc pas nécessairement de regrouper physiquement toutes les personnes. Il consiste surtout à réduire le coût de la distance.

Quel impact des IA génératives ?

Les IA génératives peuvent modifier partiellement ce facteur.

Elles peuvent faciliter la synthèse de réunions, la rédaction et la clarification de spécifications, la traduction, la recherche d’informations dans une documentation importante ou la transmission de connaissances entre équipes.

Elles peuvent donc réduire certaines frictions liées à la circulation de l’information.

Mais elles ne suppriment ni les besoins d’arbitrage ni les responsabilités organisationnelles.

Une décision retardée reste une décision retardée. Une exigence ambiguë peut être reformulée par une IA, mais l’IA ne peut pas déterminer seule quelle interprétation correspond réellement au besoin métier.

Les IA génératives réduisent donc certaines conséquences de la distance sans faire disparaître la nécessité d’une organisation efficace.

Les erreurs fréquentes

La première erreur consiste à considérer qu’avec Teams, Slack ou la visioconférence, la localisation des équipes n’a plus aucune importance.

La seconde est inverse : considérer systématiquement une organisation multisite comme moins efficace.

La troisième consiste à confondre SITE avec la compétence des équipes. COCOMO II traite les capacités et l’expérience du personnel à travers d’autres facteurs.

Enfin, une erreur classique de chiffrage consiste à retenir les conditions théoriquement prévues par l’organisation plutôt que celles qui seront réellement rencontrées par le projet.

À retenir

Développement multisite — 5 points essentiels

  1. SITE ne mesure pas uniquement la distance entre les équipes.
  2. Il combine localisation et moyens de communication.
  3. Ses coefficients COCOMO II vont de 1,22 à 0,80.
  4. Sur une base nominale de 1 000 jours-homme, cela représente jusqu’à 420 jours-homme d’écart entre les situations extrêmes.
  5. L’organisation de la collaboration doit donc être examinée dès le chiffrage.

Quelles décisions pour un DSI ?

Pour un DSI, le facteur SITE ne conduit pas à conclure qu’il faut systématiquement privilégier les équipes colocalisées.

Il invite plutôt à intégrer le coût réel de la coordination dans les décisions de sourcing et d’organisation.

Un tarif journalier inférieur sur un site distant ne garantit pas un coût projet inférieur si l’organisation génère davantage d’effort de coordination et de reprises.

Inversement, une organisation distribuée, bien outillée et disposant de processus de collaboration efficaces, peut être parfaitement pertinente.

Le DSI peut donc agir à trois niveaux : intégrer SITE dans les chiffrages, investir dans les conditions de collaboration et mesurer les frictions réellement observées sur les projets multisites.

« La distance ne coûte pas forcément cher. La difficulté à collaborer, oui. »

Le conseil Estimancy

Ne chiffrez pas un projet multisite uniquement à partir des tarifs journaliers des différentes équipes.

Lors de l’estimation, documentez explicitement la localisation des intervenants, le nombre d’organisations impliquées, les moyens de collaboration, les décalages horaires et les mécanismes de décision.

L’objectif est de vérifier que l’économie apparente sur les coûts unitaires n’est pas absorbée par un effort supplémentaire de coordination.

Partager :

Autres articles

Vous souhaitez en discuter ?

Vous souhaitez savoir comment nous aidons les entreprises à mieux maîtriser les projets logiciels ?