3 pistes pour maîtriser les DAT

Pourquoi le DAT reste un point de friction dans les DSI ? Cet article explore les leviers concrets d’amélioration — collaborateurs, validation, outillage — pour rendre la documentation d’architecture technique plus fiable, fluide et stratégique.

ameliorer-gestion-dat-document-architecture-technique
Samir NAMANI
Features
Architecture SI
ameliorer-gestion-dat-document-architecture-techniqueameliorer-gestion-dat-document-architecture-technique
ameliorer-gestion-dat-document-architecture-technique

Nous l’avons vu à de nombreuses reprises dans notre série d’articles, le sujet du DAT ne rime pas avec simplicité et peut s'avérer être un vrai point de douleur pour les DSI . Dans cet article, je propose de prendre un peu de hauteur de vue sur les différentes problématiques discutées jusqu’à présent et d’explorer des pistes de réflexion pour pointer les éléments clés à améliorer.

Piste 1 : Les contributeur

Un DAT n’est jamais l'œuvre d’une personne unique mais toujours issu d’un travail d’équipe qui mobilise plusieurs acteurs : équipe projet, éditeur, architecte, exploitant, référent sécurité, etc. Bien que le DAT soit l’affaire de tous, il n’est pas pour autant à la portée de tous et demeure un document complexe à lire et à comprendre, nécessitant une maîtrise de nombreux principes afin d’être appréhendé correctement.

Lorsqu’un DAT ne respecte pas les bons processus de création et de mise à jour, il est donc naturel qu’il perde sa valeur de référence et que la confiance soit davantage portée par les sachants que par la documentation. Cela rend d’autant plus critiques les turnovers qui, naturellement, engendrent une perte de maîtrise sur l’existant.

La montée en compétences d’un architecte n’est pas chose aisée. Ce n’est pas forcément une problématique de personnes (dans le sens où telle ou telle personne ne serait pas capable ou pas à la hauteur) mais plutôt de maîtrise globale. En effet, l’architecte doit avoir une connaissance solide et transverse de l’écosystème technique de l’entreprise dans laquelle il officie.

Par exemple, cela peut concerner :

  • les problématiques de sécurité telles les échanges possibles entre les différentes zones réseaux
  • les types d’authentification requis en fonction des cas d’usage
  • le chiffrement attendu en fonction de la confidentialité des données
  • le catalogue de produits de l’entreprise afin d’aiguiller le projet vers les bonnes solutions techniques et également savoir gérer les écarts assez réguliers

Il doit également avoir une grande aisance rédactionnelle et schématique. En résumé, cela prend du temps !

L’architecte est au service des projets auxquels il contribue tout en étant le garant de la politique SI de l’entreprise. Ce rôle de garant nécessite de savoir s'adapter et d’arbitrer les règles SI sur les problématiques techniques et opérationnelles des projets.

Piste 2 : Le cycle de validation

Certaines entreprises, bien que mettant en œuvre des efforts considérables dans les processus de contrôle et validation de DAT avant toute mise en production, peuvent être confrontées à une certaine résistance en interne via des phénomènes type “shadow IT”. Il s’agit d’interventions faites en dehors de toute validation officielle par des personnes ayant les moyens techniques de les réaliser. Il peut s’agir d’ouvertures de flux, d’approvisionnements de machines, de décommissionnements, etc. Autant de gestes qui devraient théoriquement nécessiter une mise à jour préalable du DAT et une validation en comité d’architecture. Il ne s’agit pas de jeter la pierre aux personnes faisant cela mais plutôt d’essayer de comprendre ce qui peut les y mener.

Le projet gérant une application  ou un service d'infrastructure donné a une obsession  journalière : que le service fonctionne. Toute l’énergie de l’équipe est orientée vers cet objectif.

Dans ces conditions d'urgence permanente dans laquelle évoluent certains projets, parler de validation de DAT revient parfois à expliquer à un marcheur qu’il doit escalader une barrière de 3 mètres de haut alors qu’il lui suffit de la contourner. Tout l’art est donc de faire converger les intérêts des 2 parties : la gouvernance de l’entreprise doit faire adhérer les projets dans l’effort de documentation et les projets doivent y dédier un effort raisonnable tout en étant sensibilisés sur l’importance de cet engagement.

L’entreprise doit donc avoir un cycle de validation adapté aux différents types de cas de figure. Il faut notamment proposer aux projets des cycles de validation courts voire immédiats pour les cas simples. Par exemple, si un projet ne fait que redimensionner le gabarit d’une machine, tout en restant dans un cadre préalablement défini, la validation doit être très rapide. Sans cela, la validation devient un obstacle.

Il convient aussi de mieux identifier et cibler les bons relecteurs et spécifier précisément les sections à relire (celles ayant été modifiées ou ajoutées). Trop souvent, les cycles de relectures impliquent toutes les personnes d’une mailing-list pré-établie en induisant la relecture complète du DAT alors qu’une petite partie a été modifiée. Cela mène à un allongement du temps de relecture ou au contraire à des relectures précipitées.

Par ailleurs, les projets doivent être davantage sensibilisés quant à la réelle valeur ajoutée des architectes et ainsi les impliquer le plus en amont possible dans leurs évolutions. En général, lorsqu’un architecte est embarqué très tôt dans un projet, la partie documentation et validation s’en trouve immédiatement simplifiée car elle est prévue d’entrée de jeu.

Piste 3 : L’outillage

Gardons toujours en tête que le DAT est un ensemble de documents dans lesquels une même information est dispersée sous des formes différentes. Cette construction requiert une grande rigueur pour éviter toute incohérence qui conduirait à des  décalages de versions (j’utilise la dernière version du tableau des matériels mais pas la dernière version du schéma technique) ou à des décalages dans l’information (je mets à jour le schéma applicatif mais j’oublie de reporter la mise à jour dans la cartographie des flux). Par ailleurs, il est à noter que l'édition des documents  se fait sur via différents outils. Le plus communément, la suite Office va être utilisée : Visio pour la partie schématique, Excel pour les tableaux (cartographie des flux et tableau des matériels), Word pour le document de synthèse.

Dompter Excel et Word est relativement simple pour construire la structure des documents concernés. Pour ce qui est de Visio, cela l’est beaucoup moins.

Nous avons vu l’importance du schéma applicatif qui, en tant que pierre angulaire du DAT, peut nécessiter une charge de travail importante. Précision, justesse et lisibilité de l’information sont des éléments clés dans sa formalisation.

Visio est un logiciel généraliste de schématisation, il n’est donc pas spécifiquement fait pour répondre aux attentes des architectes. En outre, il est difficile de mettre en place une surcouche adaptée aux architectes sauf si un expert VB.Net vient apporter son aide.

Pour définir une architecture, son utilisation n’est pas intuitive et requiert beaucoup de pratique avant une réelle maîtrise. Nous pouvons citer la gestion des points d’accroche et des espacements entre les flux à titre d’exemples. Par ailleurs, aucune fonctionnalité de contrôle ne permet de gérer les identifiants des modules et des flux pour éviter le risque de doublons. Pour la formalisation du schéma applicatif, le temps et l’énergie se concentrent plus sur des problèmes de forme que sur des problèmes de fond, ce qui accentue le risque d’erreurs.

La communication entre les fichiers n’est par ailleurs pas possible, à savoir que par exemple, on ne peut pas faire communiquer un schéma applicatif Visio et une cartographie Excel pour automatiser le passage de l’un à l’autre, donc ça sera toujours la rigueur et la minutie de l’architecte qui devront être de mise !

Cette base de réflexion a pour but de redonner au DAT son statut de document de référence, statut qu’il a parfois perdu dans certains contextes. Mettre à jour un DAT peut parfois prendre des semaines, voire des mois. L’important est de toujours faire adhérer les équipes à la finalité de l’effort.

A l’heure où le SI est un pilier majeur des entreprises, ces dernières ne peuvent plus se permettre d’en avoir une vision approximative ou faussée. Au contraire, le SI doit être connu d’une façon quasiment chirurgicale car le jour où un problème sérieux survient sans en connaître la raison et pouvoir en évaluer les impacts, il est déjà trop tard.

PS : Nous avons créé l'outil Uncia pour apporter une réponse simple à tous ces écueils. Allez visiter notre page et faites-nous signe pour plus d'information !

https://uncia.io

https://www.linkedin.com/company/unciaio/

Découvrez aussi