Ranger & réorganiser des contenus

Ranger & réorganiser des contenus

Définir la nouvelle arborescence au moment de créer (ou de refondre) un centre d’aide, une base de connaissance, un intranet, etc.

En bref : comment décider du “quoi doit être rangé où et pourquoi”.

Avertissements

1️⃣ L’architecture de l’information (IA) est un vrai métier. Dès qu’on dépasse une certaine taille de projet, il vaut mieux faire appel à quelqu’un de rôdé, qui exerce ce métier à plein temps.

2️⃣ Si la plateforme a des ambitions de référencement, il y a tout une autre série de paramètres et de contraintes qui entrent en jeu. Et, dans ce cas, il vaut mieux être accompagné aussi par un expert SEO.

Ce que tu vas trouver ici, c’est la version hyper courte. Elle est parfaite pour des projets “simples” (moins de 500 contenus), sans enjeux SEO.

Au-delà de ça, je te recommande plutôt la version longue, ou mieux, les deux bouquins cultes (concrets et pratiques) qui l’ont inspirée :

Étape par étape

👉 Pré-requis indispensable : prépare le terrain avec les décideurs (et démine un quiproquo fréquente)

Tous les décideurs avec lesquels tu vas échanger (= toute personne qui peut te faire un retour “obligatoire,” un véto ou autre sur ce que tu vas proposer) doivent comprendre quelque chose d’important.

👉 Il n’y a pas de “bonne architecture de l’information”.

Si tu y réfléchis un instant, tu te rends compte qu’il y a une infinité de combinaisons possibles de rubriques, de sous-rubriques et de manières de ranger l’information.

Quand tu vas présenter une suggestion d’architecture, il y a de fortes chances que quelqu’un te fasse remarquer…

🤔 “Ha, bah oui, mais tel contenu, il peut aller aussi bien dans cette sous-rubrique que dans cette autre”.

C’est normal. On trouvera souvent 1 ou 2 contenus qui vont être compliqués à ranger. Il faut en être conscient. 

On n’arrive pas toujours à créer des architectures parfaites où chaque contenu ne peut être que dans une seule catégorie et où les catégories couvrent tous les contenus possibles (on parle de “MECE”).

🤔 L’autre retour que tu vas souvent entrendre va être :

  • “On pourrait aussi…”
  • “Je n’aurais pas fait comme ça”

C’est un retour dangereux. Il existe une infinité de combinaisons : on trouvera toujours “quelque chose qu’on aurait pu faire différemment”.

Et parfois, on s’entête : on a une arborescence qui marche plutôt pas mal, mais on a repéré UN truc qui ne marche pas parfaitement. Et en essayant de le corriger (= on ajoute des rubtiques, on supprime, on fusionne, etc.)… eh bien, on se retrouve au final avec une architecture qui marche beaucoup moins bien que l’originale.

👉 Donc, quand quelqu’un te fait une remarque sur une architecture que tu viens de proposer, il est vraiment important de garder tout ça en tête.

Il ne faut pas avoir peur d’expérimenter : si ça se trouve, la remarque est pertinente et peut aider à améliorer l’architecture.

Mais il faut aussi savoir laisser passer certains retours.

On se contrefiche que l’arborescence trouvée soit…

  • parfaite
  • élégante
  • symétrique
  • visuellement plaisante
  • parlante pour les décideurs

La seule chose qui nous intéresse, c’est de trouver une arborescence qui réponde : 

  1. à l’objectif (= à quoi sert ce site)
  2. aux besoins des users (= que veulent-ils, comment ils fonctionnent) et 
  3. aux contenus que l’on prévoit d’y mettre

👉 Le chemin le plus court pour y arriver, c’est…

1️⃣ Se mettre d’accord entre décideurs sur nos besoins (l’objectif, les contraintes, etc.). Les formaliser pour s’assurer qu’on ne diverge pas en cours de route.

2️⃣ Comprendre comment les utilisateurs vont vouloir se servir de la plateforme.

3️⃣ Identifier tous les contenus qu’on a l’intention d’y mettre.

Une fois seulement que ces 3 étapes sont terminées, on pourra passer à la suite.

4️⃣ Choisir un type d’arborescence parmi les 6 principaux qui existent.

5️⃣ Concevoir l’architecture de l’information.

6️⃣ La tester.

7️⃣ La déployer.

💡 Je te recommande la version longue de l’article pour en savoir plus sur chaque étape, mais voici déjà les principales questions à te poser sur chaque.

1️⃣ Nos besoins

👉 Ce qui suit va peut-être te paraître bêtement évident, mais je t’assure que c’est vital. Près de 90% des problèmes que tu auras pendant le projet viendront de là : de décideurs qui pensent être d’accord sur leurs besoins, mais qui, en fait, ne le sont pas.

1/ L’objectif

Qu’est-ce que l’on attend de cette plateforme ? Quel est l’objectif business qui nous a poussés à investir pour la créer ?

On en attend quoi concrètement comme résultats sur notre bottom line ?

Exemples :

  • Moins de questions de nos clients (= le centre d’aide va permettre à plus de nos clients de trouver des réponses à leurs questions basiques)
  • Plus d’efficacité des équipes SAV (= la base de connaissance interne va leur permettre de trouver les réponses à plus de 50% des questions que posent les clients)
  • Plus de satisfaction de nos clients (= notre académie en ligne va aider nos clients à monter en puissance dans leur vie professionnelle, et ils en seront reconnaissants)

2/ Les parties prenantes

Qui soit être consulté ? Sondé ? Informé ? Intégré dans les décisions ?

3/ Timing

Quels sont les deadlines à prendre en compte ?

(En séparant bien “Les éléments non négotiables” vs “Les timings qu’on espère tenir”.)

4/ Contraintes techniques

Est-ce que l’outil qui va héberger le contenu est déjà décidé ? Est-ce qu’on veut le revoir ? Est-ce qu’on attend de définir l’IA idéal avant de choisir l’outil ou est-ce que l’IA doit être décidée en fonction de l’outil ? Est-ce qu’on ne sait pas ? Comment on va décider ?

Une fois l’outil validé, quelles sont les contraintes techniques qu’il faudra prendre en compte ?

5/ Contraintes graphiques

Est-ce qu’on doit suivre des guidelines graphiques ? Intégrer un validateur sur ce point ?

2️⃣ Les users

👉 Cette partie-là est vraiment tricky. Tu vas probablement être tenté de la sauter (ou de la survoler), mais il faut que tu résistes à la tentation.

C’est cette étape qui va te donner les éléments et les idées dont tu vas avoir besoin pour “trouver” l’IA. Si tu te retrouves coincé plus loin (étapes 4️⃣ à 6️⃣), reviens ici : tu as peut-être manqué quelque chose.

Prends une feuille de papier, ou ouvre un document sur ton ordi, et raconte qui va se servir de cette architecture.

Fred est Customer Manager.

Son job est de répondre aux questions des clients :

  • le plus vite possible
  • avec la réponse la plus exacte possible.

Fred reçoit régulièrement (environ 6x / jour) des questions auxquelles il n’a pas la réponse.

  • Parce que c’est un cas particulier que Fred n’a jamais rencontré.
  • Parce que le client est bloqué sur une partie de notre SaaS que Fred connaît mal.
  • Parce que Fred n’est pas sûr de comprendre pourquoi l’app se comporte de cette façon.

Quand ça arrive, Fred se rend sur la page d’accueil du Wiki interne.

Il veut comprendre comment l’app est censée fonctionner dans ce type de situation.

Afin de pouvoir soit répondre directement au client, soit reporter un bug à l’équipe technique pour qu’elle prenne le relais.

Quand tout se passe bien, Fred trouve très vite…

  • soit un article dédié à la feature ou à la situation (qui explique ce qui doit se passer vs ce qui ne doit pas arriver) ;
  • soit un article “d’auto-diagnostic” (qui explique “quelles vérifications faire dans quel ordre quand un client a tel problème”).

Quand ça se passe mal, Fred…

  • trouve trop d’articles qui peuvent potentiellement répondre à sa question, et ne sait pas lesquels lire (et il n’a pas le temps de tout lire) ;
  • ne trouve aucun article qui pourrait l’aider ;
  • trouve des informations contradictoires.

👉 Encore une fois, ça va peut-être te paraître bête d’écrire quelque chose qui a l’air aussi évident quand on le relit.

“Bah oui, c’est un intranet quoi.”

Mais je te garantis que, si tu ne fais pas l’exercice, ça va être un cauchemar de trouver la bonne arborescence.

Trouver la bonne arborescence est bête comme chou… tant que tu as pris le temps en amont de noter les autres infos bêtes comme chou : l’objectif, ce qu’attendent tes users, etc.

Quand tu fais ça, l’IA te saute presque aux yeux. Mais si tu zappes ces étapes “évidentes”, tu n’y arriveras jamais.

Essaye a minima de compléter la trame suivante.

Quand il se passe [DECLENCHEUR],

[USER] se rend sur la plateforme.

[USER] veut [MOTIF DE LA VISITE]

afin de [MOTIVATION]

Quand tout se passe bien, [ADJUVANT]

Mais ça coince quand [OBSTACLE]

Pour trouver la bonne histoire, il est vital que tu passes du temps avec au moins 5 users. Prends au moins 20 à 30 minute avec chacun d’eux pour comprendre qui ils sont, de quoi ils ont besoin, comment ils fonctionnent, ce qui marche pour eux aujourd’hui, ce qui ne marche pas, etc.

3️⃣ Les contenus

Quels sont les contenus qu’on a l’intention de mettre sur la plateforme ? 

C’est-à-dire, ceux que l’on a déjà (et que l’on veut conserver) plus ceux qu’on a l’intention de produire.

Tu vas avoir besoin de faire un inventaire des contenus. Et un plan des contenus à produire.

Plus, idéalement, un audit des contenus existants.

👉 Un point très important : réfléchis soigneusement avant de décider de reprendre tels quels tous les contenus que tu as déjà.

Dans certaines situations, ça fait sens. Tu as un blog, avec des articles clairement définis, chacun bien référencés dans Google.

Et tu veux simplement les organiser différemment.

Dans ce cas, pas de soucis, tu peux probablement reprendre les contenus tels quels.

Mais dans toutes les autres situations, c’est une très mauvaise idée.

Exemple type : 

“On a un intranet, mais personne ne l’a jamais vraiment géré. On a créé du contenu au fur et à mesure. Aujourd’hui, on ne sait même pas trop ce qu’on a dessus. 

Dans ce cas, il y a de fortes chances que tes contenus soient mal définis : 

  • tu as la même information dans plusieurs contenus ;
  • tu as des contenus en double ;
  • tu as des contenus qui manquent.

Donc… Si tu décides de reprendre tels quels les contenus que tu as déjà (= si tu te dis “Ok, la nouvelle architecture doit accueillir ces contenus exactement tels qu’ils sont maintenant, découpés de cette manière là”)… tu vas avoir un mal fou à trouver une arborescence qui marche.

Et avec le temps, tu vas te retrouver de plus en plus souvent face à de nouveaux contenus qui vont arriver et que tu ne sauras pas ranger dans ton architecture neuve.

👉 Si tu penses que tes contenus actuels sont mal découpés, prévois une étape supplémentaire

Commence par lister “Les contenus que nous devrions avoir sur cette plateforme” (= sans regarder ce que tu as déjà).

Puis fais un inventaire de tous les contenus dont tu disposes déjà.

Et enfin, fais un tri impitoyable parmi les contenus que tu as déjà pour voir s’ils correspondent vraiment à ce dont tu as besoin.

L’erreur classique, c’est de faire un inventaire et de te dire naïvement : 

“Ah, mais en fait, on a déjà un contenu sur X, Y et Z”

Sans te rendre compte que ces contenus, même s’ils parlent des sujets qui t’intéressent, ne répondent pas vraiment aux questions des utilisateurs.

Tu risques de dérouler ton projet sans t’en rendre compte, d’annoncer fièrement à tes utilisateurs que la nouvelle version règle tous les problèmes… puis de faire un flop.

4️⃣ Choisis le type d’arborescence

Au fur et à mesure que tu as formalisé les besoins du projet, les besoins des users et les besoins en contenu, il y a probablement un début d’idée qui a commencé à germer sur la meilleure manière d’organiser le tout.

Commence simple : choisis d’abord le type d’architecture.

A/ Une hierarchie ? (Des catégories imbriquées les unes dans les autres)

B/ Une table de donnée ? (Chaque contenu a les mêms types de propriétés. L’user peut filtrer les contenus en filtrant les propriétés.)

C/ Un catalogue ? (Un mélange de A et de B : l’user peut se rendre dans une catégorie, puis à l’intérieur de la catégorie, filtrer les contenus selon certaines propriétés.)

D/ Un parcours linéaire (D’abord le contenu 1, puis le contenu 2, puis le contenu 3, puis…)

E/ Un portail (pense “Wikipedia”)

F/ Un hybride de plusieurs types.

5️⃣ Enfin, construis l’architecture

Garde en tête tous les choix faits jusqu’ici et… tente des combinaisons. Expérimente.

Note ce qui marche et ce qui ne marche pas.

💡 L’exercice est beaucoup plus facile sur papier que sur ordinateur.

Sur écran, je trouve ça très difficile de déterminer la bonne combinaison.

En revanche, avec des post-it, ça devient immédiatement beaucoup plus facile. Il y a quelque chose dans le fait de pouvoir manipuler les post it (les déplacer, les rapprocher ou les éloigner les uns des autres) qui aide vraiment la réflexion.

6️⃣ La tester

Idéalement, avec des vrais utilisateurs.

Donne-leur des exercices et des cas concrets pour voir si l’architecture leur permet de trouver facilement ou non l’information qu’ils cherchent.

“Imagine que tu es… Il se passe… Tu veux savoir… Que fais-tu ?”

💡 Préciise-leur bien..

  • que c’est l’architecture qui est testée (pas eux)
  • qu’ils doivent faire comme si tu n’étais pas là (= il faut juste qu’ils utilisent l’architecture pour trouver le contenu et qu’ils racontent à haute voix ce qu’ils font ; pas qu’ils évaluent l’arborescence ou t’expliquent comment eux l’aurait fait)

7️⃣ La déployer

Mettre en place l’architecture (migrer les contenus, gérer la conduite du changement, etc.) est un gros morceau. Ne sous-estime pas le temps et l’énergie que cela va prendre.