Contenu

Les outils de la surface éditoriale et de la communauté.

Le CMS est une couche de surcharge, pas un stockage

/admin/content/cms ne contient pas le contenu. Le MDX vit dans content/**, dans le dépôt ; cette table contient des surcharges : dépublier, archiver, épingler, mettre en avant.

La dépublication retire une entrée de l'index, du sitemap, du flux RSS et de la page elle-même (une entrée retirée répond 404 au lieu de répondre 200 avec une URL canonique). Elle la retire aussi de la recherche de la documentation : le moteur liste les entrées en direct via listContentEntries à chaque appel, précisément pour qu'un retrait prenne effet immédiatement plutôt qu'à l'expiration d'un cache.

Ce qu'elle ne peut pas faire, c'est modifier le texte. Cela passe par un commit.

Les signalements ne masquent jamais rien automatiquement, et c'est voulu

/admin/content/reports contient les signalements déposés par les utilisateurs sur les fils et les messages du forum. Un signalement ne masque rien à lui seul.

L'alternative (masquer automatiquement au bout de N signalements) donne à un groupe organisé le pouvoir de faire taire un membre. La file existe pour qu'un humain décide, et le prix de ce choix, c'est que la file doit réellement être lue.

Bulletin : la capture, puis le jugement

Le cron /api/cron/bulletin-radar remplit la mémoire des signaux toutes les heures à partir de sources primaires. Tout arrive en NEW et rien n'est publiable sans un jugement humain. Le radar est un appareil de capture, pas un éditeur.

Les pages opérateur qui rendaient ce jugement (sous /ops, avec celles du Growth interne) ont été retirées le 2026-10-08 : /ops ne mène plus qu'au Dev Studio (/ops/dev, voir src/app/(dashboard)/ops/README.md).

Support : le desk asynchrone vit ici, le chat non

/admin/content/support, c'est un fil par adresse extérieure : ce que le formulaire de contact a écrit, ce que la personne a répondu par e-mail, ce qu'un opérateur a renvoyé. La ligne est écrite avant qu'un e-mail ne parte, donc une panne de Resend ne perd jamais un message.

Répondre depuis le fil envoie depuis l'adresse du desk, avec support+<thread>@ en Reply-To. La réponse de la personne revient par POST /api/webhooks/resend (email.received) et arrive sur le même fil ; un fil résolu se rouvre à sa réception. La carte Adresse du fil de la page de détail est cette adresse : tout e-mail qui y est transféré est rattaché au fil.

Une chose que la page ne fait pas, volontairement : un fil marqué spam ne peut pas recevoir de réponse tant que son statut ne change pas : le formulaire de réponse le dit au lieu d'envoyer.

La réception exige la variable RESEND_SUPPORT_DOMAIN, avec son MX chez Resend ; sans elle, les réponses partent toujours depuis le domaine racine, mais la réponse d'un client atterrit dans une boîte mail, pas sur le fil.

Feedback → roadmap → changelog

Cette boucle est le journal public du produit. Le feedback est trié ici et promu vers la roadmap ; la roadmap est livrée et devient une entrée du changelog. Seules les entrées de changelog COMPLETED sont publiques.

C'est à cause de cette boucle que le formulaire public de feedback a été retiré : il faisait doublon avec le menu déroulant du tableau de bord tout en contournant ce tri.