Une hypothèse technique qui peut coûter cher
Lorsqu’une DSI lance un projet logiciel, elle estime généralement son coût à partir des fonctionnalités à développer, de la complexité de la solution, des compétences nécessaires et du calendrier.
Mais une autre hypothèse peut peser significativement sur l’effort : la stabilité de l’environnement technique pendant la durée du projet.
Un projet peut démarrer sur une version donnée d’un système d’exploitation, d’un SGBD, d’un middleware, d’une infrastructure cloud ou d’un ensemble de composants techniques. Si cet environnement évolue rapidement, les équipes peuvent devoir adapter ce qu’elles viennent de développer, mettre à jour des composants, reprendre des tests ou revoir certaines décisions techniques.
COCOMO II prend explicitement en compte cette situation à travers le facteur Platform Volatility – PVOL, que nous traduirons ici par volatilité de la plateforme.
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 volatilité de la plateforme ?
Dans COCOMO II, la plateforme désigne l’ensemble du matériel et des logiciels d’infrastructure auxquels le produit fait appel pour fonctionner. Le modèle cite notamment le matériel, le système d’exploitation et le SGBD.
La notion est donc relative au logiciel étudié.
Si l’on développe un système d’exploitation, la plateforme est principalement constituée du matériel. Pour un SGBD, elle comprend le matériel et le système d’exploitation. Pour une application utilisant des services réseau et des bases de données, le périmètre est naturellement plus large.
PVOL ne mesure donc ni la volatilité des besoins fonctionnels, ni le nombre de modifications demandées par les utilisateurs.
Il mesure la fréquence des changements affectant l’environnement technique dont dépend le logiciel.
Les différents niveaux
COCOMO II distingue les situations suivantes :
| Niveau | Changements majeurs | Changements mineurs |
| Faible | tous les 12 mois | tous les mois |
| Nominal | tous les 6 mois | toutes les 2 semaines |
| Élevé | tous les 2 mois | toutes les semaines |
| Très élevé | toutes les 2 semaines | tous les 2 jours |
Il n’existe pas, dans cette table, de niveau Très faible ni Extra élevé applicable à PVOL.
Cette grille est ancienne dans ses exemples calendaires, mais le principe reste particulièrement pertinent : plus l’environnement technique évolue pendant le développement, plus le projet doit absorber d’adaptations.
Les coefficients COCOMO II
Les coefficients d’effort associés sont les suivants :
| Niveau | Coefficient |
| Faible | 0,87 |
| Nominal | 1,00 |
| Élevé | 1,15 |
| Très élevé | 1,30 |
Il s’agit d’un multiplicateur d’effort : toutes choses égales par ailleurs, une volatilité plus importante conduit à augmenter l’effort estimé.
Exemple sur un projet de 1 000 jours-homme
Prenons un projet dont l’effort de référence serait de 1 000 jours-homme avec PVOL au niveau nominal, les autres paramètres restant inchangés.
| Niveau | Coefficient | Effort correspondant | Écart / nominal |
| Faible | 0,87 | 870 j.h | –130 j.h |
| Nominal | 1,00 | 1 000 j.h | — |
| Élevé | 1,15 | 1 150 j.h | +150 j.h |
| Très élevé | 1,30 | 1 300 j.h | +300 j.h |
Entre les situations Faible et Très élevé, l’écart atteint donc 430 jours-homme, soit environ 49 % d’effort supplémentaire par rapport au niveau Faible.
Ce calcul n’affirme évidemment pas que tout changement de plateforme entraîne automatiquement 300 jours-homme supplémentaires. Il illustre l’effet du coefficient COCOMO II lorsque les autres caractéristiques du projet sont maintenues constantes.
Cas concret : une application bancaire
Imaginons une banque développant un nouveau portail destiné à ses clients.
Le projet doit s’intégrer à une plateforme comprenant notamment une infrastructure cloud, un SGBD, des composants de sécurité, des API internes et plusieurs middlewares.
Au lancement, l’architecture est définie et le projet est estimé sur cette base.
Pendant les 18 mois de réalisation, plusieurs évolutions interviennent : nouvelles versions de composants, modification des politiques de sécurité, évolution des API techniques et migration de certains services d’infrastructure.
Chaque changement pris isolément paraît limité.
Mais leur accumulation impose des analyses d’impact, des adaptations, des tests de non-régression, des modifications de configuration et parfois la reprise de développements déjà réalisés.
Le problème n’est donc pas seulement la complexité de la plateforme. C’est son évolution pendant que le projet se construit.
Pourquoi un tel impact ?
Une forte volatilité agit de plusieurs manières.
D’abord, elle génère du retravail. Un composant conçu et testé dans un environnement donné peut devoir être adapté après une évolution.
Ensuite, elle augmente les besoins de tests et de qualification. Une modification d’infrastructure peut avoir des conséquences sur les performances, la sécurité, les interfaces ou la compatibilité.
Elle peut également provoquer une obsolescence accélérée des décisions techniques : ce qui était pertinent au démarrage du projet ne l’est plus nécessairement quelques mois plus tard.
Enfin, elle accroît l’incertitude. Plus la plateforme change rapidement, plus il devient difficile de considérer l’environnement technique comme une donnée stable du chiffrage.
Les symptômes à surveiller
Plusieurs signes doivent attirer l’attention :
- migrations techniques programmées pendant la réalisation du projet ;
- versions de composants non stabilisées ;
- changements fréquents de versions majeures ;
- infrastructure cible encore en construction ;
- dépendance importante à des services externes évoluant rapidement ;
- modifications récurrentes des environnements de développement et de test ;
- nombreuses reprises liées à des problèmes de compatibilité ;
- roadmap technique de la DSI évoluant plus rapidement que le projet lui-même.
Un projet de deux ans dépendant d’une plateforme profondément modifiée tous les trois mois ne doit pas être estimé comme un projet réalisé sur une infrastructure mature et stable.
Conséquences sur le chiffrage
PVOL conduit surtout à poser de meilleures questions avant de produire l’estimation.
Il faut notamment identifier quelles plateformes sont utilisées, quelles versions sont prévues, quelle est leur maturité, quelles migrations sont déjà programmées et à quelle fréquence interviennent les changements majeurs et mineurs.
Une question particulièrement utile est :
« Quelles évolutions de la plateforme sont susceptibles d’intervenir avant la mise en production du projet ? »
Il faut également distinguer les évolutions probables des simples possibilités technologiques.
L’erreur serait d’attribuer automatiquement un niveau élevé à toute technologie récente. Ce qui importe ici est avant tout la fréquence réelle ou prévisible des changements affectant le projet.
Lorsque cette information est incertaine, l’estimation peut être présentée sous plusieurs scénarios. Par exemple : 1 000 jours-homme avec une volatilité nominale, contre 1 150 si elle devient élevée.
L’incertitude devient alors visible pour le décideur.
Comment améliorer ce facteur ?
Une DSI ne peut pas empêcher les technologies d’évoluer. Elle peut cependant réduire l’exposition de ses projets à cette évolution.
Les principaux leviers sont :
Stabiliser les versions de référence. Définir clairement les versions supportées pendant certaines phases du projet évite les migrations permanentes.
Synchroniser roadmaps projet et technique. Une migration d’infrastructure connue doit être intégrée au planning et au chiffrage.
Découpler autant que possible l’application de la plateforme. Des interfaces et couches d’abstraction appropriées peuvent limiter la propagation de certains changements.
Automatiser les tests. Plus les changements sont fréquents, plus la capacité à vérifier rapidement la non-régression devient importante.
Réévaluer les hypothèses. Pour les projets longs, le niveau PVOL retenu au démarrage mérite d’être vérifié lors des réestimations.
Quel impact des IA génératives ?
Les IA génératives peuvent réduire une partie du coût d’adaptation : assistance à la migration, analyse de code, génération ou transformation de configurations, adaptation de composants, production de tests ou analyse de documentation technique.
Elles peuvent donc rendre certains changements moins coûteux à absorber.
Mais elles ne suppriment pas le phénomène mesuré par PVOL.
Une modification de SGBD, d’API, de politique de sécurité ou d’infrastructure doit toujours être analysée, intégrée, testée et validée. L’IA peut accélérer certaines tâches, mais elle ne garantit ni la compatibilité ni la conformité du système obtenu.
Par ailleurs, l’IA peut elle-même introduire de nouvelles dépendances technologiques : modèles, API, frameworks et services évoluent actuellement très rapidement.
Elle modifie donc davantage la manière de gérer la volatilité qu’elle ne fait disparaître son importance.
Les erreurs fréquentes
La première erreur consiste à confondre volatilité de la plateforme et volatilité des exigences. Ce sont deux phénomènes différents.
La deuxième consiste à considérer la plateforme comme définitivement fixée au lancement du projet.
La troisième est de retenir le niveau nominal par défaut faute d’information. L’absence d’information sur la roadmap technique devrait plutôt être considérée comme une incertitude à lever.
Enfin, une autre erreur consiste à supposer que l’utilisation du cloud supprime le problème. Elle peut faciliter certaines évolutions, mais les services cloud, API, runtimes et composants managés possèdent eux aussi leurs cycles d’évolution et d’obsolescence.
À retenir
Volatilité de la plateforme : 5 points essentiels
- PVOL mesure la fréquence des changements de l’environnement technique, pas celle des exigences.
- COCOMO II lui associe des coefficients allant de 0,87 à 1,30.
- Sur une référence de 1 000 jours-homme au niveau nominal, le niveau Très élevé correspond à 1 300 jours-homme, toutes choses égales par ailleurs.
- Roadmaps techniques et roadmaps projets doivent être confrontées dès le chiffrage.
- L’IA peut faciliter certaines adaptations, mais elle ne supprime ni les changements de plateforme ni leurs risques.
Quelles décisions pour un DSI ?
La volatilité de la plateforme n’est pas uniquement un problème d’architecte ou de développeur. Elle peut devenir un facteur budgétaire et un risque de planning.
Un DSI peut donc agir à trois niveaux : mieux identifier les dépendances technologiques lors du chiffrage, coordonner les calendriers de transformation technique avec ceux des projets et demander plusieurs scénarios d’estimation lorsque la stabilité de la plateforme est incertaine.
L’objectif n’est pas de rechercher une plateforme immobile. Une DSI doit nécessairement faire évoluer son patrimoine technologique.
L’enjeu consiste plutôt à éviter qu’une évolution prévisible soit découverte, quelques mois plus tard, sous la forme d’un dépassement budgétaire.
« Une plateforme qui évolue n’est pas un problème. Une évolution non anticipée dans le chiffrage peut le devenir. »
Le conseil Estimancy
Ne demandez pas seulement sur quelle plateforme le projet sera développé. Demandez comment cette plateforme évoluera pendant toute la durée du projet.
Pour les projets longs ou fortement dépendants d’infrastructures en transformation, confrontez systématiquement le calendrier du projet à la roadmap technique de la DSI. Si plusieurs évolutions importantes sont prévues, faites-en une hypothèse explicite du chiffrage plutôt qu’une marge de risque implicite.
