Logiciel critique
Un logiciel critique est un logiciel dont l'éventuel mauvais fonctionnement aurait un impact important sur la sécurité ou la vie des personnes, des entreprises ou des biens.
Sont par exemples critiques les logiciels de pilotage des avions, des trains, des centrales nucléaires.
Niveaux de criticité
Il existe différents niveaux de criticité d'un logiciel, 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 dysfonctionnement augmentant la charge de travail et les risques d'erreur de pilotage des opérateurs humains.
En aviation, la norme DO-178B sépare les logiciels avioniques en 5 catégories :
- Niveau A : un dysfonctionnement du logiciel provoquerait ou contribuerait à une condition de perte catastrophique de l'appareil
- Niveau B : un dysfonctionnement du logiciel provoquerait ou contribuerait à une condition dangereuse ou un dysfonctionnement sévère et majeur de l'appareil
- Niveau C: un dysfonctionnement du logiciel provoquerait ou contribuerait à un dysfonctionnement majeur de l'appareil
- Niveau D: un dysfonctionnement du logiciel provoquerait ou contribuerait à un dysfonctionnement mineur de l'appareil
- Niveau E: aucun impact sur le fonctionnement de l'appareil ou la charge de travail du pilote.
Contraintes particulières de développement
Les précautions à prendre dans le développement d'un logiciel critique 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 l'implémentation 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.
Les systèmes les plus critiques sont généralement soumis à des autorités de certification, qui vérifient que les impératifs prévus par la norme ont été remplis.
L'usage de méthodes formelles pourra, à l'avenir, être encouragé, voire imposé.