Chapitre 6. Proposition de processus à mettre en œuvre pour contribuer à la résilience
6.2. Contribution à des évolutions des processus d’ingénierie système
Les processus d’ingénierie système doivent évoluer pour intégrer les processus de conception centrée utilisateur (ISO, 2010b), faire évoluer l’architecture26 pour prendre en compte l’intégration du système de surveillance de l’usage et de l’état et prendre en compte les processus d’appropriation et d’adaptation du système technique par les opérateurs (Ruault, 2009).
Les premiers impacts de l’intégration du système de surveillance de l’usage et de l’état concernent les processus techniques d’ingénierie système (cf. section 2.3 « Processus d'ingénierie »).
Il s’agit de déterminer les mesures permettant d’évaluer si le système est mis en œuvre dans son domaine d’emploi ou fonctionne hors de ce domaine d’emploi. Ces mesures doivent aussi caractériser l’état courant du système, sa dynamique dans le temps, mais aussi l’état et la dynamique de l’environnement avec lequel le système interagit. La détermination et la sélection de ces mesures, parmi la multitude de mesures potentiellement disponibles, doivent être pilotées par la gestion des risques et l’analyse préliminaire de sécurité. En effet, la surveillance du système hors de son domaine d’emploi est complémentaire de l’analyse de sécurité qui détermine les événements redoutés, évalue les conséquences de leur survenue et leur probabilité d’occurrence.
Il s’agit aussi de caractériser les barrières mises en place pour réduire ces occurrence et/ou ces conséquences, obtenir leur état et tracer dans le système les justifications de ces barrières et les éléments de sécurité qu’elles préservent. Il est nécessaire de déterminer les empans de recueil de ces mesures, les moyens de stockage et les traitements permettant de mettre en évidence les tendances.
Connaissant ces mesures, il faut ensuite déterminer les capteurs qui peuvent fournir ces mesures. Il s’agit aussi de stocker dans le système les données de référence de sa définition à partir desquelles seront effectuées les comparaisons pour évaluer l’écart entre un état courant et un état de référence. Ces données doivent êtres mises à jour lorsque la définition du système change.
Il s’agit de déterminer les seuils d’alerte, tant à partir d’un changement d’état d’un capteur que des données calculées.
L’ensemble de ces mesures, de ces données et des traitements associés doit être fiabilisé. En effet, des informations qui ne seraient pas fiables entraîneront des présentations non fidèles au niveau des IHM et en cascade des erreurs de jugement de la part des opérateurs. En outre, des informations qui ne seraient pas fiables jetteraient un important discrédit sur le système, une perte de confiance de la part des opérateurs et au-delà de la méfiance, de la défiance par rapport au système. Pour autant, il paraît nécessaire d’affecter un niveau de confiance aux informations, à l’instar du niveau de confiance attribué aux prévisions météorologiques. Enfin, il faut élaborer l’adaptation des alertes aux différents dispositifs des systèmes interactifs qui seront utilisés par les opérateurs.
26
Architecture au sens de l’activité, de la pratique, le terme architecting est souvent utilisé pour marquer la différence par rapport à l’architecture en tant qu’organisation du système traitée dans le Chapitre 5, « Proposition d’un patron de conception pour l’architecture d’un système résilient ».
Le processus visant à déterminer les mesures, les capteurs, les données et les traitements peut être l’objet d’un document de bonnes pratiques, par exemple une norme, pour aider les concepteurs dans leur activité. De plus, ce processus doit être intégré dans les documents majeurs de l’ingénierie système (ISO, 2014). C’est une action à mener (cf. Conclusion générale, section « Actions à mener dans le domaine de la normalisation »).
Cela se aussi traduit par une plus grande prise en compte des processus de conception centrée utilisateur dans des processus d’ingénierie système. Au-delà des propositions qui ont déjà été faites à ce sujet (cf. section 3.3, « Processus de conception centrée utilisateur »), il s’agit d’articuler la conception pour l’appropriation (cf. section 6.3.1 « Concevoir pour l’appropriation » de ce chapitre) avec les processus et activités d’ingénierie système. Tant la conception pour l’appropriation que l’intégration du système de surveillance de l’usage et de l’état du système principal affectent les processus d’analyse métier ou de la mission, de définition des besoins et exigences des parties prenantes, de définition des exigences système, de définition de l’architecture, de définition de la définition du système (ISO, 2014).
Dans la même perspective, les documents majeurs (ISO, 2010b ; ISO, 2014) doivent prendre en compte le processus d’appropriation dans une future mise à jour (cf. Conclusion générale, section « Actions à mener dans le domaine de la normalisation »).
L’anticipation en amont de l’usage qui pourra être fait du futur système peut s’appuyer sur la modélisation de scénarios. Dans le cadre des travaux consacrés au Grand Paris (Chérel, 2012), des scénarios d’usage sont élaborés. Les usagers des transports, exploitant les ressources des technologies de l’information et des communications, recalculent leur itinéraire en fonction des perturbations de trafic. Cette situation, au niveau individuel, doit être analysée globalement pour envisager dynamiquement les impacts sur la charge des itinéraires alternatifs et gérer cette surcharge pour maintenir un trafic régulier, malgré les perturbations locales.
De plus, cela se traduit aussi par la capacité d’effectuer un retour d’expérience des situations opérationnelles pour prendre en compte les adaptations que mettent en œuvre les opérateurs et les nécessaires évolutions du système technique. Cela concerne en priorité le processus de définition des exigences des parties prenantes, le processus d’analyse des exigences, le processus de définition de l’architecture (ISO, 2014), ainsi que le processus de gestion des exigences (ISO, 2009). Le retour d’expérience nourrit aussi le processus de maintenance du système à élaborer. Ce retour d’expérience doit être clairement identifié comme le processus d’ingénierie système clef de voûte pour apporter une capacité de résilience du système technique dans la mesure où il contribue à améliorer la compréhension, par les ingénieurs, de la manière dont le système s’adapte et à quelles gammes ou sources de variation. Ce retour d’expérience doit rendre compte des migrations et des mécanismes de compensation, ainsi que des variations et des évolutions du contexte opérationnel.
Ce processus de retour d’expérience se nourrit des données produites et stockées par le système de surveillance de l’état et de l’usage du système principal. En effet, si la première vocation de ce système de surveillance est d’alerter les opérateurs et leur permettre de naviguer à vue, les informations recueillies par le système de surveillance entrent dans le processus de retour d’expérience pour faire évoluer le système (cf. section 6.3.3 « Activité de veille et retour d’expérience »).
Par ailleurs, le retour d’expérience doit tracer les dérives, tant celles qui fonctionnent bien que celles qui génèrent des incidents. Pour les premières, le retour d’expérience doit aider à différencier, d’une part les compensations qui cachent potentiellement un grave accident lorsqu’il y a décompensation, et d’autre part les ajustements adaptés aux évolutions de
l’environnement et qui ne bouleversent pas l’équilibre du système, en particulier des ajustements qui ne génèrent pas des compensations sources de risque (cf. Tableau 4.2).
Les documents normatifs (ISO, 2010c ; ISO, 2014) sont muets sur le retour d’expérience et sur les activités de rénovation à mi-vie qui peuvent profiter du retour d’expérience. Dans ce contexte, une action doit être envisagée afin que soient formalisées et décrites ces activités dans une prochaine édition des documents normatifs (ISO, 2014). Ces activités doivent être anticipées et prises en compte le plus tôt possible puisqu’elles affectent l’ensemble des processus, et en particulier celui de définition de l’architecture.
Processus d’analyse métier ou de la mission
Processus de définition des besoins et exigences des parties prenantes
Processus de définition des exigences système Processus de définition de l’architecture
Processus de définition de la définition du système Processus d’analyse système
Processus de réalisation Processus d’intégration Processus de vérification Processus de transition Processus de validation Processus d’exploitation Processus de maintenance
Processus de retour d’expérience
Processus de démantèlement
Figure 6.1. Insertion du processus de retour d'expérience dans les processus techniques de la norme ISO 15288 (adapté de ISO, 2014).
La Figure 6.1 illustre notre proposition d’intégration du processus de retour d’expérience au sein des processus techniques décrits dans la norme (ISO, 2014). Ce processus de retour d’expérience s’appuie sur les informations issues du processus d’exploitation pour enrichir le
processus de maintenance. Une action est à mener afin de mener à bien cette intégration (cf. Conclusion générale, section « Actions à mener dans le domaine de la normalisation »).