Ce qu'Attaché peut voir de vos données (et ce qu'il ne peut pas)

Réponse courte : un connecteur IA comme Attaché voit passer les données qu’il interroge, mais ne les conserve pas — aucune donnée métier n’est stockée, seuls des jetons OAuth chiffrés (AES-256-GCM), les identifiants des ressources partagées et un journal des requêtes (la question posée, jamais le résultat) résident en base. Le tout est vérifiable sans nous croire : scopes lisibles sur l’écran de consentement Google, révocation contrôlable sur myaccount.google.com/permissions.

La liste exhaustive de ce qu’Attaché conserve — et de ce qu’il ne voit jamais.

À chaque démo, la même question arrive vers la dixième minute. Parfois poliment — « et vous, vous voyez quoi ? » — parfois frontalement : « qu’est-ce qui m’empêche de penser que vous aspirez les données de mes clients ? » C’est la bonne question. Voici la réponse complète, y compris les parties qui ne nous arrangent pas.

Ce qui est stocké, exhaustivement

Attaché a une base de données. Elle contient votre compte (email, nom de l’agence, membres de l’équipe), vos clients (le nom que vous leur donnez et le lien d’invitation associé), la liste des ressources partagées — un identifiant et une étiquette du type « GA4 — Boutique Dupont (properties/123456789) », rien d’autre —, les jetons OAuth chiffrés en AES-256-GCM, un journal d’accès, et un compteur de requêtes par jour et par client, pour la facturation.

C’est tout. Il n’y a pas de table de sessions GA4, pas de table de campagnes, pas d’entrepôt. Ce n’est pas une politique de rétention à zéro jour — c’est une absence de schéma. La donnée n’a nulle part où aller.

Que se passe-t-il quand vous posez une question ?

Vous demandez à Claude le ROAS d’un client sur juillet. Claude appelle l’outil correspondant (ga4_run_report, par exemple) sur votre connecteur. Le serveur retrouve le client, vérifie que la propriété fait partie de celles qui ont été cochées, déchiffre le jeton OAuth en mémoire, appelle l’API de Google, renvoie la réponse à Claude — et l’oublie.

Cet oubli n’est pas une opération de nettoyage : c’est le fait qu’aucune écriture n’ait lieu. Le seul cache porte sur la liste des propriétés partagées — les identifiants et les noms, pas les chiffres — pendant soixante secondes, pour éviter de rappeler l’API d’administration à chaque question. La marche à suivre côté agence est décrite dans connecter GA4 à Claude.

Le journal garde la question, jamais la réponse

Nuance souvent passée sous silence ailleurs : nous enregistrons les paramètres de chaque requête. Si Claude demande « sessions et revenus, du 1er au 31 juillet, propriété 123456789 », cette ligne-là est conservée. Pas le résultat. Pas les sessions, pas le revenu, pas une ligne du rapport.

Ce journal existe pour une raison précise : votre client peut ouvrir son espace et voir exactement ce que vous avez consulté, et quand. Un accès qu’on ne peut pas auditer n’est pas un accès de confiance, c’est un accès subi.

Pour une agence fictive de 12 clients e-commerce qui pose une trentaine de questions par jour, la base Attaché grossit d’autant de lignes de journal — et de zéro donnée métier. Au bout d’un an : environ 10 000 lignes de « qui a demandé quoi, quand », et toujours pas un seul chiffre d’affaires stocké chez nous.

Ce que nous pourrions faire, techniquement

Voici la partie que la plupart des pages « Sécurité » évitent.

Attaché détient la clé de chiffrement des jetons. Nous pourrions donc, techniquement, déchiffrer un jeton et appeler l’API à votre place. Ce n’est pas du chiffrement de bout en bout, et prétendre le contraire serait mensonger : un service qui doit utiliser un jeton pour vous ne peut pas, par construction, être incapable de l’utiliser.

Ce qui limite ce risque n’est pas une impossibilité mathématique, mais quatre garanties dont trois se vérifient sans nous faire confiance. Les scopes sont en lecture seule (analytics.readonly, webmasters.readonly) : même jeton en main, on ne peut rien modifier — et vous les lisez sur l’écran de consentement Google avant de cliquer. Google Ads est le cas particulier, et nous le disons : aucun scope lecture seule n’existe pour Ads, notre garde-fou est applicatif — toute requête GAQL qui n’est pas un SELECT est rejetée côté serveur. Cette garantie-là repose sur notre code, donc sur notre parole. La révocation, elle, se fait chez Google et pas seulement chez nous : un clic appelle l’endpoint officiel, le jeton devient inutilisable partout, y compris pour nous, y compris si notre base était copiée — le mécanisme complet est ici. Et le journal est consultable par le client : une consultation anormale se voit.

Et l’hébergement européen ?

Notre infrastructure tourne chez Railway, en région US East. Nous avons envisagé de migrer vers l’Europe, puis regardé ce que cela changeait sur la question qui vous préoccupe : rien. Aucune donnée issue de vos comptes ne réside sur ces serveurs — ce qui y réside, ce sont des identifiants de propriétés, des adresses email et des jetons chiffrés. Déplacer ces trois choses de quelques milliers de kilomètres n’ajoute aucune protection à des données qui ne sont pas là.

Nous préférons l’écrire ainsi plutôt que d’afficher un drapeau européen sur la page d’accueil. Les transferts s’appuient sur les clauses contractuelles types, le détail des sous-traitants est sur la page sécurité, et si la région devient bloquante pour votre conformité, dites-le nous : c’est une migration, pas un obstacle de principe.

Ce que votre client voit de son côté

C’est le point qui fait basculer les discussions. Votre client n’a pas à vous croire sur parole non plus. Il dispose de son propre espace où il voit les comptes qu’il a connectés et avec quel compte Google, la liste précise de ce qu’il partage — des cases qu’il peut décocher —, l’historique de vos consultations, et un bouton de révocation qui coupe tout.

Aucun mot de passe n’a changé de mains. Aucun email de l’agence n’a été ajouté dans GA4, Google Ads ou Search Console — rien à retirer, donc, le jour où la collaboration s’arrête. C’est l’argument qui fait signer : vous offrez à votre client un contrôle qu’il n’avait pas avant vous. Notre grille d’évaluation d’un connecteur est dans la checklist sécurité.

Comment vérifier tout ça vous-même

Sans nous croire, en quatre minutes :

1. Lisez les scopes sur l’écran de consentement Google avant d’accepter.
2. Une fois le compte connecté, ouvrez myaccount.google.com/permissions : vous voyez précisément ce qui a été accordé.
3. Révoquez depuis Attaché, rechargez cette page Google : nous n’y sommes plus.
4. Posez une question dans Claude, puis ouvrez le journal d’accès : la requête y figure, le résultat non.

C’est plus convaincant que n’importe quelle page « Sécurité », y compris celle-ci.

Questions fréquentes

Attaché stocke-t-il les données GA4 ou Google Ads de mes clients ?

Non. Attaché est un connecteur temps réel : les données transitent de l’API de Google vers Claude et ne sont jamais écrites en base. Ne sont stockés que les jetons OAuth chiffrés, les identifiants des ressources partagées et le journal des requêtes — la question posée, jamais son résultat.

Anthropic (Claude) voit-il les données de mes clients ?

Les résultats s’affichent dans votre conversation Claude, comme n’importe quel contenu que vous y collez, et relèvent donc de la politique de données de votre abonnement Claude. Attaché, lui, n’en garde aucune copie.

Que reste-t-il chez Attaché après une révocation ?

Le jeton OAuth est révoqué chez Google (l’application disparaît de myaccount.google.com/permissions) puis supprimé de notre base, avec les identifiants des ressources associées. Reste le journal des requêtes passées — les paramètres, jamais les résultats — comme trace consultable de la mission.

---

Une question que cet article ne couvre pas ? Écrivez à [email protected] — les questions difficiles finissent en général dans le texte. Et Attaché se teste gratuitement pendant 60 jours, sans carte : app.attache.studio.