La Sécurité de Fonctionnement (SdF): définition, explication et exemple. Correspondant à la notion « Safety » en Anglais, il s’agit de l’ensemble des dispositions assurant que votre Système ne se dégrade pas ni ne blesse ses utilisateurs, à la suite de dysfonctionnements involontaires. Voici quelques méthodes simples pour sécuriser un Produit.
Sécurité, Sûreté, Fiabilité, Résilience… Ces 4 mots ne désignent en fait pas les mêmes notions. Et la différence est importante lors de la conception de votre produit car les objectifs et méthodes sont différents. Je traite dans cet article de la notion de Sécurité Système, et j'aborde la sécurisation d'un Système avec les méthodes simples de l'état de l'art.
La Sécurité est la lutte contre les dysfonctionnements involontaires d’un Système.
C'est le "S" de FMDS (ou RAMS, en Anglais).
Il s’agit, lors de la conception d’un Produit (et/ou son opération et/ou sa maintenance) :
Un Risque correspond à toute condition qui viendrait à produire au sein du Système une situation dysfonctionnelle amenant à :
Un Produit sécurisé, c’est un Produit qui se révèle au final pratique, robuste et sans danger à produire, utiliser, maintenir et retirer du service.
Cela influe directement sur le coût d’exploitation de ce Produit, son efficacité à l’utilisation, sa Disponibilité, et… le nombre de procès auxquels vous serez conviés.
Maîtriser les Risques de votre Produit, c’est maîtriser vos coûts.
Les dysfonctionnements peuvent provenir du moindre élément non maîtrisé au sein de votre Produit, qu’il soit Logiciel, Électronique ou Mécanique.
Exemple de dysfonctionnements involontaires :
Avoir une connaissance poussée de son Système en cours de conception via l’application d’une méthode d’Ingénierie Systèmes est un bon début. En effet, documenter le Système sous la forme de listes d’exigences, de schémas d’architectures et autres représentations & modèles permet déjà de se faire une bonne idée de son fonctionnement et ainsi d’identifier par anticipation ses potentiels défauts et ce qui pourrait se produire de manière non souhaitée.
Une fois les Risques repérés grâce à vos schémas, il s’agit d'en tirer des exigences supplémentaires, à ajouter aux précédentes, afin de mettre en place petit à petit dans notre futur Systèmes les barrières qui viendront empêcher le Risque ou bien réduire ses conséquences à un niveau acceptable.
Vous l'aurez compris, la Sécurité doit faire partie intégrante de la Spécification, Conception et du Développement de son Système. Rajouter des éléments supplémentaires de sécurisation à la fin de sa conception est souvent inefficace et va mettre à mal tout l’effort de conception et d’esthétique de votre Produit. Il faudra souvent reboucler la conception pour insérer votre barrière, et c'est alors un allongement du temps Projet.
Exemples de sécurisations qui arrivent trop tard dans la conception du Produit :
En plus d'avoir un Produit qui va sembler un peu bancal, arranger son Produit sur la fin du projet va aussi coûter très cher.
Si vous savez déjà générer, gérer des exigences et leurs tests de vérification, alors vous n’aurez pas de mal à en ajouter quelques-unes qui vous garantiront un système safe, en tenant compte de toutes ses phases de vie.
Exemples de sécurisations arrivées au bon moment (lors de la conception) :
Tout ceci a bien été pensé lors des phases de Spécifications, Conception et Développement du Système. Il n’est pas possible (simplement) une fois le Système produit en série de rajouter une pièce mécanique, un composant électronique, ou de modifier profondément le logiciel. Le système doit être « Safe by design ».
L’ingénieur Systèmes, avec sa vision transverse et holistique du Système, a un rôle essentiel à jouer dans l’identification et la mitigation des Risques.
Il y a plusieurs moyens d'arriver à sécuriser son Système. Voici ci-dessous les méthodologies à exploiter. Il s'agit du « minimum syndical » (méthodes simples) de la conception Produit. Un autre article suivra pour les méthodes avancées.
C’est essentiel pour y voir clair sur le Système qu’on développe (cf. ci-dessus). Et je dirais qu’y voir clair, sur tout le cycle de vie du Produit, c’est déjà 60% du travail de Sécurité qui est fait.
En effet, avoir le « Produit » sous les yeux (sous ses différentes représentations) permet de mieux se rendre compte de ce qui pourrait mal se passer et de prendre les dispositions adéquates (rajouter un composant software de surveillance du fonctionnement, chanfreiner les bords tranchants, …).
Exemples de représentations de votre Produit :
Évidemment, toutes ces représentations, listes et autres schémas seront très flous et incomplets au début de votre conception. Qu'importe : ils représenteront déjà de précieuses informations sur votre futur Produit et le fonctionnement que vous envisagez pour lui. Cela vous permettra de vous rendre compte de certains risques, et de prendre vos premières décisions de sécurisation du Système.
A mesure que vous avancerez dans le Projet, certaines zones d'ombre s'éclairciront et vous pourrez ajouter les barrières pertinentes pour contrer les Risques que vous verrez apparaitre.
Astuce : faites relire les exigences et vos schémas d’architecture par une autre personne que celle qui les a rédigées et dessinés. Le point de vue extérieur aidera grandement pour détecter les Risques.
Il faut rechercher les textes qui sont pertinents pour votre Produit et qui offrent des guidelines pour le sécuriser :
NOTA : certains de ces textes, en plus d’être pertinents, seront obligatoirement à respecter pour mettre votre Produit sur le marché… Il ne s’agit pas que d’une aide à la conception.
Exemple de textes :
Ces textes donnent généralement des exigences que vous pouvez insérer plus ou moins directement dans vos Spécifications Systèmes (exigences de design), ou qui vont vous donner des étapes à respecter dans votre processus de conception (exigences de process).
Exemple d’exigences que vous pouvez y retrouver :
Vous noterez que pour le 1er exemple (taux de défaillance), la prise en compte n’est pas directe. Un vrai travail doit ensuite suivre pendant la conception et le développement du Produit pour s’assurer qu’on comprenne bien ce que cela implique et qu’on fasse les bons choix de design. Qu'est ce qu'on entend par défaillance ? Par quoi sont-elles provoquées ? Comment limiter leur occurrence ?
AMDEC : Analyse des Modes de Défaillances, de leurs Effets et de leurs Causes. En Anglais, FMECA : Failure Mode Effects and Causes Analysis. C'est un incontournable des méthodes de sécurisation de son Système.
Une fois votre liste d’exigences constituant la Spécification Système complète , analysez chaque exigence (Fonction du Produit dans le tableau ci-dessus) et déterminez si un risque existe (on parle d’évènement redouté, ou de Mode de Défaillance dans le tableau ci-dessus) et a besoin d’une barrière spécifique (Action préventive dans le tableau ci-dessus). Faites autant de lignes à votre tableau que nécessaire.
Exemple de questions à se poser pour chaque exigence pour identifier le mode de défaillance :
Pour chacun de ces évènements redoutés déduits, déterminez ensuite sa cause, sa conséquence (ou Effet selon le tableau ci-dessus) et notez ce risque via 3 critères :
Ci-dessus une échelle de notation pour les 3 critères. Pour ma part, je préfère limiter la note à 4 pour chaque critère. Cela oblige à faire pencher la balance du côté + ou du côté -, sans possibilité de mettre une note "neutre" sur les critères.
La criticité vient apporter la note finale de chaque risque :
Criticité = Non détectabilité * Probabilité * Gravité
A ce stade, vous avez identifié vos risques et déduit de manière quantitative leur Criticité. Que faire ?
Ci-dessus un exemple d'échelle de criticité vous permettant de savoir quand une barrière (Action) est nécessaire pour mitiger ou supprimer votre risque :
Vous pouvez tout à fait redéfinir cette échelle de niveaux acceptables pour les risques. En effet, cela dépend de l’application de votre Produit. Si c’est un Système militaire, l’acceptabilité du risque est généralement sévère et il y a une plus grande part de cases rouges. Des normes peuvent aider à la définition de cette échelle en associant un niveau d'Assurance Level a votre produit ou ses composantes (DAL, SWAL, SIL...).
Si un risque de votre liste quantifiée dépasse le niveau de criticité limite que vous avez décidé, il faut trouver une barrière de sécurisation et la mettre en place.
Pour trouver une barrière, vous pouvez jouer sur :
On peut combiner plusieurs barrières pour faire diminuer la criticité d'un évènement redouté sous une valeur acceptable.
Pour valider que les barrières envisagées sont bien suffisantes, refaite une notation des 3 critères en tenant compte de votre barrière ajoutée au Système, et voyez si la Criticité est effectivement passée sous le niveau limite que vous vous êtes défini. Si oui, c'est gagné ! Si non, réfléchissez encore à vos barrières...
Ajoutez enfin ces barrières déduites, sous la forme d’exigences, dans votre spécification pour la compléter.
Exemples de barrières devenant exigences :
* Et oui, la sécurisation d'un Système peut aussi donner des exigences qui ne portent pas sur le Système lui-même !
A ce stade, vous avez appliqué 3 méthodologies pour sécuriser votre Système, et vous avez donc :
Le travail n'est pas pour autant terminé !
A partir de ce moment-là, vous pouvez procéder aux déclinaisons d’exigences typiques de la descente du Cycle en V (ou de la méthode projet hybride que je propose).
Néanmoins, les exigences de Sécurité revêtant une importance particulière (car protègent des défaillances Système et notamment des défaillances pouvant blesser les utilisateurs…) il faut veiller à les taguer comme tel. La mention [SECURITE] dans l’intitulé de l’exigence peut suffire.
Et lors de la déclinaison, toutes les exigences issues d’une exigence [SECURITE] doivent hériter de ce tag. Cela permettra à vos collègues développant le logiciel, la mécanique et l’électronique de savoir que cette exigence est critique et nécessite donc d’être particulièrement soignée dans sa réalisation.
En plus du logiciel, de l’électronique et de la mécanique, on peut aussi voir ces exigences déclinées jusqu’à impacter des procédures d’utilisation (le manuel utilisateur par exemple, ou l'affiche sur la machine de cisaille guillotine - cf. ci-dessus), des procédures de fabrication du produit, ou bien faire apparaitre un besoin de formation spécifique du client lorsqu’il recevra son système. Les exigences de sécurité ne vont pas forcément porter seulement sur le Produit lui-même !
La priorité est la suivante (par ordre décroissant) :
On retrouve bien l’ordre logique et naturel pour éviter un problème :
On peut tout à fait choisir de cumuler les barrières pour faire "Ceinture-Bretelles". On peut cumuler des dispositions sur :
Lors des phases d’Intégration, Vérification, Validation et Qualification de votre Produit (IVVQ), vous avez bien travaillé et disposez d’une liste d’exigences de Sécurité avec le Plan de Test qui va en face.
Les exigences taguées [SECURITE] doivent évidemment être vérifiées à la fin du développement du produit, comme toutes les autres exigences.
On peut, comme pour tout le reste des exigences, procéder de la sorte pour se convaincre que l’exigence est bien atteinte par le Produit (méthode au choix) :
La Sécurité doit être partie intégrante de la démarche d’Ingénierie Systèmes.
La Sécurité d’un Système doit se penser dès le début si on veut que les barrières mises en place soient réellement efficaces, et à coût maîtrisé. Sinon, on va au-devant de mauvaises surprises et le Système sera bancal et dangereux. Les performances fonctionnelles d’un Produit se pensent dès le début (lors du Besoin, Spécification, Conception) et c’est normal. La Sécurité doit être considérée comme une performance du Système. X jours sans pb, X jours sans victimes... c’est une performance !
Il n’y a pas de magie : une grande part de la sécurisation d’un Système tient dans le fait de suivre un processus clair, rigoureux et systématique lors de la conception, du développement, et de la validation. Processus dans lequel vont intervenir des méthodes particulières que l’ingénieur en charge de la Sécurité peut utiliser de manière plus ou moins poussée. Il n’y a pas de façon générique et automatique de faire, pas d’outil adaptable à toutes les situations.
Je termine sur cette citation :
"If you think good design is expensive, you should look at the cost of bad design." — Dr. Ralf Speth
Aurélien NARDINI
Un Système Sans Problème est une ressource de connaissances et de savoir-faire pratiques, avec exemples concrets.
Que vous soyez Chef de Programme, Chef de Projet, Architecte Système, Ingénieur, Manager dans l'Industrie, Etudiant ou Curieux de l'Ingénierie, vous êtes au bon endroit.
Au travers d'articles publiés régulièrement, découvrez ou révisez les Processus, Méthodes, Outils et Astuces utiles pour concevoir et piloter dans les domaines du Software, Firmware, de l’Électronique, et de la Mécanique.
Parce-qu'un produit fiable et industrialisable ne s'improvise pas !
