La limite que le fournisseur a écrite avant qu'on la lui trouve

Il existe une phrase que presque personne n'écrit, dans un secteur où tout le monde la connaît. Elle dit que surveiller un système pour y détecter les usages abusifs oblige à conserver les données assez longtemps pour les rapprocher entre elles — et que jeter la donnée dans l'instant, aussi vertueux que cela paraisse, revient à renoncer à la détection.

Cette phrase a été publiée le 1er septembre 2026, par un fournisseur, à propos de son propre produit.

Ce qui a été écrit, mot pour mot

Le texte est en anglais. Nous le donnons dans sa langue, puis dans notre traduction, signalée comme telle.

Dans tout ce billet, le retrait en bloc est réservé au texte officiel. Les citations qui ne sont pas du droit restent dans le fil, entre guillemets : la distinction n'est pas typographique, elle dit d'où vient ce qu'on lit.

« it is not sufficient to run automated analysis on each interaction separately and then instantaneously discard the data. Effective detection requires storing data for a meaningful period of time so that it can be correlated across time and accounts. »

Notre traduction : il ne suffit pas d'analyser automatiquement chaque interaction séparément puis de jeter la donnée dans l'instant. Une détection efficace exige de conserver les données pendant une durée significative, afin de pouvoir les corréler dans le temps et entre les comptes.

Ce n'est pas un aveu arraché. C'est un paragraphe d'une page publique, écrit par l'éditeur, à un endroit où il aurait pu ne rien dire.

Pourquoi cette phrase compte pour quelqu'un qui ne vend pas de modèle

Prenons deux principes. Ils sont dans le même article du même règlement, à deux lettres d'écart.

Le règlement (UE) 2016/679, article 5, paragraphe 1, demande que les données soient

« conservées sous une forme permettant l'identification des personnes concernées pendant une durée n'excédant pas celle nécessaire au regard des finalités pour lesquelles elles sont traitées »

C'est le point e), celui que le texte nomme lui-même « limitation de la conservation ».

Le point f), immédiatement après, demande qu'elles soient

« traitées de façon à garantir une sécurité appropriée des données à caractère personnel, y compris la protection contre le traitement non autorisé ou illicite et contre la perte, la destruction ou les dégâts d'origine accidentelle, à l'aide de mesures techniques ou organisationnelles appropriées »

Nous ne qualifions ni l'un ni l'autre : ce n'est pas notre métier, et la portée exacte de chacun se discute avec un praticien. Ce que nous constatons est plus simple, et relève de la construction. Détecter un traitement non autorisé dans un système où des milliers de comptes agissent en parallèle demande de comparer ce qui s'est passé hier avec ce qui se passe aujourd'hui, et ce qu'a fait un compte avec ce qu'ont fait les autres. Cette comparaison a un prix, et ce prix est de la durée de conservation. Moins on garde, moins on compare. Moins on compare, moins on détecte.

Le fournisseur ne dit rien d'autre. Il le dit à propos de son produit, et cela vaut pour n'importe quel dispositif de détection, y compris ceux que vous exploitez.

Ce que la réponse apportée déplace, et ce qu'elle ne tranche pas

La suite du texte est aussi intéressante que la phrase elle-même, parce qu'elle ne résout pas la tension : elle en change le siège.

« Activity data used for monitoring can be stored in the customer's own cloud account (such as Amazon S3, Azure Blob Storage, or Google Cloud Storage). »

Les données d'activité utilisées pour la surveillance peuvent être stockées dans le compte cloud du client lui-même. Le fournisseur explique pourquoi :

« Customers want the ability to have their data live in infrastructure they control, under their own encryption keys, access policies, and audit logging. »

Les clients veulent que leurs données vivent dans une infrastructure qu'ils contrôlent, sous leurs propres clés de chiffrement, leurs politiques d'accès et leur journalisation. Et l'examen est retiré du circuit du fournisseur :

« Those flags go directly to the customer and their people take it from there – no human review by Anthropic employees is required. »

Les signalements vont directement au client, et ses équipes prennent la suite : aucun examen humain par des salariés du fournisseur n'est requis.

Regardons ce que cela fait, sans applaudir ni dénoncer. La durée de conservation nécessaire à la détection n'a pas diminué d'une heure. Ce qui a changé, c'est qui détient les données pendant cette durée, sous quelles clés, et qui regarde les signalements. La contradiction n'est pas dissoute ; elle est transférée à celui qui, désormais, l'assume — et qui, désormais, doit savoir qu'il l'assume.

Ce que cela change, très concrètement, pour qui déploie

Si vous exploitez un système d'IA dans votre organisation, la question posée par ce texte n'est pas philosophique. Elle a une adresse.

Quelque part, sur la page de sécurité de votre fournisseur, dans son addendum de traitement des données ou dans sa documentation d'entreprise, il y a un paragraphe sur la conservation. Il dit une durée, ou il n'en dit aucune. Il dit ce qui est conservé pour la détection d'abus, ou il n'en parle pas. Il dit où ces données vivent, ou il laisse la question ouverte.

Le geste tient en dix minutes : ouvrir cette page et lire ce paragraphe. Il ne demande aucun outil, aucun budget, aucune réunion. Si c'est le premier fournisseur que vous passez au crible, nous avons détaillé ailleurs les questions à poser, dans l'ordre — quand on est trois et sans service juridique.

Nous n'avons aucun chiffre sur la proportion de ces paragraphes qui sont effectivement lus par la personne qui, dans l'organisation, répond aux questions des clients sur ce sujet — et nous nous garderons d'en inventer un. Ce que nous pouvons établir est plus étroit, et suffit : dans le cas cité ici, l'information est publique, datée, et sa vérification est gratuite. Le seul chiffre qui compte est celui que vous obtiendrez chez vous.

Ce que nous avions déjà écrit, et que nous ne refaisons pas

Le 2 août 2026, nous avons publié ici même l'analyse d'un scanner de sécurité publié sous licence Apache-2.0, dont les deux modes d'authentification ne relevaient pas du même contrat de données : entraînement sauf accord explicite d'un côté, entraînement sauf opposition de l'autre, selon le bouton choisi. Rien dans la licence ne le disait, et la documentation du produit n'en parlait pas.

Ce billet-ci porte sur le cas inverse, et c'est ce qui le rend intéressant. Là, l'information manquait et il fallait la reconstituer. Ici, elle est publiée, complète, en clair, sur une page ouverte à tous — et le risque n'est plus qu'elle soit dissimulée, mais qu'elle ne soit jamais ouverte.

Ce que nous ne disons pas

Nous ne disons pas que ce fournisseur fait mieux ou moins bien que les autres : nous n'avons pas mené d'étude comparative, et sans étude, une telle affirmation ne vaut rien.

Nous ne disons pas que ce dispositif serait conforme à quoi que ce soit. Cette qualification n'est pas la nôtre, et nous n'avons pas les éléments pour la porter.

Nous ne disons pas qu'il faudrait conserver moins, ni davantage. Les deux principes cités existent tous les deux, ils s'appliquent tous les deux, et l'arbitrage entre eux dépend d'un contexte que nous ne connaissons pas.

Ce que nous disons tient en une phrase : un fournisseur a écrit noir sur blanc une limite de son propre produit, à un endroit où il pouvait se taire. C'est une manière de faire, et elle mérite d'être remarquée pour ce qu'elle est — parce qu'elle est rare, et parce qu'elle donne à qui la lit de quoi décider en connaissance de cause.