Ingénieur en sécurité fonctionnelle : entretien avec Tomasz Łokietek

Dans ce volet de notre ‘Spyrosoft Peoplesérie, nous nous entretenons avec Tomasz Lokietek, ingénieur en sécurité fonctionnelle.

Que fait un ingénieur en sécurité fonctionnelle ?

Selon la taille de l'entreprise, du projet et du flux de travail, les entreprises créent le rôle d'Ingénieur en Sécurité Fonctionnelle pour soutenir le processus de développement produit. Une personne ayant déjà participé à la conception d'architectures matérielles/logicielles/systèmes peut également être nommée et chargée de responsabilités supplémentaires en matière de sécurité fonctionnelle. La sécurité fonctionnelle est importante pour tous ces domaines et couvre tous les éléments du cycle de vie du produit – de l'idée initiale jusqu'au rebut du produit final. L'ingénieur en sécurité fonctionnelle aura des responsabilités différentes selon le domaine auquel il est affecté, et il aura également différentes tâches à accomplir.

Si nous nous limitons au développement logiciel, l'ingénieur en sécurité fonctionnelle doit s'assurer que les exigences en matière de sécurité des produits sont en place. Souvent, il est également en mesure d'expliquer le concept de sécurité aux autres membres de l'équipe et de veiller à ce que les exigences de sécurité soient non seulement mises en œuvre, mais aussi cohérentes avec la manière dont les ingénieurs système les ont définies au niveau du système. L'ingénieur en sécurité joue également le rôle de consultant qui aide à trouver une solution pour aligner les processus sur les exigences de sécurité. Il veille aussi à ce que ces processus ne nuisent pas à l'achèvement du projet. Le plus souvent, cela est obtenu en sélectionnant les éléments et les exigences les plus cruciaux dans le processus de sécurité fonctionnelle.

En ce qui concerne le logiciel lui-même, l'ingénieur en sécurité fonctionnelle vérifie les composants, les éléments et la documentation liés à la sécurité. Ils réalisent également des analyses de sécurité : ils vérifient les solutions proposées par les architectes logiciels au regard des exigences de sécurité du système existant et déterminent si ces solutions peuvent être mises en œuvre conformément aux exigences. Ils s'assurent aussi que les solutions n'allongent pas la liste actuelle des risques produit.

Ils accompagnent également les développeurs dans la définition des directives de codage. Lorsque l'équipe souhaite déroger au processus, ils rédigent des explications justifiant la nécessité de la dérogation et démontrant qu'elle reste sûre.

Une autre tâche consiste à analyser tout document externe provenant de nos fournisseurs. Avant d'ajouter un nouveau composant ou une bibliothèque, nous devons vérifier si ces éléments peuvent avoir un impact sur la sécurité du produit. Nous devons estimer le degré de cet impact, en particulier s'il est négatif, et ce que nous pourrions faire pour garantir que le produit reste sûr après l'ajout de ce nouvel élément. Nous nous trouvons souvent dans une situation où nos clients proposent des solutions qui peuvent ne pas être sûres ; nous les informons donc des risques liés à l'utilisation de ces solutions (c'est-à-dire ne pas obtenir une certification, ne pas mener à bien un audit, la dette technologique).

Une grande partie du rôle de chaque ingénieur en sécurité fonctionnelle consiste à analyser les outils. Si nous souhaitons intégrer un certain outil dans le processus de développement produit ou dans la mise en œuvre d'un élément critique pour la sécurité, cet outil doit être sûr, ce qui signifie qu'il ne comporte aucune erreur susceptible d'affecter négativement la qualité du produit final.

Ingénieur en sécurité fonctionnelle vs Responsable en sécurité fonctionnelle

Un Functional Safety Manager prend en charge toutes les tâches que j'ai mentionnées ci-dessus, ainsi que tout aspect lié à l'introduction et à la promotion de ce que l'on appelle la culture de sécurité au sein d'une organisation. L'un des éléments clés de la culture de sécurité consiste à ne pas chercher un responsable lorsque des incidents se produisent.

Au contraire, les efforts de l'équipe doivent être concentrés sur la recherche d'une solution. Cette approche garantit un environnement confortable et sain où il est possible pour les membres de l'équipe de signaler leurs propres erreurs ou de mettre en évidence les risques du projet. L'objectif ultime n'est pas de chercher des boucs émissaires, mais plutôt de livrer un produit sûr.

Un responsable de la sécurité fonctionnelle est une personne profondément impliquée dans la définition des processus de sécurité au sein d'une organisation et qui établit en permanence les critères pour des produits et des processus de production de qualité. Sa priorité est de garantir la sécurité du produit.

Ils sont également responsables de la préparation d'un document très important : le dossier de sécurité. Un dossier de sécurité comprend des exemples démontrant que nous avons réalisé notre travail conformément aux processus de sécurité définis au sein de l'organisation et collectés tout au long du processus de développement du produit. Il est également essentiel pour déclarer que notre produit est sûr.

Comment avez-vous débuté dans la sécurité fonctionnelle ?

Il s'agissait d'une décision réfléchie, fondée sur l'opportunité qui m'a été offerte. J'ai obtenu mon diplôme en électronique à l'Université Technique et, au début, j'étais responsable des tests de produits à l'aide de machines automatiques dans l'une des entreprises automobiles de Wroclaw, en Pologne. J'ai ensuite rejoint leur département de Recherche & Développement, où je travaillais au développement de dispositifs électroniques pour automobiles. L'un des projets auxquels j'ai participé portait sur les tests des systèmes d'assistance au freinage. J'ai pu constater comment les tests pouvaient fonctionner dans le contexte des normes de sécurité, de l'estimation des risques et de la vérification des fonctions critiques. Je suis ensuite devenu Directeur mondial de la vérification et de la validation des produits électroniques, toujours centré sur le matériel. Mon rôle suivant a porté sur les tests et la sécurité au sein d'une entreprise de développement logiciel, et c'est ainsi que je me suis orienté vers le logiciel.

Quelle est votre approche pour les projets entièrement nouveaux ? Qu'est-ce qui attire votre attention ?

Dans la phase initiale, je me concentre toujours sur les domaines qui doivent être inclus dans le processus de développement logiciel. Pour chaque projet, il faut repasser par cette étape, même s'il s'agit d'une nouvelle génération de logiciel ou d'une nouvelle variante. La première chose à accomplir est l'analyse de l'impact de ces modifications logicielles sur le produit. Sur cette base, je détermine ensuite si les changements étaient critiques pour la sécurité.

En règle générale, le sujet de la sécurité peut être divisé en deux catégories distinctes. La première est liée à la planification de la sécurité technique, où nous définissons ce qui doit se produire lorsqu'une des fonctions critiques qui assurent la sécurité de l'utilisateur cesse de fonctionner. La seconde catégorie renvoie au fait que même si votre idée initiale est phénoménale, si l'exécution fait défaut, le produit final ne fonctionnera pas correctement. Il s'agit de l'aspect processus de la sécurité des produits, fortement influencé par la Sécurité Fonctionnelle. Nous pouvons minimiser le besoin de ressources supplémentaires du processus en identifiant les points qui peuvent être ajustés, maintenus intacts ou ajoutés. Comprendre le processus de développement d'un produit et l'aligner sur les exigences de sécurité est souvent la clé pour limiter le nombre de ressources nécessaires à l'achèvement du projet. C'est également essentiel pour satisfaire l'ensemble des exigences de qualité en une seule fois.

Quel outil de sécurité utilisons-nous chez Spyrosoft ?

La vérité, c'est que vous n'avez besoin d'aucun outil pour les projets de sécurité. Vous pouvez tout préparer dans Excel ou Word, mais son exécution ne serait pas aussi agréable et fluide pour l'ingénieur sécurité et le reste de son équipe [rires].

Chez Spyrosoft, nous utilisons Ansys Medini, qui nous permet de réaliser un certain nombre d'analyses de sécurité, notamment les AMDEC/AMDEC et l'AFD. Nous pouvons également l'utiliser pour gérer une base de données de mécanismes de sécurité dans laquelle, pour chaque risque, nous devons également définir un mécanisme de sécurité. De plus, grâce à Medini, nous pouvons nous connecter à des outils de développement logiciel populaires, notamment PTC Integrity, DOORS et EnterpriseArchitect. Nous pouvons ensuite générer un rapport de dossier de sécurité.

Quel type de documentation et de processus une entreprise devrait-elle avoir en place avant de venir chez Spyrosoft avec un projet lié à la sécurité ?

Tout dépend de la maturité des processus de l'entreprise et de la maturité de la technologie qu'elle souhaite utiliser. Si nous voulons développer – disons – un contrôle de moteur à combustion ou l'électronique utilisée dans ce type de moteur, nous pouvons utiliser un modèle standard existant appelé I-GAS. Nous disposons également d'un modèle de sécurité défini. Si une voiture est suffisamment sûre pour circuler dans la circulation habituelle, alors elle est suffisamment sûre pour circuler dans un aéroport ou lors d'une exposition professionnelle.

Je demanderais également à leur équipe à quelle étape du processus de développement produit ils sont parvenus. S'ils sont encore en train de définir les exigences système, alors leurs exigences métier devraient suffire pour que nous commencions à concevoir l'architecture système et établissions donc une liste des exigences système.

Cependant, si nous intervenions en tant qu'équipe de support ou si nous étions responsables du développement du logiciel, nous aurions besoin que ce niveau système soit défini, avec une ébauche d'architecture, une documentation et une liste d'exigences système disponibles. Cela étant dit, nous avons également travaillé sur des projets où aucun de ces éléments n'existait et nous avons malgré tout pu apporter notre aide.