• Aucun résultat trouvé

Chapitre III : Contribution théorique

3.4 La démarche opératoire de la méthode

3.4.1 Une phase de conception : le « Design Time »

3.4.1.1 Une phase de conception guidée par la notion de système de systèmes

La notion de système de systèmes nous a permis de mieux appréhender la phase de conception des projets d’A&D et donc du SA&D, notamment en identifiant la nécessité d’adopter des démarches agiles de validation avec l’ensemble des parties prenantes concernées, ou encore la nécessité du caractère itératif de la démarche de conception.

Le « Design Time », correspond donc à une phase pendant laquelle le SA&D est décrit et caractérisé tel que prévu ou souhaité, simulé et validé progressivement et itérativement jusqu'à ce qu'il soit jugé acceptable par toutes les parties prenantes, y compris, entre autres, par l'autorité de sûreté, l’exploitant, les maîtres d’œuvre et le responsable du projet. Le concept de système de systèmes est ici crucial pour obtenir une représentation à la fois statique et dynamique du SA&D. En effet, les simulations et les analyses effectuées permettent de prévoir et donc d’anticiper certaines évolutions, d’évaluer les risques, etc. Les principales activités du « Design Time » sont :

• la modélisation, en prenant en compte les principes du système de systèmes, avec saisie des données, informations et connaissances nécessaires, formatage, nettoyage, etc., et utilisation de patrons de modélisation ;

• l'analyse itérative du modèle de SA&D pour prendre en compte la maturité croissante du projet, c'est-à-dire :

o vérifier la cohérence des modèles et des données, informations et connaissances au regard des objectifs et des exigences du projet, ainsi que le respect des règles de construction des modèles ;

o évaluer les effets de la propagation de diverses modifications et la sensibilité de tout ou partie des modèles du projet à ces modifications. Cela induit par exemple la possibilité de simuler des événements pour aider à percevoir les effets secondaires ;

o communiquer et expliquer aux parties prenantes.

• la validation progressive avec les parties prenantes (validation agile) pour évaluer la relative exhaustivité et la pertinence de ces modèles jusqu'à ce que les niveaux requis de sûreté et de sécurité soient atteints et que les délais et les coûts soient jugés acceptables et partagés par toutes les parties prenantes.

3.4.1.2 Peut-on préconiser des règles métiers qui régissent la démarche ?

Aujourd’hui, en prenant l’exemple du CEA, la première étape d’élaboration d’un projet de démantèlement consiste systématiquement par des questions de base :

126

• Quel est l‘état initial de l’installation avant les opérations (i.e. les configurations passées et la configuration actuelle, les modes passés et actuels, les niveaux et caractéristiques de l’activité, les données répertoriées, les possibles REX qui semblent pertinents, …) ? Il est primordial de se mettre d’accord sur les différents paramètres à considérer pour décrire cet état initial : configuration, modes, niveau, caractéristique, activité résiduelle, etc. ;

• Quelle est la fiabilité des données disponibles qui définissent cet état ? Plus précisément, quels sont les éléments justificatifs qui permettent de s’assurer que cet état initial formalisé est bien le « bon » c’est-à-dire représentatif de la réalité ? Faut-il prévoir de nouvelles investigations pour conforter la vision globale et l’état initial de l’installation ? Ou valider simplement les données sans faire de nouvelles investigations (procéder par expertise, par simulation, etc.) ?

• Quelle est la fiabilité des systèmes qui ont permis de générer (e.g. systèmes de mesure et d’investigation), de stocker (e.g. systèmes d’informations, de sauvegarde, documents papiers…) et de sécuriser ces données ?

• Les données disponibles sont lacunaires, elles ne suffisent jamais ; il faut donc aller chercher d’autres données : lesquelles ? Où ? Comment ? Avec quels moyens ? Quels sont les risques ? Etc.

Cet état initial, dont la modélisation peut s’avérer complexe, va également contraindre le SA&D dans son entier, notamment la réalisation des opérations et l’état final attendu. Il va donc falloir manipuler et respecter des exigences provenant de très nombreuses sources (contraintes liées à l’état final, à l’état initial, au cadre réglementaire, etc.) pouvant parfois être en contradiction apparente ou réelle, pour proposer des solutions. Chaque solution induira de fait de nouvelles exigences. Posséder un référentiel structuré des exigences applicables à chaque SA&D (et donc à chaque élément de celui-ci), puis ensuite pouvoir à tout instant tracer et vérifier celui-ci, est donc primordial. Nous proposons en outre ici de modéliser les contextes de manière la plus détaillée possible afin d’augmenter le travail de conception du domaine du problème (i.e. se poser la question : « quels paramètres, quelles parties prenantes, quelles exigences dois-je prendre en compte dans mon démantèlement ? »), et donc également de minimiser les risques d’oublis.

Un scénario de démantèlement efficient consiste à supprimer au plus vite les sources de risques (dont sources radioactives), qui nécessitent de la surveillance et des investigations continues. C’est en quelque sorte des bonnes pratiques qui apparaissent ici :

• éliminer en priorité les procédés qui nécessitent de la surveillance coûteuse : on pourra simplifier l’INB (exemple : enlever des capteurs qui deviennent non nécessaires) et économiser sur cette surveillance ;

127

On peut donc préconiser une priorisation des activités. Cela passera dans notre méthode par l’importance du concept d’Indicator, dont le suivi et la hiérarchisation (qui se fera via des exigences diverses, souvent émises en contrainte par des systèmes à l’interface, tels que la minimisation des coûts, délais, déchets, dose, ou priorisation du TSM, etc.) impactera la façon de modéliser les scénarios de démantèlement.