Wiki et knowledge base¶

Organiser et entretenir un wiki ops qui reste utile dans le temps, sans devenir un cimetiere de pages oubliees.

Le problème du wiki-cimetiere¶

La plupart des équipes ont un wiki. Peu d'entre elles ont un wiki utile. Les symptomes du wiki-cimetiere sont universels :

• Des pages datant de plusieurs années sans mise à jour
• Des informations contradictoires entre plusieurs pages sur le même sujet
• Une organisation qui reflete l'historique de l'équipe plutôt que les besoins actuels
• Un moteur de recherche qui remonte des résultats perimees en premier
• Personne ne sait qui est responsable de maintenir quoi

Organisation du wiki¶

Par domaine ou par équipe ?¶

Deux approches principales :

Par domaine technique (système, réseau, base de données, sécurité) : logique pour les équipes organisees par specialite. Facilite la recherche par expertise.

Par équipe ou produit : logique pour les organisations orientees produit. Chaque équipe possédé son espace. Facilite l'ownership mais fragmente les connaissances transversales.

Une organisation hybride fonctionne souvent mieux en pratique : une section par domaine pour les éléments transversaux (sécurité, accès, réseau) et des espaces par équipe pour les spécifiques.

Taxonomie recommandee¶

graph TD
    ROOT["ops-wiki/"]
    ROOT --> GS["getting-started/<br/>Onboarding, acces, outillage"]
    ROOT --> INFRA["infrastructure/<br/>Serveurs, cloud, reseau"]
    INFRA --> PROD["production/"]
    INFRA --> PREPROD["preprod/"]
    ROOT --> SVC["services/<br/>Documentation par service"]
    SVC --> SVCA["service-a/"]
    SVC --> SVCB["service-b/"]
    ROOT --> RB["runbooks/<br/>Liens vers les runbooks"]
    ROOT --> PROC["procedures/<br/>Procedures operationnelles"]
    ROOT --> SEC["securite/<br/>Politiques, acces, contacts RSSI"]
    ROOT --> ARCH["archives/<br/>Pages retirees mais conservees"]

Conventions et templates¶

L'uniformite réduit la friction : une page qui suit toujours le même format se lit plus vite et se maintient plus facilement.

Template de page standard¶

Chaque page du wiki devrait inclure :

Conventions de nommage¶

• Titres en minuscules, mots clés en premier (pour la recherche)
• Éviter les acronymes non définis dans le titre
• Prefixer par le domaine si la page est dans un espace plat : reseau — configuration VPN

Revue périodique¶

La revue périodique est le mécanisme qui empêche la dérivé vers le wiki-cimetiere. Elle doit être planifiee et assignee, pas laissee au bon vouloir des contributeurs.

Cadence recommandee¶

Cycle de vie d'une page¶

graph LR
    A["Creation"] --> B["Active / A jour"]
    B --> C["Revue periodique"]
    C -->|Toujours valide| B
    C -->|Obsolete| D["A mettre a jour"]
    D -->|Mise a jour effectuee| B
    D -->|Plus pertinente| E["Archive"]

Déroulement d'une session de revue¶

1. Lister toutes les pages de la section a réviser
2. Pour chaque page : est-elle toujours exacte ? Toujours utile ?
3. Mettre à jour ou déléguer la mise à jour
4. Archiver les pages obsolètes (ne pas supprimer — la mémoire a de la valeur)
5. Mettre à jour la date de prochaine revue

Bonnes pratiques vs anti-patterns¶

Éviter le wiki-cimetiere : plan d'action¶

Si le wiki existant est déjà dans un état dégradé, voici une approche pragmatique :

1. Audit : lister toutes les pages avec leur date de dernière modification
2. Triage : classer en trois catégories — utile, a réviser, a archiver
3. Sprint documentaire : bloquer une journée d'équipe pour traiter le triage
4. Règles futures : établir les conventions et les assignations d'ownership
5. Intégration process : relier la mise à jour du wiki aux définition of done des changements