Le Code de bonnes pratiques (CoP) de l'Union européenne pour l'intelligence artificielle (IA) à usage général est un cadre volontaire développé pour soutenir la mise en œuvre des dispositions du règlement européen sur l'IA concernant les modèles d'IA présentant des risques systémiques. Ce code aidera les entreprises à comprendre, et à démontrer le respect de leurs obligations en matière d'évaluation des risques, de tests de sécurité et de transparence, en attendant que les normes techniques formelles soient finalisées.
Publiée le 11 mars 2025, la troisième version du CoP représente une avancée significative après des mois de consultation entre les représentants de l'industrie, les organisations de la société civile dont le CeSIA, et des experts techniques. Le Bureau européen de l'IA recueille actuellement les derniers commentaires des parties prenantes avant la publication officielle du CoP en mai 2025, après quoi le texte exercera une influence directe sur les pratiques de développement et de déploiement des systèmes d'IA avancés.
L'analyse du CeSIA a identifié six domaines nécessitant des améliorations pour garantir que le CoP contribue à assurer une protection efficace contre les risques liés aux modèles d'IA avancés. Tout en reconnaissant les points forts de cette troisième version, nous estimons que l'amélioration de ces aspects spécifiques est cruciale pour arriver à un cadre robuste qui équilibre promotion de l'innovation et garanties nécessaires de sécurité.
Contexte — Plusieurs parties prenantes, y compris les négociateurs du règlement sur l’IA, ont exprimé leur inquiétude quant à la concentration exclusive sur les « capacités à fort impact », reléguant la protection des droits fondamentaux au rang de considérations secondaires. Ce choix affaiblit l'objectif même du cadre réglementaire. La position adoptée par certains États membres, dont la France, qui ont qualifié le règlement sur l’IA de trop contraignant après son adoption, est particulièrement préoccupante. Nous sommes convaincus que le Code de bonnes pratiques devrait compléter et renforcer la mise en œuvre de l’AI Act, et non constituer une voie détournée pour en affaiblir les dispositions. Le Bureau européen de l’IA est supposé faciliter l’élaboration de ce code en faisant en sorte qu’il intègre des perspectives variées, en particulier celles des organisations de la société civile et les fournisseurs industriels.
Lorsque le secteur privé prétend que la mise en œuvre de la réglementation serait trop lourde ou menace de se retirer du marché, il convient de considérer ces affirmations comme une stratégie de négociation plutôt que comme des arguments de fond. La priorité doit rester la mise en place de protections effectives.
Recommandations — Le Considérant 115 du règlement sur l’IA prévoit que les codes devraient inclure des obligations applicables à tous les modèles d’intelligence artificielle à usage général, en accordant une attention particulière à ceux présentant des risques systémiques. Pour ces modèles, les codes devraient contribuer à l’élaboration d’une taxonomie des risques au niveau de l’Union. Nous estimons que la taxonomie des risques systémiques présentée dans l’annexe 1 doit obligatoirement intégrer les impacts sur les droits fondamentaux comme des considérations centrales et non optionnelles.
Contexte — L’évaluation par des tiers est fondamentale dans les industries à haut risque car elle apporte une indépendance et des connaissances spécialisées que les équipes internes ne peuvent pas fournir. Bien que le Code de de bonnes pratiques exige une évaluation externe avant le déploiement de modèles à usage général sur le marché, la Mesure II.11.1 crée des exceptions contestables. Les entreprises peuvent éviter tout examen indépendant simplement en affirmant qu'elles disposent de l'expertise nécessaire pour déterminer que leur modèle ne produit pas de nouveaux risques vis-à-vis de systèmes existants, ou bien qu'elles n'ont pas pu trouver d'évaluateurs compétents. Ce dispositif transforme l'évaluation indépendante en une formalité optionnelle laissée à la discrétion du fournisseur et lui permet d’évaluer lui-même sa conformité aux normes de sécurité — une pratique n’ayant pas cours dans les autres industries à risques. Lorsque les fournisseurs d’IA affirment que l'expertise interne est suffisante, le projet n'exige aucune preuve standardisée de cette expertise ni validation indépendante de leurs capacités. De même, lorsque les entreprises affirment qu'elles n'ont pas pu trouver d'évaluateurs qualifiés, la disposition très vague les incitant à démontrer leurs "meilleurs efforts" est peu contraignante.
Les fournisseurs sont placés en position de juges et parties. Les incitations commerciales, les délais de développement et la pression des investisseurs créent de puissantes incitations à sous-estimer ou minimiser les risques potentiels. L’objectivité d’évaluateurs externes est indispensable.
Recommandations — Nous recommandons trois modifications du Code pour renforcer ces dispositions. Premièrement, la Mesure II.11.1 doit être modifiée pour indiquer explicitement que les quatre critères de "sécurité similaire" doivent être satisfaits simultanément, et non traités comme des régimes d'exception alternatifs. Deuxièmement, le Code doit exiger une documentation bien plus détaillée dans les rapports de sécurité et de sûreté transmis au Bureau européen de l’IA lorsque les fournisseurs revendiquent des régimes d’exception, de sorte à permettre au Bureau d'évaluer correctement les demandes des fournisseurs plutôt que de les accepter sans vérification. Troisièmement, il convient de prolonger le délai minimal de sélection des évaluateurs par appel d’offres de deux semaines à six semaines pour garantir un délai suffisant aux experts indépendants pour postuler. Ces ajustements conserveraient une certaine flexibilité tout en limitant les échappatoires qui fragilisent le cadre d'évaluation des modèles.
Contexte – Lorsque les systèmes d'IA présentent des risques graves, impossibles à atténuer et inacceptables, des protocoles clairs pour la suppression sécurisée des modèles deviennent essentiels. La Mesure II.7.6 contient l’unique référence du Code à la suppression des poids du modèle. Elle indique : "Les signataires doivent s'assurer que les mesures de sécurité [...] s'appliquent tout au long du cycle de vie du modèle, depuis la période précédant l'entraînement jusqu'à la suppression sécurisée ou la décision de publier les poids du modèle ou les ressources associées." Cela crée une faille : les entreprises peuvent simplement décider de publier les poids du modèle plutôt que de les supprimer.
Dans un scénario où une entreprise découvre que son système d'IA pose des risques systémiques importants qui ne peuvent être évités par des mesures d'atténuation adéquates, la suppression sécurisée du modèle sous-jacent serait l'action la plus responsable, mais la version actuelle n'exige pas spécifiquement cette étape. La formulation actuelle tend à inciter les entreprises à publier les paramètres des modèles dangereux plutôt que de les supprimer.Lorsqu'ils détaillent les actions requises en réponse aux risques systémiques impossibles à atténuer, l'Engagement II.5 et la Mesure II.5.2 omettent tous deux la suppression des poids du modèle. Cette omission présente un risque : les modèles retirés du marché restant sur les serveurs de l'entreprise, ils sont susceptibles d'être volés et utilisés à mauvais escient. Seule une suppression complète offre une protection définitive.
Recommandations – Nous recommandons de renforcer le Code pour rendre obligatoire la suppression sécurisée des poids du modèle lorsque celui-ci présente des risques graves et impossibles à atténuer. La formulation de la Mesure II.7.6 qui présente la publication de modèles dangereux comme une alternative équivalente à la suppression sécurisée devrait être supprimée ou significativement modifiée. La suppression du modèle devrait a minima être mentionnée comme option de remédiation dans les sections traitant de la gestion des risques (Engagements II.5, II.6 et II.12), avec un cadre clair pour garantir une mise en œuvre et une vérification appropriées. Ces améliorations garantiraient que les entreprises disposent d'orientations et d’incitations claires à prendre des mesures décisives lorsque les modèles d'IA présentent des risques inacceptables pour la sécurité publique et les droits fondamentaux.
Contexte – Le CoP n’établit aucun protocole clair pour la réévaluation périodique des modèles. La Mesure II.4.14 sur la surveillance post-commercialisation demande aux Signataires de "conduire une surveillance post-commercialisation pour recueillir les informations nécessaires", sans imposer d’évaluations selon des normes et méthodes de sécurité éventuellement apparues depuis la mise sur le marché du modèle. Cette formulation vague remplace l’exigence de réévaluation périodique plus stricte de la version précédente du Code.
Prenons une entreprise qui déploie un modèle en 2025 qui passe toutes les évaluations de sécurité de l’état de l’art. D'ici à 2026, les chercheurs développeront des techniques de jailbreaking et des méthodes d'évaluation améliorées de nature à exposer des vulnérabilités critiques dans des modèles déjà testés. Selon la version actuelle du Code, les entreprises n'ont aucune obligation de tester leurs modèles déployés selon ces nouveaux critères, laissant potentiellement des vulnérabilités non traitées tandis que le modèle reste activement utilisé. Cette omission crée un angle mort dans le cadre de gestion des risques. La compréhension des risques liés à l'IA évoluera inévitablement, mais les modèles plus anciens et toujours activement déployés n’auront pas à être réévalués. Un fournisseur d'IA serait incité à continuer d'utiliser un modèle précédemment déployé plutôt que d'en déployer un nouveau, plus sûr, évalué selon des critères de pointe.
Recommandations – Pour combler cette lacune dans la surveillance de la sécurité post-déploiement, le Code devrait renforcer la Mesure II.4.14. Nous recommandons de modifier la mesure pour inclure des tests périodiques obligatoires selon les nouvelles normes et méthodes de sécurité de pointe, avec des calendriers clairs et des mécanismes de responsabilité.
Cela devrait inclure : une réévaluation trimestrielle des modèles déployés selon les nouveaux critères et méthodes ; la transmission des résultats de réévaluation aux autorités de surveillance ; une stratégie d'atténuation des risques immédiate lorsque de nouvelles vulnérabilités sont découvertes ; et des seuils clairs pour déterminer quand les résultats de nouvelles méthodes d'évaluation devraient déclencher des mises à jour ou le retrait du modèle. Ce cadre pourrait s’inspirer des exigences de surveillance post-commercialisation (PMS) pharmaceutique, où les médicaments font l'objet d'une surveillance continue de sécurité, quelle que soit leur durée d’existence sur le marché. De plus, le CoP devrait exiger de documenter ces réévaluations et de signaler les nouvelles découvertes significatives au Bureau de l'IA, créant une responsabilité pour traiter les risques nouvellement découverts dans les systèmes déployés.
Contexte – La protection efficace des lanceurs d'alerte joue un rôle crucial dans l'identification des risques potentiels avant qu'ils ne causent des dommages. Mais le CoP n'inclut qu'une seule phrase sur cette question. Fait remarquable, le projet de texte indique explicitement qu’ "Aucune mesure n'est définie pour l'Engagement II.13", ne fournissant essentiellement aucune orientation de mise en œuvre.
Il s’agit d’un recul par rapport aux versions précédentes qui contenaient des protections concrètes pour les lanceurs d'alerte. La justification selon laquelle des protections détaillées pourraient "introduire une ambiguïté juridique en raison du risque de divergence avec la Directive 2019/1937" crée en réalité un manque de protection dommageable.
Le développement de l'IA présente des défis uniques et bénéficierait d’une protection renforcée des lanceurs d’alerte. La Directive reste un acte contraignant dans toute l'UE, mais le rôle du CoP devrait être de fournir des orientations de mise en œuvre spécifiques au secteur. De telles orientations ne créeraient pas d'ambiguïté juridique mais rendraient les exigences légales existantes plus facilement applicables aux défis particuliers de la gouvernance de l'IA. A minima, le Code devrait reconnaître explicitement que la Directive (UE) 2019/1937 s'applique pleinement aux fournisseurs d'IA et que des protections robustes pour les lanceurs d'alerte sont essentielles pour respecter l'intention du règlement européen.
Recommandations – Nous recommandons de renforcer l'Engagement II.13 en rappelant explicitement que la Directive (UE) 2019/1937 s'applique pleinement aux fournisseurs d'IA et en ajoutant des lignes directrices de mise en œuvre pour la protection des lanceurs d'alerte dans le contexte de l'IA. Le Code peut explicitement interdire les représailles contre les lanceurs d'alerte qui signalent des violations potentielles du règlement sur l'IA ou des préoccupations concernant les risques systémiques via des canaux de signalement anonymes pour les employés, les contractants et le personnel temporaire impliqués dans le cycle de développement, comme mentionné dans la Mesure II.4.14. De telles orientations ne créeraient pas d'ambiguïté juridique mais rendraient les exigences légales existantes plus applicables aux défis spécifiques de la gouvernance de l'IA.
Contexte – La transparence concernant les risques et les limites des modèles d'IA aide les chercheurs, les décideurs politiques et les utilisateurs à prendre des décisions éclairées. La version actuelle du Code exige que les entreprises publient des informations sur les risques systémiques "lorsque nécessaire pour permettre efficacement l'évaluation et l'atténuation", un standard qui pourrait bénéficier d'exigences de base plus précises. Le projet de Code permet des caviardages pour des raisons de sécurité ou pour protéger "des informations commerciales sensibles dans une mesure disproportionnée par rapport au bénéfice sociétal [apporté par leur publication]." Bien que ces exceptions soient raisonnables en principe, des critères plus clairs et des mécanismes de surveillance aideraient à garantir qu’une véritable transparence reste effective. Contrairement aux industries à haut risque aux normes matures, où des personnes aux rôles clairement identifiés doivent valider les décisions critiques pour la sécurité, le projet de texte permet une opacité complète concernant la prise de décision finale de déploiement. Le texte se contente de vaguement suggérer la publication de documents qui "résument les Model Reports" (document devant être transmis confidentiellement au Bureau de l’IA) avec des descriptions de la méthodologie d'évaluation des risques, la justification du déploiement et les atténuations des risques. Cette formulation permissive permet aux entreprises de satisfaire aux exigences avec des généralités vagues. Par exemple, une entreprise d'IA pourrait publier un résumé de Model Report indiquant simplement qu'elle a "mené des évaluations complètes" et "mis en œuvre des garanties appropriées".
Recommandations – Nous recommandons de renforcer les dispositions de transparence dans l'Engagement II.16 en établissant des exigences de transparence minimale que tous les fournisseurs doivent respecter. Le Code devrait imposer le format des Model Reports avec des sections abordant les risques techniques de sécurité, les scénarios potentiels d'utilisation abusive, les méthodologies d'évaluation, les limitations identifiées, les quasi-accidents et les anomalies. Les entreprises devraient être tenues d’expliciter leur gouvernance pour les décisions critiques de sécurité, y compris les exigences de qualification pour les personnes occupant des postes à responsabilité et la chaîne décisionnelle pour l'approbation du déploiement du modèle. Ces exigences devraient refléter les pratiques établies dans d'autres industries critiques pour la sécurité, comme l'aviation et l'énergie nucléaire. Les critères pour les “caviardages légitimes” devraient être étroitement définis avec des lignes directrices claires permettant de distinguer les véritables préoccupations de sécurité de la poursuite d’ intérêts privés. Les entreprises devraient également rendre publique et expliquer leur décision de caviarder des informations des publications publiques. Étant donné que les défauts des technologies prennent souvent des années à être découverts, les entreprises devraient détailler leurs plans de surveillance pour les systèmes déjà déployés. Les entreprises devraient être tenues de documenter les modes de défaillance connus et d'expliquer pourquoi elles croient que les vulnérabilités non découvertes ne conduiront pas à des préjudices futurs, reconnaissant les limites des évaluations de sécurité actuelles.
La CeSIA estime que la troisième version du Code de bonnes pratiques de l'UE pour l'IA à usage général représente un progrès significatif vers un cadre de gouvernance efficace. Les semaines à venir présentent une opportunité importante pour affiner ce cadre avant qu'il ne commence à façonner les pratiques de l'industrie. Le CeSIA présentera au Bureau européen de l’IA les commentaires ci-dessus, parmi d'autres, afin d’assurer une standardisation efficace des meilleures pratiques des fournisseurs de modèles. Les présidents des groupes de travail examineront les commentaires des organisations de la société civile, des membres de l'industrie et des experts indépendants, et la version finale du Code de bonnes pratiques sera présentée et approuvée en mai 2025. Nous croyons que le renforcement des exigences d'évaluation externe, la clarification des protocoles de suppression des modèles, l'amélioration des protections des lanceurs d'alerte et l'amélioration des directives de transparence sont essentiels pour créer un CoP qui soutient efficacement le développement responsable de l'IA à travers l'Europe.
Nous apprécions le travail considérable qui a été consacré au développement du CoP jusqu'à présent et proposons ces recommandations pour aider à renforcer son efficacité en tant que guide pratique pour la mise en œuvre des protections importantes du règlement sur l’IA.
Alors que le Code de bonnes pratiques approche de sa version finale, un moment de vérité se joue pour les fournisseurs d'IA à usage général. Ce Code n'est pas un simple document d’orientation sectoriel à signer et à remiser. Il représente des centaines de milliers d'heures d'expertise condensées en lignes directrices concrètes. Bien que d’application volontaire, ses fondements reposent sur les exigences contraignantes du Règlement sur l'IA. Ceux qui désapprouvent les demandes du Code et choisissent d'autres voies pour démontrer leur conformité devront composer avec une charge de la preuve plus lourde, dans un paysage réglementaire qui appelle à l'unité, la clarté et la certitude.
L'histoire offre des leçons sur l'approche des géants de la technologie en matière d'autorégulation. À maintes reprises, des entreprises ont adopté des cadres volontaires avec des démonstrations publiques de bonne volonté, pour ensuite ne les appliquer que sélectivement. La force du Code réside dans ses mécanismes de transparence et ses structures de responsabilisation, à même de transformer des engagements de façade en actions vérifiables.
Il semble évident que les autres secteurs à haut risque soient soumis à des normes de sécurité proportionnées aux risques qu’ils font peser sur la société Même les produits de consommation courante sont soumis à des exigences de sécurité rigoureuses dans l'UE. Les créateurs de modèles d’IA à usage général eux-mêmes ont comparé leur impact potentiel à celui de l'énergie nucléaire. Une technologie d'une telle portée mérite des garde-fous proportionnés, non pas pour freiner à l'innovation, mais pour l’orienter dans une direction profitant à la société..
Le débat autour de la signature du Code révèlera finalement quels fournisseurs se contentent de parler de responsabilité en matière d'IA et ceux qui sont prêts à prouver leur engagement par des actes.
