Une contrainte technique qui peut devenir une contrainte budgétaire
La mémoire disponible est aujourd’hui considérablement plus importante et moins coûteuse qu’aux débuts de l’ingénierie logicielle. On pourrait donc penser que les contraintes de mémoire ont pratiquement disparu des préoccupations des projets SI.
La réalité est plus nuancée.
Systèmes embarqués, équipements industriels, infrastructures existantes, environnements virtualisés, architectures cloud fortement dimensionnées, applications déployées sur un grand nombre d’équipements : il existe encore de nombreuses situations dans lesquelles la quantité de mémoire disponible constitue une véritable contrainte.
Et lorsqu’un logiciel doit fonctionner très près de cette limite, la conséquence ne se résume pas à quelques optimisations techniques supplémentaires. Elle peut affecter sensiblement l’effort et donc le coût du projet.
Que mesure le facteur « Contraintes de stockage » ?
Dans COCOMO II, ce facteur est appelé STOR – Main Storage Constraint.
Il mesure le degré de contrainte imposé au logiciel par la quantité de mémoire principale disponible sur sa plateforme d’exécution.
Autrement dit, la question n’est pas simplement :
« Combien de mémoire consomme l’application ? »
mais plutôt :
« Quelle proportion de la mémoire dont elle dispose est-elle autorisée à consommer ? »
Une application utilisant 4 Go sur un serveur disposant de 64 Go ne rencontre pas la même contrainte qu’une application utilisant 4 Go sur une plateforme limitée à 4,5 Go.
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 distingue quatre niveaux applicables à ce facteur :
| Niveau | Utilisation de la mémoire disponible |
| Nominal | ≤ 50 % |
| Élevé | 70 % |
| Très élevé | 85 % |
| Extra élevé | 95 % |
Il n’existe pas de niveau « faible » ou « très faible » pour ce facteur : en dessous du seuil nominal, COCOMO II ne considère pas que disposer de davantage de mémoire procure un gain supplémentaire d’effort.
Les coefficients
À chacun de ces niveaux correspond un multiplicateur appliqué à l’effort estimé :
| Niveau | Coefficient |
| Nominal | 1,00 |
| Élevé | 1,05 |
| Très élevé | 1,17 |
| Extra élevé | 1,46 |
L’évolution n’est donc pas linéaire.
Passer de 50 % à 70 % de mémoire utilisée n’entraîne qu’une augmentation modérée de l’effort estimé. En revanche, fonctionner à proximité immédiate de la limite disponible devient beaucoup plus pénalisant.
Exemple : un projet de 1 000 jours-homme
Prenons un projet dont l’effort serait de 1 000 jours-homme en situation nominale, tous les autres facteurs restant identiques.
| Niveau | Coefficient | Effort estimé | Écart |
| ≤ 50 % | 1,00 | 1 000 j.h. | — |
| 70 % | 1,05 | 1 050 j.h. | +50 j.h. |
| 85 % | 1,17 | 1 170 j.h. | +170 j.h. |
| 95 % | 1,46 | 1 460 j.h. | +460 j.h. |
À contrainte maximale, l’écart atteint donc 460 jours-homme, soit 46 % d’effort supplémentaire.
Il faut naturellement interpréter ces chiffres comme l’effet du facteur dans le modèle, toutes choses égales par ailleurs. Ils ne signifient pas que toute application utilisant 95 % de sa mémoire coûtera automatiquement 46 % plus cher.
Ils montrent en revanche qu’une contrainte forte doit être explicitement intégrée au chiffrage.
Cas concret : un système industriel
Imaginons le renouvellement d’une application de supervision devant être déployée sur plusieurs milliers d’équipements industriels existants.
La DSI souhaite conserver le matériel afin d’éviter son remplacement. L’application doit donc respecter une enveloppe mémoire très stricte.
Au début du projet, cette exigence peut sembler raisonnable : pourquoi remplacer plusieurs milliers d’équipements encore opérationnels ?
Mais cette décision transfère une partie du coût de l’infrastructure vers le développement logiciel.
Les équipes doivent surveiller les allocations mémoire, optimiser certaines structures de données, limiter les traitements simultanés, arbitrer entre mise en cache et recalcul, réaliser davantage de tests en conditions limites et analyser les fuites mémoire.
Le choix initial peut rester économiquement pertinent. Mais il doit être évalué en tenant compte du coût logiciel qu’il entraîne.
Pourquoi un tel impact ?
Une contrainte de mémoire forte réduit les marges de manœuvre des équipes.
Avec une marge confortable, les développeurs peuvent privilégier la simplicité, la maintenabilité et l’utilisation de composants standards.
Lorsque la limite devient stricte, davantage d’arbitrages apparaissent.
Il peut être nécessaire de revoir les structures de données, limiter les caches, optimiser les composants consommateurs de mémoire, modifier certains algorithmes ou renoncer à des bibliothèques trop lourdes.
La conception devient plus contrainte.
Les tests doivent également vérifier le comportement du système lorsque la consommation approche de la limite. Une évolution fonctionnelle apparemment mineure peut nécessiter une nouvelle campagne d’analyse de la consommation mémoire.
Plus la marge disponible diminue, plus le risque qu’une modification provoque un dépassement augmente.
Quels symptômes doivent alerter ?
Plusieurs signes peuvent révéler une contrainte sous-estimée :
- optimisations mémoire récurrentes pendant le développement ;
- dépassements constatés tardivement pendant les tests ;
- nécessité de remplacer des composants standards par des développements spécifiques ;
- incidents ou ralentissements lorsque plusieurs traitements fonctionnent simultanément ;
- difficulté à ajouter de nouvelles fonctionnalités sans réoptimiser l’existant ;
- campagnes répétées de profiling et de tests de charge ;
- arbitrages fréquents entre fonctionnalités et consommation de ressources.
Lorsque ces symptômes apparaissent alors qu’aucune contrainte mémoire n’avait été identifiée dans le chiffrage, l’estimation initiale risque d’être trop optimiste.
Conséquences sur le chiffrage
Une estimation sérieuse doit donc faire apparaître explicitement cette hypothèse.
Quelques questions simples permettent de la qualifier :
Quelle quantité de mémoire sera disponible sur la plateforme cible ?
Quelle consommation maximale est autorisée pour l’application ?
Cette limite est-elle indicative ou impérative ?
Doit-elle être respectée dans tous les scénarios de fonctionnement ?
Existe-t-il des pics de consommation ?
La plateforme peut-elle être redimensionnée ?
Quel serait le coût d’une augmentation de la mémoire disponible ?
Cette dernière question est particulièrement importante.
Le chiffrage ne doit pas seulement constater la contrainte. Il doit permettre de challenger sa pertinence économique.
Une contrainte extrême peut entraîner des centaines de jours-homme supplémentaires. Dans certaines situations, augmenter les ressources matérielles ou cloud peut coûter beaucoup moins cher.
Comment améliorer ce facteur ?
Le premier levier consiste donc à éviter les contraintes artificielles.
Une limite historique ne doit pas automatiquement devenir une exigence du nouveau système.
Le deuxième consiste à dimensionner correctement l’environnement cible dès la conception.
Le troisième consiste à mesurer tôt la consommation réelle, notamment au moyen de prototypes et de tests représentatifs.
Enfin, lorsqu’une contrainte forte est incontournable, elle doit être traitée comme une véritable exigence non fonctionnelle : mesurable, testable et prise en compte dans l’architecture.
L’objectif n’est pas nécessairement de supprimer la contrainte.
Il est de la rendre explicite afin que son coût soit connu.
Quel impact des IA génératives ?
Les IA génératives peuvent faciliter certaines tâches : proposer des alternatives d’implémentation, identifier des structures de données potentiellement coûteuses, suggérer des optimisations ou aider à analyser du code.
Elles peuvent donc réduire le temps nécessaire à certaines investigations.
Mais elles ne suppriment pas la contrainte physique.
Un logiciel qui doit fonctionner dans une enveloppe mémoire stricte devra toujours être conçu, testé et validé dans cette enveloppe.
Par ailleurs, du code généré rapidement n’est pas nécessairement optimisé pour la consommation mémoire. L’accélération de la production de code peut même rendre encore plus nécessaire la mesure systématique de ses caractéristiques techniques.
L’IA modifie donc surtout la manière de traiter la contrainte, davantage que l’existence de celle-ci.
Les erreurs fréquentes
« La mémoire ne coûte plus rien »
Son coût unitaire a fortement diminué. Mais cela ne signifie pas que toute plateforme peut être redimensionnée librement.
Confondre optimisation souhaitable et contrainte obligatoire
Vouloir une application peu gourmande est une bonne pratique. Imposer une limite très basse est une contrainte de projet qui doit être justifiée.
Découvrir la limite pendant les tests
À ce stade, les choix d’architecture sont déjà largement réalisés et les corrections deviennent plus coûteuses.
Optimiser sans calcul économique
Consacrer plusieurs centaines de jours-homme à économiser une ressource dont l’augmentation aurait coûté quelques milliers d’euros peut être un mauvais arbitrage.
Ne pas intégrer la contrainte dans l’estimation
Si elle impose un travail supplémentaire mais n’apparaît pas dans les hypothèses du chiffrage, le budget sera mécaniquement sous-évalué.
À retenir
Contraintes de stockage : 5 points essentiels
- COCOMO II mesure la contrainte par rapport à la mémoire réellement disponible.
- Jusqu’à 50 % d’utilisation, le niveau est considéré comme nominal.
- À 95 %, le multiplicateur d’effort atteint 1,46.
- Une contrainte technique peut donc devenir un véritable facteur budgétaire.
- Le bon arbitrage consiste parfois à augmenter les ressources plutôt qu’à optimiser davantage le logiciel.
Quelles décisions pour un DSI ?
Le principal enseignement n’est pas qu’il faut systématiquement augmenter la mémoire disponible.
Il est qu’une contrainte de plateforme doit faire l’objet d’un arbitrage économique explicite.
Avant de demander aux équipes de respecter une enveloppe très stricte, une DSI peut comparer trois éléments : le coût d’augmentation des ressources, le coût supplémentaire de développement et le coût potentiel du changement de plateforme.
Elle peut également imposer que les contraintes fortes soient identifiées dès le cadrage, intégrées au chiffrage et vérifiées suffisamment tôt par des prototypes.
La contrainte devient alors une décision économique maîtrisée plutôt qu’une surprise technique découverte en cours de projet.
« Une ressource économisée n’est une économie que si elle coûte moins cher que l’effort nécessaire pour l’économiser. »
Le conseil Estimancy
Lors du chiffrage, ne demandez pas seulement combien de mémoire l’application devrait consommer.
Demandez surtout quelle est la limite réellement imposée et pourquoi elle existe.
Puis chiffrez deux scénarios : le projet avec cette contrainte et le projet avec une plateforme légèrement plus généreuse.
L’écart d’effort permet de transformer une exigence technique en décision économique et de choisir la solution présentant le meilleur coût global.
Les niveaux et coefficients de l’article proviennent directement de la table 24 du manuel de référence COCOMO II. Le manuel précise également que la plateforme désigne le complexe matériel et logiciel d’infrastructure sur lequel s’appuie le produit.
