thin_content
Umbodi fait écrire par un modèle des paragraphes fondés sur la page, ne les publie dans une pull request que si la page atteint alors 250 mots, et vérifie que le défaut a disparu du site en ligne.
Non corrigé par Umbodi sur son propre site — impossible à y planter
Une page avec très peu de texte ne donne presque rien à comprendre ou à citer aux moteurs de recherche et de réponse ; elle se classe et se fait citer rarement.
Se déclenche quand la page compte moins de 250 mots. Gravité : avertissement.
L’agent écrit des paragraphes fondés sur ce que dit déjà la page, et refuse si le résultat restait sous 250 mots. Le texte est écrit par un modèle, il n’est donc jamais marqué mécanique : il doit franchir le seuil de score, et l’appel n’est payé que par l’enveloppe quotidienne du propriétaire pour l’écriture sans surveillance, désactivée par défaut.
Le changement arrive sur le site sous forme de pull request sur son dépôt, ouverte par l’application GitHub d’Umbodi, une page par pull request. Une page générée depuis une ligne de base de données — un article de blog, par exemple — est corrigée en écrivant cette ligne, relue avant d’être comptée.
La valeur est écrite, pas déduite : elle doit franchir seule le seuil de score de 55. Elle ne s’applique aussi que si le propriétaire a activé l’action sans surveillance et réglé la jauge d’autonomie de cette catégorie sur automatique ; la fusion demande un accord distinct.
Une proposition sur dix est mise de côté comme groupe témoin — choisie par un hachage fixe par projet, pas à la main — et n’est jamais appliquée sans surveillance, pour mesurer l’effet des corrections par rapport à celles non faites.
Après la fusion de la pull request et l’apparition du déploiement en production, l’agent lit la page en ligne et exécute la même règle d’audit qui a signalé le défaut. La correction ne compte que si la règle ne se déclenche plus. Si elle se déclenche encore, la page est relue jusqu’à cinq fois, environ deux heures et demie, puis l’agent annule sa propre fusion.
Il s’arrête, en disant pourquoi, quand le site n’a pas d’installation de l’application GitHub ni de dépôt choisi, quand la page n’est pas de celles qu’il peut écrire, quand une pull request est déjà ouverte pour la page, quand les vérifications requises échouent ou qu’une personne a touché la branche, ou quand aucun déploiement n’apparaît en six heures. Il ne fusionne jamais sur une vérification illisible et n’annule jamais sur une page inaccessible.
Notre site n’offre aucun endroit où planter ce défaut sans casser quelque chose de réel : il n’y a donc pas de reçu en ligne. La correction n’est prouvée que par la suite de tests. La raison, telle que le code l’énonce :
the thinnest page this site serves is 857 words and the finding fires under 250, so the plant is "delete the body of a live page" for up to 52 hours. Measured 2026-10-06 across all 12 root pages. A drill is a worse snippet, never a broken page.
Dernière vérification 2026-10-11 08:43 UTC
Seulement ce que prouve la suite de tests : le chemin du constat à la correction vérifiée fonctionne sur des cas d’essai. Rien sur cette page n’affirme que cela s’est produit en ligne.
Cela ne prouve aucun changement de classement ni de citation. Umbodi n’en déduit jamais d’une correction : le classement est mesuré à part, sur Google, et rapporté tel que mesuré. Un reçu montre aussi que le chemin fonctionne sur ce site, pas sur tous les sites.
Umbodi fait écrire par un modèle des paragraphes fondés sur la page, ne les publie dans une pull request que si la page atteint alors 250 mots, et vérifie que le défaut a disparu du site en ligne.
Pas en ligne. Notre site n’offre aucun endroit où le planter sans casser quelque chose de réel : la correction n’est prouvée que par la suite de tests, et cette page dit pourquoi.
La page des reçus liste chaque type de défaut que l’agent corrige seul, et ceux qu’il a déjà corrigés en ligne sur ce site.