Tu n’as pas à faire confiance à FlameP. Tu dois pouvoir le vérifier.

1. Le véritable problème réside dans l’asymétrie

Un système numérique peut aujourd’hui en savoir énormément sur son utilisateur.

L’utilisateur en sait étonnamment peu sur le système.

Il voit une interface. Il voit une réponse. Peut-être voit-il aussi le nom d’un modèle.

De nombreuses opérations techniques peuvent se dérouler en dessous. Des informations sont sélectionnées, complétées, stockées, envoyées à des systèmes externes, traitées sur place, puis réassemblées. Un autre modèle peut vérifier la première réponse. Un moteur de recherche peut fournir des sources. Un système de sécurité peut classifier des contenus. Un contexte personnel que l’utilisateur n’a pas du tout saisi dans cette conversation précise peut avoir été ajouté.

Le problème commence lorsque la personne ne voit plus que le résultat final et ne dispose plus d’aucun moyen raisonnable de comprendre comment il a été obtenu.

Même pour les exploitants de tels systèmes, disposer d’une vue d’ensemble complète ne va nullement de soi. Dans son AI Risk Management Framework, le National Institute of Standards and Technology américain souligne expressément que les systèmes d’IA peuvent se composer de nombreux éléments et acteurs interdépendants. Les responsables d’une partie du système n’ont donc souvent ni une visibilité complète sur les autres parties ni un contrôle total de celles-ci. NIST recommande notamment de documenter les responsabilités, d’assurer une gestion continue des risques, de surveiller les systèmes tiers utilisés et de garantir la traçabilité des décisions sur l’ensemble du cycle de vie. [1]

Si même l’organisation qui construit une application d’IA doit veiller activement à comprendre sa propre chaîne d’approvisionnement technique, il est franchement absurde d’exiger simplement de l’utilisateur qu’il lui fasse confiance.

2. La transparence n’est pas encore une preuve

Les entreprises, FlameP comprise, aiment répondre à ce problème par la transparence.

Nous expliquons quels providers nous utilisons.

Nous publions une politique de confidentialité.

Nous décrivons nos mesures de sécurité.

C’est nécessaire, mais insuffisant.

Une information sur ce qui est censé se produire en théorie est différente d’une preuve de ce qui s’est effectivement produit dans un cas concret.

Un exemple simple :

Une plateforme peut écrire qu’elle supprime les données à caractère personnel après un certain délai.

C’est une règle.

Une preuve serait autre chose. Elle devrait pouvoir montrer que la règle de suppression correspondante a effectivement été exécutée pour un jeu de données précis.

Il en va de même pour l’IA.

Idée directriceNous n’utilisons que le contexte nécessaire à ta tâche.

C’est une promesse.

Idée directricePour cette tâche précise, les domaines d’information A et B ont été utilisés, tandis que le domaine C est resté exclu.

C’est plus vérifiable.

Idée directriceNous travaillons avec plusieurs fournisseurs d’IA et choisissons le modèle approprié.

C’est une description du produit.

Idée directriceCette tâche a été traitée le 10 août avec le modèle X chez le Provider Y parce qu’elle relevait de cette catégorie de tâches.

C’est une preuve relative à une opération concrète.

C’est précisément cette distinction qui nous intéresse.

Le droit de la protection des données la connaît lui aussi. Le principe de responsabilité du RGPD n’exige pas seulement le respect des principes de protection des données. Les responsables du traitement doivent également pouvoir démontrer ce respect. Le Comité européen de la protection des données précise expressément que, dans la pratique, cela implique notamment de documenter les décisions et les processus relatifs à la protection des données. [2] [3]

C’est une attitude différente de « Fais-nous confiance, nous faisons les choses correctement ».

Elle consiste à dire : lorsqu’une affirmation est pertinente, nous devons être en mesure de présenter des éléments probants qui l’étayent.

3. La réglementation évolue déjà dans cette direction

L’AI Act européen reprend lui aussi cette idée pour certains systèmes d’IA.

Pour les systèmes d’IA à haut risque, le règlement exige notamment des moyens techniques permettant l’enregistrement automatique des événements. Ces systèmes doivent en outre être conçus avec une transparence suffisante pour permettre aux opérateurs d’interpréter et d’utiliser correctement leurs sorties. Les informations concernant les capacités, les limites de performance, l’usage prévu et, le cas échéant, les mécanismes d’analyse des journaux font également partie des exigences. Pour les systèmes à haut risque, l’AI Act exige en outre des dispositifs appropriés de contrôle humain. [4]

Nous ne devons pas en tirer la conclusion erronée que tous les produits d’IA sont soumis aux mêmes obligations. Ce n’est pas le cas. L’AI Act établit délibérément différentes catégories de risques et différentes exigences.

Le principe sous-jacent nous paraît donc plus intéressant que la qualification juridique.

Un système techniquement complexe ne devient pas plus digne de confiance parce que son fabricant assure qu’il l’est.

La fiabilité exige des structures, de la documentation, une journalisation, des responsabilités, des possibilités de contrôle et des limites connues.

Elle exige aussi la capacité de reconstituer ultérieurement les erreurs.

Le NIST AI Risk Management Framework traite précisément ces aspects comme des composantes d’une gouvernance continue. La documentation doit améliorer la transparence, faciliter l’examen humain et renforcer la responsabilité. Le cadre exige également de documenter et de réexaminer régulièrement les rôles, les risques, les composants externes, le contrôle humain et les limites du système. [1]

L’OECD va désormais encore plus loin. Sa Due Diligence Guidance for Responsible AI, publiée en 2026, associe les obligations classiques de diligence raisonnable des entreprises à la gouvernance de l’IA. Les entreprises doivent identifier les risques et les éventuelles incidences négatives, mettre en œuvre des mesures, suivre leurs résultats, communiquer à leur sujet et, le cas échéant, permettre une réparation. [6]

C’est le passage de l’affirmation à la vérifiabilité.

4. Mais que doit réellement vérifier une personne ordinaire ?

C’est ici que les choses se compliquent.

Après chaque session FlameP, nous pourrions présenter à l’utilisateur un rapport technique comprenant 300 entrées.

Horodatages, appels API, versions des modèles, nombres de tokens, valeurs de hachage, opérations de stockage, objets d’autorisation, événements réseau.

Ce serait transparent, mais inutile.

La transparence peut en effet elle-même servir de camouflage. Autrement dit : « Beat them with details. »

Celui qui submerge les gens d’une quantité suffisante d’informations peut ensuite prétendre avoir tout divulgué. Mais personne n’a rien compris.

Nous connaissons depuis longtemps ce schéma dans les conditions générales et les fenêtres de consentement aux cookies. Formellement, beaucoup de choses sont expliquées. Dans la pratique, la personne clique sur « Accepter » parce qu’elle ne souhaite pas investir une demi-journée de travail avant de pouvoir utiliser un site web.

Pour FlameP, la preuve avant la confiance ne signifie donc pas fournir le maximum d’informations.

Elle signifie assurer une vérifiabilité pertinente.

L’utilisateur n’a pas besoin de comprendre le fonctionnement mathématique d’un Transformer.

Dans le cadre d’une utilisation normale, il n’a pas non plus à vérifier l’intégralité de l’algorithme interne de routage.

Il devrait toutefois pouvoir obtenir des réponses à quelques questions très simples.

Que savait FlameP pour cette tâche ?

Où les informations ont-elles été envoyées ?

Que leur est-il arrivé ?

Qu’a décidé une machine ?

Qu’a décidé une personne ?

Qu’est-ce qui reste stocké ?

Et qu’est-ce qui est maintenant terminé ?

Selon nous, la véritable mission d’une bonne couche de transparence n’est pas de tout montrer. Pour nous, la transparence consiste à montrer ce qui importe.

5. Nous avons donc besoin de différents niveaux de preuve

Nous n’envisageons pas la vérifiabilité comme un unique et immense fichier journal.

Il faut au moins trois niveaux.

Le premier appartient à l’utilisateur.

Il doit être compréhensible.

Pour une tâche pertinente, une personne devrait par exemple pouvoir déterminer quel espace FlameP a été utilisé, quels domaines contextuels ont été autorisés, quel provider est intervenu et si le traitement est terminé.

Pas dans le langage des développeurs.

Mais à peu près ainsi :

Idée directriceContexte utilisé : projet FlameP et profil public de l’auteur.

Idée directriceNon utilisés : conversations personnelles, informations de santé, autres projets.

Idée directriceTraitement externe : Provider X, modèle Y.

Idée directriceStockage chez le provider : selon les conditions applicables à cette route.

Idée directriceStatut FlameP : tâche terminée, autorisations temporaires révoquées.

Ce n’est pas un audit complet.

C’est un reçu compréhensible.

Le deuxième niveau nous est nécessaire à nous-mêmes.

Il faut pouvoir y documenter avec bien plus de précision ce qui s’est produit sur le plan technique. Sans cela, nous ne pouvons ni étudier les erreurs, ni reconstituer les problèmes de sécurité, ni contrôler nos propres règles.

Le troisième niveau devient nécessaire lorsqu’un contrôle indépendant est pertinent ou obligatoire.

Les auditeurs, les autorités de contrôle ou d’autres organismes habilités peuvent avoir besoin de preuves plus approfondies qu’un utilisateur ordinaire n’a ni besoin ni vocation à voir.

Trois niveaux.

Compréhensibilité pour les personnes.

Reconstitution pour l’exploitant.

Vérifiabilité pour le contrôle indépendant.

6. Cela crée toutefois un nouveau problème

La journalisation peut elle-même se transformer en collecte de données.

C’est l’une de ces belles contradictions qui ont tendance à disparaître dans une présentation.

Nous voulons pouvoir prouver le mieux possible ce qui est arrivé aux données, alors nous journalisons le plus de choses possible. Et soudain, nous avons construit une nouvelle base de données qui consigne assez précisément ce qu’une personne a fait et à quel moment.

Ce serait absurde.

La preuve avant la confiance ne doit donc pas signifier que chaque opération est conservée éternellement sous une forme permettant d’identifier les personnes. Les preuves doivent elles aussi respecter la minimisation des données.

Le RGPD cite la minimisation des données, la limitation des finalités et la limitation de la conservation parmi ses principes fondamentaux. Les organisations ne doivent traiter les informations à caractère personnel que dans la mesure et pendant la durée nécessaires à la finalité concernée. [3]

Il en résulte pour FlameP un exercice d’équilibre technique exigeant.

Nous devons pouvoir prouver qu’une chose s’est produite sans conserver inutilement l’intégralité du contenu de ce qui s’est passé.

Il est parfois possible de journaliser un événement sans en stocker le contenu.

Il suffit parfois d’indiquer qu’un certain type de contexte était autorisé, sans copier l’intégralité du contexte dans le journal d’audit.

Une référence technique peut parfois prouver qu’une version donnée d’une Policy s’appliquait sans stocker de nouveau toutes les données des utilisateurs.

Et une preuve plus détaillée sera parfois nécessaire.

Cela ne peut pas être résolu par un simple interrupteur. C’est un travail d’architecture difficile.

7. Les réponses de l’IA rendent la tâche encore plus difficile

Supposons que FlameP indique clairement :

Ce modèle a été utilisé. Ces sources ont été consultées. Ce contexte était autorisé. Ces autorisations s’appliquaient.

Tout cela est très bien, mais nous n’avons évidemment pas prouvé pour autant que la réponse est correcte.

C’est une limite importante de notre principe. Pour de nombreux résultats d’IA, FlameP ne peut pas prouver qu’une affirmation est vraie. Un modèle de langage peut commettre une erreur malgré un processus rigoureux.

Deux modèles peuvent se tromper. Une source peut être obsolète. Une étude scientifique peut être réfutée ultérieurement. Une décision entrepreneuriale peut échouer malgré une excellente analyse.

La preuve avant la confiance ne doit donc pas devenir elle-même une illusion de sécurité absolue.

Dans de nombreux cas, nous pouvons rendre le processus plus vérifiable. Quelles sources ont été utilisées ? Quelle vérification a été effectuée ? Quelles incertitudes ont été détectées ? Un deuxième modèle a-t-il été utilisé ? Une personne a-t-elle validé le résultat ? Quelle version d’une information était disponible à ce moment-là ?

Le résultat demeure néanmoins une décision prise dans l’incertitude.

C’est précisément pourquoi NIST distingue également les différentes caractéristiques d’une IA digne de confiance. La transparence, l’explicabilité, la protection des données, la sécurité, la fiabilité et la responsabilité sont liées, mais aucune ne garantit à elle seule qu’un système agira correctement dans toutes les situations. [1]

Nous ne voulons donc pas remplacer « Fais confiance à l’IA » par un nouveau « Fais confiance à l’Audit-Log ».

La preuve ne remplace pas la réflexion, mais elle lui offre une meilleure base.

8. Les providers ne doivent pas non plus disparaître derrière FlameP

L’une des solutions les plus commodes lors de la création d’une plateforme Multi-Provider consisterait à rendre la complexité technique totalement invisible.

L’utilisateur parle à FlameP.

En arrière-plan, nous choisissons le modèle.

Et voilà. Ce serait agréable, mais cela aurait un prix.

FlameP deviendrait un nouveau point de confiance central. L’utilisateur ne dépendrait certes plus directement d’un fournisseur de modèles unique, mais il devrait croire qu’en arrière-plan, nous faisons toujours le bon choix.

Ce serait précisément la dépendance que nous souhaitons réduire.

C’est pourquoi la transparence concernant les providers fait partie, pour nous, de la preuve avant la confiance.

Cela ne signifie pas que quelqu’un doive commencer par prendre cinq décisions techniques à chaque demande simple. Un bon système peut organiser la complexité.

Mais les décisions pertinentes doivent rester reconstituables. Quel provider a été choisi ? Pourquoi cette route était-elle autorisée ? Quelle classe de données pouvait parvenir à ce provider ? Quelle version de la règle s’appliquait ? Existait-il une autre option ?

Une tâche particulièrement sensible a-t-elle été traitée différemment d’un brouillon de texte anodin ?

Outre la transparence et l’explicabilité, les OECD AI Principles mettent expressément l’accent sur la responsabilité et la traçabilité en tant qu’éléments d’une gouvernance responsable de l’IA. [5]

Pour nous, la traçabilité n’est pas un luxe technique.

Elle détermine si l’indépendance vis-à-vis des providers crée véritablement de l’indépendance ou seulement un nouvel intermédiaire opaque.

9. La preuve avant la confiance s’applique aussi à nous-mêmes

Jusqu’ici, on pourrait avoir l’impression que FlameP cherche principalement à prouver ce que d’autres providers font des données.

Si nous affirmons que le contexte personnel reste séparé, nos systèmes doivent effectivement imposer cette séparation.

Si nous affirmons qu’un espace FlameP n’a accès qu’à certaines informations, l’intégralité de l’historique personnel ne doit pas malgré tout être disponible en arrière-plan.

Lorsqu’une autorisation temporaire a pris fin, elle doit être techniquement révoquée.

Si nous affirmons qu’une tâche est terminée, les connexions temporaires créées à cette fin ne doivent pas simplement subsister indéfiniment.

Si nous disons qu’une opération donnée n’est pas stockée, nos propres journaux doivent respecter cette promesse.

Et si quelque chose ne fonctionne pas encore, nous ne devons pas écrire comme si cela fonctionnait déjà.

La vision du produit et la réalité du produit évoluent à des vitesses différentes. Un concept est adopté lors d’un workshop. L’interface utilisateur emploie déjà le nouveau langage. Mais une partie de l’implémentation technique manque encore dans le Backend.

L’entreprise commence à parler du produit qu’elle veut construire comme s’il s’agissait déjà de celui que les gens utilisent.

Capability avant Claim.

Ce que nous affirmons doit être réellement pris en charge par le système.

Et si ce n’est pas encore le cas, nous parlons de plan, d’objectif ou de développement. Pas de fonction.

10. Il en va de même pour l’impact social

Ce point relie directement la preuve avant la confiance à notre étoile polaire du flux de valeur.

Supposons que FlameP décide d’affecter 20.000 euros à un programme social.

Cela peut désigner au moins cinq choses différentes. Nous avons calculé que 20.000 euros seraient destinés à ce programme selon notre règle. Nous avons réservé cette somme en interne.

Nous nous sommes fermement engagés à l’accorder à un projet. Nous l’avons effectivement transférée.

Ou nous pouvons en outre prouver que l’argent est arrivé et a été employé aux fins décrites.

Ces cinq états ne sont pas identiques.

Dans la communication d’entreprise, ils sont volontiers confondus.

« 20.000 euros pour l’impact social. » Cela sonne merveilleusement bien. Mais ensuite, plus personne ne sait ce qui s’est réellement passé.

Nous voulons distinguer ces états, et certainement pas parce que la comptabilité est notre passe-temps favori.

Mais parce que l’impact social est particulièrement propice à l’auto-illusion bien intentionnée.

Il en va de même pour les applications.

Si nous écrivons que FlameP prend en charge une langue donnée, il faut préciser ce que signifie « prend en charge ».

Le système peut-il traduire quelques phrases ? Une personne de langue maternelle peut-elle véritablement travailler avec lui ? La qualité a-t-elle été vérifiée par des personnes parlant cette langue ? La saisie vocale fonctionne-t-elle ? Cela fonctionne-t-il uniquement dans une Demo ou dans le produit réel ?

11. Une transparence totale serait néanmoins une erreur

Il existe une conception romantique de la transparence : si tout était simplement ouvert, tout irait bien. Mais ce n’est pas vrai.

Un système de sécurité ne devrait pas publier chacune de ses règles de protection internes. Sinon, il fournirait directement un mode d’emploi aux attaquants potentiels.

Un utilisateur ne devrait pas pouvoir voir les données personnelles d’autres utilisateurs simplement parce que nous avons promis la transparence.

Les secrets d’affaires et la propriété intellectuelle ne disparaissent pas non plus parce qu’une entreprise souhaite agir de manière responsable.

Et certaines informations techniques sont non seulement incompréhensibles, mais aussi totalement dépourvues de pertinence pour la décision concrète. La preuve avant la confiance ne signifie donc pas une divulgation radicale.

Elle signifie une vérifiabilité proportionnée.

Que doit savoir ou pouvoir vérifier un acteur donné pour évaluer une affirmation pertinente ?

L’utilisateur a besoin d’une vue différente de celle d’un contrôleur de sécurité. Une autorité de protection des données a besoin d’une vue différente de celle d’un client. Un développeur a besoin d’autres informations qu’un auditeur.

C’est à juste titre que NIST travaille avec des rôles, des responsabilités documentées et différents processus de contrôle plutôt qu’avec une unique exigence universelle de transparence. [1]

12. Mais un point est essentiel : la confiance restera malgré tout nécessaire

On pourrait maintenant assez facilement retourner notre principe contre nous.

Si tout doit être prouvé, pourquoi faudrait-il encore faire confiance ? Parce qu’aucun système complexe ne fonctionne sans confiance. Aucune personne ordinaire ne lira le code source de tous les composants de FlameP. Personne n’inspectera personnellement les centres de données de chaque provider.

Même un auditeur indépendant ne contrôle que certains domaines à certains moments.

Les certifications peuvent être erronées. Les Logs peuvent être mal implémentés. Les lois peuvent être enfreintes. Les gens commettent des erreurs. Il y aura toujours une limite à ce qu’un utilisateur peut vérifier par lui-même. Notre objectif n’est donc pas d’abolir la confiance.

Notre objectif est de réduire le domaine dans lequel une confiance aveugle est nécessaire.

Aujourd’hui, beaucoup de choses fonctionnent selon ce principe : fais-nous d’abord confiance. Tu pourras peut-être vérifier plus tard si nous l’avons mérité. Nous voulons inverser l’ordre : nous présentons autant d’éléments probants pertinents qu’il est raisonnablement possible de le faire. La confiance peut alors en découler.

13. Cela modifie également la répartition du pouvoir

En définitive, la preuve avant la confiance n’est pas une question de détail technique.

Il s’agit de pouvoir.

Celui qui est seul à savoir ce qu’un système a fait dispose d’un avantage informationnel.

Celui qui peut décider seul quelles informations deviennent visibles contrôle le récit qui en est fait.

Et celui qui, à la fois, possède les données, détermine les règles et formule lui-même la preuve du respect de ces règles exige beaucoup de confiance.

Nous ne pourrons pas éliminer complètement cette asymétrie. FlameP exploite le système. Nous détenons donc inévitablement du pouvoir. La question pertinente n’est donc pas de savoir si le pouvoir existe. Pour nous, elle consiste à savoir comment construire des mécanismes qui le limitent.

La documentation limite le pouvoir. Des autorisations traçables limitent le pouvoir. La séparation des contextes limite le pouvoir. Un provider visible limite le pouvoir. Des contrôles indépendants peuvent limiter le pouvoir.

Et une culture d’entreprise dans laquelle une affirmation nécessite une preuve limite au moins la tentation de trop rapprocher la réalité du marketing.

L’OECD associe désormais elle aussi expressément l’IA responsable à un processus continu d’identification des risques, de prévention, de suivi, de communication et, le cas échéant, de réparation. [6]

14. Conclusion : notre ambition est simple. Sa mise en œuvre ne le sera pas.

Nous ignorons aujourd’hui dans quelle mesure nous réussirons dans chaque domaine. Certaines preuves seront techniquement relativement simples à fournir.

D’autres seront coûteuses. Nous pourrons présenter certaines informations de manière compréhensible.

Pour d’autres, nous constaterons que la transparence entre en conflit avec la protection des données.

Au début, nous journaliserons peut-être des éléments que nous devrons ensuite traiter autrement.

Les utilisateurs constateront peut-être que notre interface de transparence affiche les mauvaises informations.

Un contrôle externe nous signalera peut-être un angle mort que nous n’avions pas nous-mêmes détecté.

La preuve avant la confiance ne signifie pas que nous ne commettrons aucune erreur.

Elle signifie que notre système doit être conçu, autant que possible, de manière à rendre les erreurs visibles, reconstituables et corrigibles.

C’est une promesse plus modeste. Et plus exigeante.

Nous ne voulons pas dire :

Idée directriceFlameP est digne de confiance.

Ce serait une affirmation à notre propre sujet. Nous préférons dire :

Idée directriceVoici ce que FlameP a fait. Voici les règles pertinentes. Voici les limites. Et voici ce qui peut être vérifié.

Chacun peut ensuite décider lui-même du degré de confiance qui en découle. Nous estimons que c’est l’ordre le plus honnête.

Tu n’as pas à faire confiance à FlameP. Nous devons mériter cette confiance.

Et partout où cela est possible, notre parole ne devrait pas suffire.