Skip to content Skip to sidebar Skip to footer

Le cadrage : la clé pour réussir son projet d’architecture du système d’information

Dans le tumulte des projets informatiques, le cadrage d’un projet d’architecture SI joue le rôle d’une boussole indispensable. Cette approche, souvent négligée, consiste à définir avec précision les contours, les objectifs et les contraintes d’un projet d’architecture. A l’aide d’ateliers, il permet d’éviter les dérapages, de cadrer le risque et de s’assurer de bien répondre aux attentes. Il favorise la collaboration et permet d’aller au-delà d’une simple description des besoins.

Matthieu Strohl, Lead Cloud, référent technique Digital Foundation et Red Hat chez Inside, nous explique concrètement les tenants et les aboutissants du cadrage d’un projet d’architecture du SI, les principes de High-Level Design et nous partage la méthode qui a ses faveurs.

En quoi consiste le cadrage d’un projet d’architecture du SI ?

Selon moi, il s’agit surtout d’une méthode qui permet de collecter auprès des parties prenantes toutes les informations nécessaires pour comprendre le contexte client, dans le cadre d’un projet d’architecture du SI, et qui prend la forme d’un document ou DAT. C’est-à-dire comprendre les enjeux, les objectifs et les contraintes de ce client, et lui proposer ainsi l’architecture la plus adaptée. En effet, dans ce type de projet, il est rare que toutes les données entrantes nécessaires soient fournies d’emblée. Par exemple, définir que le besoin est de migrer toutes ses applications dans le Cloud ou son SI dans des conteneurs n’est pas suffisant pour cadrer. Il n’est pas question ici de challenger le choix du client, mais de mettre en exergue une orientation. Le cadrage d’un projet d’architecture du SI est donc important, car il aide à définir le scope d’intervention, les tenants et les aboutissants, et ainsi de comprendre où se situent les enjeux ? Car chaque enjeu ne va pas profiter des mêmes solutions techniques.

Qu’est-ce que le High-Level Design (HLD) et comment intervient-il dans ce contexte ?

Comme pour le DevOps, il existe plusieurs définitions du HLD. Pour moi, le HLD fait la synthèse de l’architecture d’un système, en décrivant ses principaux composants, leurs interactions et leurs fonctionnalités. Par exemple, lors d’un projet avec Red Hat, des ateliers ont été menés pour prendre en compte les besoins, pour expliquer les contraintes du produit que le client souhaite mettre en œuvre, et trouver ainsi les « best practices » pour cette mise en œuvre.

Dans ce contexte, le HLD permet de reprendre de manière « technico-fonctionnelle » l’ensemble de ce qui a été décidé lors de ces ateliers. Car il faut faire la différence entre opérer des choix architecturaux et techniques liés à un contexte client, et leur mise en œuvre effective. La HLD va dire, par exemple, que pour une architecture basée sur la plateforme OpenStack, il a été décidé d’utiliser des baies de stockage SAN parce qu’elles étaient déjà présentes et maîtrisées, plutôt que de partir sur une solution de stockage distribué de type CEPH. Le HLD permet donc de mettre à plat toutes les décisions, mais également les impacts que cela va engendrer. Si les Architecture Decision Record (ADR) sont des documents qui visent à officialiser une décision « Low Level » d’architecture, le HLD peut être vu comme un ensemble d’ADR. Ce qui permet in fine d’obtenir un document qui liste de façon exhaustive idéalement l’ensemble des points qui visent à l’implémentation d’une architecture cible.

Comment mettre en œuvre ce cadrage d’un projet d’architecture du SI ?

J’utilise personnellement la méthode Navigate de Red Hat. Elle est animée avec la méthode Agile, et n’est pas si éloignée du framework Accelerate. Elle se décompose en deux parties : d’abord des ateliers découpés par typologie (stockage, sécurité, gestion du risque…) suivi de la création d’un document de Contrat Engagement Report (CER). Dans le cadre d’un projet d’architecture du Système d’Information, Navigate aide à constituer l’ensemble des décisions et des recommandations d’implémentation. Concrètement, pour notre contexte d’architecture, nous savons qu’il faudra aborder plusieurs thématiques. Pour chacune d’elle, il est nécessaire de constituer un atelier dédié, donc préparer en amont un ensemble de questions qui serviront à l’édification d’un arbre de décision. Comme ces ateliers humanisent la démarche, ils favorisent un vrai partage. Qui plus est, la temporalité de Navigate est également intéressante, avec généralement des ateliers menés le matin, l’après-midi étant réservé au consultant pour qu’il « digère » l’atelier. Ainsi, au fur et à mesure des réflexions menées, il est possible de « réajuster le tir » avec le client. Dans cette méthodologie se trouve également le concept du « parking », c’est-à-dire un emplacement sur le board visuel dédié au stockage de questions qui n’ont pas encore été abordées, ou qui le seront dans de futurs ateliers. Cela favorise l’exhaustivité et la qualité.

Quels sont tes conseils pour mener à bien ce type de cadrage ?

Je conseille d’utiliser une méthode reconnue, Navigate ou autre, car c’est rassurant et sécurisant pour le client. Nous n’avons pas de framework dédié chez Inside, notre agnosticisme ne nous impose rien. Mais j’apprécie pour ma part la méthode de Red Hat car elle permet d’aller très loin, et d’aborder tous les points clés en fonction de la technologie mise en regard. Concrètement, je conseille de commencer par des ateliers pour comprendre le besoin, puis de continuer avec des phases d’assimilation de l’information, pour terminer par la restitution d’un document HLD qui fera une synthèse des décisions prises et de celle restant à prendre. En effet le client reste seul décisionnaire, notre travail est de l’alimenter avec des préconisations. Concernant les ADR, Je conseille également d’opérer une approche par dichotomie, qui va certes multiplier le nombre de documents, mais ils permettront une gestion plus fine du référentiel documentaire. Enfin, il est judicieux de rationaliser les ressources et de condenser les interactions avec le client, pour ne pas avoir à le solliciter trop régulièrement et éviter de consommer de son temps.

Vous souhaitez échanger avec nos experts autour du cadrage de projet d’infrastructures d’un SI, c’est par ici !