Documents ou bases de données ? La gestion des connaissances structurée met fin à un faux choix
Le savoir d'une équipe vit soit dans des documents libres (wikis, pages, fichiers Word), soit dans des bases de données et tableurs rigides. Les documents sont faciles à écrire mais impossibles à interroger. Les bases sont interrogeables mais personne n'y écrit le contexte. La gestion des connaissances structurée combine les deux : des documents par blocs, plus des objets typés avec propriétés et relations. Le même savoir se lit comme une page et s'interroge comme une base.
Pourquoi les wikis pourrissent
Un wiki échoue d'une manière prévisible. Le même fait, disons le contact d'un fournisseur, l'intervalle de maintenance d'une pompe ou le responsable d'un serveur, est écrit dans cinq pages différentes. Une page est mise à jour après un changement. Les quatre autres gardent l'ancienne valeur avec un aplomb total. Pas de source unique de vérité : la prose n'a aucune notion de « ceci est le même fait ».
Pourquoi les bases de données ne les remplacent pas
Le réflexe est de « mettre ça dans une base ». Mais une ligne de table ne raconte rien. Pourquoi l'intervalle est-il de six mois et pas douze ? Qu'est-ce qui a mal tourné la dernière fois ? Quelles exceptions s'appliquent ? On cesse de consulter un système qui contient des faits sans contexte, et on cesse de mettre à jour un système qu'on ne consulte pas. Les tableurs héritent des deux problèmes, plus la dérive silencieuse des formules.
Les objets typés : des faits avec une forme
L'approche structurée donne une identité aux choses importantes. Une machine, une procédure, un client ou un serveur devient un objet avec un type, des propriétés et des relations. Les objets s'insèrent dans les documents où l'histoire se raconte, mais le fait vit une seule fois, sur l'objet. Mettez à jour l'intervalle de maintenance à cet endroit et chaque document qui s'y réfère est à jour.
Le graphe de connaissances : des relations qu'on peut parcourir
Dès que le savoir a des objets et des relations, il forme un graphe qu'on peut naviguer et questionner. Quelles procédures impliquent cet équipement ? Qu'est-ce qui dépend de ce serveur ? Quels clients sont touchés si ce composant change ? Cette analyse d'impact est exactement ce qu'une recherche plein-texte ne peut pas fournir.
Le branching : la discipline de l'ingénierie appliquée à la documentation
Les équipes de développement ont résolu depuis longtemps « comment changer quelque chose d'important en sécurité » : brouillon sur une branche, relecture, merge. Appliqué au savoir, le même flux permet de retravailler sereinement une procédure critique pendant que la version courante reste la référence. On fusionne ensuite le changement avec la trace de qui l'a relu. Pour des opérations réglementées ou sensibles, cette trace fait la différence entre une documentation et une documentation de confiance.
Qui en a réellement besoin
Les équipes dont le savoir est dense en faits interconnectés : ingénierie et exploitation, gestion d'actifs et d'infrastructures, quiconque maintient des procédures qui référencent équipements, systèmes et personnes. Si le wiki de votre équipe dérive pendant que les « vraies » données se cachent dans des tableurs, vous êtes le public visé.
Écrit par Yuma Idrissa