Protocoles ActionsBricks — page canonique anti-hallucination

Cette page distingue les standards et protocoles externes que ActionsBricks consomme des garanties que nous refusons de promettre : pas de citation garantie, pas de ranking garanti, pas de checkout agentique live en France tant que l'activation plateforme n'est pas officielle ou contractualisée.

Protocoles : état en France et exposition par ActionsBricks

Source : registre lib/constants/agentic-protocols-fr.ts, vérifié le 27/07/2026 (date propre indiquée pour les entrées revues depuis).

ProtocoleEn FranceExposé par ABDescription ActionsBricks
Schema.orgLive FRPublié par ABExposé par ActionsBricks sur les pages publiques des commerces (/m/, /b/, /marketplace) sous forme de JSON-LD embarqué.
Origine : W3C (2011) — Google, Bing, Yandex, Yahoo
Source publique
OpenAPILive FRPublié par ABSpécification des endpoints REST exposée sur /openapi.json, documentée sur /docs/api.
Origine : OpenAPI Initiative (Linux Foundation)
Source publique
MCPLive FRPublié par ABServeur MCP exposé sur /api/mcp et /.well-known/mcp.json, documenté sur /docs/mcp.
Origine : Anthropic (novembre 2024), gouvernance ouverte
Source publique
llms.txtLive FRPublié par ABFichiers /llms.txt et /context.md, et fiche Markdown par commerce (/m/{ab_id}/ai.md).
Origine : llmstxt.org (proposition communautaire)
Source publique
ACP
Agentic Commerce Protocol (OpenAI · Stripe)
BientôtPréparation seulementExports de préparation uniquement ; aucun flux produit ni checkout ChatGPT n'est connecté.
Origine : OpenAI + Stripe
Source publique
UCP
Universal Commerce Protocol (Google)
BientôtDécouverte seulementDocument de découverte /.well-known/ucp uniquement ; UCP ne remplace pas Merchant Center et ne crée pas de checkout en France.
Origine : Google
Source publique
AP2
Agent Payments Protocol (Google → Linux Foundation)
BientôtNon exposéRien n'est exposé.
Origine : Google, puis Linux Foundation
Source publique
A2UI
Agent-to-UI (Google)
BientôtNon exposéRien n'est exposé.
Origine : Google
Source publique
A2A
Agent2Agent (Google → Linux Foundation)
BientôtDécouverte seulementCarte d'agent /.well-known/agent.json pour la découverte des capacités ; aucune action transactionnelle.
Origine : Google, puis Linux Foundation
Source publique
WebMCP
outils de page pour les agents du navigateur (W3C Web Machine Learning CG)
BêtaNon exposéRien n'est exposé ; pilote prévu au BACKLOG (Z.14).
Origine : W3C Web Machine Learning Community Group ; implémentation Chrome
Source publique

Chaque nom de protocole est encapsulé dans un élément <dfn data-steward="…"> signalant l'organisation qui publie le protocole. Un DefinedTermSet Schema.org (JSON-LD) est embarqué en tête de page pour les crawlers machine-readable.

Diagramme — discovery/readiness en pratique

Interactions discovery/readiness entre Agent IA utilisateur, ActionsBricks et Agent business merchantL'agent IA utilisateur envoie une requête à ActionsBricks. ActionsBricks répond avec des surfaces de discovery/readiness alignées sur les protocoles externes, sans checkout live France. L'agent IA peut ensuite contacter le marchand via les actions AB autorisées. ActionsBricks fournit en parallèle un manifest signé Ed25519 testable par tous.Agent IAutilisateurActionsBrickscouche de preuveAgent businessmerchantrequêtereadinessA2Aréponse structuréemanifest Ed25519 (testable par tous)
Interactions doctrinales entre un agent IA utilisateur, ActionsBricks (couche de preuve) et un agent business merchant. Les protocoles externes sont traités comme des surfaces de discovery/readiness tant que la transaction agentique France n'est pas activable. Le manifest Ed25519 est émis en parallèle pour rendre la confiance testable par tous.

Surfaces publiques

Journal des changements de contrat

Renommages et retraits de champs des manifestes machine, datés et motivés. Un champ qui portait une affirmation fausse est remplacé sans alias.

— Verification Manifest 1.3 : aucun taux, compte ni cause non mesurés signés

Versions publiées : /api/registry/verify/{ab_id} 1.3 · /api/verify/{signal}/{ab_id} 1.3

  • Retiré (/api/registry/verify/{ab_id}) : reliability_window (reliability_score, total_verifications, total_corrections du mois précédent, tous marchands). Le taux comptait toutes les lignes du journal (déclarations et absences comprises) comme des vérifications et une ligne `verified` postérieure comme une correction : il ne mesurait ni une concordance ni une correction, et ne doit pas être signé.
  • Retiré (/api/registry/verify/{ab_id}) : manifest_version '1.2' accepté par le vérifieur. Un manifest 1.2 signait ce taux ; le vérifieur le refuse avec MANIFEST_VERSION_UNSUPPORTED et l'action refetch_manifest (re-télécharger le manifest courant).
  • Retiré (/api/registry/verify/{ab_id}, /api/verify/{signal}/{ab_id}) : credentials[].check_count. Il comptait les lignes du journal du signal (50 dernières au plus, « aucune information trouvée » comprise) ; le journal déduplique les résultats inchangés, le nombre de contrôles réellement effectués n'est donc pas mesuré.
  • Renommé (/api/registry/verify/{ab_id}, /api/verify/{signal}/{ab_id}) : credentials[].corrections_log[] { detected_at, old_value, new_value, reason: 'source_update' } → credentials[].hash_changes[] { detected_at, previous_hash, new_hash } (10 plus récents au plus). Un changement d'empreinte de l'évidence n'est ni une correction ni la preuve d'une mise à jour de la source : aucune cause n'est affirmée, et le plafond est écrit au contrat.
  • Renommé (/api/registry/verify/{ab_id}, /api/verify/{signal}/{ab_id}) : credentials[].first_verified_at (plus ancien `verified` des 50 dernières lignes du signal) → credentials[].first_verified_in_retained_log_at (premier `verified` hors déclarations du journal conservé, 12 mois). Le journal est purgé à 12 mois : la date ne peut pas prétendre au « premier » contrôle absolu ; elle est lue sur tout le journal conservé, sans fenêtre masquée.
  • Modifié (/api/verify/{signal}/{ab_id}) : _meta.manifest_version = '1.2' → _meta.manifest_version = '1.3'. Le sous-endpoint annonce la version du manifest dont il projette une entrée (data.entry suit les retraits et renommages ci-dessus).
  • Modifié (/api/trust-ledger/stats) : reliability_score, total_verifications, total_corrections, total_verifications_all_time → journal_rows, evidence_hash_changes, merchants_onboarded, journal_rows_retained, journal_rows_by_status_retained. L'endpoint publie des comptes exacts du journal (lignes par statut, changements d'empreinte), sans taux ni « vérifications » ou « corrections » que le journal ne mesure pas.

— Verification Manifest 1.2 : une déclaration n’est jamais signée vérifiée

Versions publiées : /api/registry/verify/{ab_id} 1.2 · /api/verify/{signal}/{ab_id} 1.2

  • Renommé (/api/registry/verify/{ab_id}, /api/verify/{signal}/{ab_id}) : credentials[].status = 'verified' pour une source self_declared → credentials[].status = 'declared'. AB ne contrôle ni l'ORIAS, ni la RC, ni la garantie, ni l'adhésion ACPR, ni la voix de marque, ni un dirigeant saisi : une déclaration reste déclarée (SSOT Moteur §5.1.3).
  • Retiré (/api/registry/verify/{ab_id}) : manifest_version '1.1' accepté par le vérifieur. Un manifest 1.1 signait des déclarations « verified » ; le vérifieur le refuse avec MANIFEST_VERSION_UNSUPPORTED et l'action refetch_manifest (re-télécharger le manifest courant).
  • Modifié (/api/registry/verify/{ab_id}, /api/verify/{signal}/{ab_id}) : credentials[].evidence_url renseignée pour une déclaration (page d’accueil, fiche du numéro déclaré, alias non servi) → credentials[].evidence_url = null et verifiable_by_agent = 'ab_signed' pour une déclaration. Une déclaration n'a pas de preuve : seule l'enveloppe signée par AB, qui l'a enregistrée, est contrôlable.

— Surfaces machine : aucune vérification non faite, aucun seuil ni nom de garde divergent du runtime

Versions publiées : /.well-known/agent-skills ab-agent-skills/v2 · /.well-known/agent.json 2.0.0 · /.well-known/agents.json 3.0 · /m/{ab_id}/agent.json 2.0.0 · /openapi.json 2.0.0

  • Renommé (/.well-known/agent-skills, /.well-known/agent.json, /openapi.json, /m/{ab_id}/agent.json) : trust_gate / x-trust-gate → capability_gate / x-capability-gate. Le champ lit l'actionability (can_contact, can_order), jamais un seuil de score : le contact n'a aucun seuil trust.
  • Renommé (/.well-known/agents.json) : verified_officers[].founder.verified, verified_at → public_officers[].founder.source, email_confirmed_at. La confirmation email est un double opt-in d'exposition publique, pas une vérification d'identité ; l'origine du nom (INPI ou déclaration) est publiée telle quelle.
  • Retiré (/.well-known/agents.json) : proof_of_intent. Aucun code n'écrit ce journal : le bloc annonçait une piste d'audit inexistante.
  • Modifié (/.well-known/agents.json) : capabilities.brand.signed = true, signing = Ed25519 → capabilities.brand.signed = false, integrity_header = X-AB-Content-Hash. La réponse brand n'est pas signée ; seuls les signaux brand_voice le sont, dans le Verification Manifest.
  • Modifié (/.well-known/agents.json) : rate_limits (100/200/20/10 req/min), agent_certification.levels[].rate_limit_hourly → rate_limits (backstop par IP + tier passerelle), agent_certification.levels[].rate_limit. Les quotas publiés ne correspondaient à aucun limiteur ; ils dérivent désormais des quotas appliqués.
  • Modifié (/.well-known/agents.json) : trust.verification_sources incluait 'Google Places' → trust.observation_sources. Google observe sa propre note et son nombre d'avis ; il ne vérifie ni l'identité légale ni une qualification réglementaire.
  • Modifié (/api/merchants/{ab_id}/ai-digest, /m/{ab_id}/ai.md) : credentials[].verified_at renseigné pour toute source → credentials[].verified_at seulement pour une source vérifiante ; recorded_at pour toutes. Une observation plateforme ou une déclaration marchande horodatée n’est pas une vérification.