Une entreprise de quarante personnes perd un administrateur système. Il partait à la retraite, le départ était prévu depuis un an. Trois mois plus tard, personne ne sait plus pourquoi le certificat d'un service se renouvelle à la main tous les six mois, ni quel est le mot de passe du contrat de sauvegarde chez l'opérateur, ni pourquoi il ne faut surtout pas redémarrer un certain serveur avant dix-neuf heures.
Ces informations n'étaient nulle part. Elles étaient dans sa tête, dans un fichier texte sur son poste, et dans un courriel de 2021. Personne n'a mal fait son travail : il n'existait tout simplement aucun endroit où les écrire qui soit plus commode que de ne pas les écrire.
C'est tout l'enjeu d'une base de connaissances, et c'est pour cela que l'outil compte moins que la manière dont on l'installe.
Accepter d'abord qu'on ne migrera pas tout
Le réflexe est de vouloir tout reprendre : les anciens documents, les procédures dans les tableurs, le wiki abandonné de 2019, les pages du réseau partagé. C'est ce qui tue le projet, parce que l'effort devient énorme et que le résultat est une décharge propre et bien rangée.
La règle qui fonctionne est brutale : on migre ce qui a été consulté ou modifié dans les douze derniers mois, et rien d'autre. Le reste est archivé en lecture seule, à son emplacement actuel, avec un lien depuis la nouvelle base pour ceux qui iront le chercher. En pratique, cela représente souvent moins d'un cinquième du volume, et c'est la partie qui sert.
Une deuxième décision se prend au même moment : ce qui n'a pas vocation à entrer. Les documents à valeur contractuelle, les pièces comptables, les contrats signés relèvent d'une gestion documentaire avec versionnement et conservation légale, pas d'un wiki. Une base de connaissances porte le savoir-faire, pas les preuves.
Le socle, plus exigeant qu'annoncé
Outline n'est pas une application qu'on lance d'un conteneur unique. La documentation officielle le dit elle-même : l'outil est conçu comme une plateforme horizontalement extensible et son installation en production demande une compétence d'exploitation.
Les prérequis annoncés sont PostgreSQL en version 14 ou supérieure, Redis en version 4 ou supérieure, un stockage pour les fichiers joints, et un fournisseur d'authentification compatible.
Ce dernier point mérite d'être lu deux fois : l'authentification externe n'est pas une option de confort, c'est une dépendance. Il n'y a pas de comptes locaux avec mot de passe. Une organisation qui n'a pas déjà d'annuaire ni d'authentification unique doit donc en monter un avant, par exemple avec Keycloak ou un équivalent. C'est une excellente chose sur le fond, puisque les arrivées et les départs se gèrent au même endroit que pour le reste, et c'est une charge de projet qu'il faut avoir vue venir.
Le stockage des pièces jointes se branche sur un service compatible S3, ce qu'un Garage ou un MinIO fournit très bien sur une infrastructure interne, sans dépendre d'un fournisseur externe.
L'arborescence décide de l'adoption
C'est l'étape la plus rapide et la plus déterminante.
Deux organisations sont possibles. Par équipe, ce qui est le réflexe naturel : une section pour l'informatique, une pour les ressources humaines, une pour le commerce. Par sujet, ce qui vient moins naturellement : l'accueil d'un nouvel arrivant, les procédures de sécurité, les clients.
L'organisation par équipe a un défaut redoutable : les sujets transverses n'ont pas de place. La procédure d'arrivée d'un nouveau salarié concerne les ressources humaines, l'informatique et le manager. Rangée dans une seule section, elle sera introuvable pour les deux autres, qui en écriront leur propre version. Six mois plus tard, trois procédures d'arrivée coexistent et se contredisent.
L'organisation par sujet demande une discussion de deux heures au départ et évite ce scénario. Elle rend aussi la recherche plus naturelle, puisqu'on cherche un sujet, jamais un service.
Une règle complète le tout : une page a un propriétaire nommé et une date de dernière revue. Sans propriétaire, une page périmée reste en ligne éternellement, et une base de connaissances dans laquelle on ne peut pas faire confiance à ce qu'on lit ne vaut pas mieux que pas de base du tout.
L'import, et le piège du copier-coller
Outline parle le Markdown, ce qui rend l'import d'un wiki existant presque indolore. Les documents bureautiques, eux, passent mal : la mise en forme se perd, les tableaux se cassent, les images sautent.
La méthode qui donne le meilleur résultat est aussi la moins technique. Pour chaque document à reprendre, on demande à son auteur de le relire et de le réécrire dans le nouvel outil, en coupant ce qui n'est plus vrai. C'est long, cela ne se délègue pas à un script, et c'est la seule façon d'obtenir une base dont le contenu est exact au premier jour.
Sur un volume important, cette réécriture se planifie sur quelques semaines, par lots, avec une personne responsable de chaque lot. Un import automatique complet produit mille pages que personne n'a relues, dont la moitié est fausse, et détruit la confiance avant même le lancement.
Ce qui fait qu'elle vit ou qu'elle meurt
Une base de connaissances ne meurt pas d'un problème technique. Elle meurt parce que plus personne n'y écrit.
Trois habitudes changent tout, et aucune ne relève de l'outil. La première : toute réponse donnée deux fois par messagerie devient une page, et la troisième fois on envoie le lien. La deuxième : la fin d'un incident inclut l'écriture ou la mise à jour de la page correspondante, au même titre que le rapport. La troisième : une revue trimestrielle où chaque propriétaire passe sur ses pages et supprime ce qui ne sert plus. Supprimer est un acte de maintenance, pas une perte.
L'indicateur à surveiller n'est pas le nombre de pages, qui ne fait que croître, mais le nombre de pages modifiées dans le mois. Une base où plus rien ne bouge est une base morte qui n'a pas encore été enterrée.
Ce qu'il faut tenir en exploitation
Trois composants à sauvegarder ensemble et de façon cohérente : la base PostgreSQL, qui contient les documents et l'historique des révisions ; le stockage des pièces jointes, sans lequel les documents restaurés seront troués ; et la configuration, qui porte les secrets de raccordement à l'authentification.
Le point le plus souvent oublié est la clé de chiffrement de la configuration : restaurer une base sans elle donne une application qui démarre et qui ne sait plus déchiffrer ses propres paramètres.
Côté disponibilité, le besoin est modéré et il faut le dire franchement : une base de connaissances indisponible une demi-journée est gênante, pas bloquante. Sauf pour un cas précis, et il mérite d'être anticipé : le jour où l'infrastructure est en panne, c'est précisément le moment où l'on a besoin des procédures. Une base de connaissances hébergée sur l'infrastructure qu'elle documente est inaccessible quand elle sert le plus. Une copie exportée régulièrement, stockée ailleurs et lisible sans l'application, coûte peu et évite ce paradoxe.
Enfin, cette base est la matière première idéale pour une recherche documentaire en langage naturel, puisque son contenu est structuré, à jour et déjà porteur de droits d'accès. C'est un bon argument pour la construire proprement dès le départ.
Un mot sur la licence
Outline est distribué sous Business Source License 1.1, avec une bascule automatique vers Apache 2.0 le 9 septembre 2030. Cette licence autorise l'usage interne et interdit explicitement d'en faire un service documentaire commercial, c'est-à-dire une offre permettant à des tiers de créer leurs propres équipes et documents. Déployer Outline pour son organisation ne pose donc aucun problème ; en faire une offre mutualisée revendue, si.
Sources
- Dépôt GitHub outline/outline, 40 646 étoiles au 21 septembre 2026, base de connaissances collaborative compatible Markdown
- Licence d'Outline, Business Source License 1.1, restriction sur les services documentaires, bascule vers Apache 2.0 au 9 septembre 2030
- Prérequis d'auto-hébergement, PostgreSQL 14 ou supérieur, Redis 4 ou supérieur, fournisseur d'authentification compatible
- Guide d'hébergement Outline, architecture horizontalement extensible et compétence d'exploitation requise
