Les dossiers d’architecture sont des documents vivants, même s’ils ne changent pas souvent. Il m’est arrivé de devoir en compléter afin d’y apporter des nouveautés, et là, on peut avoir des surprises. Cela va du dossier inexistant ou vraiment ancien à un dossier incomplet. Mais les surprises peuvent ne pas s’arrêter là, en effet, plusieurs questions vont venir s’ajouter. Le client découvre à ce moment que son dossier d’architecture comporte des trous et se demande comment il faut réagir. Dans une petite structure, plus souple, on peut s’accommoder de cela pour un temps et mettre à jour le dossier petit à petit. Dans une structure plus grande, avec des process de validations plus durs, c’est une autre histoire. Alors, quel que soit le cas, comment pouvons-nous faire ?
I. Les types de surprises rencontrées
Dossier inexistant ou introuvable
Lorsque les projets sont anciens, la documentation peut avoir disparue ou n’avoir jamais existé. Pourquoi cela arrive-t-il ? Est-ce un manque de méthodologie, une pertes de données, ou simplement parce que le projet n’a jamais été officiellement documenté ? Parfois, c’est que le projet n’existe pas officiellement. C’est assez surprenant, mais une fois chez un client, on peut s’appercevoir que autour d’outils officiels gravitent autant d’outils non officiels, créés en marge, mais qui jouent un rôle important au fil du temps..
Quoi qu’il en soit, cela a un impact sur le projet : pertes de temps, incertitudes.
Dossier obsolète ou incomplet
Certains dossiers semblent figés dans le temps… probablement le dernier projet où l’on utilisait encore Windows XP.
Il arrive que le dossier d’architecture soit ancien et n’ai pas suivi les évolutions majeures du projet. Dans certains cas, le dossier est créé au début mais n’est considéré que comme une formalité pour la durée de vie du projet. dans d’autres cas, des sections sont manquantes ou mal définies. Les conséquences sont des incohérences entre l’existant et le document ou l’absence de spécifications pour des parties critiques
Lire un dossier incomplet, c’est comme recevoir un meuble IKEA sans notice : tout semble là, mais bonne chance pour assembler le tout sans pleurer.
II. Les enjeux de la mise à jour
Les parties prenantes peuvent avoir plusieurs réaction. Le client découvre (ou pas) des trous et veut une correction rapide, tandis que l’équipe peut se retrouver confrontée à une tâche complexe de mise à jour.
Une petite structure permettra une plus grande flexibilité pour une mise à jour progressive. alors qu’une grande structure aura probablement une rigidité des processus de validation et cela peut avoir un impact important sur les délais.
III. Méthodologie pour reprendre un dossier
Je vais peut être enfoncer une porte ouverte, mais comme dans beaucoup de domaines, la méthodologie est très similaire.
Récupérer un vieux dossier, c’est un peu comme hériter d’un fichier Excel géant sans explications : tout le monde sait qu’il est important, mais personne ne sait pourquoi.
Étape 1 : Faire l’état des lieux
« Faire un diagnostic rapide, c’est un peu comme jouer à ‘Où est Charlie ?’, mais dans un chaos de documents techniques et d’emails égarés. »
Si aucun document n’existe, l’état des lieux n’est pas plus simple pour autant. En effet, il faudra identifier tous les composants, soft et hard, les configurations, les environnements, etc. Si une base existe, ce même travail sera aussi à faire afin d’identifier les manques et les incohérences. l’état des lieux n’est pas solitaire, des ateliers seront certainements menés afin de recolter tout le savoir stockés dans les cerveaux et pour avoir accès aux documentations existantes. C’est le bon moment pour regrouper les docs et créer une vue d’ensemble du projet. Attention aux versions d’ARD, une mise à jour de version peut aussi engendrer de grandes modifications.
Une liste sera créée pour la priorisation des sections critiques à mettre à jour.
Étape 2 : Impliquer les parties prenantes
Une fois l’état des lieux réalisé, il faut valider les besoins et les priorités avec le client. Ensuite, il faudra continuer la collaboration avec les équipes concernées pour finir de collecter les informations.
Étape 3 : Structurer la reprise
Maintenant que les bsoins sont validés, l’etablissement d’un plan de mise à jour en étapes successives est nécessaire, il permettra de voir l’avancement dans le temps du dossier d’architecture et ainsi avoir une bonne estimation de la date de livraison. (Adopter une méthodologie Agile pour intégrer les changements peut être une bonne idée)
Étape 4 : Documenter efficacement
Comme d’habitude, il faut utiliser des outils adaptés pour faciliter les mises à jour futures, il est vrai que l’ARD est un document (Word, google Docs, etc.) mais attention aux schéma. En ce moment, Archi de Archimate est en vogue.
IV. Les leçons apprises et bonnes pratiques
Anticiper :
- ieux vaut prévenir que guérir. Il faut mettre en place un processus de maintenance régulière du dossier et sensibiliser les équipes à l’importance de le tenir à jour. (D’ailleurs, tous les documents doivent être tenus à jour, mais l’impasse est souvent faite par manque de temps)
Choisir les bons outils
- Utiliser des outils collaboratifs pour une documentation centralisée et des modèles standards pour éviter les incohérences.
Adopter une approche pédagogique
- Expliquer la valeur d’un dossier d’architecture complet et à jour, et montrer les bénéfices pour le client et les équipes. Même si cela parait évident, un bénéfice rapide est le passage de connaissances et il y en a bien d’autres.
Conclusion
Les surprises dans les dossiers d’architecture sont fréquentes, mais surmontables. Avec une méthodologie adaptée, il est possible de remettre les choses sur les rails. Réguliérement, je suis confronté à des changements de format, des dossiers qui tiennent presque sur des post-it, une obsolescence de plusieurs années… Selon la méthode utilisée sur le projet, il faut toujours se poser la questions des mises à jour de façon régulière, et toujours prévoir du temps pour la mise à jour de la documentation en général. Comment concilier la nécessité de mettre à jour un dossier d’architecture avec les contraintes de temps et de budget ? Quels sont les principaux obstacles à la mise en place d’une culture de la documentation au sein d’une organisation ? Comment mesurer l’efficacité d’un dossier d’architecture mis à jour ? C’est autant de questions complexes que je me pose très réguliérement.
Et vous, quelle est la pire surprise que vous avez trouvée dans un dossier d’architecture ? Dites-nous tout : je promets de ne pas juger… enfin, pas trop.
