Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Université des Sciences et de la Technologie Houari Boumediene

Faculté d’ Informatique

Rapport SFFL

BOUSSOURDI Mohamed Nadir

Année universitaire : 2021/2022

M1 SSI

1
Table des matières :

❖ 0.introduction …………………………………………………...…3
❖ 1. Recenser et classification des défaillances………………………..….3
■ Classification suivant la cohérence ……………………….3
■ Classification suivant la nature de la perturbation ………..3
■ -Plus- le code en question qui a causé cette catastrophe …4
■ Classification suivant la durée de la défaillance…………..4
■ Classification suivant la gravité………………………...…5
■ Classification suivant la fréquence de l’occurrence……….5
❖ 2.Recensement et classifier les fautes conduisant à ces derniers ……....5
■ par nature…………………………………………………..5
■ par le moment de leur création…………………………….5
■ par leur rapport avec le produit …………………………...5
■ par rapport à leur persistance……………………………...5
❖ 3.Les leçons à tirer de ce cas …………………………………………..6
❖ 4.Les modèles les mieux adaptés pour de tel projets…………………..7
■ 4.1. Cycle en V……………………………………………………..7
■ 4.2. Modèle en cascade …………………………………...8
■ 4.3. Le modèle à éviter………….…………………….…...8
❖ 5.Annex……………………………………………………..…9

2
Introduction :
Ariane 5 est un lanceur spatial développé pour placer des satellites sur orbite géostationnaire.
Ce dernier est venu comme successeur à la fusée Ariane 4, mais le jour de son lancement il a rencontré
un incident grave (défaillance).
Qu’est-ce qu’une défaillance ?
Comme indiqué par la définition de la défaillance : c’est un état du produit dans lequel le service
délivré n’est pas conforme au cahier des charges/spécification du produit.
Dans notre cas le produit c’est « Ariane 5 », le service principale indiqué dans le cahier des charges est
de  placer les quatre satellites de la mission Cluster sur orbite géostationnaire .
Le jour de son lancement plus exactement à H0+40 (après 40 secondes du décollage ) on a assisté à un
crash qui a causé plus de 500 millions de dollars.
Dans cette histoire le mode de défaillance est un bug dans le programme plus exactement, la faute
originelle de type OVERFLOW, mais derrière ça y’a plein de pannes qui ont conduit vers cet
‘’incident grave’’.

1-Recensement et classification des défaillances :

❖ Classification suivant la cohérence :

Il est vrai que dans notre cas on ne peut pas se permettre de reproduire
l’expérimentation pour vérifier si on aura le même résultat vu le prix, Mais on a eu
deux calculateur identique (font office d’utilisateur) on remarquera que nos
utilisateurs ont la même perception d’où :
C’est une : Défaillance cohérente.
❖ Classification suivant la nature de la perturbation :
Il nous a été dit que la première erreur technique a été l’affectation d’une donnée 64
bits vers une donnée 16 bits, c’est une délivrance de valeur erronée, c’est-à-dire :
C’est une : Défaillance de valeur.

3
 Le code en question qui a causé cette catastrophe :
La vitesse verticale a été bien gérée du côté gestion des erreurs, par contre la
vitesse horizontale a été convertie directement sans vérification et cela pour
améliorer les performances en dépit de la sûreté de fonctionnement.

❖ Classification suivant la durée de la défaillance :

Sachent que le service fourni est ‘’placer les satellites sur orbite’’
On a dû à cause de cette défaillance reconstruire un nouveau lanceur spatial, cela a
pris un temps énorme, et donc le service a dû être altéré pendant une fraction
importante de temps d’où C’est une : Défaillance durable.

4
 ❖ Classification suivant la gravité :
Dans notre cas la mission a été arrêtée, le produit (fusé) a été détruite, c’est donc
Défaillance catastrophique

❖ Classification suivant la fréquence de l’occurrence :

Sachent qu’une mission prend plusieurs minutes et que cette défaillance s’est
produite dans les 40 premiers seconds et cela à travers 2 calculateurs, on peut dire
que cette défaillance est : Défaillance Probable (Fréquent)

2-Recensement et classifier les fautes conduisant à ces derniers :

❖ Par nature :
Comme indiqué dans la première partie la gestion des erreurs a été supprimée
intentionnellement sans volonté de nuire mais plutôt pour des raisons de
performances donc c’est de nature intentionnelle.
❖ Par le moment de leur création :
Le calculateur d’Ariane 4 est repris tel quel sur Ariane 5 mais lors de
l’implémentation du code une partie de la gestion des erreurs a été supprimée
pour avoir une meilleure complexité du code alors qu'il ne fallait pas car l'erreur
fatale a été engendrée par cette partie et donc c’est une faute de développement
❖ Par leur rapport avec le produit :
L’erreur était dans le code donc c’est une faute interne
❖ Par rapport à leur persistance : Fautes permanente

5
3-Les leçons à tirer :

🡪Même si un programme a fait ses preuves (c’est-à-dire fonctionne sans jamais générer
d’erreur) au passé il est impératif de ne jamais le prendre comme tel si on veut
l’implémenter dans un nouvel environnement.

🡪Utilisé d’autre langage de programmation qui ne génère pas une telle erreur, ou bien au
minimum qui détecte de tel possibilité lors de sa compilation.

🡪Sollicité pas un ni deux, mais plutôt une équipe de testeur aguerri pour vérifier les
moindres petites erreurs d’inadvertance vu l’ampleur du projet.

🡪Faire des simulations d’exécution dans un environnement Controller avec des

prototype, pour faciliter la transition vers le modèle réel.

🡪Rajouter des mécanismes de protection et de redondance.

🡪Fournir des cahiers de charge claire et très spécifique qui ne laisse pas l’espace à la
confusion.

6
4-les modèles les mieux adaptés pour de tels projets :
Le cycle de vie de projet correspond à l'organisation des phases et des tâches de la
réalisation des produits. Il dépend de l'industrie et des métiers pour lesquels la gestion de
projets est appliquée ainsi que des procédés de production choisis.
On a l'embarra du choix pour le choix du modèle, bien sûr avec des uns mieux que
d’autre :
4.1. Cycle en V :

Le cycle en V est un modèle d'organisation des activités d'un projet qui se caractérise par
un flux d'activité descendant qui détaille le produit jusqu'à sa réalisation, et un flux
ascendant, qui assemble le produit en vérifiant sa qualité. Ce modèle est issu du modèle
en cascade dont il reprend l'approche séquentielle et linéaire de phases.
Il l'enrichit cependant d'activités d'intégration de système à partir de composants plus
élémentaires, et il met en regard chaque phase de production successive avec sa phase de
validation correspondante, lui conférant ainsi la forme d'un V.

7
4.2. Modèle en cascade :

Le modèle en cascade est le prédécesseur du cycle en V, il correspond à un découpage

linéaire et séquentiel d'un projet. La succession des étapes répond à une logique de
spécialisation des tâches

4.3 Le modèle à éviter :

Les modèles agiles, dans ce modèle le découpage des phases se fait par version
successives du produit contrairement au cycle en V et le modèle en cascade, ce qui a
donné lieu à des cycles de vie itératifs et incrémentaux.
Donc ce modèle n’est pas du tout approprié à notre cas.

8
5.ANNEX :
-toutes les questions du sujet sont proposées par Mr Youcef Hammel, Pour plus de détails
veuillez le contacter.

-Plus d’information à propos de Ariane 5 :

https://fr.wikipedia.org/wiki/Ariane_5

http://igm.univ-mlv.fr/~dr/XPOSE2002/Site_Vaubourg_Stephane_IR3/doc/esa-x-1
819eng.pdf
https://cordis.europa.eu/article/id/19509-ariane-5-explosion-caused-by-fault-in-ma
in-engine-cooling-system/fr

-le code en question qui a causé la défaillance :

https://hownot2code.com/2016/09/02/a-space-error-370-million-for-an-integer-ove
rflow/

-Gestion de Projet (cycle de vie) :

https://fr.wikipedia.org/wiki/Gestion_de_projet#Cycles_de_vie_de_projet

-cycle en V :
https://fr.wikipedia.org/wiki/Cycle_en_V

-Modèle en cascade :
https://fr.wikipedia.org/wiki/Mod%C3%A8le_en_cascade