L’avertissement de Brad Smith sur la régulation de l’IA remet en cause le pari américain de l’autorégulation
Le président de Microsoft, Brad Smith, a lancé cette semaine un avertissement sans détour : l’intelligence artificielle fait l’objet de moins de contrôles de sécurité que le lait ou les lave-linge. Son argumentaire sur la régulation de l’IA remet en cause la préférence de Washington pour l’autorégulation du secteur, alors que les agents d’IA gagnent en liberté opérationnelle.
Smith souhaite que les gouvernements imposent des rapports d’incident, des notifications aux victimes, des évaluations indépendantes et des mécanismes d’urgence pour les systèmes avancés. Ces propositions vont au-delà des engagements volontaires, que les entreprises responsables peuvent respecter tandis que les développeurs moins rigoureux les ignorent.
Le conflit ne se résume pas à Microsoft contre la dérégulation. Il oppose des règles de sécurité des produits contraignantes à des promesses volontaires conçues pour préserver la vitesse de développement. L’Union européenne a déjà opté pour des obligations contraignantes, tandis que les États-Unis continuent de débattre de l’ampleur des pouvoirs à accorder aux régulateurs.
Les propos de Brad Smith sur la régulation de l’IA relèvent le niveau d’exigence
La principale demande de Smith est que l’IA avancée soit soumise à des obligations de sécurité contraignantes avant que les défaillances graves ne deviennent habituelles.
Lors d’une interview accordée à la BBC et publiée le 11 octobre, Smith a comparé la supervision de l’IA aux inspections appliquées aux produits de consommation courante. Le lait et les lave-linge doivent satisfaire à des exigences de sécurité établies, alors que de nombreux systèmes d’IA parviennent aux utilisateurs sans contrôle équivalent avant leur mise sur le marché.
L’analogie était volontairement frappante. La réglementation du lait couvre la contamination, l’étiquetage, la manipulation et la traçabilité. Les règles applicables aux appareils électroménagers concernent les risques électriques, la consommation d’énergie et les défaillances mécaniques prévisibles. L’IA présente des risques différents, mais la comparaison de Smith vise l’absence d’une structure de responsabilité tout aussi mature.
Son argumentaire comprenait quatre mesures concrètes. Les développeurs devraient maintenir des mécanismes d’urgence, documenter les incidents graves, informer les victimes de violations facilitées par l’IA et accepter des évaluations indépendantes avant de publier des systèmes particulièrement conséquents.
Un mécanisme d’urgence, parfois appelé kill switch, permet à un opérateur de suspendre ou de restreindre un système lorsque son comportement dépasse les limites approuvées. Cela semble simple, mais les agents autonomes compliquent cette idée.
Un agent d’IA est un logiciel capable de planifier et d’exécuter plusieurs étapes avec une supervision humaine limitée. Il peut parcourir des systèmes, appeler des outils, écrire du code, déplacer des données ou communiquer avec d’autres services.
Mettre en pause un modèle ne stoppe pas nécessairement un flux de travail distribué. Les contrôles pertinents peuvent devoir couvrir les identifiants, l’accès réseau, les autorisations d’outils, les agents copiés et les applications en aval.
Smith s’est donc concentré sur la responsabilité opérationnelle, et pas uniquement sur l’exactitude des modèles. Si un agent franchit les limites prévues et compromet une autre organisation, la partie concernée devrait recevoir une notification officielle.
Cette proposition ressemble aux règles de notification des violations utilisées en cybersécurité et dans le droit de la vie privée. Elle crée une trace, fixe des délais et fournit aux victimes les informations nécessaires pour limiter les dégâts.
Selon les règles mondiales de sécurité décrites dans l’interview, Smith souhaite également que les gouvernements déterminent quand des évaluateurs externes doivent examiner les produits d’IA avant leur mise sur le marché. Il a décrit l’IA à la fois comme un outil et comme une arme.
Microsoft promeut des contrôles similaires depuis des années. Son plan de gouvernance de 2023 appelait à des freins de sécurité lorsque l’IA contrôle des infrastructures critiques, notamment les réseaux électriques, les systèmes d’eau et les flux de circulation.
Le plan de gouvernance de l’IA soutenait également que la supervision de l’IA ne devait pas rester exclusivement entre les mains des entreprises technologiques. Les derniers commentaires de Smith précisent cette position autour des agents autonomes et du risque cyber.
Ce changement compte, car l’IA générative ne produit plus seulement du texte ou des images. Les systèmes plus récents peuvent effectuer des actions via des navigateurs, des terminaux, des bases de données et des applications d’entreprise.
Une erreur de chatbot peut induire un utilisateur en erreur. Un agent doté d’identifiants peut modifier des dossiers, exposer des données confidentielles ou créer une chaîne d’actions automatisées avant qu’un humain n’intervienne.
Cette différence rend le signalement des incidents plus important. Les organisations ne peuvent pas étudier les défaillances récurrentes lorsque les développeurs divulguent les événements de façon sélective ou définissent les incidents graves selon des critères incompatibles.
L’avertissement de Smith ne prouve pas que l’IA est littéralement non réglementée partout. Les lois sur la vie privée, la protection des consommateurs, la discrimination, la responsabilité du fait des produits, le droit d’auteur et les règles sectorielles peuvent déjà s’appliquer.
Son point plus précis est plus défendable. Les États-Unis ne disposent pas d’un cadre global de sécurité des produits conçu spécifiquement pour l’IA avancée à usage général et les agents autonomes.
Cette lacune crée le conflit central de l’article. La coopération volontaire peut instaurer rapidement des pratiques utiles, mais elle n’oblige pas chaque développeur à respecter le même niveau minimal.
La pression s’exerce sur les gouvernements et les acheteurs d’IA
Les développeurs d’IA souhaitent pouvoir avancer rapidement, mais les clients ont de plus en plus besoin de preuves que la vitesse ne remplace pas la responsabilité.
Les commentaires de Smith exercent une pression immédiate sur les décideurs publics. Les gouvernements doivent déterminer si l’IA avancée doit rester principalement un service logiciel ou devenir une catégorie de produits réglementée lorsqu’elle effectue des actions conséquentes.
La réponse influence les tests, la documentation, les audits et la responsabilité. Elle détermine aussi quel régulateur reçoit l’autorité lorsqu’un agent cause des dommages dans plusieurs secteurs ou au-delà des frontières nationales.
Un assistant médical, un outil de recrutement, un agent de codage et un bot de service client peuvent utiliser le même modèle sous-jacent. Leurs risques diffèrent parce que chaque système reçoit des données, des autorisations et des responsabilités différentes.
Un processus d’approbation uniforme serait trop rudimentaire. Un cadre sans socle obligatoire laisserait les organisations négocier individuellement les normes de sécurité avec les fournisseurs.
Les acheteurs en entreprise portent déjà une grande partie de cette charge. Les équipes de sécurité examinent les contrôles d’accès, la conservation des données, le comportement des modèles, la journalisation et les contrats fournisseurs avant d’approuver des déploiements d’IA.
Ces vérifications deviennent plus difficiles lorsqu’un agent peut exécuter des commandes. Un modèle peut se comporter de manière sûre lors d’un benchmark, puis échouer après avoir reçu des instructions inattendues provenant d’un document, d’un site web ou d’un outil compromis.
L’injection de prompt illustre le problème. Une instruction malveillante dissimulée dans un contenu externe peut rediriger un agent, même si l’utilisateur n’a jamais eu l’intention d’effectuer cette action.
Les organisations peuvent réduire leur exposition en limitant les autorisations, en isolant les systèmes et en exigeant une approbation pour les étapes sensibles. Toutefois, ces contrôles dépendent d’une documentation claire de la part des fournisseurs de modèles et d’applications.
Des rapports d’incident obligatoires aideraient les acheteurs à comparer les défaillances entre systèmes. Des rapports standardisés pourraient consigner la capacité concernée, les autorisations du système, les garde-fous ayant échoué et le préjudice qui en a résulté.
La notification des victimes est tout aussi importante. Une entreprise ne peut pas contenir une intrusion si le développeur ayant détecté l’implication de l’agent n’a aucune obligation de communiquer rapidement.
Des tests indépendants pourraient aussi réduire les asymétries d’information. Les fournisseurs de modèles disposent de connaissances techniques plus approfondies, mais ils subissent une pression commerciale pour publier rapidement et présenter les résultats de manière favorable.
Des évaluateurs externes peuvent tester les capacités dans des conditions contrôlées et remettre en question les hypothèses internes. Leur indépendance dépend néanmoins de l’accès, du financement, de l’autorité légale et d’une protection contre les conflits d’intérêts.
Les règles de sécurité de Microsoft pour l’IA créeraient des coûts pour Microsoft comme pour ses concurrents. Cela rend la position de Smith plus significative, même si cela n’élimine pas les intérêts commerciaux de l’entreprise.
Les grandes entreprises peuvent absorber les coûts de conformité plus facilement que les startups. Une réglementation complexe peut donc protéger les utilisateurs tout en renforçant les barrières à l’entrée pour les petits développeurs.
Cette tension donne aux critiques une préoccupation légitime. Des règles conçues avec les grands laboratoires pourraient favoriser les entreprises qui disposent déjà d’importantes équipes juridiques, de sécurité et de politiques publiques.
Les gouvernements doivent distinguer les garanties essentielles de la paperasse qui mesure la capacité administrative. Signaler un événement grave de perte de contrôle répond à un objectif clair. Produire des documents répétitifs sans tests techniques n’en répond pas.
Les acheteurs doivent aussi disposer de dossiers internes reliant les affirmations des fournisseurs aux décisions de déploiement. Une base de connaissances sur l’IA consultable peut aider les équipes à conserver les évaluations, les approbations, les incidents et les changements de politique entre les départements.
La documentation seule ne peut pas garantir la sécurité. Elle peut toutefois établir qui a approuvé un système, quels contrôles existaient et comment une organisation a réagi après un avertissement.
La pression est donc partagée. Les gouvernements doivent définir des exigences minimales contraignantes, les développeurs doivent fournir des preuves significatives et les clients doivent contrôler le fonctionnement des systèmes dans leurs environnements.
Les règles volontaires de sécurité de l’IA ont un problème de couverture
L’autorégulation fonctionne au mieux parmi les entreprises coopératives, tandis que la réglementation est la plus importante lorsqu’une entreprise refuse de coopérer.
Smith a reconnu que les accords volontaires représentent un progrès. Il a également identifié leur faiblesse structurelle : les entreprises responsables participent, mais les organisations qui créent les plus grands risques peuvent rester en dehors.
Cette distinction devient plus importante à mesure que le développement devient accessible. Un engagement volontaire signé par des laboratoires de premier plan ne lie pas un petit fournisseur, un opérateur étranger ou un développeur distribuant des modèles modifiés.
Le même problème apparaît après la publication. Une entreprise peut promettre des évaluations, mais choisir ses propres tests, seuils et formulations de divulgation, à moins qu’une norme commune ne les définisse.
L’autorégulation présente néanmoins des avantages. Les groupes sectoriels peuvent actualiser les pratiques techniques plus rapidement que les législatures, recruter des spécialistes et expérimenter avant que les gouvernements ne comprennent les capacités émergentes.
Les tests volontaires peuvent également commencer immédiatement. Une nouvelle loi peut nécessiter des mois de rédaction, d’auditions, de règles de mise en œuvre, de contestations judiciaires et de recrutement de régulateurs.
Le cadre le plus solide combinerait les deux approches. La loi établirait des obligations minimales, tandis que les normes techniques définiraient des méthodes adaptables pour y répondre.
La position de Smith entre en conflit avec l’accent mis par le président Donald Trump sur le développement rapide américain et la concurrence avec la Chine. L’administration soutient que des règles contraignantes peuvent ralentir les entreprises nationales tandis que les rivaux étrangers progressent.
Un décret de la Maison-Blanche de 2026 indiquait que les États-Unis sont en tête notamment parce qu’ils refusent d’étouffer l’innovation par une réglementation excessive. Il mettait l’accent sur un déploiement rapide et sûr ainsi que sur une coopération plus étroite entre le gouvernement et l’industrie.
Cette politique fédérale sur l’IA reflète une théorie du risque différente. La perte du leadership technologique devient un danger pour la sécurité nationale, au même titre qu’un déploiement non sûr.
Le désaccord ne se résume pas à un simple choix entre sécurité et innovation. Les deux camps affirment que leur approche protège la compétitivité nationale et la sécurité publique.
Smith soutient que des systèmes dignes de confiance connaîtront une adoption plus large. L’administration affirme que des règles prématurées pourraient figer la technologie actuelle, augmenter les coûts et faire perdre l’élan.
La Chine complique également le débat. Des règles appliquées uniquement aux entreprises américaines ne peuvent pas régir directement les développeurs étrangers, les publications de modèles à poids ouverts ou les systèmes déployés depuis une autre juridiction.
Cependant, les normes applicables aux produits peuvent toujours influencer l’accès au marché. Un gouvernement peut exiger des tests, des rapports et une traçabilité pour les systèmes utilisés dans des secteurs critiques, quel que soit l’endroit où le modèle a été entraîné.
Les secteurs de l’aviation et des dispositifs médicaux appliquent une logique similaire. Les fabricants opèrent à l’échelle mondiale, mais leurs produits doivent répondre aux exigences locales avant d’entrer sur des marchés réglementés.
Expliquée sous cet angle, la régulation de l’IA consiste moins à approuver chaque modèle qu’à contrôler les déploiements aux conséquences majeures. Un assistant de rédaction ne devrait pas faire l’objet du même niveau de contrôle qu’un agent exploitant des infrastructures électriques.
La classification par risque peut préserver la flexibilité. Elle peut réserver l’examen indépendant aux systèmes présentant des capacités dangereuses, une large autonomie, des données sensibles ou un accès à des opérations critiques.
Pourtant, la classification crée ses propres failles. Les développeurs peuvent décrire un système de manière restrictive durant l’examen, tandis que les clients le connectent ensuite à des outils aux enjeux bien plus élevés.
La responsabilité doit donc s’étendre à l’ensemble de la chaîne d’approvisionnement. Les fournisseurs de modèles connaissent les capacités fondamentales, les développeurs d’applications définissent les flux de travail et les déployeurs attribuent les données et les autorisations.
Aucun participant ne perçoit l’intégralité du risque. Des règles efficaces doivent préciser ce que chaque partie documente et à quel moment la responsabilité est transférée.
La critique de Smith envers l’autorégulation est la plus solide sur la question de la couverture. Une promesse partagée par des entreprises réputées ne peut pas établir des obligations universelles ni imposer des conséquences à un opérateur qui les ignore.
Sa faiblesse concerne la précision. « Réguler l’IA » couvre trop de systèmes et de contextes pour constituer une politique applicable sans seuils détaillés.
L’Europe montre que la régulation est possible, mais pas simple
L’Union européenne est passée de principes volontaires à des obligations exécutoires, mais son système progressif montre à quel point une régulation complète de l’IA est difficile.
L’AI Act de l’UE adopte une structure fondée sur les risques. Il interdit certaines pratiques, crée des obligations pour les modèles d’IA à usage général et applique des contrôles supplémentaires aux systèmes utilisés dans des domaines sensibles.
Les pouvoirs d’exécution de plusieurs dispositions ont commencé à s’appliquer en août 2026. Les obligations de transparence exigent que les utilisateurs soient informés lorsqu’ils interagissent avec certains systèmes d’IA ou rencontrent certains contenus synthétiques spécifiés.
Les règles concernent également les modèles d’IA à usage général présentant un risque systémique. Les fournisseurs concernés sont soumis à des obligations d’évaluation, de documentation, de cybersécurité et d’atténuation des risques.
Le cadre de l’AI Act ne réglemente pas toutes les applications de la même manière. L’UE indique que la plupart des systèmes à risque minimal restent en dehors des contrôles obligatoires supplémentaires.
Cela remet directement en cause l’idée que les gouvernements doivent choisir entre des restrictions globales et une autorégulation totale. Les régulateurs peuvent concentrer les obligations là où les préjudices potentiels sont les plus importants.
Toutefois, le calendrier de mise en œuvre révèle des frictions pratiques. Les règles concernant plusieurs usages à haut risque ne s’appliqueront pas avant décembre 2027, tandis que les exigences applicables à l’IA intégrée dans des produits réglementés s’étendent jusqu’en 2028.
Les normes, les orientations, les capacités des régulateurs et les méthodes de test nécessitent du temps. Les entreprises ont également besoin de clarté sur les classifications et la documentation avant que l’application des règles ne devienne prévisible.
L’approche de l’UE soutient donc l’argument de Smith tout en nuançant son urgence. L’adoption d’une loi lance le processus, mais ne crée pas instantanément des évaluateurs compétents ni des méthodes d’évaluation fiables.
Tester les modèles à usage général reste particulièrement difficile. Un modèle peut présenter des capacités différentes après l’accès à des outils, un ajustement fin, des prompts système ou une intégration avec des données propriétaires.
L’évaluation avant publication peut identifier des capacités dangereuses, mais elle ne peut pas reproduire chaque configuration en aval. Une surveillance continue et des rapports post-déploiement restent nécessaires.
La loi soulève également des préoccupations concurrentielles. La conformité peut exiger une expertise juridique, une documentation technique et une gestion continue des risques que les petits fournisseurs peinent à financer.
Les partisans répondent que les produits à haut risque doivent assumer des coûts de sécurité. Une startup ne bénéficie pas d’une exemption pour protéger les patients simplement parce que la conformité médicale est coûteuse.
Les critiques rétorquent que les logiciels évoluent plus vite que les produits physiques. Des règles figées peuvent devenir obsolètes, récompenser une conformité procédurale ou décourager la recherche ouverte sans réduire le risque réel.
Les deux préoccupations sont valables. La régulation peut échouer par insuffisance, en laissant des préjudices graves sans réponse. Elle peut aussi échouer par excès, en orientant les ressources vers des formulaires plutôt que vers l’ingénierie de sécurité.
L’expérience de l’UE en matière d’application des règles apportera des éléments au débat sur la régulation de l’IA de Brad Smith. Les régulateurs doivent démontrer que les exigences améliorent la transparence et la responsabilité sans créer de barrières arbitraires.
Le Royaume-Uni suit une voie différente. Il a investi dans des capacités d’évaluation technique tout en évitant une loi horizontale de type européen couvrant l’ensemble du marché de l’IA.
Smith a décrit le Royaume-Uni comme bien placé pour mener les travaux mondiaux sur la sécurité grâce à son AI Security Institute. L’institut a débuté sous le nom d’AI Safety Institute et a reçu un mandat axé sur la sécurité en 2025.
Ses travaux comprennent l’étude des capacités avancées, des abus cybernétiques, des garde-fous et de la préparation des gouvernements. La mission de l’institut de sécurité décrit une organisation soutenue par l’État qui mène des recherches techniques afin d’appuyer la gouvernance de l’IA avancée.
Cette expertise pourrait soutenir des normes internationales de test. Toutefois, un institut de recherche ne dispose pas automatiquement du pouvoir d’imposer des divulgations, de bloquer des lancements ou de sanctionner des violations.
Smith veut que la capacité technique et l’obligation légale se renforcent mutuellement. Le Royaume-Uni a développé la première, tandis que le Parlement doit encore faire des choix concernant la seconde.
Le leadership mondial exige aussi de la coopération. Une norme adoptée par un pays a une portée limitée lorsque les développeurs peuvent publier des modèles, des poids ou des services au-delà des frontières.
Des formats communs de rapport et des méthodes d’évaluation pourraient être plus réalisables qu’un régulateur mondial unique. Les pays pourraient reconnaître des tests compatibles tout en préservant des systèmes d’application différents.
La position de Microsoft mérite son propre test de résistance
L’argument de Microsoft en faveur de règles plus strictes est crédible, mais les décideurs politiques devraient examiner qui en bénéficie et si les contrôles proposés fonctionnent en pratique.
Microsoft vend des infrastructures cloud, des services de sécurité, des logiciels de travail et des systèmes d’IA à des organisations fortement réglementées. Des règles nationales claires peuvent réduire l’incertitude pour ces clients.
L’entreprise dispose également des ressources nécessaires pour satisfaire à d’importantes exigences de conformité. Les concurrents plus petits peuvent supporter des coûts proportionnellement plus élevés, surtout si les évaluations exigent des spécialistes rares ou une puissance de calcul coûteuse.
Cela ne rend pas les propositions de Smith erronées. Cela signifie que les décideurs doivent vérifier si chaque mesure réduit le risque sans consolider la position des plus grands fournisseurs actuels.
L’évaluation indépendante en est un exemple. Une obligation peut améliorer la responsabilité, mais seulement si les évaluateurs disposent d’un accès approprié et peuvent publier des conclusions significatives.
Un examen reposant entièrement sur des tests choisis par le fournisseur offrirait une indépendance limitée. Un examen sans accès aux détails du système pourrait manquer des comportements qui émergent dans les environnements de production.
Les évaluateurs gouvernementaux ont également besoin de personnel qualifié. Les agences sont en concurrence avec les entreprises technologiques pour recruter des chercheurs qui comprennent la sécurité des modèles, les opérations cybernétiques et les systèmes distribués.
Les limites de capacité peuvent entraîner des retards. Si chaque nouveau modèle exige une approbation complète, les files d’évaluation pourraient ralentir les produits à faible risque tandis que les évaluateurs manqueraient des systèmes réellement dangereux.
Les seuils sont donc essentiels. Une obligation d’examen pourrait se concentrer sur les modèles dépassant des niveaux de capacité définis ou sur les systèmes contrôlant des infrastructures critiques.
Les seuils de capacité nécessitent également des révisions fréquentes. Une évaluation qui identifie aujourd’hui une aptitude exceptionnelle pourrait devenir un test de routine à mesure que les modèles progressent.
Les contrôles d’urgence posent un autre défi. Un service centralisé peut suspendre l’accès, révoquer des identifiants ou désactiver des outils. Un modèle à poids ouverts copié sur de nombreuses machines ne peut pas être rappelé aussi facilement.
Même les systèmes hébergés peuvent échapper à un point de contrôle unique par le biais de données mises en cache, d’applications connectées ou d’identifiants délégués. Un mécanisme d’arrêt doit couvrir l’ensemble du déploiement, et pas seulement le point de terminaison du modèle.
Le signalement des incidents soulève des questions de périmètre. Les développeurs ont besoin de définitions distinguant les erreurs inoffensives des événements de sécurité qui justifient l’attention des régulateurs.
Des exigences trop larges pourraient submerger les agences d’erreurs mineures. Des définitions étroites pourraient permettre aux entreprises d’exclure des quasi-accidents graves ou des préjudices en aval.
Les règles doivent également prévoir des protections pour le signalement. Les organisations peuvent dissimuler des incidents lorsque leur divulgation entraîne une responsabilité immédiate, un préjudice réputationnel ou l’exposition d’informations de sécurité sensibles.
La politique de cybersécurité concilie souvent confidentialité et responsabilité. Les régulateurs peuvent recevoir des rapports détaillés tout en publiant des enseignements agrégés qui aident d’autres organisations à s’améliorer.
La proposition de Smith concernant la notification des victimes mérite une attention particulière. Une cible a besoin d’informations rapides après une intrusion facilitée par l’IA, mais les enquêteurs doivent établir ce que le fournisseur savait et à quel moment.
Un système d’IA peut aider un attaquant sans agir de manière indépendante. Les régulateurs devraient éviter des définitions qui traitent chaque utilisation de logiciel génératif comme un incident d’IA distinct.
La question pertinente est de savoir si le système a introduit, accéléré ou dissimulé un préjudice substantiel. Les rapports devraient décrire cette contribution plutôt que de s’appuyer sur des étiquettes dramatiques telles que l’IA hors de contrôle.
Les propres déploiements de Microsoft devraient être soumis aux normes recommandées par Smith. Cela inclut les produits Copilot, les modèles hébergés sur Azure, les agents de sécurité et les systèmes fournis dans le cadre de partenariats commerciaux.
Une règle crédible ne peut pas dépendre de la structure d’entreprise préférée du fournisseur. Les responsabilités doivent rester claires lorsqu’un développeur de modèles, un hébergeur cloud, un fournisseur d’applications et un client partagent le contrôle.
C’est là que les règles de sécurité de l’IA de Microsoft doivent produire des résultats mesurables. Les régulateurs devraient se demander si les contrôles réduisent le délai de détection, limitent les actions non autorisées et améliorent la reprise après des défaillances.
Ils devraient également examiner la fausse confiance. Une évaluation réussie peut devenir un label marketing même lorsque la configuration déployée diffère du système examiné.
Aucun audit ne peut garantir la sécurité. Les tests indépendants fournissent des éléments sur des conditions définies, et non une assurance permanente contre chaque utilisation future.
La comparaison de Smith avec le lait est donc efficace sur le plan rhétorique, mais techniquement incomplète. Le lait est un produit physique standardisé, avec des voies de contamination établies et des méthodes d’inspection éprouvées.
Les systèmes d’IA sont des services adaptables dont le comportement change selon le contexte. Cette complexité renforce l’argument en faveur d’une supervision tout en rendant plus difficile la conception d’une régulation de type produit.
La conclusion sceptique n’est pas que la régulation devrait attendre. C’est que les règles doivent s’attacher aux capacités, aux autorisations et aux préjudices réels plutôt qu’à l’étiquette générale « IA ».
Trois signaux montreront si l’avertissement change les politiques publiques
Le prochain test consiste à savoir si les gouvernements transforment un large accord sur les risques liés à l’IA en obligations précises qui résistent à l’examen politique et technique.
Le premier signal est une proposition contraignante de signalement des incidents. Les décideurs devraient définir les systèmes couverts, les incidents graves, les délais de signalement, les notifications aux victimes et les protections de confidentialité.
Si une juridiction majeure adopte ces éléments, l’argument de Smith sera passé de l’analogie à une politique opérationnelle. Un registre volontaire ou une promesse de signalement non définie constituerait une réponse plus faible.
Le deuxième signal est un accès élargi pour les évaluateurs indépendants. Les gouvernements ont besoin d’accords permettant à des chercheurs qualifiés de tester des systèmes avancés avant des déploiements aux conséquences majeures.
L’AI Security Institute du Royaume-Uni offre une base possible. Son utilité dépendra de la rapidité avec laquelle les développeurs lui accorderont l’accès et de l’influence de ses conclusions sur les décisions de déploiement.
Un accès obligatoire pour des systèmes à haut risque clairement définis renforcerait l’argument de Smith. Une dépendance persistante à une coopération discrétionnaire montrerait que l’autorégulation fixe encore la limite concrète.
Le troisième signal provient des preuves issues de l’application des règles dans l’UE. Les autorités doivent démontrer comment les obligations de transparence, applicables aux modèles à usage général, et les contrôles des risques systémiques fonctionnent dans des cas réels.
Une application cohérente montrerait que des règles d’IA contraignantes peuvent fonctionner sur un vaste marché. Des interprétations divergentes ou des retards procéduraux conforteraient les inquiétudes liées à la complexité réglementaire.
Les États-Unis restent l’incertitude la plus déterminante. Le Congrès a débattu de la préemption fédérale, des règles des États, de la sécurité des produits et d’un cadre national souple, sans trancher le compromis fondamental.
Lors de précédents débats au Congrès, Smith avait soutenu un rôle fédéral de premier plan en matière de sécurité des produits et d’examen préalable à la commercialisation. Il s’était également dit ouvert à l’idée de laisser au pays le temps d’élaborer une approche unifiée.
Cet historique apporte une nuance. Microsoft ne demande ni que chaque État invente ses propres règles, ni que chaque application d’IA doive recevoir une autorisation.
L’entreprise semble privilégier un cadre cohérent à l’échelle nationale, centré sur les capacités avancées et les déploiements aux conséquences importantes. Les dirigeants du secteur préfèrent souvent l’uniformité fédérale, car la fragmentation des règles entre États augmente les coûts de conformité.
Le débat sur le cadre fédéral révèle également un piège politique. La préemption fédérale peut simplifier les obligations, mais elle peut créer un vide si le Congrès empêche les États d’agir sans mettre en place de protections.
Pour les développeurs, la leçon immédiate est de concevoir les systèmes comme si des obligations de signalement et d’audit allaient bientôt s’appliquer. Cela implique de conserver les journaux, de documenter les autorisations des outils, de tester les procédures d’arrêt et de séparer les actions sensibles des résultats ordinaires.
Les acheteurs d’entreprise devraient demander dès maintenant les mêmes éléments de preuve. Les équipes achats peuvent interroger les fournisseurs sur les destinataires des notifications d’incident, les évaluateurs qui obtiennent un accès et la manière dont les administrateurs révoquent l’autorité d’un agent.
Les travailleurs du savoir devraient également s’y intéresser, car les outils agentiques agissent de plus en plus dans les e-mails, les documents, les calendriers, les dépôts de code et les dossiers clients. Une réponse erronée est gênante. Une action non autorisée peut être irréversible.
Les équipes devraient conserver une approbation humaine pour les étapes importantes, limiter les identifiants et consigner les sources ayant influencé une action. Ces contrôles resteront utiles, quelle que soit la future législation.
L’avertissement de Brad Smith sur la régulation de l’IA n’aura d’importance que s’il débouche sur des responsabilités applicables et des normes techniquement crédibles. Une comparaison mémorable peut lancer le débat, mais elle ne peut pas résoudre le travail de conception.
La meilleure politique ne traitera pas chaque modèle comme une brique de lait. Elle déterminera à quel moment un logiciel acquiert assez d’autonomie, d’accès ou de capacités dangereuses pour exiger une supervision renforcée.
Au cours des trois prochains mois, surveillez l’émergence d’un projet de loi concret sur le signalement des incidents, l’élargissement de l’accès des évaluateurs et les preuves publiques issues de l’application des règles dans l’UE. Ces signaux montreront si les gouvernements construisent une véritable responsabilité ou prolongent l’ère des promesses.
Les organisations ne devraient pas attendre cette réponse. Examinez quels agents d’IA peuvent agir, quels identifiants ils détiennent et qui est averti lorsqu’ils franchissent une limite approuvée. Posez ensuite une question directe aux fournisseurs : leurs engagements de sécurité vous protégeraient-ils encore s’ils n’étaient plus facultatifs ?
