Deux projets peuvent avoir exactement le même périmètre fonctionnel et pourtant ne pas présenter les mêmes conditions de réalisation.
Dans le premier, l’équipe peut choisir son architecture, adapter certaines interfaces, négocier des exigences techniques et rechercher la solution présentant le meilleur compromis entre coût, délai et qualité.
Dans le second, une grande partie de ces choix est déjà imposée : architecture existante, interfaces obligatoires, exigences strictes, technologies contraintes et parfois date de mise en production impérative.
Pour une DSI, cette différence est importante. La marge de manœuvre laissée à un projet peut avoir une influence sur son effort et, surtout, sur la manière dont cet effort évolue avec la taille du projet.
COCOMO II désigne ce facteur sous le terme de flexibilité du développement.
Qu’est-ce que la flexibilité du développement ?
La flexibilité du développement mesure la marge de manœuvre dont dispose l’équipe pour déterminer comment atteindre les objectifs du projet.
Un projet est peu flexible lorsque l’équipe doit se conformer strictement à des exigences préétablies et à des interfaces externes imposées, éventuellement avec une forte contrainte sur la date de livraison.
À l’inverse, un projet très flexible définit davantage des objectifs généraux et laisse à l’équipe une latitude importante sur les moyens permettant de les atteindre.
Ce facteur est issu du modèle international COCOMO II, utilisé depuis de nombreuses années pour l’estimation des projets logiciels.
Il faut cependant bien comprendre sa nature : FLEX n’est pas un multiplicateur d’effort classique. Il fait partie des cinq facteurs d’échelle de COCOMO II. Il intervient donc dans l’exposant de la formule d’estimation et influence la manière dont l’effort augmente avec la taille du logiciel.
Les six niveaux de flexibilité
COCOMO II distingue six niveaux :
| Niveau | Interprétation |
| Très faible | Conformité rigoureuse aux contraintes imposées |
| Faible | Relâchement occasionnel possible |
| Nominal | Quelques adaptations sont possibles |
| Élevé | Conformité générale attendue, avec marge d’adaptation |
| Très élevé | Certaines contraintes seulement sont réellement imposées |
| Extra élevé | Les objectifs généraux sont définis, mais l’équipe dispose d’une grande liberté sur la solution |
Cette appréciation porte notamment sur trois dimensions : le respect d’exigences préétablies, le respect des spécifications d’interfaces externes et la combinaison de ces rigidités avec une forte exigence de livraison rapide.
Les coefficients COCOMO II
La calibration COCOMO II.2000 attribue les valeurs suivantes :
| Niveau | Valeur FLEX |
| Très faible | 5,07 |
| Faible | 4,05 |
| Nominal | 3,04 |
| Élevé | 2,03 |
| Très élevé | 1,01 |
| Extra élevé | 0,00 |
Ces valeurs ne doivent surtout pas être interprétées comme des multiplicateurs.
Une valeur de 5,07 ne signifie donc pas que le projet coûte 5,07 fois plus cher.
FLEX intervient dans l’exposant de la formule COCOMO II. Son influence dépend par conséquent de la taille du logiciel.
Exemple chiffré
Prenons un projet dont l’effort de référence au niveau nominal est de 1 000 jours-homme.
Pour calculer précisément l’effet de FLEX, il faut également connaître la taille du logiciel utilisée dans le modèle COCOMO II. À titre d’illustration, supposons une taille de 100 KSLOC, toutes les autres hypothèses restant inchangées.
On obtient approximativement :
| FLEX | Effort | Écart / nominal |
| Très faible | 1 098 j.h | +9,8 % |
| Faible | 1 048 j.h | +4,8 % |
| Nominal | 1 000 j.h | — |
| Élevé | 955 j.h | –4,5 % |
| Très élevé | 911 j.h | –8,9 % |
| Extra élevé | 869 j.h | –13,1 % |
L’écart entre les deux situations extrêmes représente ici environ 229 jours-homme, soit plus de 26 % de l’effort de la situation la plus flexible.
Mais ce chiffre ne doit pas être généralisé : sur un logiciel plus petit, l’écart serait moindre ; sur un logiciel plus important, il deviendrait plus marqué.
C’est précisément la caractéristique d’un facteur d’échelle.
Cas concret : refonte d’un portail client
Imaginons la refonte du portail client d’une grande entreprise.
Dans une première configuration, l’équipe doit obligatoirement :
- conserver certaines interfaces avec le système historique ;
- respecter une architecture technique définie par le groupe ;
- utiliser plusieurs composants imposés ;
- conserver des mécanismes d’authentification existants ;
- respecter une date de migration liée à l’arrêt d’une ancienne plateforme.
Le projet possède une faible flexibilité.
Dans une seconde configuration, les mêmes fonctions doivent être fournies aux utilisateurs, mais l’équipe peut revoir les interfaces, choisir certains composants et proposer une trajectoire de migration différente.
Le périmètre fonctionnel peut être identique. La quantité de logiciel à produire peut être comparable. Mais les conditions de réalisation ne le sont pas.
C’est cette différence que FLEX cherche à prendre en compte.
Pourquoi la flexibilité peut-elle avoir un tel impact ?
Lorsqu’une difficulté apparaît dans un projet flexible, plusieurs solutions peuvent être envisagées.
Une interface est trop complexe ? Elle peut éventuellement être simplifiée.
Une technologie présente une limitation ? Une alternative peut être étudiée.
Une exigence technique entraîne un coût disproportionné ? Elle peut être renégociée.
Dans un projet très contraint, ces arbitrages sont beaucoup plus difficiles.
L’équipe doit alors résoudre le problème à l’intérieur d’un espace de solutions plus réduit.
À mesure que le projet grandit, ces contraintes peuvent également se combiner : davantage d’interfaces, davantage de dépendances, davantage d’acteurs et davantage de décisions nécessitant coordination et validation.
La faible flexibilité contribue ainsi aux déséconomies d’échelle.
Quels symptômes observer ?
Plusieurs signes doivent attirer l’attention lors du lancement ou du chiffrage d’un projet :
- architecture presque entièrement imposée avant l’étude ;
- nombreuses interfaces considérées comme non négociables ;
- exigences techniques très détaillées dans le cahier des charges ;
- obligation de conserver des solutions historiques ;
- technologies imposées indépendamment du besoin ;
- faible capacité des équipes à proposer des alternatives ;
- date de livraison impérative combinée à de fortes contraintes techniques ;
- multiplication des dérogations nécessaires pour modifier une décision initiale.
Pris isolément, chacun de ces éléments n’est pas nécessairement problématique. Certaines contraintes sont parfaitement justifiées.
C’est leur accumulation qui doit être évaluée.
Conséquences sur le chiffrage
Lors d’un chiffrage, demander uniquement « quelles sont les fonctionnalités à développer ? » ne suffit donc pas.
Il faut également comprendre dans quelles conditions elles devront être développées.
Quelques questions sont particulièrement utiles :
- Les exigences décrivent-elles principalement le besoin ou imposent-elles également la solution ?
- Les interfaces avec les autres systèmes peuvent-elles évoluer ?
- L’architecture peut-elle être adaptée ?
- Les technologies sont-elles imposées ?
- L’équipe peut-elle proposer des solutions alternatives ?
- Existe-t-il des contraintes réglementaires ou de sécurité non négociables ?
- Une date impérative limite-t-elle encore davantage les choix ?
Une erreur fréquente consiste à utiliser implicitement des conditions « normales » dans le modèle de chiffrage alors que le projet est en réalité beaucoup plus contraint.
L’estimation risque alors d’être trop optimiste.
Comment améliorer ce facteur ?
COCOMO II indique que FLEX et la familiarité du projet sont largement intrinsèques au projet. Cela signifie qu’il n’est pas toujours possible de transformer un projet fortement contraint en projet totalement flexible.
L’objectif n’est donc pas de supprimer artificiellement les contraintes.
Il est plutôt de faire la distinction entre contraintes nécessaires et contraintes héritées.
Trois leviers peuvent être utilisés.
1. Rechallenger les contraintes historiques
Une interface ou une règle d’architecture peut être présentée comme intangible simplement parce qu’elle existe depuis longtemps.
La préparation du projet est l’occasion de vérifier si cette contrainte reste justifiée.
2. Spécifier le besoin avant la solution
Une exigence fonctionnelle devrait autant que possible exprimer le résultat attendu.
Imposer prématurément la solution réduit mécaniquement les possibilités d’optimisation.
3. Donner un véritable pouvoir d’arbitrage
La flexibilité n’existe réellement que si l’équipe peut proposer et faire valider des alternatives.
Une gouvernance permettant des arbitrages rapides peut donc préserver une partie de cette marge de manœuvre.
Quel impact des IA génératives ?
Les IA génératives ne font pas disparaître ce facteur.
Elles peuvent néanmoins modifier la manière de gérer certaines contraintes.
Une IA peut aider à explorer rapidement plusieurs solutions, analyser les conséquences d’une contrainte, rechercher des incohérences dans les exigences ou proposer des variantes d’architecture.
Elle peut donc réduire le coût d’exploration des alternatives.
Mais elle ne supprime pas une interface réglementaire, une architecture obligatoire ou une date impérative.
Paradoxalement, l’IA peut même rendre la flexibilité plus précieuse : si plusieurs solutions peuvent désormais être étudiées rapidement, une organisation capable de les arbitrer bénéficie davantage de cette capacité qu’une organisation dans laquelle tous les choix sont figés.
L’IA améliore donc potentiellement l’exploitation de la flexibilité disponible ; elle ne crée pas à elle seule cette flexibilité.
Les erreurs fréquentes
Confondre contrainte et exigence.
Une exigence décrit ce que le système doit accomplir. Une contrainte limite les solutions permettant d’y parvenir.
Considérer toutes les contraintes historiques comme intangibles.
Certaines peuvent être supprimées ou renégociées.
Évaluer FLEX comme un multiplicateur classique.
C’est une erreur méthodologique : FLEX est un facteur d’échelle.
Croire que l’agilité rend automatiquement le projet flexible.
Un projet Scrum peut rester extrêmement contraint techniquement.
Penser que l’IA annule les contraintes.
Elle facilite l’analyse et l’exploration des solutions mais ne supprime pas les obligations externes.
À retenir
Flexibilité du développement : 5 idées essentielles
- Deux projets de même taille fonctionnelle peuvent avoir des conditions de réalisation très différentes.
- Plus les exigences et interfaces sont imposées, plus la marge d’optimisation se réduit.
- FLEX est un facteur d’échelle : son impact devient plus significatif lorsque la taille du logiciel augmente.
- Toutes les contraintes ne doivent pas être supprimées : elles doivent être identifiées, justifiées et intégrées au chiffrage.
- Les IA génératives facilitent l’exploration des solutions mais ne suppriment pas les contraintes structurelles du projet.
Quelles décisions un DSI peut-il prendre ?
La première décision consiste à rendre les contraintes visibles avant d’engager le projet.
La deuxième consiste à demander, pour chacune d’elles : est-elle réellement non négociable ?
La troisième consiste à intégrer explicitement le niveau de flexibilité dans le chiffrage, particulièrement pour les projets importants.
Enfin, une DSI peut créer des mécanismes de gouvernance permettant aux équipes de proposer rapidement des alternatives lorsque le coût d’une contrainte devient disproportionné.
La flexibilité n’est donc pas l’absence de règles. C’est la capacité à conserver suffisamment de choix pour rechercher la solution la plus pertinente.
« Une contrainte nécessaire doit être respectée. Une contrainte inutile doit être challengée. »
Le conseil Estimancy
Lors d’un chiffrage, ne mesurez pas uniquement ce qu’il faut construire.
Évaluez également la liberté dont disposera l’équipe pour le construire.
Sur les projets importants, une contrainte apparemment anodine peut prendre davantage de poids avec la taille du logiciel. L’analyse des facteurs d’échelle permet précisément d’éviter qu’un projet très contraint soit estimé comme s’il se déroulait dans des conditions nominales.
Les définitions et niveaux ci-dessus reprennent l’échelle officielle FLEX : de « rigorous » jusqu’à « general goals ». Le manuel précise également que FLEX et PREC sont largement intrinsèques au projet, contrairement aux trois autres facteurs d’échelle qui représentent davantage des leviers de management.
