FAQ vérification du déploiement et première connexion Emdash CMS

Publié le 2026-04-08 par Emdash Cms Everything

Que vérifier en premier après le déploiement ?

Séquence d’acceptation en trois couches :

1. Front accessible : la page d’accueil renvoie le contenu attendu.
2. Admin accessible : /_emdash/admin chargé.
3. Données inscriptibles : créer et lire un élément de contenu.

La seule accessibilité des routes ne suffit pas.

Pourquoi le front peut marcher alors que l’init admin échoue ?

Causes fréquentes :

• incohérence des bindings (DB, MEDIA, etc.)
• variables d’environnement ou secrets manquants
• configuration non supportée conservée pour le plan Free

Ordre de triage recommandé : bindings d’abord, variables d’env ensuite, contraintes de palier enfin.

Que se passe-t-il lors de la première connexion admin ?

Typiquement :

• création de l’identité admin
• enregistrement des identifiants (ex. Passkey)
• écriture de l’état système initial

Cette étape dépend du navigateur et du compte. Réalisez-la sur un réseau stable et un navigateur compatible.

Que faire en premier si la configuration Passkey échoue ?

Dans cet ordre :

• support navigateur et disponibilité Passkey
• exactitude de l’horloge système
• problèmes cross-origin ou en-têtes de reverse proxy

Ne commencez pas par suspecter la base — la plupart des échecs d’auth viennent du client ou du proxy edge.

Qu’est-ce qu’un script d’acceptation minimal en production ?

Flux répétable :

1. Ouvrir la page d’accueil et noter la réponse.
2. Se connecter à l’admin et terminer la configuration initiale.
3. Créer et publier un contenu de test.
4. Téléverser un média et vérifier la récupération.
5. Confirmer que le contenu publié est visible sur le front.

Cela valide routes, auth, écriture, stockage et lecture.

Le déploiement semble réussi mais le contenu manque. Par où commencer ?

Diagnostic court :

1. L’élément est-il publié (pas brouillon) ?
2. Le front interroge-t-il la collection attendue ?
3. Consulter les logs runtime pour erreurs de requête ou de permission.

La plupart des contenus manquants viennent de l’état ou du chemin de requête, pas d’une panne plateforme.

Comment institutionnaliser la qualité d’acceptation ?

Intégrez dans le flux de release :

• pre-merge : acceptation trois couches en local ou staging
• post-release : l’ingénieur de garde exécute le script minimal sous 10 minutes
• post-incident : ajoutez une nouvelle vérification déterministe pour éviter la récurrence

Des mises en ligne fiables viennent du processus, pas de la mémoire implicite.

Extrait de commandes de vérification

# Exemples de contrôles runtime
curl -I https://your-site.workers.dev
curl -I https://your-site.workers.dev/_emdash/admin
npx wrangler tail your-worker-name