Retour au numéro
... pour échapper à la boule de cristal !
Vue 12 fois
12 octobre 2015

LA PRISE DE DÉCISION POUR UN ARCHITECTE SYSTÈME

Le travail de l’architecte est de transformer un ensemble de besoins en une architecture qui permet d’établir le lien entre des éléments physiques ou informationnels d’un côté, et des fonctions de l’autre, et de définir les relations entre les différents éléments ainsi qu’avec le contexte environnant le système d’intérêt. Pour des systèmes complexes, c’est un véritable défi car les relations complexes entre les paramètres de conception et les alternatives impliquent un espace de recherche défiant les capacités humaines de décision. Malgré la compétence certaine des architectes et leur intuition basée sur l’expertise qu’ils ont pu acquérir dans leur domaine de compétence, il est impossible de faire sérieusement cet exercice décisionnel sans méthode fondée sur des approches formelles.


Les idées maîtresses de la prise de décision sont d’être en présence d’une situation avec de multiples alternatives, de faire alors une sélection selon certains critères dans l’espace de recherche, afin que la solution obtenue apporte un bénéfice attendu. Il est donc essentiel de définir, d’une part, cet espace de recherche en identifiant ses différentes dimensions, et d’autre part le(s) critère(s) d’évaluation quantifiant la valeur de chaque solution, c’est-à-dire une quantité directement en relation avec ce que les clients sont prêts à payer pour obtenir le produit ou le service (suivant la définition due à l’économiste Michael Porter).

Du point de vue formel cela peut se reformuler simplement comme une optimisation multicritère, où l’on cherche à déterminer tous les meilleurs compromis possibles (ensemble des valeurs des paramètres) vis-à-vis de plusieurs objectifs potentiellement antagonistes. Cela se fait en déterminant le « front de Pareto » dans l’espace des critères, c’est-à-dire la frontière entre solutions réalisables et irréalisables, qui correspond à l’ensemble des solutions non dominées (dites Pareto - optimales), caractérisées par le principe suivant : il est impossible de trouver une solution meilleure sur un critère sans qu’elle soit plus mauvaise sur au moins un autre critère. La figure illustre ce concept dans un cas simple.

Ainsi, dans sa thèse soutenue en 2008 au MIT, intitulée « A Framework for Decision Support in Systems Architecting », Willard Lennox Simmons a calculé le front de Pareto correspondant aux choix architecturaux possibles pour un système permettant d’envoyer un équipage sur la Lune et de le ramener, en analysant deux paramètres clés : la masse initiale nécessaire pour mise sur orbite basse terrestre ; la probabilité de réussite de la mission. Il se trouve que la solution soviétique, les solutions initialement prônées par Wernher von Braun, et la solution finalement choisie pour la mission Apollo, se trouvent toutes sur ce front de Pareto, mais à des endroits fort variés : la solution soviétique a une très faible masse initiale et une probabilité de réussite faible ; les solutions proposées par W. von Braun ont une probabilité de réussite haute mais une masse initiale également élevée ; les concepts étudiés dans le cadre de la mission Apollo se situent entre ces solutions extrémales.

Exemple (simpliste) de problème de minimisation de deux critères p1 et p2. La ligne continue représente le front de Pareto qui relie les solutions non dominées (les points A et B sont des exemples de telles solutions). Les autres points plus clairs correspondent à des solutions dominées.

Mais le front de Pareto n’est qu’un ensemble de solutions optimales du point de vue formel, et le véritable travail d’architecture va être de ne pas s’arrêter à ce travail d’optimisation. En effet, l’analyse de l’espace des solutions et en particulier la recherche d’éventuels sous-ensembles – obtenus par exemple par des algorithmes de « clustering » bien connus en analyse des données – regroupant de nombreuses solutions architecturales (nécessairement dominées) peuvent apporter des renseignements très intéressants sur les familles d’architectures répondant à un problème donné. Si l’on reprend les travaux faits dans la thèse précitée, on peut ainsi classer les architectures en familles, correspondant à des missions respectivement directes (« à la Tintin » avec une fusée qui part de la Terre et alunit), avec rendez-vous terrestre, avec rendez-vous lunaire.

Une telle analyse de l’espace des solutions architecturales permet éventuellement de remettre en question certains critères d’évaluation, voire de remonter dans le cadre du processus d’ingénierie vers une potentielle remise en question des exigences ou tout au moins des plans de validation de ces dernières. On voit ici tout l’intérêt de cette démarche dans des études d’architecture capacitaire (les critères incluraient alors différentes mesures d’efficience, des probabilités de succès, des dimensions temporelles, des indices de coût…) avec des allers - retours en amont du cycle de vie.

De plus, il faut souligner qu’une solution sur le front de Pareto a le défaut d’être potentiellement sensible à une variation paramétrique. En reprenant l’exemple simpliste illustré dans la figure, si par exemple le point B est entaché d’une petite erreur, le front de Pareto va se déplacer en passant cette fois par des solutions qui étaient précédemment dominées. Afin de pallier cette sensibilité paramétrique, il est donc nécessaire d’étudier le voisinage du front de Pareto et d’y identifier là encore d’éventuels sous-ensembles.

Et n’oublions pas que tout ce qui précède a été fait à un certain niveau de modélisation. Il convient éventuellement, de manière récursive, de refaire les mêmes analyses (optimisation, recherche de regroupements, analyse de sensibilité paramétrique) pour des modélisations plus ou moins fines.

« comprendre la structure de l’espace des solutions et l’interpréter en termes de familles d’architectures » 

L’architecte : un décideur, et pas un simple utilisateur d’outils

En conclusion, l’architecture système, en particulier quand elle est faite dans le cadre de systèmes de complexité croissante (architectures de systèmes de systèmes, architectures capacitaires ou d’entreprise…), ne peut se concevoir comme un simple exercice où l’expert se baserait sur son expérience passée et quelques compromis éventuellement appuyés par quelques simulations. Il est nécessaire de définir, en fonction du niveau de modélisation du système choisi, simultanément l’espace des solutions et les critères d’évaluation, puis de ne pas se contenter d’un calcul d’optimisation multicritère, mais bien de comprendre la structure de l’espace des solutions et de l’interpréter en termes de familles d’architectures.

C’est rassurant : l’architecte n’est donc pas simplement un manipulateur d’outils aussi sophistiqués soient-ils, mais a une réelle valeur ajoutée pour « décider », c’est-à-dire étymologiquement « séparer » entre les solutions qui se présentent à lui.  

 

Références

- A Framework for Decision Support in Systems Architecting. Willard Lennox Simmons. PhD soutenu au Massachusetts Institute of Technology (2008).

- System architecture: strategy and product development for complex systems. E. Crawley, B. Cameron, D. Selva. Pearson Higher Education, Inc., Hoboken, NJ (2016).

 

    
Dominique Luzeaux, IGA
Dominique Luzeaux a occupé à la DGA des fonctions d’architecte et de direction de projets dans les domaines des systèmes d’information, d’observation, de renseignement, de la robotique ou des systèmes terrestres. Il a écrit une dizaine d’ouvrages sur l’ingénierie système et est enseignant chercheur rattaché à la chaire d’ingénierie des systèmes complexes de l’Ecole Polytechnique.
 

Auteur

Articles liés par des tags

Commentaires

Aucun commentaire

Vous devez être connecté pour laisser un commentaire. Connectez-vous.