Réflexion sur l'évolution des cadres d'architecture - 1ère Partie

Ali Koudri

Avec l'avènement du numérique, la transformation digitale des entreprises a changé les rapports entre elles. Pour faire face à la demande croissante en termes de services ou de produits, et également se positionner sur de nouveaux segments de marché, les entreprises n'ont pas d'autres choix que de collaborer dans des rapports équilibrés. Cette nécessaire collaboration implique la révision des cadres d'architecture actuels, davantage centrés sur le développement d'une seule et unique entreprise. Dans ces approches, les questions auxquelles ces cadres permettent de répondre concernent en effet l'analyse de ce que l'acceptation d'un contrat ou la tentative de s'imposer sur un nouveau secteur de marché peut impliquer en termes de transformations pour l'entreprise; et de déterminer s'il est opportun ou non de s'y engager. A l'heure où l'on parle d'entreprise étendue, la révolution numérique nous permet de considérer un changement de paradigme et d'adopter une vision moins centrée sur l'entreprise que sur la société en générale. Jusqu'à présent la dure loi de la compétition poussait les entreprises à adopter des comportements agressifs, pouvant se révéler dangereux pour l'environnement, l'économie ou l'homme. Aujourd'hui, nous avons atteint les limites de cette logique, et d'autres logiques beaucoup plus responsables se mettent en place. C'est ainsi que l'on parle d'économie circulaire ou verte. Dans cette série, nous présentons des pistes de réflexions sur l'évolution des cadres d'architecture pour supporter des comportements plus sains des entreprises envers la société.

Une entreprise est semblable à un individu: elle naît, grandit, devient adulte et responsable, puis meurt en laissant un héritage. Dans le vivant, on a bien souvent interprété le darwinisme comme une compétition pour la survie. Par analogie, on a longtemps pensé que la survie d'une entreprise dépendait de sa compétitivité. L'histoire a montré que bien des entreprises ont grandi jusqu'à perdre de leur compétitivité, dû à une augmentation des coûts structuraux et à une perte d'agilité. Certaines de ces entreprises sont simplement mortes, d'autres ont été maintenues pour des raisons stratégiques de souveraineté à grands coups de perfusions. Ca n'est que récemment que cette vision a été réinterprétée plus justement. Comme le soulignait si bien Lynn Margulis, ce ne sont pas les espèces les plus compétitives qui survivent, mais plutôt celles qui coopèrent le mieux. Par exemple, les girafes et les éléphants doivent collaborer pour leur survie; ces deux espèces se complètent dans leurs aptitudes pour anticiper le danger: la girafe a une vue qui lui permet de voir le danger de loin tandis que l'éléphant possède une ouïe qui permet d'entendre le danger avant qu'il n'arrive. Aujourd'hui, on se rend compte que cette analogie fonctionne également pour les entreprises. En effet, les entreprises qui veulent survivre et prospérer ont tout intérêt à collaborer au risque de ne pas pouvoir faire face à l'arrivée de nouveaux entrants bien plus agiles et compétitifs.

Cette idée de collaboration s'illustre parfaitement bien dans le développement d'un système de systèmes qui implique de fait la collaboration entre différentes entreprises dans un rapport gagnant / gagnant à la fois pour les entreprises et pour la société. Au delà des entreprises impliquées, le développement d'un système de systèmes peut amener à remettre en question la législation, les comportements humains (acceptation du système de systèmes) et les enjeux sociétaux. Procéder à une analyse de gap dans cette situation relève de l'exploit car bon nombre de facteurs peuvent échapper au jugement collectif des décideurs. D'un point de vue théorique, le développement d'un système de systèmes nécessite un saut paradigmatique comparé à celui d'un système. Dans le cas de systèmes, on raisonne généralement dans un monde fermé, dans le sens où toutes les hypothèses non connues sont considérées comme fausses. Dans le cas de systèmes de systèmes, on raisonne dans un monde ouvert, dans le sens où toutes les hypothèses non connues restent indéterminées jusqu'à leur résolution. Une autre question importante qui se pose concerne la conservation des connaissances métiers et de la propriété intellectuelle quand les entreprises sont amenées à devoir échanger beaucoup d'informations pour converger vers une solution acceptable pour toutes les parties prenantes. La question centrale que l'on se pose est: comment supporter un processus de développement agile tout en conservant son savoir-faire et sa propriété intellectuelle ?

Dans un projet de grande ampleur, il s'agit pour les différents partenaires industriels d'établir une base d'exigences de haut niveau afin de concevoir une solution répondant aux besoins; exigences qui seront ensuite déclinées en exigences plus techniques dans chacun des périmètres propres aux fournisseurs de solutions. Sur la base des solutions apportées par les partenaires et en utilisant une méthodologie agile, il s'agit de concevoir un système de systèmes qui soit en adéquation avec le besoin et les contraintes, qu'elles soient métiers (certification), environnementales ou législative. Cette méthodologie doit donc être un savant mélange de "bottom-up", de "top-down", résultant de la composition des différentes méthodologies des partenaires. En effet, chaque partenaire apporte un savoir-faire (méthode outillée), ses propres bases de connaissances et des bases d'exigences acquises et consolidées à travers l'expérience.

La collaboration entre ces différentes entreprises nécessitent des synchronisations entre les processus et un partage d'informations aux moments opportuns. Un premier problème est que ni les processus des entreprises ni leurs données ne sont publiques, pour les raisons que nous avons évoquées plus haut. Un second problème concerne l'agilité. Il s'agit là de pouvoir mesurer l'impact d'une décision locale sur l'ensemble des exigences du système de systèmes; ce qui implique une traçabilité quasi-totale et qui devraient se traduire en principe par la capture des liens entre artefacts d'ingénierie hétérogènes encapsulées dans des boîtes noires. Dans la mesure où chaque entreprise exécute ses propres méthodologies outillées avec pour résultat des données d'ingénierie capturés dans des espaces technologiques en silos, cela ne facilite ni la traçabilité ni la mise en cohérence globale des exigences.


Figure 1 : Système de systèmes et entreprise étendue

Comme l'illustre la figure 1 inspirée du projet d'unification du ciel européen SESAR, les partenaires industriels doivent collaborer pour fournir un service de mobilité aérienne plus efficace, plus sûr et plus respectueux de l'environnement. Leur collaboration, qui vise à concevoir, à réaliser, à exploiter et à maintenir ce système de systèmes, constitue de fait une entreprise étendue. Dans cette entreprise, chaque partenaire amène un système, un savoir-faire et des connaissances métier propres, issus de leur longue expérience. Chaque entreprise développe son système dans un contexte qui lui est propre: droit du travail, environnement, normes, etc. avec des risques et des opportunités associés. Les exigences liées au système dont ils ont la charge doivent tenir compte de toutes ces caractéristiques. Il est important de souligner ici le fait que les différents contextes des entreprises impliquées dans la collaboration peuvent évoluer à des rythmes différents; et un partenariat qui peut paraître pertinent un jour peut s'avérer inopportun le lendemain.

Dans cet exemple, nous ignorons volontairement la gestion des risques liées à l'évolution des contextes. Nous nous focalisons davantage sur les problèmes techniques posés par la co-conception du système de systèmes de mobilité aérienne. La question que nous nous posons est: comment concevoir de manière sûre un système de systèmes qui fait un compromis acceptable entre les propriétés fonctionnelles et extra-fonctionnelles imposées par les parties prenantes ? Notre réponse à cette question est d'ordre méthodologique. De l'observation des pratiques, nous constatons que les parties prenantes du processus collaboratif ne collaborent que de manière épisodique pour la résolution de problèmes qu'ils ne peuvent résoudre que de manière collective, en s'échangeant des informations pertinentes. Les processus collaboratifs qui permettent la résolution de tels problèmes sont guidés de fait par des intentions qui déterminent la nature, la forme et la séquence des informations à échanger pour prendre de bonnes décisions. Les partenaires sont ainsi amenés à partager des informations issues de différents espaces technologiques, et souvent de manière décontextualisée. L'objectif de chaque partenaire est donc de ne fournir que l'information juste et nécessaire, au bon moment, pour favoriser la convergence des décisions sans rien laisser transparaître de leurs propriétés intellectuelles ou savoir-faire. Et pour ajouter un peu plus de complexité au problème, il est nécessaire d'assurer une traçabilité quasi-complète entre les différents artefacts d'ingénierie pour pouvoir mesurer l'impact d'un changement, où qu'il se produise, et apporter ainsi une certaine agilité au processus de co-conception.