Parsed : Un outil SEO qui écrit dans ta base de code

La plupart des outils SEO finissent avec un rapport. Parsed commence là.

Tu obtiens une liste de schema manquant, des gaps de mots-clés, des URLs non indexées. Ensuite tu fermes l’onglet et tu l’oublies. Le travail n’a pas eu lieu — on t’a juste dit quel était le travail.

J’ai construit Parsed pour sauter cette étape.

Le problème avec les outils SEO

Chaque outil d’audit que j’ai utilisé a la même forme : il scanne ton site, te montre ce qui ne va pas, et te laisse le corriger toi-même. Ça avait du sens quand le travail était manuel. Ça a moins de sens quand les agents existent.

Le gap n’est pas l’information. Je sais que j’ai besoin de schema JSON-LD sur mes pages produit. Je sais que j’ai des gaps de mots-clés dans mon blog. Je sais que la moitié de mon sitemap n’est pas encore indexée. Je sais ces choses depuis des mois. La contrainte c’est l’exécution — s’asseoir et faire chaque chose.

Parsed traite ça comme le vrai problème à résoudre.

Ce que fait Parsed

Parsed est un super-agent local qui tourne aux côtés de ton monorepo. Il se connecte directement à ta base de code, pas via une interface web qui te tend un snippet à copier.

Trois agents principaux :

Agent d’optimisation autonome — scanne tes pages, identifie les données structurées manquantes ou faibles, génère des composants de schema JSON-LD, et les écrit directement dans ton projet. Au prochain déploiement, le schema est en ligne. Pas de copier-coller.

Agent de publication — trouve les gaps de mots-clés dans ton contenu, génère des articles SEO, les fait passer par une vérification de score humain, et écrit des fichiers .md dans ton dossier de contenu. L’article existe sur le disque. Tu le révises, tu le commites, c’est fait.

Agent d’indexation rapide — récupère ton sitemap, soumet chaque URL à IndexNow. Google, Bing, et Yandex sont pingués immédiatement. Plus d’attente qu’un crawler découvre une page que tu as publiée il y a trois semaines.

Il y a aussi le tracking de citations — surveiller à quelle fréquence ton site est cité par les moteurs de recherche AI. De vraies appels API, pas des données mock.

La stack est Next.js 14, Zustand, OpenRouter qui route entre GPT-4o et Claude 3.5 Sonnet selon la tâche, et IndexNow pour la couche de soumission.

AEO : ce que la plupart des outils SEO ignorent

Google n’est plus le seul moteur de recherche qui compte.

ChatGPT, Perplexity, et Claude génèrent un trafic significatif — et ils citent des sources. Quand quelqu’un demande à Perplexity “quel est le meilleur outil pour X”, il fait remonter quelques sites avec des citations inline. Ces citations génèrent de vrais clics.

La logique d’optimisation est différente du SEO traditionnel. Google classe les pages basé sur les liens, l’autorité, les signaux techniques. Les moteurs AI citent basé sur la clarté du contenu, la richesse du schema, l’autorité thématique, et à quel point ton contenu répond directement à une question spécifique.

Parsed suit les deux. Le travail sur le schema nourrit Google. Le travail sur le contenu nourrit les citations AI. Ils se recoupent mais ne sont pas identiques, et les traiter pareil c’est laisser de la couverture sur la table.

J’ai commencé à penser à ça comme l’AEO — answer engine optimization. Ce n’est pas un rebranding du SEO, c’est une couche supplémentaire. Ton contenu doit se classer dans la recherche traditionnelle et être citable par l’AI. Ce sont des objectifs liés mais distincts.

La boucle humanizer

Voici la partie inconfortable.

Je génère des articles avec une AI, puis je les fais passer dans un détecteur AI, puis je réécris les sections flagguées jusqu’à ce que le score humain atteigne 87% ou plus, puis j’écris le fichier sur le disque.

Le paradoxe : utiliser l’AI pour écrire du contenu, puis utiliser l’AI pour vérifier si le contenu se lit comme s’il n’avait pas été écrit par une AI, puis utiliser l’AI pour corriger les parties qui donnent cette impression.

Ça marche. Les articles passent. Google n’a pas de détecteur fiable au niveau du contenu — il regarde les signaux comme les liens, l’autorité, le comportement des utilisateurs. Mais je préfère publier du contenu qui se lit comme s’il avait été écrit par un humain, que le détecteur compte ou non. C’est simplement une meilleure écriture.

La boucle humanizer fait partie du pipeline de l’agent de publication. Ce n’est pas optionnel. Chaque article qui sort de Parsed est passé par elle.

Limitation actuelle

Parsed tourne localement.

Il a un accès direct au filesystem parce qu’il a besoin d’écrire dans ton projet. C’est ce qui le rend utile et ce qui le rend difficile à productiser. Une version hébergée nécessiterait une intégration de dépôt — GitHub app, permissions d’écriture, workflow de PR. C’est un vrai produit, pas un side project.

Pour l’instant c’est un outil que je fais tourner sur mes propres sites. igindin.com est le cas de test principal. L’agent schema a écrit des données structurées pour chaque page importante. L’agent de publication a généré et commité plusieurs articles. L’agent d’indexation tourne chaque fois que je publie du nouveau contenu.

Le chemin vers le SaaS est une intégration GitHub qui crée une branche, écrit les fichiers, ouvre une PR pour révision. Tu obtiens l’exécution autonome sans donner à un outil tiers un accès direct en écriture sur main. C’est la bonne architecture. Je ne l’ai pas encore construite.

Ce qui vient

Court terme : une boucle de feedback plus serrée entre le tracking de citations et la génération de contenu. Si un article spécifique est cité par Perplexity, je veux savoir quelle section est tirée et écrire plus de contenu autour de ce cadrage.

Moyen terme : l’intégration GitHub. Parsed comme service qui tourne sur un calendrier, ouvre des PRs, et te laisse approuver le travail sans toucher un environnement local.

Long terme : je ne suis pas sûr. Les outils SEO sont un espace encombré. Mais “écrit dans ta base de code” est une catégorie différente de “te montre un rapport.” La valeur est dans le gap d’exécution, et ce gap est réel.

L’outil existe. Il tourne. Il a produit un output mesurable. C’est assez pour continuer à construire.