Le cycle de vie de sécurité : de l'analyse au déclassement
La sécurité fonctionnelle est un cycle de vie, pas un calcul ponctuel. Les phases de l'IEC 61511, le modèle en V, le contenu de la spécification (SRS), la différence entre vérification et validation, et les évaluations FSA qui jalonnent le parcours.
Pourquoi un cycle de vie
Une fonction de sécurité n’est pas un objet qu’on installe et qu’on oublie. Elle est spécifiée à partir d’hypothèses, réalisée par plusieurs corps de métier, mise en service, puis exploitée pendant vingt ou trente ans — pendant lesquels le procédé change, les composants vieillissent, les équipes tournent, et les hypothèses initiales se périment silencieusement.
L’IEC 61511 structure cette durée en phases enchaînées, chacune avec ses entrées, ses sorties et ses exigences de documentation. L’objectif n’est pas bureaucratique : il s’agit de garantir qu’à tout moment, quelqu’un puisse démontrer que la fonction fait toujours ce pour quoi elle a été conçue.
Les phases, dans l’ordre
1. Analyse des dangers et évaluation du risque. HAZOP puis LOPA. Sortie : la liste des scénarios et le risque à réduire.
2. Attribution des couches de protection. Répartir la réduction de risque entre les couches — procédé, BPCS, alarmes, SIS, protections physiques. Sortie : la liste des SIF et leur SIL requis. C’est ici qu’on décide de ce qui revient à l’instrumentation, et ce qui devrait plutôt être résolu par la conception.
3. Spécification des exigences de sécurité (SRS). Le document pivot, détaillé plus bas.
4. Conception et ingénierie du SIS. Choix des composants, architectures, calculs de PFD, logique applicative, contraintes d’installation. Sortie : dossier de conception et note de calcul justifiant l’atteinte du SIL.
5. Installation, mise en service et validation. Montage, essais de boucle, essais fonctionnels bout en bout. Sortie : le procès-verbal de validation, qui atteste que chaque SIF fait ce que la SRS demandait.
6. Exploitation et maintenance. Tests périodiques, gestion des pontages, enregistrement des demandes et des défaillances.
7. Modification. Toute évolution repasse par les phases amont concernées — c’est le management of change.
8. Déclassement. Mise hors service maîtrisée : une SIF qu’on retire doit l’être avec la même rigueur que celle avec laquelle on l’a installée, car son absence modifie l’analyse de risque.
Le modèle en V
Le cycle se représente naturellement en V. La branche descendante définit — du risque jusqu’au code applicatif, en passant par la spécification et la conception. La branche montante contrôle — des essais unitaires jusqu’à la validation globale.
La force du modèle tient à l’appariement horizontal : chaque étape de définition a son étape de contrôle en vis-à-vis.
| Branche descendante (définir) | Branche montante (contrôler) |
|---|---|
| Analyse de risque, SIL requis | Validation : la SIF réduit-elle le risque visé ? |
| SRS | Essais fonctionnels bout en bout |
| Conception du SIS | Essais d’intégration, essais de boucle |
| Logique applicative | Essais unitaires, revue de code |
La conséquence est directe : un défaut introduit dans la branche descendante n’est détecté qu’à la hauteur correspondante de la branche montante. Une erreur de SRS ne se révèle qu’à la validation finale, quand tout est installé — c’est-à-dire au moment le plus coûteux.
La SRS : le document pivot
La spécification des exigences de sécurité (safety requirements specification) est le point de bascule du cycle. Tout ce qui vient après en découle ; tout ce qui y manque ne sera jamais réalisé.
Une SRS complète décrit, pour chaque SIF :
- La condition déclenchante — quel paramètre, quel seuil, quelle logique de vote
- L’action de sécurité — quel actionneur, dans quelle position
- L’état sûr recherché, et le comportement en cas de perte d’énergie ou d’air
- Le temps de réponse exigé — le process safety time, délai au-delà duquel l’action devient inutile
- Le SIL requis et le mode de sollicitation (faible, élevée, continu)
- Le comportement au redémarrage — réarmement manuel ou automatique, conditions de retour en service
- Les exigences de pontage — qui peut inhiber, dans quelles conditions, avec quelle signalisation
- Les exigences de test — quel intervalle, quelle couverture, testable en marche ou à l’arrêt
- Les interfaces — avec le BPCS, les alarmes, la conduite
Deux exigences sont systématiquement sous-traitées et se paient cher plus tard : le temps de réponse (une SIF juste mais trop lente ne protège pas) et la testabilité (une SIF qu’on ne peut tester qu’à l’arrêt complet de l’unité verra son intervalle de test dériver vers l’arrêt quinquennal, avec la PFD qui suit).
Vérification et validation : deux mots, deux sens
Confusion fréquente, distinction essentielle :
- Vérification : a-t-on bien fait la chose ? Contrôle de conformité d’une phase à ses exigences d’entrée. Le calcul de PFD est correct, la logique est conforme à la SRS, le câblage suit les plans. Elle a lieu à chaque phase.
- Validation : a-t-on fait la bonne chose ? Essai final, installation complète, qui démontre que chaque SIF réalise réellement l’intention de sécurité, dans son temps, avec ses conditions de réarmement.
On peut parfaitement vérifier avec succès toutes les phases et échouer à la validation — c’est exactement le cas d’une SRS erronée, correctement mise en œuvre.
Les évaluations FSA
L’évaluation de la sécurité fonctionnelle (functional safety assessment, FSA) est une revue indépendante du travail réalisé, menée par des personnes qui n’en sont pas les auteurs. La norme prévoit plusieurs jalons, dont le plus critique se situe avant la mise en service du procédé — dernier moment où une erreur se corrige encore à coût raisonnable.
Une FSA examine la cohérence de la chaîne : l’analyse de risque justifie-t-elle les SIL retenus ? La SRS couvre-t-elle chaque SIF ? Les calculs sont-ils traçables ? Les essais couvrent-ils la SRS ? Les compétences des intervenants sont-elles établies ?
D’autres jalons interviennent après une modification importante et à intervalles réguliers en exploitation.
La gestion de la sécurité fonctionnelle
En transverse de toutes les phases, la norme exige une organisation : un plan de sécurité fonctionnelle qui nomme les rôles et responsabilités, établit la compétence des intervenants (formation, expérience, tenue à jour), fixe les règles de documentation et de traçabilité, et définit le processus de gestion des modifications.
Cette exigence n’est pas décorative. Elle vise directement les défaillances systématiques, qui dominent les accidents réels : personne n’a relu la logique, la modification n’a pas été tracée, le technicien n’a pas été formé au système, l’hypothèse de test n’a pas été transmise à l’exploitation.
En pratique
Sur une installation existante, ce cycle se heurte à trois réalités récurrentes : la documentation d’origine est incomplète ou perdue ; les modifications successives n’ont pas toutes été tracées ; et les hypothèses de test initiales ne correspondent plus aux intervalles réellement pratiqués.
La démarche utile consiste alors à reconstruire dans l’ordre : inventaire des SIF existantes, reconstitution des SRS à partir du terrain, recalcul des PFD avec les intervalles réels, puis identification des écarts. C’est précisément le travail que structure l’application Functional Safety d’IndustryHub, qui suit les phases du cycle 61511 et produit les livrables associés.
Le chapitre suivant fait le tour de la famille normative — car selon qu’on travaille en procédé, en machine, en automobile ou en ferroviaire, ce cycle prend des noms et des échelles différents.