Kunstbrein : un site d'actualité qui se remplit tout seul, avec les règles éditoriales dans le code

Une instruction dans un prompt est une demande. Une porte est une porte. C'est pourquoi le contrôle qualité de Kunstbrein vit dans le code, et non dans la consigne donnée au modèle.

Cinquante sources, chaque matin, sans modèle

À 07:25, le pipeline récupère 47 flux RSS et Atom plus trois pages qui ne proposent pas de flux et sont donc interrogées directement. Ces cinquante sources ne sont pas égales : 41 peuvent fournir du contenu, neuf sont derrière un paywall et ne peuvent que signaler qu'il se passe quelque chose. Chaque source a aussi un rôle, de la source primaire à l'analyse et à la contradiction, en passant par la presse et la politique.

Ce qui suit se passe dans le code. Les flux sont normalisés, dédupliqués contre tout ce qui est déjà en ligne, puis regroupés : le même récit chez cinq éditeurs devient un seul candidat au lieu de cinq. La pondération tient compte du nombre de sources indépendantes (de façon logarithmique, car dix sources ne comptent pas dix fois), de la diversité des rôles (une source primaire plus une analyse plus la presse forment un vrai récit, cinq copies du même communiqué non), de la fraîcheur et de la présence de termes pertinents pour les PME. L'actualité purement scientifique reçoit un malus. Ce dernier réglage est arrivé après que "Midjourney rachète une appli d'astrologie" a pu devenir candidat.

Faire tout cela sans modèle n'est pas de l'économie mais de la fiabilité. Ce qui vit dans le code ne peut rien inventer, est reproductible et se teste. À ce volume, faire classer quatre-vingts titres par jour par un modèle de langage coûterait d'ailleurs plus cher que la rédaction elle-même.

Les portes : la qualité vit dans le code, pas dans le prompt

C'est le cœur du projet. Cinq couches se dressent entre un article rédigé et sa publication, toutes dans le code et toutes testées :

• Recouvrement littéral. Après la rédaction, l'article est comparé mot par mot au texte source. Toute suite de huit mots ou plus qui correspond littéralement et ne se trouve pas dans une citation marquée est un refus. Les faits sont libres, les formulations non. Un affinage est venu de la mesure : une suite plus courte contenant un chiffre est une description factuelle et non du plagiat, car "de 10 gigawatts dans le sud de l'Ohio" ne se dit pas autrement sans perdre le fait. Dix mots d'affilée sans chiffre n'est jamais un hasard.
• Vérification des faits avec deux mesures. Une puce de résumé est un fait et doit figurer dans les sources. Une conséquence d'analyse est une interprétation et ne doit par définition pas figurer dans les sources, puisque la consigne demande explicitement un angle que les sources n'ont pas. Traiter les deux de la même façon reviendrait soit à refuser toute analyse, soit à laisser passer toute affirmation factuelle inventée.
• Porte anti-doublon. Recouvrement des titres avec les publications récentes, avec un seuil. Le 30 juillet, elle a refusé un article parce qu'il reconstruisait la même intrusion via un agent IA qu'un texte de quatre jours plus tôt. À juste titre.
• Contrôle des entités et des liens. Les URL de sources, éditeurs ou noms inventés ne passent pas. Le frontmatter doit renvoyer à ce que l'étape de collecte a réellement rapporté.
• Longueurs, avec une cible et un point de rupture. Le modèle écrit vers le plafond, donc trois caractères de trop ne sont pas un défaut de qualité mais du calcul de probabilités. Il y a désormais une limite que la consigne demande et une frontière dure où la porte refuse. Entre les deux, l'article reçoit une remarque de style, et le style se corrige mais ne refuse jamais.

Le piège en dessous est le schéma de contenu. Une porte plus large que le schéma laisse passer un article qui casse le build, et le pipeline fusionne sa propre pull request. C'est pourquoi un test lit les maxima du schéma de contenu et les compare aux points de rupture dans le code. Quiconque relèvera une frontière en oubliant le schéma obtiendra un test rouge plutôt qu'un site à l'arrêt.

La moitié est refusée, et c'est voulu

Sur 16 exécutions de rédaction enregistrées, 22 articles ont été écrits et 11 publiés. Les refus : 10 sur la vérification des faits, 6 sur la longueur, 3 sur le plagiat, 2 comme doublons et 1 sur une réponse de modèle cassée. Ces 50 % ne sont pas un défaut, c'est le système qui fonctionne.

La vérification des faits existe d'ailleurs parce que quelque chose est passé. La source disait que trois modèles étaient impliqués, dont un pas encore sorti. L'article en a fait un nom de modèle que personne n'avait annoncé. Toutes les portes étaient au vert, et le corps de l'article était correct. L'erreur se trouvait dans la couche de compression, dans le résumé, et c'est précisément là que la nuance meurt. Depuis, chaque puce de cette couche est confrontée aux sources individuellement.

Le site est sa propre horloge

Le pipeline dépendait d'abord du planificateur de GitHub Actions. Ce n'est volontairement pas une garantie : les événements planifiés arrivent dans une file partagée. Mesuré sur ce dépôt, l'étape de collecte a tourné avec 2 heures et 32 minutes de retard le 26 juillet, l'étape de rédaction avec 2 heures et 2 minutes, et les 27 et 28 juillet rien n'a tourné du tout. Passer à des minutes impaires n'a rien changé, et une sentinelle accrochée à ce même planificateur n'est qu'une demi-solution.

Depuis le 28 juillet, les rôles sont inversés. Le Worker Cloudflare qui sert déjà le site est aussi le réveil : ses déclencheurs cron lancent le pipeline via un appel API qui part immédiatement, et GitHub Actions n'est plus que l'atelier. Il y avait un véritable obstacle technique en dessous, car l'adaptateur Astro construit un point d'entrée qui n'accepte que le trafic des visiteurs et ne laisse aucune place à une tâche planifiée. Un point d'entrée propre à côté de celui d'Astro résout cela, et comme une telle intervention est sensible aux versions, le script de build vérifie tout ce dont il dépend. Si quelque chose ne colle pas, le build échoue, et un build échoué est un déploiement sauté plutôt qu'un site cassé.

Cette même migration a produit la leçon la plus coûteuse du projet. Le cron de la newsletter était réglé sur une valeur qui signifie mardi et vendredi dans crontab et dans GitHub Actions. Cloudflare compte les jours de la semaine autrement, la newsletter est donc partie un jour trop tôt. Un test existait, intitulé "démarre le mardi et le vendredi matin", mais il vérifiait si la bonne chaîne de caractères figurait dans le tableau. Il testait la frappe, pas l'hypothèse, alors que son nom suggérait le contraire. La numérotation des jours de Cloudflare figure désormais comme tableau dans le code et les tests vérifient ce qui sort réellement. Un test qui ne tient pas sa propre promesse est pire que pas de test.

Git est la base de données du contenu

Il n'y a pas de CMS. Un article n'existe qu'après un commit, ce qui ressemble à une limite mais est un avantage : chaque article a un diff, un historique et un retour arrière, le sitemap obtient un vrai lastmod par page, et aucune base de données ne peut se corrompre en silence. La déduplication se fait contre les URL de sources de ce qui est déjà publié, il n'y a donc pas de table de statut séparée qui pourrait se désynchroniser de la réalité.

Le site lui-même est en Astro 7 sur Cloudflare Workers, avec tous les articles, rubriques et dossiers prérendus : aucune attente et aucun appel de base de données pour lire un article. D1 ne gère que ce qui est réellement un état, comme la liste de la newsletter, le compteur des articles les plus lus et les alertes. La recherche tourne sur Pagefind, sans service de recherche externe. L'image OG de chaque article est dessinée au postbuild avec la rubrique et le titre. Les polices sont auto-hébergées, la CSP est en mode strict, GA4 ne charge qu'après consentement et l'admin est derrière Cloudflare Access avec une vraie validation de jeton : si les clés ne correspondent plus, cette admin se ferme au lieu de s'ouvrir.

La couche d'analyse est l'apport propre

Une réponse d'IA ne cite pas un site qui dit la même chose que cinq autres. Le cœur de chaque article Kunstbrein n'est donc pas l'actualité mais sa lecture : trois à quatre profils concrets, comme une PME qui exploite un chatbot via un fournisseur externe ou un marketeur qui compare des abonnements IA sur le prix, avec à chaque fois la conséquence explicitée. C'est le texte qui n'existe nulle part ailleurs, et donc la seule partie pour laquelle une réponse d'IA doit renvoyer vers Kunstbrein.

Autour se trouve la transparence que les réponses d'IA récompensent. Chaque article montre ses sources avec l'éditeur, le titre, l'horodatage et le lien, sans nofollow, car une mention de source est l'inverse d'un lien payant. Chaque article indique lui-même qu'il a été composé avec l'assistance de l'IA, sous la responsabilité éditoriale de Frederiek Pascal. La charte éditoriale est une vraie page et constitue en même temps la cible de publishingPrinciples dans le graphe schema.org. Chaque article est un NewsArticle dont les citations sont construites à partir du champ de sources obligatoire : pas de source, pas d'article, imposé par le schéma. Par-dessus : une politique délibérée envers les crawlers IA, un llms.txt et un sitemap avec un vrai lastmod par page.

Ce que cela coûte

Un à trois dollars par mois de coûts de modèle. Ce chiffre bas ne vient pas d'un modèle bon marché mais de l'architecture : le modèle ne fait que la rédaction et la vérification des faits, tout le reste se passe dans le code. Tout passe par la Message Batches API à la moitié du prix des tokens, car personne n'attend la réponse à huit heures dix du matin. Le flux fonctionne par tours : d'abord tous les appels principaux en un seul lot, puis les portes dans le code, puis toutes les demandes de correction ensemble dans le lot suivant. Un lot qui n'est pas prêt après quarante-cinq minutes est annulé et l'exécution échoue proprement : pas d'article, pas de pull request, on recommence demain.

Ces coûts sont réellement mesurés, pas estimés : un script récupère la consommation et les coûts chez le fournisseur lui-même. Notre propre total tiré des logs ne comptait en effet que les articles publiés, alors qu'un article refusé coûte exactement autant de tokens. Pour le reste : Cloudflare Workers, D1 et le routage e-mail dans le plan existant, et Resend pour l'envoi. Pas de licence CMS, pas de service de recherche, pas de banque d'images.

Ce que nous ne prétendons pas

Une étude de cas qui ne montre que le beau côté est une brochure. Donc :

• Ce n'est pas "l'IA écrit, l'humain vérifie". Il n'y a pas de relecture finale avant publication. Les portes se trouvent avant le merge, et le contrôle qualité a posteriori se fait dans l'admin, où un article peut être archivé ou un retour peut déclencher une réécriture. C'est un choix assumé.
• Aucune promesse de trafic ni de classement. La mesure n'a démarré qu'au lancement. Le point de contrôle est à trois et six mois : Kunstbrein apparaît-il dans les réponses d'IA aux questions du public cible, et du trafic arrive-t-il vers nos propres pages IA. Sinon, cela s'arrête, avec une archive qui reste en ligne.
• Les articles les plus anciens sont du matériel de démarrage issu de la phase précédant la mise en service du pipeline, et ils sont plus courts. Nous séparons donc toujours les chiffres de longueur moyenne à cette date, sinon vous mesurez deux choses à la fois.

Outils utilisés