Le président de Microsoft Brad Smith défend une surveillance renforcée de l’IA par une comparaison volontairement banale : lait et machines à laver subiraient davantage de contrôles de sécurité que l’IA avancée. Dans la couverture de l’entretien du 12 octobre, il décrit l’IA comme outil et arme, réclame contrôles d’urgence, évaluation indépendante et obligations envers les victimes d’agents incontrôlés pénétrant des systèmes.
Cela ne signifie pas que l’IA échappe à tout droit. Confidentialité, discrimination, consommation, fraude, propriété intellectuelle et règles sectorielles s’appliquent déjà. Smith demande si les protections exécutoires avant et pendant l’usage correspondent à des systèmes capables de lire des données, d’utiliser des outils et d’agir au-delà d’une conversation. Cette exigence expose aussi Microsoft et ses intérêts commerciaux.
Ce qu’établit l’analogie de sécurité des produits
Inspection du lait et normes des appareils imposent des obligations compréhensibles : tester, documenter, répondre aux défauts et aux dommages. L’IA complique ce modèle : un même système résume, programme, interprète des informations médicales ou opère des services. Instructions, contenus récupérés, mémoire et permissions changent son comportement sans nouveau modèle sous-jacent.
L’analogie désigne une lacune, pas un régime d’inspection prêt à appliquer. Approuver un modèle fixe ne certifie pas chaque application. Développeurs, hébergeurs cloud, fournisseurs d’applications et entreprises utilisatrices contrôlent des risques différents. Un benchmark ne garantit pas un agent relié aux dossiers clients ou aux outils financiers.
Microsoft traverse ces couches via infrastructure, modèles, Azure, Copilot et relation avec OpenAI. Cela donne une portée pratique au propos, mais empêche de se présenter comme observateur neutre ou simple fournisseur d’infrastructure.
Son programme d’IA responsable expose équité, fiabilité, confidentialité, transparence, responsabilité et inclusion, avec examens internes, outils et rapports. C’est utile avant la loi, mais défini par l’entreprise. Les principes ne prouvent pas la sécurité de chaque produit ou configuration client.
Un frein d’urgence n’annule pas les actions
Les « kill switches » de Smith désignent la capacité d’arrêter ou limiter un comportement hors frontières, pas nécessairement un bouton physique. Révoquer des identifiants, couper des outils, limiter les dépenses, interrompre des workflows et isoler des points d’accès agissent à plusieurs niveaux. Autorité humaine, séparation technique et escalade testée sont nécessaires si le service initial est compromis.
Une discussion du 22 septembre sur les responsabilités examinait également surveillance, plafonds de dépenses et division entre infrastructure, modèles, données et applications. Chacun peut accuser une autre couche alors que le client manque de preuves pour reconstituer l’incident.
Arrêter le processus ne récupère pas des données exposées et n’annule pas une décision déjà acceptée en aval. Moindre privilège, autorisation des actions importantes et séparation des environnements sensibles doivent précéder l’urgence. L’injection de prompt montre le risque : un contenu malveillant lu peut être pris pour une instruction autorisée, puis devenir une action via les outils.
La surveillance exige des signaux exploitables, pas seulement des journaux : accès inhabituels, outils imprévus, dépenses anormales ou contournements répétés. Un superviseur sans compréhension ni pouvoir d’interruption est inefficace. La récupération exige aussi preuves, notifications et identification des actions terminées.
Aucun interrupteur universel ne maîtrise toutes les copies, modifications à poids ouverts ou utilisations malveillantes sur Internet. Les règles du cloud centralisé ne conviennent pas automatiquement aux modèles téléchargeables. Développement, distribution, hébergement et déploiement à risque doivent être distingués selon contrôle et possibilité d’atténuation.
Les recours des victimes font partie de la proposition
Smith demande des obligations juridiques envers les victimes, pas seulement de meilleurs documents. Un recours devrait examiner qui connaissait le danger, contrôlait la décision et pouvait prévenir le dommage. Ce sont des questions politiques, non l’affirmation qu’un même acteur doit déjà indemniser tous les incidents.
Un développeur ne devrait pas porter automatiquement toute perte d’une application tierce ignorant des restrictions documentées. Un utilisateur ne devrait pas non plus absorber toutes les conséquences d’une vulnérabilité cachée par son fournisseur. Il faut éviter immunité générale et transfert intégral au client.
Le signalement pourrait révéler des échecs récurrents que les acheteurs isolés ne peuvent regrouper. Les seuils devraient distinguer erreurs ordinaires d’accès non autorisés, pertes financières matérielles, interruption essentielle, dommages physiques ou exposition massive de données sensibles. Trop larges, ils saturent ; trop étroits, ils suppriment les alertes.
Les enquêteurs indépendants ont besoin de preuves techniques si les causes sont contestées. La publication doit protéger données personnelles et défenses avant correction des failles. Indemnisation, accès aux preuves et confinement doivent être conçus ensemble, non comme promesses séparées.
Europe, Washington et Londres proposent des voies différentes
Le cadre européen de l’AI Act répartit déjà les obligations par risque, avec documentation, transparence et exigences systémiques des modèles généraux. Le Bureau de l’IA peut demander des pièces, évaluer, imposer des corrections et sanctionner les manquements. L’IA n’est donc pas totalement non réglementée.
La couverture varie toutefois par juridiction, secteur, système et date. Les États-Unis privilégient souvent engagements volontaires et protections sectorielles, rapides à adapter mais définis par les entreprises, avec peu de preuves externes. Une autorisation rigide peut vieillir avant son achèvement ; des principes vagues peuvent manquer de prise.
Des devoirs durables associés à des normes techniques adaptables offrent un équilibre. Risques, signalement, permissions et évaluation indépendante n’exigent pas de prescrire chaque méthode. Les organismes techniques actualisent les tests et les régulateurs gardent leurs pouvoirs. Bacs à sable et ressources communes peuvent aider les petites entreprises.
Smith estime que Londres dispose d’une opportunité parce que Washington la voit différemment de Bruxelles. Les autorités britanniques préparaient une surveillance renforcée, mais la source n’établit pas une nouvelle loi achevée. Il faut préciser systèmes, responsables, seuils, preuves et pouvoirs, ou rester dans le volontariat. La concurrence américaine avec la Chine ajoute une pression de vitesse sans supprimer les conséquences sécuritaires.
Les règles doivent aussi contraindre Microsoft
L’inquiétude commerciale est légitime. Les grands groupes ont déjà équipes de conformité, infrastructures et relations publiques. Des règles validant ces structures pourraient charger disproportionnellement les petits concurrents et transformer la sécurité en barrière. Cela n’invalide pas les risques, mais oblige à examiner les incitations.
Les exigences doivent suivre capacités, contrôle et risques démontrés, non seulement taille ou exemption automatique d’un mode de distribution. Les modèles ouverts ont d’autres frontières. Une restriction trop large concentre le développement ; une règle faible permet l’évasion par changement de distribution.
Microsoft devrait donc identifier ses contrôles, leurs tests et les déclencheurs d’escalade. Les contrats doivent clarifier partage entre Microsoft, partenaires de modèles, développeurs et clients. Des principes publics accompagnés d’un transfert total des conséquences saperaient l’argument des victimes.
Les essais indépendants devraient couvrir services connectés, révocation sélective, reconstitution et récupération, avec preuves comparables sur périmètre et défaillances. Il n’est pas nécessaire d’exposer poids propriétaires ou défenses sensibles, mais les clients doivent comparer les limites et vérifier que les administrateurs disposent réellement des contrôles prônés.
Une base de connaissances IA interrogeable conserve usages approuvés, responsables et décisions, sans remplacer le confinement. Les prochaines preuves sont des propositions britanniques concrètes, des freins testés indépendamment et des responsabilités couvrant la chaîne. La comparaison comptera si elle produit des obligations et recours exécutoires, y compris pour Microsoft, pas seulement une formule mémorable.