#Journal des changements

Ce que la plateforme a gagné, perdu ou corrigé, à la date où c’est arrivé. Les entrées sont tirées de l’historique du dépôt, pas d’une feuille de route : chacune correspond à du code qui tourne.

#Ce que ce journal couvre

Trois choses, et rien d’autre :

• le format des thèmes — ce qu’un thème peut lire, écrire et rendre ;
• le CLI — ses commandes, ses options, ses confirmations ;
• l’API HTTP — ses routes, ses portées, ses codes d’erreur.

Ce qui bouge dans le CMS lui-même — l’interface, la facturation, l’assistant — n’y figure que si un développeur peut s’en apercevoir depuis son éditeur.

#5 août 2026

La journée où la plateforme est devenue programmable. Tout ce qui suit est arrivé le même jour, dans cet ordre.

#Les thèmes Liquid

Un site peut désormais être rendu par un thème au format Shopify plutôt que par les composants React du CMS. Six dossiers, layout/theme.liquid comme coquille, des sections déclarées par un bloc {% schema %}, et des templates JSON qui les composent.

layout/     .liquid
sections/   .liquid
snippets/   .liquid
assets/     .css .svg
config/     .json
templates/  .json

Les deux moteurs cohabitent, et c’est délibéré. Un site qui a un thème publié passe par Liquid ; tous les autres continuent exactement comme avant. Aucun site en ligne n’a changé d’apparence ce jour-là — c’est ce qui a permis d’installer les thèmes sans fenêtre de maintenance. Voir l’anatomie d’un thème.

#Quatre thèmes d’origine

Origo d’abord : trente-cinq sections, sept gabarits de page, et de quoi tout régler sans toucher au code — couleurs, typographie, arrondi, largeur, densité. C’est le thème que reçoit tout le monde. Puis Forge, Vela et Piazza, plus typés.

Ils ont été renommés le jour même : leurs premiers noms étaient français et ne se prononçaient nulle part ailleurs. Un thème est un objet de catalogue, il voyage.

#page.demande — remercier sans JavaScript

Le formulaire de contact des thèmes postait dans le vide : il avait l’air de marcher et n’enregistrait rien. Il enregistre maintenant, et la page se rend à nouveau avec un objet de plus :

{% if page.demande == 'merci' %}
  <p class="merci">Merci, votre message est parti.</p>
{% elsif page.demande == 'erreur' %}
  <p class="erreur">L’envoi a échoué. Réessayez dans un instant.</p>
{% endif %}

La valeur est lue dans la chaîne de requête après la redirection. C’est ce qui permet à une section de remercier sans une ligne de script — et c’est cohérent avec le refus du .js dans assets/.

#Le bac à sable prend ses bornes

Un thème s’exécute sur le serveur qui rend aussi les sites de tous les autres. Quatre bornes sont posées : rendu plafonné à 3 secondes, source analysée à 512 Ko, objets créés à 10⁸, imbrication de sections à 6 niveaux.

Deux détails valent d’être connus, parce qu’ils viennent de défauts réels :

• les 3 secondes sont appliquées deux fois. Une simple course contre un minuteur ne coupait rien : un rendu synchrone bloque le fil d’exécution de Node, donc le minuteur ne s’exécutait jamais ;
• le compteur de profondeur vit dans une fermeture, hors de portée du thème. Tant qu’il vivait dans le contexte Liquid, {% assign _profondeur = 0 %} suffisait à le remettre à zéro — un compteur qui surveille du code ne doit pas être écrit par ce code.

Le détail complet est sur la page du bac à sable.

#asset_url ne trouvait aucune feuille de style

Rupture — c’est le correctif qui demande peut-être une action de ta part.

Le filtre ajoutait le segment assets/ à l’adresse qu’il produisait, alors que la route des fichiers de thème n’en veut pas :

La route est /theme-assets/<id>/<fichier>, un seul segment de nom, et c’est elle qui remet le préfixe assets/ pour interroger la base. Conséquence : aucun site sur thème Liquid n’avait jamais chargé sa feuille de style depuis que les thèmes existaient. Le défaut ne levait aucune erreur — la page rendait quand même, en HTML nu, ce qui ressemble à un thème mal écrit plutôt qu’à une adresse fausse.

{{ 'theme.css' | asset_url | stylesheet_tag }}

#Le CLI

scripts/theme.mjs transporte les fichiers d’un thème entre un dossier local et un site. Node 20.13 ou plus, aucune dépendance, un seul fichier qu’on peut copier ailleurs que dans ce dépôt.

Six commandes — connexion, lister, recuperer, pousser, suivre, publier — chacune avec un alias anglais. Trois garde-fous qui n’ont pas été ajoutés après coup :

• pousser signale les fichiers distants absents en local, il ne les supprime pas. --supprimer les retire, après les avoir listés et demandé confirmation ;
• recuperer liste les fichiers locaux divergents avant de les écraser ;
• suivre refuse un thème publié sans --oui-je-sais, et propose de le dupliquer.

Il n’y a pas de serveur d’aperçu local, et il n’y en aura pas : la raison tient en trois paragraphes. Référence complète des commandes sur cette page.

#Les clés d’API

Le CLI ne connaît pas les cookies du navigateur : il s’authentifie avec une clé, créée dans le CMS sous Réglages → Clés d’API. Deux portées seulement — lecture pour lire, themes pour tout.

Le secret (wc_ suivi de 43 caractères) ne s’affiche qu’une fois. La base n’en garde que l’empreinte : personne, pas même nous, ne peut le rendre. Une clé perdue se révoque et se remplace.

Le site visé se désigne par l’en-tête X-Webcosa-Site-Cible. Le suffixe -Cible n’est pas décoratif : X-Webcosa-Site, sans lui, est un en-tête que le proxy pose lui-même et purge de toute requête entrante. L’envoyer revient à ne rien envoyer, et à écrire dans le premier site venu. Voir l’authentification.

#L’éditeur de code, dans le CMS

Les fichiers d’un thème s’éditent aussi depuis le navigateur, avec la coloration syntaxique et le refus de supprimer les trois fichiers indispensables (layout/theme.liquid, templates/index.json, config/settings_schema.json).

C’est le chemin du dépannage, pas celui du travail quotidien : le CLI garde ton Git, tes raccourcis et ton éditeur. Les deux écrivent dans la même table.

#Le Store prend son adresse

Le catalogue des thèmes vit désormais sur store.webcosa.com, servi par le même déploiement mais sur son propre hôte — et ouvert aux moteurs de recherche. Ajouter un thème au catalogue passe par le guide dédié ; rien n’y monte automatiquement depuis un site.

#Cette documentation

dev.webcosa.com : trente pages de référence et de guides, la recherche en ⌘K, et un bouton « Copier la page » qui rend le markdown de la page pour le coller dans un assistant.

Deux écarts ont été relevés en l’écrivant, et documentés tels quels plutôt que corrigés en silence :

#Avant le 5 août 2026

Rien à signaler ici, et c’est exact : il n’y avait pas de surface développeur. Les sites étaient rendus par les composants React du registre du CMS, réglés depuis l’éditeur visuel. Aucun thème, aucun Liquid, aucune API publique, donc rien qu’un thème écrit aujourd’hui puisse regretter.

Ces sites-là existent toujours et continuent de rendre comme avant. C’est ce que recouvre l’expression « les deux moteurs » dans le reste de la documentation : un site passe par Liquid le jour où on lui publie un thème, jamais avant.