Atelier — Lire un dossier de conformité comme un article scientifique
Un dossier de conformité GPAI ressemble de plus en plus à une publication scientifique.
On y trouve un résumé exécutif, des annexes techniques, une déclaration de limites, des références juridiques, parfois même des éléments de méthodologie proches d’un protocole expérimental : tests de sécurité, red teaming, évaluation des risques, documentation du modèle, politique de respect du droit d’auteur.
Le piège est donc le même que face à un article scientifique : s’arrêter au résumé.
Dans le monde académique, cela revient à lire seulement l’abstract et à conclure que l’étude est solide. Dans le monde de l’intelligence artificielle, cela revient à lire une formule comme « conforme à l’AI Act » ou « signataire du Code GPAI » et à considérer que le problème est réglé.
Or une preuve ne se juge pas à son slogan. Elle se juge à sa méthode, à ses données, à ses limites et à sa capacité à être contestée.
Cet atelier transpose le fondamental « Lire un article scientifique », lié à l’étape 6 du Sentier du Savoir, à un objet d’actualité : le Code of Practice GPAI, la conformité des modèles d’IA à usage général et le compte à rebours avant le 2 août 2026.
L’enjeu n’est pas de devenir juriste spécialisé en intelligence artificielle. Il est d’apprendre à poser les bonnes questions avant de croire une déclaration de conformité.
Pourquoi le sujet devient décisif en 2026
Le règlement européen sur l’intelligence artificielle distingue les systèmes d’IA et les modèles d’IA à usage général, appelés GPAI pour General-Purpose AI. Ces modèles peuvent être intégrés dans de nombreux outils : assistants conversationnels, moteurs de recherche, outils bureautiques, solutions de code, plateformes éducatives, agents automatisés.
Depuis le 2 août 2025, les fournisseurs de modèles GPAI doivent respecter certaines obligations prévues par l’AI Act. Pour les modèles les plus avancés, considérés comme susceptibles de présenter un risque systémique, les exigences sont plus fortes : évaluation des risques, documentation, suivi des incidents graves, cybersécurité, mesures de réduction des risques.
Le Code of Practice GPAI, publié par la Commission européenne, est présenté comme un outil volontaire permettant aux fournisseurs de démontrer plus facilement leur conformité. Il comporte trois grands chapitres : transparence, droit d’auteur, sûreté et sécurité.
Mais volontaire ne veut pas dire secondaire. Pour un fournisseur, signer le Code peut faciliter la démonstration de conformité. Pour un acheteur, une institution ou une organisation qui utilise ces modèles, cette signature devient un indice utile.
Un indice, pas une preuve définitive.
Le 2 août 2026 marque une étape importante : les pouvoirs de supervision et d’exécution de la Commission européenne concernant les fournisseurs de modèles GPAI entrent en application. Autrement dit, la question ne sera plus seulement : « Le fournisseur affirme-t-il être prêt ? » Elle deviendra : « Peut-il le démontrer avec des pièces vérifiables ? »
Mini-cas : deux sources, deux niveaux de preuve
Pour comprendre la méthode, prenons deux types de sources.
La première est institutionnelle : la page de la Commission européenne consacrée au General-Purpose AI Code of Practice. Elle explique que le Code est un outil volontaire, qu’il a été élaboré avec des experts indépendants dans un processus multi-acteurs, qu’il couvre les obligations des fournisseurs de modèles GPAI et qu’il peut aider les signataires à démontrer leur conformité.
Elle indique aussi que les fournisseurs peuvent signer le Code au moyen d’un formulaire transmis à l’AI Office, et qu’une Signatory Taskforce a été mise en place pour favoriser une application cohérente du Code.
Ce que cette source permet d’établir : le cadre officiel, la logique du Code, ses chapitres, le processus de signature, le rôle de l’AI Office.
Ce qu’elle ne permet pas d’établir à elle seule : que chaque signataire a publié toutes les annexes utiles, que chaque modèle utilisé par une organisation est couvert de manière claire, ou qu’une signature suffit à protéger automatiquement un acheteur, une administration ou une entreprise.
La deuxième source est explicative : l’AI Act Consortium, qui propose une lecture commentée du Code et de l’AI Act. Ce type de source aide à comprendre la chronologie, les obligations, les différences entre signataires et non-signataires, ou encore la période qui précède les standards harmonisés.
Ce que cette source apporte : une mise en contexte, une pédagogie juridique, une synthèse utile des effets pratiques du Code.
Ce qu’elle ne remplace pas : l’audit concret du dossier d’un fournisseur.
La leçon méthodologique est simple : une source officielle donne le cadre ; une source commentée aide à l’interpréter ; mais aucune des deux ne remplace l’examen des preuves fournies par le fournisseur lui-même.
Étape 1 — Formuler une question testable
La première erreur consiste à poser une question trop générale.
« Le modèle est-il sûr ? »
Cette question paraît importante, mais elle est trop vague. Elle ne permet pas de décider quelles preuves chercher.
Une question testable serait plutôt :
« Ce fournisseur a-t-il publié une évaluation de risque systémique datée, avec une méthodologie explicite, des scénarios de test, des limites reconnues et des mesures de réduction des risques ? »
Même chose pour la conformité.
Dire « ce fournisseur est-il conforme ? » reste trop large.
Une question plus opératoire serait :
« Quelles obligations des articles 53 à 55 de l’AI Act sont couvertes par le Code signé, et quelles obligations sont couvertes par d’autres mesures documentées ? »
Dans un contexte d’achat public, de déploiement éducatif ou d’usage professionnel, la question devient encore plus concrète :
« Avons-nous en main les pièces exigées par notre cahier des charges, ou seulement une déclaration générale de conformité ? »
C’est la différence entre une croyance et une vérification.
Étape 2 — Identifier le type de document
Lire un dossier GPAI suppose de comprendre à quoi correspond chaque partie du document.
Dans un article scientifique, l’abstract donne le résumé, la méthode explique le protocole, les résultats présentent les observations, la discussion expose les limites, et les références permettent de vérifier l’ancrage théorique.
Dans un dossier GPAI, on peut retrouver une logique comparable.
La fiche de transparence joue le rôle du résumé exécutif.
La méthodologie de red teaming, d’évaluation des risques ou de test de sécurité joue le rôle de la méthode.
Les résultats d’évaluation, les incidents signalés, les métriques de performance ou les taux d’échec documentés jouent le rôle des résultats.
L’analyse des limites, les risques résiduels, les incertitudes et les plans de mitigation jouent le rôle de la discussion.
Les renvois à l’AI Act, au Code of Practice, aux politiques de droit d’auteur et aux documents techniques jouent le rôle des références.
Si le fournisseur ne livre qu’une présentation générale du type « AI Act ready », sans méthode ni résultats, le dossier doit être traité comme un communiqué, non comme une preuve.
Un article scientifique sans protocole ne permet pas de vérifier l’expérience. Un dossier de conformité sans méthode ne permet pas de vérifier la conformité.
Étape 3 — Vérifier la reproductibilité
Dans les sciences expérimentales, une affirmation gagne en solidité lorsqu’une autre équipe peut comprendre comment le résultat a été obtenu.
En matière de GPAI, la reproductibilité est forcément partielle. Les poids des modèles, les données d’entraînement exactes ou certains protocoles internes ne sont pas toujours publics. Mais cela ne signifie pas que tout doit rester opaque.
On peut au minimum demander :
la version précise du modèle évalué ;
la date de l’évaluation ;
le périmètre des tests ;
les langues couvertes ;
les modalités testées, par exemple texte, image, audio ou code ;
les cas d’usage exclus ;
les indicateurs chiffrés utilisés ;
les limites reconnues ;
le contact réglementaire pour les demandes d’information.
Un dossier sérieux doit permettre de savoir ce qui a été testé, quand, comment, avec quels critères et dans quelles limites.
L’enjeu n’est pas d’obtenir tous les secrets industriels. L’enjeu est d’éviter une transparence purement déclarative.
Un acheteur ou un utilisateur professionnel peut donc comparer plusieurs fournisseurs : les champs sont-ils homogènes ? Les métriques sont-elles comparables ? Les risques sont-ils décrits avec précision ? Ou chaque fournisseur redéfinit-il ses propres catégories de manière à rendre toute comparaison impossible ?
La reproductibilité n’est pas seulement une exigence scientifique. C’est une exigence de gouvernance.
Étape 4 — Tester la falsifiabilité
Le philosophe Karl Popper a proposé un critère célèbre : une hypothèse scientifique doit pouvoir être réfutée. Autrement dit, elle doit s’exposer à la possibilité d’être contredite par des faits.
Cette idée peut être transposée à la conformité GPAI.
Une affirmation comme « notre modèle ne présente pas de risque systémique » n’est utile que si l’on sait ce qui pourrait la contredire.
Un incident documenté de cybersécurité, une capacité dangereuse non anticipée, une campagne de désinformation facilitée par le modèle ou une manipulation massive pourraient affaiblir cette affirmation.
Une affirmation comme « nous respectons le droit d’auteur » doit aussi pouvoir être confrontée à des éléments externes : politique d’exclusion, résumé des contenus d’entraînement, procédures de retrait, contentieux, décisions de justice, plaintes d’ayants droit.
Une affirmation comme « nous sommes transparents » peut être testée par une question simple : le fournisseur répond-il clairement aux demandes d’information légitimes ? Fournit-il les documents attendus ? Explique-t-il les limites de ses réponses ?
Si une déclaration ne peut jamais être contredite, elle relève davantage de la communication que de la preuve.
Pour un fournisseur non signataire, ou signataire seulement sur une partie du Code, l’exigence est encore plus forte : il faut identifier quelles preuves alternatives couvrent les chapitres non signés.
Sans cela, la conformité reste difficilement vérifiable.
Étape 5 — Lire les limites déclarées
Un bon article scientifique n’est pas celui qui prétend tout démontrer. C’est celui qui sait dire ce qu’il ne démontre pas.
La section « discussion » d’un article est souvent la plus importante : elle expose les limites de l’échantillon, les biais possibles, les incertitudes, les résultats à confirmer.
Un bon dossier GPAI devrait faire la même chose.
Il devrait dire ce qui n’est pas publié, et pourquoi.
Il devrait préciser les zones d’incertitude : données d’entraînement non détaillées, tests encore incomplets, risques difficiles à mesurer, dépendance à des sous-traitants, limites dans certaines langues ou certains contextes d’usage.
Il devrait distinguer ce qui est prouvé, ce qui est probable, ce qui reste à surveiller.
Si un dossier ne contient aucune limite, il faut se méfier. L’absence de limites n’est pas nécessairement le signe d’un modèle parfait. C’est souvent le signe d’un document trop orienté vers la communication.
C’est ici que le dilemme de Collingridge devient utile : lorsqu’une technologie est encore jeune, il est difficile d’en mesurer tous les effets ; lorsqu’elle est largement diffusée, il devient plus difficile de la corriger. Réguler tôt expose à l’incertitude. Réguler tard expose à l’irréversibilité.
Le Code GPAI tente précisément de se situer dans cet entre-deux : obtenir assez d’informations pour agir avant que les risques ne deviennent incontrôlables.
Étape 6 — Croiser avec une source indépendante
Une preuve isolée reste fragile.
Comme dans la lecture scientifique, il faut croiser.
Pour un dossier GPAI, cela signifie comparer :
la liste officielle des signataires publiée par la Commission européenne ;
les questions-réponses de la Commission sur la signature du Code ;
les lignes directrices de l’AI Office ;
les analyses juridiques indépendantes ;
les rapports d’ONG spécialisées ;
les incidents publics documentés ;
les décisions de justice éventuelles ;
les communications du fournisseur.
Si un fournisseur annonce être signataire du Code, la première vérification consiste à consulter la source officielle. S’il n’apparaît pas dans la liste publique, il faut demander la date de signature, le périmètre exact de l’engagement et les documents transmis à l’AI Office.
La Commission indique que les fournisseurs peuvent envoyer le formulaire signé à l’adresse dédiée de l’AI Office. Cette information est utile, mais elle ne suffit pas : ce qui compte ensuite, c’est le périmètre de la signature et les preuves associées.
Autrement dit : signer est un signal. Documenter est une preuve. Accepter l’examen est un test.
Tableau de décision : du dossier à l’usage
Avant d’acheter, d’intégrer ou de recommander un modèle GPAI, une organisation peut appliquer cette grille simple.
Question 1 : la question testable est-elle formulée ?
Si non, il faut reporter la décision ou préciser le besoin.
Question 2 : le dossier contient-il une méthodologie et des résultats ?
Si non, il faut demander un complément.
Question 3 : les versions, les dates et le périmètre des tests sont-ils clairs ?
Si non, il faut refuser les formulations générales du type « conforme AI Act » sans preuve associée.
Question 4 : les scénarios pouvant contredire la déclaration sont-ils identifiés ?
Si non, il faut prévoir une veille, une clause de révision ou une clause de résiliation.
Question 5 : les limites sont-elles explicites ?
Si non, il faut traiter le dossier comme incomplet.
Question 6 : les informations sont-elles croisées avec au moins une source indépendante ?
Si non, il ne faut pas communiquer en interne que l’organisation est « couverte ».
Cette grille ne donne pas une réponse automatique. Elle donne mieux : une discipline de lecture.
Exercice pratique — 20 minutes pour tester un fournisseur
Choisissez un fournisseur que vous utilisez déjà ou que vous envisagez d’utiliser.
Ouvrez la liste officielle des signataires du Code GPAI.
Vérifiez si le fournisseur y figure.
Cherchez sa fiche de transparence, sa documentation modèle ou son rapport de sécurité le plus récent.
Remplissez deux colonnes : méthode et résultats.
Dans la colonne méthode, notez ce qui est réellement expliqué : protocole, périmètre, version, date, tests, langues, cas d’usage.
Dans la colonne résultats, notez ce qui est réellement mesuré : incidents, taux d’échec, limites, risques identifiés, mesures de réduction.
Ajoutez ensuite deux lignes.
Première ligne : une limite que le fournisseur reconnaît clairement.
Deuxième ligne : une limite qu’il semble esquiver.
Enfin, formulez une conclusion en une phrase :
« À ce stade, ce dossier permet / ne permet pas de justifier un usage responsable, parce que… »
L’objectif n’est pas de condamner ou de valider trop vite. L’objectif est de transformer une impression de conformité en lecture critique.
Ce que signer ne fait pas
Signer le Code GPAI ne signifie pas que tout est réglé.
La signature ne remplace pas l’analyse du modèle utilisé.
Elle ne garantit pas que tous les documents utiles sont publics.
Elle ne supprime pas le besoin d’un audit interne.
Elle ne dispense pas l’utilisateur professionnel de réfléchir à ses propres cas d’usage.
Elle ne protège pas automatiquement contre les risques liés au droit d’auteur, à la sécurité, aux biais, aux hallucinations ou aux usages détournés.
Elle ne transforme pas une technologie incertaine en technologie parfaitement maîtrisée.
En revanche, elle peut créer un cadre commun de comparaison. Elle peut faciliter la coopération avec l’AI Office. Elle peut rendre les engagements plus lisibles. Elle peut aider les organisations à distinguer les fournisseurs qui documentent leurs pratiques de ceux qui se contentent d’une communication générale.
C’est déjà beaucoup, à condition de ne pas confondre le cadre avec la preuve.
Pourquoi cet atelier relève du Sentier du Savoir
Cet atelier n’est pas seulement un exercice juridique. C’est un exercice d’érudition appliquée.
Lire un article scientifique, ce n’est pas se laisser impressionner par son titre, son institution ou son résumé. C’est examiner la question posée, la méthode utilisée, les résultats obtenus, les limites reconnues et les sources mobilisées.
Lire un dossier GPAI demande la même posture.
Dans les deux cas, il faut ralentir.
Ne pas croire trop vite.
Ne pas rejeter trop vite non plus.
Identifier ce qui est établi, ce qui est probable, ce qui reste flou, ce qui manque.
C’est exactement l’esprit du Sentier du Savoir : former des lecteurs capables de traverser les discours techniques sans se laisser capturer par eux.
Conclusion : vérifier avant de croire
Le Code of Practice GPAI n’est pas une fin de l’effort critique. C’est un format de comparaison.
Il permet de structurer les engagements des fournisseurs, d’identifier les obligations importantes et de préparer l’entrée dans une phase plus exigeante de supervision européenne. Mais il ne dispense pas de lire les pièces.
À l’approche du 2 août 2026, deux erreurs symétriques menacent le débat public.
La première serait la panique : croire que tout devient interdit, que l’innovation est bloquée, que l’Europe étouffe l’intelligence artificielle.
La seconde serait la confiance aveugle : croire qu’une signature suffit, qu’un logo de conformité règle tout, qu’un fournisseur reconnu n’a plus besoin d’être interrogé.
Entre ces deux erreurs, il existe une voie plus exigeante : demander des preuves, lire les méthodes, repérer les limites, croiser les sources.
Vérifier avant de croire : c’est l’esprit de l’étape 6 du Sentier du Savoir.
Et c’est peut-être l’une des compétences civiques les plus importantes à l’heure où les technologies prétendent penser avec nous.
Repères de sources
Commission européenne — The General-Purpose AI Code of Practice
Commission européenne — Signing the General-Purpose AI Code of Practice
Commission européenne — Guidelines for providers of general-purpose AI models
AI Act Consortium — Introduction to the Code of Practice for General-Purpose AI
AI Act Consortium — Enforcement of Chapter V under the EU AI Act
David Collingridge — The Social Control of Technology, 1980
Karl Popper — La logique de la découverte scientifique
Dans ce triptyque
Pour relier cet atelier à ses deux autres dimensions :
Revenir à l’actualité : Code of Practice GPAI : l’Europe entre signature volontaire et compte à rebours du 2 août 2026
Approfondir avec le texte fondateur : David Collingridge : réguler tôt ou tard — le dilemme du Code GPAI
Repères de sources
- Commission européenne : General-Purpose AI Code of Practice
- Commission, Q&A signature : Signing the Code
- AI Act Consortium : Introduction to the Code of Practice
- David Collingridge, *The Social Control of Technology* (1980) — voir le TF de ce triptyque
Dans ce triptyque
Pour relier cette mise en perspective à ses deux autres dimensions :
- Revenir à l’actualité : Code of Practice GPAI : l’Europe entre signature volontaire et compte à rebours du 2 août 2026
- Approfondir avec le texte fondateur : David Collingridge : réguler tôt ou tard — le dilemme du Code GPAI
Vous devez être connecter pour pouvoir voter
