DAT - Dossier d'Architecture Technique
La traduction technique de la cible fonctionnelle : composants, flux, infrastructure, sécurité, et les décisions qui les expliquent.
13 rubriques, consignes de rédaction incluses. Sans inscription. Le tableur contient une grille « Interfaces » prête à remplir.
À quoi sert ce document
Le DAT décrit comment la solution est construite et pourquoi elle l'est ainsi. Le « pourquoi » est la partie qui a le plus de valeur dans le temps : dans deux ans, personne ne se souviendra des contraintes qui ont conduit à ce choix de découpage, et l'équipe suivante refera le débat ou cassera un équilibre qu'elle n'aura pas compris. Le DAT sert de contrat d'interface avec l'exploitation, la sécurité et les équipes voisines, et de point de départ à toute étude d'impact ultérieure.
Quand le produire
- Sur toute solution mise en production dans un SI d'entreprise.
- Quand la solution consomme ou expose des interfaces vers d'autres systèmes.
- Avant passage en comité d'architecture ou en validation sécurité.
- Avant une reprise par une autre équipe, une TMA ou un changement de prestataire.
Référentiel de rattachement : arc42 et modèle C4
arc42 fournit le plan de référence d'une documentation d'architecture (contexte, contraintes, vue des blocs, vue d'exécution, décisions, qualité, risques). Le modèle C4 fournit les niveaux de schéma associés : contexte, conteneurs, composants, code. Le plan ci-dessous combine les deux, avec les rubriques attendues en contexte SI français.
Le plan, rubrique par rubrique
-
Objet et périmètre du document
Ce que couvre le DAT, ce qu'il ne couvre pas, et à qui il s'adresse.
- Solution décrite et version
- Documents de référence (SFG, SFD, cahier des charges)
- Public visé
-
Contraintes et exigences architecturales
Ce qui s'impose à l'architecture avant tout choix.
- Contraintes techniques : socle imposé, versions, référentiels internes, hébergement
- Exigences de qualité chiffrées : performance, disponibilité, capacité, temps de reprise
- Contraintes réglementaires et de conformité
- Contraintes organisationnelles : compétences disponibles, modèle de support
-
Vue de contexte
La solution vue de l'extérieur, avec ses voisins (niveau 1 du modèle C4).
- Schéma de contexte : systèmes amont, aval, acteurs
- Pour chaque interface : nature, protocole, sens, fréquence, volumétrie
- Responsabilités : ce que porte la solution, ce que portent les systèmes voisins
-
Vue applicative
Le découpage interne en composants et leurs responsabilités (niveaux 2 et 3 du C4).
- Schéma des conteneurs applicatifs et des composants
- Responsabilité de chaque composant, en une phrase
- Technologies et versions retenues
- Dépendances internes et externes
-
Vue des données
Où vivent les données, sous quelle forme, et qui en est propriétaire.
- Modèle physique et volumétries par entité, à trois ans
- Stockages : bases, systèmes de fichiers, files, caches
- Cycle de vie : rétention, archivage, purge
- Classification des données et présence de données personnelles
-
Vue des flux et intégration
Le détail de chaque échange, en tant que contrat d'interface.
- Fiche par flux : source, cible, format, protocole, fréquence, volumétrie, fenêtre
- Mode de transport et sécurisation
- Gestion des rejets, des relances, et des traitements qu'on peut relancer sans créer de doublon
- Ordonnancement et dépendances entre traitements
-
Vue infrastructure et déploiement
Où ça tourne, sur quoi, et comment ça y arrive.
- Schéma de déploiement par environnement
- Dimensionnement : CPU, mémoire, stockage, réseau
- Environnements : développement, intégration, recette, préproduction, production
- Chaîne de livraison : build, versionnement, déploiement, retour arrière
-
Sécurité
La réponse aux exigences de sécurité, pas une déclaration d'intention.
- Authentification et gestion des identités
- Habilitations et cloisonnement
- Chiffrement en transit et au repos, gestion des secrets
- Journalisation, traçabilité, conservation des traces
- Flux réseau ouverts, avec justification de chacun
-
Disponibilité et continuité
Le comportement attendu quand un composant tombe.
- Redondance et tolérance de panne par composant
- Objectifs de reprise : perte de données admissible et délai de remise en service
- Sauvegardes : périmètre, fréquence, rétention, et test de restauration
- Plan de continuité et bascule
-
Supervision et exploitabilité
Ce qui rend la solution pilotable une fois en production.
- Indicateurs techniques et fonctionnels supervisés
- Seuils d'alerte et destinataires
- Journaux produits, format, centralisation, durée de conservation
-
Décisions d'architecture
Les choix structurants et leur justification, sous forme de liste renvoyant aux ADR.
- Décision, options écartées, raison du choix, conséquences acceptées
- Renvoi vers la fiche ADR détaillée
-
Risques techniques et dette assumée
Ce qu'on sait imparfait et qu'on assume, plutôt que de le laisser découvrir.
- Risque, impact, parade ou surveillance
- Dette technique acceptée et échéance de traitement
-
Glossaire technique
Les termes et sigles propres à la solution.
Les erreurs qui coûtent cher
- Documenter le comment sans le pourquoi. Un DAT qui ne consigne pas ses arbitrages perd 80 % de sa valeur dès que ses auteurs quittent le projet.
- Produire un schéma unique où tout figure. Un schéma répond à une question et à une seule : contexte, composants, déploiement sont trois schémas distincts.
- Oublier les volumétries et les fenêtres de traitement. C'est ce qui distingue une architecture qui tient en production d'une architecture qui tient en démonstration.
- Laisser le DAT figé à la fin de la conception. Un DAT non maintenu devient un piège : on s'y fie et il est faux.
- Traiter la sécurité en annexe. Une revue sécurité tardive est la première cause de report de mise en production.
Sigles associés
Documents complémentaires
Besoin d'un cadrage, pas seulement d'un modèle ?
Nous rédigeons et challengeons ces documents en mission, sur des projets d'intégration, de migration de données et de décisionnel. Parlons de votre projet.