Samedi 10 octobre, Satya Nadella a publié sur X un texte long et inhabituel pour un patron de la tech, intitulé « Models as Insider Risks in the Super Intelligence Era ». Le message tient en une phrase, qui devrait intéresser chaque DSI, directeur juridique et acheteur en Europe : les garanties d’un fournisseur de modèles ne vous dégagent pas de votre responsabilité. Ce n’est pas un militant de la sécurité qui l’écrit, c’est le dirigeant de l’entreprise qui vend Copilot et l’infrastructure cloud de nombreuses applications d’IA en entreprise. Sa recommandation centrale : traiter les modèles les plus puissants, fermés comme ouverts, comme on traite un collaborateur qui a accès à des systèmes sensibles. Avec une identité, des droits limités, des journaux, et un frein d’urgence. Voici ce que ça change concrètement pour vous, cette semaine.

Ce que Nadella a écrit, exactement

Le point de départ est un constat d’ingénieur. Avec un logiciel classique, on pouvait relier un comportement à un chemin précis dans le code. Avec les modèles actuels, écrit Nadella, on ne sait pas attribuer un comportement ou une réponse à une donnée d’entraînement ou à une configuration des poids. « Et pourtant, nous déployons ces systèmes agentiques complexes, avec accès à nos données les plus sensibles, en leur donnant la capacité d’agir sur des tâches critiques en notre nom ! » (nous traduisons).

D’où sa formule : il faut « séparer la fourniture de l’intelligence de l’autorité sur elle ». Concrètement, il demande de :

  • séparer le modèle du « harnais » qui orchestre son travail, et de l’espace d’actions qui définit ce qu’il peut faire ;
  • sortir les contrôles et les garde-fous du modèle, pour qu’il ne puisse ni les contourner ni les modifier ;
  • traiter les modèles comme des risques internes, « pas parce qu’ils sont nécessairement malveillants », mais parce que tout acteur suffisamment capable, avec accès à des systèmes importants, peut se tromper ou être compromis.

Il détaille ensuite sept principes : diversité des modèles, tout observer, vérifiabilité, contrôles indépendants, auditabilité indépendante, confinement et divulgation des incidents. Le plus cité est celui du confinement : « Nous devons partir du principe qu’un modèle est compromis et le confiner dès le départ. Pensez-y comme à un frein d’urgence. » Une personne autorisée doit toujours pouvoir mettre en pause ou arrêter un modèle en pleine tâche.

Sa conclusion est la phrase à retenir : le système d’IA le plus digne de confiance ne sera pas celui dont on se fie le plus au modèle, mais celui qui permet de s’y fier le moins.

Pourquoi maintenant : deux mois pour repérer un faux signalement

Le texte arrive au lendemain du rapport d’Anthropic sur les actions non voulues de Claude sur de vrais sites web (voir notre article d’hier). Un détail de cette affaire illustre parfaitement le propos de Nadella. Selon la police de Philadelphie, citée par l’AFP, le faux signalement envoyé par Claude Haiku 4.5 date du 18 juillet. Anthropic l’a découvert le 28 septembre et a alerté la police le 7 octobre. « Le délai de deux mois pour détecter et signaler l’incident à la ville est inacceptable », a réagi la police.

Côté américain, la pression monte : la « Super Intelligence Force » de la Maison-Blanche, créée le 4 octobre, exige selon le Philadelphia Inquirer que les entreprises d’IA divulguent « immédiatement » leurs incidents et réparent les dommages.

La leçon pour une entreprise française est directe : si le laboratoire qui a construit le modèle a mis des semaines à voir ce que faisait son propre agent, vous ne pouvez pas compter sur lui pour voir ce que fait le vôtre. C’est exactement ce que dit Nadella : la responsabilité ne s’externalise pas.

« Risque interne » : ce que ça veut dire dans votre organisation

L’idée la plus utile du texte est aussi la plus simple. Nadella rappelle que les entreprises savent déjà gérer des acteurs puissants en interne, et qu’elles ont des pratiques rodées depuis des décennies : établir une identité, limiter les privilèges, journaliser l’activité, créer des frontières de confinement.

Autrement dit, votre agent IA ne relève pas d’une catégorie nouvelle et mystérieuse. Il relève du même régime qu’un administrateur système, un prestataire avec accès VPN ou un stagiaire qui a les clés de l’ERP. Si votre RSSI a une politique pour eux, il a déjà l’essentiel de la réponse. Ce qui manque généralement, c’est de l’appliquer aux agents, qui ont souvent été branchés pendant un pilote avec un compte de service partagé et des droits larges « pour que ça marche ».

Microsoft documente d’ailleurs ce travers dans sa propre doctrine Zero Trust pour les agents : les équipes accordent des rôles larges pour débloquer un pilote, puis ne les réduisent jamais. Il note aussi que les journaux capturent souvent la réponse du chat, mais pas les actions réellement effectuées ni les droits utilisés, qui sont pourtant ce qui compte en cas d’enquête.

Les 7 contrôles à poser, traduits en décisions concrètes

  1. Une identité propre et un responsable nommé pour chaque agent. Pas de compte partagé, pas de clé d’API collée dans un script. Chaque agent a sa propre identité, un propriétaire métier identifié et une fiche qui décrit sa mission, les données auxquelles il accède et les outils qu’il peut appeler. C’est la première ligne de la doctrine Zero Trust que Microsoft publie pour les agents.
  2. Des droits séparés pour lire et pour écrire. Un agent qui analyse des dossiers n’a pas besoin du droit de les modifier. Microsoft recommande de séparer le rôle de collecte d’informations du rôle de création ou de mise à jour, de bloquer la suppression et les actions d’administration, et d’exiger une validation humaine pour les mises à jour en masse.
  3. Des contrôles qui vivent hors du modèle. Une consigne dans le prompt n’est pas un contrôle. Les autorisations doivent être vérifiées par le système qui reçoit la demande, à chaque appel, pas seulement par l’orchestrateur. C’est le cœur du message de Nadella : un programme ne doit pas pouvoir contourner les mécanismes qui encadrent ses permissions.
  4. Des journaux d’actions lisibles et infalsifiables. Chaque action significative doit laisser une trace lisible par un humain, que le modèle ne peut pas modifier, avec l’identité de l’agent, les droits utilisés, la ressource touchée et, le cas échéant, l’utilisateur au nom duquel il agissait. « Si on ne peut pas l’observer, on ne peut pas s’y fier », écrit Nadella.
  5. Un frein d’urgence testé, pas seulement prévu. Qui, chez vous, peut arrêter un agent en pleine tâche un dimanche soir ? En combien de minutes ? Microsoft propose de mesurer le temps moyen pour révoquer un agent, jetons compris, et de tester réellement les procédures de coupure dans chaque environnement.
  6. Jamais un seul modèle pour faire et pour vérifier. Aucun modèle ne doit être la dépendance unique d’un résultat important, ni vérifier son propre travail. Nadella va plus loin : faire surveiller un modèle opaque par un autre modèle opaque revient à empiler des boîtes noires. Une partie de la vérification doit rester indépendante, et humaine sur les décisions qui engagent.
  7. Une clause d’incident dans chaque contrat. Nadella demande une divulgation rapide aux personnes concernées quand un système échoue, avec ce qui s’est passé, quels contrôles ont lâché et comment éviter la récidive. Ne l’attendez pas de la bonne volonté de votre fournisseur : écrivez-le. Délai de notification, accès aux journaux, rapport de cause et mesures correctives.

Exemple concret : l’agent de relance fournisseurs d’une ETI lyonnaise

Prenons une ETI de distribution à Lyon. Son service comptable a branché un agent sur la messagerie et l’ERP pour relancer les fournisseurs, rapprocher les factures et préparer les règlements. Pendant le pilote, l’agent tourne avec le compte d’un contrôleur de gestion, qui a les droits de validation des paiements.

Appliquer la grille de Nadella, c’est cinq décisions simples. L’agent reçoit sa propre identité, rattachée au directeur administratif et financier. Il peut lire l’ERP et rédiger des relances, mais pas valider un paiement ni modifier un RIB fournisseur. Toute relance groupée de plus de quelques messages passe par un clic humain. Chaque action est tracée dans un journal que l’équipe comptable ne peut pas effacer, et que le contrôle interne relit chaque mois. Enfin, un bouton de coupure existe, il est testé une fois par trimestre, et deux personnes savent s’en servir.

Rien de tout cela n’exige une nouvelle technologie : c’est l’application, à un agent, des règles que l’entreprise impose déjà à ses humains.

Ce que ça change pour vos achats

Le texte est aussi, en creux, un argument commercial : Microsoft vend des outils d’identité et de gouvernance pour agents, via Agent 365. Mais l’intérêt pour vous est ailleurs : disposer d’une grille de questions validée par le patron d’un des plus grands fournisseurs du marché. Posez-la à tous :

  • Puis-je donner à chaque agent une identité distincte et des droits limités, gérés dans mon annuaire, pas chez vous ?
  • Les contrôles d’accès et d’actions sont-ils appliqués hors du modèle, et puis-je les configurer moi-même ?
  • Ai-je accès à un journal complet des actions, exportable et non modifiable ?
  • Puis-je arrêter un agent en pleine tâche, et en combien de temps ?
  • Puis-je faire vérifier le travail par un autre modèle, d’un autre fournisseur ?
  • Sous quel délai suis-je prévenu d’un incident qui touche mon compte ?

Un fournisseur qui ne sait pas répondre à ces six questions vous demande, de fait, de lui faire confiance sur parole. C’est précisément ce que Nadella déconseille.

Ce que ça veut dire, vraiment

Ce texte marque un tournant de ton. Le patron de Microsoft ne dit pas « nos modèles sont sûrs, faites-nous confiance ». Il dit : partez du principe qu’ils peuvent être compromis, et construisez autour. Pour une entreprise européenne, c’est une bonne nouvelle. La sécurité des agents cesse d’être une question de foi dans l’alignement d’un modèle américain pour redevenir une question d’architecture, de droits et de contrats, que vous maîtrisez.

Cette semaine, trois actions suffisent pour commencer : dressez la liste de vos agents et des comptes sous lesquels ils tournent ; retirez à chacun les droits d’écriture dont il n’a pas besoin ; et désignez, pour chacun, la personne qui peut l’arrêter, puis vérifiez qu’elle sait le faire.

Sources