←~/progetti/magosox/README.md

magosox

{ “date”: “2026-08-01”, “statut”: “live”, “modules_stack”: 12 }

Automatise le contenu social d'une marque — il choisit le sujet, écrit le texte, produit les visuels et publie

magosox produit le contenu social d'une marque et le met en ligne tout seul. Aux heures qu'on lui a fixées, il décide de quoi parler, écrit le texte, en tire les visuels et publie : personne n'a rien à ouvrir. Le plus difficile n'est pas de publier, c'est de le faire en gardant une voix reconnaissable. Une publication automatique qui sonne comme une publication automatique ne vaut rien, et c'est précisément là que ce projet met l'effort.

## Le contexte de la marque est une donnée, pas du code

Ce qui rend une publication reconnaissable — la voix, la manière de s'adresser au lecteur, ce que la marque sait et ce qu'elle tait volontairement, ainsi que le stock de sujets — vit dans magosox à l'intérieur du produit et non dans le code source. Cela s'écrit et se corrige depuis l'interface, et la modification vaut dès la publication suivante, sans livraison. Tout le reste en découle : prendre en charge une nouvelle marque relève de la configuration et non du développement, et chaque marque emporte son propre contexte sans toucher à celui des autres.

## Structurer la prose, ne pas la découper

La qualité d'une publication ne vient pas d'une architecture : elle vient d'un millier de mots bien écrits. C'est une distinction qui paraît évidente et que presque tous les systèmes de ce genre manquent — ils découpent ces mots en colonnes, ton, formalité, utiliserEmoji : false, puis les recomposent, produisant des instructions moins bonnes que celles de départ. Dans magosox, les règles de voix sont des lignes qui contiennent du texte rendu au mot près, sauts de ligne et retraits compris. Le système sait seulement quand les injecter, dans quel ordre et sous quel intertitre : il structure la portée, le poids et la place de la prose, jamais la prose elle-même. Et pour qu'une intervention sur le moteur ne modifie pas la voix en douce, un test de régression recompile le prompt à partir de ces lignes et le compare, caractère par caractère, à une référence figée.

## Un registre plutôt qu'une requête

Pour que le fil ne se répète pas, le système doit savoir de quoi il a été question récemment. Le réflexe serait de le déduire des publications déjà parues, et cela ne tient pas. La fenêtre compte les publications, pas les jours, et plusieurs peuvent sortir le même jour : aucun tri chronologique ne sait les mettre en file. S'y ajoutent les publications ponctuelles écrites à la demande, qui ne renvoient à aucun sujet du catalogue et ne pourraient donc jamais être des clés étrangères. L'anti-répétition est donc un registre qui ne fait que s'accroître, avec sa propre numérotation. Une publication programmée consomme son sujet aussitôt et le rend si la publication échoue : un cycle de vie que le statut d'une publication ne saurait représenter sans mentir.

## Limites annoncées et limites appliquées

Pour chaque surface de texte, il existe deux nombres distincts : celui annoncé au modèle et celui que le contrôle applique réellement. Un titre peut être annoncé à 55 caractères et refusé seulement à 65, le message de correction continuant de dire 55. Cette marge d'environ 18 % est ce qui maintient le taux de reprise proche de zéro, et cela pèse plus qu'il n'y paraît : la deuxième tentative produit en moyenne un texte moins bon que la première. Fondre les deux nombres en une seule colonne, c'est soit inonder la boucle de correction, soit laisser chaque titre grossir de 18 %.

## De l'idée à la publication

La chaîne tourne sans surveillance, aux heures fixées par le calendrier, et chaque étape laisse une trace que l'on peut relire :

·Choix du sujet : cadence des piliers de contenu, temps de repos, rotation des catégories par usage le moins récent, saisonnalité — avec un générateur aléatoire à graine, pour pouvoir rejouer un choix

·Génération : prompt compilé depuis le contexte de la marque, sortie structurée, nettoyage, validation et boucle de correction conversationnelle

·Rendu : mustache et Chrome headless produisent les JPEG ; thème, gabarit et version de Chrome sont figés à chaque rendu

·Publication : Instagram Graph API en trois phases, avec reprise des conteneurs déjà créés et renouvellement automatique du jeton

·Planification : créneaux fixant les jours et l'heure — et, au besoin, le pilier ou le format du jour —, occurrences matérialisées à partir de ceux-ci, et un worker qui génère en avance et publie à l'heure exacte

## L'interface

L'administration est l'endroit où le contexte de la marque se modifie vraiment, sans que personne n'ait à s'approcher d'un dépôt. La connexion se fait sans mot de passe, par un code envoyé par e-mail ; il n'y a pas d'inscription, les comptes se créent depuis le terminal.

·Contexte : sections de prompt, règles de voix et documents, tout est modifiable

·Prompt : le texte exact qui partirait vers le modèle, sans l'appeler

·Sujets : le stock, avec éligibilité et distance depuis la dernière utilisation en colonne

·Taxonomie : piliers avec leur cadence, catégories, tags avec leur couleur, formats avec leurs limites annoncées et appliquées

·Publications et calendrier : ce qui sort et quand, et dans quel état

·Réglages : les fournisseurs de modèle, de stockage, d'e-mail et de rendu, chacun avec le résultat d'une vérification réelle

## Stack technologique

L'approche de la configuration mérite une note : les variables d'environnement sont le seul moyen de configurer le service avant que la base n'existe, elles restent donc. Mais dès le premier démarrage, la valeur enregistrée l'emporte, et l'interface montre laquelle des deux gagne. Changer la clé du modèle à trois heures du matin ne doit pas exiger un accès au serveur.

·API : NestJS sur Fastify, Prisma et PostgreSQL

·Administration : React, Vite, HeroUI, TanStack Query et Router

·Génération : Claude avec sortie structurée

·Rendu : Chrome headless, polices intégrées en data URI parce que Chrome applique le CORS aux @font-face même entre documents file://

·Stockage : Cloudflare R2 — Instagram télécharge les images depuis une URL publique

·Connexion : better-auth avec code à usage unique par e-mail, session dans un cookie httpOnly

·Exploitation : Docker Compose derrière un Caddy partagé, avec TLS automatique

magosox est en production depuis le 1er août 2026 et publie sans surveillance, au rythme qu'on lui a donné. Avant la mise en service, l'historique des contenus déjà parus a été chargé lui aussi, afin que l'anti-répétition dispose d'une mémoire dès le premier jour au lieu de devoir se la constituer en plusieurs semaines.

// stack

[“nestjs”, “fastify”, “prisma”, “postgres”, “react”, “vite”, “typescript”, “claude-api”, “instagram-api”, “docker”, “caddy”, “content-automation”, ]