Une personne, trois langues, 300 URL : le système éditorial de y8y avec des agents d'IA

Une publication de niche compétitive exige, au minimum : rédaction documentée, vérification des affirmations, traduction pour chaque marché, SEO technique (balisage, hreflang, sitemaps), distribution aux moteurs et une carte de contenu qui évite les cannibalisations. Avec une équipe traditionnelle, cela fait quatre ou cinq personnes avant le premier lecteur. L'expérience y8y a été de demander : quelle part de tout cela peut devenir un système, en laissant à la seule personne disponible le travail qui exige vraiment du jugement ?

La réponse n'a pas été "utiliser un chatbot pour écrire". Elle a été de concevoir une chaîne éditoriale où chaque maillon (rechercher, rédiger, localiser, valider, lier, distribuer) a une définition de fait vérifiable, et où l'IA exécute à l'intérieur de cette définition.

La pièce centrale n'est pas un modèle d'IA : c'est la structure de données. Chaque entité (robot, histoire, comparatif, terme, réponse) est un fichier JSON aux champs trilingues, avec une requête de recherche qu'elle possède et une réponse extractible. Sur ce graphe, des agents d'IA font la recherche concurrentielle, rédigent des brouillons conformes à un playbook éditorial écrit, génèrent les trois versions linguistiques et proposent les liens internes. Un jeu de validations automatiques rejette toute entrée invalide : schéma de données, références cassées, requêtes dupliquées (le gardien anti-cannibalisation) et même des règles de style.

La distribution aussi est un système, pas une tâche : l'index de contenu est publié comme fichier lisible par machines, les nouveautés sont notifiées automatiquement aux moteurs après chaque déploiement, et les réponses complètes sont servies aux moteurs d'IA dans un fichier unique. La personne reste exactement où elle doit être : choisir les sujets, vérifier les faits aux sources primaires, signer les verdicts et décider ce qui ne se publie pas. La méthode éditoriale complète est publique dans la méthodologie.

Coûts directs : l'infrastructure mensuelle est nulle (site statique sur l'offre gratuite de son hébergeur) et la vraie dépense, ce sont les abonnements d'outils d'IA et les heures de la personne. C'est le schéma qui compte pour une équipe marketing : le coût dominant d'un système à agents n'est pas le logiciel, c'est la supervision, et c'est pourquoi tout le design vise une revue humaine rapide (validations automatiques avant, différences claires après).

Gouvernance en trois règles. Un : l'IA propose, la personne publie ; aucun contenu n'atteint le site sans revue humaine. Deux : toute affirmation factuelle porte sa source citée, et les chiffres qu'affirme seul un fabricant sont étiquetés comme tels. Trois : il existe des règles dures que les tests rendent impossibles à contourner, du schéma de données au style. Ce que ce cas n'affirme pas encore, par honnêteté : des revenus et un trafic consolidé ; la publication est jeune et ces chiffres seront ajoutés ici, datés, quand ils existeront. Le système qui les produira est ce qui est documenté aujourd'hui.

L'ordre compte plus que les outils : chaque étape crée la condition dont la suivante a besoin. Avec la dédication partielle d'une personne, le parcours complet se compte en semaines, pas en trimestres. La version prescriptive complète (diagnostic des fuites de budget, équipe reconstruite, outils avec pour et contre, économie des tokens et risques) se trouve dans le blueprint de l'opération de contenu.

La vraie décision d'un responsable n'est pas quel outil acheter mais quel modèle d'équipe opérer. Les trois fonctionnent ; ils diffèrent par l'endroit où ils placent le coût et le risque.

Un cas qui ne montre pas ses alternatives n'enseigne rien : toute architecture semble inévitable racontée à rebours. Le principe qui a ordonné tous les choix est celui-ci : de la technologie ennuyeuse et remplaçable là où il n'y a pas d'avantage compétitif, et du design propre seulement là où il y en a un. Dans ce système, l'avantage vit à deux endroits précis, la structure de données (le graphe d'entités avec sa carte de requêtes) et le playbook éditorial avec ses tests. Tout le reste a été choisi pour le coût, la robustesse ou la sortie facile, et chaque pièce a un substitut honnête : le générateur statique pourrait être Hugo ou Eleventy au lieu d'Astro ; le magasin de fichiers JSON pourrait migrer vers un CMS avec interface (Keystatic, Contentful) le jour où une équipe écrit ; les agents généralistes pourraient être n'importe quel LLM compétent opérant le même playbook.

Le tableau résume les six décisions structurelles avec l'alternative raisonnable écartée et le motif réel. Aucune n'est un dogme : dans un autre contexte (une grande équipe, un contenu à haut risque réglementaire, une marque sans données propres), plusieurs s'inversent, et la dernière colonne dit quand.

Trois échecs réels, documentés parce que chacun a réécrit une règle. Un : une histoire a été publiée avec une vidéo intégrée non vérifiée (l'identifiant venait d'un résultat de recherche et le lecteur avait un défaut de styles) ; un lecteur l'a trouvée en boîte noire sur mobile. Depuis, aucun contenu externe n'est intégré sans vérification technique préalable, et le lecteur est testé sur mobile avant publication. Deux : le premier brouillon de la première étude de données était trop court et l'un de ses chiffres clés, cent mille postes vacants attribués à un organisme public, n'a pas résisté à la vérification : la vraie source était une organisation patronale citée dans un communiqué. Détecté avant publication, l'étude a été réécrite autour de l'écart (devenu le résultat le plus intéressant) et la passe de vérification aux sources primaires a cessé d'être optionnelle.

Trois : la distribution automatique aux moteurs a échoué en silence pendant des jours. La cause n'était pas dans le code mais dans une configuration de domaine de l'hébergeur, et n'est apparue qu'en examinant le comportement réel depuis un environnement neutre. La règle qui en résulte : après chaque déploiement, le système vérifie le comportement vivant du site, pas la supposition que le déploiement a fonctionné. Aucun des trois échecs n'a été détecté par l'IA seule ; les trois ont été transformés en règles par une personne. C'est le compte honnête de l'opération avec des agents.

Cette section est une analyse de l'auteur, datée de juillet 2026, et sera révisée en public comme tout le reste. Le pari de fond : la recherche se scinde en deux économies, celle du clic et celle de la citation. Les moteurs qui répondent (résumés d'IA, assistants, agents) n'envoient pas de visites, ils citent des sources, et ils citent mieux ce qu'ils peuvent vérifier et extraire proprement. C'est pourquoi chaque pièce de ce système a une double sortie : la page pour les personnes et la surface pour les machines (réponses extractibles, données structurées, l'index de contenu, le fichier de réponses complet suivant la convention llms.txt). J'attends que ces surfaces se standardisent et deviennent aussi obligatoires que le sitemap ; qui les a en premier accumule des citations pendant que les autres discutent.

Deuxième attente : les lecteurs seront de plus en plus des agents agissant pour le compte de quelqu'un (comparer des fournisseurs, préparer un rapport, vérifier une affirmation). Un graphe d'entités aux données datées et sourcées est exactement ce qu'un agent peut consommer avec attribution ; un blog de prose continue, non. L'opportunité que je vois : les petits sites structurés comme celui-ci fonctionnent de facto comme des API de confiance pour ces agents, et cela ne dépend pas de la taille du domaine mais de la qualité et de la vérifiabilité de la donnée. C'est la première ère du SEO où le petit opérateur rigoureux a un avantage structurel sur la grande ferme de contenu.

Troisième : le coût de production du contenu continuera de tomber vers zéro, ce qui signifie que produire cesse d'être le métier. Toute la valeur se déplace vers ce que ce cas appelle le compte et la gouvernance : données propres, vérification, responsabilité nommée et l'historique publié des réussites et des échecs. Ce que j'ajouterai ensuite à ce système, dans cet ordre : la re-vérification programmée des affirmations datées (que le système alerte quand une donnée citée vieillit), des réponses par surface (la même entité répondant différemment à un moteur, un assistant vocal et un agent), et le même graphe opérant du contenu client. Quand cela arrivera, ce sera documenté ici avec ses chiffres.