#0011 — Structure doc orientée "knowledge base"

#Contexte

• Besoin d'une documentation personnelle durable et réutilisable pour le hub.
• Accumulation progressive de connaissances techniques (setup, outils, workflows) qui doivent rester centralisées.
• Nécessité de retrouver rapidement l'information au fil du temps sans relire tout le site.

#Décision

• Organiser la documentation comme une base de connaissance structurée.
• Découper les contenus en sections fonctionnelles: getting-started, infra, tools, runbooks, decisions.
• Prioriser la lisibilité et la réutilisation plutôt que le rendu "marketing" d'un site vitrine.

#Raisons

• Faciliter la recherche et la réutilisation de l'information récurrente.
• Éviter un contenu désorganisé ou difficile à maintenir sur la durée.
• Améliorer la productivité long terme en réduisant les reprises de notes.
• Autoriser une évolution progressive sans perte de cohérence entre sections.
• Mieux correspondre à un usage personnel très technique.

#Conséquences

#Positives

• Documentation structurée, navigable et cohérente.
• Meilleure capitalisation du savoir et des décisions.
• Accès rapide aux informations utiles lors des mises à jour.
• Vision globale homogène malgré des ajouts incrémentaux.

#Négatives

• Nécessité de maintenir une structure rigoureuse et à jour.
• Effort initial de catégorisation avant publication.
• Rigidité possible si la structure choisie n'est plus adaptée.

#Alternatives considérées

• Site vitrine / blog: rejeté car inadapté à un usage technique interne.
• Documentation non structurée (notes libres): rejetée car difficile à exploiter ou rechercher.
• Outils externes type Notion: rejetés car peu intégrés au workflow Git local.

#Statut

Accepté