# Aperçus de portée des purges CDN pour agents d'IA

Un agent d'IA ne devrait jamais demander l'autorisation de « vider le cache du CDN ». Cette phrase masque les seules informations dont un opérateur a besoin avant d'autoriser l'action : quel hôte, quel chemin, combien de tags et quelle quantité de contenu mis en cache risque de ne plus être servie.

Un bon aperçu de la portée d'une purge CDN transforme la requête finale en une description compacte du rayon d'impact. Il doit aussi placer une invalidation ciblée dans une catégorie de risque différente d'une purge totale. J'ai vu des purges trop larges transformer une mise en production ordinaire en incident de trafic sur l'origine, parce que la fenêtre d'approbation présentait un caractère générique comme un chemin anodin. La requête était courte sur le plan syntaxique. Son effet ne l'était pas.

Une bonne conception ne se limite pas à ajouter une boîte de confirmation. Elle normalise la requête du fournisseur, classe sa portée, estime son effet avec une incertitude honnête et lie l'approbation de l'opérateur à ces paramètres précis. Si l'agent modifie un hôte, un chemin, un tag, un environnement ou un mode de purge après l'approbation, la passerelle doit redemander une autorisation.

## Une requête de purge a besoin d'un modèle d'impact

La portée d'une purge CDN correspond à l'ensemble des représentations mises en cache que le fournisseur peut invalider, et non au nombre de chaînes dans une requête API. Un seul caractère générique peut couvrir une distribution. Un tag peut désigner des milliers d'URL sans rapport entre elles. Une URL peut avoir plusieurs variantes en cache, car le cache varie selon les paramètres de requête, les en-têtes, les cookies, le type d'appareil ou la langue.

C'est la première distinction que les équipes confondent souvent : la taille de la requête n'est pas la taille de son effet. La documentation d'Amazon CloudFront expose clairement ce décalage. Un chemin d'invalidation générique compte pour un seul chemin envoyé, même s'il invalide des milliers de fichiers. L'unité de facturation décrit la requête, pas sa portée. Une carte d'approbation qui indique « 1 chemin » sans préciser qu'il s'agit de `/*` donne une information techniquement exacte, mais inutile pour l'exploitation.

Modélisez l'action proposée selon quatre axes :

- **Cible :** le compte, le service ou la distribution CDN, l'environnement et le nom d'hôte.
- **Sélecteur :** URL exacte, préfixe de chemin, caractère générique, tag de cache, clé de substitution ou indicateur de purge totale du fournisseur.
- **Sémantique :** la façon dont les sélecteurs se combinent, les variantes qu'ils couvrent et si le fournisseur invalide ou supprime les objets en cache.
- **Conséquence :** le nombre estimé d'objets ou de requêtes touchés, le comportement attendu du remplissage et la possibilité de continuer à servir du contenu périmé.

Ce modèle doit vivre dans la passerelle d'exécution, près des identifiants et de l'adaptateur du fournisseur. Ne laissez pas l'agent attribuer lui-même une étiquette de risque. L'agent peut proposer une purge, mais le code qui comprend l'API du fournisseur doit calculer ce que cette proposition signifie.

Cette séparation compte, car le vocabulaire varie d'un fournisseur à l'autre. Fastly appelle son étiquette de regroupement une surrogate key. Google Cloud et Akamai parlent de tags de cache. Cloudflare accepte les tags, noms d'hôte, préfixes d'URL, fichiers individuels et purges totales. CloudFront accepte les chemins, caractères génériques et invalidations par tags de cache. Un outil portable destiné aux agents peut offrir une interface simple, mais l'aperçu doit conserver les vraies règles de correspondance du fournisseur.

Avant d'afficher quoi que ce soit, le composant d'exécution doit résoudre les alias, normaliser les hôtes, décoder et normaliser les chemins selon les règles du fournisseur, développer les options pratiques et identifier l'environnement effectif. L'aperçu décrit ensuite la requête qui sera signée et envoyée. Afficher l'entrée initiale et plus lisible de l'agent crée un écart où la normalisation peut élargir la portée sans que l'humain le voie.

## L'invalidation ciblée et la purge totale sont deux actions

Une invalidation ciblée sélectionne du contenu par une URL exacte, un chemin ou préfixe borné, un ou plusieurs tags, ou une intersection de sélecteurs pris en charge. Une purge totale élimine l'état utile de tout un service, d'une zone ou d'une distribution. Les traiter comme deux valeurs d'une même liste déroulante minimise leur différence.

La classification doit suivre l'effet, pas le nom du point d'accès. Toutes ces requêtes méritent l'étiquette de purge totale :

- L'indicateur explicite `purge_everything` d'un fournisseur.
- Un chemin de distribution `/*`.
- Un caractère générique ou un préfixe qui se normalise vers la racine.
- Un tag qui, selon une convention locale connue, marque toutes les réponses d'un service.
- Une liste de sélecteurs dont l'union couvre l'ensemble des hôtes configurés.

Les deux derniers cas exigent des métadonnées locales. Un fournisseur peut ignorer que `release-current` figure sur chaque objet d'un service, mais le système de déploiement qui applique ce tag peut le consigner. Si la passerelle ne peut pas prouver qu'un sélecteur est borné, elle doit indiquer une portée inconnue et relever le niveau d'approbation. « Inconnu » est un résultat valable. Le traiter discrètement comme une petite portée ne l'est pas.

« Ciblé » ne veut pas dire « sans danger ». Un préfixe `/products/` sur une grande boutique peut couvrir la majorité du trafic, et un tag `tenant:42` peut traverser plusieurs hôtes. Cette étiquette signifie que la requête exprime une limite que l'aperçu peut montrer. L'opérateur a encore besoin d'une estimation de ce qui se trouve à l'intérieur.

La purge totale a besoin d'un flux visuellement et mécaniquement distinct. Exigez un nom d'action explicite comme `purge_all`, et non un sélecteur vide que l'adaptateur interprète comme tout le contenu. Refusez les champs d'hôte et de chemin vides en mode ciblé. Demandez à l'opérateur d'approuver l'environnement de production et le service entier en tant que cibles nommées. Une approbation générale de session ne doit pas absorber cette action au seul motif que le même agent a effectué plus tôt une purge d'URL sans danger.

Je m'oppose ici à une recommandation répandue : « Il suffit de demander une confirmation pour chaque purge. » La répétition apprend aux personnes à approuver la forme d'une fenêtre, pas à lire son contenu. L'invalidation d'un seul fichier pendant une publication et la purge d'une distribution entière ne doivent pas présenter le même bouton, le même avertissement ni la même étape d'authentification. L'approbation humaine n'aide que si l'interface rend la différence matérielle évidente.

## L'hôte, le chemin et le nombre de tags vont au-dessus du bouton

La carte d'approbation doit commencer par la cible et la portée effectives, car les opérateurs lisent sous pression. Placez d'abord le fournisseur et l'environnement de production, puis le nom d'hôte, le chemin normalisé, le nombre de tags, la portée estimée et la catégorie d'opération. Les détails secondaires peuvent se déplier plus bas, mais les faits qui modifient la décision doivent rester visibles sans clic.

Un aperçu indépendant du fournisseur peut prendre cette forme :

```json
{
  "operation": "targeted_invalidation",
  "provider": "example-cdn",
  "environment": "production",
  "hosts": ["assets.example.test"],
  "paths": ["/releases/2026-07-24/*"],
  "tag_count": 2,
  "tag_samples": ["release:842", "asset:bundle"],
  "selector_logic": "host AND path AND (tag OR tag)",
  "estimated_reach": {
    "objects": {"low": 1600, "high": 2300},
    "method": "tag-index snapshot",
    "observed_at": "2026-07-24T14:31:08Z"
  },
  "refill": "origin requests expected on subsequent misses"
}
```

Ces nombres sont donnés à titre d'exemple, et ne promettent pas qu'un CDN puisse compter chaque objet encore présent sur ses nœuds périphériques. La forme de la sortie importe : une plage, sa méthode et son heure d'observation. Si l'estimateur ne dispose d'aucune donnée défendable, renvoyez `"objects": "unknown"` et expliquez pourquoi.

Affichez tous les hôtes quand ils sont peu nombreux. Pour une longue liste, montrez le nombre et les premiers noms triés, avec une commande explicite permettant d'inspecter le reste. Ne résumez jamais une liste mêlant production et préproduction par « 12 hôtes ». La frontière entre environnements pèse davantage sur la décision que le nombre.

Les chemins exigent à la fois la valeur normalisée et la règle de correspondance. `/picture*` et `/picture/*` ne désignent pas le même sélecteur sur Google Cloud CDN : le premier correspond aussi à des chemins tels que `/pictures/dog.jpg` et `/picture1.jpg`, tandis que le second reste sous le répertoire. CloudFront exige que le caractère générique soit à la fin pour agir comme tel ; un astérisque placé ailleurs est littéral. Un aperçu qui n'affiche que les caractères bruts oblige l'opérateur à se souvenir de la grammaire du fournisseur au pire moment.

Le nombre de tags demande aussi une formulation précise. « 2 tags » désigne deux sélecteurs, pas deux objets en cache. Affichez les tags réels sauf s'ils contiennent des informations sensibles sur un locataire ; dans ce cas, présentez des libellés masqués stables et une vue détaillée sécurisée. Indiquez si les tags se combinent avec OR ou AND. Google Cloud CDN traite plusieurs tags d'une même requête avec OR, tandis que leur combinaison avec des filtres d'hôte et de chemin réduit le résultat par intersection. Cette petite ligne logique explique souvent l'essentiel du rayon d'impact.

## La portée estimée doit reconnaître ce que le CDN ne compte pas

Une estimation de portée doit répondre à la question « quelle quantité d'état de cache risque de changer ? » sans prétendre qu'un cache distribué est une base d'inventaire. Les objets périphériques apparaissent et disparaissent au gré de l'expiration, de l'éviction, de la demande régionale et du remplissage en arrière-plan. De nombreuses API de purge CDN acceptent un sélecteur, mais ne renvoient aucun décompte préalable.

Utilisez les meilleures preuves disponibles dans un ordre fixe. Un décompte récent fourni par le fournisseur est la meilleure source quand l'API en propose un. Vient ensuite un index de tags tenu par le système de déploiement et recensant les URL qui ont reçu chaque tag. Utilisez ensuite les journaux de requêtes ou la télémétrie d'état du cache sur une fenêtre indiquée. Un catalogue des routes configurées peut fournir une limite supérieure grossière. Si aucune de ces sources n'existe, indiquez que la valeur est inconnue.

Chaque estimation doit comporter quatre propriétés :

- Une unité, par exemple des objets en cache, des variantes d'URL ou des requêtes récentes servies par le cache.
- Une estimation ponctuelle ou une plage, jamais un entier sans libellé.
- Une source et une heure d'observation.
- Un niveau de confiance calculé par le code à partir du type et de l'ancienneté de la source.

Ne convertissez pas le volume récent de requêtes en nombre d'objets. « Environ 80 000 requêtes servies par le cache au cours de la dernière heure correspondaient à ce préfixe » apporte une information utile sur l'impact, mais ne signifie pas que 80 000 objets seront invalidés. Affichez les deux mesures quand elles existent : le nombre estimé d'objets décrit l'état du cache ; les succès récents décrivent la pression probable du remplissage et l'exposition des utilisateurs.

Même pour une URL exacte, la portée peut dépasser un. La documentation de CloudFront indique que l'invalidation d'un fichier invalide aussi les variantes mises en cache selon les cookies ou en-têtes transmis. Le comportement des paramètres de requête dépend de la configuration et du sélecteur. L'aperçu doit dire « 1 URL, toutes les variantes de cookies et d'en-têtes » quand c'est le comportement effectif. Un simple nombre d'objets égal à un cacherait l'élément important.

Pour les tags, estimez l'union, pas la somme. Si `release:842` couvre 1 700 objets et `asset:bundle` en couvre 900, les objets qui se chevauchent ne comptent qu'une fois. Lorsque le fournisseur applique les tags avec OR, additionner les deux décomptes peut surestimer la portée. Une surestimation est plus sûre qu'une sous-estimation pour un seuil d'approbation, mais elle érode tout de même la confiance. Calculez une véritable union si l'index local le permet, ou présentez le total comme une limite supérieure.

Pour une purge totale, ne perdez pas de temps à fabriquer un nombre précis. Écrivez « service de production entier », affichez le nombre d'hôtes configurés et ajoutez le volume récent de réponses du cache comme indicateur de pression sur l'origine. La catégorie de l'action indique déjà la frontière du cache. Une fausse précision donne à la carte un air informé sans aider la décision.

## L'aperçu doit exposer les conséquences du remplissage

Une purge change la destination des requêtes suivantes. L'approbation doit donc décrire le comportement du remplissage autant que le sélecteur. Le risque opérationnel ne vient souvent pas de la disparition du contenu périmé. Il vient d'une vague concentrée d'échecs de cache qui frappe une origine dimensionnée en supposant que le cache absorberait ces requêtes.

La documentation de Google Cloud recommande de n'invalider que le nécessaire, car une invalidation trop large peut renvoyer vers les instances ou les buckets des requêtes jusque-là servies par les caches. Elle demande aussi de confirmer que l'origine renvoie déjà le bon contenu avant de lancer l'invalidation, faute de quoi le CDN pourrait remettre en cache la mauvaise réponse. Ce second point mérite de devenir une condition préalable du flux de l'agent : vérifiez le nouvel objet sur l'origine avant de proposer la purge.

Fastly établit une autre distinction utile entre purge dure et purge douce. Une purge dure rend le contenu du cache inutilisable pour les recherches suivantes. Une purge douce le marque comme périmé, ce qui peut autoriser sa diffusion pendant la revalidation du cache, selon la configuration. Fastly ne permet pas de purge douce pour une purge totale. Une approbation qui dit seulement « purger » efface cette différence opérationnelle.

L'aperçu doit donc préciser :

- Si l'action est une invalidation dure, une invalidation douce ou une suppression propre au fournisseur.
- Si le contenu périmé peut être servi pendant l'actualisation.
- Le débit récent de requêtes servies par le cache dans la portée sélectionnée, s'il est disponible.
- L'origine ou le groupe de backends qui recevra les échecs de cache.
- Si une vérification de préparation de l'origine a réussi et quand elle a été exécutée.

Évitez les promesses comme « 2 300 requêtes atteindront l'origine ». La fusion des requêtes, leur répartition régionale, les caches des navigateurs, le shielding et les remplissages frais modifient la charge réelle. Utilisez le trafic récent mesuré et décrivez-le honnêtement : « La portée sélectionnée a servi 46 000 requêtes depuis le cache au cours des 15 dernières minutes. » Cela renseigne bien davantage l'opérateur qu'une prédiction inventée.

L'agent ne doit pas lancer lui-même son contrôle de préparation dans un shell sans restriction, puis en résumer le résultat. La passerelle doit effectuer un contrôle défini contre l'origine visée, enregistrer le statut de la réponse et la version du contenu, puis joindre cette preuve à l'aperçu. Sinon, une instruction compromise peut affirmer que l'origine est prête au cours de la même conversation qui demande l'autorisation.

## La normalisation ferme l'écart entre affichage et exécution

La passerelle doit approuver une action canonique, puis exécuter cette même action. Si l'interface affiche une représentation alors que l'adaptateur du fournisseur en envoie une autre, l'approbation n'est qu'une mise en scène.

La canonicalisation commence par des champs typés. Séparez `hosts`, `paths`, `tags`, `purge_all`, `soft`, `provider`, `service_id` et `environment`. N'acceptez pas une commande curl libre comme objet à approuver. L'adaptateur peut finir par produire du HTTP, mais le code de décision et d'affichage doit travailler sur des données validées.

Appliquez ensuite les règles du fournisseur avant la classification. Mettez les noms d'hôte en minuscules, retirez le point DNS final, refusez les identifiants intégrés, résolvez l'alias de service et analysez les chemins sans considérer un fragment comme une partie de la requête. Préservez la casse du chemin quand le CDN la distingue. Appliquez la même normalisation d'URL et la même connaissance des réécritures que le fournisseur. Cloudflare avertit que les purges par préfixe associées à des Transform Rules doivent employer l'URL d'origine après transformation. CloudFront conseille d'invalider à la fois l'URI demandé par l'utilisateur et l'URI réécrit lorsqu'une fonction modifie le chemin. L'aperçu doit montrer les deux chemins effectifs au lieu d'ajouter silencieusement le second.

Après normalisation, une courte fonction de classification peut faire respecter les cas dangereux :

```text
if purge_all is true:
    return PURGE_ALL
if any normalized path covers the root:
    return PURGE_ALL
if any tag is cataloged as service_wide:
    return PURGE_ALL
if selectors are empty:
    return REJECT
return TARGETED
```

Les adaptateurs de fournisseurs ont besoin de tests construits à partir de leur propre grammaire. Incluez les chemins racine, séparateurs encodés, barres répétées, barres finales, positions de caractères génériques, tableaux vides, hôtes mélangés, paramètres de requête et URL réécrites. Des tests de propriétés peuvent vérifier que la normalisation ne rend jamais la portée d'exécution plus large que la portée affichée. Les jeux de régression doivent conserver l'aperçu normalisé à côté de la requête sortante exacte.

Enfin, calculez une empreinte de l'action canonique et des métadonnées déterminantes de l'aperçu. Le dossier d'approbation doit comprendre l'acteur, le processus de l'agent, le nom de l'outil, les paramètres normalisés, l'environnement, l'heure de l'estimation, l'empreinte et l'expiration. L'AI Agent Security Cheat Sheet d'OWASP recommande de lier l'approbation à l'action exacte, avec l'acteur, l'outil, la cible, les paramètres normalisés, l'heure et l'expiration. C'est la bonne norme. Une décision humaine portant sur une empreinte ne peut pas autoriser une requête ultérieure avec un autre chemin.

## L'approbation doit se fermer si la portée dérive

Tout changement substantiel après l'aperçu doit invalider l'approbation. Les champs concernés comprennent le fournisseur, le compte, le service, l'environnement, l'hôte, le chemin, la logique des sélecteurs, les tags, le mode de purge et la classification ciblée ou totale. Une modification de l'estimation seule n'exige pas forcément une nouvelle demande, mais le franchissement d'un seuil d'impact configuré doit toujours en déclencher une.

Donnez une courte durée de vie à l'approbation, car l'état du cache et le trafic évoluent. Si un agent attend le déploiement suivant, le chemin peut désormais contenir d'autres objets et la preuve de préparation de l'origine peut être périmée. L'expiration doit imposer la régénération de l'aperçu, pas seulement un nouveau clic sur d'anciennes données.

La spécification des outils du Model Context Protocol indique que les applications devraient toujours permettre à un humain de refuser les appels d'outils et présenter des demandes de confirmation. C'est raisonnable, mais une confirmation générique est trop faible pour des appels destructeurs sur l'infrastructure. L'application hôte peut connaître le nom de l'outil et ses paramètres JSON ; seul l'adaptateur d'exécution sait qu'un alias du fournisseur désigne la production, ou que `/` suivi d'un caractère générique signifie tout le contenu. Placez l'aperçu utile dans le composant capable d'interpréter et d'imposer ces faits.

L'approbation doit aussi rester indépendante du texte contrôlé par l'agent. Celui-ci peut fournir un motif, comme « retirer l'image du produit rappelé », mais affichez-le dans une zone secondaire clairement marquée comme explication de l'agent. Générez les faits de portée à partir de code fiable et de la configuration du fournisseur. N'autorisez ni Markdown, ni séquences d'échappement de terminal, ni HTML arbitraire dans les champs de la carte.

Les actions à fort impact méritent davantage de friction. Une purge ciblée d'une URL exacte peut demander un clic. Un préfixe large peut exiger une confirmation délibérée qui répète la portée. Une purge totale doit demander une authentification séparée et ne pas hériter de l'approbation de la session de l'agent. Sallyport peut garder l'identifiant hors de portée de l'agent, afficher une approbation pour chaque utilisation d'une clé d'API CDN protégée et consigner l'appel HTTP obtenu ; l'adaptateur du fournisseur doit toujours fournir les champs de portée normalisés qui rendent cette approbation utile.

Les échecs doivent fermer la porte. Si l'estimateur dépasse son délai, affichez « inconnu », pas zéro. Si la normalisation échoue, refusez la requête au lieu de transmettre l'entrée brute. Si la journalisation d'audit échoue, n'exécutez rien. Si l'empreinte diffère au moment de l'envoi, abandonnez l'approbation et produisez un nouvel aperçu.

## Les journaux d'audit ont besoin de la décision et du résultat

La piste d'audit d'une purge doit conserver ce que l'humain a vu, ce que la passerelle a envoyé et ce que le CDN a renvoyé. Consigner uniquement la demande d'outil de l'agent ne prouve pas que la normalisation, l'approbation et l'exécution visaient la même portée.

Enregistrez la requête canonique, les champs affichés dans l'aperçu, la source de l'estimation, l'empreinte d'approbation, l'identité de la personne ayant approuvé, l'heure d'approbation, l'heure d'exécution, l'identifiant de requête du fournisseur et sa réponse. Indiquez si le fournisseur a accepté, terminé, partiellement terminé ou refusé l'opération. S'il expose un statut ultérieur, ajoutez des observations de statut au lieu de réécrire l'événement d'origine.

Conservez l'estimation séparément du résultat. Une estimation de 2 000 objets reste une estimation, même si le fournisseur renvoie un succès. La plupart des réponses positives signifient que le fournisseur a accepté un sélecteur, et non qu'il a trouvé exactement ce nombre d'objets en cache. Les auditeurs doivent pouvoir distinguer les affirmations issues d'une inférence locale de celles qui viennent du CDN.

La documentation de CloudFront précise qu'une invalidation ne peut pas être annulée après son envoi, car les points périphériques commencent rapidement à la traiter. Le dossier préalable à l'exécution devient donc particulièrement important. Un bouton de révocation peut bloquer un futur appel de l'agent, mais il ne peut pas retirer une purge déjà distribuée aux nœuds périphériques. L'interface d'audit ne doit pas laisser croire le contraire.

Lors d'une enquête, il faut pouvoir répondre à ces questions sans lire la transcription d'une conversation :

- Quel processus d'agent signé a proposé l'action ?
- Quelle personne a approuvé quelle empreinte canonique ?
- La carte classait-elle l'action comme ciblée ou comme purge totale ?
- Quels hôtes, chemins et tags figuraient sur la carte ?
- Que savait l'estimateur de portée à cet instant ?

La justification conversationnelle de l'agent fournit du contexte, mais elle ne fait pas autorité. Une conversation peut être tronquée, résumée ou influencée par du contenu non fiable. Le journal d'exécution constitue le dossier durable de l'action.

La résistance à la falsification compte lorsqu'un processus autonome peut appeler l'infrastructure de façon répétée. Sallyport enregistre les sessions d'agents et les appels individuels à partir d'un seul journal d'audit chiffré et chaîné par hachage, ce qui permet à une équipe de vérifier la chaîne indépendamment de la lecture de son contenu. Cela ne rend pas une mauvaise purge réversible, mais donne aux intervenants une séquence défendable de proposition, d'approbation et d'exécution.

## Un échec détaillé montre l'utilité des quatre champs

Imaginons un agent qui prépare la publication d'une boutique. La tâche demande d'actualiser les nouvelles ressources de produits après le déploiement. L'agent voit `/products/` dans le manifeste de construction et choisit une purge par préfixe, plus simple que l'énumération de fichiers hachés.

La requête brute contient un chemin. Une mauvaise fenêtre affiche « Purger 1 chemin ? » et l'opérateur approuve. Le CDN interprète le préfixe sur tous les hôtes configurés, dont la boutique publique, un hôte régional et un hôte d'images. La route contient aussi des pages de produits, des miniatures, des fragments d'inventaire et des ressources d'anciennes versions. Les objets populaires disparaissent ensemble du cache, puis se remplissent depuis le même groupe d'origine.

Un aperçu utile modifie la décision avant l'exécution. Il affiche :

1. **Hôte :** trois hôtes de production, avec leurs noms visibles.
2. **Chemin :** `/products/*`, décrit comme un préfixe récursif et non comme un seul fichier.
3. **Tags :** aucun, alors que la version actuelle possède un tag dédié.
4. **Portée estimée :** 38 000 variantes d'URL et 1,2 million de requêtes récemment servies par le cache, avec la source et la fenêtre de chaque mesure.

L'opérateur refuse la requête. L'agent propose ensuite le tag de la version uniquement sur l'hôte des ressources. La passerelle trouve 1 840 objets indexés, précise que les deux valeurs de tag se combinent avec OR et montre que l'action exclut le HTML des produits et les réponses d'inventaire. Le contrôle de l'origine confirme l'identifiant de la version actuelle. L'opérateur approuve cette empreinte plus étroite.

Les nombres de ce scénario sont illustratifs ; ce schéma d'échec est fréquent parce que la syntaxe d'un préfixe paraît peu coûteuse. La solution n'est pas une meilleure instruction pour l'agent. La frontière d'exécution doit rendre les sélecteurs larges lisibles et offrir à l'humain une option plus étroite.

Le même schéma détecte une autre erreur : un agent demande à purger la préproduction, mais un alias de service se résout vers la production. Si l'aperçu indique seulement « service `storefront` », l'opérateur peut ne rien remarquer. S'il commence par « production » et énumère les hôtes publics, l'écart saute aux yeux.

Cet exemple explique aussi pourquoi le nombre de tags ne peut pas remplacer la portée. Un tag de version peut identifier 1 840 objets, tandis que vingt tags d'URL exactes peuvent n'en identifier que vingt. Affichez le nombre de sélecteurs et le nombre estimé de correspondances comme deux faits distincts. L'un décrit la requête. L'autre décrit son effet probable.

## Livrez la frontière de sécurité comme contrat exécutable

Les équipes doivent mettre en œuvre l'aperçu de purge comme un contrat entre l'outil de l'agent, l'adaptateur du fournisseur, l'interface d'approbation et le journal d'audit. Ce contrat est assez petit pour être testé : les entrées normalisées arrivent, un aperçu classé et lié à une empreinte en ressort, et l'exécution n'accepte qu'une approbation non expirée pour cette empreinte.

Au minimum, imposez ces invariants :

- Le mode ciblé possède au moins un sélecteur autre que la racine et un environnement explicite.
- Le mode de purge totale utilise sa propre action et ne peut pas résulter de champs vides.
- L'hôte, le chemin, le nombre de tags et la logique des sélecteurs affichés viennent des paramètres canoniques.
- La portée est une plage sourcée, une limite supérieure, une mesure de trafic ou une valeur explicitement inconnue.
- L'exécution recalcule l'empreinte et refuse les paramètres modifiés.

Exécutez l'adaptateur sur des cas enregistrés pour chaque opération CDN prise en charge. Comparez la requête sortante à l'instantané de l'aperçu. Ajoutez un service canari dont l'origine peut supporter une purge, puis testez l'URL exacte, le préfixe, l'union de tags, la restriction d'hôte, le chemin réécrit et la purge totale. Une simulation qui se contente de répéter l'entrée de l'agent ne prouve rien ; le test doit exercer la normalisation et la construction de la requête au fournisseur.

Conservez le contenu versionné comme voie normale de publication. La documentation de Google Cloud recommande des durées d'expiration adaptées ou des URL versionnées plutôt que des invalidations habituelles, et ce conseil est juste. Les purges servent aux corrections, aux rappels et aux cas où attendre le TTL est inacceptable. Un agent qui purge à chaque déploiement transforme un contrôle exceptionnel en dépendance cachée envers la capacité de l'origine.

Lorsqu'une purge est justifiée, l'aperçu doit permettre une approbation rapide. Un opérateur doit voir `assets.example.test`, `/releases/842/*`, deux tags et une estimation de 1 600 à 2 300 objets sans décoder le JSON du fournisseur. Pour une purge totale, le même emplacement de la carte doit dire « service de production entier » sans atténuer cette phrase par un petit nombre de requêtes.

Mon test est direct : un opérateur peut-il distinguer l'actualisation d'une seule ressource de la purge de tout un service en deux secondes, uniquement grâce aux champs fiables situés au-dessus du bouton d'approbation ? Si ce n'est pas le cas, l'agent n'est pas prêt à disposer de cette action CDN.