Ce qu'il a fallu retirer à l'IA pour industrialiser des pages locales

Générer des centaines de pages « service + nom de ville » est un exercice que n’importe quel outil sait faire depuis longtemps. C’est aussi une architecture qui bascule vite dans ce que Google qualifie d’abus de pages satellites, lorsque les pages sont pour l’essentiel similaires et créées pour couvrir des requêtes géographiques plutôt que pour être réellement utiles. Le même raisonnement vaut pour la règle plus récente sur la production de contenu à grande échelle et à faible valeur, IA comprise. Ce n’est pas l’architecture qui est condamnée, c’est la bascule. Le problème n’est donc pas de produire du volume. Il est de produire du volume qu’on puisse défendre, une page à la fois, devant un moteur comme devant un client.

Ce dossier raconte le pilote qui a servi à répondre à cette question, chez Signature Couverture Aménagement, couvreur et paysagiste en Tarn-et-Garonne. Objectif de départ : douze prestations, vingt communes réellement desservies, donc 240 pages locales. Objectif réel, découvert en route : établir ce qu’on a le droit d’écrire, et surtout ce qu’on doit interdire à l’IA d’écrire.

Une précision d’emblée : Oramus Local et Oramus Data sont mes outils internes, pas des produits en vente. Ce dossier décrit une méthode de travail, pas une plateforme à laquelle vous pourriez souscrire.

Séparer qui mesure, qui décide, qui rédige

Tout repose sur une chaîne de responsabilités où chaque maillon ne peut pas empiéter sur le suivant.

la donnée mesure
le projet décide
l'IA rédige
les contrôles vérifient
l'humain approuve

En amont, une couche de données territoriales agrège des bases publiques et des mesures de demande, commune par commune. Elle est consommée en lecture seule. Aucun agent du site n’a le droit de retoucher un chiffre pour arranger une page : une anomalie se corrige à la source, jamais à l’arrivée.

Surtout, cette couche ne livre pas que des chiffres. Elle livre des chiffres accompagnés de leurs limites d’usage. Une distance entre deux centres communaux n’est pas une distance routière. Un logement daté n’est pas une toiture datée. Un volume de recherche n’est pas une taille de marché. Une donnée absente n’est pas un zéro. Ces précautions sont attachées à chaque variable publiable, et elles sont opposables au rédacteur.

Le point qui a le plus servi : mesurer une intention large ne donne aucun droit d’affirmer la demande d’un micro-service. Le volume de « couvreur » dans une commune ne dit rien du volume de « démoussage de toiture » dans cette commune. La donnée peut aider à décider du ciblage. Elle n’est jamais étirée pour justifier la page qu’on aurait aimé créer.

Et mesurer ne décide pas. Une commune peut être statistiquement intéressante sans être desservie. Elle peut être desservie sans qu’aucune donnée locale ne permette d’écrire quoi que ce soit sur elle. Ce second cas est parfaitement acceptable.

Le premier pipeline avait tout juste et ne servait à rien

La première version enchaînait simplement le contrat de page, la rédaction, puis les contrôles. Sur le papier, elle fonctionnait. Les contrôles passaient : schémas valides, affirmations rattachées à une source, pas d’hallucination détectée, métadonnées cohérentes.

La lecture humaine, elle, donnait autre chose. Des pages interchangeables. Des titres de section qui revenaient de page en page. Des questions fréquentes bâties sur trois moules. Beaucoup de texte expliquant comment préparer sa demande, et très peu expliquant le métier.

La formule qui a servi de diagnostic tient en une phrase. Le système avait appris à ne pas avoir tort. Il n’avait pas encore appris à être utile.

C’est le même angle mort que dans les dérives de coût dont je parlais ici : on sait très bien contrôler ce qui se vérifie mécaniquement, et l’utilité ne se laisse pas réduire à un verdict automatique.

La donnée locale ne fait pas le contenu d’une page locale

La cause était simple. Le rédacteur recevait des faits locaux, une configuration client, et beaucoup d’interdictions. Il ne recevait presque aucun savoir sur le métier lui-même. Face à ça, un modèle fait la chose la plus rationnelle possible : il se réfugie dans le texte générique, celui qui ne peut pas être pris en défaut.

La génération complète a donc été arrêtée avant de produire les 240 pages. Une couche a été ajoutée, qui n’existait pas : de la connaissance métier réelle, issue des entretiens avec l’artisan et de sources métier identifiées, puis structurée avec sa provenance et ses limites d’usage. Symptômes, causes possibles, méthodes d’intervention, matériaux, arbitrages, facteurs qui font varier un devis, limites d’intervention, règles propres à l’entreprise.

De là vient la règle la plus utile du pilote, et sans doute la plus contre-intuitive :

Zéro fait communal sur une page est acceptable. Zéro connaissance métier ne l’est pas.

La pertinence d’une page de couvreur dans une commune donnée vient d’abord de ce qu’elle explique utilement sur la couverture. Pas d’un chiffre local injecté pour faire local.

Reste le risque inverse : donner tout le corpus d’un métier au rédacteur produit mécaniquement des pages jumelles. La matière est donc découpée, et chaque page reçoit un sous-ensemble choisi par du code, selon un angle d’entrée qui varie. Deux pages d’élagage peuvent partir de la même vérité métier, l’une par les symptômes de l’arbre, l’autre par l’arbitrage entre tailler et abattre. La variation vient de la composition, jamais de faux faits locaux.

Une source citée n’est pas une source respectée

Deuxième surprise, plus fine. Les contrôles vérifiaient qu’une affirmation portait bien une référence à une source. Ils ne vérifiaient pas que la source disait effectivement ce qu’on lui faisait dire.

La revue manuelle a sorti plusieurs cas du même genre. Une affirmation correctement sourcée à laquelle on avait ajouté une conclusion absente de la source. Deux sources fusionnées sans le signaler. Une causalité plausible, jamais affirmée par personne. Un renvoi vers la mauvaise question de l’entretien.

Une étape de contrôle a donc été ajoutée, dédiée à la fidélité et non à la présence de la référence. Et une règle en est sortie : une provenance n’a de valeur que si elle soutient exactement ce qu’on lui attribue.

Cette découverte en a entraîné une autre, plus structurante. Il a fallu retirer au rédacteur le choix même des affirmations qu’il composait librement. Entre la connaissance source et la rédaction, le système construit désormais un contrat d’affirmations : ce que la page a le droit d’avancer, les conditions attachées à chaque affirmation, les facettes que le contenu doit obligatoirement couvrir, et le vocabulaire disponible. Le modèle garde toute liberté sur la rédaction. Il ne décide plus seul de l’étendue de ce qu’il peut affirmer.

Un effet de bord utile : les contrôles ne peuvent plus reprocher au rédacteur l’absence d’un élément que rien ne lui avait rendu obligatoire.

Le nom de la commune, ou pourquoi un meilleur prompt n’était pas la réponse

C’est le cas le plus instructif du projet.

Le rédacteur avait le droit de connaître la commune traitée, avec une consigne explicite : ne pas transformer une méthode générale de l’entreprise en affirmation locale. Malgré cette consigne, le modèle produisait régulièrement des tournures du type « À [commune], l’entreprise inspecte d’abord… ».

Le problème n’était pas la véracité. L’entreprise fait bien cela. Le problème est que la phrase transformait une pratique générale en engagement localisé, donc en affirmation invérifiable, répétée sur des dizaines de pages. Le défaut revenait sur plusieurs communes et plusieurs générations : pas un accident, un comportement.

La réponse n’a pas été d’écrire une meilleure consigne. Elle a été de retirer la commune au rédacteur. Le nom de commune n’est plus produit par l’IA du tout. Il est injecté par le code, uniquement dans les surfaces où il est mécaniquement exact : titre, méta-description, titre principal, formule de disponibilité. Et un contrôle bloque toute commune retrouvée dans le texte rédigé.

Une classe entière d’erreur passe ainsi de détectable à structurellement impossible. C’est la règle d’architecture la plus solide sortie du pilote :

L’IA ne doit jamais être propriétaire d’une valeur que le système sait dériver exactement depuis une source certaine.

Le même raisonnement a été appliqué à tout le reste. Identifiants, maillage interne, statuts, localisation, certaines métadonnées : tout ce qui pouvait être dérivé sans ambiguïté a progressivement été retiré au modèle. Le rédacteur écrit. Le code détient les invariants.

Refuser de simuler 240 réalités locales

C’est aussi ce qui sépare cette approche d’une automatisation SEO ordinaire.

Le système refuse de transformer une même prestation, déclinée sur trois communes, en trois réalités locales différentes. Il n’invente ni toiture typique de la commune, ni végétation particulière, ni relief, ni clientèle locale, ni chantier de référence.

Une page est localement pertinente lorsque l’entreprise dessert réellement la zone, que la prestation y est réellement proposée, que son ciblage reste cohérent avec la demande mesurée et la stratégie retenue, et que son contenu métier répond réellement au besoin. Quand un vrai fait communal ajoute quelque chose, il est utilisé. Sinon, l’absence vaut mieux qu’un décor.

Savoir s’arrêter

Trois disciplines de production ont fini par compter autant que la qualité du texte.

D’abord, un contrôle validé appartient à une version exacte du contenu, pas à la page en général. Si le texte change, le contrôle ne vaut plus. Cela paraît évident et ne l’est pas : c’est ce qui empêche un ancien feu vert de couvrir silencieusement un contenu qui a bougé depuis.

Ensuite, une régénération après échec est une nouvelle observation, jamais une réparation. On ne renvoie pas au modèle son propre échec avec une consigne corrective jusqu’à obtenir un feu vert. Un échec puis un succès, ce sont deux tirages, pas un problème résolu.

Enfin, un budget d’échec par prestation. Au-delà, la prestation est mise en quarantaine et la génération s’arrête, au lieu de continuer à l’aveugle. Là encore, c’est la même leçon que sur les coûts : un système qui n’a pas de plafond ne s’arrête jamais tout seul.

Et la frontière finale reste humaine. Un contrôle qui passe signifie qu’aucun contrat vérifié n’a été violé. Il ne signifie pas que la page mérite d’être publiée. Une partie de ce second jugement s’outille d’ailleurs très bien : densité métier, couverture des intentions, répétition des structures, similarité entre pages voisines. Mais l’autorité finale de publication reste volontairement humaine.

Ce que le pilote a vraiment produit

Au départ, il devait démontrer qu’on pouvait générer 240 pages locales. À l’arrivée, il a produit quelque chose de plus utile : une méthode pour décider quelles pages ont le droit d’exister, quelles informations elles peuvent utiliser, quelles affirmations elles peuvent porter, et comment les contrôler sans faire de l’IA une source de vérité.

Le site de Signature n’est d’ailleurs pas devenu le modèle qu’on recopie. L’audit de portabilité a montré que ce premier dépôt n’était générique qu’à un peu plus de 40 %. L’extraction du socle a donc été menée par étapes — identité client, prestations et zones, marque, pages et référencement, infrastructure de contact — puis validée sur un jeu d’essai neutre, construit sans aucune donnée Signature. Un projet client réussi et une plateforme réutilisable sont deux choses différentes, et confondre les deux coûte cher.

S’il ne fallait garder qu’une phrase : l’objectif n’est pas de produire le maximum de pages, mais d’industrialiser le maximum de pages qu’on peut réellement défendre.

Le raisonnement général sur ce qu’on délègue à une IA et ce qu’on lui reprend est développé sur la page automatisation IA. Si vous avez une activité dépendante d’une zone géographique et que la question du volume de pages se pose chez vous, on peut en parler.