Skip to content

Jean-Pierre SIGNORET raconte la génèse de GRIF 

Il manie la logique mathématique avec passion et amour du travail bien fait. Figure incontournable des sciences de l’ingénierie fiabiliste, Jean-Pierre SIGNORET continue de transmettre avec la même fougue ses connaissances au travers de ses ouvrages, colloques, formations… mais aussi de son parcours. Clé de voûte dans la conception de la suite logicielle GRIF, il nous raconte les coulisses de son histoire singulière.  

Propos recueillis par Emmanuelle LOURIA

edito_1_colomn_event_club_grif_3.png

Dans quel contexte êtes-vous arrivé chez TotalEnergies ? 

Je suis arrivé chez Total (aujourd’hui TotalEnergies) en rejoignant Elf en 1981, après avoir travaillé 10 ans au Commissariat à l’énergie atomique (CEA), au sein du bureau d’Études probabilistes de Sûreté (devenu IPSN et aujourd’hui l’IRSN – l’Institut de Radioprotection et de Sûreté Nucléaire -). 

À cette époque, le CEA réalisait des études prédictives et préventives uniquement sur les installations nucléaires (usines, sous-marins etc.). Notre mission principale consistait à évaluer la probabilité d’accidents dans les centrales en mettant en application des techniques comme les arbres de défaillances et arbres d’événements. Afin de rester pessimiste au niveau des hypothèses de calcul on entassait contraintes sur contraintes jusqu’à l’absurde, au point de simuler des situations qui ne pouvaient pas exister physiquement. Cela me lassait un peu... Et puis, une demande d’étude de sûreté sous-traitée par Elf, portant sur des installations de forage avec du gaz acide (H2S) à proximité de Pau (Pyrénées-Atlantiques), a été déposée sur mon bureau. 

Les études de fiabilité n’étaient pas encore entrées dans les mœurs dans le domaine pétrolier. J’ai trouvé ce sujet hyper intéressant à explorer. Après une première étude faite dans ce cadre, j’ai profité de l’occasion pour demander si je pouvais intégrer l’entreprise. Après quelques entretiens et passages de tests, j’ai été embauché pour rejoindre le service de Fiabilité de l’État-major de la DGEP d’Elf. 

Jean-Pierre SIGNORET naît le 6 juillet 1947 à Clermont-Ferrand. Après l’obtention d’une double Maîtrise en Physique nucléaire et en Électronique, électro-technique, automatique à l'Université de Clermont-Ferrand, il intègre en 1972 le département des affaires militaires du Commissariat à l’énergie atomique (CEA) : il y découvre la discipline de la « fiabilité » . 

Il réalise pendant trois ans des études de fiabilité portant sur les systèmes de sécurité des sous-marins nucléaires. En 1975, il entre au bureau d’Études probabilistes de Sûreté du même CEA (Bureau d’Études probabilistes de Sûreté, devenu maintenant IRSN) pour s’occuper de la sûreté des centrales nucléaires. En 1981, il rejoint le service de Fiabilité de l’Etat-major de la DGEP d’Elf (maintenant filiale de TotalEnergies – ex Total -) en tant qu’Ingénieur Fiabiliste, où il réalise des études de sûreté de fonctionnement (SdF) de systèmes de production pétroliers et conçoit les moteurs de calcul et modules de la suite logicielle GRIF. Parallèlement à ses activités, il est nommé Vice-Président de l’Institut de Sûreté de Fonctionnement (IMdR - anciemment ISdF) de 1988 à 2002, Président de l’European Safety and Reliability Association (ESRA) de 1999 à 2001, Président de l’UF56 de l’AFNOR (sûreté de fonctionnement) de 2009 à 2015. Il a animé le groupe de travail « Recherche Méthodologique » de l’Institut de sûreté de fonctionnement (IMdR - anciennement ISdF) puis de l’Institut pour la Maîtrise des Risques (IMdR) pendant plus de 20 ans et a été Président du comité de programme du congrès national lm12 en l’an 2000 (l et m sont les taux de défaillance et de réparation, deux des paramètres emblématiques de la sûreté de fonctionnement). 
Depuis son départ à la retraite en 2009 , il poursuit des activités de normalisation et reste toujours actif dans ce domaine (IEC, ISO, AFNOR). Dans le cadre de TotalEnergies Professeurs Associés (TPA), il continue d’enseigner la sûreté de fonctionnement dans diverses universités nationales et internationales. Il est l’auteur de nombreuses publications et d’ouvrages notoires dans le traitement des sciences fiabilistes. 

Bibliographie : 
- J-P SIGNORET et A LEROY, Le risque Technologique. PUF 1991
- J-P SIGNORET et A LEROY, Reliability Assessment of Safety and Production Systems – Analysis, Modelling, Calculations and test cases. SPRINGER 2021.

Les études de fiabilité étaient une discipline nouvelle pour Elf ? 

Pas tout à fait et, par exemple, des études avaient eu lieu pour le champ de Grondin nord-est (Gabon) dès les années 75. Et quand j’ai intégré Elf, nous étions deux équipes totalisant jusqu’à 6 à 7 fiabilistes, divisées entre les process et la recherche. Les directions Sécurité et Production réalisaient distinctement leurs propres études de fiabilité, parfois sur les mêmes systèmes. Cette organisation avait ses limites car des résultats différents pouvaient être obtenus sur des sujets d’études communs, mais ne couvrant pas les mêmes aspects (par exemple, sécurité versus disponibilité).  

Durant cette période toute une série d’accidents industriels ont marqué les esprits et la profession (notamment, l’explosion de Piper Alpha en Ecosse, celle de Macondo dans le golfe du Mexique ou le naufrage du Prestige en France). Les études de fiabilité sont devenues progressivement une pièce maîtresse dans la maîtrise des risques des installations de production.
Au fil du temps et des réorganisations, les équipes ont fusionné, les collègues sont partis à la retraite et je me suis retrouvé à gérer la plupart des affaires courantes, avant d’embaucher de jeunes collègues encore en activité aujourd’hui et mon propre départ à la retraite en 2009.

Comment réalisiez-vous vos études de fiabilité dans les années 1980 ? 

En posant principalement toutes nos formules et calculs sur papier ! Tout se faisait à la main. Je développais les arbres de défaillances sous la forme d’une structure binaire (développée par René-Louis VALLÉE dans son traité d’analyse binaire) qui permettait d’en extraire géométriquement les scénarios de pannes possibles. C’était laborieux mais ça marchait !

Les méthodes qualitatives se basaient beaucoup sur le « jugement de l’ingénieur » : par intuition et à partir des compétences et de l’expérience de chacun en plus des retours d’expérience en provenance du terrain afin d’établir les différents scénarios possibles (pannes, accidents, maintenance…). Cela  nous amenait à recourir à des méthodes inductives comme la méthode HAZOP (Hazard Operability Studies) issue de la Chimie, pour déterminer l’effet des dérives des paramètres physiques sur l’occurrence des pannes, ou des méthodes déductives, comme l’arbre de défaillance afin d’identifier les scénarios d’accidents/incidents susceptibles de se produire. 

"Dans les années 1980, les méthodes qualitatives se basaient beaucoup sur le « jugement de l’ingénieur » : par intuition et à partir des compétences et de l’expérience de chacun en plus des retours d’expérience en provenance du terrain (...)." 

"Les réseaux de Petri stochastiques constituent un modèle idéal de comportement des systèmes industriels, et la simulation de Monte-Carlo, une méthode informatique idéale pour singer simplement le hasard." 

Vous n’aviez pas d’ordinateurs pour vous aider à réaliser des opérations plus complexes ? 

Dans les années 80, Elf disposait d’une grosse unité Mainframe IBM 368 pour réaliser les calculs mais il existait aussi de petites machines HP-9830, ancêtre des ordinateurs personnels. Normalement destinées à faire de l’acquisition de données dans les laboratoires du Groupe, tout le monde détournait ces petites machines pour faire des calculs en échappant aux services informatiques centraux, nous de même ! Remplacées assez vite par des appareils plus puissants (HP-9845) elles ont servi de base pour le développement de nos premiers algorithmes de calcul. 

Les temps de calcul coûtaient extrêmement chers : une simple erreur pouvait griller le budget de l’année ! Mieux valait donc de ne pas se tromper dans nos calculs en amont de nos saisies. Même si ces machines nous aidaient à simuler des modèles qualitatifs et quantitatifs, les outils informatiques chez Elf demeuraient encore pauvres pour traiter pleinement, facilement et rapidement ces sujets. C’est à partir de ce moment-là que j’ai commencé à m’investir davantage dans la programmation pour permettre à mon service (et donc à l’entreprise) de disposer d’outils et de moteurs de calcul dédiés à la discipline des études fiabilistes. 

Termites n’est-il pas un ancêtre lointain du moteur de calcul ALBIZIA, intégré aujourd’hui dans la suite logicielle GRIF ? 

Tout à fait. Mais c’est la découverte des diagrammes de décision binaires (DDB) qui a favorisé un saut qualitatif pour la modélisation et le traitement de très grands arbres de défaillance et combler le rêve poursuivi avec Termites. 

J’ai ensuite développé Mark-EXD afin de réaliser les calculs probabilistes par l’approche markovienne et basé sur l’exponentielle de matrices.  Cette méthodologie de calcul, considérée à l’époque par le CEA comme l’une des plus mauvaises parmi les approches disponibles, s’est avérée en fait être la plus efficace et performante pour procéder aux calculs probabilistes relatifs aux systèmes de production et de sécurité. 

Termites et Mark-EXD constituent aujourd’hui l’ADN du moteur de calcul ALBIZIA. À l’heure actuelle c’est très certainement un des moteurs les plus puissants pour répondre aux besoins de modélisations statiques (calculs Booléens). Il est implémenté dans de nombreux modules de GRIF. 

Comment avez-vous abordé la création du moteur MOCA-RP pour les calculs dynamiques ? 

Pour MOCA-RP, j’ai voulu combiner Réseaux de Petri Stochastiques (RdPS) et simulation de Monte-Carlo. L’idée m’est venue parce que les RdPS constituent un modèle idéal de comportement des systèmes industriels et la simulation de Monte-Carlo une méthode informatique idéale pour singer simplement le hasard (simuler des pannes, des réparations, etc.) et animer lesdits RdPS. Cela procure une souplesse et une puissance de modélisation incomparable qui ouvre des possibilités énormes pour le traitement des grands systèmes complexes (et pas forcément markoviens). Partis de quelques dizaines de flops (opérations en virgule flottante par seconde) on parle maintenant de giga (109), tera (1012), et même peta flops (1015) : Il est loin le temps où on tirait les nombres au hasard dans un chapeau. La simulation de Monte-Carlo est sans aucun doute la méthode de calcul qui monte ! 

Pourquoi a-t-il été nécessaire de faire évoluer ces moteurs ? 

Dans les années 1990, l’environnement numérique a totalement été bouleversé par l’arrivée des premiers systèmes d’exploitation DOS et Unix, qui a mené à la banalisation des « personal computers » (PC). Puis, à partir des années 2000, sont apparus les systèmes Windows (sur PC), HP View, Sun Solaris et Linux (sur stations de travail). Pour suivre le mouvement, nous avons converti l’ensemble de nos outils à ces systèmes d’exploitation et délaissé le langage Basic HP et le FORTRAN pour passer au C et au C++. Avec l’appui de Damien EHRET, ingénieur informaticien toujours en exercice aujourd’hui chez TotalEnergies, nous avons développé une interface graphique interactive pour faciliter l’utilisation des divers moteurs de calcul. Appelée GRIF, elle a fini par donner son nom au progiciel tout entier. D’abord développée en langage LeLISP, elle l’est maintenant en JAVA pour la présente version du progiciel GRIF.

Des licences de moteurs de calcul ont été concédées dès la fin des années 80 mais c’est parallèlement à l’intégration des activités de Elf au sein du groupe Total que nous avons lancé la commercialisation des premiers modules de GRIF proprement dit : BFiab, Tree, Reseda, Markov et Petri en 2005, ainsi que BStoK en 2006.  

Vous avez imaginé et programmé tous ces modules vous-même ? 

Tous, de A à Z pour les algorithmes des moteurs de calcul originaux ! Durant toute ma carrière chez Total, je me suis retrouvé à porter une double casquette mêlant mes compétences fiabilistes et de programmation informatique. Ce n’était pas d’ailleurs forcément très confortable vis-à-vis des ingénieurs informatiques, mais j’ai profité d’abord de la disponibilité des HP-9845 puis de l’arrivée massive des PC sous DOS. Cela s’est avéré très utile pour obtenir des outils correspondant aux besoins réels. 

Au fil du temps, et avant de partir à la retraite, je me suis entouré d’une équipe interne et de sous-traitants comme Cyrille FOLLEAU ou Philippe THOMAS de SATODEV pour m’aider à enrichir ses fonctionnalités.

"Comme tout bon outil qui dure dans le temps : GRIF continuera d’évoluer et de s’adapter aux exigences des métiers portant sur les études de fiabilité. "

Quels sont les modules que vous avez vous-même développés dont vous êtes le plus fier ? 

Je les apprécie tous car ils répondent chacun à des besoins spécifiques que j’ai été amené à combler moi-même pour m’aider dans mes activités d’ingénieur fiabiliste. Et je me rends compte que, pour ce faire, pratiquement tout ce que j’ai appris pendant mes études (mathématiques et physique nucléaire) m’a, un jour ou l’autre, permis de me sortir d’un problème difficile. Les mathématiques sont comme des langues vivantes : avec leurs syntaxes (riches !) et leurs méthodes de calcul qui s’adaptent constamment pour comprendre et modéliser l’environnement qui nous entoure. Il me semble qu’elles sont un peu trop délaissées à l’heure actuelle.

Quel regard portez-vous sur les modules complémentaires qui ont été développés après votre départ à la retraite (ETree, Bool, Petro, Risk, Flex et SIL) ?  

Avant mon départ de chez Total, je me souviens m’être abstenu de développer un module SIL, destiné à l’évaluation du niveau d’intégrité des systèmes instrumentés de sécurité (SIS). J’estimais qu’on pouvait mieux entrevoir les problématiques d’un système sur papier et en utilisant le module d’arbre de défaillance classiques plutôt qu’au travers d’un modèle déjà tout mâché. Mais la demande était telle que Stéphane COLLAS (qui a pris la relève sur GRIF) a fait automatiser une solution informatique en ce sens : elle a rencontré, dès sa sortie, beaucoup de succès. Tous ces modules s’inscrivent dans la continuité des demandes exprimées régulièrement par les professionnels du milieu, de plus en plus sollicités pour réaliser rapidement des études de fiabilité intégrant des paramètres nouveaux (normes, contrôle des coûts, réduction de l’empreinte carbone…). Répondre aux besoins des utilisateurs est en droite ligne avec la philosophie mise en œuvre dès les premiers travaux réalisés en 1982. 

Et quel regard portez-vous sur l’évolution et les enjeux du métier d’ingénieur fiabiliste ? 

Pour ma part, je pense que la normalisation (notamment ISO et IEC) des définitions reste un sujet central pour permettre à l’ensemble des professionnels, qu’ils soient ingénieurs fiabilistes, sécurité, production et/ou maintenance, de modéliser leurs systèmes sur les mêmes bases. On a trop souvent tendance à faire évoluer les critères déterminant leurs périmètres d’applications et il en résulte des dérives sémantiques. Or, à mon sens, la bonne définition est celle qui ne change pas. Surtout quand il s’agit de qualifier les fondamentaux de notre métier : qu’est-ce que la « disponibilité », le « risque », ou encore, la « fiabilité » … ? 
La normalisation des méthodes est aussi une bonne chose à condition qu’elles ne soient pas en contradiction avec nos pratiques ! Et pour ce faire, une implication de tous les instants dans les comités de normalisation est nécessaire. 

Je remarque aussi l’apparition de disciplines émergentes dans les activités fiabilistes comme, par exemple, la maintenance prédictive - qui a pour objet d’intervenir en amont de la panne potentielle mais pas trop tôt afin de ne pas impacter la chaîne de production -, le MBSA (Model Based Safety Asessment), l’envahissement par des composants « intelligents », la croissance des problèmes de cybersécurité, …. Cela implique l’introduction de notions nouvelles, de tout un nouveau champ lexical - à définir, avec son propre vocabulaire – et de nouvelles techniques d’analyse modélisation et calcul. D’autre part, après tout ce temps, nous ne disposons toujours pas de modèles globaux mêlant les aspects technologiques, humain et informatique dans un outil unique. Les opportunités de développement restent donc, encore, insoupçonnées. 

En trois mots, comment résumeriez-vous GRIF ? 

Je pense sincèrement que GRIF reste encore aujourd’hui un des meilleurs outils de modélisation des systèmes industriels disponibles sur le marché. Aucun logiciel n'englobe toutes les méthodes de calcul qui ont été développées et intégrées au fil des années par nos soins. ALBIZIA est le seul moteur de calcul à proposer la jonction de Markov et des arbres de défaillance, et MOCA-RP est l’un des algorithmes les plus puissants du marché. Le tout, dans une interface conviviale et facile à utiliser pour tous les ingénieurs fiabilistes. Je suis très fier d’avoir pu, au travers de ma contribution et avec le soutien des équipes qui m’ont accompagné, créer un outil qui est aujourd’hui considéré comme une référence par les ingénieurs fiabilistes. Et comme tout bon outil qui dure dans le temps : GRIF continuera d’évoluer et de s’adapter aux exigences des métiers portant sur les études de fiabilité.  

Plus d'informations ? 

Contactez-nous

Damien EHRET, ingénieur informaticien chez TotalEnergies, nous raconte comment il a été amené à créer l’interface de la suite logicielle GRIF en collaboration avec Jean-Pierre SIGNORET.

Comment avez-vous été amené à collaborer avec Jean-Pierre SIGNORET sur la suite logicielle GRIF ? 

Après une formation pour devenir ingénieur généraliste, j’ai été embauché en 1987 chez Elf. J’avais alors 25 ans je travaillais au sein du département Intelligence Artificielle de Centre Scientifique et Technique Jean Féger (CSTJF), à Pau. 
Je me suis beaucoup investi dans la conception de moteurs base de règles. C’est dans le cadre de cette activité que j’ai eu un premier contact avec l’équipe de Jean-Pierre SIGNORET. Il recherchait quelqu’un qui pouvait l’aider, à partir de ses descriptions, à créer une installation capable de générer des graphes de Markov. J’ai été séduit par l’idée. Après quelques échanges, il m’a donné carte blanche pour travailler sur le projet.  

C’est étonnant de faire appel à un collaborateur interne et évoluant, de surcroît, dans un environnement industriel pour concevoir un logiciel muni d’une interface graphique. Vous n’aviez aucune expertise en externe pour vous accompagner sur ce projet, ou bien, un logiciel existant pour inspirer la création de votre interface ?  

Il faut replacer l’environnement de travail dans le contexte de l’époque des années 1990. On était au tout début des PC. Les ordinateurs et postes de travail n’étaient pas aussi démocratisés et ergonomiques qu’actuellement. A ma connaissance, non, il n’existait aucun logiciel équivalent qui avait été développé auparavant sous FORTRAN. Tout restait encore à faire. 
Chez Elf, nous innovions beaucoup en interne pour développer des solutions informatiques et techniques destinées à faciliter nos activités, bien plus que chez Total qui avait une culture de la sous-traitance déjà bien présente au moment de notre acquisition en 1999. Nos ingénieurs se concentraient davantage sur les aspects techniques. La singularité de ma collaboration avec Jean-Pierre SIGNORET a été justement de pouvoir imaginer tout un outillage clé en main pour réaliser facilement des études de fiabilité de qualité. 

edito_1_colomn_dehret_0.png

Quelle était la situation au moment où vous êtes arrivé ?

Tous les calculs étaient d’abord posés à la main. Puis, avec un fichier texte mentionnant les nœuds et le liens, Jean-Pierre intégrait toutes les descriptions des méthodes de calcul sur des serveurs HP-9845 et IBM pour permettre aux moteurs MOCA-RP et Mark-EXD d’afficher les résultats. 
La partie graphique de la modélisation et la génération du calcul restaient ainsi indépendantes les unes des autres. Il fallait penser à une interface graphique qui rassemble l’ensemble des fonctionnalités et capable de marcher à la fois sur UNIX et sur PC avec DOS. 

Comment avez-vous procédé ? 

Notre objectif n’était pas de créer quelque chose de révolutionnaire mais de numériser l’environnement de travail existant.
A partir de quelques maquettes imaginées par Jean-Pierre, et que nous discutions ensemble, nous avons développé une interface graphique qui se voulait être la plus simple possible, composée d’un large espace de visualisation de la modélisation des systèmes, et accompagnée des options de configuration sur les côtés.
Le plus important consistait à conserver les symboliques propres au jargon de l’expertise fiabiliste. Par exemple, il y avait une symbolique pour définir un nœud, une autre pour expliquer le lien avec un nœud etc. 
Après quelques développements et tests pour relier les programmes de calcul à l’interface, nous avons pu mettre à disposition un outil opérationnel. 

"Notre objectif n’était pas de créer quelque chose de révolutionnaire mais de numériser l’environnement de travail existant." 

illustration_-_evolution_grif_interface_0.png

Qui est à l’origine du nom de la suite logicielle « GRIF » ? 

C’est moi. Je l’ai trouvé comme ça. A l’époque, les brainstorming n’étaient pas vraiment à la mode. J’ai réalisé une documentation sur l’interface graphique, et puis, au fur et à mesure, je l’ai baptisé GRIF (pour Graphiques Interactifs pour la Fiabilité). J’ai proposé le nom à Jean-Pierre qui l’a immédiatement adopté. 
Jamais je n’aurais pensé un seul instant que GRIF aurait une telle longévité et que son nom allait rester. C’est amusant car on a finalement conservé le nom propre à l’interface graphique de GRIF alors que  le plus important selon moi reste les moteurs de calcul pour les Graphes de Markov et Réseaux de Petri composant les packages. Mais les gens ont aimé. Probablement parce que l’image parle d’elle-même. 
Aujourd’hui, je suis agréablement surpris de voir à quel point GRIF est devenu une référence pour les modélisations de systèmes industriels. Cela au point que son nom soit mentionné sur certaines fiches de postes d’entreprises cherchant à recruter des ingénieurs fiabilistes sachant déjà maîtriser notre outil.   

À propos de GRIF

Suite logicielle GRIF

Une suite logicielle d'analyse des systèmes pour tous les secteurs d’activité.

GRIF (GRaphiques Interactifs pour la Fiabilité) est une suite logicielle d’excellence déterminant les indicateurs fondamentaux de la sûreté de fonctionnement (Fiabilité – Maintenabilité – Disponibilité – Sécurité). Forte de l'expérience de TotalEnergies en matière de recherche et développement en simulations, elle dispose de moteurs de calcul matures, performants ainsi que de capacités de modélisation répondant aux besoins de toute étude de fiabilité.

En savoir plus