Architecture de l’information dans les projets SI : le fondement que les équipes IT oublient
- Ce qu’est l’architecture de l’information dans un contexte SI institutionnel
- Pourquoi elle doit être définie avant l’architecture technique
- Les livrables concrets qu’elle produit dans un projet
Ce qu’est réellement l’architecture de l’information
L’architecture de l’information (AI) définit comment le contenu et les fonctionnalités d’un système sont organisés, nommés et rendus accessibles aux utilisateurs. Elle répond à des questions simples : comment les utilisateurs vont-ils trouver ce dont ils ont besoin ? Comment les informations sont-elles structurées et catégorisées ? Quelles sont les relations entre les différentes sections du système ?
Dans un intranet hospitalier, l’AI détermine si une infirmière peut trouver le protocole de soins qu’elle cherche en moins d’une minute, ou si elle abandonne après trois tentatives infructueuses et appelle un collègue. Dans une application de gestion documentaire bancaire, elle détermine si un gérant peut retrouver un document client signé il y a trois ans sans aide extérieure.
Ce n’est pas un problème esthétique. C’est un problème fonctionnel avec des conséquences mesurables sur la productivité et le taux d’adoption du système.
Distinction fondamentale : L’architecture de l’information définit quoi mettre où et comment le nommer. L’architecture technique définit comment le système est construit. La première doit précéder la seconde. Un système techniquement solide avec une AI défaillante ne sera pas adopté.
Les quatre composantes de l’architecture de l’information
1. Le système d’organisation
Comment les informations et les fonctionnalités sont regroupées et catégorisées. Dans un SI institutionnel, cette organisation peut suivre une logique fonctionnelle (par service ou département), thématique (par type de contenu ou de document), ou orientée tâche (par action que l’utilisateur veut effectuer). Le choix du schéma d’organisation dépend des modes de recherche et de navigation des utilisateurs réels, pas des préférences de l’équipe projet.
2. Le système de navigation
Comment les utilisateurs se déplacent dans le système : menus principaux, navigation secondaire, fil d’Ariane, raccourcis, liens contextuels. Dans un intranet multi-services, la navigation doit permettre à des profils très différents (soignants, administratifs, direction) de trouver rapidement ce dont ils ont besoin, sans devoir mémoriser une arborescence complexe.
3. Le système de dénomination
Comment les sections, catégories, fonctionnalités et documents sont intitulés. C’est la composante la plus sous-estimée. Des intitulés tirés du jargon IT ou de la terminologie administrative de la direction ne correspondent pas nécessairement au vocabulaire utilisé par les utilisateurs terrain. Une taxonomie bien conçue utilise les termes que les utilisateurs emploient naturellement pour décrire ce qu’ils cherchent.
4. Le système de recherche
Comment les utilisateurs trouvent des informations spécifiques quand la navigation ne suffit pas. Dans les systèmes institutionnels avec de grands volumes de contenu, la qualité du moteur de recherche et des métadonnées associées aux documents est souvent plus importante que la qualité de la navigation.
En pratique : Sur un projet d’intranet pour un hôpital universitaire suisse de 13 000 collaborateurs, la construction de la taxonomie institutionnelle a nécessité huit semaines de travail avec des représentants de chaque pôle clinique et administratif. Ce travail, réalisé avant toute décision technique, a permis d’aligner les 47 catégories de contenu initialement proposées par les services sur 12 catégories cohérentes correspondant aux modes de recherche réels des utilisateurs.
Pourquoi l’AI doit précéder l’architecture technique
L’ordre des opérations dans un projet SI suit souvent cette séquence : cadrage, spécifications techniques, développement, puis « mise en forme » du contenu. L’architecture de l’information se retrouve traitée comme une tâche de fin de projet, après que les décisions structurantes ont été prises.
C’est une erreur de séquençage. L’AI influe sur des décisions techniques importantes : la structure de la base de données documentaire, le modèle de métadonnées, les règles de gestion des droits d’accès, l’architecture de recherche. Si ces décisions sont prises sans AI définie, elles devront être partiellement refaites une fois l’AI clarifiée, avec un coût significatif.
La séquence correcte : définir l’AI avec les utilisateurs, la valider par des tests de navigation (card sorting, tree testing), puis rédiger les spécifications fonctionnelles et techniques sur cette base. Dans un projet institutionnel, cette phase prend deux à quatre semaines. C’est un investissement qui évite des semaines de corrections post-déploiement.
Signal d’alarme : Si les discussions sur la navigation et les catégories du système commencent après le début du développement, l’AI n’a pas été traitée comme une phase de projet à part entière. Les ajustements d’arborescence en cours de développement sont significativement plus coûteux que les décisions prises en amont.
Les livrables d’une phase d’architecture de l’information
- L’arborescence du système : la structure hiérarchique complète de toutes les sections, sous-sections et types de contenu
- La taxonomie : le référentiel des termes officiels utilisés pour nommer et catégoriser le contenu, avec les synonymes et équivalences entre services
- Les gabarits de page : la structure type de chaque type de page ou d’écran, avec les zones de contenu et leurs contraintes
- Les wireframes de navigation : la représentation schématique des menus et chemins de navigation principaux
- Les résultats des tests utilisateurs : card sorting, tree testing ou tests de navigation conduits avec des utilisateurs représentatifs pour valider les choix d’organisation
Questions fréquentes
L’architecture de l’information concerne-t-elle uniquement les intranets et portails documentaires ?
Non. Elle s’applique à tout système où des utilisateurs doivent trouver des informations ou accomplir des tâches : applications métier, systèmes de gestion, dashboards décisionnels, portails partenaires. Dès qu’un système a plusieurs fonctionnalités ou plusieurs types de contenu, l’organisation de cet ensemble constitue une architecture de l’information, qu’elle soit explicitement conçue ou non.
Qui définit l’architecture de l’information dans un projet SI ?
C’est typiquement une responsabilité du Business Analyst ou du Product Owner, en collaboration avec des représentants des utilisateurs. Les équipes IT définissent comment le système est construit techniquement. Les équipes métier définissent ce dont elles ont besoin fonctionnellement. Le BA fait la synthèse des deux et produit l’AI qui sert de référence commune.
Comment valider une architecture de l’information avant le développement ?
Par des tests avec des utilisateurs représentatifs. Le card sorting (demander à des utilisateurs de regrouper des contenus selon leur propre logique) permet de valider le système d’organisation. Le tree testing (demander à des utilisateurs de trouver un contenu dans l’arborescence proposée) permet de valider la navigabilité. Ces tests prennent quelques jours et révèlent des problèmes qu’aucune revue interne ne détecte.
Une architecture de l’information doit-elle être refaite à chaque projet ?
Elle doit être revue lors de chaque projet qui modifie significativement le périmètre fonctionnel du système. Un projet d’ajout de fonctionnalités mineures n’impacte généralement pas l’AI existante. Un projet de refonte, de migration ou d’extension majeure du système nécessite une revue de l’AI pour s’assurer que la nouvelle structure reste cohérente et navigable.
Votre projet SI implique une refonte documentaire ou un intranet ?
L’architecture de l’information est l’étape que la plupart des projets sous-investissent et regrettent ensuite. Un premier échange permet d’évaluer ce que votre projet nécessite.
Prendre rendez-vous
