Lorsque l’on évoque les causes de dépassement budgétaire d’un projet logiciel, les discussions portent souvent sur la taille du périmètre, la complexité technique ou encore les compétences de l’équipe.
Pourtant, un facteur est fréquemment sous-estimé : le niveau de fiabilité attendu du logiciel.
Développer un logiciel qui peut occasionner une gêne mineure en cas de panne n’a rien à voir avec le développement d’un logiciel dont une défaillance pourrait provoquer des pertes financières importantes, des interruptions de service critiques ou mettre des vies humaines en danger.
Le modèle d’estimation COCOMO II prend explicitement en compte cette réalité à travers le facteur RELY (Required Software Reliability).
Qu’est-ce que le facteur RELY ?
RELY mesure les conséquences d’une défaillance du logiciel sur les utilisateurs, l’entreprise ou la société.
Plus les conséquences d’une erreur sont graves, plus le niveau de fiabilité attendu augmente.
Cette exigence influence directement :
- la conception ;
- les revues ;
- les tests ;
- la validation ;
- la documentation ;
- la gestion des anomalies ;
- les procédures de mise en production.
Autrement dit, la taille fonctionnelle du logiciel reste identique, mais l’effort nécessaire pour atteindre le niveau de qualité requis augmente.
Les différents niveaux de fiabilité
COCOMO II distingue plusieurs niveaux de fiabilité.
| Niveau RELY | Conséquence d’une défaillance |
| Very Low | Inconvénients mineurs pour les utilisateurs |
| Low | Pertes limitées et facilement récupérables |
| Nominal | Conséquences modérées pour l’activité |
| High | Pertes financières importantes ou interruption significative du service |
| Very High | Risques majeurs pour l’entreprise ou l’activité |
| Extra High | Risques pour des vies humaines |
Les coefficients d’effort associés
Le modèle COCOMO II associe à chaque niveau un multiplicateur d’effort.
| Niveau RELY | Multiplicateur d’effort |
| Very Low | 0,82 |
| Low | 0,92 |
| Nominal | 1,00 |
| High | 1,10 |
| Very High | 1,26 |
Le niveau nominal constitue la référence.
Quel impact sur le budget ?
Prenons un projet de référence estimé à 1 000 jours-homme avec un niveau de fiabilité nominal.
| Niveau RELY | Budget résultant |
| Very Low | 820 j.h |
| Low | 920 j.h |
| Nominal | 1 000 j.h |
| High | 1 100 j.h |
| Very High | 1 260 j.h |
L’écart entre les extrêmes atteint :
1 260 – 820 = 440 jours-homme
Pour un coût moyen de 700 € par jour :
440 × 700 € = 308 000 €
La seule exigence de fiabilité peut donc représenter plusieurs centaines de milliers d’euros sur un projet de taille moyenne.
Pourquoi la fiabilité coûte-t-elle si cher ?
La réponse est simple : la majorité du coût supplémentaire ne provient pas du développement lui-même.
Elle provient des activités destinées à réduire le risque d’erreur.
Par exemple :
Conception plus rigoureuse
Les architectures sont davantage documentées et analysées.
Les choix techniques doivent être justifiés et vérifiés.
Revues supplémentaires
Les spécifications, le code et les scénarios de tests font l’objet de contrôles renforcés.
Tests plus nombreux
Les campagnes de tests couvrent davantage de situations :
- cas limites ;
- scénarios d’erreur ;
- tests de charge ;
- tests de robustesse ;
- tests de reprise après incident.
Traçabilité renforcée
Chaque exigence doit être reliée aux développements et aux tests associés.
Validation plus stricte
Les critères d’acceptation deviennent plus exigeants.
Quelques exemples
Niveau faible
Exemples :
- application interne de consultation ;
- outil bureautique ;
- portail d’information.
Une panne est gênante mais sans conséquence majeure.
Niveau nominal
Exemples :
- CRM ;
- ERP ;
- portail client ;
- gestion commerciale.
Une erreur a un coût mais reste généralement récupérable.
Niveau élevé
Exemples :
- système bancaire ;
- facturation de masse ;
- gestion de production industrielle ;
- gestion de réseau énergétique.
Une erreur peut générer des pertes importantes ou interrompre l’activité.
Niveau très élevé
Exemples :
- contrôle aérien ;
- systèmes ferroviaires de sécurité ;
- dispositifs médicaux ;
- pilotage d’équipements industriels dangereux.
Une défaillance peut mettre des vies humaines en danger.
Une erreur fréquente dans les projets
De nombreuses organisations définissent des exigences de disponibilité, de sécurité ou de qualité très ambitieuses sans mesurer leur impact économique.
Il n’est pas rare d’entendre :
« Nous voulons zéro défaut. »
ou
« Le système doit être totalement fiable. »
Ces objectifs sont compréhensibles mais ils ne sont jamais gratuits.
Plus le niveau de fiabilité augmente, plus les coûts de prévention, de détection et de correction augmentent également.
Un facteur à intégrer dès le chiffrage
L’exigence de fiabilité doit être clarifiée très tôt dans le projet.
Deux applications de même taille fonctionnelle peuvent présenter des budgets très différents uniquement à cause de leurs objectifs de fiabilité.
Ne pas expliciter cette hypothèse revient à construire un budget sur une base incertaine.
Conclusion
La taille fonctionnelle d’un logiciel détermine ce qu’il faut développer.
L’exigence de fiabilité détermine le niveau d’effort nécessaire pour garantir que le logiciel fonctionnera correctement.
Selon le modèle COCOMO II, un projet soumis à des exigences de fiabilité très élevées peut nécessiter plus de 50 % d’effort supplémentaire par rapport à un projet de même taille dont les conséquences d’une panne sont limitées.
Avant de demander un logiciel « sans défaut », il est donc utile de se poser une question simple :
Quel est réellement le coût d’une erreur ?
