FAQ

Questions fréquentes sur EmDash CMS, l’architecture de ce site, les choix de déploiement et le parcours de migration depuis WordPress.

Qu’est-ce qu’EmDash CMS en une phrase ?

EmDash CMS est un CMS TypeScript full-stack construit autour d’Astro, avec un modèle de contenu moderne, une interface d’administration et une architecture de plugins conçue pour une exécution plus sûre sur Cloudflare.

EmDash est-il un CMS headless ?

Pas au sens habituel. La documentation publique d’EmDash le présente comme un CMS natif d’Astro, plutôt qu’un service de contenu séparé interrogé depuis n’importe quel frontend.

C’est important car le produit est conçu pour vivre dans l’architecture du site, et non en dehors.

EmDash est-il réservé à Cloudflare ?

Non. Les documents officiels présentent Cloudflare comme le runtime le plus adapté pour la plateforme complète, notamment pour les plugins sandboxés, D1 et R2. Mais EmDash est aussi décrit comme portable sur des environnements Node.js et des configurations compatibles SQLite ou S3.

En résumé :

  • Cloudflare est l’option de production la plus solide
  • Cloudflare n’est pas le seul environnement possible

Pourquoi ce site commence-t-il en Astro statique plutôt qu’avec le runtime complet d’EmDash ?

Parce que ce site est avant tout une surface de contenu public :

  • documentation
  • pages de plugins
  • pages de templates
  • FAQ
  • contenu de migration
  • mises à jour

Tout cela se prête parfaitement à une diffusion statique sur Cloudflare Pages. Commencer ainsi réduit la complexité et les coûts, sans bloquer une migration future vers le runtime complet.

Pourquoi ne pas construire le site officiel directement sur WordPress ?

Parce que le site doit refléter la direction produit qu’il promeut.

La structure actuelle du site reflète cette direction :

  • contenu basé sur des fichiers
  • outillage frontend moderne
  • publication claire pilotée par Git
  • bonne compatibilité avec l’édition assistée par IA

Utiliser WordPress pour promouvoir un successeur de WordPress affaiblirait aussi fortement le discours architectural.

EmDash prend-il en charge la migration depuis WordPress ?

Oui. La documentation officielle décrit trois approches d’import :

  • import de fichier WXR
  • import WordPress.com
  • interrogation via API REST

Elle décrit aussi la prise en charge des migrations pour les articles, pages, médias, taxonomies, le mapping des statuts et la conversion de Gutenberg vers Portable Text.

EmDash inclut-il l’authentification ?

Oui. Les docs officielles décrivent EmDash comme passkey-first, avec WebAuthn comme modèle principal. Elles décrivent aussi un fallback par magic link, OAuth optionnel, et la possibilité d’utiliser Cloudflare Access pour les déploiements Cloudflare.

Les pages de plugins et de templates peuvent-elles ressembler à de vraies pages produit sur ce site statique ?

Oui. Dans ce projet, chaque fiche plugin ou template peut inclure :

  • captures d’écran
  • version
  • prix
  • statut
  • date de publication
  • lien de téléchargement
  • lien GitHub
  • lien de démo
  • journal des changements

Cela suffit pour créer une couche publique convaincante de type marketplace, sans backend.

Quand ce site doit-il passer au runtime complet d’EmDash ?

Passez au runtime complet quand la diffusion statique ne suffit plus, par exemple si vous avez besoin de :

  • édition dans le navigateur pour des personnes non techniques
  • workflows de soumission authentifiés
  • gestion des médias et uploads par le runtime
  • permissions éditoriales complexes
  • opérations d’écosystème qui nécessitent des interfaces d’administration plutôt que Git

D’ici là, la diffusion statique reste l’option la plus simple à maintenir.

Le runtime complet d’EmDash nécessite-t-il des fonctionnalités Cloudflare payantes ?

Le README officiel sur GitHub indique que les plugins sandboxés dépendent de Dynamic Workers, et que cette fonctionnalité requiert actuellement un compte Cloudflare payant. Il précise aussi que vous pouvez désactiver la configuration du worker loader si vous voulez exécuter sans plugins sandboxés.

C’est une autre raison pour laquelle le site public actuel commence d’abord sur Cloudflare Pages.

L’IA peut-elle aider à maintenir ce site ?

Oui, et c’est l’une des meilleures raisons de garder un site public orienté contenu d’abord.

L’IA est plus efficace lorsqu’elle peut travailler sur :

  • des fichiers MDX distincts
  • un frontmatter explicite
  • des structures de routes stables
  • des diffs révisables

Ce projet est justement conçu pour tirer parti de cela.