Bloomberg passe en revue les options de régulation de l'IA : du signalement des incidents à l'interdiction

Le débat sur la régulation de l'IA n'oppose plus depuis longtemps les partisans et les adversaires de la régulation. On discute désormais de l'endroit où placer le curseur sur l'échelle de la sévérité. Bloomberg Tech a rassemblé les options dans un seul guide : à l'extrémité souple, l'obligation de signaler les problèmes de sécurité ; à l'extrémité dure, l'interdiction pure et simple de la « superintelligence ». L'encadré d'origine donne peu de détails. Nous déroulons donc ci-dessous cette échelle à l'aide de lois déjà adoptées ou ayant fait l'objet de discussions. Le seuil de 10^25 FLOPs de l'AI Act européen et les amendes pouvant atteindre 7% du chiffre d'affaires mondial montrent que tout cela n'a rien d'abstrait.

L'extrémité souple : signalement et tests

La mesure la plus réaliste consiste à obliger les acteurs à divulguer leurs incidents. Elle coûte peu à l'État et n'empêche pas de lancer des produits. C'est le principe du SB 53 californien, signé en septembre 2025 : les grands développeurs de modèles frontier publient leurs protocoles de sécurité et signalent les incidents critiques au régulateur. Les infractions sont passibles d'amendes pouvant atteindre 1 million de dollars.

L'échelon suivant exige des tests préalables et un audit indépendant. C'est là que surgissent les questions les plus épineuses : qui contrôle, selon quelles méthodologies et avec quel accès aux poids du modèle. L'AI Act européen a emprunté cette voie pour les modèles à usage général présentant un « risque systémique ». Un seul critère s'applique : un entraînement dont le budget de calcul dépasse 10^25 FLOPs.

L'éventail type des outils souples et intermédiaires :

• rapports obligatoires sur les incidents de sécurité ;
• publication des protocoles internes d'évaluation des risques ;
• tests préalables sur les capacités dangereuses (biologie, cyberattaques) ;
• protection des employés qui signalent des manquements ;
• amendes indexées sur le chiffre d'affaires (dans l'AI Act, jusqu'à 7% du chiffre d'affaires mondial pour les pratiques interdites).

L'extrémité dure : kill switch et interdiction

L'idée d'un interrupteur d'urgence paraît simple, mais son efficacité dépend en pratique de l'architecture. Le projet de loi SB 1047, rejeté en 2024 par Newsom, gouverneur de la Californie, exigeait la possibilité d'arrêter complètement un modèle. Il visait les systèmes dont l'entraînement a coûté au moins 100 millions de dollars et dont la puissance dépasse 10^26 FLOPs.

Si le modèle fonctionne via une API sur les serveurs de l'entreprise, il est effectivement possible de couper l'accès. Si les poids sont publiés, les copies ne peuvent plus être rappelées, et le « coupe-circuit » devient une simple déclaration d'intention. Les détracteurs avancent précisément cet argument, tandis que les partisans répondent qu'il faut réguler le droit même de publier les poids des systèmes les plus puissants.

La position la plus radicale consiste à interdire le développement de la « superintelligence » tant qu'aucun consensus scientifique sur sa sécurité n'a émergé. En octobre 2025, le Future of Life Institute a lancé un appel en ce sens, signé notamment par Geoffrey Hinton et Yoshua Bengio. Mais il s'agit d'une pétition, pas d'un projet de loi. Il n'existe même pas de définition consensuelle de la frontière entre un modèle puissant et une « superintelligence ». Sans elle, une interdiction est difficile à rédiger, et plus difficile encore à appliquer.

Comment s'y préparer

Les équipes qui construisent des produits sur des LLM n'ont aucune raison d'attendre la version définitive des règles. Dès maintenant, il vaut la peine de tenir un journal des incidents : défaillances du modèle, fuites de données, cas de réponses nuisibles. Il faut documenter les résultats des tests et prévoir un circuit désactivable pour les agents ayant accès à des systèmes réels, qu'il s'agisse de paiements, de code ou d'infrastructure.

Pour les entreprises qui utilisent des modèles via API, le principal risque tient au fournisseur : s'il passe le seuil de régulation, les conditions d'accès, les limites et les prix changeront. Les investisseurs et les product managers feraient mieux de regarder non pas les interdictions tapageuses, mais les ennuyeuses exigences de reporting. Ce sont elles qui, dans les prochaines années, détermineront le coût de la conformité.