Centraliser le savoir : la base de connaissances

La mémoire de l'équipe ne doit pas vivre dans une tête

Dans une équipe jeune, l'information critique est souvent stockée dans le cerveau du fondateur : comment on facture, où sont les accès, pourquoi telle décision a été prise. Tant que c'est dans une tête, chaque question repose sur sa disponibilité, et chaque départ fait perdre de la mémoire. La solution n'est pas une réunion de plus, c'est une base de connaissances : un endroit unique, cherchable, où vit ce qui doit survivre aux conversations.

Si une information ne se trouve qu'en demandant à quelqu'un, elle n'est pas documentée — elle est en otage.

Les outils de base de connaissances

L'outil central de la collaboration moderne, c'est souvent le wiki d'équipe. Les options :

• Notion est le couteau suisse : pages, wikis, bases de données, modèles. Plan gratuit pour petite équipe, puis ≈ 8-10 $/utilisateur/mois. Idéal quand on veut un seul outil pour les docs et le suivi léger.
• Google Workspace (Docs + Drive) est imbattable pour la co-rédaction en temps réel et la simplicité ; moins structuré qu'un wiki (≈ 6 $/utilisateur/mois).
• Confluence vise les équipes plus grandes et techniques, structuré mais plus lourd.
• Slite ou Coda sont des alternatives à Notion, l'une plus orientée doc d'équipe, l'autre plus « doc programmable ».

Quel outil pour quel besoin

Ce qui mérite d'être documenté (et ce qui ne le mérite pas)

Tout documenter tue la documentation : plus personne ne la lit. On écrit ce qui est réutilisé ou coûteux à reposer :

1. Les procédures récurrentes : onboarding, facturation, publication d'un contenu.
2. Les décisions et leur raison : pourquoi on a choisi tel outil, telle cible, tel prix.
3. Les accès et références : où sont les comptes, les liens, les contacts clés (sans y mettre les mots de passe — voir plus bas).
4. Le « comment on travaille » : conventions de nommage, rituels, qui décide quoi.

:::tip[Astuce : documenter au fil de l'eau] La meilleure doc s'écrit au moment où l'on répond à une question pour la deuxième fois. Plutôt que de répondre en privé, écrivez la réponse dans le wiki et partagez le lien. La troisième personne se servira seule. :::

Une structure simple qui tient dans le temps

Un wiki devient vite un grenier si on n'y pose pas une arborescence. Un squelette qui fonctionne pour la plupart des petites équipes :

Accueil
├── Équipe (qui fait quoi, rituels, conventions)
├── Procédures (onboarding, facturation, publication…)
├── Projets (une page par projet actif)
├── Décisions (journal daté des choix importants)
└── Ressources (accès, liens, contacts)

L'important n'est pas la perfection de l'arborescence, mais qu'il y ait un seul endroit officiel et que tout le monde le connaisse.

La sécurité des accès : ce qui ne va PAS dans le wiki

:::danger[À ne jamais faire : stocker les mots de passe en clair] Aucun mot de passe, clé d'API ou secret ne doit traîner dans une page Notion ou un Google Doc partagé. Utilisez un gestionnaire de mots de passe d'équipe — 1Password, Bitwarden (open source, gratuit possible) ou Dashlane — qui chiffre et trace les accès. Le wiki dit où est le compte ; le coffre garde la clé. :::

Le piège de la doc qui pourrit

Une documentation fausse est pire que pas de documentation : elle fait perdre confiance et induit en erreur. Deux habitudes la maintiennent vivante : dater les pages sensibles et désigner un propriétaire par section, responsable de sa mise à jour. Une page sans propriétaire finit toujours périmée.

Ce qu'il faut retenir

Sortez la mémoire de l'équipe des têtes et des fils de chat : posez une base de connaissances unique (Notion pour le tout-en-un, Google Workspace pour la co-rédaction), documentez ce qui est réutilisé ou coûteux à reposer, et structurez en quelques sections claires avec un propriétaire chacune. Gardez les secrets dans un gestionnaire de mots de passe, jamais dans le wiki. Une fois le savoir centralisé, reste à organiser le travail lui-même : place au pilotage des projets et des tâches.