_edited.png){kind=small}
Pour ceux d'entre vous qui ne sont pas familiers avec l'architecture de l'information, il existe de nombreuses définitions de l'architecture de l'information, mais ma préférée est celle de Louis Rosenfeld et Peter Morville « Information Architecture for the World Wide Web » (mieux connue dans les cercles IA comme le « livre de l'ours polaire » pour sa couverture distinctive) où ils disent qu'un architecte de l'information est quelqu'un qui:
Clarifie la mission et la vision du site, en équilibrant les besoins de son organisme parrain et les besoins de son public. Détermine le contenu et les fonctionnalités que le site contiendra. Spécifie comment les utilisateurs trouveront des informations sur le site en définissant ses systèmes d'organisation, de navigation, d'étiquetage et de recherche. Décrit comment le site s'adaptera au changement et à la croissance au fil du temps.
Remplacez le mot «site» par «document» et vous aurez une idée de ce dont je parle - les mêmes principes s'appliquent à la vision du DA (architecte de la documentation).
Le DAT (document d’architecture technique) est un document réalisé par un architecte technique ou un architecte de la documentation. Il définit et documente tout ce qu’il faut faire et mettre en place pour réussir la mise en œuvre de l’architecture, en vue d’atteindre les objectifs et respecter les différentes contraintes.
Il explique exactement quelles ressources techniques (serveurs, machines, réseaux, protocoles, etc.) sont nécessaires pour répondre aux besoins et comment elles doivent être implémentées au sein du SI, pour une garder la performance, stabilité, sécurité, etc.
Il existe plusieurs formats de DAT, qui vont de quelques pages avec des schémas aux rapports complets et formels de plus de 100 pages. Il faut savoir cependant qu’il s’agit d’un document vivant, conçu pour être consulté, commenté, évalué et validé par les différentes parties prenantes.
Ma recommandation pour aborder une architecture est de la découper en sous-ensembles cohérents et complémentaires. C’est la démarche classique de l’ingénieur : on découpe un ensemble complexe en parties plus simples et maîtrisables.
Par défaut, un système d’information vu sous l’angle de l’architecture technique peut se décomposer en 4 plans :
Le plan fonctionnel, représente l’aspect métier, c’est à dire ce que fait l’application et la nature des données qu’elle échange avec le reste du monde ;
Le plan applicatif est concentré sur l’aspect logiciel : les flux (protocole, fréquence, sens), les stocks (partage de donnée...), les middlewares (base de données, serveur java…) et les frameworks utilisés (.NET, Java...) ;
Le plan infrastructure permet de décrire les choix techniques: les serveurs (dans le cloud ou ailleurs), leur dimensionnement, l’interconnexion via les réseaux, etc ;
La couche opérationnelle enfin, décrit comment le système va être géré : les mécanismes de sauvegarde, de supervision, de métrologie, etc.
Il existe ainsi 4 types d’architecture dans chaque système.
L’architecture opérationnelle
L’architecture fonctionnelle
L’architecture applicative
L’architecture technique
«Architecture de documentation» n'est pas (encore) un terme courant - une recherche Google fait apparaître des pages relatives à la manière de documenter l'architecture logicielle. Ce que j'entends par là, c'est que la façon dont les principes d'architecture de l'information qui ont été appliqués au Web peuvent aussi être utilisés pour améliorer des ensembles de documentation, tout en gardant à l'esprit les différences entre le Web et les nombreux types et formats que prend la documentation.
Le DA doit adopter une approche holistique pour aborder la documentation: un type de document est généralement l'un des différents types, chacun avec son propre objectif et son public différent. Le type de personne qui lira un guide de «démarrage rapide» est différent de celui qui va s'asseoir et lire un manuel d'utilisation, et vous devez en tenir compte lors de la refonte de ces types de documents. Bien que vous ayez des publics différents pour différents types de documents, le DA doit examiner et auditer tous les différents types de documents disponibles pour s'assurer qu'ils ont tous un sens commun de l'objectif et qu'ils contiennent le bon type de contenu pour leur destination.
En ce qui concerne la fonctionnalité, le DA doit envisager la manière optimale d'organiser tout, des niveaux de sous-titres à utiliser dans une table des matières à l'ordre pour une indexation efficace du point de vue de l'utilisateur. Selon le type de «document», cela peut également être étendu à tous les éléments interactifs qui entrent de plus en plus en jeu (depuis les quiz interactifs, les sondages, la vidéo intégrée et les visualisations 3D). Le DA garantit également que les étiquettes (pensez: en-têtes ou métadonnées) sont claires du point de vue de l'utilisateur. La clarté l'emporte toujours sur le battage médiatique et, dans la mesure du possible, concentrez-vous plutôt sur ce que le produit fait réellement et comment il le fait.
Enfin, le DA doit également réfléchir au cycle de vie d'un document, non seulement en ce qui concerne un produit donné, mais également à la manière dont le document lui-même peut évoluer dans le temps. Par exemple, il y a une douzaine d'années, il était peut-être suffisant de fournir un fichier d'aide compilé pour aller avec un logiciel, mais maintenant il existe toutes sortes d'autres options disponibles, y compris l'aide Web, l'aide basée sur un navigateur local, le multimédia intégré tutoriels, etc. Il y a aussi des moments où un type de document n'est plus nécessaire, soit parce que le produit auquel il est lié disparaît, soit parce qu'il a été remplacé par un autre ensemble de documents.
En bref, l'architecte de documentation est un architecte d'information qui se concentre sur des publications, les optimisant pour une utilisation par les lecteurs en leur appliquant les principes de l'architecture de l'information. Les entreprises en ont besoin car elles peuvent aider à faire disparaître la «douleur» associée à un ensemble de documentation existant, peuvent aider à optimiser le transfert d'informations dans un système de gestion de contenu (CMS), et également à réaliser des économies de productivité grâce à la réutilisation du contenu. Si vous disposez d'un ensemble de documentation de taille moyenne à grande et que vous ne disposez pas d'un DA qui le gère, vos publications coûteront inévitablement plus cher que nécessaire.
En complément vous trouverez ci-dessous un cours par Openclassrooms sous licence
CC BYSA 4.0.
A très bientôt !