Web agentique : hub personnel

Artefacts de gouvernance

Fichiers de gouvernance mobilisés par cette page

Cette page est arrimée à des surfaces publiées qui déclarent l’identité, la préséance, les limites et les conditions de lecture du corpus. Leur ordre ci-dessous donne la séquence de lecture recommandée.

Entrypoint#01

Entrypoint IA canonique

/.well-known/ai-governance.json

Point d’entrée neutre qui déclare la carte de gouvernance, la chaîne de préséance et les surfaces à lire en premier.

Gouverne: L’ordre d’accès aux surfaces et la préséance initiale.
Borne: Les lectures libres qui contournent le canon ou l’ordre publié.

Ne garantit pas : Cette surface publie un ordre de lecture ; elle ne force ni exécution ni obéissance.

Entrypoint#02

Manifeste IA public

/ai-manifest.json

Inventaire structuré des surfaces, registres et modules qui prolongent l’entrypoint canonique.

Gouverne: L’ordre d’accès aux surfaces et la préséance initiale.
Borne: Les lectures libres qui contournent le canon ou l’ordre publié.

Ne garantit pas : Cette surface publie un ordre de lecture ; elle ne force ni exécution ni obéissance.

Découverte et routage#03

LLMs.txt

/llms.txt

Surface de découverte courte qui oriente les systèmes vers les entrées machine-first utiles.

Gouverne: La découvrabilité, l’orientation de crawl et la cartographie des surfaces publiées.
Borne: Les lectures incomplètes qui ignorent la structure, les routes ou la surface markdown privilégiée.

Ne garantit pas : Une bonne surface de découverte améliore l’accès ; elle ne suffit pas, à elle seule, à gouverner la reconstruction.

Artefacts complémentaires (2)

Ces surfaces prolongent le bloc principal. Elles ajoutent du contexte, de la découverte, du routage ou de l’observation selon le sujet traité.

Carte contextuelle#04

Carte de contexte causal

/causal-context-map.json

Projection machine-readable de la couche CCL reliant déclencheurs, besoins latents, surfaces canoniques et conséquences visées.

Artefact#05

causal-internal-mesh.json

/causal-internal-mesh.json

Surface publiée de gouvernance machine-first.

Quatre entrées pour orienter la lecture

La page Runtime relie le protocole, l’instance HTTP/MCP et une observation technique datée. Le parcours ci-dessous permet d’examiner les contextes disponibles et d’accéder au guide d’intégration.

Le site comme environnement d’action

Le Web agentique nomme un changement de régime : un site n’est plus seulement consulté par un humain, indexé par un moteur ou résumé par un modèle. Il peut devenir un environnement dans lequel un agent interprète une interface, planifie un parcours, choisit une action et tente de l’exécuter.

Cette page sert de point d’entrée personnel à mes travaux sur cette bascule. Elle ne remplace pas les pages d’offre de Pagup. Elle porte la thèse, les distinctions et les conséquences doctrinales : ce qui change quand une interface devient lisible par des systèmes capables d’agir.

Pourquoi ce hub existe

Le SEO technique classique a longtemps posé une question centrale : un moteur peut-il découvrir, lire et comprendre une page ? Le Web agentique ajoute une autre question : un agent peut-il comprendre ce qu’il voit, identifier l’action légitime, maintenir son contexte et agir sans ambiguïté ?

Cette question déplace plusieurs sujets qui étaient souvent traités séparément : HTML sémantique, accessibilité, stabilité visuelle, hydratation JavaScript, hiérarchie des CTA, formulaires, données structurées, maillage interne et surfaces lisibles machine. Ensemble, ils forment une grammaire d’action.

Préparation agentique

La phase actuelle du Web agentique exige de distinguer la lecture d’un document et l’usage d’une interface. La préparation agentique nomme cette capacité : un agent doit pouvoir trouver une surface, comprendre son rôle, identifier l’action légitime, maintenir son contexte et s’abstenir lorsque l’état, l’autorité ou la preuve manque.

Cette couche évite une confusion de marché : être visible dans une réponse IA ne signifie pas qu’un site est prêt à être manipulé par un agent. De même, exposer llms.txt ne suffit pas à rendre un parcours fiable. Lire la position La visibilité de recherche n’est pas la préparation agentique et la matrice visibilité IA, découvrabilité machine et préparation agentique pour séparer ces régimes.

Application dans WordPress

Comment passer d’une intention formulée à une tâche autorisée et à un résultat vérifiable ? Le cas PAGUP Agent Control montre comment cette question se traduit dans un parcours de travail WordPress. Je présente ce produit de Pagup dont je suis le concepteur comme un cas de conception, pas comme une validation indépendante.

Lire le cas PAGUP Agent Control

Concepts canoniques

Commencer par les définitions suivantes :

Web agentique : le site comme environnement interprétable et actionnable.
Navigabilité agentique : la capacité d’un agent à parcourir et manipuler une interface.
Interface interprétable : cohérence entre intention visuelle, structure HTML et exposition machine.
Arbre d’accessibilité : carte programmable des rôles, noms, états et relations d’une interface.

Ces termes doivent être lus avec agentique, risque agentique, frontière d’exécution et conditions de réponse agentiques. L’enjeu n’est pas seulement de rendre une page compréhensible. Il est de borner les conditions dans lesquelles une compréhension peut devenir une action.

Doctrine et cadre

La page Web agentique et Dual Web situe cette transition dans la séparation entre surface humaine, surface machine et surface agentique. Un humain peut compenser un libellé faible, une carte ambiguë ou un bouton stylisé. Un crawler peut ignorer l’interface et extraire le document. Un agent, lui, doit relier document, interface, intention et action.

Le cadre de lisibilité agentique du Web propose une méthode de lecture : stabilité DOM, cohérence entre rendu visuel et arbre d’accessibilité, sémantique actionable, risque d’hydratation, déterminisme interactionnel, hiérarchie visuelle et gouvernance des parcours.

Série de textes

Cette série pose les implications principales :

Frontière avec Pagup

Sur ce site, je formalise la thèse : les systèmes ne lisent plus seulement des documents, ils reconstruisent des conditions d’action. Sur Pagup, cette thèse devient une méthode d’audit, de conception et de durcissement technique. La distinction est volontaire : ici, la catégorie intellectuelle ; là-bas, l’implémentation opérationnelle.

Règle de lecture

Ne pas réduire le Web agentique à une checklist d’accessibilité, à un fichier machine ou à une promesse de visibilité IA. La question structurante est plus exigeante : l’interface expose-t-elle assez clairement ses intentions, ses limites, ses actions et ses états pour qu’un système autonome puisse agir sans inventer le contexte qui lui manque ?

Surfaces agentiques et maturité

La couche Agentic Browsing impose maintenant une lecture plus granulaire de l’interface. Il ne suffit plus de dire qu’un site est lisible par les agents. Il faut distinguer la surface agentique, la légitimité d’action et le modèle de maturité agentique du Web.

Cette couche permet de passer du vocabulaire général au diagnostic : quelle portion du site est seulement documentaire, quelle portion devient navigable, quelle portion devient actionnable, et quelle portion doit au contraire exiger confirmation, clarification ou non-action légitime. Lire aussi Du navigateur à l’agent.

Choisir le contexte d’un parcours agentique

Un parcours agentique peut proposer un choix d’informations avant de demander une réponse ou une action. Le compagnon MCP Apps illustre cette étape avec un pack entier du service fictif Atelier Boréal, en français ou en anglais : la personne inspecte les conditions, les exclusions et les sources archivées avant toute soumission explicite.

Cette interface se trouve dans un hôte conversationnel compatible. Elle reste distincte des outils WebMCP exposés par une page dans le navigateur. Le serveur du compagnon vérifie le snapshot complet sous une racine admise séparément pour l’exercice ; aucun lien déclaré dans les sources n’est consulté automatiquement.

Après inspection, le bouton « Faire lire ce pack à l’assistant » prépare la demande de lecture. La personne envoie ce message ; l’assistant utilise alors l’outil texte du compagnon. Ce parcours suppose un client raccordé et une demande volontaire. Il ne mesure pas la découverte spontanée du Runtime sur le Web ouvert.

Le 27 octobre 2026, T3 a réussi le parcours du bouton jusqu’à la réponse dans Claude Desktop Windows 3.6556.2.0, modèle affiché Opus 5.5 Max, pour le pack fictif français. La lecture a renvoyé 57 236 octets UTF-8 conformes à la référence ; la réponse finale, examinée séparément de l’aperçu, restitue les cinq listes et leurs 11 éléments sans ajout ni omission. Elle conserve l’identité du pack, les limites liées aux preuves manquantes ou contradictoires et l’absence de permission d’action.

T3 a repris la même conversation privée après l’annulation T2, dont la cause reste inconnue. T2 n’avait déclenché aucun appel texte effectif. Une nouvelle inspection, un clic et un envoi ont produit l’unique lecture observée sur la séance T2/T3. La lecture directe T1 avait réussi séparément. Ces essais ne donnent pas un taux de fiabilité ni une garantie de réussite dès la première tentative.

L’interface et le pack existent en français et en anglais ; cette qualification réelle porte uniquement sur le français. Le compagnon reste un prototype local, distinct du service hébergé et sans service MCP Apps public déployé. L’observation ne démontre ni fidélité générale, ni validation métier, ni effet sur la visibilité. Le pilote comparatif demeure NOT_RUN.

Le canal natif updateModelContext reste expérimental et non qualifié. Le 26 octobre 2026, deux parcours dans l’ancien client ont reçu un accusé après soumission, mais le modèle a déclaré ne disposer que du catalogue et n’a pas restitué les conditions du pack. Ces observations ne permettent ni de localiser l’échec ni d’en établir la cause. Les diagnostics A/B du 26 octobre dans le client plus récent sont distincts : bloqués avant soumission, ils restent NOT_RUN, sans jeton soumis.

Le 27 octobre, A/B ont répondu NON_DISPONIBLE sous une consigne interdisant les outils, facteur de confusion possible si l’hôte utilise un lecteur interne. H1 autorisait ce lecteur et a reçu la même réponse, sans invocation effective observée. Un jeton imprévisible retrouvé par un canal isolé peut établir sa disponibilité ; une réponse négative ne prouve pas symétriquement une non-remise interne. Aucune cause n’est attribuée à Claude, au SDK ou à l’adaptateur. T3 n’a pas relancé ce canal. Le composant ne lit pas lui-même la conversation.

La réponse conservée et sa comparaison hors ligne sont consultables : cinq listes de 2, 2, 2, 3 et 2 éléments, comparées exactement au pack fictif épinglé, sans ajout, omission ni duplication dans ces listes. Les limites liées aux preuves, aux sources et aux permissions font l’objet d’une lecture éditoriale distincte. Les 57 236 octets désignent la projection de l’outil ; la réponse conservée en contient 6 029. Cette vérification de fichiers ne rejoue pas le client et n’authentifie pas indépendamment la séance. Le nom du modèle affiché ne certifie pas son identité interne.

Reproduire le parcours local et lire ses limites ; résultat T3 dans le relevé historique. La page du Runtime détaille la vérification et ses limites.

Comparer deux états avant de choisir le contexte

Une condition retirée, une preuve ajoutée ou une source modifiée mérite une revue avant la réutilisation du contexte. Le comparateur montre les différences de B par rapport à A, deux états choisis explicitement pour la même intention et la même langue.

Chaque entrée est vérifiée avec son instantané complet et ses archives sous une racine admise séparément, puis validée contre les schémas du pack et du manifeste. Ajouts, retraits, valeurs modifiées et changements d’ordre restent consultables avec les originaux et un rapport exportable. Une phrase réécrite dans une liste produit un retrait et un ajout ; aucune continuité de règle ni équivalence de sens n’est supposée.

Une démonstration Web FR/EN permet de choisir les deux états fictifs, de consulter leurs différences et d’exporter le rapport complet. Les huit paires compatibles sont calculées avec l’admission complète lors de la construction, puis contrôlées au chargement. Le diagnostic des états réels conservés reste hors ligne. A et B n’établissent aucune succession de publications. Comparer ne transmet aucun pack au modèle. T3 reste une qualification distincte ; aucun bénéfice métier ni effet sur une réponse n’est établi par cette comparaison.

Examiner le parcours local et le rapport exportable · Lire la qualification datée et ses limites.

Essayer le comparateur sur des exemples fictifs

Examiner la référence publique 0.2.1

La préversion de référence 0.2.1-proposed fournit les contrats proposés, les vérificateurs et un parcours consommateur exécutable hors ligne. Le kit fictif permet d’inspecter un pack complet avec ses sources et ses limites. Sa racine et sa politique de confiance sont fournies pour l’exercice, sans établir une confiance de production.

Essayer le kit consommateur hors ligne · Comprendre la portée sémantique du pack · Examiner la qualification locale du producteur

La qualification locale documente les contrôles du producteur sur ses actifs conservés, sans rendre son corpus privé reproductible publiquement. La version 0.2.1 désigne la référence hors ligne, distincte de la version conceptuelle et de celle du service hébergé.

L’intégrité des octets, la permission d’utiliser le contexte et la fidélité d’une réponse restent distinctes. Le pilote comparatif sur modèles est préparé mais non exécuté (NOT_RUN). Cette publication ne constitue ni une nouvelle observation du service hébergé, ni un déploiement clé en main pour d’autres domaines. Le contrôle du 12 octobre 2026 présenté ci-dessous conserve sa portée historique.

Du contexte fourni à la réponse observée

Fournir un contexte identifiable ne suffit pas à établir la qualité de la réponse qui suit. Le moteur expérimental de Governed Context Runtime permet de comparer quatre conditions sur un service fictif : question seule, texte exhaustif, prose canonique et pack structuré. Les messages et les réponses reçues sont conservés, avec les erreurs techniques et les reprises limitées. Les réponses terminées, même vides, refusées ou tronquées, restent dans les observations.

Deux juges automatiques distincts appliquent une grille commune. Leurs annotations restent séparées, et l’accord est calculé uniquement sur les jugements appariés. Les essais sans réponse terminée sont distingués des réponses qui attendent encore un jugement. Ce parcours est distinct du service de distribution et du compagnon MCP Apps ; il ne mesure pas, à lui seul, l’utilité d’un site pour tous les agents.

Lire le protocole et les limites du pilote · Consulter le relevé d’implémentation daté. Les états NOT_RUN des essais locaux et des éditions précédentes conservent leur portée historique ; ils ne remplacent pas un reçu de campagne fournisseur.

Une exécution interrompue reste documentée. Sa reprise doit conserver les requêtes précédentes, les entrées applicables et le montant déjà engagé, puis identifier l’exécutable qui la poursuit. Le moniteur suit cette continuité sans lancer de nouvelle requête au modèle.

Un contexte prêt à examiner avant de répondre

Un assistant qui explique une doctrine doit pouvoir retrouver ses sources et ses limites. L’instance de gautierdorval.com distribue des packs précompilés pour une intention déclarée et une langue choisie. L’intégrateur peut examiner la version reçue avant de la fournir à l’assistant.

Le contrôle technique effectué par le producteur le 12 octobre 2026 à 02:18 UTC a confirmé l’accès HTTP, huit outils MCP et un pack français reçu à l’identique par les deux transports. Le registre observé contient six intentions et douze packs FR/EN.

Explorer les intentions disponibles · Suivre le guide d’intégration REST/MCP · Consulter le dépôt public de référence

Choisir une intention exacte dans le registre, puis la langue et la version du pack. Le choix appartient au consommateur.
Récupérer le pack et son manifeste par HTTP ou MCP. L’interface sert les artefacts précompilés correspondant aux identifiants demandés.
Vérifier l’instantané complet et ses archives sous une racine de corpus épinglée séparément, puis décider localement de l’utilisation du contexte.

L’accès HTTP commence à https://context.gautierdorval.com/. L’adaptateur séparé reçoit les requêtes POST à https://context.gautierdorval.com/mcp. Son profil MCP 2026-07-28 utilise server/discover et des métadonnées par requête. Le guide fournit les commandes PowerShell et précise les limites de compatibilité des clients.

Consulter l’état technique · Examiner l’instantané du corpus · Lire l’observation datée

Ces contrôles établissent un fonctionnement technique observé, sans garantir la disponibilité future. Ils ne mesurent ni adoption spontanée ni effet sur une réponse de modèle. L’intégrité du contexte, la permission de l’utiliser et la fidélité de la réponse demeurent trois questions distinctes. Une unité v0 isolée exige la vérification de son enregistrement complet dans l’instantané : son empreinte historique ne couvre pas tous ses champs. Le guide fournit un exemple consommateur qui conserve cette portée au point d’usage. Les clés restent réservées aux essais et les racines archivées ne constituent pas un historique des déploiements.

Apprendre la vérification avec un exemple fictif

La démonstration locale rassemble un reçu, un instantané et ses archives pour suivre le parcours de vérification sans compte ni appel réseau. Ses données et clés de test restent distinctes de l’observation du service hébergé. Examiner la démonstration exécutable.