10 conseils pour alléger vos analyses des risques

Par Guillaume Promé
le
19 Juil. 2021 Risques et B/R

Les analyses des risques des fabricants ont, trop souvent, beaucoup trop de lignes. Et pas assez de colonnes, mais c’est un autre sujet.

Cet article vous livre 🔟 conseils pour réduire la voilure, en se concentrant sur les risques dont l’analyse apporte un réel intérêt en matière de sécurité, au delà le l’abatage réglementaire.

👉 Voir également le modèle Qualitiso d’analyse des risques (format google sheets)


astuces pour l'analyse des risques

Dix points à surveiller dans vos analyses des risques

  1. Analyser les risques délirants relève du délire

    Le risque zéro n’existe pas : un risque de probabilité nulle est un dommage impossible, un risque de dommage nul est un événement insignifiant.

    Il ne sert à rien de développer l’analyse des risques que vous jugez impossibles compte tenu de votre contexte et des preuves disponibles.

    Au besoin, il est conseillé de faire une “pré analyse des risques”, un premier brainstorming d’où ne sortiront que les risques plausibles, pour être traités dans le processus de gestion des risques.

  2. La réglementation est une arme de réduction massive

    Des mesures de maitrise concrètes vous sont dictées par la réglementation, notamment en matière d’informations fournies.

    Ces mesures sont des obligations légales, vous n’avez pas d’autres choix que de les respecter : cela ne sert à rien de le justifier dans votre analyse des risques.

    Il est conseillé d’identifier ces exigences dans votre dossier de gestion des risques, éventuellement d’en rappeler l’intérêt en termes de maitrise et l’analyse s’arrête là : ces mesures sont efficaces, les risques résiduels sont extrêmement faibles.

  3. Les normes sont des armes de réduction massive

    C’est surement la plus grosse source de risques-à-ne-pas-analyser : les normes applicables sont de véritables “manuels pour réduire les risques”, surtout si elles traitent des performances d’un produit.

    Vous devez respecter ces standards, la plupart du temps un tiers va vérifier la conformité, souvent un laboratoire qui va tester biocompatibilité, la sécurité électrique, compatibilité électromagnétique…

    Autant de mesures de maitrise définies et validées selon l’état de l’art : inutile de vous poser trop de questions, inutiles de développer les analyses.

    Comme pour les exigences réglementaires : la conformité aux normes est identifiée dans le dossier de gestion des risques, cela suffit pour justifier que les risques associés sont maitrisés.

    Attention : les labos ne font pas tout le travail, ils utilisent votre dossier de gestion des risques (dont l’analyse) pour comprendre le contexte.

  4. Les normes vous en font trop faire

    Les normes, leurs annexes et leurs guides proposent des checklists pour l’identification des risques. Elles sont prévues pour répondre à des contextes très variés, beaucoup trop variés pour vous.

    Il est conseillé d’alléger ces listes avant utilisation, en retirant tout ce qui ne concerne pas vos projets.

  5. Vos ingénieurs sont ingénieux

    Votre analyse repose sur des données d’entrée, dont des exigences de sécurité formulées en conception.

    Le bureau d’étude va naturellement intégrer la notion de risque à la conception du produit, avec des exigences en matière de sécurité qui n’ont pas besoin d’une analyse des risques pour être formulées et dont l’efficacité est déjà confirmée par l’état de l’art.

    Au besoin, vous pouvez confirmer que les mesures imaginées en conception sont efficaces en analysant le risque initial qui inclue la mesure de maitrise (pas la peine de dérouler la maitrise  : il est déjà réduit par conception, c’est le top).

  6. L’analyse des risques médicaux n’est pas une AMDEC

    C’est un réflexe d’ingénieur : appliquer la méthode AMDEC à l’analyse des risques médicaux.


    Cette méthode permet d’identifier les risques techniques par analyse des défaillances. Et ces défaillances sont potentiellement très nombreuses.

    Il est conseillé de faire une AMDEC technique uniquement au bureau d’étude.

    En données de sortie de l’AMDEC : les risques significatifs sont regroupés autant que possible, ces regroupements sont injectés dans l’analyse des risques pour une évaluation “médicale”, au-delà du technique.

  7. Trop de 62304 tue la 14971

    La sur-identification est un travers des DM logiciels qui sont soumis à la norme IEC 62304 qui demande de faire l’analyse des risques associés à tous les éléments logiciels pour déterminer la classe de sécurité du soft.
    Et un logiciel compte beaucoup d’éléments.

    Inutile d’injecter toutes ces identifications dans l’analyse des risques, ici aussi on procédera “par paquets”.

    Il est conseillé d’évaluer la classe du logiciel indépendamment de l’ADR, l’analyse est alors simplifiée (la 62304 classe les logiciels en fonction des dommages associés aux bugs, avec P=100%).

    Vous pouvez vous contenter de reporter des gros blocs dans votre analyse : indépendamment de la cause du danger, ils sont unis par la situation, les dommages et la mesure de maitrise : la mise en œuvre de la 62304 à une classe donnée.

  8. Concentrez-vous sur le pire

    Autre problème : analyser toutes les variantes possibles d’un risque : selon l’utilisateur, la finalité, l’environnement…

    Il est conseillé d’avoir une approche par le pire cas : pour un même risque  on analysera le pire cas, son acceptabilité vaudra pour les autres.

  9. Vous n’êtes pas un justicier

    Vos analyses doivent inclure les erreurs d’utilisations, mais les mauvais usages intentionnels sont à exclure.

    Aussi, tout ce qui est sabotage, utilisation détournés, non-respect volontaire des conditions d’utilisations… est à retirer de vos analyses. Attention : la cybersécurité est un cas particulier : les attaquants étant des robots le risque devient probable, il ne doit pas être négligé.

  10. Vous êtes juge

    En résumé, vous devez juger si les risques méritent d’être injectés dans vos analyses, selon les besoins pour la démonstration de sécurité et en excluant les points déjà traités dans le reste de votre documentation technique.