Pourquoi nous construisons nos propres outils

Le problème qu’aucun outil ne réglait

Nous avons passé dix ans à payer des crawlers. De bons outils, pour la plupart. Trois choses nous ont fait basculer, et aucune n’était une question de fonctionnalité manquante.

La limite de pages. Les licences se comptent en URL. Sur nos propres sites de données, à plusieurs millions de pages, l’audit complet n’était simplement pas achetable. Nous en étions réduits à échantillonner, c’est-à-dire à ne pas voir précisément les zones où les problèmes se concentrent.

Les données des clients. La plupart des crawlers hébergés envoient le contenu audité sur les serveurs de l’éditeur. Pour un client sous NDA, ou dans un secteur réglementé, ce n’est pas un détail contractuel : c’est la différence entre pouvoir travailler et devoir refuser la mission. Nous avons refusé des missions pour cette raison.

L’analyse qui s’arrête là où elle devient intéressante. Presque tous les crawlers listent les problèmes page par page. Très peu calculent le graphe : quelle page concentre l’autorité, laquelle est à cinq clics de l’accueil alors qu’elle porte le chiffre d’affaires. Or c’est précisément à cette échelle que se prennent les décisions d’architecture.

Ce que nous avons construit

Deux outils, pour deux moments distincts du travail.

crawler4seo est notre crawler d’audit. Il tourne sur le poste, la base SQLite ne quitte jamais la machine, et les seules requêtes sortantes vont vers le site audité. Vingt analyseurs couvrent le SEO on-page et technique, la qualité et la duplication de contenu, les données structurées et l’internationalisation. Il calcule le graphe de liens internes — PageRank, hubs et autorités, profondeur de clic réelle par parcours en largeur — valide l’éligibilité aux résultats enrichis type par type, remonte les Core Web Vitals avec les données terrain CrUX, et vérifie l’accès de dix crawlers IA. Il est gratuit et sans limite de pages.

Colonel Search est notre outil de pilotage. Il se branche sur la Search Console, suit les positions et les concurrents, détecte les anomalies — une chute de clics sur un cluster, une page qui décroche — et produit les rapports clients. Les narratifs sont rédigés par un modèle à partir des données réelles, puis relus : le brouillon est automatique, l’analyse reste humaine.

Le premier répond à « qu’est-ce qui ne va pas sur ce site ». Le second à « qu’est-ce qui a changé cette semaine ». Ce sont deux questions différentes, et elles ne se posent pas au même moment.

MCP : la vraie raison de tout ça

Si nous ne devions garder qu’un argument, ce serait celui-là, et ce n’est pas celui que nous avions prévu en commençant.

Les deux outils exposent un serveur MCP (Model Context Protocol), le standard qui permet à un assistant IA de se brancher directement sur un outil : 29 outils pour crawler4seo, 28 pour Colonel Search — en lecture, et en écriture côté Colonel Search. Concrètement, nos agents n’attendent plus qu’un humain produise un export : ils interrogent le crawl et les données Search Console eux-mêmes.

« Quelles pages ont le PageRank le plus faible et pas de meta description ? » devient une question, plus un tableur à retravailler. C’est un changement de nature, pas de vitesse : entre un outil qui produit des fichiers et un outil qu’un agent peut interroger, ce n’est pas le même métier qui s’exerce derrière.

C’est aussi ce qui nous permet de suivre plus de sites sans grossir à proportion — et c’est la brique centrale de notre chaîne de production. Aucun crawler du marché ne proposait ça au moment où nous en avions besoin.

Ce que ça coûte vraiment

Autant être honnête, parce que le discours « construisez vos outils » est généralement tenu par des gens qui ne comptent pas.

Le coût n’est pas le développement, c’est la maintenance. Écrire un crawler qui marche prend quelques semaines. Le maintenir face aux changements de Google, aux nouveaux formats, aux cas tordus rencontrés chez un client précis, c’est un engagement permanent. La question à se poser n’est pas « sommes-nous capables de le faire », mais « accepterons-nous encore de le maintenir dans trois ans ».

Le support existe, même pour un outil gratuit. À partir du moment où il est public, des gens l’utilisent, trouvent des bugs, demandent des fonctionnalités. C’est une charge réelle, et elle est aussi la meilleure source d’amélioration que nous ayons.

Ce que ça rapporte est indirect. Ni licence, ni abonnement à vendre pour crawler4seo. Le retour vient d’ailleurs : des missions que nous pouvons accepter, un audit que personne d’autre ne rend, et un outil téléchargeable qui donne aux autres une raison concrète de nous citer. C’est exactement le mécanisme que nous décrivons dans l’article sur la marque — un outil public est une preuve, une page de service est une affirmation.

Ce que nous n’avons pas construit

La liste est bien plus longue que celle de ce que nous avons construit, et c’est elle qui rend la règle crédible.

Les index de liens. Constituer un index de backlinks suppose de crawler le web entier, en continu, et de le stocker. C’est une infrastructure à plusieurs millions d’euros par an. Nous payons des abonnements pour cette donnée, et nous continuerons.

Les volumes de recherche. Même raisonnement : la donnée vient de panels et d’accords auxquels nous n’aurons jamais accès. Un outil maison ne produirait qu’une estimation moins bonne, présentée avec plus d’assurance — c’est le pire des deux mondes.

Ce que Google donne déjà. La Search Console est gratuite, exacte sur son périmètre, et irremplaçable. Colonel Search ne la remplace pas, il l’exploite : suivre, croiser, détecter les écarts, restituer. C’est un projet radicalement plus petit que de recréer la source.

La distinction utile n’oppose donc pas l’outil maison à l’abonnement. Elle sépare la donnée, qu’on achète parce que la produire exige une infrastructure, et le traitement de cette donnée, qu’on peut construire dès lors qu’on sait précisément ce qu’on veut en tirer. Nous n’avons jamais construit une source. Nous avons construit ce qui vient après.

Quand il ne faut pas construire

La réponse honnête, dans la majorité des cas : ne construisez pas.

Construire se justifie quand les trois conditions sont réunies en même temps. Une contrainte que le marché ne lève pas — pour nous, la confidentialité des données clients et la limite de pages. Un usage quotidien, qui amortit la maintenance ; un outil utilisé trois fois par an ne la justifie jamais. Et une compétence interne réelle, pas un prestataire ponctuel : un outil dont personne chez vous ne sait lire le code est une dépendance, pas un actif.

Si une seule de ces conditions manque, un abonnement coûte moins cher que le temps que vous y passerez. Nous avons construit parce que les trois étaient réunies, et parce que nous avions dix ans de frustration précise à convertir en cahier des charges — ce qui est probablement la ressource la plus rare des trois.

Reste le vrai bénéfice, celui qu’on ne mesure pas : nous cassons nos outils sur nos propres sites avant de les utiliser chez des clients. Ce que nous appliquons chez vous, nous l’avons d’abord cassé puis réparé chez nous. C’est une garantie modeste, et c’est la seule qui vaille quelque chose.