Article «  Prévoir et anticiper les risques à chaque étape de la conception de système complexe  » de Mme Catherine LAVAL © Consultant et Président du Conseil d’Administration – Société APTE SYSTEM © 1 place Jean Baptiste CLEMENT – 75018 PARIS
(2000)

Résumé Conception de système complexe

La démarche proposée ici a pour objectif de faciliter, dans le cadre de développement et de conception de systèmes complexes, la prise en compte des aspects performances, disponibilité et sécurité système, mais aussi celle des coûts et des délais, cela dans un approche systémique des risques dès la conception.

Cela suppose de :

– différencier les risques inhérents au système  » à faire « , et ceux liés au projet lui-même (système associé  » pour faire  » ou organisation pour développer ce système),
– d’utiliser une démarche de conception de système complexe rigoureuse, associée à des processus de décision,
– de disposer d’outils de raisonnement, à chaque étape, pour anticiper les risques et disposer d’aides à la décision pour leur prise en compte, cela dès la spécification du système.
La gestion des risques ne suffit plus. Il faut évoluer vers le Management des risques : anticipation et aides à la décision deviennent alors des priorités.

Gérer, maîtriser et manager les risques …

Faut-il inévitablement  » subir  » les risques qui existent dans le cadre de développement de systèmes complexes ?

Que ce soit par la mise en place d’actions correctives, ou de suivi rigoureux des risques pour en limiter les impacts, il s’agit toujours d’une attitude plus gestionnaire que managériale…
Il faut intégrer :

– la créativité et l’anticipation dans la mise en évidence des risques,
– des logiques et outils d’aide à la décision dans leur prise en compte.

Système  » à faire  » et système  » pour faire  » :

La complexité d’un projet est due à deux aspects interdépendants :

– la complexité liée au système même à développer,
– la complexité liée au projet et à l’organisation pour conduire ce développement.

Il s’agit de distinguer ces deux logiques car elles ne font pas appel aux mêmes critères, mais aussi de les intégrer, dès l’amont et en permanence dans le raisonnement des choix.
Les risques qui en découlent interagissent sur le résultat (figure A) :

afitep_1

Les risques Système sont liés à la satisfaction des exigences (contextes, fonctions et critères associés).
Les risques Projet correspondent, bien sûr, aux risques économiques mais concernent aussi la stratégie industrielle, les délais, les ressources/compétences, le taux d’innovation, l’impact sur l’image de l’entreprise…

Risques et conception de système complexe

Pour J. MORIN (2), la  » technologie, c’est l’art de mettre en oeuvre, dans un contexte local et pour un but précis, toutes les sciences, techniques et règles fondamentales qui entrent aussi bien dans la conception des produits que dans les procédés de fabrication, les méthodes de gestion ou les systèmes d’informations de l’entreprise « .
Le « raisonnement » des risques doit être intégré au processus de conception, ce qui implique une formalisation de la méthode de conception, des logiques de choix et leur traçabilité.
La démarche proposée ici intègre les logiques et outils de la Méthode APTE® (1) d’Analyse Fonctionnelle, les approches de conception de système complexe, d’ingénierie système et de sûreté de fonctionnement.

Les 5 grandes étapes en conception de système complexe

Nous décomposerons le processus de conception de système complexe en cinq étapes significatives des types de choix nécessaires pour construire la solution :

O Opportunité
1 Définition des besoins et contraintes à satisfaire
2 Recherche et choix de principes
3 Structuration / architecture fonctionnelle
4 Structuration / architecture technique

Le synoptique présenté ci-après (figure B) illustre ce processus de conception de système complexe et les outils méthodologiques associés, pour les étapes 1 à 4.

afitep_2

Les 5 niveaux de raisonnement des risques :

A chaque étape du processus de conception de système complexe, est associée une analyse des risques, avec des logiques et des outils spécifiques (figure C):

Analyse de risques liés à l’environnement ARE
Analyse de risques dûs aux choix de principes ARP
Analyse de risques dûs aux choix d’architecture fonctionnelle ARAF
Analyse de risques dûs aux choix d’architecture technique ARAT
Analyse de risques liés aux défaillances techniques type AMDEC

Dans ce court exposé, nous n’aborderons que les trois premiers niveaux.

Analyse de risques liés à l’environnement

Il est quasiment devenu commun d’énoncer que la maîtrise des risques repose, en amont, sur une expression

– des besoins rigoureuse … mais cela ne suffit pas :
– quels critères définissent la  » rigueur  » ?
– de quels besoins parle-t-on ?
– quels liens entre les besoins liés au système à créer et les besoins/contraintes du spécificateur ou du concepteur en tant qu’organisation intervenante ?

On peut définir la  » rigueur  » par un certain nombre de qualificatifs :

– objectivité, exhaustivité ou complétude,…,
mais n’est-ce pas aussi la capacité à mettre en évidence les informations manquantes pour exprimer les besoins, la capacité à différencier ce qui relève soit du système à faire soit des exigences du projet ??

L’incomplétude des spécifications est un des principaux facteurs de dérive des projets : les documents de spécifications sont souvent volumineux, mais, malgré tout :

– mal structurés : les informations sont mélangées, et souvent redondantes, associant différents niveaux de spécifications : exigences, contraintes, principes imposés, besoins liés au réel but final et besoins liés à des choix de réalisation, d’intégration, de soutien…

– souvent incomplets : les services à rendre en mode nominal sont exprimés et détaillés, mais :
– que requiert-on du système si un de ses milieux extérieurs dysfonctionne ?
– que requiert-on du système en cas de défaillance d’une de ses fonctions ?

Ces derniers aspects, généralement nommés  » modes dégradés « , sans distinction de l’origine de la dégradation (milieu extérieur ou système lui-même), sont souvent abordés de manière technique que fonctionnelle, et cela parfois tard dans le déroulement du projet, entraînant des itérations coûteuses, si ce n’est des  » verrues  » car il n’est plus possible de remettre en cause les choix technologiques déjà faits.

afitep_3

Ce que nous proposons :

– une expression de besoins structurée, distinguant :
– les exigences liées aux contextes d’utilisation (but final), en précisant objectivement les critères de disponibilité et sécurité requis , en identifiant les impacts fonctionnels des dégradations des milieux extérieurs, et ceux des indisponibilités  » admises  » du système nominal,
– les contraintes que l’on impose pour les autres phases de vie du système,
– les principes de conception impos

une analyse de risques liés à l’environnement:
ayant pour objectifs d’apporter des informations pertinentes pour cette expression de besoins, et de structurer l’exploitation du retour d’expériences :
Il s’agit ici de s’appuyer sur l’objectivité qui naît d’un raisonnement non lié à la description du système (base, le plus souvent, du retour d’expériences), mais à celles de ses actions sur ses milieux extérieurs,
Inventorier toutes les causes possibles de  » dangers  » pour chaque milieu extérieur est illusoire : comme tout inventaire, il se limitera à celui des causes connues, si tant est que l’on puisse se mettre d’accord sur la définition du terme cause (s’agit-il de la cause immédiate, des enchaînements de faits ayant abouti, de causes origine, etc…
Un couplage entre des méthodes de créativité (associations, analogies,..), l’analyse fonctionnelle et des règles de structuration des connaissances est ici proposé, à travers la notion de  » flux agressif « .
Les causes sont innombrables : par contre les types de  » flux  » pouvant créer un danger pour le système, ou auxquels ses milieux extérieurs sont sensibles, sont en nombre limité, flux de matières, flux de fluides, flux d’informations, flux  » psychologique « , flux électromagnétique, flux chimique…

afitep_4

Il s’agit alors, par rapport à une liste-type de flux, d’identifier sa  » dangerosité  » pour chaque milieu extérieur et pour le système, et définir les niveaux d’acceptabilité de risque ainsi que les responsabilités qui en découlent pour le milieu extérieur ou pour le système.

Analyse de risques dus aux choix de principes

Tout choix comporte potentiellement un risque.
Un principe est ici un mode d’action pour satisfaire une fonction : principe logique en amont, il devient principe technologique.

– Ce que nous proposons :
– une logique de conception affichant les choix de principes:
selon l’arbre des voies technologiques de la méthode APTE® (1), soit une décomposition arborescente par fonction, alternant :
– inventaire des principes possibles, et exercice de la logique de choix : selon les critères de valeur de la fonction-mère, selon les critères projet,
– pour le principe ou l’association de principes répondant aux critères, identification de la chaîne fonctionnelle juste nécessaire pour le réaliser (ensemble de fonctions élémentaires),
– pour chaque fonction élémentaire, poursuite du même raisonnement : inventaire des principes possibles, logique de choix, décomposition,..
– une analyse des risques associée à ces choix de principes.
Pour un principe donné, cette analyse comporte plusieurs aspects :
– risques intrinsèques au principe lui-même,
– risques liés à la mise en oeuvre du principe dans un environnement donné
– risques liés à l’association de principes pour répondre à une même fonction : Principes différents ou identiques, associés en simultané ou en séquentiel, ou sous telle condition contextuelle,l’analyse se situe alors sur la/les fonctions d’association, qui gèrent/pilotent cette association, en fonction du contexte, du temps et des états des principes: contrôle des états initiaux des principes, initialisation de chaque principe selon ordre unique ou multiple, contrôle de réalisation, …
risques liés à l’incompatibilité de principes pour des fonctions distinctes.

Le choix résulte alors :
– des types et niveaux d’acceptabilité des risques,
– des voies de solutions pour les résoudre et de leurs impacts économiques.
Cette démarche peut s’appliquer à tout choix de principe, mais dans le cadre de projets de systèmes complexes, son application systématique est illusoire voire non pertinente .

Il s’agit de l’appliquer pour les « fonctions à risques », liées au système à faire ou au système pour faire. Ces fonctions peuvent être repérées de par :
– des objectifs forts de disponibilité et/ou sécurité,
– le degré d’innovation introduit au niveau des besoins ou des choix de conception,
– l’importance des facteurs humains dans l’obtention des résultats visés,
les enjeux économiques associés,…

Analyse de risques, Architectures Fonctionnelle et Technique

Pour ces analyses, nous ne citerons ici, pour illustrer la démarche, que les points qu’elles permettent de traiter :
– au niveau des choix d’architecture fonctionnelle, il s’agit des risques :
– liés au regroupement de fonctions :
choix d’un principe commun pour deux fonctions distinctes, ou mise en commun d’une fonction sur deux chaînes fonctionnelles distinctes : risques liés aux conditions d’utilisation et initialisation de chaque chaîne, aux critères associées, aux impacts de défaillance de l’élément commun,..
– liés à la création de flux parasites,
– liés aux modes de traitement des transitions: entre contextes et entre modes nominaux et dégradés.
au niveau des choix d’architecture technique, il s’agit des risques :
– liés aux fonctions de conception générées (interfaces techniques)
– liés aux chois d’affectation des fonctions élémentaires aux composants.
Ainsi chaque étape comprend alors la justification des choix :
– par rapport aux critères de valeur (besoins fonctionnels)
– en terme de réponse aux critères projet (contexte, organisation, économique)
– en terme d’anticipation et décision de prise en compte des risques.
Cette démarche a également pour résultats :
– génération de tests et validations CIBLES à chaque stade du projet
– clarté des partages de responsabilités entre acteurs/partenaires d’un projet
– traçabilité des raisonnements et des choix entre les différentes phases du projet et entre les différents intervenants
– utilisation ciblée des outils de sûreté de fonctionnement pour des études ponctuelles de validation (simulations dynamiques, graphes Pétri, Markov,…)
– mais aussi :
– capacité de réutilisation du savoir-faire ainsi formalisé, par constitution de référentiels de choix et d’aide à la conception,
– capacité à identifier l’impact d’une évolution sur les choix.

Perspectives….

Une démarche de maîtrise des risques doit être à la fois :

– une démarche structurée de créativité,
– une logique continue d’aide à la décision.
Valider une conception n’est plus alors la validation de la solution (c’est quasiment trop tard), mais devient la validation des logiques de choix pour aboutir à la solution.

C’est ainsi conserver au concepteur son vrai rôle, qui n’est pas à notre sens, de mettre en oeuvre et assembler des éléments de solutions (« intégrateur »), mais de prendre le risques de faire des choix, en améliorant la maîtrise de leurs raisons.
Alors le terme d’architecte ou de systèmier prend toute sa valeur.
Le management des risques ne deviendrait-il pas alors la maîtrise des décisions ?
…. et dans ce sens, un outil de maîtrise de l’innovation ?

Bibliographie risques et conception de système complexe

(1) – Méthode APTE®, Analyse Fonctionnelle et Analyse de la Valeur, propriété intellectuelle de la Société APTE
(2) – L’excellence technologique – MORIN J.- Publi-Union, Paris 1985.
– Maîtrise de la Qualité des Systèmes Industriels – Groupe MACSI – Editions MASSON – 1993
– Analyse Fonctionnelle et Sécurité : une approche Système originale pour la conception et la validation de systèmes de transport complexes. Catherine LAVAL, Jacques VALANCOGNE (RATP). 30 Mai/3 Juin 94.
– L’Atelier d’Analyse Système. Jacques VALANCOGNE et Daniel COINEAU – Colloque PREDIT, 7/9 Février 95.
– La théorie du système général – Théorie de la modélisation. LEMOIGNE – Editions PUF, 1984
– Logiciels-supports : Need (CdCF), Structure (Bloc-diagrammes Fonctionnels – SADT), FMEA (analyse de risques et AMDEC)  et APTE- AVT (arbres des voies technologiques).

© 1999 Catherine Laval. Tous droits réservés

Logiciels méthodologiques en conception

Logiciel analyse fonctionnelle et AMDEC

Webinaire Logiciel Analyse Fonctionnelle

Webinaire Logiciel analyse fonctionnelle Need

Webinaires et salons

Aller au contenu principal