L’AI a une qualité remarquable : ajouter un paragraphe ne lui coûte rien. Puis un autre. Avec assez d’automatisation, on finit par découvrir que la limite principale d’une rédaction est la capacité d’une personne à lire tout ce qu’elle a déjà produit.
Dans le premier Content OS, j’explorais le passage de Custom GPT à un paquet de contenu structuré. L’idée de ContentPack était de transmettre des champs, blocs et textes localisés préparés plutôt qu’une collection de réponses de chat.
Voici une interface Publisher archivée avec un contenu fictif. Le récit source est réuni dans un éditeur ; c’est l’écran d’une première expérience, pas le système actuel de publication de nevsky.ae.
Éditeur du contenu source
Interface archivée · données de démonstration
Le paquet doit savoir ce qu’il modifie
Un lien à la version source est utile. Si le texte a changé depuis la préparation du paquet, une ancienne proposition ne doit pas écraser discrètement le travail nouveau. L’expérience utilisait une empreinte source et une application sélective des changements.
Ici, le contenu est réparti en cartes de plateformes. On peut voir les versions anglaises préparées et l’éditeur de diffusion. Aucune publication n’est envoyée depuis cette démo.
Versions pour différentes plateformes
Interface archivée · données de démonstration
La validation de schéma répondait à la question de la bonne structure. Les contrôles sémantiques demandaient si les parties convenaient au contenu. Ce sont deux choses différentes : un JSON impeccable peut contenir une biographie inventée, une légende perdue ou la traduction d’un autre article.
La matrice montre l’état de contenus fictifs selon les canaux de publication. C’est une autre façon de voir quelles parties du paquet demandent encore du travail éditorial.
Matrice de préparation
Interface archivée · données de démonstration
Le paquet était une proposition de modifications. Réussir un contrôle syntaxique ne devait pas le transformer automatiquement en page publique.
Cet écran montre le paquet JSON destiné à la transmission. On peut en examiner la structure ; son existence n’autorise pas la publication automatique de son contenu.
Transmission du ContentPack
Interface archivée · données de démonstration
Ce qui fonctionne pour moi aujourd’hui
Pour nevsky.ae, j’ai choisi un ordre plus direct : préparer et approuver le texte russe, les traductions, les images et la présentation ; les transmettre à Codex ; modifier les fichiers dans content ; voir le résultat localement ; décider séparément de publier.
C’est le fonctionnement actuel. ContentPack reste une expérience utile de conception des échanges éditoriaux, pas un éditeur automatique caché qui publie aujourd’hui mon blog.
La transmission manuelle peut sembler un recul. Mais elle place la pause au bon endroit : avant que d’autres lisent un texte signé de mon nom. Cette pause permet de voir un ancien prototype présenté comme produit fini, un terme technique décoratif ou un événement prétendument vécu qui n’a pas eu lieu.
Du premier Content OS, j’ai gardé le contenu structuré et la vérification des changements. Le blog actuel a son propre processus et une acceptation manuelle du texte. Les interfaces Publisher montrent l’ancien outil, pas une autre rédaction active de Nevsky.ae.
Articles liés : L’histoire de Nevsky.ae · Contra MCP Starter · Source et Operator.
@nevsky_alexander
Sur Instagram, Dubaï au-delà de la carte postale : la famille, la ville, les trouvailles et la vie entre deux projets. Sur Threads, des réflexions à voix haute sur le design et l’IA. Sur YouTube, des vidéos qui ont besoin de plus de place qu’une story. Retrouvez-moi là où vous vous sentez bien, et gardons le contact