Retour au Blog

Pourquoi votre wiki ne fonctionne pas (et que faire à la place)

Les cinq problèmes prévisibles qui tuent les wikis d'entreprise — et comment vraiment les résoudre

Diagnostic de l'échec du wiki d'entreprise montrant les problèmes courants et les alternatives propulsées par l'IA

Points clés à retenir

  • Les wikis d'entreprise échouent non pas parce que la technologie est défaillante, mais parce qu'ils succombent à l'entropie organisationnelle : manque de responsabilité, mauvaise recherche et perte rapide de confiance face au contenu obsolète
  • Plus un wiki accumule de contenu, plus il devient difficile de trouver quelque chose de précis — le succès crée son propre mode d'échec
  • Une seule mauvaise expérience avec du contenu wiki obsolète peut annuler des années de bonnes contributions, propageant la méfiance au sein des équipes
  • Pour améliorer l'accès aux connaissances, les organisations doivent passer d'une mentalité de « stockage » à une mentalité de « réponse » — en désignant des responsables clairs et en ajoutant éventuellement une couche d'IA pour la recherche

À un moment donné, quelqu'un dans votre entreprise a eu une bonne idée : mettons toutes nos connaissances dans un wiki.

Confluence, Notion, SharePoint, peu importe. Un seul endroit pour tout. N'importe qui peut contribuer. Tout le monde peut trouver ce dont il a besoin.

C'était il y a deux ans. Peut-être cinq. Peut-être dix.

Aujourd'hui, le wiki existe, techniquement. Il contient des milliers de pages. Certaines sont utiles. Beaucoup sont orphelines — créées une fois, jamais mises à jour, avec des liens vers des contenus qui n'existent plus. Personne ne sait ce qui est à jour et ce qui ne l'est pas. Chercher quelque chose de précis renvoie une douzaine de résultats, et aucun n'est vraiment le bon.

0

Le nombre de personnes qui maintiennent activement votre wiki en ce moment — probablement. Quand tout le monde en est responsable, personne ne l'est.

Les gens ont abandonné. Quand ils ont besoin d'information, ils demandent à quelqu'un. Ou ils fouillent dans l'historique Slack. Ou ils se débrouillent seuls en espérant avoir trouvé la bonne réponse.

Le wiki n'a pas échoué parce que c'était une mauvaise idée. Il a échoué à cause de problèmes prévisibles que personne n'a résolus. Si vous pouvez nommer le problème, vous pouvez le corriger — ou au moins décider si cela vaut l'effort.

Le premier problème : personne n'en est responsable

Quand le wiki a été lancé, il y avait de l'énergie. Les gens ont contribué. Les choses se sont organisées. Mais ensuite, les personnes motivées sont passées à d'autres projets. De nouvelles priorités ont émergé.

Le wiki est devenu la responsabilité de tout le monde, ce qui signifie qu'il est devenu la responsabilité de personne.

Le contenu est devenu obsolète. Les pages se sont contredites. La structure qui avait du sens au départ ne correspondait plus au fonctionnement réel de l'organisation. Personne ne l'a remarqué parce que personne ne regardait.

Les wikis ont besoin de responsables. Pas d'un comité de pilotage — d'une vraie personne dont le travail inclut de maintenir le wiki en bonne santé. Réviser le contenu. Archiver l'obsolète. S'assurer que les nouvelles informations sont ajoutées. Sans cela, l'entropie gagne. C'est toujours le cas.

Si personne ne s'occupe de votre wiki, c'est votre premier problème à résoudre. Tout le reste en découle.

Le deuxième problème : contribuer n'est la priorité de personne

Les gens sont occupés. Ils ont un vrai travail. Rédiger de la documentation n'apparaît pas dans leurs évaluations de performance. Personne ne vérifie s'ils maintiennent à jour les pages wiki de leur équipe.

Alors ils ne le font pas. Ils ont l'intention de le faire. Ils s'y mettront éventuellement. Mais il y a toujours quelque chose de plus urgent, et le wiki peut attendre. Il attend indéfiniment.

À quand remonte la dernière fois qu'un membre de votre équipe a été reconnu — ou même remercié — pour avoir mis à jour la documentation interne ?

Les organisations où les wikis fonctionnent ont trouvé comment rendre la contribution soit obligatoire, soit irrésistible. Certaines font de la documentation une partie intégrante du travail — un projet n'est pas terminé tant qu'il n'est pas documenté. D'autres intègrent la contribution dans les flux de travail pour que cela se fasse naturellement. Certaines ont simplement une culture où écrire les choses est valorisé.

Si votre culture traite la documentation comme une corvée optionnelle, votre wiki le reflétera. L'outil n'est pas le problème. Ce sont les incitations.

Le troisième problème : trouver des choses est trop difficile

Les wikis sont conçus pour la contribution. Ils ne sont pas toujours conçus pour la recherche d'information. Ajouter une page est facile. Retrouver cette page six mois plus tard, quand vous ne vous souvenez plus de son nom ni de son emplacement ? Pas facile.

La recherche aide, mais la recherche wiki est souvent médiocre. Si vous cherchez « politique de dépenses », vous obtenez toutes les pages qui mentionnent les dépenses. La vraie politique de dépenses est quelque part dans les résultats, noyée parmi les notes de réunion et les plans de projet qui mentionnaient les dépenses en passant.

Le piège de la taxonomie

Et la recherche ne fonctionne que si vous savez quoi chercher. Si vous ne connaissez pas la terminologie — si vous êtes nouveau, ou si vous cherchez quelque chose en dehors de votre domaine habituel — vous êtes coincé à naviguer dans une structure qui n'a pas été conçue pour vous. L'ironie est que plus un wiki a de contenu, plus il devient difficile de trouver quelque chose de précis. Le succès crée son propre mode d'échec.

Le paradoxe de la recherche wiki : plus vous ajoutez de contenu, plus les résultats de recherche deviennent bruyants — et moins il est probable que quiconque trouve ce dont il a vraiment besoin.

Le quatrième problème : la confiance s'érode avec le temps

Un employé trouve une page wiki qui répond à sa question. Il prend une décision en se basant dessus. Plus tard, il découvre que la page était obsolète — la politique avait changé un an plus tôt, mais personne n'avait mis à jour le wiki.

Maintenant, il ne fait plus confiance au wiki. Il vérifie quand même auprès d'un collègue. Il dit à ses collègues de ne pas se fier à ce qui s'y trouve. La réputation se propage vite.

La confiance est difficile à construire et facile à détruire. Une seule mauvaise expérience peut annuler des années de bon contenu. Et plus le wiki grossit, plus les occasions se multiplient pour que des pages obsolètes posent problème.

Certaines équipes essaient de résoudre cela avec des dates de « dernière mise à jour ». Cela aide, mais ce n'est pas suffisant. Une page mise à jour hier peut encore être fausse. Une page intouchée depuis deux ans peut encore être exacte. Les dates signalent quelque chose, mais elles ne résolvent pas le problème fondamental : quelqu'un doit activement maintenir le contenu.

Le cinquième problème : les wikis résolvent le mauvais problème

C'est le plus difficile à voir quand on est dedans.

L'hypothèse derrière un wiki est que les gens veulent parcourir des documents. Si vous organisez assez bien l'information, ils navigueront jusqu'à elle et la liront.

Mais ce n'est pas ce que les gens veulent. Ils veulent des réponses. Ils ont une question, ils veulent la réponse, ils veulent retourner travailler.

Lire une page wiki pour trouver le paragraphe pertinent, c'est de la friction. Naviguer dans une hiérarchie pour trouver la bonne page, c'est de la friction. Chaque clic et défilement est une occasion pour eux d'abandonner et de simplement demander à quelqu'un.

Posez-vous la question : vos employés cherchent-ils des documents, ou cherchent-ils des réponses ? Si ce sont des réponses, votre wiki résolvait le mauvais problème dès le départ.

Les wikis ont été conçus pour un monde d'avant l'IA. Ils supposent que les humains feront le travail de trouver et d'extraire l'information. Ils sont optimisés pour le stockage et l'organisation, pas pour la recherche et les réponses. Cela fonctionnait à peu près quand il n'y avait pas d'alternative. Maintenant, il y en a une.

Alors, que faire à la place ?

Vous avez plusieurs options, et elles ne sont pas mutuellement exclusives.

1. Réparer le wiki

Si le contenu est fondamentalement bon — juste désorganisé, obsolète et mal indexé — le wiki peut être récupérable. Désignez un responsable. Auditez le contenu. Archivez l'obsolète. Améliorez la recherche. Faites de la contribution une partie du travail, pas un bonus optionnel. Cela fonctionne, mais cela demande un effort soutenu.

2. Ajouter une couche d'IA

Certaines organisations conservent leur wiki comme source de vérité mais ajoutent une couche d'assistant de connaissances IA pour la recherche de connaissances. Les employés posent des questions en langage naturel, l'IA trouve le contenu pertinent et synthétise une réponse. Cela peut fonctionner étonnamment bien. Vous bénéficiez du contenu existant sans obliger les utilisateurs à naviguer dans la structure du wiki. L'IA fait la recherche ; les humains posent simplement leurs questions.

Le piège, c'est que l'IA hérite de tous les problèmes de votre wiki. Si le contenu est obsolète, l'IA donnera des réponses obsolètes. Si le contenu est contradictoire, l'IA pourrait être confuse. Vous n'êtes pas dispensé de maintenir la qualité — vous améliorez simplement l'accès.

3. Repartir de zéro

Parfois, le wiki est trop dégradé — trop de contenu inutile, trop peu de structure, trop d'années de négligence. Le réparer demanderait plus d'efforts que de repartir à neuf. Si vous repartez de zéro, réfléchissez à ce dont vous avez vraiment besoin. Peut-être une base de connaissances conçue pour les questions-réponses plutôt que pour la navigation. Peut-être quelque chose avec une recherche alimentée par l'IA intégrée dès le départ. Peut-être un périmètre plus restreint — uniquement le contenu le plus important, activement maintenu, plutôt que d'essayer de tout documenter.

Le bilan réaliste

Voici la vérité inconfortable : votre wiki a probablement échoué pour des raisons prévisibles et évitables. Personne n'en était responsable. Personne n'était récompensé pour y contribuer. La recherche était mauvaise. La confiance s'est érodée. Et le modèle fondamental — organiser des documents, espérer que les gens les trouvent — était toujours un peu défaillant.

Vous pouvez résoudre ces problèmes. Ou vous pouvez les accepter et les contourner. Ce que vous ne pouvez pas faire, c'est prétendre qu'ils n'existent pas et attendre des résultats différents. Le wiki ne va pas soudainement se mettre à fonctionner tout seul. Quelque chose doit changer.

JoySuite est conçu autour de la façon dont les gens trouvent réellement l'information — en posant des questions. Pas de navigation dans des dossiers ni d'espoir que la recherche fonctionne. Joy répond à partir de votre contenu avec des sources vérifiables, en tirant l'information de tous vos systèmes grâce à des connecteurs universels. Et quand quelque chose manque, vous le savez — pour pouvoir le corriger.

Dan Belhassen

Dan Belhassen

Fondateur et PDG, Neovation Learning Solutions

Prêt à transformer la façon dont votre équipe travaille?

Rejoignez les organisations qui utilisent JoySuite pour trouver des réponses plus rapidement, apprendre continuellement et accomplir plus.

Rejoindre la Liste d'Attente