Synthèse de la doc utilisateur EmDash CMS à partir de conversations réelles
Cartographie documentée des questions utilisateurs récurrentes vers des docs longues et entrées FAQ, avec priorités de publication et standards éditoriaux.
Pourquoi cette page existe
Cette page consigne la façon dont des conversations de support répétées ont été transformées en actifs de documentation durables.
Elle maintient la stratégie doc ancrée sur la friction utilisateur observée, pas sur des hypothèses internes.
Points de friction sources et emplacement documentaire
Point de friction 1 : « Par où commencer avec un projet EmDash vide ? »
Motif observé : les utilisateurs demandent une planification des dossiers avant d’écrire du code et ont besoin des arbitrages d’architecture dès le départ.
Emplacement : guide long dans docs/docs car la réponse exige séquence, justification et analyse des anti-patterns.
Page associée :
docs/docs/emdash-cms-project-bootstrap-and-directory-layout.mdx
Point de friction 2 : « Puis-je déployer sur le plan gratuit Cloudflare et qu’est-ce qui casse exactement ? »
Motif observé : les utilisateurs déploient partiellement mais échouent sur les limites fonctionnelles et l’interprétation du langage de facturation.
Emplacement : partagé entre docs/docs et docs/faq :
- le runbook de déploiement appartient aux docs longues
- la facturation et les clarifications de limites appartiennent à la FAQ
Pages associées :
docs/docs/emdash-cms-cloudflare-free-tier-production-playbook.mdxdocs/faq/emdash-cms-cloudflare-pricing-and-billing-faq.mdxdocs/faq/emdash-cms-cloudflare-free-plan-limitations-faq.mdx
Point de friction 3 : « Où dois-je exécuter ces commandes ? »
Motif observé : la commande est souvent correcte, mais le contexte de répertoire de travail est faux.
Emplacement : FAQ, car les utilisateurs ont besoin de diagnostics rapides et de règles de décision courtes.
Page associée :
docs/faq/emdash-cms-deployment-command-context-faq.mdx
Point de friction 4 : « Comment vérifier qu’un déploiement est vraiment terminé ? »
Motif observé : les utilisateurs s’arrêtent à l’accessibilité des routes et oublient la validation admin / chemins de données.
Emplacement : FAQ au format liste de contrôle et ordre de triage rapide.
Page associée :
docs/faq/emdash-cms-deployment-verification-and-first-login-faq.mdx
Point de friction 5 : « À quoi sert vraiment Dynamic Workers ? »
Motif observé : le nom de la fonctionnalité est compris, pas les implications pour les frontières de sécurité.
Emplacement : guide d’architecture dans docs/docs, car il s’agit d’une explication de modèle, pas d’une phrase.
Page associée :
docs/docs/emdash-cms-plugin-runtime-and-security-model.mdx
Ordre de publication et justification
Séquence de publication recommandée :
docs/faq/emdash-cms-cloudflare-pricing-and-billing-faq.mdxdocs/docs/emdash-cms-cloudflare-free-tier-production-playbook.mdxdocs/faq/emdash-cms-cloudflare-free-plan-limitations-faq.mdxdocs/docs/emdash-cms-project-bootstrap-and-directory-layout.mdx- le reste des références d’architecture et d’auto-hébergement
Principe d’ordonnancement :
- publier d’abord les sujets les plus confus et les plus chargés côté support
- puis publier les guides d’exécution complets
- puis publier les références d’architecture approfondies
Règles éditoriales pour garder une documentation crédible
Utilisez ces standards pour les ajouts futurs :
- commencer par la décision et la limite, puis détailler le mécanisme
- inclure signaux de succès et signaux d’échec pour chaque opération
- fournir un chemin de retour arrière ou de secours pour chaque étape à fort impact
- éviter les adjectifs abstraits sauf s’ils sont liés à des critères mesurables
- écrire pour des opérateurs sous pression temporelle, pas pour un ton marketing
Routine de maintenance
Revoyez cette cartographie chaque mois à partir de trois sources :
- questions support les plus répétées
- schémas d’échec de déploiement issus des retours utilisateurs
- pages doc avec beaucoup de sorties et peu de retours de complétion
Lorsqu’une question apparaît plus de deux fois en un mois au support, améliorez les diagnostics de la page existante ou ajoutez une entrée FAQ ciblée.