# Dossier d'Architecture Technique

| | |
| --- | --- |
| **Projet** | *à compléter* |
| **Version** | *à compléter* |
| **Date** | *à compléter* |
| **Auteur** | *à compléter* |
| **Rédigé par** | Architecte / MOE |
| **Destinataires** | MOE, exploitation, sécurité, DSI |
| **Statut** | Brouillon / En relecture / Validé |

---

## 1. Objet et périmètre du document

<!-- Ce que couvre le DAT, ce qu'il ne couvre pas, et à qui il s'adresse. -->

<!-- Points à couvrir :
     - Solution décrite et version
     - Documents de référence (SFG, SFD, cahier des charges)
     - Public visé
-->

*à compléter*

## 2. Contraintes et exigences architecturales

<!-- Ce qui s'impose à l'architecture avant tout choix. -->

<!-- Points à couvrir :
     - 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
-->

*à compléter*

## 3. Vue de contexte

<!-- La solution vue de l'extérieur, avec ses voisins (niveau 1 du modèle C4). -->

<!-- Points à couvrir :
     - 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
-->

*à compléter*

## 4. Vue applicative

<!-- Le découpage interne en composants et leurs responsabilités (niveaux 2 et 3 du C4). -->

<!-- Points à couvrir :
     - Schéma des conteneurs applicatifs et des composants
     - Responsabilité de chaque composant, en une phrase
     - Technologies et versions retenues
     - Dépendances internes et externes
-->

*à compléter*

## 5. Vue des données

<!-- Où vivent les données, sous quelle forme, et qui en est propriétaire. -->

<!-- Points à couvrir :
     - 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
-->

*à compléter*

## 6. Vue des flux et intégration

<!-- Le détail de chaque échange, en tant que contrat d'interface. -->

<!-- Points à couvrir :
     - 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
-->

*à compléter*

## 7. Vue infrastructure et déploiement

<!-- Où ça tourne, sur quoi, et comment ça y arrive. -->

<!-- Points à couvrir :
     - 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
-->

*à compléter*

## 8. Sécurité

<!-- La réponse aux exigences de sécurité, pas une déclaration d'intention. -->

<!-- Points à couvrir :
     - 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
-->

*à compléter*

## 9. Disponibilité et continuité

<!-- Le comportement attendu quand un composant tombe. -->

<!-- Points à couvrir :
     - 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
-->

*à compléter*

## 10. Supervision et exploitabilité

<!-- Ce qui rend la solution pilotable une fois en production. -->

<!-- Points à couvrir :
     - Indicateurs techniques et fonctionnels supervisés
     - Seuils d'alerte et destinataires
     - Journaux produits, format, centralisation, durée de conservation
-->

*à compléter*

## 11. Décisions d'architecture

<!-- Les choix structurants et leur justification, sous forme de liste renvoyant aux ADR. -->

<!-- Points à couvrir :
     - Décision, options écartées, raison du choix, conséquences acceptées
     - Renvoi vers la fiche ADR détaillée
-->

*à compléter*

## 12. Risques techniques et dette assumée

<!-- Ce qu'on sait imparfait et qu'on assume, plutôt que de le laisser découvrir. -->

<!-- Points à couvrir :
     - Risque, impact, parade ou surveillance
     - Dette technique acceptée et échéance de traitement
-->

*à compléter*

## 13. Glossaire technique

<!-- Les termes et sigles propres à la solution. -->

*à compléter*

---

## Notes de rédaction

**Quand produire ce document**

- 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.

**Erreurs les plus fréquentes**

- 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.

**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.

---

Modèle « DAT - Dossier d'Architecture Technique » (Conception technique), publié par DataALC.
Version en ligne, commentée : https://www.dataalc.com/boite-a-outils/templates/dat/

Ce modèle est fourni comme base de travail : adaptez-le à votre contexte, supprimez les rubriques sans objet plutôt que de les laisser vides.