« Tu n’as qu’à reprendre le DAT du projet d’avant, on fait la même chose »
Réutiliser un Dossier d’Architecture Technique (DAT) existant, c’est tentant.
On se dit qu’un bon DAT, une fois rédigé, peut servir de base pour les projets suivants avec les mêmes technologies. C’est vrai… mais à condition d’avoir une bonne rigueur et une grosse expertise en audit documentaire.
Non, ce n’est pas suffisant de faire un simple ‘Rechercher/Remplacer’ dans Word. On oublie trop de choses, et même avec des relecteurs, les erreurs passent.
De toute façon, chaque projet est unique, donc cela ne fonctionne pas.
Avant même d’écrire : la quête du Graal (ou comment trouver la bonne solution)
Je ne sais pas si je ne travaille pas avec les bonnes personnes, si la hiérarchie est trop concentrée sur le budget, si je ne sais pas convaincre, si c’est l’air du temps, mais la recherche des solutions semble être un lointain souvenir, presque une légende.
Avant de poser une ligne dans le DAT, l’architecte doit explorer, comparer, prototyper, simuler. Et puis on présente les conclusions et on prend des décisions.
Il y a quelques années, juste avant mon burn out, j’ai halluciné lors du lancement d’un projet ou l’on me donnait 5 jours pour écrire un DAT, tout en me montrant sur le planning que les spécifications ne seraient écrites que plus tard, après même le lancement des développements
C’est la phase qu’on oublie souvent de facturer, ou peut être celle que le client ne veut pas entendre, mais qui conditionne tout le reste.
Un bon DAT, c’est comme un bon plat : tout se joue à l’étape des ingrédients.
Pendant cette phase :
- On évalue plusieurs architectures possibles
- Monolithique ou microservices ?
- Cloud natif ou hybride ?
- Broker ou REST ?
Il ne s’agit pas de choisir au pif. Il faut mettre en perspective les contraintes métiers, techniques, économiques.
- On consulte les collègues
Rien ne vaut un bon débat entre architectes (ou un Slack rempli d’arguments passifs-agressifs). Oui, il y a plusieurs spécialités dans l’architecture. - On relit les projets similaires (mais pas pour les copier)
Identifier les erreurs passées, les patterns qui ont tenu, les technos qui ont résisté au temps. - On fait des PoC ou des maquettes
Le DAT n’est pas là pour “voir si ça marche”. On le rédige quand on sait que ça marche.
Et ça, ça demande un peu de sueur, quelques VM, et parfois un cluster de test en feu. - Et surout, on n’oublie pas qu’un projet vit,
Il évolue, il se maintient, il s’expose. Penser dès le début à sa durabilité, c’est penser à ceux qui devront le faire vivre dans 2, 5 ou 10 ans. Et cela demande de se pencher sérieusement sur la durabilité des composants et la robustesse de notre système.
🧩 Pourquoi ce n’est jamais un simple copier-coller
1. Chaque contexte est différent
C’est le même client, mais de nouveaux métiers impliqués, la volumétrie est différente, les contraintes SI ont évoluées, il y a de nouvelles roadmaps des produits.
Le projet ressemble donc au précédent, comme un paëlla surgelé ressemble à une paëlla maison. La différence que l’on nous présente comme mineure peut redéfinir l’ensemble de l’architecture.
2. Les technos évoluent
Un COTS magique en 2022 peut devenir “non supportée” en 2025.
Et l’outil magique adoré par l’architecte précédent ? Il a été blacklisté par la DSI entre-temps.
3. Les oublis sont vicieux
Reprendre un DAT sans le relire, c’est comme réutiliser une présentation PowerPoint sans vérifier les slides. On peut voir :
“Connexion au module MARCEL via MQSeries”
Sauf que… on est sur “Projet DOROTHÉE”, avec Kafka.
Résultat : la réunion vire au karaoké technique gênant.
4. Les choix doivent être justifiés
N’oublions pas que chaque décision d’architecture doit être :
- Justifiée par le contexte métier (Tiens, il faut des spécifications ?)
- Alignée sur les objectifs du projet
- Argumentée pour être comprise (et validée)
Un choix sans justification est un dogme, et un dogme non discuté est un futur correctif en prod ou pire, un projet .qui n’est pas mis en production.
50 % des projets de développement d’applications se soldent par un échec (cf Developpez.com)
5. L’intégration dans le SI est unique
Chaque SI est un écosystème vivant, les flux, les API, les règles IAM et les niveaux de confidentialité sont spécifiques. Rien n’est générique. Même pas l’authentification.
Alors, on fait quoi à la place ? Y’a-t-il une solution ?
Oui, il faut déjà prendre le temps. Le temps pris à réfléchir, à discuter, à confronter les visions sera du temps gagné sur le long terme. La durée d’un logiciel custom est souvent autour de 7 ans
- Auditer le DAT existant
- Qu’est-ce qui est encore valable ?
- Quelles technos sont obsolètes ?
- Vérifier si par hasard, le DAT contient bien toutes les technos qu’utilise le projet, on rajoute très rapidement des COTS…
- Le contexte métier est-il le même ?
- Mettre à jour avec rigueur
- Modifier les schémas
- Réévaluer les risques
- Revalider les décisions
- Inclure les parties manquantes
- Spécifications fonctionnelles (souvent absentes)
- Intégration SI complète, bizarrement, les projets sont rarement passés dans les mains d’un architecte d’entreprise
- Sécurité, supervision, DevSecOps
- Faire relire (par quelqu’un d’autre que soi)
- Oui, même si “c’est bon je l’ai déjà fait 10 fois”. Et on n’est plus des adolescents, on doit pouvoir comprendre que l’on fait un travail d’équipe. Et oui, ce n’est pas une perte de temps et d’argent de s’assurer que l’on ne va pas dans le mur.
- Un œil extérieur ( voir deux ou trois yeux) repère les Marcel oubliés.
Les 5 drapeaux rouges d’un faux bon DAT
Tu penses avoir un bon DAT entre les mains ? Voici 5 signes qu’en réalité… tu tiens une belle coquille vide :
- Il a été livré avant même que les specs soient écrites.
Bonus : les specs arrivent « après la mise en prod ». - Il n’a pas de section sur la supervision, la sécurité ou l’exploitation.
Ce n’est pas un DAT, c’est une pub pour la dette technique. - Il mentionne des composants non utilisés dans le projet.
MQSeries ? MARCEL ? Ah oui, c’est l’ancien projet… - Aucun schéma ne correspond à l’implémentation réelle.
Le datacenter est on-prem, mais le DAT parle d’Azure tout le long. - Il n’a jamais été relu par personne d’autre que son auteur.
Et son auteur est en vacances. Longues.
Conclusion
Un bon DAT réutilisé est un DAT :
- Audité par des pairs, pas uniquement ceux de la qualité
- Mis à jour
- Revalidé par les parties prenantes
Sinon, c’est juste du plagiat mal relu, qui n’impressionne que ceux qui ne le liront pas.
Si ton DAT est rapide à faire, c’est peut-être que tu ne l’as pas fait.
