Une exigence technique qui peut modifier l’économie du projet
« Le temps de réponse doit rester inférieur à une seconde. »
« Le traitement doit être terminé avant l’ouverture des agences. »
« Le système doit absorber 10 000 transactions par seconde. »
Ces exigences sont fréquentes dans les projets SI. Pourtant, leur impact sur le coût du projet est parfois sous-estimé lors du chiffrage.
La question importante n’est pas simplement de savoir si une application doit être performante. Elle est de déterminer jusqu’à quel point elle doit exploiter les capacités de la plateforme pour atteindre les performances demandées.
Lorsqu’une application dispose d’une marge importante, les équipes peuvent privilégier des architectures et des solutions relativement standards. Lorsqu’elle doit fonctionner très près des limites disponibles, les choix deviennent plus contraints.
Et l’effort de développement augmente.
Que mesure le facteur « contraintes de temps d’exécution » ?
Ce facteur est issu du modèle international COCOMO II, utilisé depuis de nombreuses années pour l’estimation des projets logiciels.
COCOMO II le désigne sous le nom Execution Time Constraint (TIME). Il mesure la contrainte de temps d’exécution imposée au logiciel en fonction du pourcentage de la ressource de temps d’exécution disponible que le système devrait consommer.
L’idée est simple.
Plus le système dispose de marge pour effectuer ses traitements, plus la conception est confortable.
À l’inverse, lorsqu’il doit utiliser 85 % ou 95 % des capacités disponibles, les équipes disposent de beaucoup moins de latitude. Elles doivent rechercher, mesurer et optimiser les performances.
Il ne s’agit donc pas directement d’un indicateur de vitesse du logiciel. C’est avant tout un indicateur de niveau de contrainte imposé à sa conception.
Les différents niveaux
COCOMO II distingue les situations suivantes :
| Niveau | Utilisation du temps d’exécution disponible | Coefficient |
| Nominal | ≤ 50 % | 1,00 |
| Élevé | 70 % | 1,11 |
| Très élevé | 85 % | 1,29 |
| Extrêmement élevé | 95 % | 1,63 |
Il n’existe pas de niveaux « faible » ou « très faible » pour ce facteur : en dessous du niveau nominal, COCOMO II ne considère pas qu’une marge supplémentaire réduise encore l’effort.
Que signifient ces coefficients ?
Le coefficient agit comme un multiplicateur de l’effort estimé du projet, toutes choses égales par ailleurs.
Prenons un projet dont l’effort de référence est de 1 000 jours-homme.
| Niveau | Coefficient | Effort obtenu | Écart |
| Nominal | 1,00 | 1 000 j.h | — |
| Élevé | 1,11 | 1 110 j.h | +110 j.h |
| Très élevé | 1,29 | 1 290 j.h | +290 j.h |
| Extrêmement élevé | 1,63 | 1 630 j.h | +630 j.h |
L’écart maximal atteint donc 630 jours-homme, soit 63 % d’effort supplémentaire.
Ce chiffre ne signifie évidemment pas que toute exigence de performance augmente automatiquement un projet de 63 %. Il correspond au niveau extrême défini par le modèle, lorsque le logiciel doit fonctionner très près de la capacité disponible.
L’intérêt est ailleurs : une exigence non fonctionnelle peut avoir un impact économique majeur sans ajouter une seule fonctionnalité supplémentaire.
Cas concret : une application bancaire
Imaginons une banque développant un nouveau système de traitement des paiements.
Les fonctionnalités sont connues et la taille fonctionnelle du logiciel a été estimée.
Mais une exigence supplémentaire apparaît : lors des périodes de forte activité, le système doit traiter un volume très élevé de transactions tout en respectant des temps de réponse stricts.
Dans une architecture disposant d’une forte réserve de capacité, cette exigence peut être relativement facile à satisfaire.
Si l’infrastructure cible est déjà fortement sollicitée, la situation change.
Les architectes doivent analyser plus finement les traitements, les échanges réseau, les accès aux données, les mécanismes de concurrence et les ressources consommées.
Des campagnes de tests de charge deviennent nécessaires. Certains composants peuvent devoir être réécrits ou optimisés.
La fonctionnalité métier reste pourtant exactement la même.
Ce qui augmente n’est pas la quantité fonctionnelle du logiciel, mais l’effort nécessaire pour respecter ses contraintes d’exécution.
Pourquoi l’impact peut-il devenir aussi important ?
Une forte contrainte de performance agit sur plusieurs dimensions du projet.
Elle réduit tout d’abord la liberté de conception. Une solution techniquement correcte sur le plan fonctionnel peut devenir inacceptable si elle consomme trop de ressources.
Elle nécessite ensuite davantage de mesures. Les performances doivent être testées dans des conditions représentatives des volumes réels.
Elle peut également conduire à optimiser certains algorithmes, requêtes, structures de données ou échanges entre composants.
Enfin, les problèmes de performance apparaissent souvent dans des situations difficiles à reproduire : pics d’activité, traitements simultanés, gros volumes ou interactions entre plusieurs composants.
La difficulté n’est donc pas seulement de développer le logiciel, mais de démontrer qu’il respectera ses objectifs dans les situations critiques.
Quels symptômes doivent alerter ?
Plusieurs formulations doivent attirer l’attention lors de l’analyse d’un projet :
- « temps réel » ;
- « réponse immédiate » ;
- « aucune dégradation en période de pointe » ;
- « traitement impérativement terminé avant… » ;
- « très gros volumes » ;
- « forte simultanéité » ;
- « infrastructure imposée » ;
- « temps de réponse garanti ».
Ces expressions ne prouvent pas que le facteur TIME est élevé. Elles indiquent qu’il faut approfondir la question.
La première difficulté consiste justement à transformer des expressions qualitatives en exigences mesurables.
Conséquences sur le chiffrage
Une estimation sérieuse ne devrait donc pas se limiter à la liste des fonctionnalités.
Lors du chiffrage, plusieurs questions doivent être posées :
Quels sont les temps de réponse attendus ?
Quels volumes doivent être traités ?
Quels sont les volumes en situation de pointe ?
Quelles fonctions sont réellement soumises à ces contraintes ?
Quelle est la capacité de la plateforme cible ?
Existe-t-il une marge de capacité ?
Ces performances ont-elles déjà été validées par des tests ou un prototype ?
La précision du chiffrage dépend fortement de la qualité de ces informations.
Une phrase telle que « l’application devra être très performante » ne constitue pas une hypothèse exploitable.
À l’inverse, des objectifs mesurés et associés à des scénarios de charge permettent d’évaluer beaucoup plus précisément le niveau de contrainte.
Comment améliorer ce facteur ?
Le premier levier consiste paradoxalement à ne pas chercher une performance supérieure au besoin réel.
Chaque exigence extrême devrait pouvoir être reliée à une justification métier.
Un temps de réponse de 500 millisecondes apporte-t-il réellement plus de valeur qu’un temps de réponse d’une seconde ?
Toutes les transactions nécessitent-elles la même performance ?
Une partie des traitements peut-elle être réalisée de manière asynchrone ?
La plateforme peut-elle être dimensionnée différemment ?
Une DSI peut également agir en testant très tôt les architectures envisagées. Un prototype technique ou un test de charge réalisé avant le développement complet coûte généralement beaucoup moins cher qu’une remise en cause tardive de l’architecture.
Enfin, conserver une marge de capacité permet d’absorber plus facilement les évolutions futures.
Quel impact des IA génératives ?
Les IA génératives ne font pas disparaître les contraintes de performance.
Elles peuvent cependant aider les équipes dans certaines tâches : analyse de code, recherche de pistes d’optimisation, génération de scénarios de tests, interprétation de résultats ou proposition d’alternatives techniques.
Elles peuvent donc réduire l’effort nécessaire à certaines activités d’analyse ou d’optimisation.
Mais elles ne changent pas le problème fondamental : un système devant fonctionner très près de ses limites physiques reste plus contraint qu’un système disposant d’une marge importante.
Par ailleurs, l’utilisation de composants d’IA générative peut elle-même introduire de nouvelles contraintes : latence des modèles, appels à des services externes, consommation de ressources ou variabilité des temps de réponse.
L’IA modifie donc la manière de traiter le facteur TIME plus qu’elle ne le fait disparaître.
Les erreurs les plus fréquentes
La première erreur consiste à considérer la performance comme un sujet à traiter uniquement lors des tests.
À ce stade, une mauvaise architecture peut être coûteuse à corriger.
La deuxième consiste à confondre performance souhaitable et performance nécessaire. Une exigence excessive peut imposer des optimisations qui apportent peu de valeur métier.
La troisième consiste à considérer toutes les fonctions de la même manière. Dans beaucoup de systèmes, seules quelques fonctions sont réellement critiques.
Enfin, une erreur classique consiste à dimensionner l’effort uniquement à partir des fonctionnalités à développer, sans intégrer suffisamment les exigences non fonctionnelles.
Deux projets offrant exactement les mêmes services aux utilisateurs peuvent nécessiter des efforts très différents si leurs contraintes de performance ne sont pas les mêmes.
À retenir
- La contrainte de temps d’exécution mesure la pression exercée sur les capacités disponibles de la plateforme.
2. Dans COCOMO II, son coefficient peut passer de 1,00 à 1,63.
3. Sur un projet de référence de 1 000 jours-homme, cela représente potentiellement 630 jours-homme supplémentaires.
4. Les exigences de performance doivent être quantifiées dès le chiffrage.
5. Le meilleur levier consiste souvent à distinguer la performance réellement nécessaire de la performance simplement souhaitée.
Quelles décisions un DSI peut-il prendre à la lumière de ce paramètre ?
La première décision consiste à considérer les exigences de performance comme de véritables hypothèses économiques du projet, et pas uniquement comme des questions techniques.
Lorsqu’une exigence de performance est particulièrement forte, le DSI peut demander sa justification métier et évaluer son rapport coût/bénéfice.
Il peut également décider d’investir plus tôt dans l’architecture, le prototypage et les tests de charge.
Enfin, il peut arbitrer entre trois leviers : augmenter les ressources de la plateforme, optimiser davantage le logiciel ou revoir certaines exigences.
L’objectif n’est pas de minimiser systématiquement la performance.
Il est de savoir combien l’organisation est prête à investir pour obtenir le niveau de performance réellement nécessaire.
« La performance devient coûteuse lorsqu’il ne reste plus de marge. »
Le conseil Estimancy
Lors d’un chiffrage, ne demandez pas simplement : « Y a-t-il des contraintes de performance ? »
Demandez plutôt : « Quelles fonctions sont contraintes, quels niveaux de performance doivent-elles atteindre, dans quelles conditions de charge et quelle marge offre la plateforme cible ? »
Cette formulation transforme une exigence qualitative en hypothèses utilisables pour l’estimation.
