SDK Fonctionnement
Fonctionnement
Deux circuits qui ne se mélangent jamais : vos utilisateurs parlent à ID Side de leurs préférences, et votre backend parle à ID Side de ses appels IA. Le développeur se tient exactement d'un seul côté de cette cloison — c'est précisément ce qui donne sa valeur à la preuve.
Circuit A — préférences
L'utilisateur parle à ID Side. Vous n'écoutez pas.
Le widget Centre de préférences est une iframe servie depuis notre domaine, intégrée à vos pages. Quand Marie refuse l'entraînement de l'IA, ce choix va directement de son navigateur à nos serveurs. Votre frontend héberge l'iframe ; il ne peut pas lire ce qui s'y passe, et votre backend ne dispose d'aucun point d'entrée pour écrire une préférence — cette API n'existe tout simplement pas.
Les préférences peuvent aussi arriver sans le widget : le signal Global Privacy Control du navigateur est détecté et enregistré comme une source de consentement à part entière. Le GPC a force contraignante dans une douzaine d'États américains (dont la Californie) ; en Europe, il n'a aujourd'hui aucune force juridique — nous l'enregistrons comme un signal explicite de l'intention de l'utilisateur, rien de plus, et un choix explicite fait dans le widget prime toujours sur lui.
Circuit A′ — la politique
Quand personne n'est interrogé : la politique de l'organisation
Il existe un second chemin par lequel une préférence atteint un appel, et ce n'est pas celui de la personne. Une organisation déclare ce qu'elle refuse pour tous ceux qui travaillent sous son autorité — pour l'entreprise entière, ou pour une seule de ses équipes — et cette déclaration est lue à chaque autorisation, par-dessus ce à quoi l'état propre de la personne s'est résolu.
Elle ne peut que restreindre. Seuls les refus d'une politique sont lus. Elle ne peut pas rallumer une option, et le refus propre d'une personne survit à une politique qui l'autoriserait. Ce n'est pas de la courtoisie : une politique capable d'autoriser laisserait un client annuler les choix de ses utilisateurs depuis son propre tableau de bord, c'est-à-dire la seule chose que toute cette conception existe pour rendre impossible.
Au travail, le consentement n'est pas disponible comme base. Le RGPD ne tient pas le consentement d'un salarié pour librement donné : la politique d'une organisation porte donc l'intérêt légitime ou l'obligation contractuelle — ou rien du tout. Ce n'est pas une règle que nous pensons à appliquer : le modèle n'accepte pas la valeur, donc le formulaire ne peut pas la proposer.
Ce que l'on doit à un salarié n'est pas une fenêtre, c'est un état des lieux. Chaque membre dispose d'une page de transparence nommant son organisation, ses équipes, la base invoquée, exactement quelles options sont refusées pour lui, et chaque chiffre que son employeur peut voir à son sujet. Les mêmes chiffres, par une règle qu'un test fait respecter — rien n'est montré à l'employeur qui soit caché à la personne.
Où ce mode s'arrête
Il suppose un lien d'emploi ou un lien équivalent. Rien dans le code ne vous empêche de le pointer vers vos visiteurs, et nous préférons expliquer plutôt qu'interdire. Quelqu'un qui n'a jamais été interrogé, et qui ne travaille pas pour vous, se résout avec aucune base légale constatée — not_established, la valeur inscrite dans le jeton ACT, chaînée dans le ledger et renvoyée par le point de vérification, à chaque appel. Le document que vous étiez venu chercher est celui qui le dit.
Revendiquer l'intérêt légitime sur des personnes qui ne sont pas vos salariés ne répare rien non plus : cela signe et date la revendication, dans votre propre ledger en ajout seul, pour quiconque s'en enquerra plus tard. C'est toute la conception : dissuasive et probatoire, jamais policière.
Circuit B — l'appel IA
Votre backend demande une autorisation avant chaque appel
Avant que chaque requête n'atteigne le fournisseur, le client encapsulé appelle ID Side avec une référence utilisateur pseudonymisée et un hachage de la requête — jamais le contenu. Nous résolvons les préférences actuelles de l'utilisateur, décidons ce qui doit être appliqué, et répondons par deux types d'injection. Si nous sommes injoignables, le SDK échoue de façon fermée : il lève une erreur et l'appel IA ne part pas. Pas d'autorisation, pas de requête.
- decision
- allow
- mode
- live
- consent_state
- training.foundation
- false
- memory
- false
- retention.conversation
- true
- source
- widget
- legal_basis
- consent
- binding
- user_id
- params_forced
- store=false
- act_token
- eyJhbGciOiJFUzI1NiJ9…
- token_id
- act_01kycmhhx6jw4614ze3gt66n8b
- expires_at
- 2026-07-25T13:38:31Z
Un appel autorisé, et ce qu'il laisse derrière lui.
L'entrée du registre n'est pas un champ de cette réponse, et ce n'est pas non plus une tâche qui s'exécute ensuite : elle est ajoutée de façon synchrone, dans la même transaction que l'enregistrement du jeton, si bien que la preuve existe avant que l'appel ne parte. Une réponse que vous pouvez lire est un appel déjà consigné.
Deux types d'injection
Paramètres du fournisseur forcés
Lorsque le fournisseur expose un véritable levier de confidentialité, le SDK le fixe directement sur la requête et votre code ne peut pas le désactiver. Chez OpenAI, un utilisateur ayant refusé l'entraînement obtient store=false sur chaque appel — réellement appliqué, pas seulement journalisé. Cette correspondance vit dans notre registre de fournisseurs : quand un fournisseur change son API, nous mettons à jour une ligne au lieu de vous livrer un nouveau SDK. Là où un tel levier n'existe pas, le niveau de confiance de ce fournisseur le dit clairement.
Le jeton ACT
Aux côtés des paramètres forcés, chaque requête porte un jeton de consentement IA (ACT) signé : une preuve compacte liant cette requête unique (par hachage et nonce, une heure de validité, sans réutilisation) à l'état de consentement sous lequel elle a été autorisée. Les fournisseurs d'IA n'agissent pas encore sur ce jeton aujourd'hui — nous sommes francs à ce sujet. Sa valeur est pour vous : un reçu cryptographique portable, que n'importe qui peut vérifier avec nos clés publiques publiées, ancré dans le registre.
Un seul compte, toutes les applications
Marie ne devrait pas avoir à répéter « pas d'entraînement de l'IA » à chaque produit qu'elle utilise. Avec un compte ID Side, elle le dit une fois. Quand elle relie une application — via une fenêtre en propre où elle prouve qu'elle contrôle son adresse email — ses préférences s'y appliquent immédiatement, et chaque application future n'est plus qu'à un clic.
Le parcours de liaison est aussi ce qui garantit la sincérité de l'identité : le développeur ne fournit que son user_id local ; Marie fournit l'identité vérifiée. Aucun des deux côtés ne peut affirmer les deux moitiés à la fois, donc aucun développeur ne peut discrètement rattacher ses utilisateurs à un compte définitivement consentant.