Système critique

Un système critique, en anglais safety-critical system ou life-critical system, « système vital pour la sécurité » ou « pour la survie », est un système dont la panne peut avoir des conséquences dramatiques, comme des morts ou des blessés graves, des dégâts matériels importants, ou des conséquences graves pour l'environnement. L'analyse des systèmes critiques ne se limite pas à celle que permet, aujourd'hui de plus en plus, l'informatique de contrôle des processus, fussent-ils mécaniques ou humains.

Domaines critiques

Dans le monde de l'informatique, les systèmes qualifiés de « critiques » se retrouvent par exemple dans :

les systèmes de transport : pilotage des avions, des trains, logiciels embarqués automobiles ;
la production d'énergie : contrôle des centrales nucléaires ;
la santé : chaînes de production de médicaments, appareil médicaux (à rayonnement ou contrôle de dosages) ;
le système financier : paiement électronique ;
les applications militaires.

En fait, par la diffusion généralisée des technologies à base d'informatique et donc de l'impact plus massif d'un défaut quelconque, la notion de criticité tend à se diffuser, même s'il s'agit plus souvent d'un risque de désorganisation sur les plans économique, social ou financier.

Niveaux de criticité

Évaluation

Il existe différents niveaux de criticité d'un système, suivant l'impact possible des dysfonctionnements. On apprécie ainsi différemment, par exemple, un dysfonctionnement provoquant des pertes coûteuses, mais sans mort d'homme (cas des missions spatiales non habitées) et un dysfonctionnement provoquant des morts dans le grand public (cas des vols commerciaux). De même, on apprécie différemment des dysfonctionnements faisant courir un danger de mort ou de blessure à des humains, ou des dysfonctionnements augmentant la charge de travail et les risques d'erreur de pilotage des opérateurs humains.

Conséquences sur la sécurité

La criticité du système définit un niveau d'exigence par rapport à la tolérance aux pannes. Elle aura des conséquences sur l'évaluation des niveaux d'assurance pour la sécurité.

Cas particulier de l'aviation

En aéronautique, le niveau de criticité d'un système critique est calculé pour chaque « événement redouté » (terme que l'on peut traduire de l'anglais failure condition^{[Note 1]}) du système. Il existe cinq niveaux, qui sont détaillés dans ARP4761A/ED-135^[1]. Pour chaque fonction que doit remplir ce système, les événements redoutés sont évalués en fonction de leur effet^[2] :

Le niveau CAT (catastrophique) : la survenue de l'événement redouté provoquerait ou contribuerait à une condition de perte catastrophique de l'aéronef, à de nombreuses morts de personnes.
Le niveau HAZ (hazardous, dangereux) : la survenue de l'événement redouté provoquerait ou contribuerait à une condition dangereuse ou un dysfonctionnement sévère de l'aéronef, à de multiple blessure grave ou à la mort d'un nombre limité de personnes.
Le niveau MAJ (major, majeur) : la survenue de l'événement redouté provoquerait ou contribuerait à un dysfonctionnement majeur de l'aéronef, ou à une surcharge importante d'activité du personnel navigant.
Le niveau MIN (minor, mineur) : la survenue de l'événement redouté provoquerait ou contribuerait à un dysfonctionnement mineur de l'aéronef.
Le niveau no effect (pas d'effet) : La survenue de l'événement redouté ne provoquerait ou ne contribuerait à aucun impact sécurité sur le fonctionnement de l'aéronef ou la charge de travail du pilote.

Ces niveaux se déclinent en deux types d'obligations : des obligations qui concernent la fiabilité et la tolérance aux pannes, d'une part, et des obligations au niveau de la qualité en développement, d'autre part^[2].

Fiabilité et la tolérance aux pannes

En ce qui concerne le niveau de fiabilité du système, le taux de panne toléré est donné suivant le niveau de l'événement redouté le plus élevé. Il est donné en nombre de panne par heure de vol (valeur bien inférieure à un). Dans la dernière colonne, cette valeur est mise sous forme de nombre d'heures de vol requis sans que la panne apparaisse (valeur statistique)^[2].

Niveau de l'événement redouté le plus élevé.	Taux de pannes toléré	Nombre d'heure de vol requis sans pannes
CAT	1 * 10 ^-9	1 000 000 000 heures de vol
HAZ	1 * 10 ^-7	10 000 000 heures de vol
MAJ	1 * 10 ^-5	100 000 heures de vol
MIN	1 * 10 ^-3	1 000 heures de vol
No Effect	Non spécifié	Non spécifié

Pour obtenir ces valeurs de fiabilité, les systèmes sont souvent constitués de composants (ou items) redondants et indépendants pour les systèmes supportant les événements redoutés les plus élevés.

Niveau qualité en développements

En ce qui concerne le second point, la norme ARP4754/ED-79 sépare les systèmes avioniques en 5 catégories de DAL (Design Assurance Level, en anglais)^[2] :


Niveau de l'événement redouté le plus élevé.	DAL associé.
CAT	A
HAZ	B
MAJ	C
MIN	D
No Effect	E

Cette norme identifie, en fonction du niveau de sécurité requis pour le système (appelé le FDAL, pour Functionnal Design Assurance Level, en anglais) et en fonction de l'architecture du système (simplex, redondant, dissymétriques ...), pour les items organiques du système, les niveaux nécessaires pour chacun deux (appelé le IDAL, pour Item Design Assurance Level, en anglais), en suivant les normes spécifiques : DO-178/ED-12 pour les logiciels, DO-254/ED-80 pour le matériel (hardware, en anglais)^[3].

Logiciel critique

Définition, enjeux

Un logiciel critique est un logiciel dont le mauvais fonctionnement aurait un impact important sur la sécurité ou la vie des personnes, des entreprises ou des biens.

L'ingénierie logicielle pour les systèmes critiques est particulièrement difficile, dès lors que les systèmes sont complexes, mais l'industrie aéronautique, ou plus généralement l'industrie du transport de passagers, a réussi à définir des méthodes pour réaliser des logiciels critiques. Des méthodes formelles peuvent servir à améliorer la qualité du logiciel des systèmes critiques. Le coût de réalisation d'un logiciel de « système critique » est beaucoup plus élevé que celui d'un logiciel ordinaire.

Contraintes particulières de développement

Les précautions à prendre dans le développement sont généralement fixées par une norme, et dépendent du domaine d'application et surtout de la criticité du logiciel. Généralement, on trouve des impératifs :

de documentation : tous les composants doivent être documentés, notamment dans l'interface qu'ils présentent aux autres composants ;
de traçabilité : le système doit répondre à chaque spécification, soit dans sa mise en œuvre, soit dans des spécifications intermédiaires (auquel il faudra aussi répondre) ; on doit donc avoir une chaîne complète de traçabilité entre les spécifications fonctionnelles et la mise en œuvre du système ;
de limitation des pratiques dangereuses : certaines techniques de programmations, sources possibles de problèmes, sont interdites, ou du moins leur usage doit être justifié par des raisons impératives (ex. : allocation dynamique de mémoire, procédures récursives) ;
de test : on devra essayer le logiciel dans un grand nombre de configurations, qui couvrent tous les points et un maximum des chemins de fonctionnement du programme ;
d'utilisation d'outils de développement et de vérification eux-mêmes sûrs.

Contraintes d'exploitation

La mise en œuvre de systèmes critiques implique une adaptation de l'architecture physique dans une optique de fiabilité et de sécurisation. L'architecture doit répondre aux risques identifiés.

La fiabilité passe par un plan de continuité d'activité et des infrastructures adaptées. Des exemples de mesure sont :

redondance des systèmes ;
durcissement des équipements.

La sécurité peut être renforcée par :

l'emploi de systèmes d'authentification forte,
l'isolation des systèmes critiques, par l'usage d'une architecture VPN, voire « air gap »,
la protection physique des équipements (bâtiments sécurisés, contrôle des accès physiques...).

Certification

Les systèmes les plus critiques sont majoritairement soumis à des autorités de certification, qui vérifient que les impératifs prévus par la norme ont été remplis.

Dans le cas de l'aviation commerciale, la certification des aéronefs est régie en Europe par les réglementations CS-23 Normal, Utility, Aerobatic and Commuter Aeroplanes, CS-25 Large Aeroplanes, CS-27 Small Rotorcraft, CS-29 Large Rotorcraft de l'EASA^[4], ou de leurs équivalents américains, 14 CFR Parts 23^[5], 25^[6], 27^[7] et 29^[8], de la FAA.

Notes et références

Notes

↑ Sur cette page, nous associons le terme « événement redouté » à « failure condition », en accord avec la pratique du milieu.

Références

↑ (en-US) SAE International, « ARP4761A - Guidelines for Conducting the Safety Assessment Process on Civil Aircraft, Systems, and Equipment » [PDF], sur sae.org, 20 décembre 2023 (consulté le 1^er février 2026)
1 2 3 4 Marc Gatti, « Évolution des Architectures des Systèmes Avioniques Embarqués » [PDF], sur theses.hal.science, 1^er décembre 2017 (consulté le 1^er février 2026), p. 92-94
↑ SAE/EUROCAE, « ARP4754B - Guidelines for Development of Civil Aircraft and Systems » , sur www.sae.org, 20 décembre 2023 (consulté le 20 octobre 2025)
↑ (en) EASA, « Certification Specifications (CSs) / Detailed Specifications (DSs) » , sur easa.europa.eu (consulté le 1^er février 2026)
↑ (en) FAA, « 14 CFR Part 23 -- Airworthiness Standards: Normal Category Airplanes » , sur ecfr.gov (consulté le 1^er février 2026)
↑ (en) FAA, « 14 CFR Part 25 -- Airworthiness Standards: Transport Category Airplanes » , sur ecfr.gov (consulté le 1^er février 2026)
↑ (en) FAA, « 14 CFR Part 27 -- Airworthiness Standards: Normal Category Rotorcraft » , sur ecfr.gov (consulté le 1^er février 2026)
↑ (en) FAA, « 14 CFR Part 29 -- Airworthiness Standards: Transport Category Rotorcraft » , sur ecfr.gov (consulté le 1^er février 2026)

Voir aussi

Sûreté de fonctionnement
Profil d'application
Analyse décisionnelle des systèmes complexes (méthode de conception de systèmes critiques)
Capella - atelier de modélisation des architectures système, logicielles et matérielles

Bibliographie

Portail de la sécurité des systèmes d'information
Portail de la sécurité de l’information

[1] Sur cette page, nous associons le terme « événement redouté » à « failure condition », en accord avec la pratique du milieu.

[2] (en-US) SAE International, « ARP4761A - Guidelines for Conducting the Safety Assessment Process on Civil Aircraft, Systems, and Equipment » [PDF], sur sae.org, 20 décembre 2023 (consulté le 1^er février 2026)

[:0-3] 1 2 3 4 Marc Gatti, « Évolution des Architectures des Systèmes Avioniques Embarqués » [PDF], sur theses.hal.science, 1^er décembre 2017 (consulté le 1^er février 2026), p. 92-94

[4] SAE/EUROCAE, « ARP4754B - Guidelines for Development of Civil Aircraft and Systems » , sur www.sae.org, 20 décembre 2023 (consulté le 20 octobre 2025)

[5] (en) EASA, « Certification Specifications (CSs) / Detailed Specifications (DSs) » , sur easa.europa.eu (consulté le 1^er février 2026)

[6] (en) FAA, « 14 CFR Part 23 -- Airworthiness Standards: Normal Category Airplanes » , sur ecfr.gov (consulté le 1^er février 2026)

[7] (en) FAA, « 14 CFR Part 25 -- Airworthiness Standards: Transport Category Airplanes » , sur ecfr.gov (consulté le 1^er février 2026)

[8] (en) FAA, « 14 CFR Part 27 -- Airworthiness Standards: Normal Category Rotorcraft » , sur ecfr.gov (consulté le 1^er février 2026)

[9] (en) FAA, « 14 CFR Part 29 -- Airworthiness Standards: Transport Category Rotorcraft » , sur ecfr.gov (consulté le 1^er février 2026)

[Note 1]

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]