Microsoft impose un code de conduite à ses modèles IA

Un cadre de comportement au moment où l’IA devient un enjeu de gouvernance

Microsoft veut préciser ce que ses modèles d’intelligence artificielle doivent, et ne doivent pas, faire. Selon l’article de TechCrunch AI intitulé “Microsoft’s new AI ‘code of conduct’ tells models not to hack systems or trick humans”, l’entreprise a formalisé un ensemble de principes de comportement qui interdit notamment à ses systèmes de pirater des infrastructures ou de tromper des personnes.

L’annonce paraît simple dans sa formulation, presque évidente : un outil d’IA ne devrait ni s’introduire dans un système informatique, ni induire un humain en erreur. Mais elle intervient dans un contexte où les capacités attribuées aux modèles les plus avancés suscitent une attention croissante. À mesure que les assistants conversationnels savent rédiger du code, analyser des documents, interagir avec des outils logiciels ou exécuter des tâches en plusieurs étapes, la question ne porte plus seulement sur la qualité de leurs réponses. Elle concerne aussi le type d’actions que ces systèmes peuvent recommander, faciliter ou, dans certaines architectures, réaliser.

Le texte évoqué par TechCrunch ne constitue pas une loi ni un accord international. Il s’agit d’un cadre interne, volontaire, élaboré par Microsoft pour guider la conception et le déploiement de ses modèles. Cette différence est fondamentale. Une règle interne peut influencer les choix de produit, les mécanismes de sécurité, les jeux de tests et les décisions de mise à disposition. Elle ne bénéficie toutefois ni de la force obligatoire d’un texte réglementaire, ni de mécanismes publics automatiques de contrôle comparables à ceux qui accompagnent une obligation légale.

La démarche s’inscrit dans une évolution plus large de l’industrie. Les entreprises qui développent des modèles d’IA généralistes publient de plus en plus souvent des principes, des politiques d’usage, des documents de sûreté ou des cadres de comportement. Ces textes cherchent à rendre plus visibles les limites que les concepteurs veulent imposer à leurs systèmes. Ils répondent aussi à une pression croissante : celle des utilisateurs, des chercheurs, des régulateurs et des responsables politiques qui demandent comment des modèles puissants sont entraînés, testés et empêchés de produire des effets nuisibles.

Microsoft occupe une position singulière dans ce débat. Le groupe commercialise des produits destinés au grand public, aux développeurs et aux grandes organisations. Ses services de cloud, ses outils de productivité et ses offres liées à l’IA le placent au cœur de nombreux environnements professionnels. Quand l’entreprise décrit des comportements interdits pour ses modèles, le sujet dépasse donc la seule conversation entre un utilisateur et un chatbot. Il concerne potentiellement la manière dont des outils d’IA sont intégrés à des logiciels, à des flux de travail, à des environnements de programmation et à des systèmes d’information.

Le choix des exemples mis en avant est révélateur. Le piratage renvoie au risque de voir une IA générer des instructions, automatiser des séquences ou aider à contourner des protections. La tromperie des humains renvoie à une autre famille de risques : faux prétextes, manipulation, impersonation, dissimulation de l’identité ou présentation trompeuse de capacités et de résultats. Derrière ces deux interdictions, Microsoft semble vouloir affirmer une ligne : l’IA doit rester un outil d’assistance au service de personnes identifiables et responsables, plutôt qu’un acteur autonome autorisé à poursuivre ses propres objectifs.

Cette distinction entre assistance et remplacement sans supervision constitue un point central du débat. Un modèle peut aider un professionnel à résumer un dossier, préparer une réponse, rechercher des éléments dans une base de connaissances ou produire une première version de code. La situation devient plus sensible si le système prend seul des décisions affectant des personnes, s’il agit sur des ressources numériques ou s’il interagit avec des tiers sans qu’un humain comprenne clairement son rôle, ses limites et les conséquences de ses choix.

Ce que Microsoft demande à ses modèles de ne pas faire

D’après TechCrunch, le code de conduite de Microsoft énonce des attentes de comportement à l’égard des modèles. Parmi les règles les plus marquantes figure l’interdiction de pirater des systèmes. Dans le langage de la cybersécurité, le terme couvre des réalités diverses : exploitation de vulnérabilités, accès non autorisé à des comptes ou à des machines, contournement de mécanismes de protection, exfiltration de données, ou encore actions préparatoires destinées à compromettre une infrastructure. Le principe formulé par Microsoft ne résout pas à lui seul chacun de ces cas, mais il fixe un objectif normatif clair : l’outil ne doit pas être conçu comme un participant à une intrusion informatique.

Une telle règle soulève immédiatement une difficulté pratique. Les modèles de langage peuvent répondre à des questions légitimes de défense informatique, par exemple expliquer un correctif, analyser un journal d’événements, aider à comprendre une vulnérabilité ou produire du code de test. Les mêmes connaissances peuvent, selon le contexte, servir à renforcer une protection ou à préparer une attaque. Un code de conduite doit donc être traduit en décisions beaucoup plus précises : quelles demandes sont refusées, lesquelles sont redirigées vers une explication défensive, quelles capacités nécessitent une validation supplémentaire, et comment l’entreprise traite les tentatives de contournement.

Le deuxième principe mis en avant par TechCrunch est l’interdiction de tromper les humains. Cette formulation touche à la confiance, qui est devenue un problème central pour les systèmes génératifs. Un modèle peut produire un texte affirmatif alors qu’il se trompe, imiter un style, présenter une réponse plausible sans disposer de preuve, ou être intégré à une interface qui rend ambigu le rôle de l’automatisation. La tromperie intentionnelle, si elle est distinguée de l’erreur, pose une question encore plus exigeante : comment concevoir un système qui ne cherche pas à induire l’utilisateur en erreur, sans prétendre qu’il sera toujours exact ?

Dans les produits destinés au grand public comme dans les outils d’entreprise, la réponse passe généralement par plusieurs couches. Il y a la formulation des consignes données au modèle, les filtres de sécurité, les garde-fous installés autour du service, la conception de l’interface, les avertissements présentés aux utilisateurs et les dispositifs d’évaluation. Aucun de ces éléments n’est suffisant isolément. Une politique écrite peut être contournée par une requête inhabituelle ; un filtre peut produire des faux positifs ou des faux négatifs ; une interface peut encourager une confiance excessive ; un utilisateur peut ignorer une alerte. Le comportement observé est le résultat de cet ensemble, pas du seul texte publié.

Le code insiste également, selon les éléments rapportés, sur une IA conçue pour assister les personnes plutôt que les remplacer sans supervision. Le vocabulaire est important. Il ne dit pas que l’automatisation est exclue, ni qu’un système ne pourra jamais réaliser de tâches complexes. Il pose plutôt une préférence de conception : conserver l’humain comme point de contrôle, particulièrement lorsqu’une action a des conséquences importantes. Cela rejoint une idée fréquemment invoquée dans les débats sur l’IA : les systèmes doivent renforcer la capacité d’action humaine, et non faire disparaître la possibilité de comprendre, contester ou corriger une décision.

Cette ambition est plus difficile à appliquer qu’à énoncer. Une supervision réelle ne signifie pas seulement qu’un humain peut théoriquement cliquer sur un bouton. Elle suppose que cette personne dispose du temps, des informations et des compétences nécessaires pour évaluer la recommandation du système. Si un salarié reçoit des centaines de suggestions automatisées, si les réponses sont trop techniques, ou si la pression opérationnelle pousse à valider rapidement, l’intervention humaine peut devenir symbolique. Le risque n’est alors pas une autonomie officielle du modèle, mais une automatisation de fait, masquée par une validation humaine peu substantielle.

TechCrunch décrit ainsi un texte qui vise à donner une direction morale et opérationnelle à l’IA de Microsoft. Mais l’intérêt journalistique de cette publication se situe moins dans l’énoncé abstrait de principes consensuels que dans la manière dont ils seront transposés dans les produits. Interdire au modèle de tromper, pirater ou agir contre l’intérêt de l’utilisateur est une promesse de conception. Sa valeur dépendra du niveau de précision des règles internes, de la qualité des évaluations avant et après déploiement, ainsi que de la capacité de l’entreprise à reconnaître publiquement les limites de ses propres protections.

Du principe au produit : les limites d’un « code de conduite »

Un code de conduite appliqué à un modèle n’est pas l’équivalent d’un règlement que la machine lirait et respecterait mécaniquement. Les modèles génératifs ne fonctionnent pas comme des logiciels classiques composés d’une succession de règles explicites. Ils produisent des réponses à partir de calculs statistiques issus de leur entraînement et de leur configuration. Les comportements recherchés sont donc influencés par les données, les méthodes d’entraînement, les instructions système, les mécanismes de filtrage, les outils auxquels le modèle peut accéder et les conditions dans lesquelles il est utilisé.

Cette réalité oblige à distinguer l’intention, la politique et l’application. L’intention est le principe annoncé par Microsoft : ne pas pirater, ne pas tromper, assister plutôt que remplacer sans supervision. La politique est la traduction de cette intention en catégories de demandes autorisées, limitées ou refusées. L’application est enfin ce qui se passe devant un utilisateur concret, qui peut formuler une requête ambiguë, séquencer plusieurs demandes ou employer un outil développé par un tiers autour du modèle.

Les cas limites sont inévitables. Un chercheur en cybersécurité peut demander une analyse technique utile à la défense. Un administrateur informatique peut chercher à comprendre comment réagir à un incident. Un développeur peut solliciter du code qui, hors contexte, pourrait être utilisé de façon offensive. À l’autre extrémité, une personne malveillante peut présenter sa demande comme un exercice pédagogique ou fractionner son objectif en petites étapes. Un cadre crédible ne se juge donc pas uniquement à sa déclaration d’interdiction, mais à sa capacité à traiter ces ambiguïtés de manière cohérente sans priver les professionnels légitimes d’outils utiles.

La même difficulté existe pour la tromperie. Il est relativement aisé d’affirmer qu’un modèle ne doit pas mentir. Il est plus compliqué de déterminer comment un système doit répondre lorsqu’il ne sait pas, lorsque ses sources sont incomplètes, lorsqu’un utilisateur exige une réponse certaine ou lorsqu’il est invité à endosser une identité fictive. Dans de nombreux cas, le comportement responsable consiste moins à fournir une interdiction brute qu’à signaler l’incertitude, demander des précisions, refuser une usurpation ou orienter vers une vérification indépendante.

Le débat recouvre également la question des agents d’IA, c’est-à-dire des systèmes qui ne se limitent pas à générer du texte mais peuvent enchaîner des actions au moyen d’outils logiciels. Plus un modèle peut consulter des services, manipuler des données, envoyer des messages, exécuter du code ou opérer dans un environnement numérique, plus les principes de comportement doivent être accompagnés de permissions strictes. Un agent qui ne peut théoriquement pas agir sans autorisation explicite n’expose pas le même risque qu’un agent doté d’un accès étendu à des comptes ou à des ressources sensibles.

Dans ce contexte, l’enjeu est celui des mécanismes concrets de contrôle. Un code de conduite peut être utile s’il entraîne des restrictions d’accès, des validations humaines, une journalisation des actions, des tests dédiés aux scénarios d’abus et des procédures de suspension lorsque des comportements dangereux sont détectés. Il reste en revanche difficile à évaluer de l’extérieur si l’entreprise ne détaille pas la manière dont ces engagements sont mesurés et appliqués.

Le modèle économique ajoute une tension supplémentaire. Les entreprises attendent de l’IA qu’elle augmente la productivité, accélère certaines opérations et réduise le temps consacré aux tâches répétitives. Ces objectifs peuvent encourager une délégation toujours plus large. À l’inverse, le principe d’assistance sous supervision implique parfois de conserver des étapes de contrôle qui réduisent le gain de temps apparent. Microsoft devra donc arbitrer entre l’ambition commerciale des outils intégrés aux activités quotidiennes et l’exigence de ne pas présenter l’automatisation comme une substitution sans risque au jugement humain.

Cette tension ne concerne pas seulement Microsoft. Elle traverse l’ensemble du secteur des modèles avancés. Les éditeurs veulent démontrer que leurs systèmes sont utiles dans des tâches réelles, tandis que les critiques demandent quelles limites sont fixées avant que les outils soient confiés à des processus sensibles. La publication d’un code de conduite marque une volonté de répondre à cette interrogation. Mais elle ne transforme pas, par elle-même, une promesse de comportement en garantie technique universelle.

Une initiative volontaire dans un paysage réglementaire fragmenté

La publication intervient alors que le développement des IA avancées fait l’objet d’un débat public intense. Des chercheurs, des dirigeants technologiques, des organisations de la société civile et des responsables publics divergent sur le rythme auquel ces systèmes doivent être développés et déployés. Certains mettent l’accent sur les bénéfices économiques, scientifiques et organisationnels. D’autres alertent sur les risques liés à la désinformation, à la cybersécurité, à la concentration du pouvoir technologique, aux biais ou à la délégation de décisions importantes à des systèmes difficiles à auditer.

Dans ce paysage, les codes internes jouent un rôle ambigu. Ils peuvent constituer une étape positive, en obligeant les entreprises à expliciter les comportements qu’elles considèrent inacceptables et à structurer leurs équipes autour d’objectifs communs. Ils peuvent aussi rester insuffisants si aucune instance indépendante ne peut vérifier leur respect. Une entreprise peut modifier ses politiques, faire évoluer ses produits ou interpréter ses propres principes selon les contextes. L’utilisateur, lui, ne dispose pas forcément des éléments nécessaires pour apprécier la robustesse des garanties.

La comparaison avec le cadre européen est éclairante. L’Union européenne a adopté l’AI Act, un règlement qui repose notamment sur une approche par les risques. Le texte établit des obligations pour certains systèmes d’IA et prévoit des exigences plus importantes pour les usages considérés comme présentant un risque élevé. Contrairement à un code de conduite d’entreprise, ce cadre relève du droit européen et s’inscrit dans une logique de contrôle, de conformité et de responsabilité.

L’AI Act ne se confond toutefois pas avec le document de Microsoft. Le règlement européen ne formule pas simplement une liste de vertus souhaitables pour les modèles. Il organise des catégories juridiques, des obligations et des interdictions, avec une application progressive de ses dispositions. Son entrée en vigueur a eu lieu en 2024, tandis que plusieurs obligations sont prévues selon un calendrier échelonné. Cette architecture montre que la régulation de l’IA ne peut pas reposer uniquement sur le bon vouloir des entreprises, même si les engagements volontaires peuvent compléter les exigences réglementaires.

Pour les acteurs européens et français, la coexistence de ces deux niveaux est déterminante. D’un côté, un fournisseur mondial peut imposer ses propres règles de comportement à des modèles accessibles dans ses produits. De l’autre, les entreprises qui utilisent ces produits restent soumises à leurs obligations sectorielles, à la protection des données, au droit du travail, aux exigences contractuelles et, selon les cas, au droit européen de l’IA. Un code publié par Microsoft ne transfère pas automatiquement la responsabilité de l’usage vers le fournisseur ni vers le client : cette répartition dépend des produits, des contrats, des rôles de chacun et du cadre juridique applicable.

Il existe aussi une différence de temporalité. Une entreprise peut mettre à jour rapidement le comportement d’un modèle, modifier une interface ou renforcer un filtre après avoir identifié un problème. Le droit évolue généralement plus lentement, car il doit être débattu, adopté, interprété et appliqué. Mais cette lenteur relative est compensée par une autre propriété : la règle juridique peut être opposable et s’imposer à des acteurs qui n’auraient pas spontanément intérêt à adopter les mêmes précautions.

Les autorités et les législateurs ne peuvent pas non plus se contenter d’interdictions générales. Comme dans les codes internes, l’efficacité réglementaire repose sur des définitions, des mécanismes de preuve, des autorités compétentes et des sanctions crédibles. La difficulté est accentuée par la dimension transfrontière de l’IA. Un modèle peut être développé dans un pays, entraîné sur des infrastructures réparties entre plusieurs territoires, proposé depuis un cloud international et utilisé par une organisation française dans des processus qui affectent des citoyens européens. Aucune politique d’entreprise ne résout à elle seule cette fragmentation.

Le cas Microsoft illustre donc une réalité plus large : l’industrie avance à la fois par auto-encadrement et sous la pression des cadres publics. Le premier peut accélérer la mise en place de pratiques de sécurité. Le second vise à établir un socle commun, y compris pour les entreprises qui n’adopteraient pas volontairement des standards élevés. La question essentielle est de savoir si ces deux dynamiques se renforcent ou si les déclarations de principes servent à retarder des obligations plus précises.

Ce que les entreprises françaises doivent regarder au-delà du texte

Pour une organisation française qui utilise des services d’IA fournis par Microsoft, l’annonce mérite d’être lue comme un signal de gouvernance plutôt que comme une garantie absolue. Le fait qu’un fournisseur affirme que ses modèles ne doivent pas pirater ou tromper est pertinent, notamment pour les équipes de sécurité, de conformité et de gestion des risques. Mais il ne dispense pas l’entreprise utilisatrice d’évaluer ses propres paramètres, ses accès, ses données et les usages autorisés à ses salariés.

La première question concerne les données confiées aux outils. Lorsqu’un assistant peut accéder à des documents internes, à des bases de connaissances ou à des ressources d’entreprise, le principe de moindre privilège reste essentiel : ne donner que les accès nécessaires à une tâche déterminée. La sécurité ne dépend pas uniquement du comportement attendu du modèle. Elle dépend aussi de l’identité de l’utilisateur, des droits disponibles, de la segmentation des environnements, de la qualité de l’authentification et de la traçabilité des opérations.

La deuxième question concerne le niveau de supervision. Dans les organisations, le mot « assistant » peut recouvrir des usages très différents. Un outil qui prépare un brouillon de courrier ne présente pas les mêmes enjeux qu’un dispositif qui recommande une décision de recrutement, aide à trier des demandes de clients, produit une analyse financière ou génère du code destiné à un système en production. Plus les effets d’une erreur sont élevés, plus le contrôle humain doit être concret, documenté et confié à des personnes en capacité de contester le résultat.

La troisième question porte sur la formation. Une promesse de non-tromperie ne doit pas conduire les utilisateurs à croire que les réponses sont systématiquement exactes. Les salariés ont besoin de savoir qu’un système génératif peut se tromper, simplifier à l’excès ou produire un contenu convaincant sans garantie suffisante. Ils doivent aussi comprendre les limites de confidentialité, les règles internes de partage d’information et les situations où une vérification humaine ou une expertise spécialisée demeure indispensable.

Pour les équipes de cybersécurité, le code de conduite de Microsoft appelle une vigilance particulière. L’interdiction de pirater des systèmes peut réduire le risque que l’outil réponde à certaines demandes manifestement malveillantes. Elle ne fait pas disparaître la nécessité d’une défense active. Les attaquants n’ont pas besoin qu’un fournisseur légitime leur donne accès à toutes les capacités souhaitées ; ils peuvent utiliser d’autres outils, des méthodes traditionnelles ou des sources non contrôlées. Les entreprises doivent donc continuer à surveiller les comportements anormaux, gérer les vulnérabilités, contrôler les accès et préparer leur réponse aux incidents.

Du côté des fournisseurs français et européens d’IA, la démarche de Microsoft peut contribuer à faire monter les attentes du marché. Les clients demanderont davantage de précisions sur les comportements interdits, les procédures de red teaming, les modalités de signalement d’incidents, la conservation des traces et les contrôles d’accès aux fonctions sensibles. Cette exigence peut représenter une charge pour les acteurs plus petits, mais elle peut aussi devenir un facteur de différenciation : la transparence sur les limites d’un produit et sur sa gouvernance peut peser dans les choix d’achat, notamment dans les secteurs régulés.

La question de la langue et du contexte culturel reste également importante pour le marché francophone. Les politiques de comportement doivent fonctionner dans des formulations variées, y compris en français, avec ses nuances, ses références administratives, ses usages professionnels et ses ambiguïtés. Un dispositif de sécurité performant en anglais n’est pas automatiquement aussi robuste dans toutes les langues. Les utilisateurs français ont donc intérêt à évaluer les réponses, les refus et les mécanismes d’alerte dans leurs cas d’usage réels, plutôt que de supposer que les principes généraux se traduisent uniformément dans chaque environnement linguistique.

Enfin, la publication du code renvoie à une responsabilité de gouvernance interne. Une direction ne peut pas déléguer à un fournisseur la définition complète de ce qui est acceptable dans son organisation. Elle doit déterminer quels usages sont permis, quelles données sont exclues, qui valide les déploiements, comment les erreurs sont remontées et à quel moment un outil doit être désactivé. Le code de Microsoft peut fournir un point d’appui, mais il ne remplace ni une politique d’IA propre à l’entreprise ni une analyse de risques adaptée à ses métiers.

La crédibilité se jouera sur les preuves, les incidents et la capacité à corriger

La perspective à long terme dépasse le cas d’un seul document publié par Microsoft. Les modèles d’IA vont continuer à être intégrés dans des logiciels, des postes de travail, des services en ligne et des processus d’entreprise. À mesure que leurs interfaces deviennent plus naturelles et que leur capacité à utiliser des outils se développe, les principes de comportement devront être traduits en contraintes techniques visibles. Un code de conduite aura d’autant plus de valeur qu’il sera associé à des permissions limitées, à des validations explicites, à des mécanismes d’arrêt et à une capacité de contrôle après coup.

Le critère décisif sera la vérifiabilité. Les utilisateurs, clients, régulateurs et chercheurs auront besoin de savoir non seulement ce que les modèles sont censés faire, mais aussi comment l’entreprise évalue les écarts. Cela implique des tests portant sur les tentatives de piratage, sur les demandes de manipulation, sur les scénarios de contournement et sur les erreurs susceptibles de créer une confiance injustifiée. Cela implique aussi de pouvoir mesurer les refus abusifs, qui peuvent pénaliser les usages légitimes, et les réponses dangereuses, qui peuvent faciliter des abus.

Dans un secteur marqué par une compétition technologique et commerciale intense, il sera difficile pour les entreprises de maintenir des limites crédibles si celles-ci sont perçues comme des freins face à des concurrents plus permissifs. C’est précisément pourquoi les règles communes, les obligations de transparence et les mécanismes de responsabilité comptent. Une entreprise peut annoncer des principes exigeants ; elle sera néanmoins confrontée à la pression des marchés, aux demandes de clients et aux attentes autour de nouvelles fonctionnalités. La cohérence entre les déclarations et les décisions de déploiement deviendra un indicateur central.

La formulation de Microsoft, rapportée par TechCrunch, a au moins le mérite de placer explicitement deux lignes rouges dans le débat : ne pas aider à compromettre des systèmes et ne pas chercher à tromper les personnes. Elle rappelle également que l’IA doit être conçue comme une assistance, non comme une autorité autonome dépourvue de supervision. Ces points ne constituent pas un consensus technique facile à mettre en œuvre ; ils dessinent plutôt un terrain sur lequel les fournisseurs devront rendre des comptes.

Pour la France et l’Europe, l’enjeu sera d’éviter deux écueils. Le premier serait de traiter les chartes d’entreprise comme des substituts suffisants à la régulation et au contrôle indépendant. Le second serait d’ignorer leur utilité concrète dans la conception quotidienne des produits. Les politiques internes peuvent modifier rapidement des comportements et orienter les investissements de sécurité. Elles deviennent réellement significatives lorsqu’elles sont confrontées à des audits, à des retours d’usage, à des obligations juridiques et à la possibilité d’être corrigées publiquement.

Le débat sur un éventuel ralentissement du développement des IA avancées ne sera donc pas tranché par la seule publication de principes. Il continuera de porter sur la vitesse de déploiement, le niveau d’autonomie accordé aux systèmes, la préparation des institutions et la répartition des responsabilités lorsqu’une IA échoue. Dans cette perspective, le code de conduite de Microsoft vaut moins comme point final que comme test : celui de la capacité des grands fournisseurs à prouver que les limites affichées résistent à l’augmentation des capacités, à la complexité des usages et à la pression concurrentielle.