# Un agent IA régénère les pages statiques après chaque webhook

> Cas d'une architecture où un agent orchestre la reconstruction sélective de pages statiques plutôt qu'un rebuild complet à chaque publication WordPress.

- Auteur : Clément Hadrot
- Publié le : 2026-02-27
- Mis à jour le : 2026-02-27
- Catégorie : Headless & API
- URL : https://wpmoderne.dev.wordpress-developpement.fr/headless/agent-ia-regenere-pages-statiques-webhook/

## L’essentiel

- Rebuild complet devenu trop coûteux au-delà de 40 000 pages
- Agent chargé d'identifier les pages réellement impactées par un changement
- Reconstruction sélective réduisant le temps de build de façon marquée

{ "event": "post.updated", "post_id": 48213, "affected_taxonomies": ["categorie", "praticien"] }. Ce message JSON, reçu par un serveur d'orchestration à chaque webhook de publication WordPress, est devenu le point de départ d'une refonte complète de la stratégie de reconstruction statique d'un site catalogue dépassant les 40 000 pages générées. Le problème initial était simple à formuler : un rebuild complet du site, déclenché à chaque publication ou modification d'article, prenait 38 minutes, un délai devenu incompatible avec un rythme de publication de plusieurs dizaines de modifications par jour.

## Le problème du rebuild complet à grande échelle

Sur un site de quelques centaines de pages, reconstruire l'intégralité du site à chaque publication reste anodin. Passé plusieurs dizaines de milliers de pages, ce choix devient structurellement intenable : non seulement le temps de build s'allonge, mais le nombre de webhooks quotidiens dépasse largement le nombre de rebuilds que la plateforme d'hébergement peut raisonnablement enchaîner sans provoquer de file d'attente de déploiements en retard.

## L'architecture retenue : un agent qui identifie l'impact réel d'un changement

Plutôt que de reconstruire tout le site ou de se contenter d'une revalidation ISR classique (jugée insuffisante ici en raison de dépendances complexes entre pages, notamment les pages de taxonomie qui agrègent plusieurs dizaines d'articles), l'équipe a mis en place un agent chargé d'analyser chaque webhook de publication pour en déduire précisément quelles pages statiques doivent être régénérées, au-delà de la seule page modifiée.

```
Webhook WordPress (post.updated)
  └── Agent d'analyse d'impact
       ├── Page de l'article modifié ─── toujours régénérée
       ├── Pages de taxonomie associées ─── régénérées si le tri ou le compte change
       ├── Page d'accueil ─── régénérée seulement si l'article est mis en avant
       └── Pages liées (articles similaires) ─── régénérées si le contenu source est référencé
```

> L'essentiel à retenir : Rebuild complet devenu trop coûteux au-delà de 40 000 pages ; Agent chargé d'identifier les pages réellement impactées par un changement ; Reconstruction sélective réduisant le temps de build de façon marquée

## Comment l'agent détermine la liste des pages à reconstruire

L'agent reçoit le webhook, interroge l'API WPGraphQL pour récupérer les taxonomies et relations associées à l'article modifié, puis applique une série de règles de décision pour déterminer la liste exacte des chemins statiques à reconstruire. Cette liste est ensuite transmise à l'API de reconstruction sélective de la plateforme d'hébergement, qui ne régénère que les pages concernées, sans toucher au reste du site :

```
const impactedPaths = await agent.analyzeImpact(webhookPayload);
// exemple de résultat : ['/praticiens/dr-martin', '/annuaire/cardiologie', '/']

await fetch('https://api.plateforme.exemple/v1/rebuild', {
  method: 'POST',
  headers: { Authorization: `Bearer ${process.env.DEPLOY_TOKEN}` },
  body: JSON.stringify({ paths: impactedPaths }),
});
```

## Le résultat mesuré après trois mois

Le temps de reconstruction moyen est passé de 38 minutes (rebuild complet) à environ 90 secondes pour une reconstruction sélective typique, portant sur une dizaine de pages en moyenne. Le nombre de rebuilds complets restants, désormais réservés aux changements structurels (modification de thème global, changement de navigation générale), est tombé à moins d'un par semaine, contre plusieurs dizaines auparavant.

- Reconstruction sélective déclenchée à chaque webhook de publication.
- Rebuild complet conservé uniquement pour les changements structurels globaux.
- File d'attente de secours si l'agent ne parvient pas à déterminer l'impact avec certitude, déclenchant alors un rebuild complet par prudence.

## Le garde-fou indispensable : le doute profite au rebuild complet

L'agent n'est pas infaillible : dans certains cas, une relation entre contenus n'est pas correctement détectée, ou une règle de décision ne couvre pas un cas de figure rare. Plutôt que de risquer une page obsolète non régénérée silencieusement, l'agent a été conçu pour déclencher un rebuild complet par défaut chaque fois que son niveau de confiance sur la liste des pages impactées descend sous un seuil défini, quitte à perdre le bénéfice de rapidité dans ces cas limites.

> Un agent qui optimise un processus critique doit toujours pouvoir se rabattre sur l'option la plus sûre en cas de doute, même si cette option coûte plus cher : le gain de rapidité ne vaut rien s'il s'accompagne d'un risque de contenu obsolète non détecté.

## En résumé

Confier à un agent l'analyse d'impact d'un changement de contenu a permis de réduire drastiquement le temps de reconstruction d'un site statique volumineux, sans sacrifier la fraîcheur du contenu affiché. La question de la sécurisation des permissions accordées à cet agent, notamment sa capacité à déclencher des déploiements en production, reste un sujet distinct qui mérite sa propre analyse.