Une application de consultation d’informations, un portail client, une application bancaire et un système de contrôle industriel peuvent présenter une taille fonctionnelle comparable.
Pourtant, leur coût de développement peut être sensiblement différent.
L’une des raisons est simple : les conséquences d’une défaillance ne sont pas les mêmes.
Une indisponibilité de quelques minutes peut être acceptable pour une application interne. Elle peut devenir beaucoup plus problématique pour un système de paiement, une application participant à un processus industriel ou un logiciel dont le dysfonctionnement peut mettre des personnes en danger.
Pour un DSI, la fiabilité attendue n’est donc pas uniquement une question technique ou de qualité. C’est également une hypothèse structurante du chiffrage.
Qu’est-ce que la fiabilité requise du logiciel ?
COCOMO II définit le facteur Required Software Reliability (RELY) comme une mesure du niveau auquel le logiciel doit assurer correctement la fonction prévue dans le temps. Le modèle détermine ses niveaux en fonction des conséquences possibles d’une défaillance.
Ce facteur est issu du modèle international COCOMO II, utilisé depuis de nombreuses années pour l’estimation des projets logiciels.
Il ne s’agit donc pas simplement de demander : « Le logiciel doit-il être fiable ? »
Tous les logiciels doivent l’être.
Il s’agit plutôt de déterminer ce qui se passe lorsque le logiciel ne remplit pas correctement sa fonction.
Les différents niveaux
COCOMO II distingue cinq niveaux utilisables pour ce facteur.
| Niveau | Conséquence indicative d’une défaillance | Coefficient |
| Très faible | Gêne légère | 0,82 |
| Faible | Pertes faibles et facilement récupérables | 0,92 |
| Nominal | Pertes modérées et facilement récupérables | 1,00 |
| Élevé | Pertes financières importantes | 1,10 |
| Très élevé | Risque pour la vie humaine | 1,26 |
Le coefficient agit comme un multiplicateur d’effort dans le modèle. COCOMO II considère d’ailleurs explicitement qu’un produit présentant de fortes exigences de fiabilité nécessite davantage d’effort de développement.
Exemple sur un projet de 1 000 jours-homme
Prenons un projet dont l’effort de référence est de 1 000 jours-homme au niveau nominal.
En isolant uniquement l’effet du facteur de fiabilité :
| Niveau | Coefficient | Effort résultant | Écart / nominal |
| Très faible | 0,82 | 820 j.h. | –180 j.h. |
| Faible | 0,92 | 920 j.h. | –80 j.h. |
| Nominal | 1,00 | 1 000 j.h. | — |
| Élevé | 1,10 | 1 100 j.h. | +100 j.h. |
| Très élevé | 1,26 | 1 260 j.h. | +260 j.h. |
L’écart entre les deux extrêmes atteint ainsi 440 jours-homme.
Plus frappant encore : un projet classé « très élevé » représente environ 54 % d’effort supplémentaire par rapport au même projet classé « très faible », toutes les autres hypothèses restant identiques.
Ce calcul ne signifie évidemment pas que la fiabilité explique à elle seule le coût d’un projet. COCOMO II combine plusieurs facteurs. Il permet en revanche d’isoler son influence.
Cas concret : une application bancaire
Imaginons deux fonctions présentant une taille fonctionnelle similaire.
La première permet à un client de consulter certaines informations commerciales. Une indisponibilité ponctuelle occasionne essentiellement une gêne.
La seconde exécute des opérations financières.
Une anomalie sur cette seconde fonction peut entraîner des transactions incorrectes, des pertes financières, des opérations de régularisation et des conséquences réglementaires ou d’image.
La quantité de fonctionnalités développées peut être comparable. Le niveau de maîtrise attendu ne l’est pas.
L’effort supplémentaire ne rémunère donc pas davantage de fonctionnalités : il rémunère une exigence supérieure sur la manière dont elles doivent fonctionner.
Pourquoi la fiabilité augmente-t-elle l’effort ?
Une exigence élevée de fiabilité se répercute sur plusieurs activités du projet.
Les exigences doivent être plus précises, les situations anormales davantage étudiées, les mécanismes de récupération mieux définis et l’architecture adaptée.
Les stratégies de tests deviennent également plus exigeantes : davantage de scénarios, de cas limites, de tests d’erreur et de vérifications des mécanismes de reprise.
À cela peuvent s’ajouter des revues plus approfondies, des contrôles supplémentaires et des critères d’acceptation plus stricts.
On ne développe pas nécessairement davantage de fonctions ; on investit davantage pour garantir leur comportement.
Quels symptômes observer ?
Plusieurs signes doivent attirer l’attention lors d’un chiffrage :
| Symptôme | Risque |
| « L’application ne doit jamais tomber » sans justification | Sur-spécification |
| Criticité non documentée | Sous-estimation possible |
| Même exigence appliquée à toutes les fonctions | Surcoût potentiel |
| Conséquences d’une panne non analysées | Mauvaise classification |
| Tests de résilience découverts tardivement | Dérive de charge |
| Exigences de disponibilité confondues avec la fiabilité | Hypothèses imprécises |
Le niveau de fiabilité doit donc être relié à des conséquences métier concrètes.
Conséquences sur le chiffrage
Lors du chiffrage, plusieurs questions simples permettent de qualifier le facteur :
- Que se passe-t-il si cette fonction produit un résultat erroné ?
- La perte est-elle facilement récupérable ?
- Existe-t-il un impact financier ?
- Existe-t-il un impact sur la sécurité des personnes ?
- Un mécanisme manuel permet-il de poursuivre l’activité ?
- Toutes les fonctions présentent-elles réellement la même criticité ?
Cette dernière question est importante.
Une application n’est pas toujours homogène. Certains composants peuvent être critiques et d’autres beaucoup moins. Appliquer indistinctement le niveau maximal à l’ensemble du système peut conduire à surévaluer l’effort.
Inversement, retenir par défaut un niveau nominal alors que certaines fonctions sont critiques conduit à sous-estimer le projet.
La fiabilité doit donc être une hypothèse explicite et traçable du chiffrage.
Comment améliorer la maîtrise de ce facteur ?
L’objectif n’est pas nécessairement de « réduire » le niveau de fiabilité. Une exigence élevée peut être parfaitement justifiée.
L’amélioration consiste surtout à définir le bon niveau au bon endroit.
Trois leviers sont particulièrement utiles.
Segmenter les niveaux de criticité.
Toutes les fonctions d’une application n’ont pas nécessairement besoin des mêmes exigences.
Relier les exigences à des impacts métier.
Une exigence telle que « haute fiabilité » est difficilement exploitable. Décrire les conséquences acceptables et inacceptables d’une défaillance permet une évaluation plus objective.
Intégrer ces exigences suffisamment tôt.
Découvrir tardivement que le logiciel doit répondre à des exigences de fiabilité élevées peut remettre en cause l’architecture, la stratégie de tests et donc le chiffrage initial.
Quel impact des IA génératives ?
Les IA génératives peuvent réduire l’effort de certaines activités : génération de scénarios de tests, analyse d’exigences, recherche de cas limites, assistance à la revue ou production de documentation.
Elles peuvent donc contribuer à réduire le coût de mise en œuvre de certaines mesures de qualité.
Mais elles ne font pas disparaître l’exigence de fiabilité.
Plus un système est critique, plus les résultats produits avec l’aide d’une IA doivent eux-mêmes être contrôlés. Générer plus rapidement des cas de tests n’apporte de valeur que si leur couverture et leur pertinence sont suffisantes.
L’IA modifie donc surtout la manière d’atteindre le niveau de fiabilité attendu, plutôt que la nécessité de définir ce niveau.
Les erreurs fréquentes
La première erreur consiste à considérer la fiabilité comme une exigence implicite : « évidemment que notre logiciel doit être fiable ».
Cette affirmation ne permet pas de chiffrer.
La deuxième consiste à confondre fiabilité maximale et qualité maximale. Exiger partout le niveau le plus élevé peut entraîner un investissement disproportionné par rapport aux enjeux métier.
La troisième consiste à définir le niveau uniquement à partir de considérations techniques, sans analyser les conséquences métier d’une défaillance.
Enfin, une erreur particulièrement coûteuse consiste à modifier l’exigence en cours de projet sans réviser l’estimation.
Passer d’un niveau nominal à très élevé n’est pas une simple précision apportée au cahier des charges. Dans COCOMO II, toutes choses égales par ailleurs, le coefficient passe de 1,00 à 1,26.
À retenir
Fiabilité requise du logiciel
- La taille fonctionnelle ne suffit pas à expliquer l’effort d’un projet.
- La conséquence d’une défaillance détermine le niveau de fiabilité à rechercher.
- COCOMO II utilise des coefficients allant de 0,82 à 1,26.
- Sur une référence de 1 000 jours-homme, le niveau très élevé représente 260 jours supplémentaires par rapport au nominal.
- L’objectif n’est pas de maximiser systématiquement la fiabilité, mais d’appliquer le niveau approprié à la criticité métier.
Quelles décisions pour un DSI ?
La première décision consiste à faire de la fiabilité une hypothèse explicite des estimations, et non une exigence implicite découverte pendant le développement.
La deuxième consiste à demander aux équipes métier et projet de qualifier les conséquences réelles d’une défaillance.
La troisième consiste à différencier les niveaux de criticité lorsque cela est possible. Cette approche permet de concentrer les investissements de conception, de tests et de sécurisation là où ils produisent réellement de la valeur.
Enfin, lorsqu’une exigence de fiabilité évolue, le chiffrage doit évoluer avec elle.
« La fiabilité n’est pas gratuite : son niveau doit être choisi avant d’être chiffré. »
Le conseil Estimancy
Lors d’un chiffrage, évitez la question trop générale : « Quel niveau de fiabilité souhaitez-vous ? »
Demandez plutôt :
« Quelles seraient les conséquences métier si cette fonction ne produisait pas le résultat attendu ? »
La réponse est beaucoup plus facile à obtenir auprès d’un responsable métier et permet de transformer une notion abstraite de qualité en hypothèse de chiffrage explicite, argumentée et mesurable.
