Une question :
"Comment un document conçu il y a quasiment trente ans continue-t-il à être incontournable dans nos projets malgré sa lourdeur et ses anachronismes ?"
Je vous propose d'explorer à travers une série de 5 articles comment faire évoluer le Dossier d'Architecture Technique vers une forme plus adaptée aux enjeux actuels.
Ce premier article a pour but de placer le décor : l'histoire, la nature et le but du DAT.
Petite histoire du DAT
Le Dossier d'Architecture Technique (DAT) en 2024, c'est un peu un dinosaure de l'IT :
Un gros document unique volumineux, poussiéreux dont on ne sait plus trop que faire, mais "il faut un DAT pour mettre en production le projet".
Rajoutons que maintenant, avec l'agilité/le devops ("délivrer souvent"), l'Infra-as-Code, l'automatisation, la scalabilité et le finops, la plateforme évolue plus vite que sa documentation.
Ce qui avant était gravé dans la silice des serveurs physiques est maintenant variabilisé dans un bout de code exécuté quotidiennement.
En plus, l'ancien archi sur le projet est parti sans laisser le fichier visio du schéma d'archi alors on peut plus le mettre à jour.
Et de toute façon, j'ai pas de license Visio
Avec tout ça, la petite motivation de le mettre à jour s'effondre face à la montagne de dette à reprendre.
Du coup, on l'abandonne avec son confrère le DEX (dossier d'exploitation) dans un coin de notre GED (Gestion Electronique des Documents).
À quoi sert un DAT ?
Un dossier d'architecture (DA) est un dossier("document") qui porte les références pour la conception, le développement, le déploiement et la maintenance d'une solution informatique.
(ndlr: je n'aime vraiment pas ce terme "document" que l'on retrouve pourtant trop souvent dans les définitions.)
Le DAT remplit deux fonctions principales :
- Documenter et valider formellement l'architecture et les choix techniques d'un projet informatique, pour garantir sa bonne construction et sa maintenance future.
- Servir d'engagement ou de protection juridique pour les différents acteurs impliqués dans le projet.
Les plus répandus sont :
- Le DAT (Technique)
- Le DAG (Générale)
D'autres dossiers se spécialisent sur des aspects architecturaux spécifiques.
Bien que cet article se concentre sur le DAT, les observations s'appliquent à tous les types de Dossiers d'Architecture qui présentent rapidement les mêmes limitations. Le terme DA sera parfois utilisé pour parler plus généralement des Dossiers d'Architecture.
Étape Lexique des acronymes
"Moi, on m'a parlé de DAT ? DAG ? DAS ? DAF ? DAC ? DEX ? DIN ? DMV ?"
Dossier d'architecture…
- Technique (DAT) : vue infrastructure, système et réseau
- Générale (DAG) : vue entreprise, souvent avec cadre TOGAF
- Applicatif / Logiciel (DAL)
- Sécurité (DAS)
- Data (DAD) : commence à apparaitre
- Cloud (DAC)
- Dossier d'exploitation (DEX)
- Dossier d'installation (DIN)
- Dossier de Montée de Version (DMV)
La complexité de maintenir un seul document a vu naitre pratiquement autant de document que de vision d'architecture.
Mais pourquoi un si gros document ?
Le DAT est devenu un document volumineux pour plusieurs raisons historiques et pratiques :
1. Contexte historique
Bonne question : Quand est né le DAT ?
La notion d'architecture informatique émerge véritablement dans les années 1990s.
Une recherche de publications techniques sur l'architecture informatique révèle un premier article en 1964 (concernant l'architecture de l'IBM System/360), suivi d'une croissance continue jusqu'à aujourd'hui.
Le TOGAF (The Open Group Architecture Framework) introduit en 1995 la notion d'aspects de l'architecture (métier, données, applicative, technique) et formalise les concepts et pratiques, dont les DA.
Il se base sur le TAFIM, un concept développé par le Département de la Défence Américain.
Dans les années 1990 en France, de grands projets de structuration des DSI des groupes français démarrent.
Ces DSI se structurent en faisant appel aux premières Sociétés de Services en Ingénierie Informatique (SSII).
Deux éléments spécifiquement français ont influencé les choix :
- L'influence de la culture d'ingénieur française
- La tradition française (administrative, affaires et ingénierie) privilégiant l'écrit formel
La gestion documentaire existait déjà dans d'autres domaines industriels.
Le TOGAF et ses DAG/DAT ont donc été naturellement adoptés.
2. Aspects juridiques et contractuels
DSI important + contractants (SSII et éditeurs) + contrats aux montants importants = protection contractuelle nécessaire.
Il devient impératif de se protéger juridiquement dans les relations client-fournisseur.
Le DAT devient un document de référence pour :
- La base contractuelle en cas de litiges potentiels
- Les audits et certifications
3. Culture organisationnelle
La structure hiérarchique des entreprises françaises induit une hiérarchisation similaire au sein des DSI.
La relation client-fournisseur et les engagements contractuels créent une séparation marquée des rôles (MOA/MOE), nécessitant une documentation détaillée.
"Le client maîtrise le métier, la SSII maîtrise la technique."
Tout doit être documenté de manière exhaustive.
4. Contraintes sectorielles
L'entreprise doit respecter différentes contraintes :
- Les exigences réglementaires (notamment dans la banque/assurance)
- Les besoins de conformité (normes ISO, RGPD, etc.)
- La documentation des choix pour les audits de sécurité
Impact
N'oublions pas une certaine culture française de la
paperasse"traçabilité des décisions".
Ironiquement, tous ces points vont directement nuire à l'efficacité du document :
- Temps considérable requis pour la rédaction et la maintenance
- Multiplicité des intervenants devant mettre à jour leur partie de DAT
- Risque de dilution ou perte des informations cruciales
- Décalage potentiel avec la réalité du projet
Le DAT français par rapport au reste du monde
Non, le DAT n'est pas universel. Les autres pays utilisent des formes différentes de documentation d'architecture.
Petit exercice de comparaison de DAT avec le Technical Design Document (TDD), qui est probablement l'équivalent le plus proche dans le monde anglo-saxon.
| Aspect | DAT (France) | TDD (Anglo-saxon) |
|---|---|---|
| Structure et Formalisme | Structure normée et standardisée Sections obligatoires Format souvent imposé |
Structure souple et adaptable Sections recommandées Format flexible |
| Contenu et Profondeur | Description exhaustive Inclut aspects gouvernance Documentation détaillée des choix Accent sur la traçabilité |
Centré aspects techniques Documentation concise Orienté implémentation Moins d'aspects organisationnels |
| Cycle de vie | Validation formelle préalable Mises à jour peu fréquentes Document de gouvernance |
Évolution continue Mises à jour fréquentes Guide vivant |
| Usage | Document contractuel Base pour validation/audits Référence officielle |
Document de travail Communication technique Support développement |
| Culture d'entreprise | Culture hiérarchique Gestion formelle Relations client-fournisseur |
Culture agile Adaptabilité Focus équipe développement |
Ces différences reflètent des approches culturelles distinctes de la gestion de projet et de la documentation technique :
- Le DAT s'inscrit dans une approche formelle, exhaustive et hiérarchique, servant de document contractuel et de gouvernance,
- Le TDD adopte une démarche plus souple, privilégiant l'efficacité opérationnelle et l'agilité.
Différence clé avec le DAT :
- Le DAT souffre souvent d'une rigidité excessive qui freine les mises à jour
- Le TDD souffre plutôt d'un manque de rigueur qui peut créer du flou
Conclusion
En 2024, le DAT reste manifestement un vestige du passé.
Malgré les révolutions technologiques successives, la documentation n'a pas évolué en conséquence.
Peu de publications actuelles parlent de documentation et proposent des solutions pour transformer cette situation.
Les publications existantes se concentrent principalement sur "quel contenu inclure", sans réellement aborder la question "comment le rédiger ?"
Les évolutions technologiques récentes offrent pourtant de nouvelles possibilités et je suis convaincu que l'on peut faire autrement.
Pour le prochain article, on parlera des erreurs les plus fréquentes.
Cet article fait partie du "Advent of Tech 2024 Onepoint", une série d'articles tech publiés par Onepoint pour patienter jusqu'à Noël.
Voir tous les articles du Advent of Tech 2024
Merci pour votre lecture.
Top comments (3)
Est ce que les exigences RGPD, RSE, accessibilité, green-IT, etc. ne milite pas pour qu'il existe quand même un document par projet ? un DAT light ou un TDD.
Afin de ne rien oublier et de pouvoir répondre facilement aux demandes d'audit.
On peut débattre du terme document vs dossier,
Mais oui, les normes ISO, le Cobit, ITIL et le TOGAF demandent une référence de documentation d'architecture.
Je pense qu'on peut faire autrement mais ... il te faudra attendre les autres articles pour avoir ma conclusion là-dessus :)
top cet article! et bonne mise en bouche pour les prochains articles à ce sujet. merci