Contenu qui ne peut être expédié sans preuve

Rasmus Kjær Damgaard, Fondateur · 7 septembre 2026

Cet article a été produit avec l'assistance de l'IA et revu par une personne. Rasmus Kjær Damgaard assume la responsabilité éditoriale du contenu.

TL;DR : Les promesses marketing s’éloignent souvent de la réalité, et personne ne s’en aperçoit avant qu’un auditeur ou un régulateur ne pointe le problème. Sur ce site, une phrase qui affirme un fait concernant le traitement des données, leur accessibilité, leur transfert transfrontalier ou l’impossibilité d’entraîner un modèle avec elles ne peut être publiée que si un prédicat vérifié par machine la soutient. Ce billet explique le mécanisme, présente trois affirmations que le système refuse actuellement de nous laisser publier, cite un cas réel qu’il a détecté, et précise ce qu’il ne peut pas prouver.

Le problème, c’est la dérive – et cette dérive est un risque juridique

Une affirmation sur le site d’un fournisseur est rédigée une fois, puis oubliée. Pourtant, les faits qu’elle décrit évoluent : un sous-traitant est ajouté, une région change, une certification expire. La phrase, elle, reste en place. Pendant des mois, la page affirme quelque chose que les propres registres de l’entreprise contredisent déjà, et cet écart passe inaperçu parce que les deux informations vivent dans des endroits différents, modifiées par des équipes distinctes.

Pour un vendeur européen, ce n’est pas seulement un problème de crédibilité. Selon la directive sur les pratiques commerciales déloyales (2005/29/CE), article 12, une autorité peut exiger qu’un professionnel prouve une affirmation factuelle et considérer l’absence de preuves suffisantes comme la preuve que cette affirmation est fausse. La charge de la preuve nous incombe, et aucune procédure judiciaire n’est nécessaire pour déclencher ce mécanisme. Le EU AI Act ajoute une obligation de transparence : l’article 50(1) impose d’informer une personne lorsqu’elle interagit avec un système d’IA. Une page qui exagère ce qu’une entreprise peut prouver correspond exactement au type de situation que ces règles visent à sanctionner.

Le mécanisme : affirmation, prédicat, registre, verrou

La conception est simple. Un registre associe chaque affirmation destinée aux clients à un prédicat, et ce prédicat est évalué à partir de faits que les rédacteurs ne peuvent pas modifier : le registre des sous-traitants et l’instantané de confiance, tous deux générés à partir du code source. Les prédicats sont définis par couche, car une expression comme « hébergé dans l’UE » recouvre plusieurs affirmations : le stockage, le chemin des requêtes et la télémétrie peuvent chacun avoir une réponse différente, et les confondre revient à transformer une vérité sur un aspect en un mensonge sur un autre.

Le verrou, bun run check:claims, impose alors quatre règles en une seule passe. Une affirmation dont le prédicat est faux ne doit pas apparaître dans le contenu, quelle que soit la langue. Toute phrase qui promet une localisation, une juridiction, un transfert ou une restriction d’entraînement doit être déclarée, afin d’éviter qu’une nouvelle affirmation absolue ne soit ajoutée en silence. Aucune de ces affirmations ne peut exister en dehors du catalogue de messages traduisibles, où elle échapperait à tous les autres contrôles. Enfin, une correction apportée en anglais ne doit pas rester active dans les 22 autres langues : le pipeline de traduction ne se relance que lorsqu’une personne l’exécute, donc une correction appliquée uniquement en anglais laisserait l’ancienne affirmation en place dans toutes les autres versions linguistiques. Ce dernier contrôle, le parity gate, est celui que la plupart des systèmes oublient.

La dernière pièce supprime entièrement l’étape de rédaction pour les emplacements les plus risqués. Plutôt que de rédiger manuellement une phrase sur la résidence des données dans une méta-description ou un manifeste en espérant qu’un relecteur la repère, ces emplacements utilisent un jeton qui se résout en un fragment dérivé du registre. Ce fragment ne s’affiche que si son prédicat est vérifié. Une phrase que le registre ne peut pas étayer n’a pas de fragment à insérer, donc elle ne peut pas être saisie. La détection repère une formulation à la fois ; la génération élimine toute une catégorie de risques.

Ce qu’il refuse

La meilleure façon de faire confiance à un verrou, c’est de le voir dire non. Trois affirmations sont aujourd’hui déclarées, mais le registre ne nous permet pas encore de les publier, et le verrou signale chaque blocage à chaque exécution :

• Une affirmation selon laquelle nos conditions interdisant aux fournisseurs de modèles d’entraîner leurs systèmes sur le contenu des clients sont contractuellement répercutées à tous les niveaux. Nous le souhaitons, mais le registre ne le prouve pas encore, donc elle reste non publiée.
• Une affirmation selon laquelle la plateforme satisfait déjà l’intégralité du EU AI Act. Le corpus enregistre un statut par obligation, et toutes ne sont pas encore remplies, donc la version totalisante est rejetée.
• Une affirmation sur la juridiction de la chaîne d’approvisionnement des modèles, qui nécessite un prédicat sur l’immatriculation des sociétés plutôt que sur le lieu d’exécution des requêtes, et qui n’est pas encore vérifiée.

Il ne s’agit pas d’oublis. Ce sont des affirmations que nous aimerions faire, mais que nous ne publions pas, car la rigueur prime sur la phrase.

Le système a aussi détecté un cas réel. Le 27 juillet 2026, le verrou a été déployé (commit 3b7a4bffd), et en moins de 24 heures, il a imposé une correction que le processus de relecture avait manquée : la bannière d’accueil affirmait une résidence des données sans qu’aucune preuve ne figure dans le registre (commit a8d94d4a3). Le parity check a ensuite exigé que la correction soit répercutée dans les 22 autres langues, et pas seulement en anglais. Les affirmations qui ont résisté sont les plus précises et vérifiables : l’inférence s’exécute en France, les embeddings à Berlin, les documents en Irlande et à Nuremberg, chacun étant présenté sur la page de confiance avec sa base juridique de transfert.

Ce qu’il ne peut pas prouver, expliqué clairement

Un verrou qui surestimerait ses capacités serait précisément ce qu’il cherche à éviter. Voici donc ses limites. Il prouve que chaque affirmation publiée correspond au registre. En revanche, il ne prouve pas que le registre décrit correctement la réalité, bien qu’un autre verrou maintienne le registre aligné sur le code. Il ne peut pas vérifier qu’un chiffre issu d’un benchmark est exact ou qu’un numéro d’article cité est le bon : ce sont des questions de jugement qu’une expression régulière ne peut pas trancher. Ce qu’il élimine, c’est l’échec spécifique et récurrent où une affirmation vraie au lancement devient discrètement fausse, sans que personne ne surveille le fichier. Garantir que l’affirmation est correcte dès le départ reste une responsabilité humaine.

Comment faire de même

Le modèle est reproductible, et aucun de ses composants n’est exotique. Maintenez un registre lisible par machine des faits sur lesquels reposent vos affirmations, généré à partir du code source plutôt que tenu à jour manuellement. Associez chaque affirmation à un prédicat que le registre peut réfuter, avec une portée suffisamment étroite pour qu’une vérité sur un sous-système ne puisse pas en masquer une autre. Exécutez un verrou pré-commit qui évalue chaque affirmation dans toutes les langues que vous livrez, et laissez un prédicat faux faire échouer la construction. Enfin, pour les emplacements où une affirmation absolue erronée causerait le plus de dégâts, générez le texte à partir du registre plutôt que de le saisir manuellement.

Le résultat n’est pas un contenu plus tapageur. C’est un contenu qu’un lecteur méfiant peut vérifier, et pour un acheteur européen évaluant un fournisseur de solutions de sécurité, c’est le seul type de contenu qui convertit.