Agent IA d'autoréparation de site web : réparer ce qu'il peut vérifier

Ce que fait la boucle du site web autoréparateur

Un site web ne se répare lui-même que là où l'agent peut prouver la correction, et nous avons construit tout le mécanisme autour de cette limite. Notre agent IA d'autoréparation balaie le site en ligne chaque semaine, ouvre un bug pour chaque défaut et envoie chaque bug vers sa propre exécution dans un environnement isolé. Cette exécution réécrit ce qu'elle peut via l'API du CMS, revérifie la page enregistrée et ne ferme le bug que si la vérification est propre. ConvOps fait tourner la planification, la file de bugs et les deux workflows. C'est l'une des boucles sur lesquelles tourne notre entreprise.

Un site web autoréparateur est un site où un agent détecte les défauts visibles par les lecteurs et répare ceux qu'il peut vérifier, en mettant le reste de côté pour une personne. Ce n'est pas une suite de tests autoréparatrice : celles-ci réparent les sélecteurs des tests, alors que cette boucle répare le contenu que voit un lecteur.

Chaque écran et chaque chiffre ci-dessous utilisent des données d'exemple de Shutterlane, un site fictif de tests de matériel photo tenu par deux personnes, à l'adresse shutterlane.example.com.

Un balayage hebdomadaire détecte les défauts, chaque bug a sa propre exécution de réparation, et le registre transforme les récidives en contrôles à l'écriture.

Le balayage (repère 1) consigne les constats (2), les compare au registre de prévention (3) et répartit les bugs ouverts (4). Chaque bug est réparé selon sa voie (5), vérifié (6), puis fermé ou mis en attente (7).

Pourquoi nous l'avons construite : un agent IA qui corrige les bugs de contenu d'un site

Un agent de QA qui se contente de signaler produit du bruit. Un agent qui détecte et corrige dans la même exécution corrige sa propre copie. Nous avons séparé les deux.

Notre balayage ne faisait au départ que signaler. Il retrouvait chaque semaine les mêmes liens cassés et les mêmes pages périmées, et personne ne se chargeait de la correction. Le graphique montre ce schéma sur les données de Shutterlane : un bug est ouvert (repère 1), reçoit une note de récurrence chaque mardi (2) et n'est jamais réparé (3).

Un balayage qui ne fait que signaler retrouve le même défaut chaque semaine, et sans étape de réparation, la pile de notes de récurrence ne fait que grossir.

Trois principes en sont ressortis :

1. Détecter et corriger sont deux tâches distinctes. Le balayage n'écrit jamais de contenu, et la réparation ne juge jamais le site.
2. Un défaut, une unité de travail. Chaque nouveau constat devient son propre bug, et chaque exécution de réparation prend en charge exactement un bug.
3. Terminé veut dire vérifié. Un bug n'est fermé qu'après une revérification de la page enregistrée, jamais sur la parole de l'agent.

Si vos rapports de QA s'empilent de la même façon, découvrez comment ConvOps transforme les constats en bugs que des exécuteurs prennent en charge un par un(s’ouvre dans un nouvel onglet).

Comment elle tourne : pool, exécuteur, environnement, workflow

Le modèle est la partie la moins intéressante. Le pool décide de ce qui est traité, l'environnement de ce que l'agent peut toucher, le workflow du moment où c'est terminé. Deux workflows portent le travail : le workflow de balayage, WF-qa, et le workflow de réparation, WF-bugfix. C'est un graphe d'étapes et de contrôles, la forme que nous décrivons dans Qu'est-ce que le graph engineering ?, la même boucle contrôlée et planifiée que nos expériences SEO avec Claude Code, et la réponse à la prolifération d'agents.

Un pool décide de ce qui est traité, l'exécuteur le fait tourner, l'environnement limite ce qu'il peut toucher, et le workflow décide du moment où c'est terminé.

Les constats deviennent des bugs dans un pool

Un pool est une requête enregistrée dans ConvOps : un filtre sur le type de tâche, les tags, le projet, l'horizon et le statut, plus un tri. Il ne contient jamais de tâches ; il se résout en tâches correspondantes au moment où on l'interroge, de sorte que les bugs de n'importe quel projet arrivent dans chaque pool qui leur correspond. pools_next renvoie la tâche placée en tête, départage les égalités par identifiant de tâche et enregistre une ligne de prélèvement par appel : chaque prélèvement est donc auditable.

Le pool open-qa-bugs de Shutterlane est type = bug AND tags contains qa-finding AND status in [backlog, todo], du plus ancien au plus récent (repère 1).

Les exécuteurs prennent le travail en charge

Un exécuteur est un exécutant nommé, éventuellement rattaché au pool dans lequel il puise (repère 2). Il en existe exactement deux sortes :

Notre boucle tourne sur un exécuteur Claude Code isolé, désigné dans la planification. L'étape de répartition du balayage exécute elle-même la requête au format du pool et envoie chaque bug à cet exécuteur ; rattacher l'exécuteur à un pool déplace ce même prélèvement dans ConvOps. Une exécution bloquée est arrêtée au bout de time_limit_s (par exécuteur, de 60 à 86 400 secondes, sinon le réglage de l'espace de travail : 14 400 ici).

Les environnements isolés limitent ce que l'agent peut toucher

Un environnement isolé est la définition écrite de tout ce qu'une exécution peut toucher. Chaque exécution est un Job Kubernetes, créé en pause ; un Secret propre à l'exécution, rattaché au Job, est ajouté avant son démarrage. Un volume de tâche conserve le dossier de travail de la tâche d'une exécution à l'autre. Le Job est supprimé 300 secondes après sa fin et le Secret disparaît avec lui : les identifiants ne survivent jamais à l'exécution.

Tout ce que l'agent peut toucher est déclaré avant son exécution, et l'identifiant est une référence, jamais une valeur.

• Dépôts. Un seul reçoit le travail et il est toujours poussé (repère 1) : directement sur la ref extraite, rejoué une fois, jamais en force.
• Règles d'outils. Le serveur du CMS refuse tout par défaut et autorise 8 outils (repère 2). Le navigateur n'autorise que des outils de lecture : navigation, instantané, capture d'écran et trois autres.
• Des références, pas des valeurs. CMS_API_TOKEN pointe vers une entrée du gestionnaire de secrets (repère 3), et l'identifiant de l'exécuteur est lui aussi une référence enregistrée (repère 4). Le repère 5 est le rattachement au pool.
• Droits ConvOps. Les écritures de tâches n'atteignent que la tâche de l'exécution. Les notes et les lectures atteignent n'importe quelle tâche, si bien que le balayage peut annoter les bugs, mais seule une exécution de réparation ferme son propre bug.
• Limites de répartition. run_dispatch_limit vaut 10 par exécution, ce qui borne le coût et le rayon d'impact d'un balayage. run_dispatch_named_environment vaut false : une exécution ne peut pas élargir le bac à sable de ce qu'elle répartit.

Deux workflows : l'un détecte, l'autre corrige

L'auditeur lit les pages comme un lecteur les reçoit : certaines rendues dans un navigateur, les autres en HTML brut, avec les compteurs et la fraîcheur recoupés avec la base de données. La promesse de fraîcheur est de 7 jours pour les modèles d'appareils photo et de 14 pour les entrées du répertoire, la cadence de leurs boucles de vérification.

Le balayage déroule six étapes chaque mardi à 5 h UTC, détecte et consigne, et n'écrit jamais de contenu.

La réparation déroule cinq étapes sur un seul bug, n'utilise que la voie de ce bug, et ne le ferme qu'après une revérification.

La planification (repère 1) est FREQ=WEEKLY;BYDAY=TU;BYHOUR=5;BYMINUTE=0. Le rythme hebdomadaire correspond à la promesse de fraîcheur de 7 jours : un constat est encore d'actualité quand sa réparation s'exécute.

Une exécution, étape par étape : un bug, du constat à la correction vérifiée

Le plus intéressant dans une réparation, c'est la vérification après l'écriture, pas l'écriture. Voici le balayage qa/2026-09-15 de Shutterlane, de la planification au verdict.

Mardi 5 h UTC : le balayage détecte et consigne

Le balayage tourne sur isolated-sonnet dans un seul Job avec shutterlane-qa. L'auditeur lit 24 pages (6 dans le navigateur, 18 en HTML brut) et renvoie 7 constats, un par règle.

L'auditeur renvoie un constat sous la forme page, règle et détail, et une nouvelle paire page et règle devient un bug intitulé règle : page.

Ce constat est nouveau : il devient le bug demo0101, absolute-self-link: /blog/best-travel-cameras-2026, statut todo. L'exécution consigne qa-dedupe: 5 novel, 2 recurrences ; chaque récidive ajoute une note à son bug ouvert.

L'étape de prévention lit le registre. absolute-self-link est covered et l'article a 3 jours, soit dans la fenêtre de fuite de 7 jours : le balayage ouvre donc l'idée demo0110 comme prevention-proposal.

La répartition liste les bugs de QA ouverts, du plus ancien au plus récent : 7, sous la limite de 10. Chacun part vers isolated-sonnet sans environnement désigné, et reçoit donc l'environnement par défaut de son projet.

Un bug, une exécution

Chaque bug tourne dans son propre Job isolé avec son propre volume, et note sa voie avant de toucher quoi que ce soit.

demo0101 reçoit son propre Job, run-demoex01, et son propre volume. read-bug choisit la voie selon le type de page et la règle : un lien vers soi-même sur une page /blog/ relève de post. Il écrit bugfix-demo0101/2026-09-15 lane=post avant de toucher quoi que ce soit.

Une seule écriture protégée

L'unique écriture porte la version qu'elle a lue, si bien qu'un article modifié la refuse, et elle ne transmet jamais de statut.

heal-post lance post-lint, qui désigne la cible fautive et sa correction. Il effectue ensuite un seul remplacement ancré body_md_edits, protégé par l'expected_version qu'il a lue. Il ne transmet jamais status : une réparation ne peut donc jamais publier ni dépublier une page.

En cas de conflit de version, l'agent relit une fois et reconstruit ; un second refus se termine en not healed. Un lien mort sans adresse connue est retiré et son libellé conservé. Retirer un lien est sans risque ; deviner une cible ne l'est pas.

Réparé, ou mis en attente

Un bug n'est terminé qu'après un nouveau lint propre et la disparition de la cible fautive, tandis qu'un bug de la voie d'attente est bloqué pour une personne, contenu intact.

L'agent relit l'article enregistré et repasse le lint. Réparé signifie que la règle n'a plus aucun constat ET que la cible fautive a disparu du corps enregistré, car le lint peut manquer une cible que l'auditeur a vue. La note indique healed: https://shutterlane.example.com/models/orrin-k5 -> /models/orrin-k5, le journal d'exécution est committé, le bug est terminé, et le Job et le Secret disparaissent 300 secondes plus tard.

À droite, demo0104 (counter-sanity: /news) arrive dans hold. Il passe à blocked, « nécessite une correction produit ou opérateur », contenu intact.

À quoi ressemble la sortie : rapport, notes, registre

Lisez le balayage par statut, pas par nombre. Une récidive sur une règle couverte est un bug de votre garde-fou, pas de votre contenu.

Lisez le balayage par statut : les lignes nouvelles sont de nouveaux bugs, les récidives sont des notes, et une règle couverte qui revient signifie que le garde-fou a fui.

Deux signaux pilotent l'étape de prévention :

• Fuite : une règle couverte sur un article /news/ ou /blog/ publié depuis moins de 7 jours. Seul un article récent prouve que le garde-fou à l'écriture l'a laissé passer.
• Lacune : une règle partielle ou non couverte sur 2 pages ou plus dans une même exécution, ou qui est revenue. Une page, c'est un défaut ; deux pages ou une récidive, c'est un schéma.

Chaque règle reçoit une seule proposition ; une proposition ouverte reçoit une note, jamais une seconde idée.

Sur le rapport de Shutterlane, encoding-artifact est covered et pourtant revenu sur /directory : le garde-fou fuit par un ancien chemin de publication. Nous avons rencontré ce schéma, et il a produit un second garde-fou, post-lint à l'étape de publication, en plus des refus à l'écriture dans les outils du CMS. Chaque journal d'exécution arrive dans git, la trace que nous décrivons dans l'observabilité des agents IA.

Ce qui tourne mal : une règle, trois orthographes

La plupart de nos échecs venaient de la plomberie et des droits, pas du modèle. Le pire ressemblait à une boucle qui fonctionne.

Le dédoublonnage s'appuie sur (page, rule). Notre auditeur écrivait les noms de règles librement et, d'une exécution à l'autre, orthographiait un même contrôle de trois façons. Le dédoublonnage voyait trois règles et ouvrait trois bugs pour un seul défaut. Sur les données de Shutterlane : dead-link, broken-link et dead-internal-link sur /news/corvane-x2-firmware-3 sont devenus demo0081, demo0084 et demo0087.

Trois orthographes d'une même règle ont ouvert trois bugs ; un seul nom figé laisse un seul bug, avec une note de récurrence par exécution.

La règle qui en est sortie tient en une ligne dans la fiche de l'auditeur : « rule est exactement l'un de encoding-artifact, dead-link, absolute-self-link, counter-sanity, vocab-drift, freshness, reader-error ; jamais une variante. » Désormais, un lien correspond à un bug, avec une note de récurrence par exécution.

Construisez la vôtre : la version minimale

Commencez par la voie d'attente et les droits sur les outils. Décidez de ce que l'agent ne doit jamais toucher avant de le laisser toucher quoi que ce soit.

La boucle minimale : une planification hebdomadaire, un auditeur qui ne fait que signaler, un script de dédoublonnage, un pool de bugs et un exécutant en bac à sable qui répare et repasse le lint, ou met en attente pour une personne.

Gardez le script de lint hors réseau : le nôtre juge les liens d'après la table des routes et les listes d'entités, si bien que son verdict se reproduit à l'identique. La voie d'attente est le contrôle humain décrit dans Concevoir des systèmes d'IA avec humain dans la boucle. La table des voies, prête à copier :

lanes:
  post:       # rewrite through the CMS API, then re-lint
    rules: [absolute-self-link, dead-link, encoding-artifact]
    pages: ["/blog/<slug>", "/news/<slug>"]
  freshness:  # re-verify; healed when the general stamp moves
    rules: [freshness]
    pages: ["/models/<slug>", "/directory/<slug>"]
  reader:     # re-read; healed on HTTP 200 with the page's own content
    rules: [reader-error]
  hold:       # everything else: blocked, a person fixes it
    rules: ["*"]

L'environnement, prêt à copier :

environment: shutterlane-qa
repos:
  - repo: shutterlane/site-ops
    receives_work: true
    push_target: ref
mcp_servers:
  shutterlane-cms:
    default: deny
    allow: [post_get, post_list, post_update,
            translations_manage, model_get, tool_get,
            verification_log_manage, verdict_history]
  playwright:
    default: deny
    allow: [browser_navigate, browser_snapshot,
            browser_take_screenshot, browser_console_messages,
            browser_wait_for, browser_close]
convops_tools_any_task: [task_notes_add, task_notes_list, tasks_get]
run_dispatch_limit: 10
run_dispatch_named_environment: false
secrets:
  CMS_API_TOKEN: {kind: gcp-sm, ref: demo-project/cms-token}

Copiez la table des voies et la définition de l'environnement, puis planifiez votre balayage hebdomadaire dans ConvOps(s’ouvre dans un nouvel onglet). Vous voulez que cela tourne sur votre propre site ? Réservez une séance de découverte gratuite.