Quand les données deviennent un sujet de chiffrage
Lorsqu’une DSI prépare le budget d’un projet logiciel, elle évalue naturellement les fonctionnalités à développer, les interfaces, l’architecture, les ressources nécessaires et les contraintes techniques.
Le volume de données est souvent considéré comme un sujet d’infrastructure : capacité de stockage, performances de la base de données, sauvegarde ou archivage.
Mais il existe un autre impact, plus discret : l’effort nécessaire pour disposer de données permettant de développer et surtout de tester correctement l’application.
Sur un ERP comportant plusieurs années d’historique, une application bancaire traitant des millions de transactions ou un CRM comprenant plusieurs millions de clients, constituer des jeux de données représentatifs peut devenir une activité importante du projet.
COCOMO II intègre explicitement cette réalité dans l’estimation de l’effort.
Ce que mesure réellement le facteur « Taille de la base de données »
Le facteur DATA — Data Base Size — appartient à la famille des caractéristiques du produit.
Contrairement à ce que son nom pourrait laisser penser, il ne consiste pas simplement à mesurer le nombre de gigaoctets ou de téraoctets de la base de données en production.
COCOMO II cherche à mesurer l’importance du volume de données nécessaire aux tests par rapport à la taille du logiciel développé. Le manuel précise que l’objectif est de prendre en compte l’effort nécessaire pour constituer et maintenir les données permettant de tester le programme.
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 utilise le rapport D/P :
- D : volume en octets de la base de données utilisée pour les tests ;
- P : taille du logiciel en lignes de code source équivalentes.
Le modèle définit quatre niveaux effectivement applicables au facteur DATA.
| Niveau | Rapport D/P | Interprétation |
| Faible | < 10 | Peu de données relativement à la taille du logiciel |
| Nominal | 10 ≤ D/P < 100 | Volume courant |
| Élevé | 100 ≤ D/P < 1 000 | Volume important |
| Très élevé | ≥ 1 000 | Très gros volume relativement au logiciel |
Les niveaux « très faible » et « extrêmement élevé » ne sont pas utilisés pour ce facteur.
Les coefficients COCOMO II
À chaque niveau correspond un multiplicateur d’effort :
| Niveau | Coefficient |
| Faible | 0,90 |
| Nominal | 1,00 |
| Élevé | 1,14 |
| Très élevé | 1,28 |
Ces coefficients proviennent de la calibration COCOMO II.2000 présentée dans le manuel de référence.
Le niveau nominal constitue la référence : son multiplicateur est 1,00. Dans COCOMO II, les facteurs hors niveau nominal viennent multiplier l’effort estimé.
Exemple sur un projet de 1 000 jours-homme
Prenons un projet dont l’effort serait de 1 000 jours-homme au niveau nominal, tous les autres paramètres restant inchangés.
| Niveau DATA | Coefficient | Effort calculé | Écart / nominal |
| Faible | 0,90 | 900 j.h | -100 j.h |
| Nominal | 1,00 | 1 000 j.h | — |
| Élevé | 1,14 | 1 140 j.h | +140 j.h |
| Très élevé | 1,28 | 1 280 j.h | +280 j.h |
Le passage d’une situation nominale à une situation très élevée représente donc 280 jours-homme supplémentaires, soit +28 %.
L’écart entre les deux extrêmes, 900 et 1 280 jours-homme, atteint même 380 jours-homme, soit environ 42 % par rapport au niveau faible.
Il ne s’agit évidemment pas de dire qu’une grosse base augmente systématiquement de 28 % le coût de n’importe quel projet : c’est le niveau DATA, combiné aux autres caractéristiques du projet dans le modèle, qui contribue à l’estimation globale.
Cas concret : refonte d’un CRM
Prenons la refonte du CRM d’une grande entreprise.
Le nouveau système doit reprendre plusieurs millions de clients, leurs contrats, interactions, demandes, factures et historiques commerciaux.
L’équipe ne peut pas se contenter de tester quelques centaines de clients fictifs.
Elle doit reproduire des situations réalistes :
- clients possédant plusieurs contrats ;
- historiques longs ;
- données incomplètes ou atypiques ;
- doublons ;
- changements d’adresse ;
- différentes combinaisons de produits ;
- volumes importants de transactions.
À cela peuvent s’ajouter des contraintes de confidentialité empêchant l’utilisation directe des données de production.
Il faut alors extraire, anonymiser, transformer ou générer les données, vérifier leur cohérence puis maintenir les jeux de tests au fur et à mesure des évolutions du projet.
La donnée devient alors une véritable charge projet.
Pourquoi le volume des données augmente-t-il l’effort ?
L’explication donnée par COCOMO II est principalement liée aux tests : une grande quantité de données impose davantage d’efforts pour constituer et maintenir les données nécessaires à la validation du logiciel.
Dans les SI actuels, plusieurs mécanismes peuvent renforcer cet effet.
La préparation des données.
Les données de production sont rarement directement utilisables. Elles peuvent nécessiter extraction, nettoyage, transformation ou anonymisation.
La représentativité.
Un jeu de test doit reproduire non seulement les cas courants, mais également les cas rares et les combinaisons susceptibles de provoquer des anomalies.
La cohérence.
Les données sont souvent liées entre plusieurs applications et référentiels. Créer artificiellement un client peut nécessiter de créer simultanément ses contrats, opérations, factures ou droits.
La maintenance.
Lorsque le modèle de données ou les règles métier évoluent, les jeux de tests doivent eux aussi évoluer.
Le véritable sujet n’est donc pas uniquement le nombre d’octets stockés : c’est le travail nécessaire pour rendre les données exploitables par le projet.
Les symptômes à surveiller
Plusieurs signes doivent attirer l’attention lors de la préparation d’un projet :
- besoin de reprendre plusieurs années d’historique ;
- millions d’objets métier ou de transactions ;
- nombreux systèmes sources ;
- modèle de données fortement interconnecté ;
- difficulté à obtenir des données représentatives ;
- fortes contraintes de confidentialité ;
- anonymisation complexe ;
- environnements de test très éloignés de la production ;
- constitution manuelle des jeux de tests ;
- tests de volumétrie prévus tardivement.
Pris isolément, aucun de ces éléments ne suffit à déterminer le niveau DATA. Ils constituent en revanche de bons signaux pour approfondir l’analyse.
Conséquences sur le chiffrage
Lors d’un chiffrage, demander uniquement « Quelle est la taille de la base ? » est insuffisant.
Il faut comprendre quelles données seront nécessaires au développement et aux tests et comment elles seront obtenues.
Quelques questions sont particulièrement utiles :
Quel volume de données devra être représenté dans les environnements de test ?
Combien d’années d’historique sont nécessaires ?
Les données de production peuvent-elles être utilisées ?
Doivent-elles être anonymisées ?
Existe-t-il déjà des jeux de données de référence ?
Faut-il générer des données synthétiques ?
Quels volumes seront nécessaires aux tests de performance ?
Les données proviennent-elles de plusieurs SI ?
Ces informations permettent d’éviter une erreur classique : chiffrer correctement le logiciel tout en oubliant une partie du travail nécessaire pour le tester.
Comment maîtriser ce facteur ?
La DSI ne peut évidemment pas supprimer les données dont le système a besoin.
Elle peut cependant réduire l’effort nécessaire pour les exploiter.
Industrialiser la gestion des données de test.
Des processus reproductibles d’extraction, d’anonymisation et de chargement évitent de reconstruire les jeux de données pour chaque projet.
Constituer des jeux de référence.
Des jeux représentatifs et réutilisables peuvent réduire considérablement les travaux préparatoires.
Automatiser la génération des données.
Les outils de génération permettent de créer plus rapidement certaines populations ou certains cas particuliers.
Identifier le besoin dès la conception.
Plus le sujet est découvert tardivement, plus il risque de devenir un facteur de retard.
L’objectif n’est donc pas nécessairement de diminuer le volume, mais de réduire le coût de préparation et de maintenance des données nécessaires au projet.
Quel impact des IA génératives ?
Les IA génératives peuvent modifier sensiblement la manière dont ce facteur est géré.
Elles peuvent notamment faciliter la génération de données synthétiques, aider à produire des variantes de cas de test ou contribuer à identifier des combinaisons de données intéressantes.
Elles peuvent donc réduire une partie de l’effort de constitution des jeux de données.
Mais elles ne font pas disparaître le problème.
Une donnée synthétique doit rester cohérente avec les règles métier. Un historique bancaire, un dossier client ou un processus industriel ne peut pas être constitué d’informations simplement plausibles : les relations entre les données doivent respecter les contraintes du SI.
L’IA réduit donc potentiellement certains coûts de préparation, mais ne supprime ni le besoin de représentativité, ni celui de validation, ni les contraintes liées aux volumes importants.
Les erreurs fréquentes
Confondre base de production et données de test.
Le facteur DATA de COCOMO II porte spécifiquement sur les données nécessaires aux tests relativement à la taille du logiciel.
Raisonner uniquement en gigaoctets.
COCOMO II raisonne sur un rapport entre données et taille du programme, et non sur un volume absolu.
Considérer les données comme un simple sujet d’infrastructure.
Stocker les données n’est qu’une partie du problème. Les préparer et les maintenir consomme également de l’effort projet.
Découvrir le sujet pendant les tests.
Lorsque les équipes constatent tardivement que leurs données sont insuffisantes ou non représentatives, le planning est déjà exposé.
Supposer que l’IA supprimera la difficulté.
Générer rapidement beaucoup de données ne garantit ni leur cohérence ni leur représentativité.
À retenir
5 idées essentielles
- Le facteur DATA ne mesure pas simplement la taille physique d’une base de production.
- Il rapporte le volume des données nécessaires aux tests à la taille du logiciel.
- Dans COCOMO II, son coefficient varie de 0,90 à 1,28.
- Sur une référence de 1 000 jours-homme, un niveau très élevé représente 280 jours-homme de plus qu’un niveau nominal.
- Industrialiser les données de test permet de mieux maîtriser cet effort.
Quelles décisions pour un DSI ?
Le principal enseignement pour une DSI est simple : la stratégie de données de test doit faire partie des hypothèses de chiffrage d’un projet.
Sur les projets manipulant de grandes quantités de données, il est pertinent d’évaluer le besoin avant d’engager le développement : volumes, historique, diversité des données, anonymisation, génération synthétique, environnements et automatisation.
Cette analyse permet à la fois d’améliorer la qualité du chiffrage et d’identifier des investissements transverses susceptibles de bénéficier à plusieurs projets : plateformes de données de test, automatisation, anonymisation ou génération de données synthétiques.
COCOMO II rappelle ainsi un principe utile au pilotage des projets :
« Une donnée de test n’est pas seulement stockée : elle doit être préparée, maintenue et validée. »
Le conseil Estimancy
Ne demandez pas seulement quelle sera la taille de la base de données.
Lors du chiffrage, posez plutôt la question :
« De quelles données aurons-nous besoin pour tester réellement cette application, et quel effort faudra-t-il pour les obtenir et les maintenir ? »
Cette formulation permet de révéler beaucoup plus tôt une charge souvent invisible dans les premières estimations.
