Pour estimer un projet logiciel, une première étape consiste à déterminer ce qu’il faut construire : fonctionnalités, processus, données manipulées, interfaces…
Mais cette taille ne raconte pas toute l’histoire.
Deux applications offrant une quantité comparable de fonctionnalités peuvent présenter des difficultés techniques radicalement différentes. Un portail permettant de consulter et modifier des données métier n’est pas comparable à un système industriel distribué devant réagir en temps réel, même si leur taille fonctionnelle est similaire.
Cette différence porte un nom dans COCOMO II : la complexité du produit.
Et son impact sur l’effort peut être considérable.
Qu’est-ce que la complexité du produit ?
La complexité du produit mesure la difficulté technique intrinsèque du logiciel à construire.
COCOMO II distingue cinq grandes dimensions :
- les opérations de contrôle ;
- les traitements et calculs ;
- les opérations dépendantes des équipements ;
- la gestion des données ;
- la gestion des interfaces utilisateur.
Il ne s’agit donc pas de mesurer le nombre de fonctionnalités.
Il s’agit de déterminer à quel point leur réalisation est techniquement difficile.
Un calcul simple et un algorithme numérique complexe peuvent chacun correspondre à une fonctionnalité demandée par l’utilisateur, mais ne nécessiteront évidemment pas le même effort de conception, de développement et de test.
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 définit six niveaux :
| Niveau | Caractéristiques générales | Coefficient |
| Très faible | Traitements, données et interfaces très simples | 0,73 |
| Faible | Complexité limitée, traitements relativement standards | 0,87 |
| Nominale | Complexité courante d’une application | 1,00 |
| Élevée | Traitements, données ou interactions techniques complexes | 1,17 |
| Très élevée | Temps réel, distribution, traitements ou données particulièrement complexes | 1,34 |
| Extrêmement élevée | Contraintes techniques exceptionnelles, systèmes fortement couplés ou traitements particulièrement difficiles | 1,74 |
Ces coefficients proviennent directement de COCOMO II.2000.
Le manuel fournit des critères techniques beaucoup plus précis. Par exemple, le niveau élevé peut inclure des traitements distribués homogènes, du temps réel souple, des restructurations complexes de données ou des interfaces multimédias.
Aux niveaux supérieurs apparaissent notamment la synchronisation de tâches, le temps réel dur, les bases de données distribuées, la parallélisation complexe ou des structures de données dynamiques fortement couplées.
Un écart pouvant devenir considérable
Prenons un projet dont l’effort de référence est de 1 000 jours-homme au niveau nominal.
En appliquant uniquement le facteur de complexité :
| Complexité | Coefficient | Effort | Écart / nominal |
| Très faible | 0,73 | 730 j.h | -270 j.h |
| Faible | 0,87 | 870 j.h | -130 j.h |
| Nominale | 1,00 | 1 000 j.h | Référence |
| Élevée | 1,17 | 1 170 j.h | +170 j.h |
| Très élevée | 1,34 | 1 340 j.h | +340 j.h |
| Extrêmement élevée | 1,74 | 1 740 j.h | +740 j.h |
Autrement dit, entre les deux extrêmes, l’effort théorique passe de 730 à 1 740 jours-homme, soit un rapport d’environ 2,38.
Il faut évidemment interpréter ces chiffres correctement : ils isolent l’effet de la complexité en supposant tous les autres paramètres identiques. Dans une estimation réelle, la complexité intervient avec les autres facteurs du projet.
Mais ils montrent pourquoi ignorer ce facteur peut fortement dégrader un chiffrage.
Cas concret : un système industriel
Prenons deux applications de taille fonctionnelle comparable.
La première est une application de gestion permettant de consulter des données, d’effectuer des mises à jour et de produire des états.
La seconde supervise des équipements industriels. Elle doit recevoir des événements provenant de différents dispositifs, traiter des informations en temps réel, synchroniser plusieurs traitements, gérer des situations d’exception et assurer la cohérence de données distribuées.
Du point de vue de l’utilisateur, les deux systèmes peuvent proposer un nombre comparable de fonctions.
Du point de vue de leur réalisation, ils sont très différents.
COCOMO II classe précisément parmi les caractéristiques de forte complexité le traitement distribué, le temps réel, les opérations liées aux équipements, les bases de données distribuées ou encore les mécanismes de synchronisation.
Une estimation reposant uniquement sur la taille risque donc de sous-estimer le second projet.
Pourquoi la complexité augmente-t-elle l’effort ?
La complexité agit à plusieurs endroits du cycle de développement.
Elle augmente d’abord l’effort de conception. Les interactions entre composants, traitements et données doivent être étudiées plus précisément.
Elle augmente ensuite l’effort de réalisation : davantage de cas particuliers, de mécanismes de synchronisation, d’algorithmes ou de traitements spécifiques doivent être implémentés.
Elle pèse également sur les tests. Plus les interactions sont nombreuses et complexes, plus le nombre de situations à vérifier augmente.
Enfin, elle augmente le risque de défauts difficiles à reproduire, notamment lorsque le comportement dépend de séquences d’événements, de traitements concurrents ou d’interactions avec des équipements.
Le manuel COCOMO II souligne d’ailleurs que, parmi les facteurs liés au produit, la complexité présente une influence particulièrement forte sur l’effort estimé.
Quels symptômes doivent alerter ?
Certains signaux doivent conduire à examiner la complexité plus attentivement :
- nombreuses règles de traitement interdépendantes ;
- traitements asynchrones ou parallèles ;
- nombreuses interactions entre composants ;
- contraintes temps réel ;
- interfaces avec des équipements ;
- structures de données fortement couplées ;
- traitements numériques complexes ;
- nombreux cas d’exception ;
- architectures distribuées ;
- comportements fortement dépendants de l’état du système.
Pris isolément, chacun de ces éléments ne signifie pas nécessairement que le projet est extrêmement complexe.
C’est leur importance et leur combinaison qui doivent être appréciées.
Conséquences sur le chiffrage
Une erreur fréquente consiste à déduire implicitement la difficulté technique de la taille du logiciel.
Or ce sont deux informations différentes.
Lors du chiffrage, il est donc utile de poser explicitement des questions telles que :
Quels sont les traitements les plus complexes ?
Existe-t-il des contraintes temps réel ?
Le logiciel pilote-t-il ou dialogue-t-il directement avec des équipements ?
Les traitements sont-ils distribués ou parallèles ?
La gestion des données nécessite-t-elle des mécanismes complexes de synchronisation ou de restructuration ?
Certaines interfaces nécessitent-elles des interactions particulièrement sophistiquées ?
Ces questions permettent de documenter l’hypothèse retenue et, surtout, d’éviter de choisir automatiquement le niveau nominal faute d’information.
Lorsque la complexité n’est pas suffisamment connue, elle doit devenir une hypothèse explicite du chiffrage.
Comment réduire l’impact de la complexité ?
Une DSI ne peut pas toujours supprimer la complexité : certaines contraintes sont inhérentes au métier ou au système.
Elle peut néanmoins éviter de créer de la complexité inutile.
Trois leviers sont particulièrement utiles.
Simplifier les exigences. Certaines difficultés techniques proviennent d’exigences dont la valeur métier est faible par rapport à leur coût.
Isoler les composants complexes. Une architecture adaptée peut empêcher qu’une difficulté locale se propage à l’ensemble du système.
Traiter les incertitudes suffisamment tôt. Prototypes, expérimentations et études techniques permettent de valider les choix les plus risqués avant d’engager massivement les développements.
L’objectif n’est donc pas nécessairement de rendre le logiciel simple, mais de maîtriser la complexité réellement nécessaire.
Et les IA génératives ?
Les IA génératives peuvent modifier une partie de l’équation.
Elles peuvent accélérer certaines activités : génération de code standard, documentation, création de tests, analyse de code ou assistance au développement.
Mais elles ne font pas disparaître la complexité intrinsèque d’un système.
Un système distribué reste distribué. Une synchronisation complexe reste complexe. Une contrainte temps réel continue d’imposer des choix d’architecture, des validations et des tests spécifiques.
L’IA peut donc réduire l’effort de certaines tâches nécessaires pour traiter la complexité, sans nécessairement supprimer la complexité elle-même.
Elle peut également aider en amont : analyser les exigences, détecter des interactions, identifier des zones potentiellement complexes et aider à formaliser les hypothèses de chiffrage.
Il faudra toutefois disposer de retours d’expérience suffisants pour déterminer dans quelle mesure les coefficients historiques doivent évoluer pour des équipes utilisant intensivement ces outils.
Les erreurs les plus fréquentes
La première consiste à assimiler taille et complexité.
Un gros logiciel n’est pas nécessairement techniquement complexe. À l’inverse, un composant relativement petit peut concentrer une difficulté technique très importante.
La deuxième consiste à retenir systématiquement le niveau nominal, simplement parce que les informations manquent.
La troisième consiste à apprécier la complexité uniquement à partir de l’architecture générale. COCOMO II montre qu’elle peut provenir de plusieurs dimensions différentes : contrôle, calcul, équipements, données et interfaces.
Enfin, la quatrième erreur consiste à constater la complexité seulement lorsque le développement a commencé.
À ce stade, elle apparaît sous forme de retards, de difficultés techniques, de multiplication des tests ou de réestimations.
À retenir
- La taille fonctionnelle et la complexité répondent à deux questions différentes.
- Dans COCOMO II, le coefficient de complexité varie de 0,73 à 1,74.
- Sur une référence de 1 000 jours-homme, une complexité très élevée représente 340 jours-homme supplémentaires par rapport au niveau nominal.
- La complexité doit être identifiée et documentée dès le chiffrage.
- L’IA générative peut aider à traiter la complexité, mais ne fait pas disparaître la complexité intrinsèque du système.
Quelles décisions pour un DSI ?
Pour un DSI, la première décision consiste à ne pas confondre quantité de logiciel et difficulté de réalisation.
La mesure de la taille permet d’objectiver ce qu’il faut produire. L’analyse de la complexité permet d’évaluer dans quelles conditions techniques cette quantité devra être produite.
Cette distinction améliore les décisions de chiffrage, mais également les arbitrages en amont.
Lorsqu’une exigence augmente fortement la complexité sans créer une valeur métier proportionnelle, elle peut être remise en question.
Lorsqu’une complexité est incontournable, elle doit au contraire être identifiée, financée et traitée suffisamment tôt.
La bonne question n’est donc pas seulement :
« Combien devons-nous développer ? »
mais également :
« Quelle difficulté technique devons-nous réellement assumer ? »
Le conseil Estimancy
Mesurez séparément la taille fonctionnelle et la complexité technique.
Lorsqu’un projet présente une complexité élevée, identifiez les composants concernés et documentez les hypothèses utilisées pour le chiffrage. Vous pourrez ainsi distinguer ce qui relève de la quantité de logiciel à produire de ce qui relève de la difficulté à le produire.
« La taille dit combien de logiciel produire. La complexité dit à quel point il sera difficile de le produire. »
