Fiabilité des Systèmes et des Logiciels

Ce document traite de la fiabilité des systèmes et des logiciels, en particulier des méthodes d’évaluation et des concepts fondamentaux liés à la sûreté de fonctionnement des systèmes informatiques. Il s’adresse aux étudiants de niveau universitaire, notamment en informatique ou en ingénierie, souhaitant comprendre les enjeux, la terminologie et les approches pour mesurer et améliorer la fiabilité des logiciels et matériels.

Problématique de la sûreté de fonctionnement des systèmes informatiques

Contexte

Ces dernières années, la maîtrise des risques et la sûreté de fonctionnement ont pris une importance croissante dans de nombreux domaines : sanitaire, environnemental, industriel, financier et géopolitique. L’opinion publique exige des niveaux de sécurité et de fiabilité toujours plus élevés.

Les systèmes informatiques, omniprésents, sont souvent au cœur de ces problématiques. Par exemple, en 2004, la France a subi plusieurs pannes majeures de réseaux informatiques, toutes causées par des défaillances logicielles :

• Juillet 2004 : le système de réservation Mosaic de la SNCF a été bloqué pendant près de 4 jours à cause d’un programme de contrôle mal conçu, provoquant une saturation du système.
• Octobre 2004 : une panne d’une journée sur le réseau fixe de France Télécom due à une anomalie logicielle dans un équipement de VoIP.
• Novembre 2004 : une panne sur le réseau mobile de Bouygues Telecom a privé 1,37 million de clients d’accès, causée par la défaillance simultanée de deux serveurs centraux jumeaux.
• Décembre 2004 : 800 terminaux de vente SNCF paralysés par un algorithme défectueux contaminant progressivement les terminaux.

D’autres exemples historiques illustrent l’impact des fautes logicielles, comme l’explosion d’Ariane 5 en 1996, des perturbations du trafic aérien britannique en 2004, ou encore des bugs dans des logiciels commerciaux majeurs.

Ces incidents ont érodé la confiance du public dans les systèmes informatiques. Par ailleurs, la pression économique pousse les entreprises à réduire les coûts et à avancer les dates de lancement, souvent au détriment de la fiabilité. Par exemple, la durée de garantie des ordinateurs personnels a diminué, indiquant une hausse des pannes.

Terminologie générale de la sûreté de fonctionnement

La sûreté de fonctionnement (SdF) d’un système est la propriété qui permet à ses utilisateurs de lui faire confiance pour délivrer le service attendu. Elle est composée de cinq éléments :

• Fiabilité (reliability) : probabilité que le système fonctionne sans défaillance pendant une durée donnée.
• Disponibilité (availability) : probabilité que le système fonctionne à un instant donné.
• Maintenabilité (maintainability) : aptitude du système à être réparé ou à évoluer après une panne.
• Sécurité-innocuité (safety) : aptitude à éviter des défaillances catastrophiques.
• Sécurité-confidentialité (security) : aptitude à se protéger contre les accès ou manipulations non autorisées.

On distingue deux types de systèmes :

• Système non réparable : mis au rebut dès qu’il tombe en panne (ex. ampoules).
• Système réparable : peut être remis en état après défaillance (ex. systèmes informatiques).

La maintenance peut être corrective (réparation après panne) ou préventive (actions pour retarder les pannes futures).

Deux approches d’étude existent :

• Boîte blanche (structurelle) : analyse des composants et de leur influence sur la fiabilité globale.
• Boîte noire (globale) : étude du système dans son ensemble, sans décomposition.

Fiabilité des matériels ou des logiciels

Plus de 80 % des défaillances des systèmes informatiques sont d’origine logicielle. Cependant, la fiabilité des matériels et des logiciels présente des différences fondamentales :

• Les défaillances matérielles sont dues à l’usure et aux facteurs environnementaux, tandis que les défaillances logicielles proviennent de fautes de conception (bugs).
• Un matériel s’use, un logiciel ne s’use pas.
• La maintenance matérielle ralentit le vieillissement, la correction logicielle augmente la fiabilité.
• Un logiciel non utilisé ne tombe pas en panne, contrairement au matériel.
• Une faute corrigée dans un logiciel est éliminée définitivement, alors que le matériel peut avoir des défaillances répétables.
• La fiabilité d’un matériel est souvent indépendante de l’environnement, alors que celle d’un logiciel dépend fortement du profil opérationnel.
• Un logiciel peut être relancé immédiatement après une défaillance, ce qui n’est pas le cas du matériel.

Ces différences impliquent que les méthodes d’étude de la fiabilité doivent être adaptées à chaque cas.

Le risque logiciel

Les défaillances logicielles sont causées par des fautes dans les programmes. Une étude montre qu’un programmeur professionnel fait en moyenne 6 fautes pour 1000 lignes de code (LOC). La taille des logiciels augmente sans cesse :

• Navette spatiale américaine : 500 000 LOC embarqué, 3,5 millions au sol.
• Réseaux téléphoniques : plusieurs millions de LOC.
• Windows Vista : plus de 50 millions de LOC.
• Logiciel commercial standard : environ 350 000 LOC.

Ces chiffres impliquent des milliers, voire des centaines de milliers de fautes potentielles. La détection et la correction sont coûteuses : environ 12 heures de travail par faute détectée. Par exemple, un logiciel avec 2000 fautes nécessite près de 24 000 heures de débogage.

Malgré les efforts, le zéro défaut est impossible. Les conséquences des fautes résiduelles peuvent être minimes ou catastrophiques.

Pour limiter ces risques, quatre catégories de méthodes sont utilisées :

• Prévention des fautes : empêcher l’introduction des fautes dès la conception (ex. méthodes formelles).
• Élimination des fautes : détecter et corriger les fautes dans un programme existant (tests, inspections, vérifications).
• Tolérance aux fautes : permettre au système de fonctionner malgré la présence de fautes (ex. redondance).
• Prévision des fautes : estimer la présence des fautes et prévoir les défaillances futures (méthodes probabilistes et statistiques).

Ce cours se concentre principalement sur la dernière catégorie, essentielle pour évaluer si les objectifs de fiabilité sont atteints.

Méthodes d’évaluation de la fiabilité des logiciels selon les étapes du cycle de vie

La nature des méthodes d’évaluation dépend des informations disponibles, liées au cycle de vie du logiciel :

Phase du cycle de vie	% d’erreurs introduites	% d’erreurs détectées
Analyse	55%	18%
Conception	30%	10%
Codage et test	10%	50%
Vie opérationnelle	5%	22%

Les erreurs majeures sont introduites en analyse et conception (85%) et détectées surtout en codage, test et vie opérationnelle (72%).

Avant la construction du système (analyse, conception, codage), aucune défaillance n’est observable. On peut alors utiliser des métriques (nombre de lignes de code, complexité cyclomatique, etc.) pour évaluer la qualité, mais pas directement la fiabilité.

En phase de test et en vie opérationnelle, le système fonctionne, les défaillances sont observées, et des corrections sont apportées. L’analyse statistique de ces événements permet d’évaluer la fiabilité.

Les logiciels complexes sont souvent modulaires. Si la fiabilité de chaque module est connue, on peut appliquer une approche boîte blanche. En pratique, on utilise souvent une approche boîte noire, considérant le logiciel comme un tout.

Utilisation des évaluations de fiabilité des logiciels

Les évaluations de fiabilité permettent :

• De quantifier la confiance d’un utilisateur envers un système, c’est-à-dire d’évaluer le risque lié à son utilisation.
• De vérifier que le logiciel atteint les objectifs de fiabilité spécifiés, souvent exprimés en taux de panne ou taux de défaillance. Par exemple, le métro parisien sans conducteur Meteor vise un taux de panne inférieur à 10^-11 pour le logiciel.
• De déterminer la durée et le coût des garanties associées aux systèmes.
• D’estimer l’effort de test nécessaire pour atteindre un objectif donné, fournissant ainsi un critère d’arrêt des tests.

Par exemple, chez AT&T, la mise en place de mesures de fiabilité a réduit la durée des tests de 15% et le coût total du projet de 4%, pour un surcoût de mesure de seulement 0,2%.

Enfin, la mesure de fiabilité peut aussi servir à évaluer la qualité d’une méthode de génie logiciel ou la performance d’un programmeur ou testeur, bien que cette dimension humaine soit délicate à gérer.

Terminologie spécifique aux logiciels

La fiabilité d’un logiciel est la probabilité qu’il fonctionne sans défaillance pendant une durée donnée dans un environnement spécifié. Cette notion est temporelle et peut se mesurer en temps CPU, temps calendaire, ou nombre d’opérations. Ce cours se concentre sur la définition temporelle.

Une défaillance survient lorsque le résultat fourni par le logiciel n’est pas conforme aux spécifications. Le logiciel peut être vu comme une fonction transformant un espace d’entrées en un espace de sorties (figure 1.1).

Programme

Espace des entrées → Programme → Espace des sorties

Une faute logicielle (bug) est un défaut intrinsèque au programme qui, dans certaines conditions, provoquera une défaillance. La faute existe même si le logiciel n’est pas utilisé, alors que la défaillance est un phénomène dynamique qui se manifeste à l’exécution.

Les fautes sont dues à des erreurs humaines (analyse, conception, programmation). Les défaillances dues à des problèmes matériels sont généralement identifiables et ne seront pas traitées ici.

Tester toutes les entrées possibles est impossible en raison de leur nombre. Le profil opérationnel définit un sous-ensemble d’entrées à tester, en associant une probabilité à chaque entrée ou groupe d’entrées selon leur fréquence d’utilisation. Ce profil diffère généralement entre phases de test et vie opérationnelle.

Lorsqu’une défaillance survient, on cherche à détecter et éliminer la faute par correction ou débogage. Parfois, des changements majeurs conduisent à une nouvelle version du logiciel.

Glossaire des termes clés

• Sûreté de fonctionnement (SdF) : capacité d’un système à être fiable, disponible, maintenable, sûr et sécurisé.
• Fiabilité : probabilité que le système fonctionne sans défaillance pendant une durée donnée.
• Disponibilité : probabilité que le système fonctionne à un instant donné.
• Maintenabilité : aptitude à être réparé ou évolué après une panne.
• Sécurité-innocuité : aptitude à éviter des défaillances catastrophiques.
• Sécurité-confidentialité : aptitude à se protéger contre les accès non autorisés.
• Système non réparable : système jeté après panne.
• Système réparable : système pouvant être remis en état après panne.
• Boîte blanche : approche d’analyse basée sur la structure interne du système.
• Boîte noire : approche d’analyse basée sur le système global sans décomposition.
• Défaillance : incapacité du système à délivrer le service attendu.
• Faute logicielle (bug) : défaut dans le programme pouvant provoquer une défaillance.
• Profil opérationnel : distribution des entrées utilisées par le logiciel dans son environnement.
• Maintenance corrective : réparation après défaillance.
• Maintenance préventive : actions pour retarder l’apparition de défaillances.

Points clés à retenir

• La fiabilité des systèmes informatiques est devenue un enjeu majeur dans de nombreux secteurs.
• Les défaillances logicielles sont la cause principale des pannes, souvent dues à des fautes de conception.
• La sûreté de fonctionnement comprend plusieurs composantes : fiabilité, disponibilité, maintenabilité, sécurité-innocuité et sécurité-confidentialité.
• La fiabilité des logiciels diffère fondamentalement de celle des matériels, notamment parce que les logiciels ne s’usent pas mais contiennent des fautes intrinsèques.
• Les méthodes d’évaluation de la fiabilité varient selon les phases du cycle de vie du logiciel, avec une forte concentration des erreurs introduites en analyse et conception, et détectées en test et vie opérationnelle.
• Les évaluations de fiabilité permettent de quantifier la confiance dans un système, d’atteindre des objectifs de qualité, et d’optimiser les efforts de test.
• La notion de défaillance logicielle est liée à la non-conformité du résultat à la spécification, et la détection des fautes repose sur l’analyse du profil opérationnel et des tests ciblés.