Aujourd’hui, sans Dossier d’Architecture Technique (DAT), impossible d’obtenir une vue complète de l’infrastructure technique d’un projet ou d’un système d’information (SI). Car c’est ce dossier qui montre comment les différents composants d’un système interagissent, et garantit la cohérence et l’efficacité dans le développement et la maintenance, tout en facilitant la prise de décision en matière de mises à jour technologiques ou de résolution de problèmes. Remi Ruiz, consultant technique, décortique pour vous ce document essentiel pour une gestion efficace des systèmes, de l’infrastructure, des réseaux, et des applications au sein d’une entreprise.
Pourquoi rédiger un DAT (Dossier d’Architecture Technique) et à quoi sert-il ?
La rédaction d’un DAT intervient dans 2 principaux cas : le lancement d’un nouveau projet, ou pour obtenir l’état des lieux technique et fonctionnel de tous les composants déjà en production dans un système existant.
Dans le premier cas, lorsqu’une équipe de développement crée un nouveau logiciel par exemple, le DAT est utilisé pour détailler l’architecture technique du système. C’est-à-dire les informations sur les composants logiciels, les bases de données, les interfaces, les protocoles de communication, etc.
Dans le second cas, pour faire évoluer son SI ou pour effectuer sa maintenance, le DAT sert de référence pour comprendre l’architecture en place, et garantir que les évolutions et les modifications sont cohérentes avec cette architecture.
Dans les 2 cas, le Dossier d’Architecture Technique peut être vu comme un outil dont le but est de documenter et communiquer les aspects techniques d’un système informatique tout au long de son cycle de vie. C’est en quelque sorte la mémoire et l’état des lieux technique et fonctionnel de tous les composants de ce système. Le DAT permet donc de définir et de documenter tout ce qu’il faut faire et mettre en place pour réussir la mise en œuvre de l’architecture ou pour la faire évoluer, en s’assurant de respecter les objectifs et les contraintes propres à chaque entreprise.
Que trouve-t-on dans un Dossier d’Architecture Technique ?
UN DAT sert de référentiel et permet de garder la maîtrise de son SI en matière :
- De ressources
- D’usages
- De capacités
- D’information
- De communication
Pour se faire le DAT doit :
- Décrire le but de l’architecture cible ou existante
- Définir/identifier les contraintes du système (les critères de fonctionnement du système et ses limites)
- Définir/identifier les caractéristiques à mettre en place ou existantes
- Définir le périmètre et les différentes composantes du projet dans le contexte d’une gestion de projet
- Servir de support pour communiquer sur l’architecture technique du système aux parties prenantes internes et externes de l’entreprise (nouvel embauché, prestation d’un acteur externe, direction)
Plus concrètement, un SI se compose toujours de 3 couches (métier, applicative et infrastructure) associées à différents types d’architecture (fonctionnelle, applicative, technique et opérationnelle). Généralement, le dossier d’architecture technique va représenter ces 3 couches que nous associons chez Inside à 2 couches supplémentaires : sécurité et opérationnelle.
La couche Métier
Elle fait référence aux entités, processus et systèmes qui définissent les valeurs métiers. S’y trouve une analyse contextuelle qui présente les principes stratégiques et les points structurants auxquels l’architecture doit répondre, et les interlocuteurs cibles. C’est–à–dire les représentant métiers et toutes les informations concernant les enjeux et objectifs métiers. Apparaissent également les différents types d’exigences et contraintes qui impactent la solution d’architecture technique (architecture, sécurité, performances, normes techniques et d’exploitation, etc.).
Les acteur/utilisateurs du système doivent également être identifiés pour savoir qui utilise le système (Employés de l’entreprise, partenaires ou client avec des informations comme leur rôle ou leur localisation). Enfin, la vision métier inclut également l‘ensemble des différents services fonctionnels rendus par le système (les Spécifications Fonctionnelles Générales), les données fonctionnelles manipulées et les traitements réalisés ainsi qu’un schéma des couches fonctionnelles : utilisateurs, interfaces, type des données manipulées et leur traitement.
La couche Applicative
C’est une représentation des aspects logiciels qui va détailler les composants et les services qu’ils proposent. L’analyse conceptuelle présente ainsi les besoins qui ont été exprimés et auxquels l’architecture cherche à répondre, et l’analyse logique des mécanismes mis en œuvre pour répondre aux besoins spécifiés dans l’analyse conceptuelle. La vision applicative va également mettre en lumière les informations liées aux composants du Système d’Information (Applications, middlewares, frameworks) soit les composants permettant d’instancier concrètement les flux, ses données et les traitements (bases de données, serveurs d’applications et serveurs web).
La présentation des principaux protocoles de communication entre les différents applicatifs du projet est également essentielle (avec la volumétrie transmise, la fréquence des envois, le sens du flux, les zones réseau traversées par les flux, etc.) pour identifier quel(s) flux technique(s) correspond(ent) aux flux métiers afin de faire le lien avec la couche métier. Enfin, il est intéressant d’inclure le mécanisme de fonctionnement applicatif utilisé sous forme d’architecture logique afin d’éclaircir le fonctionnement de certaines parties applicatives.
La couche Infrastructure
C’est ici que sont décrits tous les mécanismes mis en œuvre pour assurer le fonctionnement du système en détaillant tous les équipements qui sont ou seront utilisés. L’analyse physique décrit les équipements et les logiciels cibles, et le référencement de l’infrastructure qui permet de supporter les flux, les données et autres composants identifiés. Précisons que ce dernier point englobe les équipements avec leur dimensionnement, leurs types, leur emplacement en matière de réseau et leur stockage (serveurs, machine virtuelle de réseau, de stockage ou de virtualisation).
Sont également présents les mécanismes de fonctionnement des différentes ressources qui garantissent l’utilisation de certains services, que ce soit pour les aspects de performance, de disponibilité et de protection des données par exemple. Enfin, il ne faut pas oublier le type d’environnement et les schémas d’architecture existants, avec une description de l’utilisation de chaque environnement (Prod, préprod, intégration… et leur schéma).
La couche Opérationnel
Elle représente le cycle de vie du Système d’Information et décrit tous les mécanismes qui vont permettre de gérer l’ensemble des systèmes, que ce soit en matière de reporting, de supervision, de sauvegarde, d’ordonnancement et d’exploitation. Cette vision embarque le RACI (Responsible, Accountable, Consulted, Informed) pour visualiser les rôles de chacune des parties prenantes dans la gestion d’exploitation.
La couche Sécurité
Elle met en avant le niveau de sécurisation du Système d’Information, les aspects liés à la sécurité, à la conformité et à d’autres considérations importantes en matière d’architecture, contribuant ainsi à garantir que le système respecte les normes et les politiques de sécurité. Elle s’adresse principalement aux RSSI et aux responsables d’infrastructures.
Avez-vous un retour d’expérience ou un exemple à nous confier sur une mission de construction d’un Dossier d’Architecture Technique ?
Nous avons été contactés par une « infrastructure de recherche » qui a essayé de mettre en œuvre un Dossier d’Architecture Technique, en vain. Sans une bonne méthodologie, l’exercice est en effet assez compliqué. Chez Inside, nous nous appuyons sur 3 axes principaux pour garantir le succès de la mission.
- Un premier axe Stratégie et roadmap permet de définir une trajectoire en phase avec les enjeux et objectif de la mission. Cela passe par la mise en œuvre d’un recueil du besoin, la découverte des processus existants de l’entreprise, l’identification des interlocuteurs clés, et la définition d’un référentiel commun afin de mieux cerner le contexte de la mission et concevoir une solution réellement adaptée au client.
- Un second axe dit de conception, avec le découpage du projet en plusieurs phases et sous activités. Nous utilisons un cycle incrémental et itératif de l’ensemble des activités à réaliser pour chaque phase.
- Un troisième axe d’accompagnement, qui consiste à fournir des conseils sur la gouvernance à mettre en place, en adéquation avec la gouvernance existante. Durant cette phase, nous sensibilisons sur la valeur ajoutée que le DAT peut apporter au sein du SI en termes de communication, de pilotage, de sécurité et de réponse à des enjeux futurs.
Pour conclure, je préconise de toujours privilégier un format facile à lire et à comprendre, avec idéalement des schémas. Il faut également rappeler que le dossier d’architecture technique est un document « vivant », conçu pour être consulté régulièrement. Il est donc important de le maintenir à jour pour éviter de fournir des informations obsolètes. L’absence de DAT, ou la mauvaise qualité de celui-ci par obsolescence, représente un véritable risque en matière de maîtrise des composants utilisés en production, et plus généralement de son SI.
Vous souhaitez échanger avec nos experts autour de vos enjeux et de la gestion du dossier d’architecture technique, c’est par ici !