Que fait Architecture de l'information ?
L'architecture de l'information est la manière dont le contenu et les fonctionnalités d'un système sont regroupés, étiquetés et connectés afin que les personnes puissent trouver ce dont elles ont besoin et comprendre ce qu'elles peuvent faire. Chaque décision répond à un seul test : cette structure aide-t-elle la personne qui l'utilise à faire un bon choix, rapidement, sans qu'on lui explique comment faire ?
Elle est en amont de tout le reste. Une mauvaise structure pénalise le contenu, qui n'a pas de chez-soi, le design, qui doit inventer des navigations supplémentaires, la recherche, où les URLs changent constamment, et le CMS, qui devient un empilement de contournements.
Ce skill délimite le travail et contient les règles qui s'appliquent à l'ensemble. Le travail lui-même est réalisé dans les skills ci-dessous.
1. Choisir le travail
La plupart des demandes nécessitent une partie de la boîte à outils, pas la totalité. Nommez ce que vous allez produire, afin que la personne sache ce qu'elle obtient.
| Le travail | Exécutez ceci, dans l'ordre |
|---|---|
| Réorganiser du contenu existant | content-inventory, card-sort ou taxonomies, sitemaps, url-structure si les adresses changent, tree-tests, redirect-maps |
| Nouveau site, zone d'application ou section | sitemaps, navigation, url-structure, content-models |
| Repenser un menu, une navigation ou un sélecteur d'application | navigation, labeling, tree-tests |
| Tags et catégories | taxonomies |
| Noms qui ne fonctionnent pas | labeling |
| « Les gens ne trouvent pas X » | findability, puis le skill vers lequel le diagnostic oriente |
| Déplacer ou reconstruire un site | sitemaps, navigation, url-structure, content-models, redirect-maps |
| Vérifier une structure avant de la construire | tree-tests |
| Une fonctionnalité ou un produit d'IA | Section 5 ici, puis findability |
Un sitemap seul est une décoration. Pour une construction de site, l'ensemble complet est un sitemap, des règles d'URL, un cahier des charges de navigation, un modèle de contenu et, pour toute reconstruction, une carte de redirection. Sans les quatre autres, personne ne peut construire à partir de cela.
Si un skill frère n'est pas disponible, effectuez cette partie ici en utilisant les règles ci-dessous, et mentionnez-le.
2. Cadrer, puis cartographier l'existant
Avant toute décision, déterminez qui utilise ce système et ce qu'ils essaient de faire, la quantité de contenu actuelle et dans deux ans, ce que l'entreprise en attend, et comment le succès sera mesuré. Enregistrez les chiffres actuels pour ces mesures avant tout changement, sinon il n'y aura rien à comparer par la suite.
Ensuite, construisez le portrait actuel. Ne jamais reconcevoir à partir de la page d'accueil seule.
- Dans un code source : lisez les routes, les composants de navigation,
sitemap.xml, le schéma du CMS et les éventuelles tables de catégories ou de tags. Comptez les éléments par section. Les sections vides et surchargées sont des constats en elles-mêmes. - Dans un dossier de contenu : examinez l'ensemble du corpus, pas un élément à la fois. Dites ce que c'est et à qui cela semble servir, et laissez la personne vous corriger avant de construire sur une lecture erronée.
- Contenu dans une base de données ou un CMS : exportez d'abord les titres, types, tags et dates.
- Très grands ensembles : examinez par type et échantillonnez au sein de chaque type, et dites ce que vous avez échantillonné, afin que personne ne confonde un échantillon avec un recensement.
Demandez également ce que seules les personnes savent : les publics et leurs tâches principales, la direction de l'organisation, les analyses, les journaux de recherche du site, et les questions auxquelles le support répond sans cesse.
3. Les règles qui s'appliquent à l'ensemble du travail
- Structurez par ce que les gens essaient de faire, jamais par l'organigramme. « Pour les développeurs, API » est mieux que « À propos de nous, ingénierie, API ».
- Donnez à chaque élément un emplacement canonique unique. Il peut être lié depuis d'autres endroits, mais il vit à un seul endroit.
- Privilégiez l'indice olfactif plutôt que le nombre de clics. Les gens cliquent plus loin lorsque chaque étape sent clairement leur objectif. La règle des trois clics est un mythe. Les impasses et les libellés vagues sont le véritable coût.
- Concevez pour dix fois le contenu. Si une catégorie va croître, concevez-la dès maintenant.
- Offrez plusieurs voies d'entrée. Parcours, recherche, filtres, liens connexes, fils d'Ariane.
- Placez les indices là où la décision se prend. Un bon indice répond à une question que la personne a déjà, au moment où elle choisit, à l'endroit où elle regarde déjà, discrètement et à moindre coût.
- Concevez pour le contexte supérieur. Une page se trouve dans une section, une section dans un site, un site dans une entreprise.
4. Travailler en tant qu'IA sur l'AI
Ce que vous faites bien : lire un corpus entier en quelques minutes, proposer des schémas alternatifs, appliquer une taxonomie de manière cohérente à des milliers d'éléments, trouver des termes quasi-doublons, et repérer les éléments qui ne s'intègrent nulle part.
Ce que vous ne pouvez pas faire : effectuer un tri par cartes ou un test d'arbre avec de vraies personnes, ou connaître la stratégie et la politique de l'organisation à moins qu'on vous le dise. Donc :
- Proposez, ne décidez pas. Donnez deux ou trois schémas avec leurs compromis, recommandez-en un et expliquez pourquoi. Une seule réponse cache la décision.
- Obtenez d'abord le public et la direction. Si on ne vous a pas dit pour qui c'est et où va le produit, demandez, ou énoncez votre hypothèse en haut.
- Placez tout ce qu'on vous a demandé de placer. Un élément inadapté reçoit son emplacement le moins mauvais et un drapeau, et le cas pour le déplacer, le fusionner ou le retirer fait l'objet d'une recommandation séparée.
- Livrez chaque artefact demandé. Si vous pensez qu'il ne devrait pas exister, livrez-le quand même et plaidez séparément.
- N'inventez jamais de données de recherche. Pas de nombres de participants, de taux de réussite, de volumes de tickets, de citations ou de fréquences inventés. « Utilisé toutes les heures » énoncé comme un fait compte. Dites « probablement » et listez-le comme une hypothèse.
- Ne devinez pas le comportement de la plateforme. Ce qu'un hébergeur ou un CMS peut faire varie. Dites ce à quoi vous vous attendriez et demandez à la personne de le confirmer.
- Protégez le contenu. Avant de modifier le contenu, les métadonnées, les routes ou les redirections en place, assurez-vous que le travail est sous contrôle de version ou sauvegardé.
5. AI pour les produits d'IA, et pour le contexte des agents
Avant d'ajouter de l'IA à un produit, cherchez ce qui fait réellement obstacle. Si les gens ne peuvent pas comprendre comment le système fonctionne, ne peuvent pas distinguer ses catégories, ou continuent à devoir poser les mêmes questions, une structure plus claire, un meilleur libellé ou un indice bien placé résoudront généralement cela à moindre coût qu'une boîte de dialogue. Les boutons et les menus font deux choses : ils permettent aux gens d'agir, et ils montrent aux gens ce que le système peut faire. Un dialogue ouvert fait la première chose lentement et la seconde pas du tout. Utilisez le dialogue lorsque la tâche est vraiment ouverte, et ailleurs utilisez l'IA derrière une interface structurée.
Le contexte des agents est aussi un problème d'AI. Donnez à un modèle les bonnes informations au bon moment : un fichier d'entrée court qui pointe vers des fichiers plus profonds, un emplacement canonique unique pour chaque fait, des noms cohérents, et rien de chargé dont la tâche n'a pas besoin.
6. Lorsque le travail couvre plusieurs skills
Sauf demande contraire, remettez un document unique avec :
- Résumé : la recommandation en deux ou trois phrases, et la raison principale.
- Ce qui existe maintenant : l'arborescence actuelle et les problèmes qu'elle contient, avec des décomptes.
- Les options : deux ou trois schémas, chacun avec qui il sert, ce qu'il coûte et où il est tendu.
- La proposition : l'arborescence recommandée avec le type de modèle de chaque nœud, puis les libellés et le cahier des charges de navigation, et les règles d'URL et le modèle de contenu le cas échéant.
- Migration : le mapping ancien-nouveau et les notes de réétiquetage, si quelque chose bouge.
- Hypothèses et questions ouvertes : tout ce que vous avez supposé.
- Comment valider : les tâches du test d'arbre avec leurs bonnes réponses et cibles, ou le tri par cartes à réaliser en premier.
Adaptez la taille au travail. Commencez par la recommandation, gardez chaque section aussi courte que possible tout en restant utilisable, et repoussez les longs tableaux à la fin. Un document plus long n'est pas plus approfondi.
Vérifiez la cohérence avant de le remettre. Re-comptez les totaux par rapport au tableau de placement, vérifiez chaque règle que vous énoncez par rapport aux tableaux que vous avez écrits, tracez toute affirmation sur la longueur du chemin dans l'arborescence, et assurez-vous que tout fichier livrable implémente chaque ligne du plan dont il est issu.
Pour examiner une architecture de l'information, la vôtre ou celle de quelqu'un d'autre, évaluez-la avec references/rubric.md.
7. Schémas à nommer lorsque vous les voyez
- Navigation par organigramme : sections nommées d'après les départements.
- Deux taxonomies concurrentes : le rail latéral, le fil d'Ariane et l'URL disent chacun quelque chose de différent.
- Tout sous un même parapluie :
/services/<chose>pour chaque section, un tiroir à bazar avec une URL. - Sections d'espace réservé : pages « À venir » qui sont livrées. Construisez-le ou laissez-le de côté.
- Une boîte de dialogue au lieu d'une structure : une interface IA ouverte là où des options claires répondraient plus rapidement à la question et apprendraient aux gens comment le système fonctionne.