Deux équipes disposent de compétences techniques comparables. Elles utilisent les mêmes technologies et doivent réaliser exactement le même périmètre fonctionnel.
Pourtant, l’une connaît depuis plusieurs années le domaine métier concerné tandis que l’autre le découvre.
Peut-on réellement considérer que leur effort de réalisation sera identique ?
Pour une DSI qui chiffre un projet, prépare un appel d’offres ou compare plusieurs scénarios de réalisation, la question est importante. Une connaissance insuffisante du domaine peut entraîner davantage d’analyses, de clarifications, d’incompréhensions et de reprises.
COCOMO II prend explicitement en compte cette dimension avec le facteur APEX – Applications Experience, que nous appellerons ici Expérience du domaine applicatif.
Que mesure l’expérience du domaine applicatif ?
Ce facteur mesure le niveau d’expérience de l’équipe avec le type d’application qu’elle doit réaliser.
Il ne faut pas le confondre avec :
- la capacité générale des analystes ;
- la capacité des développeurs ;
- l’expérience de la plateforme technique ;
- la maîtrise des langages et des outils.
Un excellent développeur peut ainsi avoir une faible expérience du domaine applicatif s’il intervient pour la première fois, par exemple, sur un système de facturation énergétique.
À l’inverse, une équipe travaillant depuis plusieurs années sur ce type de système connaît déjà une partie de ses concepts, contraintes et situations particulières.
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 évalue l’expérience équivalente de l’équipe avec ce type d’application.
| Niveau | Expérience du domaine |
| Très faible | ≤ 2 mois |
| Faible | 6 mois |
| Nominal | 1 an |
| Élevé | 3 ans |
| Très élevé | 6 ans |
Il s’agit d’évaluer l’expérience de l’équipe projet, et non simplement celle de son membre le plus expérimenté.
Les coefficients COCOMO II
À chaque niveau correspond un multiplicateur d’effort.
| Niveau | Coefficient APEX |
| Très faible | 1,22 |
| Faible | 1,10 |
| Nominal | 1,00 |
| Élevé | 0,88 |
| Très élevé | 0,81 |
Le niveau nominal constitue la référence.
Un coefficient de 1,22 signifie que l’effort estimé est augmenté de 22 % par rapport à cette référence, toutes les autres caractéristiques du projet restant identiques.
À l’inverse, un coefficient de 0,81 correspond à un effort inférieur de 19 % à la référence nominale.
Exemple sur un projet de 1 000 jours-homme
Prenons un projet dont l’effort de référence est de 1 000 jours-homme avec une expérience nominale.
| Expérience | Effort obtenu | Écart / nominal |
| Très faible | 1 220 j.h | +220 |
| Faible | 1 100 j.h | +100 |
| Nominale | 1 000 j.h | — |
| Élevée | 880 j.h | -120 |
| Très élevée | 810 j.h | -190 |
Entre les deux situations extrêmes, l’écart représente 410 jours-homme.
Autre manière de lire le résultat : une équipe très peu expérimentée nécessite, selon le modèle, environ 51 % d’effort de plus qu’une équipe très expérimentée pour un même projet.
Cet écart ne doit évidemment pas être interprété comme une règle universelle applicable mécaniquement à tous les projets. Il représente l’influence statistique du facteur dans le modèle COCOMO II, toutes choses égales par ailleurs.
Cas concret : refonte d’une application bancaire
Imaginons la refonte d’une application de gestion de crédits.
Une première équipe possède de bonnes compétences techniques, mais travaille pour la première fois dans le domaine bancaire.
Elle doit progressivement comprendre les produits financiers, les règles d’éligibilité, les circuits de validation, les contraintes réglementaires, les exceptions métier et le vocabulaire utilisé par les utilisateurs.
Une seconde équipe travaille depuis plusieurs années sur des applications de crédit.
Elle connaît déjà une grande partie de ces concepts.
La différence apparaît rapidement dans les ateliers fonctionnels.
La première équipe pose davantage de questions élémentaires, interprète parfois incorrectement certaines exigences et découvre tardivement certains cas particuliers.
La seconde peut davantage concentrer ses échanges sur les spécificités du nouveau système.
Le périmètre fonctionnel à réaliser reste identique. L’effort nécessaire pour le comprendre et le transformer en logiciel ne l’est pas nécessairement.
Pourquoi l’expérience du domaine a-t-elle un tel impact ?
Plusieurs mécanismes peuvent expliquer cet effet.
Une compréhension plus rapide des exigences
Une équipe connaissant le domaine maîtrise déjà son vocabulaire, ses concepts et une partie de ses règles.
Les échanges avec les utilisateurs sont donc généralement plus efficaces.
Une meilleure identification des cas particuliers
Dans de nombreux systèmes d’information, la difficulté réside moins dans les règles générales que dans leurs exceptions.
L’expérience permet d’anticiper plus facilement ces situations.
Moins d’erreurs d’interprétation
Une exigence techniquement simple peut être mal comprise lorsque son contexte métier est inconnu.
Ces erreurs peuvent conduire à des reprises lors des phases de recette.
Des décisions plus rapides
L’expérience permet également de reconnaître des situations déjà rencontrées et de réutiliser certains raisonnements, pratiques ou solutions.
L’effet porte donc sur l’ensemble du travail de compréhension et de réalisation, et pas uniquement sur le développement.
Quels symptômes doivent alerter ?
Plusieurs signes peuvent révéler une expérience insuffisante du domaine :
- vocabulaire métier régulièrement mal compris ;
- nombreuses questions portant sur des concepts fondamentaux ;
- forte dépendance à quelques sachants ;
- multiplication des ateliers de clarification ;
- découverte tardive de règles importantes ;
- exigences fréquemment réinterprétées ;
- augmentation des anomalies liées à une mauvaise compréhension fonctionnelle ;
- reprises importantes après les premières démonstrations ou recettes.
Pris isolément, aucun de ces symptômes ne permet de conclure. Leur accumulation doit en revanche conduire à examiner la connaissance du domaine disponible dans l’équipe.
Quelles conséquences sur le chiffrage ?
Une erreur fréquente consiste à chiffrer un projet en supposant implicitement que l’équipe possède une connaissance « normale » du domaine.
Cette hypothèse doit être explicite.
Quelques questions simples peuvent être posées :
- Depuis combien de temps l’équipe travaille-t-elle sur ce type d’application ?
- Quelle proportion de l’équipe possède réellement cette expérience ?
- Les personnes expérimentées seront-elles présentes pendant toute la réalisation ?
- Les nouveaux arrivants disposeront-ils d’un accompagnement ?
- Existe-t-il une documentation métier exploitable ?
- Les experts métier seront-ils suffisamment disponibles ?
Ces informations permettent d’éviter un biais classique : utiliser les performances d’une équipe historique pour chiffrer le travail d’une nouvelle équipe qui ne possède pas encore la même connaissance.
Dans le cadre d’une externalisation, ce point mérite notamment d’être vérifié lorsque le prestataire change.
Le prix journalier d’une équipe ne suffit pas à déterminer le coût du projet. L’effort nécessaire doit également être estimé.
Comment améliorer ce facteur ?
L’expérience ne peut évidemment pas être créée instantanément. Une DSI peut néanmoins agir.
Conserver un noyau de personnes expérimentées
Lors d’un changement d’équipe ou de prestataire, maintenir quelques personnes connaissant le domaine facilite la continuité.
Organiser le transfert de connaissances
Il doit être prévu comme une activité du projet : ateliers, binômage, documentation et accompagnement des nouveaux arrivants.
Capitaliser la connaissance métier
Glossaires, règles de gestion, décisions d’architecture fonctionnelle, cas particuliers et retours d’expérience constituent un patrimoine utile aux futures équipes.
Associer suffisamment les sachants métier
Lorsque l’équipe découvre le domaine, l’accessibilité des experts métier devient particulièrement importante.
L’objectif n’est donc pas nécessairement de disposer uniquement d’experts, mais d’éviter qu’une équipe entière doive reconstruire seule une connaissance déjà présente dans l’organisation.
Quel impact des IA génératives ?
Les IA génératives modifient partiellement la question.
Elles peuvent accélérer l’accès à une documentation volumineuse, expliquer certains concepts, synthétiser des règles métier ou aider à retrouver une information dans une base documentaire.
Elles peuvent donc réduire une partie du coût d’acquisition de la connaissance.
Mais elles ne suppriment pas nécessairement l’avantage de l’expérience.
Une équipe expérimentée sait notamment quelles questions poser, quelles situations sont réellement sensibles et quelles règles apparemment secondaires peuvent devenir critiques.
Par ailleurs, une IA ne peut exploiter correctement une connaissance métier qui n’a jamais été formalisée ou mise à sa disposition.
L’IA générative tend donc davantage à modifier la manière dont la connaissance est capitalisée et transmise qu’à rendre l’expérience du domaine inutile.
Pour les DSI, elle renforce ainsi l’intérêt de disposer d’une connaissance métier structurée, documentée et accessible.
Les erreurs d’appréciation fréquentes
Confondre expertise technique et expérience métier.
Maîtriser la technologie ne signifie pas maîtriser le domaine applicatif.
Évaluer uniquement quelques experts.
La présence d’un expert ne signifie pas que toute l’équipe possède son niveau de connaissance.
Oublier le renouvellement de l’équipe.
Un historique projet de plusieurs années n’implique pas que les personnes actuellement présentes disposent de la même expérience.
Supposer que la documentation remplace totalement l’expérience.
Elle facilite fortement l’apprentissage mais ne restitue pas toujours la connaissance tacite accumulée.
Ignorer le facteur lors d’un changement de prestataire.
Deux propositions portant sur un périmètre identique peuvent reposer sur des niveaux de connaissance métier très différents.
À retenir
Expérience du domaine applicatif — 5 idées essentielles
- COCOMO II mesure l’expérience de l’équipe avec le type d’application concerné.
- Le coefficient d’effort varie de 1,22 à 0,81.
- Sur notre référence de 1 000 jours-homme, cela représente un écart de 410 jours-homme entre les situations extrêmes.
- Expertise technique et connaissance du domaine sont deux dimensions différentes.
- Capitalisation et transfert de connaissances permettent de réduire progressivement cette dépendance.
Quelles décisions pour un DSI ?
L’expérience du domaine applicatif doit être considérée à la fois comme une hypothèse de chiffrage et comme une caractéristique de l’organisation du projet.
Un DSI peut notamment décider de préserver un noyau de compétences lors d’un changement de prestataire, d’organiser formellement le transfert de connaissances, de renforcer la capitalisation métier ou d’ajuster une estimation lorsque l’équipe prévue découvre le domaine.
Il peut également demander que le niveau d’expérience supposé soit explicitement indiqué dans les estimations importantes.
Cette transparence permet de mieux comprendre pourquoi deux équipes peuvent proposer des efforts différents pour réaliser le même périmètre.
« Même périmètre ne signifie pas nécessairement même effort : l’expérience compte. »
Le conseil Estimancy
Lors d’un chiffrage, ne demandez pas seulement « Quelle est la taille du projet ? ».
Demandez également « Quelle équipe va le réaliser et quelle expérience possède-t-elle réellement de ce domaine applicatif ? »
Lorsque l’équipe n’est pas encore connue, faites de son niveau d’expérience une hypothèse explicite du chiffrage. Vous pourrez ainsi réviser l’estimation lorsque l’organisation réelle du projet sera définie.
Les valeurs de l’article sont celles du manuel COCOMO II.2000 : le facteur APEX est défini par l’expérience équivalente de l’équipe avec ce type d’application, avec cinq niveaux de ≤2 mois à 6 ans et des multiplicateurs de 1,22 à 0,81. Le manuel précise par ailleurs qu’un cost driver agit multiplicativement sur l’effort de développement.
