Éléments de systémique. Architecture des systèmes
Texte intégral
1. Introduction
1Les systèmes que l’homme architecture et fabrique sont au cœur du monde moderne : il suffit, de fait, de penser aux systèmes sociaux et politiques, aux systèmes économiques et industriels, aux systèmes monétaires et financiers, aux systèmes de production et distribution d’énergie, aux systèmes de transport, aux systèmes de communication et plus généralement aux très nombreux systèmes organisationnels et technologiques qui nous entourent, pour se rendre compte que les systèmes « ingéniérés » sont simplement partout1.
2Tous ces systèmes sont, de plus en plus, caractérisés à la fois par une très grande complexité intrinsèque et par des interdépendances toujours croissantes. La maîtrise de ces systèmes est donc devenue un vrai enjeu, dans un monde en profonde transformation où ils doivent pouvoir résister à la pression constante et souvent contradictoire des citoyens et des consommateurs, des marchés et de la règlementation, de la concurrence et de l’innovation technologique, pour ne citer que quelques exemples de forces auxquelles ils sont soumis2.
3Mais maîtriser la complexité d’un système, c’est fondamentalement être capable de maîtriser son processus d’intégration, autrement dit sa construction par interconnexion et/ou mise en réseau de systèmes de plus petite taille. Ce processus reste sans doute encore largement incompris, dans la mesure où il génère le phénomène mystérieux qu’est l’émergence : un système intégré aura, en effet, toujours des propriétés nouvelles – dites « émergentes » – qui ne peuvent pas facilement s’obtenir ou s’exprimer avec ses briques de base.
4Penser l’intégration d’un système complexe hétérogène, résultant de l’interaction de plusieurs systèmes homogènes, nécessite par conséquent de raisonner transversalement en construisant des modèles d’un type nouveau, qui capturent l’émergence en intégrant de manière cohérente les parties de chaque modèle homogène constitutif d’un modèle systémique d’ensemble. Or force est de constater que rien ne nous prépare à ce nouveau paradigme qu’est le raisonnement systémique, qui oblige à mettre en relation des savoirs de nature extrêmement différentes et à transcender les silos traditionnels d’organisation de la connaissance.
5L’émergence d’une vraie science des systèmes – la systémique – capable d’aborder de façon rigoureuse les nombreux problèmes que posent la conception et la gestion de l’évolution des systèmes complexes modernes est donc d’une urgente nécessité, si l’on veut pouvoir apporter des réponses satisfaisantes aux nombreux défis de nature profondément systémiques que l’humanité va devoir relever à l’aube du troisième millénaire. Ce petit article de synthèse se veut ainsi une contribution modeste, mais résolue, à cette nouvelle discipline scientifique naissante en proposant une vision intégrée de l’architecture des systèmes, i.e. de la partie de la systémique qui s’intéresse à la structure des systèmes et à leurs processus de conception.
2. Qu’est qu’un système ?
2.1. Des systèmes réels aux systèmes formels
6Quand on parle de « système » en systémique, il est fondamental de comprendre que l’on se place dans une logique de modélisation, ce qui amène immédiatement à faire la distinction entre les concepts de « système réel » et de « système formel ».
7Le processus de modélisation systémique peut en effet être vu comme un aller-retour permanent entre un processus de formalisation qui consiste à construire un modèle formel abstrait d’un objet du monde réel, en utilisant les outils de l’analyse systémique, et un processus d’expérimentation, qui consiste à vérifier que la structure ou le comportement de l’objet réel, donné ou prédit par le modèle, sont bien ceux que l’on observe dans la réalité. L’objet réel ne sera donc considéré comme un système (réel) que parce qu’un processus de modélisation l’analyse comme un système (formel) au sein d’un cadre de modélisation systémique. Par abus de langage, on identifie bien entendu souvent ces deux notions de « système », mais il est important de ne jamais oublier que « la carte n’est pas le territoire »4 pour bien savoir à tout moment sur quoi on raisonne !
2.2. Définition d’un système
8Ces préliminaires étant posés, nous sommes maintenant bien armés pour donner nos deux premières définitions clefs, à savoir celles d’un système formel et d’un système réel.
Définition 2.1 : Système formel. Un système formel S est caractérisé, d’une part, par la donnée d’ensembles d’entrées X, de sorties Y et d’états internes Q, et, d’autre part, par les deux types de comportements suivants qui lient ces variables systémiques au cours du temps :
– un comportement fonctionnel qui produit une sortie y(t) Y à tout moment t du temps en fonction d’une entrée x(t) X et de l’état interne courant q(t) Q du système ;
– un comportement interne qui fait évoluer l’état interne q(t) Q du système au cours du temps t sous l’action d’une entrée x(t) X du système.
9Cette définition est volontairement extrêmement faible, car elle revient simplement à dire qu’un système est la donnée d’un comportement entrée/sortie et d’un comportement interne 5. Cela n’est pas anormal, car il s’agit bien de capturer les points communs existants entre TOUS les systèmes réels, qui sont mécaniquement très limités vue la diversité des objets dont il faut rendre compte. En revanche, nous disposons maintenant d’un cadre unifié dans lequel nous allons pouvoir raisonner de manière homogène sur tout type de système et donc penser l’intégration, ce qui était le premier de nos objectifs6.
Définition 2.2 : Système réel. Un objet du monde réel sera appelé un système réel dès lors que sa structure et son comportement sont susceptibles d’être décrits par un système formel (au sens de la définition 2.1), que l’on appellera alors un modèle du système réel.
La quasi-totalité des réalisations humaines – qu’elles soient de caractère électro-mécanique, informatique ou organisationnelle – sont dès lors analysables comme des systèmes : seules changent la nature des lois (en l’occurrence physiques, logiques ou sociologiques) qui permettent de définir les comportements fonctionnels et internes qui en font des systèmes. Les définitions précédentes permettent aussi de bien se rendre compte que ce n’est ni la nature, ni la taille, ni le positionnement hiérarchique7 qui fait un système, puisque presque tout objet peut être vu comme un système. Considérer qu’un objet est un système reste d’abord un choix de modélisation : cela revient en effet à dire qu’on va abstraire un tel objet pour ne l’analyser plus que sous un angle systémique, i.e. dans le cadre donné par la définition 2.1.
10Signalons enfin qu’à partir de maintenant, nous ne donnerons nos définitions que pour les systèmes formels sachant qu’elles se transfèrent directement aux systèmes réels, compte tenu du point de vue du modélisateur que nous avons pris ici.
2.3. Intégration de systèmes
11Nous sommes maintenant armés pour introduire la notion d’intégration de systèmes, qui est le mécanisme fondamental permettant en pratique de construire un nouveau système à partir d’autres systèmes (matériels, logiciels, humains) de plus petite dimension, en les organisant de façon à ce qu’il puisse accomplir – au sein d’un environnement donné – ses missions.
Définition 2.3 : Intégration. Soit S1, …, SN un ensemble de N systèmes (formels). On dira alors qu’un système (formel) S est le résultat de l’intégration de ces systèmes s’il existe, d’une part, un système (formel) C obtenu par composition des systèmes S1, …, SN et, d’autre part, des mécanismes duaux d’abstraction et de concrétisation8 qui permettent d’exprimer :
– le système S comme une abstraction du système C,
– le système C comme une concrétisation du système S.
Cette définition un peu technique a pour but fondamental de positionner l’intégration comme un mécanisme différent d’une simple composition de modèles, pour essayer de capturer structurellement l’émergence dans notre approche.
12Notre définition met en effet clairement en évidence le fait que la description d’un système de haut niveau, obtenu par interconnexion d’autres systèmes, nécessite de disposer :
– des modèles de chacun des systèmes constitutifs du système de haut niveau,
– d’un nouveau modèle de haut niveau propre à ce système.
13Autrement dit, la simple connaissance des modèles des constituants d’un système n’est jamais suffisante pour modéliser ce système ! Ce postulat de modélisation peut se voir comme la traduction directe du phénomène universel qu’est l’émergence. Il peut par ailleurs se vérifier sur tous les systèmes élémentaires de la vie courante. Considérons, à titre d’exemple, un mur formé uniquement de briques (sans ciment pour les lier) pour simplifier les choses. Un modèle systémique simplifié d’une brique peut alors être caractérisé par :
– un comportement fonctionnel consistant à absorber les rayons de lumière,
– un comportement interne donné par des états « longueur, largeur, hauteur » invariants.
14En composant des modèles de briques, il sera, de ce fait, difficile d’obtenir autre chose qu’un comportement fonctionnel consistant à absorber les rayons de lumière, ce qui n’est clairement pas le comportement usuel d’un mur, car on veut pouvoir rendre compte des trous existant dans les murs (les fenêtres) qui eux doivent laisser passer justement la lumière ! On notera également qu’il est difficile – et sans doute vain – de vouloir exprimer la forme d’un mur (qui est l’un de ces états internes typiques) en fonction des longueurs, largeurs et hauteurs des briques qui le composent. Tout cela plaide donc pour le fait qu’il va falloir bien évidemment créer un modèle systémique dédié, plus abstrait, pour modéliser le mur.
15Ces constations ont peut-être l’air d’être frappées du bon sens, pour ne pas dire naïves ; mais on constate malheureusement que leurs conséquences ne sont le plus souvent pas comprises, ce qui est à l’origine directe de bien des problèmes de non qualité observés au niveau des grands systèmes ingéniérés modernes. La plupart des industriels continue, en effet, toujours à penser que la maîtrise des composants d’un système intégré est suffisante pour maîtriser le système dans sa globalité. Or la nature même du mécanisme d’intégration impose de devoir ne pas se contenter uniquement de responsables de composants quand on doit concevoir un système intégré : il faut aussi disposer d’un responsable en charge spécifiquement du modèle intégratif de haut niveau du système, i.e. d’un architecte de systèmes, qui est en fait souvent inexistant dans les organisations industrielles9, aussi étrange que cela puisse paraître !
16Signalons enfin que le mécanisme d’intégration hiérarchise naturellement les systèmes tout en donnant une dimension récursive à l’analyse systémique. Les systèmes ingéniérés sont, en effet, obtenus par intégrations successives de systèmes : tout système intégré engendre donc une hiérarchie d’intégration, qui est également une hiérarchie d’abstraction compte tenu de la nature de l’intégration, appelée la hiérarchie systémique du système initial, qui permet de parler des niveaux système, sous-systèmes, sous-sous-systèmes, etc., d’un système intégré.
3. Organisation d’un modèle systémique
3.1. Visions architecturales d’un système
17L’approche systémique consiste à analyser les systèmes réels sous forme de systèmes formels, qui sont donc des modèles à identifier, à travers un prisme systémique où l’on ne pense qu’en termes de systèmes en interaction. Le caractère récursif de l’analyse systémique amène alors, mécaniquement, à introduire la notion d’environnement d’un système, qui dénote un sur-système fermé (i.e. sans entrées, ni sorties) du système qui forme donc une base naturelle pour pouvoir démarrer un processus d’analyse récursive d’un système (cf. la section 4, ci-dessous).
Définition 3.1 : Environnement d’un système. Soit S un système (formel). On dira alors qu’un système (formel) E(S) est un environnement pour S s’il s’agit d’un système (formel) fermé 10 qui résulte de l’intégration de S et d’un autre système (formel) Ext(S), que l’on appellera l’extérieur de S dans l’environnement E(S).
18Un système réel a, bien entendu, plusieurs systèmes « environnements » (réels) au sens de la définition 3.1 (l’univers physique dans son ensemble est typiquement un environnement commun à tout système réel). Les contraintes pragmatiques d’un processus de conception systémique d’un système (réel) S donné conduisent, cependant, à introduire un environnement de référence pour S (qui est appelé souvent l’environnement de S tout court, par un léger abus de langage), correspondant au plus petit environnement « utile » de S : celui-ci n’est autre, en effet, que le système résultant de l’intégration du système S et de tous les systèmes (réels) externes à S qui ont une influence sur sa conception, en négligeant, par conséquent, tous les autres systèmes (réels) externes à S quand on estime qu’ils n’ont aucune interdépendance (et donc aucune interaction fonctionnelle) avec le système à concevoir 11.
19On notera maintenant que tout ce qui suit sera désormais relatif à un choix d’environnement pour un système qui sera donc toujours considéré comme fixé a priori, ce qui permettra de parler sans abus de langage de « l’environnement » d’un système. On peut alors naturellement poser les définitions suivantes qui modélisent le fait que l’environnement d’un système S définit mécaniquement une frontière entre l’intérieur et l’extérieur de S.
Définition 3.2 : Intérieur & extérieur. Soit S un système (formel), E(S) son environnement (formel) et Ext(S) son extérieur (formel) dans cet environnement au sens de la définition 3.1. On dira alors qu’un système (formel) I (resp. E) est dans l’intérieur (resp. l’extérieur) de S si le système S (resp. le système Ext(S)) peut être obtenu par intégration de I (resp. E) et d’un autre système (formel) U (resp. V), nécessairement dans l’intérieur (resp. l’extérieur) de S.
20En pratique, poser cette frontière entre l’extérieur et l’intérieur d’un système (réel) est, en fait, le premier acte clef de modélisation, puisqu’il permet de définir clairement le système, ce qui est en général toujours difficile à faire dans la réalité. On notera aussi que ce distinguo est au cœur de la séparation des visions architecturales utilisées en analyse systémique (cf. ci-après), et notamment de la définition de la première vision architecturale d’un système (réel), dite opérationnelle, qui synthétise les interactions de l’extérieur du système avec le système.
21Nous sommes maintenant armés pour introduire les notions de visions architecturales d’un système. Attention : il s’agit là de concepts de modélisation, qui se réfèrent donc uniquement à un système réel, contrairement aux définitions précédentes qui avaient toutes une acception commune valables à la fois pour les systèmes formels et réels.
Définition 3.3 : Visions architecturales. Soit S un système réel constitué par intégration d’un ensemble C(S) de systèmes concrets de plus petite taille. On peut alors introduire les trois grandes catégories suivantes de modèles, formant ses visions architecturales :
– un modèle opérationnel de S (par abus de langage) est la donnée d’un système formel constituant un modèle de l’extérieur de S ;
– un modèle fonctionnel de S est la donnée d’un système formel qui est un modèle non organique de S (cf. ci-dessous) ;
– un modèle organique de S est la donnée d’un système formel modélisant S, obtenu par composition de systèmes formels modélisant les systèmes concrets de C(S).
22On notera tout d’abord que la définition 3.3 est bien consistante, car l’existence de modèles fonctionnels non organiques est directement liée au postulat de l’émergence (cf. paragraphe 2.3) qui affirme, rappelons-le, que la simple connaissance des composants concrets d’un système et de leurs lois d’interaction n’est jamais suffisante pour décrire le comportement d’un système intégré résultant de leur interconnexion. Cela explique pourquoi il existe toujours des modèles purement fonctionnels d’un système dont le rôle est bien d’exprimer les fonctions émergentes que l’on ne pourra pas lire au niveau organique12.
23On comprend également maintenant pourquoi il est nécessaire d’avoir trois types de modèles pour modéliser en pratique un système réel : la vision opérationnelle capture, en effet, le point de vue externe, tandis que les vues fonctionnelle et organique capturent le point de vue interne, en modélisant respectivement, d’une part, les comportements émergents et, d’autre part, la constitution concrète du système considéré.
24Cela étant précisé, il est utile de souligner que les visions architecturales jouent un rôle clef en architecture des systèmes : le premier travail d’un architecte de systèmes va, en effet, consister à classer les éléments de modélisation dont il dispose, qui mélangent le plus souvent, en pratique, de nombreux niveaux conceptuels, selon la grille de la définition 3.3, de manière à obtenir des modèles homogènes, capturant chacun une vue bien délimitée.
3.2. Propriétés d’un système
25La première manière d’analyser systémiquement un système consiste à décrire les propriétés auxquelles il doit satisfaire, ce qui donne naissance aux modèles logiques de description des systèmes que sont les exigences (qui sont typiquement utilisées en pratique comme outils de spécification pour écrire les cahiers des charges d’ingénierie).
Définition 3.4 : Exigence. Soit S un système (formel). Toute propriété logique (temporelle ou non) exprimable dans le langage de S, c’est-à-dire en faisant intervenir ses entrées, ses sorties et ses états, sera alors appelée une exigence du système S.
Dire qu’un avion est sûr revient par exemple à imposer une exigence de sûreté sur le système « avion », consistant à affirmer qu’il n’existe pas de moment du temps où ce système est dans l’état « Catastrophique » (qu’il faudra bien sûr avoir défini précisément et intégré au préalable dans le modèle de l’avion pour pouvoir exprimer l’exigence de sûreté précédente).
26Nous pouvons maintenant croiser cette notion générique d’exigence avec toutes les visions architecturales définies au paragraphe précédent, ce qui nous conduit à la définition suivante.
Définition 3.5 : Besoin, exigence fonctionnelle et exigence organique. Soit S un système réel. On dira alors qu’une propriété logique est :
– un besoin s’il s’agit d’une exigence d’un modèle opérationnel de S ;
– une exigence fonctionnelle s’il s’agit d’une exigence d’un modèle fonctionnel de S ;
– une exigence organique s’il s’agit d’une exigence d’un modèle organique de S.
Ces trois concepts sont fondamentaux car tout le raisonnement architectural consiste à partir de besoins, c’est-à-dire de propriétés attendues par l’extérieur du système (ce que veulent les « clients » du système), pour les traduire en exigences fonctionnelles (ce que doit faire le système), puis en exigences organiques (comment doit être formé concrètement le système).
27En pratique, une difficulté majeure consiste à organiser selon la grille de la définition 3.5 les propriétés qui apparaissent empiriquement dans un processus d’ingénierie. Il est, en effet, très facile d’énoncer des propriétés qui mélangent gaillardement les trois visions architecturales : du point de vue du fabricant de véhicules militaires, la propriété « les soldats doivent se déplacer dans un véhicule de transport de troupes peint en vert » n’est ainsi ni un besoin, ni une exigence sur le système « véhicule de transport », car elle combine des éléments externes (les soldats) et des éléments internes (la peinture du véhicule). Le raisonnement architectural nécessite de réécrire cette propriété sous la forme d’une exigence organique : « le véhicule doit avoir la couleur verte », ce qui pose ensuite immédiatement la question de savoir quel était le besoin (non formulé) des soldats… On peut aisément comprendre sur cet exemple qu’il manque ici une exigence fonctionnelle sur le véhicule, à savoir « le véhicule doit être invisible », qui elle-même est directement dérivée d’un besoin très simple des soldats : « les soldats ne doivent pas mourir en opérations » ! En faisant ce raisonnement, on rend alors explicite le rôle du terrain d’opérations dans l’environnement du système de transport cible, ce qui permettra de se rendre compte que le choix de la peinture verte est peut-être bien adapté aux terrains boisés européens, mais sans doute nettement moins aux sables du Golfe où des peintures ocres ou caméléons seront beaucoup plus efficaces pour couvrir le besoin primitif des soldats, rendu maintenant clairement explicite.
3.3 Descriptions d’un système
28La seconde manière d’analyser systémiquement un système consiste à décrire explicitement ses comportements sous la forme de descriptions symboliques dans une syntaxe (formelle) ad hoc, autrement dit à faire ses « plans ». Les visions architecturales introduites par la définition 3.2 permettent alors à nouveau de poser les définitions suivantes.
Définition 3.6 : Descriptions opérationnelles, fonctionnelles & organiques. Soit S un système réel. On dira alors qu’une représentation symbolique de ce système est :
– une description opérationnelle s’il s’agit d’une partie d’un modèle opérationnel de S ;
– une description fonctionnelle s’il s’agit d’une partie d’un modèle fonctionnel de S ;
– une description organique s’il s’agit d’une partie d’un modèle organique de S.
29On notera que la définition même d’un système (formel) permet naturellement d’organiser chaque description d’un système selon les axes suivants qui capturent toutes les composantes possibles d’un tel modèle (formel) du système :
(1) une représentation (statique) listant les états ;
(2) une représentation (statique) listant les entrées / sorties ;
(3) une représentation de la dynamique d’évolution des états ;
(4) une représentation de la dynamique du comportement entrée / sortie.
30Pour des raisons pratiques, on regroupe le plus souvent les représentations de type (1) et (3) en une seule représentation – sous forme d’automate fini –, centrée sur les états qui donne à la fois leur liste et leur dynamique d’évolution, et on casse la représentation de type (4) en deux représentations, la première listant simplement de manière statique les composants nécessaires à la seconde, centrée sur la modélisation de la dynamique des comportements du système. La figure 10 illustre ainsi sur un exemple (en faisant ici abstraction de la représentation des entrées / sorties) ce mode d’organisation des descriptions d’un système.
3.4. Référentiel d’analyse systémique
31En synthèse, nous avons donc fait clairement apparaître qu’un système réel est susceptible d’être analysé selon les trois angles donnés par ses visions architecturales (opérationnelle, fonctionnelle, organique), ses propriétés et ses descriptions.
32Si l’on intègre en plus le fait qu’un système a aussi une hiérarchie systémique (ses niveaux système, sous-systèmes, sous-sous-systèmes, etc.), on comprend qu’un système est un objet fondamentalement multi-dimensionnel qu’il va être structurellement difficile à analyser, vu qu’il faut non seulement comprendre chacun de ses composants architecturaux, mais aussi l’ensemble de leurs relations !
33On notera enfin que toutes nos considérations peuvent se synthétiser dans le cube d’analyse architecturale de la figure 12 qui propose une organisation générique d’un modèle systémique d’un système réel et qui constitue donc par excellence le référentiel de l’analyse systémique (qui consiste à analyser un système réel selon les différents axes de ce cube).
4. Architecture d’un système
4.1. Vision systémique du processus d’architecture de systèmes
34Nous avons mis en évidence, dans la section précédente, les structures universelles qu’ont tous les systèmes, ce qui a permis notamment de dégager un mode d’organisation universel d’un modèle systémique. On peut de même noter que les problèmes de conception systémique ont également une structure universelle commune, puisqu’ils consistent « simplement » à faire des preuves constructives13 de théorèmes qui ont (théoriquement) tous la même forme suivante :
Théorème : Il existe un système S qui satisfait à un ensemble B de besoins.
Équation 1 : Structure universelle d’un énoncé de conception systémique.
On comprend ainsi mieux pourquoi l’existence d’un algorithme universel d’identification et de construction d’un modèle systémique, que nous appellerons le processus d’architecture des systèmes, n’est pas du tout anormale. C’est ce dernier processus que nous allons maintenant présenter rapidement dans ce dernier chapitre de notre article.
35Notons d’abord que le processus d’architecture des systèmes n’est que la vision fonctionnelle de l’organisation en charge de ce processus, autrement dit la trace fonctionnelle d’un système de conception architecturale, qui peut donc s’analyser systémiquement (cf. figure 13) ! Cette « boucle étrange »14, très caractéristique de la réflexivité de la systémique qui peut se servir, comme les mathématiques, de ses propres outils pour étudier son fonctionnement interne, permet d’utiliser le référentiel d’analyse architecturale introduit au chapitre précédent pour décrire le processus d’architecture des systèmes, comme nous allons maintenant le faire.
4.2. Visions architecturales du processus d’architecture de systèmes
36Comme nous l’avons souligné plus haut, toute démarche d’analyse systémique consiste d’abord à identifier l’environnement d’un système. Dans le cas du système de conception architecturale, celui-ci n’est autre que l’environnement du processus d’ingénierie dont le processus d’architecture des systèmes est une composante : ce dernier est typiquement formé de l’entreprise dans laquelle le processus se déploie, de ses concurrents et de ses clients, des utilisateurs, des opérateurs et des fournisseurs avec lesquels il interagit et des règlementations et des technologies dont il doit tenir compte.
37Faire l’analyse opérationnelle du système de conception architecturale revient alors à se poser la question de savoir quel est le service que le processus d’architecture des systèmes rend à son environnement : on rappellera juste, à ce propos, que l’architecture des systèmes a pour mission de permettre la maîtrise des projets de conception et d’évolution des systèmes, dans le respect de leurs contraintes de coût, délai, qualité et performance. Vu de l’extérieur, le système de conception architecturale a donc principalement pour but d’aider les acteurs d’un projet de fabrication ou de transformation d’un système à agir en permanence de manière synchronisée, condition sine qua non de la réussite de toute intégration, en s’appuyant sur des modèles globaux, exhaustifs, cohérents et partagés.
38Au niveau fonctionnel, les activités du processus d’architecture des systèmes sont très simples à décrire puisqu’elles dérivent mécaniquement du référentiel d’analyse systémique introduit au chapitre précédent. Celles-ci peuvent en effet se séparer naturellement en activités :
(1) d’architecture des besoins & des exigences d’un système (réel) qui ont pour objectif de formaliser ses besoins et ses exigences fonctionnelles et organiques ;
(2) d’architecture opérationnelle, fonctionnelle et organique d’un système (réel) qui ont pour but de construire ses modèles opérationnels, fonctionnels et organiques ;
(3) de vérification & validation qui consistent en remontée de cycle à garantir que le système réel satisfait bien à ses exigences et à ses besoins.
Le point clef à souligner ici est que l’on peut associer un processus générique (qu’il serait bien entendu trop long de décrire ici) à chacune de ses activités architecturales, ce qui permet de faire émerger à la fois la méthode universelle de conception de systèmes dont nous parlions plus haut, et une « boite à outils » d’architecture des systèmes. Il est aussi intéressant de donner la dynamique d’ensemble existant entre ces différentes activités.
39Terminons enfin par la dimension organique du système de conception architectural. Celle-ci est constituée de deux grandes composantes :
– les hommes où apparaît notamment le profil clef de l’architecte de systèmes qui a un double rôle de responsable de l’intégration des systèmes techniques et des systèmes humains du périmètre dont il a la charge : construire des interfaces cohérentes au sein d’un système technique nécessite en effet toujours de faire converger les parties prenantes de ces interfaces sur une même vision de leur système ;
– les outils du processus d’architecture des systèmes qui regroupent d’une part des outils logiciels d’ingénierie des exigences & de modélisation comportementale, basés sur des langages de description comme BPMN (Business Process Modeling Notation ; ), UML (Unified Modeling Langage ; ) ou SysML (System Modeling Langage ; ), et d’autre part les outils conceptuels introduits dans le chapitre , sans oublier bien sûr le bon sens et les règles heuristiques & les bonnes pratiques issues de l’expérience.
Conclusion
40Nous espérons que ce petit article aura permis au lecteur de mieux appréhender les enjeux et les problématiques de la systémique. Il n’a bien sûr pas pour prétention de couvrir l’ensemble du périmètre de cette discipline, et il fait volontairement l’impasse sur de nombreux sujets également très importants : dynamiques des systèmes, dimensionnement et optimisation des systèmes, trajectoires d’évolution de systèmes, conception de familles homogènes de systèmes, approches agiles et collaboratives pour le développement de systèmes, gouvernance des systèmes, etc. L’univers des systèmes est en effet un « continent »15, qui forme un réel champ scientifique pour une science des systèmes. La systémique reste cependant encore à construire, nécessairement dans une interaction profonde entre théorie et pratique, malgré les prises de conscience pourtant déjà anciennes – et malheureusement quasiment sans suites – de grands précurseurs comme H. Simon16 ou K.L. von Bertalanffy17. Espérons donc que les défis systémiques que le monde commence à affronter vont enfin lui permettre d’émerger.
Remerciements
Cet article s’est notamment appuyé sur les travaux menés dans le cadre de la chaire École Polytechnique – ENSTA ParisTech – Télécom ParisTech – Dassault Aviation – DCNS – DGA – Thales « Ingénierie des systèmes complexes ».
Bibliographie
Bibliographie succincte
Booch G., Jacobson I., Rumbaugh J., The Unified Modeling Language Reference Manual, 2nde édition, Addison-Wesley, 2004.
Cousot P., Cousot R., Abstract Interpretation, Symposium on Models of Programming Languages and Computation, ACM Computing Surveys, 28(2) :324-328, juin 1996.
Friedenthal S., Moore A.C., Steiner R., A Practical Guide to SysML : the Systems Modeling Language, Morgan Kaufmann OMG Press, 2012.
Hofstadter, Douglas R., Gödel, Escher, Bach: An Eternal Golden Braid, Basic Books, 1979.
Korzybski A., Science and Sanity : an Introduction to Non-Aristotelian Systems and General Semantics, International Nonaristotelian, 1950.
Krob D., « Éléments d’architecture des systèmes complexes », in A. Appriou (éd.), Gestion de la complexité et de l’information dans les grands systèmes critiques, CNRS Éditions, 2009. p. 179-207.
Meadows D.H., Meadows D.L., Randers J., Berhens W.W. III, The Limits to Growth, Universe Books, 1972.
Simon H., « The Architecture of Complexity », Proceedings of the American Philosophica, 106 (6), 467-482, décembre, 1962.
von Bertalanffy K.L., General System Theory : Foundations, Development, Applications, George Braziller, 1976.
White S.A., Miers D., BPMN Modeling and Reference Guide, Understanding and Using BPMN, Future Strategies, 2008.
Notes de bas de page
1 Les systèmes vivants ne seront notamment pas considérés dans cet article, dont le périmètre se limite uniquement aux systèmes ingéniérés, autrement dit aux systèmes artificiels (par opposition aux systèmes naturels) architecturés par l’homme, ce qui couvre déjà un vaste spectre dans la mesure où tant les systèmes techniques que les systèmes organisationnels sont susceptibles d’entrer dans ce cadre conceptuel.
2 Sans oublier les limites intrinsèques des ressources physiques & environnementales de notre planète qu’il est désormais impossible de ne plus tenir en compte. Cf Meadows D.H., Meadows D.L., Randers J., Berhens W.W. III, The Limits to Growth, Universe Books, 1972.
3 Nous utiliserons une brosse à dents électronique pour illustrer les concepts systémiques que nous introduirons dans cet article.
4 Booch G., Jacobson I., Rumbaugh J., The Unified Modeling Language Reference Manual, 2nde éd., Addison-Wesley, 2004.
5 Modélisé par une loi d’évolution de ses variables internes que l’on appellera ici ses « états ».
6 Cf aussi D. Krob D., Éléments d’architecture des systèmes complexes, in A. Appriou (éd.), Gestion de la complexité et de l’information dans les grands systèmes critiques, CNRS Éditions, 2009, p. 179-207.
7 Une erreur courante est notamment de considérer qu’un « sous-système » d’un système (voir paragraphe 2.3 pour plus de détails) n’est pas un système, ce qui n’est bien entendu pas le cas (ce qui permet d’appliquer également les principes de l’analyse systémique à ce niveau).
8 Nous ne préciserons pas ici les notions d’abstraction et de concrétisation qui sont à prendre au sens de la théorie de l’interprétation abstraite (pour plus de détails à ce sujet, voir par exemple Booch G., Jacobson I., Rumbaugh J., The Unified Modeling Language Reference Manual, 2nde éd., Addison-Wesley, 2004).
9 Les modèles de haut niveau des systèmes intégrés étant, par conséquent, souvent aussi quasi inexistants en pratique.
10 C’est-à-dire dont les ensembles d’entrées et de sorties sont vides, ce qui revient à dire qu’il n’a ni entrées, ni sorties.
11 On peut de fait raisonner considérer que Proxima du Centaure a une influence nulle sur la plupart des systèmes ingéniérés terrestres.
12 Pour bien comprendre ce phénomène, prenons l’exemple d’une voiture dont les composants systémiques constitutifs (de haut niveau) sont la caisse, le groupe motopropulseur, l’habitacle, le contact au sol et l’électronique embarquée. L’interaction de ces différents composants permet typiquement de réaliser des fonctions comme la « détection d’obstacles », qui nécessite la coopération d’un radar (placé dans la caisse), d’un calculateur (du ressort de l’électronique embarquée), d’un voyant lumineux (positionné dans l’habitacle), voire du contact au sol ou du groupe motopropulseur si l’on veut agir sur les freins et/ou diminuer le couple moteur lorsqu’un obstacle est trop près d’une voiture. Une telle fonction – dite « transverse » – sera clairement difficilement capturable dans un modèle purement organique de la voiture, où l’on verra des flux échangés entre les différents composants du véhicule sans pouvoir rendre compte de leur logique d’ensemble. Seul un modèle fonctionnel d’ensemble de la voiture permettra donc de capturer la sémantique d’une telle fonction transverse.
13 C’est-à-dire en construisant concrètement un système qui vérifie le théorème à démontrer.
14 Friedenthal S., Moore A.C., Steiner R., A Practical Guide to SysML : the Systems Modeling Language, Morgan Kaufmann OMG Press, 2012.
15 Pour reprendre une expression que Marcel Paul Schützenberger n’aurait sans doute pas reniée.
16 Simon H., The Architecture of Complexity, Proceedings of the American Philosophica, 106 (6), 467-482, Décembre, 1962.
17 von Bertalanffy K.L., General System Theory : Foundations, Development, Applications, George Braziller, 1976.
Auteur
Le texte seul est utilisable sous licence Licence OpenEdition Books. Les autres éléments (illustrations, fichiers annexes importés) sont « Tous droits réservés », sauf mention contraire.
La pluralité interprétative
Fondements historiques et cognitifs de la notion de point de vue
Alain Berthoz, Carlo Ossola et Brian Stock (dir.)
2010
Korčula sous la domination de Venise au XVe siècle
Pouvoir, économie et vie quotidienne dans une île dalmate au Moyen Âge tardif
Oliver Jens Schmitt
2011
La mondialisation de la recherche
Compétition, coopérations, restructurations
Gérard Fussman (dir.)
2011
La prévention du risque en médecine
D'une approche populationnelle à une approche personnalisée
Pierre Corvol (dir.)
2012
Big data et traçabilité numérique
Les sciences sociales face à la quantification massive des individus
Pierre-Michel Menger et Simon Paye (dir.)
2017
Korčula sous la domination de Venise au xve siècle
Pouvoir, économie et vie quotidienne dans une île dalmate au Moyen Âge tardif
Oliver Jens Schmitt
2019