Posts in "Content Management 101"

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.

Customer nurturing : par quoi commencer ?

L’idée

On sent qu’on est prêt à faire du customer nurturing sérieux.

On est prêt à envoyer au compte-goutte du contenu à nos clients, de manière proactive.

On se dit que ça va aider à réduire le churn, améliorer la satisfaction des clients, déclencher des opportunités d’upsell…

Mais… Par quoi on commence ?

  • Quel contenus on envoie ?
  • A qui ?
  • Quand ?
  • A quel rythme ?
  • Pourquoi ?
  • Comment on mesure que ça marche ?

Alors, dans l’ordre.

0️⃣ Commence par la stratégie, surtout pas par l’opérationnel

Toutes ces questions juste au-dessus sont importantes, mais ce sont les dernières que tu dois te poser.

Il faut aborder le problème de manière logique et pragmatique. Et surtout ne pas essayer de deviner les bonnes réponses à ces questions.

1️⃣ L’objectif

Donc, première étape, formaliser ce qu’on attend exactement du Customer Nurturing.

C’est toujours le même problème : ce genre de tâche est très simple si tu as un (ou deux) objectifs clairs.

Et presque impossible si tu pars “un peu tous les objectifs”.

Exemple.

On travaille pour une SaaS qui permet aux entreprises de gérer plus facilement leur comptabilité.

La SaaS propose une offre standard (avec les options fondamentales), une offre avancée et une offre premium.

Plus un catalogue de modules et de services complémentaires auxquels peuvent souscrire nos clients.

En en discutant avec les décideurs et quelques interlocuteurs clés, on se met d’accord : les trois grosses priorités de ce programme de customer nurturing, ce seront…

  • Améliorer la rétention et réduire le churn (plus on arrive à conserver de clients, plus on est heureux)
  • Multiplier les upsell et les cross sell (plus on arrive à vendre de modules ou à upgrader des users, plus on est heureux)
  • Développer l’advocacy (plus on arrive à convaincre des clients de nous recommander autour d’eux, plus on est heureux)

2️⃣ Les résultats qu’on veut atteindre

Pour chacune de ces priorités, on va commencer par mesurer où on en est.

Quel est le churn actuel ? Quelle est la Customer LifeTime Value moyenne de nos clients ? Quel est l’advocacy rate parmis nos clients ?

Et, surtout, où veut-on aller ? Quels chiffres on aimerait voir ? Et d’ici quelles échéances ?

Une fois qu’on a réussi à décider ça, le reste va couler de source.

💡 Bien sûr, on ne se fait pas d’illusions. On sait très bien que les résultats qu’on est en train de décider là sont des placeholders. Temporaire.

En fonction de ce qu’on va découvrir par la suite, on reviendra sur ces résultats si on se rend compte qu’ils sont bien trop ambitieux (ou trop timides).

3️⃣ Les leviers pour y arriver

Quels sont les leviers qu’on peut actionner pour faire bouger les résultats dans le bon sens ?

Prends ton temps sur cette étape là. Il faut vraiment poser les choses. Ca va demander des audit, du benchmark, des interview, dujus de cerveau…

Il faut enchainer les “pourquoi”.

Pourquoi est-ce qu’on est pas à l’objectif ? Pourquoi ? Pourquoi ? Pourquoi ?

Qu’est-ce qui se passe ? Ou l’inverse : qu’est-ce qui ne se passe pas ?

4️⃣ Les projets pour actionner ces leviers

Une fois qu’on a fait tout ça, on rentre en mode projet.

On va sélectionner les projets qui 

  • ont le plus de chance de nous amener à l’objectif,
  • sont compatibles avec les ressources que l’on a.

Bien entendu, il va falloir planifier soigeusement chaque projet.

  • Quel va être le livrable
  • A quelle date
  • On part d’ou
  • Pourquoi c’est important
  • Quelles vont être les étapes pour arriver au livrable
  • Pour chaque étape, quelles sont les dépendances (ressoures, buyin, équipes à mettre dans la boucle, etc.)

Tout le reste après est une question de suivi… et d’exécution.

Manager les contenus d’un rules-based chatbot

Comment manager efficacement les contenus d’un rules-based chatbot quand ils commencent à s’accumuler.

Plus on prépare de réponses et de séquences pour un chatbot, plus il est facile de s’y perdre dans le contenu qu’on a déjà créé.

Et mettre à jour ce contenu (ou le développer pour obtenir de meilleurs résultats) devient alors un cauchemar.

Lire la suite

Knowledge Base : identifier les contenus dont ont le plus besoin les équipes

L’idée

On sait qu’on a besoin de training ou d’une base de connaissance. Maintenant, comment savoir quel sujets et quels contenus il faudrait tacler exactement ?

Evidemment, “quels contenus”, mais de manière pragmatique. On pas là pour lister “tous les sujets sur lesquels on pourrait faire un contenu”.

Le but, c’est d’aider les équipes et de les rendre plus efficaces.

Lire la suite

Knowledge base interne : par quoi commencer ? (Surtout quand on en a déjà une qui ne marche vraiment pas)

L’idée

Cas particulier : comment démarrer un projet de Knowledge base interne (= pour les équipes) dans une situation à problèmes.

C’est à dire…

  • Quand on a déjà un paquet de contenus en interne (généralement sur plusieurs supports)
  • Quand la thématique derrière le produit n’est pas simple (exemple type : SaaS très tech, juridique, ou compta)
Lire la suite