En effet, je ne sais pas pourquoi, le client imagine souvent que cette tâche est rapide.
Peut-être pensent-ils que, de nos jours, l’on a juste à appuyer sur “Générer un dossier d’architecture” dans Word, que l’IA complète les schémas, et que l’on relit cela en sirotant un café. Et pourtant…
Un dossier d’architecture, ce n’est pas un PowerPoint pour comité de direction. C’est la charpente technique d’un projet. Un squelette qui doit être à la fois réfléchi, vérifié, partagé, solide, lisible, évolutif, cohérent, documenté et validé par la moitié de la terre. Bref, ce n’est pas un flyer.
Pourquoi c’est (vraiment) long ?
- Recherche et exploration : il faut identifier les contraintes métiers, techniques, sécurité, SI, budget, performances… Et non, “copier l’archi du projet d’avant” ne suffit pas. La plupart du temps, les spécifications fonctionnelles tiennent sur un post it, et l’on passe énormément de temps à creuser, poser des questions, faire des réunions, écrire et revenir sur nos informations et nos certitudes.
- Confrontation des idées : on ne travaille pas en vase clos. On challenge son archi auprès d’autres architectes (ou tech leads), on écoute les contre-arguments, et on itère. Parfois on repart de zéro car les hypothèses de départ ont changé (et sans raler).
- Présentations intermédiaires : avant même d’écrire une ligne, on doit pitcher l’archi pour obtenir un go. Ce qui peut générer un Go-No-Go-Reviens-demain épuisant.
- Rédaction du DAT : le cœur du travail. en partant d’un template de 30 pages. Mais entre « Remplir la section sécurité » et « décrire le plan de rollback », il y a un gouffre de réflexion. Car oui, dès l’architecture, l’on pense déjà à la maintenance et aux problèmes en production.
- Relectures et arbitrages : 3 relecteurs officiels, on itére, in ajuste la formulation, on clarifie, on reformule… et c’est validé… et 3 mois plus tard, des personnes inconnues du projet, envoient des fiches de relecture à prendre en compte en urgence
Exemples vécu :
Un jour, j’ai fait l’exercice de compter le temps réel passé par section. Avec une granularité de 15 minutes. Résultat : 15 à 20 jours homme pour un dossier solide.
Un jour, kick off de début de projet. Le planning est fait : première tâche, écriture de l’ARD, seconde tâche, mise en place des environnements et départ du développement… troisième tâche : écriture des spécs générales… Et non, je n’invente rien !
Les spécifications ne sont pas forcément écrites (alors que le DAT doit y faire référence pour expliquer les choix). Que le design Haut Niveau (intégration dans l’architecture d’entreprise) n’existe pas forcément non plus.
C’est là que l’architecte devient mentaliste.
On nous demande de livrer un Dossier d’Architecture Technique (DAT) solide, traçable, validé… alors que :
- Les spécifications fonctionnelles n’existent pas (ou sont encore au stade de « brainstorming en trois bullets sur un powerpoint »).
- Le design haut niveau est inexistant : aucune vision claire d’intégration dans l’écosystème SI, pas d’urbanisation définie, pas de contraintes d’interopérabilité documentées.
- Et bien sûr, le planning prévoit quand même une date de livraison ferme.
Résultat : on comble les trous à coups d’expérience, de bon sens et d’hypothèses qu’il faudra revalider (ou réécrire) plus tard.
Alors oui, c’est long. Et non, ce n’est pas “juste du remplissage de template”.
On ne peut pas juste reprendre un DAT en changeant le nom du projet
Oui, le doux fantasme du « Copier-Coller Architectural »…
Réutiliser un DAT existant, c’est tentant. On se dit qu’un bon dossier d’architecture, une fois rédigé, peut servir de base pour les projets suivants. C’est vrai… mais ce n’est qu’une base. Il faut remettre en question chaque partie.
Pourquoi ce n’est jamais un simple copier-coller :
- Chaque contexte est différent : contraintes métier, volumétrie, SI cible, roadmap projet, partenaires techniques, exigences de sécurité… Rien n’est identique, même si “le client, c’est le même”.
- Les technos évoluent : une solution pertinente il y a 18 mois peut être obsolète ou sous-optimale aujourd’hui.
- Les oublis sont vicieux : reprendre un DAT sans tout relire, c’est risquer de mentionner “l’application ROBERT” alors qu’on travaille sur “PROJET MICHEL”.
- Des choix doivent être justifiés dans leur contexte : le pourquoi de chaque décision technique (même si reprise) doit être expliqué par rapport aux besoins du nouveau projet.
- L’intégration dans le SI est unique : on ne branche pas une app sur un autre système sans vérifier si les API, les flux ou les droits d’accès sont compatibles.
Un bon DAT réutilisé est un DAT audité, mis à jour, validé à nouveau. Sinon, c’est, on va dans le mur mais plus vite.
Comment convaincre le client ?
- Chiffrer chaque étape (même approximativement). Ça impressionne. J’ai fait cela, j’ai pris le template et pour chaque chapitre, j’ai mis un chiffre à partir de 15mn… Arrivé au bout, on avait un chiffrage de 20 jours.
- Expliquer les risques d’un dossier incomplet : mauvaise implémentation, dérives budgétaires, sécurité absente, risque en production…
- Raconter une anecdote d’échec (les clients adorent les histoires de projets qui ont foiré chez les autres).
- Comparer à un autre type d’ingénierie
- bâtiment : on ne construit pas une tour avec un plan griffonné sur une serviette.
- automobile : on ne met pas les mêmes pneus sur une Twingo et une Porsche
Bref, l’architecture, c’est du temps bien investi. Mieux vaut passer trois semaines à écrire un bon plan que six mois à réparer une usine à gaz.