Deux projets peuvent présenter une taille fonctionnelle comparable, mobiliser des technologies similaires et pourtant nécessiter des efforts sensiblement différents.
L’une des raisons est simple : dans un cas, l’organisation sait où elle va. Dans l’autre, elle doit découvrir une partie du chemin.
Cette différence est souvent perçue intuitivement par les chefs de projet. Elle est pourtant rarement formalisée dans les chiffrages.
COCOMO II la prend explicitement en compte à travers le facteur Precedentedness (PREC), que nous appellerons ici Familiarité du projet.
Ce facteur est issu du modèle international COCOMO II, utilisé depuis de nombreuses années pour l’estimation des projets logiciels.
Qu’est-ce que la familiarité du projet ?
La familiarité mesure à quel point le projet ressemble à des projets que l’organisation a déjà réalisés.
COCOMO II considère notamment :
- la compréhension des objectifs du produit par l’organisation ;
- l’expérience acquise sur des systèmes comparables ;
- la nécessité de développer simultanément de nouveaux matériels ou de nouvelles procédures opérationnelles ;
- le besoin de mettre en œuvre des architectures ou algorithmes innovants.
Un projet n’est donc pas « familier » simplement parce que l’équipe connaît la technologie utilisée.
Une banque qui développe son dixième portail client dispose probablement de nombreux repères : architecture, sécurité, authentification, parcours utilisateurs, interfaces avec le SI, procédures de mise en production, tests, exploitation.
La même banque qui développe pour la première fois un système reposant sur un nouveau modèle métier, une architecture nouvelle et de nouvelles procédures opérationnelles se trouve dans une situation différente.
La quantité de logiciel à produire peut être identique. L’incertitude ne l’est pas.
Les différents niveaux
COCOMO II définit six niveaux.
| Niveau | Situation |
| Très faible | Projet totalement nouveau |
| Faible | Projet largement nouveau |
| Nominal | Projet partiellement nouveau |
| Élevé | Projet globalement familier |
| Très élevé | Projet largement familier |
| Extra élevé | Projet parfaitement familier |
Plusieurs dimensions permettent d’apprécier cette familiarité : connaissance des objectifs, expérience de systèmes comparables, nouveauté des procédures ou équipements associés et besoin d’innovation technique.
Il faut donc évaluer le projet dans son ensemble et non simplement demander : « L’équipe connaît-elle le sujet ? »
Les coefficients COCOMO II
COCOMO II associe les valeurs suivantes au facteur PREC :
| Niveau | Valeur COCOMO II |
| Très faible | 6,20 |
| Faible | 4,96 |
| Nominal | 3,72 |
| Élevé | 2,48 |
| Très élevé | 1,24 |
| Extra élevé | 0,00 |
Attention à leur interprétation.
Ces valeurs ne sont pas des multiplicateurs d’effort. PREC fait partie des cinq facteurs d’échelle de COCOMO II. Il intervient dans l’exposant de l’équation d’effort.
Cela a une conséquence importante : l’impact de la familiarité augmente avec la taille du projet.
La familiarité est donc particulièrement importante pour les grands projets SI.
Exemple : un projet de référence de 1 000 jours-homme
Prenons, à titre pédagogique, un projet logiciel de taille importante — correspondant ici à 100 KSLOC dans l’équation COCOMO II — dont l’effort est normalisé à 1 000 jours-homme au niveau nominal.
En ne faisant varier que la familiarité du projet, nous obtenons approximativement :
| Familiarité | Effort relatif | Effort indicatif |
| Très faible | 112 % | 1 121 j.h |
| Faible | 106 % | 1 059 j.h |
| Nominale | 100 % | 1 000 j.h |
| Élevée | 94 % | 945 j.h |
| Très élevée | 89 % | 892 j.h |
| Extra élevée | 84 % | 843 j.h |
Entre un projet totalement nouveau et un projet parfaitement familier, l’écart atteint donc près de 280 jours-homme dans cet exemple.
Ce tableau ne doit toutefois pas être utilisé comme une grille universelle : puisque PREC est un facteur d’échelle, le pourcentage d’écart dépend de la taille du logiciel.
C’est précisément ce qui rend ce facteur particulièrement intéressant pour les DSI : les conséquences de la nouveauté deviennent progressivement plus importantes lorsque la taille du projet augmente.
Cas concret : le remplacement d’un CRM
Imaginons une grande entreprise qui remplace son CRM.
Dans un premier scénario, elle a déjà réalisé plusieurs transformations comparables. Les équipes connaissent les processus commerciaux, les référentiels clients, les interfaces avec l’ERP, les mécanismes d’authentification, la reprise des données et les contraintes réglementaires.
Le nouveau CRM introduit peu de concepts réellement nouveaux.
Le projet est fortement familier.
Dans un second scénario, l’entreprise profite du remplacement du CRM pour transformer simultanément ses processus commerciaux, introduire une nouvelle architecture, modifier son référentiel client et mettre en place de nouvelles interfaces avec plusieurs systèmes.
La taille fonctionnelle du CRM peut être comparable.
Mais les deux projets ne présentent clairement pas le même profil de risque ni le même besoin d’apprentissage.
Pourquoi un tel impact ?
La nouveauté génère plusieurs formes d’effort qui ne sont pas toujours visibles dans le périmètre fonctionnel.
Il faut comprendre le domaine, explorer différentes solutions, réaliser des prototypes, prendre davantage de décisions, vérifier les hypothèses et parfois remettre en cause des choix déjà réalisés.
Elle augmente également le risque de découvrir tardivement une contrainte importante.
Une équipe expérimentée sur des projets similaires dispose au contraire de références.
Elle sait davantage :
- quelles questions poser ;
- quels risques rechercher ;
- quelles solutions fonctionnent ;
- quelles solutions ont déjà échoué ;
- quelles interfaces sont sensibles ;
- quels délais sont réalistes.
L’expérience réduit donc principalement l’incertitude et le besoin d’apprentissage.
Quels symptômes doivent alerter ?
Plusieurs signes doivent attirer l’attention lors d’un chiffrage :
- « Nous n’avons jamais réalisé ce type de projet. »
- Les experts métier eux-mêmes ont du mal à préciser la cible.
- Plusieurs technologies ou architectures sont nouvelles pour l’organisation.
- Les processus opérationnels doivent évoluer simultanément.
- Les interfaces avec le SI existant sont encore mal connues.
- Les équipes utilisent principalement des analogies avec des projets assez différents.
- Le projet nécessite des expérimentations ou des prototypes pour valider certains choix.
Pris isolément, aucun de ces éléments ne suffit à conclure.
Leur accumulation doit en revanche conduire à considérer sérieusement le caractère inédit du projet.
Quelles conséquences sur le chiffrage ?
Un chiffrage ne devrait donc pas se limiter à mesurer ce que le projet doit produire.
Il doit également déterminer dans quelles conditions cette production va être réalisée.
Quelques questions simples permettent d’évaluer la familiarité :
Avons-nous déjà réalisé des projets réellement comparables ?
Les objectifs du produit sont-ils bien compris par l’organisation ?
Les équipes disposent-elles d’une expérience de systèmes similaires ?
Le projet introduit-il de nouveaux processus opérationnels ?
Des architectures ou algorithmes innovants sont-ils nécessaires ?
La réponse doit idéalement être documentée par des faits : projets de référence, équipes concernées, technologies employées et retours d’expérience.
Cette analyse permet d’éviter une erreur fréquente : utiliser mécaniquement la productivité d’un projet connu pour chiffrer un projet beaucoup plus innovant.
Comment améliorer ce facteur ?
COCOMO II considère que la familiarité est largement intrinsèque au projet : on ne transforme pas instantanément un projet totalement nouveau en projet déjà connu.
Une DSI peut néanmoins en réduire les conséquences.
Capitaliser les projets précédents
Les historiques de projets constituent une source d’information précieuse : taille, effort, coûts, architecture, difficultés rencontrées, risques et écarts entre prévisions et résultats.
Mobiliser les bonnes expériences
Il ne suffit pas d’affecter des personnes expérimentées. Leur expérience doit être pertinente pour le projet concerné.
Identifier explicitement les zones de nouveauté
Un projet n’est presque jamais totalement connu ou totalement nouveau.
Il est plus utile d’identifier précisément ce qui constitue une rupture : métier, architecture, technologie, intégration ou procédures.
Réduire l’incertitude avant les engagements majeurs
Prototypes, études préalables, benchmarks et expérimentations permettent de transformer certaines inconnues en connaissances avant de figer budget et calendrier.
Les IA génératives changent-elles la situation ?
Les IA génératives peuvent réduire certains coûts liés à la découverte.
Elles facilitent notamment l’analyse documentaire, la recherche d’informations, la comparaison de solutions, la formalisation des exigences ou la production rapide de prototypes.
Elles peuvent donc accélérer l’apprentissage.
Mais elles ne transforment pas automatiquement un projet nouveau en projet familier.
Une IA peut proposer une architecture ; elle ne possède pas nécessairement la connaissance implicite du SI de l’entreprise, de son historique, de ses contraintes organisationnelles ou des raisons pour lesquelles certaines décisions ont été prises.
L’enjeu pourrait donc progressivement évoluer.
La question ne sera plus seulement :
« L’équipe a-t-elle déjà réalisé ce type de projet ? »
mais également :
« L’organisation est-elle capable de mettre à disposition de ses équipes et de ses IA l’expérience accumulée sur les projets précédents ? »
Les IA génératives peuvent ainsi renforcer la valeur de la capitalisation plutôt que la rendre inutile.
Les erreurs les plus fréquentes
La première consiste à confondre expérience individuelle et familiarité du projet.
Une équipe composée d’excellents professionnels peut travailler sur un projet totalement nouveau.
La deuxième consiste à considérer qu’utiliser une technologie connue rend automatiquement le projet familier.
La nouveauté peut être métier, organisationnelle, architecturale ou opérationnelle.
La troisième consiste à sous-estimer le facteur parce que le périmètre fonctionnel est bien défini.
Savoir précisément ce qu’il faut construire ne signifie pas nécessairement savoir comment le construire dans le contexte considéré.
Enfin, la quatrième consiste à appliquer les ratios de productivité d’anciens projets sans vérifier leur comparabilité.
À retenir
Familiarité du projet
- Deux projets de même taille peuvent nécessiter des efforts différents.
- La familiarité réduit l’incertitude et les besoins d’apprentissage.
- Son impact augmente avec la taille du projet.
- L’expérience pertinente doit être recherchée au niveau de l’organisation, pas seulement des individus.
- Les historiques de projets permettent de mieux qualifier ce facteur lors du chiffrage.
Quelles décisions un DSI peut-il prendre ?
La première décision consiste à intégrer explicitement la familiarité dans les hypothèses de chiffrage des projets importants.
La deuxième est de distinguer, dès les phases initiales, ce qui est connu de ce qui constitue réellement une nouveauté.
La troisième consiste à renforcer les études, prototypes ou travaux de réduction d’incertitude lorsque le projet s’éloigne fortement de l’expérience disponible.
Enfin, la DSI peut considérer les données issues des projets terminés comme un véritable actif : elles permettent de comparer les projets, d’améliorer les estimations et de réutiliser l’expérience acquise.
La question n’est donc pas uniquement de savoir combien de fonctionnalités doivent être développées.
Il faut également savoir combien de chemin l’organisation a déjà parcouru auparavant.
« Un projet coûte aussi le prix de ce que l’organisation doit encore apprendre. »
Le conseil Estimancy
Lors d’un chiffrage, ne demandez pas simplement si le projet est « nouveau ».
Demandez à l’équipe de citer deux ou trois projets réellement comparables et d’expliquer précisément ce qui peut en être réutilisé : connaissance métier, architecture, interfaces, composants, méthodes, données de productivité et retour d’expérience.
S’il est difficile d’identifier ces références, la familiarité du projet est probablement plus faible que ne le pense l’équipe.
Cette information doit être intégrée au chiffrage avant de prendre des engagements de coût et de délai.
Les six niveaux et les valeurs 6,20 / 4,96 / 3,72 / 2,48 / 1,24 / 0,00 sont directement ceux du manuel COCOMO II. Le manuel précise aussi que PREC est évalué notamment à partir de la compréhension des objectifs, de l’expérience de systèmes comparables, de la nouveauté des matériels/procédures associés et du besoin d’architectures ou algorithmes innovants.
