L'approche RGPD+ et l'architecture BYOK

Ce que cet article est, et ce qu'il n'est pas. C'est une description d'architecture et une liste de vérifications techniques. Ce n'est pas un conseil juridique : votre situation dépend de vos données, de vos finalités et de vos clients. Nous décrivons ce que la technique permet de constater ; la qualification juridique se fait avec un professionnel du droit.

Introduction : la confiance ne se déclare pas, elle se constate

La plupart des pages « conformité » d'éditeurs disent la même chose : nous prenons vos données au sérieux, nous respectons le règlement, nous sommes engagés. Ces phrases ont un défaut commun — elles ne sont pas vérifiables par celui qui les lit.

Une architecture, elle, se constate. La question utile n'est donc pas « est-ce qu'ils promettent de bien faire ? » mais :

qui détient le compte chez le fournisseur d'intelligence artificielle, et donc qui a la main sur les réglages ?

Cette question a une réponse binaire, et elle décide de tout le reste. C'est le sujet de cet article : ce qu'une clé API personnelle change concrètement, ce qu'elle ne change pas, et les six points que vous pouvez aller vérifier vous-même en dix minutes.

1. Le déplacement qui change la nature du problème

Dans un modèle où l'éditeur inclut l'intelligence artificielle, il achète la capacité en gros et vous la revend. Les traitements passent par son compte, sous ses conditions, dans la région qu'il a choisie. Vous héritez de décisions que vous n'avez pas prises et que, le plus souvent, vous ne pouvez pas lire.

Avec une clé personnelle, le compte est le vôtre. Quatre conséquences, toutes constatables :

• la relation contractuelle avec le fournisseur d'IA est directe : vous acceptez ce que vous acceptez, et vous pouvez le produire ;
• la région de traitement est un réglage de votre console, pas une information à demander ;
• la durée de conservation est visible et parfois configurable, du même endroit ;
• le paramètre d'entraînement sur vos contenus se lit sur écran, il ne se croit pas.

Le mot qui compte ici est « constatable ». Un engagement contractuel vaut ce que vaut celui qui le donne ; un réglage que vous voyez vaut ce que montre l'écran. La différence apparaît le jour où on vous demande de prouver — pas avant.

Le raisonnement économique parallèle est traité dans souveraineté et maîtrise des coûts.

2. Ce que « RGPD+ » veut dire chez nous, en trois principes

Le « + » ne désigne pas une conformité supérieure — cette notion n'existe pas. Il désigne trois choix d'architecture faits au-delà de ce qui est demandé, parce qu'ils réduisent le risque à la source.

Minimiser avant de sécuriser. La donnée la mieux protégée est celle qui n'a pas été envoyée. Avant de chiffrer un flux, la question est : est-ce que ce champ doit partir ? Un traitement qui n'a besoin que du texte d'un produit n'a pas besoin du nom du client.

Rendre le départ facile. La portabilité n'est pas seulement une obligation, c'est un test de conception. Une architecture d'où l'on ne peut pas sortir avec ses données est une architecture qui vous tient — quelles que soient ses conditions affichées. La clé étant la vôtre, l'historique l'est aussi.

Ne rien promettre qu'on ne puisse montrer. C'est le principe le plus contraignant pour nous, et il vient d'une erreur réelle de notre côté : nos pages ont annoncé publiquement une facilité que notre paiement ne créait pas. Nous l'avons retirée de toutes les pages plutôt que de la maintenir. Une promesse qu'on ne peut pas dériver d'un fait est une promesse à retirer, pas à reformuler.

3. Ce que l'architecture ne fait PAS — la section qui manque partout

Trois limites. Les omettre serait exactement le défaut que le principe précédent interdit.

Elle ne vous rend pas conforme. Le contrôle des paramètres ne remplit pas votre registre des traitements, n'écrit pas votre analyse d'impact, ne rédige pas votre information aux personnes concernées, et ne définit pas vos bases légales. Ce sont des travaux à part entière.

Elle ne couvre que le flux d'IA. Vos formulaires, votre mesure d'audience, vos scripts tiers, vos exports vers un outil de gestion continuent d'exister et ne sont pas concernés. Sur la partie consentement, voir notre approche des cookies.

Elle ne survit pas à une mauvaise pratique. Une clé partagée entre plusieurs clients, ou déposée dans un fichier de configuration versionné, annule l'essentiel du bénéfice. La souveraineté est une propriété de l'usage, pas une propriété du contrat.

4. Les six vérifications que vous pouvez faire vous-même

Aucune ne demande de nous croire. Comptez dix minutes.

• Ouvrir la console de votre fournisseur d'IA et lire la région de traitement réellement appliquée
• Vérifier le paramètre d'entraînement sur vos contenus, et faire une capture datée — la capture est la preuve, pas le souvenir
• Relever la durée de conservation des journaux d'usage, et la comparer à ce que vos propres mentions annoncent
• Vérifier qu'il existe une clé par client, jamais une clé mutualisée
• Vérifier qu'aucune clé n'est dans un dépôt versionné ni dans un fichier accessible depuis le web
• Écrire en trois lignes comment vous récupéreriez tout et changeriez de fournisseur demain matin

Le sixième est le plus révélateur. Si vous ne savez pas répondre, la question n'est pas la conformité — c'est la dépendance.

5. Le point que les acheteurs professionnels regardent en premier

Si vous vendez à des organisations soumises à des obligations — santé, secteur public, données sensibles — la question du fournisseur d'IA arrive tôt dans leur processus d'achat, et elle est éliminatoire.

Ce qu'ils demandent n'est presque jamais « avez-vous une politique ? » mais « où passent les données, sous quel contrat, et comment le montrez-vous ? ». Une architecture où le client détient son propre compte répond en une phrase, avec une capture d'écran à l'appui. Une architecture mutualisée répond par un document, ce qui n'est pas la même chose et ne se traite pas au même niveau hiérarchique.

Ce n'est pas un argument marketing, c'est une réduction de cycle de vente. Et c'est mesurable : comptez le nombre d'allers-retours entre la question et la réponse validée.

Conclusion

Une architecture ne remplace pas la conformité, et aucun schéma technique ne dispense du travail juridique. Ce qu'une clé personnelle apporte est plus modeste et plus solide : la position depuis laquelle on peut vérifier sans demander la permission à personne.

La confiance construite sur une déclaration se réévalue à chaque changement d'éditeur, de conditions ou de tarif. La confiance construite sur un accès ne se réévalue pas : vous ouvrez la console, et vous voyez.

Le test qui résume l'article : si on vous demandait aujourd'hui de prouver où vont les données de vos clients, combien de personnes devriez-vous solliciter pour répondre ? Si la réponse est « aucune », l'architecture fait son travail.

Pour aller plus loin : souveraineté et maîtrise des coûts, nos six engagements sur l'IA responsable, pourquoi AIFORYA a choisi ce modèle, et notre alternative à Complianz. Côté outils : mesure d'audience et consentement — versions premium avec remboursement intégral sous 14 jours.