Comprendre le modèle risque systémique IA : au-delà de la puissance de calcul

Un modèle de fondation — ou modèle d'IA à usage général, GPAI pour General-Purpose AI — est un modèle entraîné sur d'immenses volumes de données par auto-supervision, capable d'exécuter avec compétence un large éventail de tâches distinctes. L'AI Act le définit précisément à l'article 3(63) : un modèle qui « présente une généralité significative » et peut être intégré dans une variété de systèmes en aval. Le considérant 98 précise qu'un modèle d'au moins un milliard de paramètres, entraîné à grande échelle, doit être réputé générique.

La notion de risque systémique ne découle pas de l'usage que l'on fait du modèle, mais de sa capacité propre. C'est une rupture conceptuelle. Un chatbot de service client relève d'obligations de transparence limitées ; un modèle de fondation suffisamment puissant peut, lui, abaisser la barrière technique à la conception d'armes biologiques ou orchestrer une cyberattaque coordonnée. Le risque est intrinsèque : il existe indépendamment de la bonne foi du déployeur.

IA générative classique versus impact systémique

Il faut distinguer trois niveaux. La majorité des systèmes d'IA générative — génération de texte, d'images, assistance à la rédaction — présentent un risque minimal ou limité. Les GPAI « standards » supportent des obligations de documentation et de respect du droit d'auteur. Enfin, la fraction la plus avancée des GPAI, celle dont les capacités atteignent l'état de l'art, bascule dans la catégorie « risque systémique ». Comme le rappelle la Commission dans son document d'orientation sur la navigation de l'AI Act, seuls « les modèles les plus avancés » peuvent poser ces risques dits systémiques. Pour la quasi-totalité des PME françaises que j'accompagne, l'enjeu n'est pas de produire un tel modèle — hors de portée financière — mais de comprendre le régime dont dépendent les briques qu'elles intègrent.

Le seuil technique : pourquoi 10²⁵ FLOP est devenu une frontière réglementaire

Un FLOP (Floating Point Operation, opération en virgule flottante) est l'unité élémentaire de calcul d'un processeur : une addition ou une multiplication sur des nombres décimaux. Entraîner un grand modèle consiste à répéter ces opérations des milliards de milliards de fois pour ajuster ses paramètres. La puissance totale mobilisée — le compute — se mesure donc en FLOP cumulés sur l'ensemble de l'entraînement.

L'article 51(2) du Règlement (UE) 2024/1689 pose une présomption : lorsque la quantité cumulée de calcul utilisée pour l'entraînement dépasse 10²⁵ FLOP, le modèle est réputé disposer de « capacités à fort impact » et donc présenter un risque systémique. Ce chiffre — un 1 suivi de 25 zéros — correspond, dans l'état de l'art 2024-2026 publié, aux modèles de tout premier plan mondial.

Le compute comme proxy de l'état de l'art

Pourquoi une métrique de calcul plutôt qu'une évaluation qualitative ? Parce que le compute est mesurable, vérifiable et difficilement contournable. Contrairement à des critères subjectifs de « dangerosité », le nombre de FLOP se documente dès la phase d'entraînement. C'est un proxy imparfait mais opérationnel de la capacité d'un modèle. Le tableau ci-dessous synthétise la gradation.

Niveau Critère indicatif Régime AI Act
GPAI standard ≥ 1 milliard de paramètres, entraînement à grande échelle Documentation technique, droit d'auteur, résumé des données
GPAI à risque systémique Compute cumulé > 10²⁵ FLOP (présomption) Obligations renforcées : notification, évaluation, cybersécurité
Désignation Commission Impact significatif sur le marché intérieur Peut s'appliquer même sous le seuil de calcul

Point crucial : le seuil n'est pas figé. L'AI Act autorise la Commission à le réviser par actes délégués, précisément parce que l'efficacité algorithmique progresse : un modèle de 2027 pourra égaler les capacités d'un modèle de 2024 avec moins de FLOP. Le seuil est un curseur, pas un dogme.

Typologie des risques systémiques identifiés par l'AI Act

La Commission ne se contente pas d'une abstraction juridique : elle nomme les menaces. Le Q&A officiel « Navigating the AI Act » énumère quatre familles de risques que des modèles suffisamment puissants pourraient amplifier.

  • Risques CBRN : les modèles avancés pourraient faciliter la conception d'attaques chimiques, biologiques, radiologiques ou nucléaires, en abaissant le niveau d'expertise nécessaire pour synthétiser un agent pathogène ou concevoir un dispositif dangereux.
  • Cyberattaques à grande échelle : automatisation de la découverte de vulnérabilités, génération de code malveillant polymorphe et orchestration d'offensives coordonnées dépassant les capacités défensives humaines.
  • Perte de contrôle : des modèles présentant des comportements autonomes émergents, dont les actions échappent à la supervision de leurs concepteurs, posent un risque de gouvernance interne.
  • Distorsion stratégique des comportements : manipulation à l'échelle de populations entières, altération des croyances et des processus démocratiques par désinformation industrialisée.

Face à ces menaces, l'AI Act impose une logique proactive : ce n'est pas à la victime de prouver le dommage après coup, mais au fournisseur d'évaluer et d'atténuer le risque en amont. C'est un renversement de la charge de la vigilance qui rejoint la philosophie du safety by design.

Cadre réglementaire : les obligations spécifiques pour les modèles à haut impact

Le régime applicable aux GPAI à risque systémique se résume ainsi : notification obligatoire du modèle à l'AI Office, évaluation et atténuation continue des risques systémiques, signalement des incidents graves et mise en place d'un cadre de cybersécurité robuste. Je ne détaille pas ici chaque article : pour la cartographie complète des obligations et les modèles documentaires, je renvoie au guide de mise en conformité pensé pour les PME françaises publié par notre partenaire éditorial Regulia, qui fait autorité sur l'informationnel AI Act du réseau.

La plateforme EU SEND et l'AI Office

Concrètement, les fournisseurs de modèles concernés doivent transmettre leurs documents via la plateforme EU SEND, qui garantit confidentialité, intégrité et authenticité des informations. Selon les lignes directrices de la Commission pour les fournisseurs de GPAI, cette plateforme centralise les notifications de modèles à risque systémique au titre des articles 51(2) et 52(2), les demandes de réévaluation (article 52(5)), les rapports d'incidents graves (article 55) ainsi que les cadres de sûreté et de sécurité issus du Code de bonnes pratiques GPAI. L'AI Office, logé au sein de la Commission, supervise l'ensemble et accompagne particulièrement les signataires du Code de pratique. Pour les entreprises qui déploient ces modèles sans les développer, l'essentiel est de savoir que la responsabilité de première ligne pèse sur le fournisseur amont — un point que je développe dans la section sanctions.

Gouvernance des données et conformité RGPD : le rôle pivot de la CNIL

L'AI Act ne remplace pas le RGPD : il le complète. Un modèle entraîné sur des données personnelles reste soumis au Règlement (UE) 2016/679. La CNIL a publié des recommandations qui articulent les deux cadres, notamment sur la constitution et l'annotation des jeux de données d'entraînement.

Le dilemme est réel : la qualité d'un modèle dépend de données richement annotées, mais chaque annotation portant sur une personne identifiable engage le RGPD. La CNIL recommande de documenter la base légale du traitement, de minimiser les données personnelles, de pseudonymiser dès que possible et de tracer la provenance des jeux de données. Elle insiste aussi sur les filtres de sortie : un modèle mal cadré peut restituer, lors de l'inférence, des données personnelles mémorisées pendant l'entraînement — un phénomène de « régurgitation » qui constitue une violation caractérisée.

Pour les organisations qui déploient une IA générative en interne, l'articulation se joue sur trois axes : cartographier les traitements de données personnelles impliqués, désigner le rôle de chacun (responsable de traitement, sous-traitant) et documenter les mesures de sécurité. C'est exactement l'objet de la méthode d'installation souveraine que nous appliquons chez IAPRO, où le modèle et les données restent on-premise, sous le contrôle exclusif du client. Pour situer chaque terme technique évoqué ici, je renvoie au glossaire IA d'IAPRO.

Sécurisation de l'architecture : les recommandations de l'ANSSI

La conformité juridique ne suffit pas ; encore faut-il sécuriser techniquement l'architecture. L'ANSSI a publié dès le 29 avril 2024 ses recommandations de sécurité pour un système d'IA générative, un document que je considère comme une base de travail incontournable pour toute installation.

Trois principes structurants s'en dégagent :

  • Security by design : la sécurité doit être intégrée dès la phase de conception et d'entraînement, non ajoutée après coup. Cela implique une analyse de risque en amont, une maîtrise de la chaîne d'approvisionnement des modèles et une segmentation réseau stricte.
  • Protection contre les injections malveillantes : les attaques par prompt injection et par empoisonnement des données (data poisoning) constituent des vecteurs spécifiques à l'IA générative. L'ANSSI préconise le filtrage des entrées, la validation des sorties et le cloisonnement des composants sensibles.
  • Qualité des données en production : la surveillance continue de la qualité des données injectées en phase d'inférence prévient les dérives comportementales du modèle et les fuites d'information.

L'ANSSI précise que son guide ne traite ni de l'éthique, ni de la protection des données personnelles, ni de la performance métier — ces dimensions relèvent respectivement de l'AI Act, du RGPD et de la CNIL. C'est pourquoi une démarche complète articule les trois référentiels plutôt que d'en isoler un seul.

Souveraineté numérique et dépendance technologique

Voici le point que je martèle auprès des dirigeants : le seuil de 10²⁵ FLOP dessine une carte de dépendance. Les modèles qui franchissent cette frontière sont, à ce jour, presque exclusivement développés hors de l'Union européenne, dans un petit nombre d'acteurs disposant de capacités de calcul colossales. Dépendre de ces modèles pour des fonctions critiques, c'est accepter une extraterritorialité juridique et une opacité que la souveraineté numérique cherche précisément à réduire.

La réponse souveraine ne consiste pas à courir après le plus gros modèle. Elle consiste à concilier une puissance de calcul suffisante — des modèles ouverts de type Mistral, Llama ou Qwen, largement en deçà du seuil systémique — avec un contrôle total de l'hébergement, des données et de la gouvernance. Un modèle plus modeste, installé on-premise et maîtrisé de bout en bout, protège mieux une PME industrielle qu'un modèle frontière hébergé hors d'Europe.

C'est un arbitrage économique autant que politique. Pour objectiver le retour sur investissement d'une installation souveraine face à un abonnement cloud extra-européen, j'invite les dirigeants à utiliser notre calculateur de ROI IA, qui intègre les coûts complets — matériel, énergie, conformité — sur un horizon pluriannuel.

Calendrier d'application et enjeux de transition pour les fournisseurs

Attention aux calendriers obsolètes qui circulent : le Règlement a été amendé par l'accord « omnibus numérique » du 7 mai 2026. Voici les dates exactes qui concernent les modèles de fondation, telles que confirmées par les lignes directrices GPAI de la Commission.

Date Jalon
2 août 2025 Application des obligations pour les fournisseurs de GPAI, y compris la notification obligatoire des modèles à risque systémique à l'AI Office.
2 août 2026 Entrée en vigueur des pouvoirs de sanction de la Commission, qui peut désormais faire appliquer les obligations et infliger des amendes.
2 août 2027 Mise en conformité obligatoire des GPAI mis sur le marché avant le 2 août 2025 (article 111).

Dans cette phase de transition, le Code de bonnes pratiques GPAI joue un rôle central. Volontaire et non contraignant, il offre aux fournisseurs un cadre pragmatique pour démontrer leur conformité. Ses signataires bénéficient d'un accompagnement privilégié de l'AI Office. C'est un outil de sécurisation juridique dans une période où les normes harmonisées CEN/CENELEC ne sont pas encore finalisées — un retard que la Commission reconnaît explicitement.

Responsabilité juridique et sanctions : le coût de la non-conformité

Le régime de sanctions est dissuasif. Comme le confirme la fiche du service public GNIUS sur l'AI Act, les amendes s'échelonnent de 1 % à 7 % du chiffre d'affaires annuel mondial, soit de 7,5 à 35 millions d'euros, selon la gravité du manquement et la taille de l'entreprise. Les infractions les plus lourdes — pratiques interdites — sont sanctionnées au plafond ; les manquements aux obligations des systèmes à haut risque ou de transparence relèvent de paliers inférieurs.

Fournisseur versus déployeur : une distinction structurante

Il est capital de distinguer deux rôles. Le fournisseur développe et met sur le marché le modèle ou le système : c'est lui qui porte les obligations lourdes d'évaluation et de notification pour un GPAI à risque systémique. Le déployeur utilise le système dans un contexte spécifique : ses obligations sont moindres mais réelles, notamment la supervision humaine et le respect de la notice d'utilisation. Une PME qui intègre un modèle de fondation dans son produit peut, selon l'ampleur de ses modifications, basculer du statut de déployeur à celui de fournisseur — et hériter alors des obligations correspondantes. Cet arbitrage juridique doit être tranché avant le déploiement, pas après un contrôle.

Conclusion : vers une standardisation de la confiance par le calcul

Le seuil de 10²⁵ FLOP n'est pas une limite technique, c'est un contrat de responsabilité. En transformant une capacité de calcul en obligation juridique, l'Union européenne a créé un instrument de gouvernance inédit : mesurable, révisable, et adossé à des menaces nommées. La prochaine étape est la finalisation des normes harmonisées CEN/CENELEC, qui donneront aux fournisseurs une présomption de conformité et transformeront ces obligations en levier d'innovation sûre. Pour les entreprises françaises, l'enjeu n'est pas de subir cette régulation mais d'en faire un avantage compétitif : une IA maîtrisée, souveraine et documentée inspire plus confiance qu'une boîte noire opaque.

FAQ — modèles de fondation à risque systémique

Qu'est-ce qu'un modèle à risque systémique selon l'AI Act ?

C'est un modèle d'IA à usage général dont les capacités atteignent l'état de l'art et pourraient affecter significativement le marché intérieur, la santé, la sécurité ou les droits fondamentaux. L'article 51 du Règlement (UE) 2024/1689 le présume dès que le calcul cumulé d'entraînement dépasse 10²⁵ FLOP, ou lorsque la Commission le désigne pour son impact.

Pourquoi la Commission utilise-t-elle les FLOPs comme critère de régulation ?

Parce que le FLOP est une métrique mesurable, vérifiable et documentable dès l'entraînement, contrairement à des critères qualitatifs de dangerosité, forcément subjectifs. Le compute cumulé sert de proxy à la capacité d'un modèle. Le seuil reste ajustable par actes délégués, pour suivre les progrès d'efficacité algorithmique qui rendent les modèles plus puissants à calcul égal.

Quelle est la différence entre un modèle GPAI standard et un modèle à risque systémique ?

Un GPAI standard supporte des obligations de documentation technique, de respect du droit d'auteur et de résumé des données d'entraînement. Un modèle à risque systémique y ajoute des obligations renforcées : notification à l'AI Office, évaluation et atténuation continue des risques, signalement des incidents graves et cybersécurité robuste. La bascule tient à la puissance intrinsèque du modèle.

Quelles sont les sanctions en cas de non-respect des obligations liées aux modèles 10²⁵ FLOP ?

Les amendes vont de 1 % à 7 % du chiffre d'affaires annuel mondial, soit de 7,5 à 35 millions d'euros, selon la gravité du manquement et la taille de l'entreprise. Les pouvoirs de sanction de la Commission sur les GPAI sont applicables depuis le 2 août 2026. Le plafond vise les infractions les plus graves aux obligations fondamentales.

Comment une entreprise peut-elle vérifier si son modèle dépasse le seuil réglementaire ?

Elle doit calculer la puissance de calcul cumulée mobilisée pendant tout l'entraînement, exprimée en FLOP, en additionnant les opérations sur l'ensemble des cycles. Si ce total approche ou dépasse 10²⁵ FLOP, la présomption de risque systémique s'applique et impose une notification à l'AI Office via la plateforme EU SEND. Pour l'écrasante majorité des PME, ce seuil n'est jamais atteint.

Le RGPD s'applique-t-il aux modèles d'IA entraînés sur des données personnelles ?

Oui. L'AI Act ne remplace pas le RGPD, il le complète. Tout traitement de données personnelles, y compris pour entraîner un modèle, reste soumis au Règlement (UE) 2016/679. La CNIL recommande de documenter la base légale, de minimiser et pseudonymiser les données, et de mettre en place des filtres empêchant la régurgitation de données personnelles lors de l'inférence.

Quelles sont les obligations de notification envers l'AI Office ?

Les fournisseurs de modèles à risque systémique doivent notifier ces modèles à l'AI Office au titre des articles 51(2) et 52(2), transmettre leurs demandes de réévaluation (article 52(5)) et signaler les incidents graves (article 55). Ces documents passent par la plateforme sécurisée EU SEND, qui garantit confidentialité, intégrité et authenticité des informations partagées avec la Commission.

Que signifie la menace CBRN dans le contexte de l'IA générative ?

CBRN désigne les risques chimiques, biologiques, radiologiques et nucléaires. La Commission craint que des modèles très avancés abaissent la barrière d'expertise nécessaire pour concevoir de telles armes, en fournissant des connaissances ou des protocoles autrement inaccessibles. C'est l'une des quatre familles de risques systémiques justifiant les obligations d'évaluation proactive imposées aux fournisseurs.

Existe-t-il des exemptions pour les modèles open-source ?

Oui, partiellement. Les lignes directrices de la Commission précisent que les fournisseurs de modèles open-source sont exemptés de certaines obligations de documentation, pour favoriser la transparence et l'innovation. Toutefois, cette exemption ne s'applique pas aux modèles à risque systémique : dès qu'un modèle franchit le seuil de capacité, il reste soumis aux obligations d'évaluation, de notification et de cybersécurité, open-source ou non.

Comment la CNIL recommande-t-elle d'annoter les données pour rester conforme ?

La CNIL préconise de documenter la provenance et la base légale des jeux de données, de minimiser les données personnelles annotées, de pseudonymiser dès que possible et de tracer chaque étape du traitement. L'objectif est de concilier la qualité nécessaire à la performance du modèle avec la protection des personnes, notamment en évitant que des données identifiantes ne fuient lors de l'inférence.

Pour aller plus loin avec IAPRO

L'AI Act n'est pas une contrainte abstraite : c'est un cadre qui récompense les organisations qui maîtrisent leur IA de bout en bout. Chez IAPRO, nous installons des modèles souverains on-premise, sous votre contrôle exclusif, avec la documentation de conformité AI Act et RGPD intégrée à la livraison. Si vous déployez ou envisagez de déployer un modèle de fondation, discutons de votre exposition réglementaire et de la formule adaptée à votre structure : prenez contact avec notre équipe.

Liens utiles