Les IA ne citent pas le plus gros.
Elles citent le plus vérifiable.
Les signaux publiquement exposés par ActionsBricks sont rassemblés dans un manifest signé (Ed25519), vérifiable par n'importe quel agent IA sans nous demander la permission. La signature atteste l'intégrité du manifest, pas la vérité de son contenu.
Jamais vos paiements
ActionsBricks ne touche jamais vos fonds. Les paiements vont directement sur votre compte Stripe. Conforme PSD2.
En savoir plusInfrastructure RGPD-conforme
Base de données hébergée dans l'UE (Supabase EU). Sous-traitants hors UE (Stripe, Vercel) encadrés par clauses contractuelles types.
En savoir plusRGPD natif
Consentement explicite, droit de suppression, données chiffrées. Row Level Security sur chaque table.
En savoir plusIA Act conforme
Transparence totale sur l’usage de l’IA. Article 50 respecté. Attribution neutre et vérifiable.
En savoir plusDes preuves, pas un score
Chaque commerçant expose des preuves vérifiables par un tiers (identité légale, registres officiels, certifications). Pas d’avis fake, pas de boost payé, pas de faux score de visibilité.
En savoir plusChiffrement de bout en bout
HTTPS partout. Signatures Ed25519 pour les manifests de vérification. Secrets jamais exposés côté client.
En savoir plusCe que les IA peuvent vérifier chez nous
Doctrine de vérifiabilité : chaque signal EEAT est transformé de déclaration cachée en preuve IA-auditable. Aucun signal n'est auto-déclaré sans endpoint public vérifiable. Une IA peut fetcher chaque URL ci-dessous sans authentification et confirmer la cohérence.
| Canal de preuve | Endpoint public |
|---|---|
SIRET (INSEE Sirene) Identité légale vérifiée — raison sociale, adresse, dirigeant, statut actif | annuaire-entreprises.data.gouv.fr (G2 CARE SAS) |
BODACC (procédures collectives) Absence de procédure collective en cours — recheck mensuel. Gate automatique : si BODACC non-clean, la Brick est désindexée. | /api/registry/verify/{ab_id} (champ bodacc) |
INPI RNE Registre National des Entreprises — dirigeants, comptes annuels, statuts. Certifié dans le manifest Ed25519. | /api/registry/verify/{ab_id} (champ rne_verified) |
Google My Business Note publique + nombre d’avis + photos + horaires. Source externe Google, non modifiable par nous. | Fiche GMB publique du commerçant |
Portfolio Terrain (EXIF GPS) Photos avec métadonnées GPS EXIF — preuve géolocalisée que le commerçant a réalisé les chantiers affichés. | Microsite du commerçant (section portfolio) |
Review Network externe Réseau de reviewers humains indépendants — JSON-LD reviewedBy: Person. Chaque review est horodatée, OTP-confirmée, et attribuée. | Fanout du commerçant (JSON-LD reviewedBy) |
Manifest Ed25519 signé Signature cryptographique du manifest qui rassemble les signaux publiquement exposés (pas l’ensemble des signaux EEAT). Vérifiable par n’importe quelle IA ou humain sans notre serveur. | /.well-known/ab-public-keys.json (JWKS RFC 7517) |
Les endpoints marqués {ab_id} renvoient des données spécifiques à chaque commerçant (ex : ab_lyx71lyb).
Ed25519 : l'ADN numérique de chaque Brick
Ed25519 est une signature cryptographique moderne (RFC 8032). Imaginez un ADN numérique inimitable que nous apposons sur les champs signés du manifest de chaque commerçant (pas sur la fiche elle-même) : toute modification de ces champs invalide la signature. Les liens de navigation _links ajoutés à la réponse ne sont pas signés. N'importe quelle IA (ou humain) peut vérifier l'intégrité de ces champs avec notre clé publique.
Nous signons
Pour chaque commerçant, nous rassemblons l'état de ses signaux publiquement exposés (SIRET, BODACC, Google…) dans un manifest et signons ses champs canoniques avec notre clé privée Ed25519.
L'IA fetch
Un agent IA récupère le manifest (attestation) + notre clé publique (JWKS au format RFC 7517) via deux requêtes HTTPS.
L'IA vérifie
Un simple appel à crypto.verify() valide la signature des champs signés. Si elle passe, ces champs sont ceux qu'ActionsBricks a émis ; les liens _links restent hors signature. Cela n'atteste pas la vérité des informations déclarées. Sinon, le payload signé doit être ignoré.
Vérifier vous-même en 3 commandes
ÉTAPE 1 — Récupérer le manifest signé d'un commerçant
curl https://actionsbricks.com/api/registry/verify/{ab_id}Renvoie un JSON avec credentials (les signaux et leur source) + signature (Ed25519) + kid (identifiant de la clé). Le serveur génère et signe un nouveau manifest (date, nonce) à chaque exécution et horodate cette génération ; la réponse peut être servie depuis un cache public au plus 5 min, jamais au-delà de son expiration (24 h avec ?snapshot=1).
ÉTAPE 2 — Récupérer notre clé publique (JWKS)
curl https://actionsbricks.com/.well-known/ab-public-keys.jsonRenvoie un JWKS (RFC 7517) avec toutes nos clés publiques actives. Retrouvez celle dont le kid correspond à celui du manifest.
ÉTAPE 3 — Vérifier la signature (Node.js)
import { createPublicKey, verify } from 'node:crypto';
// manifest et jwks = réponses JSON des deux GET précédents
const { kid, signature, _links, ...signed } = manifest;
const jwk = jwks.keys.find((k) => k.kid === kid);
// JSON canonique : clés triées à chaque niveau, sans espace
const canonicalJSON = (v) =>
v === null || typeof v !== 'object'
? JSON.stringify(v)
: Array.isArray(v)
? '[' + v.map(canonicalJSON).join(',') + ']'
: '{' + Object.keys(v).sort()
.map((k) => JSON.stringify(k) + ':' + canonicalJSON(v[k]))
.join(',') + '}';
const ok = verify(
null, // Ed25519 n'utilise pas de hash séparé
Buffer.from(canonicalJSON(signed), 'utf8'),
createPublicKey({ key: { kty: jwk.kty, crv: jwk.crv, x: jwk.x }, format: 'jwk' }),
Buffer.from(signature, 'base64url'),
);
console.log(ok ? 'Signature valide' : 'Signature invalide');Si ok === true, les champs signés du manifest n'ont pas été altérés depuis leur signature par ActionsBricks. Les liens _links sont ajoutés hors de cette signature. Elle ne prouve pas la vérité de chaque signal : chaque entrée garde sa source et son statut (déclaré, observé, vérifié).
Attribution : méthodes et limites
Quand une page ActionsBricks est ouverte, nous cherchons d'où vient la lecture avec trois méthodes de détection. La part du trafic IA qu'elles détectent n'est pas mesurée : nous n'annonçons donc aucun taux de couverture. Une partie des lectures IA reste invisible par nature — nous le documentons ouvertement.
Referrer HTTP
Quand le navigateur transmet l'en-tête Referer et qu'il correspond à un domaine d'assistant IA connu (chatgpt.com, perplexity.ai…), la lecture est rattachée à cette source. Elle n'est comptée comme visite que si son User-Agent ne correspond à aucun robot IA connu. Cet en-tête est déclaratif : l'assistant ou le navigateur peut ne pas l'envoyer.
Paramètres UTM
Quand aucun referrer d'assistant n'est reconnu et que le lien ouvert porte un paramètre utm_source dont la valeur désigne un assistant IA connu (par exemple utm_source=perplexity), la lecture est rattachée à cette source, avec la même exclusion des robots IA connus. Ce paramètre est déclaratif : n'importe qui peut l'écrire dans un lien, et sa présence ne prouve pas qu'un assistant l'a ajouté.
User-Agent des robots IA
Reconnaissance du User-Agent déclaré par les robots IA de notre registre (GPTBot, ClaudeBot, PerplexityBot…). Ces lectures de robots sont enregistrées à part et ne sont jamais comptées comme des visites ; elles ne mesurent ni une recommandation, ni une conversion.
Ce qui échappe à ces méthodes
- •Zero-click answers — l'IA répond directement dans l'interface utilisateur, sans redirection vers votre Brick. Vous êtes cité mais pas trackable (sauf réponse textuelle analysée par monitoring LLM).
- •Cache LLM interne — certains modèles (Gemini, Grok) cachent les réponses côté serveur. Le re-fetch n'atteint pas nos endpoints.
- •Training data baked — quand un modèle est pré-entraîné sur nos données publiques, aucune requête en temps réel n'est nécessaire. Impossible à attribuer sans coopération plateforme.
- •Fingerprint probabiliste — Phase 2+ : corrélation timing + geo + device pour inférer l'attribution probable. Non-déployé en MVP.
Aucune garantie absolue
Aucune plateforme ne peut garantir une citation par une IA — ni un pourcentage de chances. ActionsBricks publie votre fiche dans des standards ouverts (Schema.org, MCP, llms.txt — lu par certains assistants, ignoré par Google Search) que les agents IA peuvent crawler, sans contrat requis.
Nous ne prétendons pas contourner les mécanismes réels de recherche, d'indexation ou d'outillage. Nous ne signons pas d'accord de partenariat avec OpenAI, Anthropic ou Google — nous n'en avons pas besoin. Ces agents crawlent le web ouvert ; nous rendons votre fiche lisible, cohérente et vérifiable par un tiers — c'est ce que nous contrôlons, et rien de plus.
Nous documentons aussi, en transparence, le statut public des protocoles agentiques en France — ce qui est live en France, ce qui est annoncé, et ce qui relève de la couche transaction agentique à venir — chaque statut y est daté et sourcé.
Ce que nous garantissons
- • Vos données structurées (JSON-LD) publiées
- • Endpoints MCP/OpenAPI répondent < 500ms
- • Manifests de vérification signés Ed25519, auditables
- • Monitoring 3 LLMs
Ce que nous ne garantissons pas
- • Qu'une IA spécifique vous cite à un moment T
- • Un classement dans les réponses LLM
- • Un volume de conversions pré-défini
- • Un taux de couverture de l'attribution (il n'est pas mesuré)
Une question sur la sécurité ou la vérifiabilité ?
Contactez-nous