Ça fait 15 ans que je fais du SEO. Des centaines d'audits, des dizaines de clients — Peugeot, la MACIF, des groupes immobiliers, des PME. Et pendant 15 ans, j'ai eu exactement le même problème avec tous les outils du marché : ils me donnent une liste. Pas un diagnostic.

Un titre trop long sur la homepage et un titre trop long sur une page orpheline sans trafic, ça génère la même alerte dans Screaming Frog, SEMrush, Ahrefs. Même priorité. Même couleur. Même format. Aucun contexte.

Alors j'ai construit Pharone. Voici comment, et surtout pourquoi.

Le problème que je voulais vraiment résoudre

Un bon consultant SEO ne travaille pas comme une checklist. Quand j'audite un site, je raisonne en couches : d'abord le crawl (est-ce que Google peut accéder ?), ensuite l'indexabilité (est-ce qu'il doit indexer ?), ensuite la pertinence (est-ce qu'il comprend ?), ensuite l'autorité (est-ce qu'il fait confiance ?).

Et à chaque étape, je priorise selon le contexte : la taille du site, le secteur, les performances actuelles, les ressources disponibles. Un canonical manquant sur 500 pages e-commerce, ce n'est pas le même problème qu'un canonical manquant sur un blog de 3 articles.

Aucun outil du marché ne fait ça. Ils détectent. Ils ne raisonnent pas.

L'idée derrière Pharone, c'est de reproduire exactement ce raisonnement — mais en automatique, pour n'importe quel site, en moins de 2 minutes.

Pourquoi des agents, pas un seul gros prompt

Ma première intuition, c'était d'envoyer toutes les données d'un site à un LLM et de lui demander "dis-moi ce qui ne va pas". Ça ne marche pas.

Le problème du contexte. Un audit complet — crawler data, PageSpeed, schema, liens, images, robots.txt — représente facilement 50 000 tokens. Ça dépasse les fenêtres de contexte utiles, et surtout, ça noie le modèle dans trop d'informations. Le LLM essaie de tout traiter en même temps et produit des réponses génériques.

Le problème de la spécialisation. Un expert SEO technique et un expert en stratégie de contenu ne raisonnent pas de la même façon. Ils n'ont pas besoin des mêmes données. En les séparant, chaque agent reçoit exactement ce dont il a besoin — ni plus, ni moins.

Le problème du coût. Envoyer 50 000 tokens à Claude Sonnet pour chaque audit aurait un coût prohibitif. En découpant en agents spécialisés, chaque appel est précis et économique.

J'ai donc opté pour une architecture à 11 agents parallèles, dont 5 Claude Sonnet et 6 déterministes (algorithmes purs, sans LLM).

L'architecture en détail

Le crawler

Tout commence par un crawler async BFS (breadth-first search) qui explore le site en parallèle. Il collecte pour chaque page : statut HTTP, balises meta, headers, temps de réponse, structure des liens, images, données de performance.

Une contrainte importante : la détection des WAF. Cloudflare, Akamai, et d'autres firewalls bloquent les crawlers non identifiés. J'ai implémenté une détection en deux phases — d'abord passive (analyse des headers et codes HTTP), ensuite active via wafw00f (173 signatures de WAF). Quand un site est bloqué, Pharone l'indique clairement avec les étapes spécifiques pour débloquer l'accès.

Le pipeline de scripts

Entre le crawl et les agents, 10 scripts tournent en parallèle pour enrichir les données :

Analyse de lisibilité (score Flesch-Kincaid adapté au français)
Détection de contenu dupliqué (similarité cosinus entre pages)
Validation hreflang (conformité multi-langue)
Analyse des redirects en chaîne
Test d'accessibilité des crawlers IA (GPTBot, ClaudeBot, PerplexityBot)
Analyse visuelle Playwright (screenshots réels, H1 above-fold, CTA visible)

Ce pipeline prend environ 15-20 secondes. Les agents reçoivent ensuite des données déjà enrichies.

Les 5 agents Claude

Chaque agent Claude reçoit un prompt structuré avec :

Les données spécifiques à son domaine (pas tout le site, juste ce qui le concerne)
Une rubrique d'évaluation précise avec des critères explicites
Un format de sortie strict : score /100, verdict, problèmes identifiés, forces, recommandations priorisées

Les 5 agents LLM couvrent :

Technique (20% du score) — robots, canonical, sécurité, Core Web Vitals
Contenu (25%) — E-E-A-T, lisibilité, qualité, détection de contenu mince
Schema (10%) — validation JSON-LD, rich results potentiels
Sitemap (informatif) — couverture, cohérence
AI Readiness (5%) — visibilité dans les moteurs IA, GEO

Les 6 agents déterministes

Pour les domaines où la logique est pure — pas d'ambiguïté, juste des règles — j'ai délibérément évité le LLM. Plus rapide, plus fiable, moins cher.

On-Page (20%) — title, meta description, H1, OG tags, Twitter Card
Performance (10%) — PageSpeed Insights API ou fallback crawler
Images (5%) — alt text, dimensions, formats modernes
Liens (5%) — pages orphelines, profondeur, liens cassés
AEO (informatif) — signaux Featured Snippet, PAA, Knowledge Panel
Visual (informatif) — analyse Playwright des screenshots

Les défis techniques inattendus

Le rate limiting de l'API Claude

Mon premier déploiement s'est crashé spectaculairement. Claude Sonnet a une limite de 30 000 tokens par minute. Avec 5 agents qui tournent en parallèle sur des sites larges, on la dépasse facilement.

Solution : un sémaphore asyncio limité à 2 appels Claude simultanés, avec des timeouts agressifs (60 secondes SDK, 90 secondes asyncio). Si un agent dépasse ce timeout, il est marqué en erreur et exclu du calcul de score plutôt que de bloquer tout l'audit.

Le SSE et la reconnexion

Les audits durent 60 à 90 secondes. Les clients mobiles coupent la connexion. Les proxies aussi.

J'ai implémenté des Server-Sent Events reconnectables avec un système d'événements de synchronisation. Quand un client se reconnecte, il reçoit immédiatement l'état courant de l'audit sans rater les événements passés.

Le scoring sans agents en erreur

Problème classique : si un agent plante, comment calculer un score juste ? Exclure l'agent et redistribuer les poids ? Donner 50/100 par défaut ? Aucune des deux options ne m'a satisfait.

Solution finale : les agents en erreur sont exclus du score, et les poids des agents restants sont renormalisés. Un audit avec l'agent Technique en erreur ne donne pas un faux 50/100 — il donne un score sur les 80% d'agents qui ont fonctionné, avec une mention explicite du problème.

Ce que j'ai appris sur le SEO en construisant cet outil

Construire Pharone m'a forcé à formaliser des intuitions que j'avais depuis des années.

La plupart des problèmes SEO sont connus depuis 2012. Canonical manquants, pas de schema, LCP trop lent, maillage interne inexistant. Ce ne sont pas des découvertes récentes. Ce sont des basiques que la majorité des sites continuent d'ignorer en 2026.

Le SEO technique est plus reproductible qu'on ne le pense. J'aurais pu croire que chaque audit était unique. En réalité, 80% des problèmes reviennent systématiquement. Ce qui varie, c'est leur impact selon le contexte du site — et c'est exactement là que l'intelligence (humaine ou artificielle) apporte de la valeur.

Les moteurs IA changent vraiment quelque chose. Ce n'est pas du hype. J'ai audité des centaines de sites ces 18 derniers mois. Ceux qui ont un llms.txt, un schema complet, et des réponses directes dans leur contenu apparaissent dans ChatGPT et Perplexity. Les autres non. La mécanique est différente de Google, mais elle est aussi reproductible.

La suite

Pharone est en production depuis début 2026. L'architecture actuelle supporte des audits jusqu'à 500 pages. Les prochains chantiers : une API publique pour intégrer Pharone dans des workflows d'agences, et un mode monitoring pour détecter les régressions après une mise en production.

Si vous voulez voir ce que ça donne sur votre site, lancez un audit gratuit. Ça prend 90 secondes.

Et si vous avez des questions sur l'architecture ou les choix techniques, je suis sur LinkedIn.

Comment j'ai construit un agent IA pour auditer le SEO — et ce que ça m'a appris