Skibidystopie
Construire un observatoire qui ne se contente pas de publier.
Skibidystopie est un produit-laboratoire développé en interne : un agent IA basé sur Hermes construit, alimente et fait évoluer un observatoire éditorial consacré aux absurdités contemporaines, avec un CMS headless et un workflow de publication contrôlé.
Cette fiche documente une expérience en cours : ce que l’agent prend en charge, les briques techniques mobilisées et les points qui doivent encore être validés.
- Nature
- Produit interne / laboratoire
- Frontend
- Astro 6 · React 18
- CMS headless
- EmDash 0.14 intégré
- Données
- SQLite · base unique
- Agent de veille
- Node TypeScript · webwatch
- Orchestration
- Hermes · 3 cycles par jour
- Publication
- Brouillon → preview → validation Telegram
- Design system
- CSS custom · sans Tailwind
- Performance
- Règles 120 Hz · cards optimisées
- Statut
- Prototype en démonstration
Un radar éditorial
en démonstration.
Les captures montrent les surfaces les plus utiles pour comprendre le produit : sa vue d’ensemble, sa matière éditoriale et la façon dont il assemble une enquête. Le site précise lui-même que les contenus de cette version sont des exemples éditoriaux fictifs.
Tester ce qui se passe quand un agent devient aussi constructeur et éditeur.
L’idée n’est pas de produire une vitrine de plus. Skibidystopie sert à explorer une chaîne complète : une intention éditoriale, un frontend public, un CMS, une collecte proactive et une capacité à proposer de nouveaux sujets. Le projet permet d’observer les points où l’autonomie crée de la valeur — et ceux où elle a besoin d’un cadre humain.
- Explorer une nouvelle manière de fabriquer et de maintenir un produit numérique.
- Tester la continuité entre recherche, structuration, rédaction, publication et évolution.
- Documenter les limites d’un agent autonome avant de parler d’industrialisation.
Chercher, structurer, publier, puis recommencer.
L’agent de veille webwatch orchestre la collecte, le clustering, le scoring SKB de 1 à 5 et la génération de brouillons. Hermes déclenche trois cycles quotidiens. Le workflow reste volontairement draft-first : un aperçu est envoyé, puis la publication dépend d’une validation explicite dans Telegram. Dans l’état actuel, les fournisseurs LLM et Search sont en mode mock déterministe.
- Rechercher des sujets et des angles éditoriaux.
- Organiser les contenus en signaux, dossiers, sources et catégories.
- Générer un brouillon et un lien de prévisualisation signé.
- Conserver une reprise, une réécriture ou un rejet humain avant publication.
Une base web légère autour d’un agent qui orchestre.
La démonstration met en regard plusieurs couches. Astro 6, en rendu SSR standalone, porte le frontend public. EmDash 0.14 est intégré à Astro comme CMS headless et s’appuie sur une base SQLite unique. L’agent webwatch, en Node TypeScript, lit, classe et prépare les contenus ; Hermes orchestre les cycles actifs.
- Astro 6 + React 18 · frontend public et îlots interactifs.
- EmDash 0.14 · CMS headless intégré et administration.
- SQLite · contenu et médias dans un socle local unique.
- webwatch + Hermes · collecte, scoring, rédaction et orchestration.
- Cloudflare Tunnel · exposition publique du service, sans exposer les secrets d’exploitation.
L’autonomie utile commence par un cadre lisible.
Skibidystopie rappelle qu’un agent ne remplace pas une doctrine éditoriale, une architecture claire ou des garde-fous. Le choix le plus important est peut-être le workflow de publication : l’agent peut préparer et recommander, mais la validation reste traçable et humaine.
- Définir le cadre avant d’augmenter l’autonomie.
- Séparer collecte, scoring, rédaction et publication.
- Mesurer la qualité des contenus, pas seulement leur quantité.
- Privilégier le draft-first et la reprise humaine.
- Choisir une architecture légère, observable et réversible.
Passer de la démonstration à un protocole d’apprentissage.
La suite consiste à documenter les garde-fous, tester la reprise humaine, mesurer la qualité des suggestions avec des sources réelles et identifier les morceaux de cette chaîne qui méritent d’être réutilisés dans d’autres produits internes ou projets clients.
- Formaliser les règles de publication et les journaux de décision.
- Remplacer progressivement les mocks par des connecteurs évalués si le protocole le justifie.
- Comparer la pertinence des sujets proposés dans le temps.
- Tester des scénarios hybrides où l’agent et l’équipe se relaient.
- Décider ce qui peut être industrialisé sans perdre la maîtrise du système.