Le maillage interne, c'est le levier SEO le plus sous-exploité d'un blog — pas de budget, pas d'outil payant, juste des liens correctement posés entre des articles qui existent déjà. On a confié ce chantier entier à Claude Code sur les 23 articles du blog Reflex IA : l'audit, le plan de liens, la réécriture par lots, les liens externes vers les outils cités, et une vérification à chaque étape. Voici le déroulé complet, avec les difficultés qu'on ne montre jamais dans ce genre de récit.
Sommaire
- Le point de départ : un état des lieux, pas une correction
- Étape 1 — L'audit et l'artefact visuel
- Étape 2 — Le plan de maillage, cluster par cluster
- Étape 3 — La réécriture par lots, un cluster à la fois
- Étape 4 — Les liens vers les outils cités
- Étape 5 — Le check systématique après chaque lot
- Les difficultés qu'on ne montre jamais
- Bilan complet
Le point de départ : un état des lieux, pas une correction
La demande initiale à Claude Code n'était pas "corrige le maillage interne". C'était : "regarde ce qu'on a fait sur Reflex IA". Un état des lieux, sans objectif précis. C'est cette étape qui a fait toute la différence — parce qu'un audit ouvert révèle des problèmes qu'une commande fermée n'aurait jamais fait remonter.
Sur les 23 articles publiés depuis avril, l'audit a montré que 3 seulement renvoyaient vers un autre article du site. Treize pour cent. Les 20 autres étaient publiés, indexés, mais isolés du reste du contenu — sans qu'on l'ait décidé, simplement parce que chaque article avait été écrit sans regarder les précédents.
Étape 1 — L'audit et l'artefact visuel
Plutôt que de livrer une liste de fichiers dans le terminal, Claude Code a construit un artefact HTML interactif : tableau de bord avec les statistiques globales, liste des articles maillés et non maillés, opportunités de clusters par thématique détectée automatiquement (Clay, automatisations Make/Zapier/n8n, assistants IA). Ce document a servi de base de décision pour prioriser le chantier — commencer par le cluster le plus dense (4 articles sur Clay, déjà proches thématiquement) plutôt que de traiter les 23 articles dans le désordre.
Cet artefact a été mis à jour à chaque phase du chantier — pas figé une fois pour toutes. Après le cluster Clay, après l'unification de format, après chaque nouveau cluster traité, le même document a été republié avec les chiffres à jour, la timeline des commits, et le statut de chaque cluster.
Étape 2 — Le plan de maillage, cluster par cluster
Une fois l'audit fait, l'étape suivante n'a pas été d'ajouter des liens au hasard. Claude Code a identifié 5 regroupements thématiques cohérents parmi les 23 articles :
Les 5 clusters identifiés
- 1Clay & prospection B2B — 4 articles publiés le même mois, jamais reliés entre eux malgré un sujet quasi identique.
- 2Automatisations Make/Zapier/n8n — 7 articles, du tutoriel Gmail au pipeline LinkedIn, tous isolés les uns des autres.
- 3Assistants IA (ChatGPT/Claude/Gemini) — 4 articles comparatifs qui répondaient en réalité aux mêmes questions sous des angles différents.
- 4Productivité — 2 articles (prompts IA, second cerveau) réunis a posteriori en mini-cluster réciproque.
- 5Comparatifs outils — 2 articles (landing page, newsletter) qui se citaient déjà à moitié sans réciprocité.
Pour chaque cluster, le plan précisait qui lie qui, avec quel texte d'ancrage, et dans quelle section de l'article. Sur les petits clusters (4 articles), un mesh complet — chaque article lie les 3 autres. Sur le cluster à 7 articles, un modèle plus dense mais pas systématique : 2 à 3 liens sortants par article, choisis pour leur pertinence réelle plutôt que pour atteindre un quota.
Étape 3 — La réécriture par lots, un cluster à la fois
En posant les premiers liens sur le cluster Clay, un problème est apparu : les liens ajoutés étaient invisibles à l'écran. Une règle CSS globale du site (a { color: inherit; text-decoration: none; }) faisait hériter tous les liens de la couleur du texte environnant. En creusant pourquoi ce genre de bug avait pu passer inaperçu, Claude Code a découvert que le blog tournait sur 4 formats de mise en page différents — dont un qui stockait le contenu de 4 articles comme des blocs HTML bruts de 30 000 à 68 000 caractères chacun.
La décision a été de ne pas patcher au cas par cas, mais d'unifier les 23 articles vers un seul format avant de continuer le maillage. Concrètement : réécrire 10 articles répartis en lots par similarité de format, chaque lot confié à un agent IA distinct tournant en parallèle, avec une spécification précise du format cible et un exemple déjà fonctionnel à imiter.
| Lot | Articles traités | Difficulté principale |
|---|---|---|
| Format html-native → rich | 4 articles (blocs HTML bruts) | Extraire le contenu utile d'un blob de 30 000 à 68 000 caractères sans en perdre une donnée |
| Format visual → rich | 4 articles | Retirer un bloc de ~120 lignes de CSS inline sur l'un d'eux |
| Format editorial → rich | 2 articles (les tout premiers du blog) | Replier des champs de score/verdict non supportés par le nouveau format dans le contenu |
Une fois les 10 articles migrés, le chantier de maillage cluster par cluster a repris : Clay, puis Automatisations, puis Assistants IA, puis les deux derniers mini-clusters pour les articles encore isolés. À la fin de cette phase, 23 articles sur 23 avaient au moins un lien interne — contre 3 au départ.
Étape 4 — Les liens vers les outils cités
Le chantier aurait pu s'arrêter là. Une question annexe a émergé : est-ce que Clay, Make, ChatGPT, Notion et la trentaine d'autres outils cités dans les articles renvoient vers leur site officiel ? Réponse après audit : 129 mentions sans aucun lien. Recentré sur les outils qui sont le vrai sujet d'un article ou d'une section — pas les mentions de passage dans un tableau annexe — le périmètre est tombé à 90 mentions à corriger, réparties sur 22 des 23 articles.
Étape 5 — Le check systématique après chaque lot
Chaque phase — chaque cluster, chaque lot de migration, la passe finale sur les liens externes — a été suivie d'un build complet du site et d'une série de vérifications automatiques : liens internes qui pointent vers une page qui existe vraiment, balance des balises HTML, absence de header ou de barre de lecture dupliqués, absence de style inline résiduel. Rien n'a été considéré comme terminé sur la seule base d'un "ça a l'air bon" — chaque étape a été confirmée par un script avant de passer à la suivante.
C'est ce réflexe de vérification, plus que la génération de contenu elle-même, qui a permis de détecter deux bugs de header dupliqué et deux liens internes cassés vers d'anciens slugs — des problèmes qui n'avaient rien à voir avec la demande initiale, mais qui seraient restés invisibles sans cette discipline de contrôle.
Les difficultés qu'on ne montre jamais
🚩 3 obstacles réels rencontrés pendant le chantier
Le CSS qui rendait les liens invisibles était fonctionnel au clic — aucun outil de test automatique ne l'aurait signalé. Seule une vérification visuelle manuelle l'a révélé.
Pour la passe finale sur les liens externes, 5 agents lancés en parallèle par lot thématique ont tous atteint la même limite de session API au même moment — un seul avait fini un fichier complet avant l'arrêt. Le reste du travail a été terminé manuellement, avec un script suivant exactement la même règle que les agents.
Pendant le dernier build de contrôle, le disque du serveur s'est retrouvé plein à 100% — un problème totalement indépendant du chantier, causé par des sauvegardes d'autres projets. Impossible de builder tant que l'espace n'était pas libéré. Rien de technique dans le code du blog, tout dans la réalité d'un environnement de travail partagé.
Aucune de ces trois difficultés n'a fait échouer le chantier. Chacune a changé la méthode en cours de route : vérification visuelle systématique après le premier bug, script manuel après la panne des agents, pause de quelques minutes après le disque plein. C'est la différence entre un plan qui tient parce qu'il ne rencontre jamais d'obstacle, et un plan qui tient parce qu'il s'adapte à chaque obstacle réel.
Bilan complet
Un bilan qui ne parle que du temps passé et du coût en tokens raconte la moitié de l'histoire. Voici les deux faces.
Les résultats
| Indicateur | Avant | Après |
|---|---|---|
| Articles avec au moins 1 lien interne | 3 / 23 (13%) | 23 / 23 (100%) |
| Clusters thématiques structurés | 0 | 5 |
| Formats de mise en page actifs | 4 | 1 |
| Liens internes invisibles à l'écran | 13 articles touchés | 0 |
| Outils cités sans lien officiel | 129 mentions | 78 corrigées |
| Bugs de header/reading-bar dupliqués trouvés et corrigés | — | 2 |
| Liens internes cassés trouvés et corrigés | — | 2 |
Le temps
Les horodatages des commits Git donnent une lecture honnête, sans arrondi favorable. Le cœur du chantier — audit Clay, fix CSS, fix header dupliqué, migration des 10 articles vers le format unique, trois clusters de maillage, rattachement des derniers isolés — tient dans une fenêtre continue d'environ 1 heure 14 minutes, de 01h11 à 02h25. La dernière étape, les liens externes, a été poussée plus de 10 heures plus tard, après une interruption qui inclut le temps de réponse indisponible sur les agents (limite de session réinitialisée à heure fixe) et le blocage disque plein — pas du temps de traitement actif, mais du temps d'attente réel qu'un bilan honnête ne doit pas effacer.
Le coût
Les 6 agents IA qui ont mené la migration de format en parallèle ont consommé, cumulé, environ 924 000 tokens pour 150 actions (lectures, écritures, vérifications) et un temps de traitement cumulé d'environ 49 minutes — répartis sur des agents qui tournaient simultanément, donc largement absorbés dans la fenêtre d'1h14 ci-dessus plutôt qu'ajoutés bout à bout. Les 5 agents de la dernière phase n'ont pas de données de coût exploitables : ils se sont arrêtés sur erreur avant de reporter leur consommation, et le travail restant a été terminé par un script déterministe plutôt que par des agents supplémentaires — un coût en tokens proche de zéro pour cette portion, mais un coût en temps de résolution du problème qui, lui, ne se mesure pas en tokens.