La réutilisation n’est pas gratuite
Pour une DSI, l’idée paraît naturellement séduisante : plutôt que de développer plusieurs fois des fonctionnalités similaires, pourquoi ne pas construire une fois un composant et le réutiliser dans plusieurs applications ?
API communes, composants techniques, services métier, bibliothèques, plateformes partagées : la mutualisation peut effectivement produire des économies significatives à l’échelle d’un système d’information.
Mais cette logique comporte un piège dans le chiffrage.
Un composant conçu pour être largement réutilisable coûte généralement plus cher à développer qu’un composant répondant uniquement aux besoins immédiats d’un projet.
Cette différence doit être anticipée dès l’estimation.
Qu’est-ce que la réutilisabilité requise ?
La réutilisabilité requise mesure l’étendue dans laquelle le logiciel développé doit pouvoir être réutilisé au-delà de son utilisation immédiate.
COCOMO II désigne ce facteur par RUSE (Developed for Reusability).
Le modèle considère explicitement que rendre un composant réutilisable entraîne un effort supplémentaire. Trois raisons principales sont citées : une conception plus générique, une documentation plus élaborée et des tests plus étendus afin que le composant puisse être utilisé dans d’autres applications.
Ce facteur est issu du modèle international COCOMO II, utilisé depuis de nombreuses années pour l’estimation des projets logiciels.
Il est important de distinguer deux notions :
- réutiliser un composant existant, ce qui peut réduire l’effort d’un nouveau projet ;
- concevoir un nouveau composant pour qu’il soit réutilisable, ce qui augmente l’effort du projet qui le développe.
Le facteur étudié ici concerne la seconde situation.
Les différents niveaux de réutilisabilité
COCOMO II distingue cinq niveaux applicables, correspondant à une extension progressive du périmètre de réutilisation.
| Niveau | Réutilisation demandée | Interprétation |
| Faible | Dans le projet | Réutilisation entre composants ou modules d’un même projet |
| Nominal | Dans un programme | Réutilisation entre plusieurs projets appartenant à un même programme |
| Élevé | Dans une ligne de produits | Composant commun à plusieurs produits ou applications |
| Très élevé | — | Niveau intermédiaire de contrainte renforcée |
| Extra élevé | Plusieurs lignes de produits | Composant destiné à des familles de produits différentes |
Le manuel donne notamment l’exemple d’une réutilisation « across project » entre modules d’un même projet financier, puis « across program » entre plusieurs applications financières d’une organisation. À l’autre extrême, la réutilisation peut couvrir plusieurs lignes de produits, par exemple finance, ventes et marketing.
Les coefficients COCOMO II
Les multiplicateurs d’effort associés sont :
| Niveau | Coefficient |
| Très faible | Non applicable |
| Faible | 0,95 |
| Nominal | 1,00 |
| Élevé | 1,07 |
| Très élevé | 1,15 |
| Extra élevé | 1,24 |
Ces coefficients ne représentent pas les économies futures produites par la réutilisation. Ils représentent l’impact sur l’effort du projet chargé de produire le logiciel réutilisable.
Exemple sur un projet de 1 000 jours-homme
Prenons un projet dont l’effort de référence au niveau nominal est de 1 000 jours-homme, tous les autres facteurs étant supposés constants.
| Niveau | Coefficient | Effort correspondant | Écart / nominal |
| Faible | 0,95 | 950 j.h | -50 j.h |
| Nominal | 1,00 | 1 000 j.h | Référence |
| Élevé | 1,07 | 1 070 j.h | +70 j.h |
| Très élevé | 1,15 | 1 150 j.h | +150 j.h |
| Extra élevé | 1,24 | 1 240 j.h | +240 j.h |
Entre un composant conçu essentiellement pour être réutilisé dans son projet et un composant destiné à plusieurs lignes de produits, l’écart atteint donc 290 jours-homme dans cet exemple.
Ce chiffre illustre pourquoi l’exigence de réutilisabilité doit apparaître explicitement dans les hypothèses d’estimation.
Cas concret : une API client commune
Imaginons une grande entreprise qui développe un nouveau portail client.
Le projet a besoin d’une API permettant d’accéder aux informations du client.
Une première approche consiste à développer cette API pour répondre précisément aux besoins du portail. Les données, interfaces, règles de sécurité et performances sont adaptées à ce contexte.
Mais la DSI décide que cette API devra également être utilisée demain par :
- l’application mobile ;
- le CRM ;
- les outils des centres de relation client ;
- différents portails ;
- de futurs services numériques.
Le problème change de nature.
Il faut désormais prévoir des interfaces suffisamment génériques, stabiliser les contrats d’API, renforcer les mécanismes de compatibilité, documenter les conditions d’utilisation et tester davantage de scénarios.
Le composant devient un actif partagé du système d’information.
Cette stratégie peut être excellente économiquement, mais son coût ne doit pas être imputé au projet initial comme s’il développait uniquement ses propres besoins.
Pourquoi un tel impact ?
Plus le périmètre de réutilisation s’élargit, plus le développeur doit anticiper des situations qui ne sont pas directement nécessaires au projet courant.
COCOMO II identifie notamment trois sources d’effort supplémentaires : généricité de la conception, documentation et tests.
À cela peuvent s’ajouter, dans les organisations actuelles, la gouvernance des interfaces, la gestion des versions, la compatibilité ascendante ou encore les processus de publication et de support.
Un composant local peut évoluer avec son application. Un composant partagé doit davantage protéger ses consommateurs contre les évolutions futures.
Il faut donc investir aujourd’hui pour réduire les coûts de plusieurs développements demain.
Les symptômes observables
Plusieurs signes indiquent qu’une exigence forte de réutilisabilité existe sans avoir été correctement intégrée au projet :
| Symptôme | Conséquence possible |
| Multiplication des consommateurs potentiels | Augmentation des exigences génériques |
| Nombreuses discussions sur les interfaces | Effort d’architecture sous-estimé |
| Documentation plus importante que prévu | Charge non intégrée au chiffrage |
| Multiplication des scénarios de tests | Augmentation de l’effort de validation |
| Besoins futurs mal définis | Risque de sur-conception |
| Projet initial supportant seul le coût | Dérapage apparent de son budget |
Conséquences sur le chiffrage
Lors du chiffrage, demander simplement « ce composant sera-t-il réutilisable ? » est insuffisant.
Il faut déterminer jusqu’où cette réutilisation est réellement exigée.
Quelques questions sont particulièrement utiles :
- Le composant est-il destiné uniquement à cette application ?
- Doit-il être utilisé par plusieurs modules du projet ?
- Plusieurs projets sont-ils déjà identifiés comme consommateurs ?
- S’agit-il d’un composant commun à une gamme d’applications ?
- Doit-il devenir un standard de l’entreprise ?
- Quels consommateurs futurs sont réellement identifiés ?
- Quelles exigences supplémentaires de documentation et de tests en découlent ?
Cette analyse améliore la précision du chiffrage en évitant deux erreurs opposées : oublier l’effort nécessaire à la réutilisation, ou surévaluer un besoin de réutilisation encore hypothétique.
COCOMO II établit d’ailleurs un lien entre RUSE et les exigences de fiabilité et de documentation : une forte réutilisabilité impose certaines contraintes minimales sur RELY et DOCU.
Comment améliorer ce facteur ?
L’objectif n’est pas nécessairement de réduire la réutilisabilité. Il s’agit plutôt de maîtriser l’investissement qu’elle représente.
Trois leviers sont particulièrement importants.
Définir les usages futurs avant de généraliser.
Il est préférable d’identifier des consommateurs plausibles plutôt que de concevoir systématiquement pour tous les usages imaginables.
Distinguer le coût du projet du coût de mutualisation.
Si un portail finance une API qui sera ensuite utilisée par dix applications, une partie de l’investissement relève d’une logique transverse.
Mesurer les bénéfices dans le temps.
Le surcoût initial devient intéressant lorsque les réutilisations ultérieures évitent effectivement de nouveaux développements.
La réutilisation doit donc être pilotée comme un investissement avec un coût initial et un retour attendu.
Quel impact des IA génératives ?
Les IA génératives peuvent réduire certains coûts associés à la réutilisabilité.
Elles peuvent notamment faciliter la génération de documentation, la production de tests, l’analyse d’interfaces ou l’identification de cas d’utilisation supplémentaires.
Mais elles ne suppriment pas le problème fondamental.
Décider qu’un composant doit fonctionner dans plusieurs contextes reste une décision d’architecture. Définir les bonnes abstractions, garantir la stabilité des interfaces ou déterminer les responsabilités du composant demande toujours une compréhension du SI et des usages futurs.
L’IA peut donc réduire certains coûts de mise en œuvre, mais elle ne rend pas gratuite la conception pour la réutilisation.
Elle peut même faciliter tellement la création de composants génériques que le risque de sur-conception mérite une attention accrue.
Les erreurs fréquentes
« Réutilisable signifie moins cher. »
À terme, potentiellement. Pour le projet qui construit le composant réutilisable, pas nécessairement.
« Autant rendre tous nos composants réutilisables. »
Une réutilisation hypothétique ne justifie pas toujours l’investissement.
« Nous verrons plus tard qui pourra l’utiliser. »
Sans consommateurs identifiés, il devient difficile de déterminer le bon niveau de généricité.
« Le projet initial doit absorber le surcoût. »
Lorsque le composant devient un actif transverse, son financement peut relever d’une décision plus globale de la DSI.
« L’IA supprimera ce surcoût. »
Elle peut automatiser certaines tâches, mais pas supprimer les exigences de conception, de gouvernance et de qualité liées à un composant partagé.
À retenir
Réutilisabilité requise — les 5 points essentiels
- Concevoir pour la réutilisation demande un investissement initial.
- COCOMO II évalue cet impact entre 0,95 et 1,24 selon le niveau considéré.
- Sur une base nominale de 1 000 jours-homme, le niveau maximal conduit à 1 240 jours-homme.
- Cet effort supplémentaire peut être rentable si les réutilisations futures sont suffisamment nombreuses.
- Le véritable enjeu pour une DSI est donc de déterminer où investir dans la réutilisation et jusqu’à quel niveau.
Conclusion — Quelles décisions un DSI peut-il prendre ?
La réutilisation ne doit être considérée ni comme une contrainte technique, ni comme une source automatique d’économies.
C’est une décision d’investissement.
Un DSI peut donc demander que les composants destinés à devenir des actifs partagés soient identifiés dès le chiffrage, que leur périmètre de réutilisation soit explicite et que l’effort supplémentaire correspondant soit distingué du besoin propre au projet initial.
Il peut également demander que cet investissement soit confronté aux économies attendues sur les projets futurs.
La question n’est finalement pas : « Pouvons-nous rendre ce composant réutilisable ? »
Elle est : « Avons-nous suffisamment de réutilisations probables pour justifier l’investissement ? »
« La réutilisation permet d’économiser demain, mais elle commence par coûter aujourd’hui. »
Le conseil Estimancy
Lors d’un chiffrage, ne cochez pas simplement une case « réutilisable ». Identifiez le périmètre réel de réutilisation : projet, programme, ligne de produits ou plusieurs lignes de produits. C’est ce périmètre qui permet d’évaluer correctement l’effort supplémentaire et d’éviter de faire financer implicitement un actif transverse par un seul projet.
