Roadmap

Chinaski évolue lentement et délibérément : la même philosophie qui maintient la surface livrée petite s'applique à ce qui sera ajouté ensuite. Cette page recense les améliorations actuellement en cours de planification, regroupées selon les piliers qu'elles servent. Tout ce qui est listé ici est une proposition : les affirmations « ce qui existe aujourd'hui » sont des descriptions exactes du logiciel actuel, et le reste est de l'intention, pas de l'implémentation.

Maturité des formulaires

Le module de formulaires fonctionne (soumissions, notifications, webhooks, protection anti-spam) et quatre raffinements sont planifiés pour l'amener à un niveau de qualité adapté à l'hébergement en production :

Quarantaine anti-spam au lieu de l'abandon silencieux. Aujourd'hui, le honeypot et les filtres de balisage/liens empêchent les bots d'apprendre. Ils voient le même écran de « merci » que les vraies personnes, et la soumission n'est jamais stockée. Le coût : un faux positif (une vraie personne qui colle des URLs dans un message, par exemple) disparaît sans trace et sans aucun moyen de vérifier que les filtres sont bien calibrés. Prévu : des soumissions mises en quarantaine qu'un administrateur peut examiner, libérer ou vérifier.
Santé de la livraison sur le formulaire lui-même. La journalisation des livraisons de webhooks avec retries existe déjà et est consultable dans l'admin des webhooks, mais les webhooks déclenchés par formulaire n'enregistrent pas à quel formulaire ils appartiennent, de sorte que l'écran d'édition d'un formulaire n'a rien à montrer sur la santé de ses livraisons. Prévu : rattacher les livraisons déclenchées par formulaire à leur formulaire afin que l'écran d'édition de chaque formulaire affiche son propre statut de webhook.
Libellés et messages par langue. Les libellés des formulaires, les placeholders, le message de succès et le texte du bouton de soumission sont aujourd'hui des chaînes uniques ; un mur infranchissable pour les sites multilingues. Première étape envisagée : couvrir uniquement les chaînes au niveau du formulaire, en réutilisant le mécanisme de traductions existant plutôt qu'en construisant un système parallèle par langue.
Double opt-in pour les formulaires de type newsletter. Une soumission compte dès qu'elle est stockée ; il n'y a aucune porte de confirmation avant qu'un contact ne soit considéré comme abonné. Prévu comme option d'hygiène pour les formulaires de type inscription, afin que les listes restent propres.

Découverte SEO

Aider les moteurs de recherche à trouver plus vite le contenu frais ; aujourd'hui le sitemap et le robots.txt sont corrects mais entièrement passifs :

Directives robots.txt personnalisées et prise en charge du sitemap index: le robots.txt est actuellement construit à partir d'un modèle fixe sans possibilité d'ajouter des directives (crawl-delay et similaires), et chaque langue publie un seul fichier sitemap sans fichier d'index, si bien qu'une langue franchissant le plafond de 50 000 URLs du sitemap n'a aucun chemin de scission.
Un sous-système de ping des moteurs de recherche: aujourd'hui il n'existe aucun mécanisme de notification du tout (le build webhook ping *vos propres systèmes*, pas les moteurs de recherche). Prévu : prise en charge de Google Indexing API / Bing URL Submission avec retries et visibilité des soumissions, pour que vous puissiez voir ce qui a été soumis et quand.
Prise en charge du protocole IndexNow: le précurseur : notifier proactivement aux moteurs participants quelles URLs ont changé à chaque build, au lieu de compter sur la découverte organique par exploration. Même objectif de maturité que la ligne précédente : retries et un registre de soumissions visible.
Gestion complète de la taxonomie: les catégories sont à plat aujourd'hui (pas d'imbrication parent/enfant), et les tags sont une simple colonne de texte séparée par des virgules sans prise en charge des synonymes (« CMS » et « Content Management System » ne se reconnaissent pas mutuellement). Prévu : hiérarchie de tags, synonymes, et les pages d'archive qui rendent la navigation taxonomique utile.

Contrôle d'accès

Le modèle de permissions actuel est délibérément simple (deux rôles plus des restrictions de contenu/langue grossières par utilisateur) et les ajouts planifiés donnent aux équipes en croissance un contrôle plus précis :

Un rôle Manager entre admin et éditeur: pour les responsables d'équipe qui ont besoin de publier et d'inviter des utilisateurs sans accès destructeur complet (l'ensemble de rôles compte actuellement exactement deux éléments).
Clés API à permissions délimitées: les clés API existantes portent la lecture ou l'écriture ; prévu : des portées plus fines pour que les intégrations de service à service n'aient pas besoin d'un accès complet.
Comptes de service: des comptes non humains avec leur propre matrice de permissions, leurs allowlists IP, et une expiration/rotation pour l'automatisation qui ne devrait pas emprunter les identifiants d'une personne.
Une table de capacités unifiée: en remplacement des conventions « ces pages seulement / ces formulaires seulement » par un seul système de capacités prenant en charge à la fois les octrois par entité et globaux.
Permissions au niveau de la page: restreindre une page ou un article précis (à un propriétaire, ou à des rôles désignés) pour les sites multi-équipes et les brouillons sous embargo ; aujourd'hui les restrictions n'existent qu'au niveau du type d'entité et de la langue.
Contrôle d'accès au niveau du champ: conditionner l'accès aux champs critiques pour le SEO (URL canonique, noindex, données structurées) par rôle, pour qu'une édition de contenu ne puisse pas atteindre involontairement des réglages qui affectent l'indexation de tout le site.

Ce qui n'est pas sur cette roadmap

La roadmap publique liste ce que le projet entend construire ; elle ne promet ni dates ni ordre de publication. Les comportements livrés mentionnés ci-dessus (journaux de livraison des webhooks, restrictions par entité, le système à deux rôles) sont documentés sur leurs propres pages ; le travail planifié ici s'appuie dessus, et crée des liens plutôt que de répéter.

'Roadmap' en une phrase : les piliers ci-dessus sont le travail d'achèvement : un système de formulaires prêt pour le marketing basé sur les listes, une assistance à la découverte pour les moteurs de recherche, et un contrôle d'accès qui passe de l'opérateur solo aux organisations multi-équipes. Rien ici ne se livre sans que sa clause « ce que ça fait aujourd'hui » reste vraie, alors revenez vérifier à mesure que les éléments arrivent.