Le code de conduite MAI de Microsoft transforme l'offensive de Satya Nadella sur la superintelligence en promesse vérifiable

Satya Nadella a annoncé un code de conduite MAI de Microsoft tout en appelant de ses vœux un ralentissement réfléchi afin d'aligner les projets concurrents de superintelligence du secteur. Le PDG de Microsoft a soumis la poursuite du développement à deux conditions : l'IA avancée doit aider l'humanité et les personnes doivent en conserver le contrôle.

Cette position place Microsoft entre deux camps de plus en plus visibles. Le premier réclame des contrôles plus stricts avant que les systèmes n'acquièrent davantage d'autonomie. Le second soutient qu'une large diffusion de l'IA avancée offre la meilleure protection contre la concentration du contrôle.

Nadella tente de concilier ces deux positions. Microsoft veut continuer à développer des modèles de pointe tout en présentant le contrôle humain comme une condition du progrès, et non comme un frein. Cet équilibre paraît raisonnable, mais il ne prendra sens que lorsque l'entreprise publiera des règles applicables, des évaluations et des limites de mise à disposition.

L'annonce intervient alors que les dirigeants de l'IA débattaient de la capacité des systèmes de sécurité à suivre le rythme des progrès des modèles. Le PDG d'Anthropic, Dario Amodei, avait appelé à ralentir suffisamment le développement pour que les garde-fous puissent rattraper leur retard. Meta, de son côté, a défendu une superintelligence personnelle largement distribuée comme moyen de préserver le pouvoir individuel.

La réponse de Microsoft n'est ni une pause ni une course sans restrictions. C'est une promesse de poursuivre le développement, sous réserve d'un code qui devrait définir ce que l'entreprise ne déploiera pas. La question centrale est de savoir si cette promesse modifie le développement des modèles ou seulement la manière dont Microsoft le décrit.

Ce que Satya Nadella a réellement annoncé

Microsoft a transformé sa philosophie sur la superintelligence en engagement de gouvernance, bien que les détails opérationnels restent incomplets.

Dans une déclaration du 13 septembre mise en avant par l'annonce de Nadella, le PDG a déclaré que Microsoft accueillait favorablement le rythme délibéré nécessaire pour parvenir à l'alignement. L'alignement consiste à maintenir le comportement d'un système d'IA en cohérence avec les objectifs et les limites humaines, en particulier à mesure que ses capacités progressent.

Nadella a présenté le contrôle humain comme un préalable à la poursuite de la superintelligence. Si un système n'aide pas l'humanité et ne reste pas sous direction humaine, a-t-il soutenu, il ne mérite pas d'être construit. Il a également affirmé que les bénéfices de l'IA devraient s'étendre aux pays et aux communautés.

Cette combinaison est importante. Un appel au contrôle peut justifier des restrictions plus strictes, tandis qu'un appel à une large diffusion peut favoriser un déploiement plus rapide. Microsoft affirme que ces deux objectifs relèvent d'une même stratégie.

Le code de conduite MAI de Microsoft qui l'accompagne vise à encadrer la famille de modèles développés en interne par l'entreprise. MAI désigne les modèles développés par Microsoft AI, plutôt que ceux fournis par des partenaires tels qu'OpenAI ou Anthropic.

Microsoft avait déjà placé MAI au cœur de sa feuille de route produit. Lors de Build 2026, l'entreprise a présenté une famille MAI de sept modèles menée par MAI-Thinking-1, son premier modèle de raisonnement conçu en interne. La gamme couvrait également la génération d'images, la transcription, la parole et le codage.

Microsoft a indiqué que MAI-Thinking-1 utilisait 35 milliards de paramètres actifs et prenait en charge une fenêtre de contexte de 256 000 tokens. Les paramètres actifs sont les composants du modèle utilisés lors d'une inférence donnée, tandis que la fenêtre de contexte définit la quantité d'entrées qu'il peut prendre en compte.

Ces caractéristiques montrent que l'annonce sur le code de conduite n'est pas un exercice abstrait. Microsoft intègre déjà des modèles MAI dans Foundry, GitHub Copilot, PowerPoint, OneDrive et d'autres produits très utilisés.

Toutefois, l'annonce disponible n'établit pas l'ensemble des règles nécessaires pour évaluer la conformité. Elle ne fournit pas encore de protocole public complet de tests, de processus d'application, de seuil de déploiement ou de classification des risques propre à chaque modèle.

La distinction est importante. Annoncer un code crée une attente. Publier des obligations mesurables créerait une responsabilité.

Pour l'heure, le fait vérifié est que Nadella a relié le programme de superintelligence de Microsoft à un principe explicite de contrôle humain. La question non résolue est la manière dont ce principe régira les décisions réelles de mise à disposition.

Pourquoi le code de conduite MAI de Microsoft arrive maintenant

Le code arrive parce que les propres modèles de Microsoft deviennent suffisamment importants pour créer des risques que les politiques de ses partenaires ne peuvent pas couvrir.

L'expansion initiale de Microsoft dans l'IA générative reposait largement sur OpenAI. Cette relation a permis à l'entreprise d'accéder rapidement à des modèles de pointe pour Azure, Microsoft 365, GitHub et ses produits grand public.

Sa position est désormais plus complexe. Microsoft propose toujours les modèles d'OpenAI, mais distribue également Anthropic, Mistral, Meta, DeepSeek, xAI et d'autres familles de modèles via ses plateformes. Parallèlement, l'entreprise développe MAI comme alternative propriétaire.

Cette diversité répond à des objectifs commerciaux et techniques. Un modèle spécialisé peut réduire la latence, l'utilisation de tokens ou les coûts d'exploitation lorsqu'un modèle généraliste de pointe dépasse les besoins d'une tâche. Elle donne également à Microsoft un contrôle accru sur l'entraînement, le déploiement et l'intégration aux produits.

Nadella a soutenu que les entreprises devraient éviter de dépendre d'un seul modèle pour chaque tâche. En juillet, il a déclaré que les organisations devraient séparer leurs données, leur mémoire, leurs outils et leurs infrastructures d'agents de tout modèle individuel.

Une infrastructure d'agents est le logiciel environnant qui fournit des instructions, de la mémoire, des outils et des retours. Séparer cette couche permet à une entreprise de remplacer des modèles sans reconstruire l'intégralité de son flux de travail.

Cet argument en faveur de l'indépendance vis-à-vis des modèles exerce une pression sur OpenAI et les autres laboratoires de pointe. Microsoft reste à la fois leur investisseur, partenaire cloud, distributeur, client et concurrent de plus en plus direct.

L'expansion de MAI modifie également les responsabilités de Microsoft. L'entreprise ne peut plus considérer que la sécurité au niveau des modèles relève principalement d'un fournisseur externe. Lorsque Microsoft entraîne le modèle, fixe ses conditions de mise à disposition et le déploie dans ses produits, elle assume une part plus importante du risque.

Microsoft maintient déjà un code d'IA pour les entreprises destiné aux clients utilisant ses services d'IA. Ce document impose des contrôles des entrées et des sorties, la divulgation des contenus synthétiques, des tests continus, des canaux de retour, des mesures de sécurité et une supervision humaine appropriée.

Il restreint également les usages nuisibles, la manipulation trompeuse, certaines inférences biométriques, la notation sociale et les décisions aux conséquences importantes prises sans implication humaine adéquate. Les systèmes autonomes doivent inclure une surveillance, des contrôles d'intervention, des avertissements en cas de défaillance et une documentation de leurs limites.

Ces obligations pour les clients sont pertinentes, mais elles ne sont pas identiques à un code de développement des modèles. Un contrat de service indique aux clients comment ils peuvent utiliser un système. Un code relatif aux modèles devrait aussi expliquer ce que Microsoft entraînera, testera, retiendra, modifiera ou refusera de mettre à disposition.

Cette différence explique pourquoi un code de conduite MAI de Microsoft a davantage de poids qu'une simple politique d'utilisation acceptable. Il devrait encadrer Microsoft avant qu'un modèle n'atteigne les clients, et pas seulement les clients après le déploiement.

Ce calendrier reflète également le plan quinquennal de l'entreprise pour la superintelligence. Microsoft a réorganisé sa direction de l'IA en mars 2026 afin que Mustafa Suleyman puisse se concentrer plus directement sur les modèles de pointe et les lignées de modèles adaptées aux entreprises.

Lorsqu'une entreprise engage ses talents, ses capacités de calcul et sa stratégie produit vers cet objectif, des assurances de sécurité informelles deviennent insuffisantes. Un code écrit peut établir des limites communes pour les chercheurs, les dirigeants, les équipes produit et les partenaires de déploiement.

Il peut aussi révéler si Microsoft définit le progrès uniquement par les performances aux benchmarks. Un code sérieux considérerait la contrôlabilité, la résistance aux abus, la surveillance et l'impact réel comme des critères de mise à disposition aux côtés des capacités.

Le véritable adversaire de Microsoft est la course sans limites de mise à disposition

Le conflit principal n'oppose pas Microsoft à un concurrent unique ; il oppose sa promesse de contrôle à la pression concurrentielle visant à déployer des systèmes de plus en plus autonomes.

Chaque grand laboratoire d'IA est incité à avancer rapidement. De meilleurs modèles attirent développeurs, contrats d'entreprise, talents, investissements et précieuses données d'usage. Un retard peut faire perdre du terrain à une entreprise, même lorsqu'il améliore la sécurité.

La pression s'intensifie lorsque des concurrents décrivent la superintelligence comme suffisamment proche pour influencer les décisions actuelles. Les entreprises dépensent alors davantage, accélèrent les expérimentations et annoncent des calendriers ambitieux par crainte de manquer un changement de plateforme.

Dario Amodei d'Anthropic a accentué cette tension en affirmant que les garde-fous avaient besoin de temps pour rattraper leur retard. Un avertissement sur la sécurité de l'IA, rapporté par l'Associated Press, indiquait qu'il soutenait un ralentissement du développement suffisant pour renforcer les contrôles autour de systèmes de plus en plus capables.

Selon ce rapport, Amodei a averti que l'IA avancée pourrait bientôt coordonner de grands groupes d'agents capables d'opérer sur Internet. Le calendrier exact relève d'une prévision, et non d'un fait établi de manière indépendante.

Pourtant, la préoccupation sous-jacente est concrète. Les agents d'IA peuvent exécuter des tâches en plusieurs étapes, appeler des outils, écrire et exécuter du code, communiquer avec d'autres systèmes et poursuivre leur travail avec une supervision limitée.

Un modèle qui produit une réponse nuisible crée une catégorie de risque. Un agent qui agit sur cette réponse en crée une autre. Le second système peut transformer une erreur, une tromperie ou une instruction exploitée en action externe.

Le soutien de Nadella à un rythme délibéré reconnaît que les capacités et la gouvernance ne progressent pas toujours de concert. Il évite également d'approuver un arrêt indéfini. Microsoft souhaite toujours développer et distribuer des systèmes avancés.

Meta représente une orientation différente. Son argument en faveur de la superintelligence personnelle soutient que donner largement des moyens aux individus peut empêcher qu'un contrôle excessif ne se concentre au sein des gouvernements ou d'un petit groupe d'entreprises.

Meta reconnaît également le danger de systèmes qui s'améliorent eux-mêmes ou poursuivent des objectifs au-delà d'une supervision humaine réelle. Sa réponse proposée met l'accent sur les contrôles, la confidentialité, la distribution du pouvoir et la coordination lorsque des comportements nuisibles apparaissent.

La position de Microsoft recoupe certains aspects des deux arguments. Comme Anthropic, l'entreprise considère l'alignement et le contrôle comme des raisons de rythmer le développement. Comme Meta, elle affirme que les bénéfices de l'IA avancée devraient être largement distribués.

La difficulté consiste à déterminer ce qui se produit lorsque ces principes entrent en conflit. Une large diffusion peut accroître l'accès, mais aussi augmenter le nombre de personnes susceptibles d'abuser d'un système performant. Un déploiement restrictif peut réduire les abus, mais concentrer le pouvoir chez le fournisseur.

Un code utile doit préciser qui tranche ce conflit. Il devrait expliquer si une équipe de sécurité peut bloquer une mise à disposition, si des dirigeants produit peuvent annuler cette décision, et si des évaluateurs externes reçoivent des éléments probants significatifs.

Il devrait également définir opérationnellement le contrôle humain. Un bouton d'arrêt est insuffisant si les opérateurs ne peuvent pas comprendre les actions d'un système, détecter les défaillances ou intervenir avant que des conséquences irréversibles ne surviennent.

Pour les acheteurs en entreprise, le contrôle comprend le choix des modèles, les limites relatives aux données, les journaux d'audit, les accès fondés sur les rôles, les dossiers d'évaluation, les procédures de retour en arrière et les limites imposées aux actions autonomes. Il inclut également la conservation du contexte organisationnel en dehors de tout fournisseur unique.

Cette architecture ressemble à un principe plus large de knowledge blending : les systèmes deviennent plus utiles lorsqu’ils relient des sources pertinentes sans effacer leur provenance ni le contrôle de l’utilisateur. Dans un agent d’entreprise, la provenance peut déterminer si une action est jugée fiable, examinée ou rejetée.

Le code de Microsoft sera donc jugé à l’aune des produits, non de la rhétorique. La preuve la plus convaincante serait un cas visible où l’entreprise aurait retardé, restreint ou annulé une version parce qu’un modèle n’a pas atteint le seuil annoncé.

Un code ne vaut que par ses tests et son application

La plus grande incertitude est de savoir si les principes de Microsoft produiront des décisions susceptibles d’être examinées de manière indépendante.

Microsoft développe depuis des années un programme d’IA responsable. Son programme d’IA responsable publié s’articule autour de la transparence, de la responsabilité, de l’équité, de l’inclusion, de la fiabilité, de la sûreté, de la confidentialité et de la sécurité.

L’entreprise décrit également un processus visant à cartographier, mesurer et gérer les risques. Ces pratiques constituent une base pour la gouvernance des modèles, mais un code relatif à la superintelligence exige un niveau plus élevé.

Premièrement, Microsoft doit définir les systèmes couverts par ce code. La famille MAI comprend des modèles de raisonnement, de programmation, de voix, de transcription et d’images. Ces systèmes présentent des modes de défaillance différents et nécessitent des évaluations distinctes.

Un modèle vocal soulève des questions de consentement, d’usurpation d’identité, de fraude et de divulgation. Un modèle de programmation soulève des enjeux de cybersécurité, de dépendances, d’exécution et d’intégrité logicielle. Un modèle de raisonnement connecté à des outils pose des questions plus larges de planification et d’action autonome.

Un principe universel ne peut pas remplacer ces contrôles propres à chaque modèle. Le code doit reposer sur une base commune, complétée par des exigences distinctes pour chaque capacité et chaque contexte de déploiement.

Deuxièmement, les évaluations doivent ressembler à l’usage réel des produits. Un modèle de programmation testé uniquement sur des tâches de référence isolées pourrait se comporter différemment au sein d’un agent qui modifie des dépôts, exécute des commandes et accède à des identifiants.

Microsoft a indiqué que ses modèles MAI sont entraînés et optimisés pour des tâches propres aux produits. Cela rend l’évaluation au niveau du produit particulièrement importante. L’unité pertinente est souvent le système complet, y compris le cadre d’exécution, les outils, la mémoire, les politiques et le processus d’approbation humaine.

Troisièmement, les résultats exigent des rapports clairs. Un score a une valeur limitée si les observateurs extérieurs ne peuvent pas consulter la définition du test, les conditions de comparaison, la version du modèle, l’accès aux outils ou les catégories de défaillance.

Microsoft n’a pas besoin de publier les poids sensibles des modèles ni des détails de sécurité pour fournir des éléments utiles. L’entreprise peut publier les méthodes d’évaluation, des résultats synthétisés, les limites connues, les restrictions de déploiement et la description des mesures d’atténuation importantes.

Quatrièmement, l’application doit atteindre les équipes internes. Les restrictions destinées aux clients sont plus faciles à observer, car Microsoft peut suspendre l’accès au service. L’application interne est plus difficile, car les échéances produits et les objectifs de revenus s’exercent au sein de la même entreprise.

Une structure de gouvernance crédible sépare l’examen des risques des équipes récompensées pour la rapidité des sorties. Elle crée des voies d’escalade documentées et définit qui détient l’autorité lorsque les objectifs de sécurité et les objectifs commerciaux entrent en conflit.

Cinquièmement, le code devrait traiter les changements effectués après le lancement. Les modèles peuvent recevoir de nouveaux outils, un contexte plus long, des instructions système mises à jour ou des autorisations plus étendues sans obtenir un nouveau nom public.

Ces changements peuvent modifier le risque davantage qu’une mise à jour conventionnelle du modèle. La gouvernance doit donc couvrir la configuration complète du déploiement, et pas seulement le checkpoint produit à la fin de l’entraînement.

Des chercheurs indépendants ont également souligné que le risque de perte de contrôle reste difficile à mesurer. Les priorités mondiales de recherche publiées dans le cadre du Consensus de Singapour de 2026 décrivent le domaine comme de plus en plus testable, tout en reconnaissant une incertitude prédictive majeure.

Cette incertitude joue dans les deux sens. Elle ne prouve pas que des conséquences catastrophiques sont imminentes. Elle ne justifie pas non plus de considérer l’absence de défaillances observées comme une preuve qu’un système est sûr.

Microsoft devrait éviter de laisser entendre qu’un code écrit résout le problème de l’alignement. L’alignement demeure un problème technique, organisationnel et politique, qui implique des valeurs contestées et des mesures incomplètes.

Les critiques devraient éviter l’exagération inverse. Un code volontaire n’est pas automatiquement dénué de sens. Il peut influencer les décisions d’ingénierie lorsqu’il comprend des tests concrets, des décideurs nommés, des jalons de mise en production et des conséquences documentées.

La norme appropriée est la preuve. Le code modifie-t-il ce qui est entraîné, la façon dont cela est testé, les capacités qui restent restreintes et le moment où le déploiement s’arrête ?

Ce que les développeurs et les acheteurs d’entreprise devraient demander

Les clients devraient traduire l’engagement de Microsoft en faveur du contrôle humain en questions d’approvisionnement avant de confier aux modèles MAI un travail aux conséquences importantes.

La première question concerne le périmètre. Les acheteurs doivent savoir si le Microsoft MAI Code of Conduct s’applique uniquement aux modèles accessibles au public ou également aux versions internes utilisées dans les produits Microsoft.

Un modèle intégré à Copilot peut affecter des utilisateurs qui ne le sélectionnent jamais directement. Microsoft devrait indiquer quel modèle exécute une tâche, quand le routage intervient et si les administrateurs peuvent restreindre certaines familles de modèles.

La deuxième question concerne l’évaluation. Les organisations devraient demander quels tests de sécurité et de qualité s’appliquent à leur cas d’usage, plutôt que de se demander si un modèle a obtenu un score élevé sur une évaluation générale.

Un assistant de service client doit être testé sur les affirmations non étayées, l’escalade, la confidentialité et le traitement des dossiers. Un agent de programmation doit être testé sur les commandes dangereuses, le code vulnérable, l’exposition de secrets, l’intégrité des paquets et les modifications non autorisées.

Un flux de travail de santé ou de finance exige un examen humain plus strict, car les erreurs peuvent affecter les droits, les opportunités ou le bien-être physique. Le code d’entreprise existant de Microsoft considère déjà que les décisions ayant des conséquences importantes nécessitent une supervision appropriée.

La troisième question concerne l’autonomie. Les acheteurs devraient documenter les actions qu’un agent peut entreprendre, celles qui exigent une approbation et celles qui restent interdites en toutes circonstances.

Le contrôle humain doit exister avant une action aux conséquences importantes, et pas seulement après une défaillance. Les écrans de révision, les limites d’autorisation, les plafonds de transaction et les environnements de mise en scène réversibles offrent davantage de protection qu’une instruction générale de se comporter de manière sûre.

La quatrième question concerne la surveillance. Les équipes ont besoin de journaux montrant les entrées, le contexte récupéré, les appels d’outils, les sorties du modèle, les interventions de politique, les approbations et les actions finales.

Ces enregistrements doivent rester compréhensibles lorsqu’un flux de travail utilise plusieurs modèles. Une entreprise ne peut pas enquêter sur un incident si sa plateforme achemine silencieusement chaque étape sans conserver de piste de décision exploitable.

La cinquième question concerne les modifications de modèles. Les déploiements d’entreprise devraient définir des délais de préavis, des tests de régression, des options de retour en arrière et des contrôles de version lorsque Microsoft met à jour un modèle MAI ou modifie la couche de routage.

L’amélioration automatique est attrayante, mais un modèle mis à jour peut modifier le comportement d’un flux de travail validé. Les équipes soumises à une réglementation peuvent devoir répéter leurs tests avant d’adopter la nouvelle version.

La sixième question concerne les données. Nadella a soutenu que les entreprises doivent préserver le contrôle de leurs propres boucles d’apprentissage, c’est-à-dire des informations générées lorsque les employés et les systèmes effectuent leur travail.

Les acheteurs devraient clarifier si les prompts, les sorties, les retours et les traces d’outils servent à entraîner les modèles Microsoft. Ils devraient également déterminer où ces enregistrements résident et comment ils peuvent les exporter ou les supprimer.

La septième question concerne la réponse aux incidents. Un code a besoin de canaux de signalement, mais les entreprises ont également besoin de délais de réponse, de contacts d’escalade, de procédures de confinement et d’explications après incident.

Les développeurs ont leur propre responsabilité pratique. Ils devraient considérer les sorties des modèles comme non fiables jusqu’à ce que le système environnant les valide. Ce principe est particulièrement important lorsqu’un agent écrit du code, modifie des données ou communique à l’extérieur.

Aucune de ces questions ne nécessite d’attendre la superintelligence. Elles s’appliquent aux systèmes actuels qui combinent déjà des modèles de langage avec des outils et des données organisationnelles.

L’annonce de Nadella est importante, car elle donne aux clients une norme qu’ils peuvent invoquer. Si Microsoft affirme que l’IA doit rester sous contrôle humain, les acheteurs peuvent demander à l’entreprise de montrer où ce contrôle existe.

Trois signaux montreront si Microsoft est sérieux

Le prochain test est la mise en œuvre, et trois signaux observables révéleront si le code modifie le comportement de Microsoft.

Le premier signal sera la publication d’exigences propres aux modèles et de résultats d’évaluation. Microsoft devrait relier le code à des modèles MAI individuels au lieu de le laisser au stade d’une déclaration générale.

Pour MAI-Thinking-1, cela pourrait inclure la fiabilité du raisonnement, des tests de tromperie, les limites d’utilisation des outils, des évaluations de cybersécurité et les résultats relatifs au contrôle des agents. Pour les modèles vocaux et d’images, cela devrait couvrir l’usurpation d’identité, la provenance, le consentement et les protections contre les contenus nuisibles.

Le détail décisif n’est pas de savoir si chaque score paraît favorable. Des limites transparentes rendraient le cadre plus crédible, car aucun modèle avancé ne fonctionne de manière fiable dans tous les environnements.

Si Microsoft publie des méthodes reproductibles, des résultats versionnés et des restrictions de déploiement claires, la promesse de Nadella gagnera en force. S’il ne publie que des principes, l’annonce restera difficile à auditer.

Le deuxième signal sera la preuve que les jalons de mise en production ont des conséquences. Surveillez une capacité MAI que Microsoft retarde, limite ou conserve en préversion après que les tests ont révélé des risques non résolus.

Une telle décision montrerait qu’un rythme délibéré peut l’emporter sur la pression commerciale. Elle établirait également un précédent pour les employés et les partenaires qui évalueront les versions ultérieures.

Un retard à lui seul ne prouve pas une bonne gouvernance. Les entreprises retardent des produits pour des raisons techniques, financières ou stratégiques. Microsoft devrait expliquer à quel moment son code a influencé la décision et identifier le seuil pertinent sans révéler de détails sensibles de sécurité.

Si aucune version ne change jamais en raison du code, les observateurs devraient se demander si le cadre régit le développement ou s’il se contente de documenter des intentions existantes.

Le troisième signal concerne la manière dont Microsoft gère les agents autonomes dans Foundry, Copilot et Microsoft 365. La sécurité des modèles et celle des agents ne peuvent pas rester séparées une fois que les modèles reçoivent des outils et l’autorisation d’agir.

Recherchez des contrôles administrateur plus robustes, des autorisations granulaires, des exigences d’approbation, de la surveillance, des mécanismes de retour en arrière et une identification cohérente des modèles. Ces fonctionnalités feraient du contrôle humain une propriété du produit.

Observez également si Microsoft applique des normes équivalentes aux modèles partenaires distribués par ses plateformes. Les clients font l’expérience du service Microsoft dans son ensemble, même lorsqu’un modèle sous-jacent provient d’un autre laboratoire.

Un code limité à MAI pourrait améliorer les pratiques internes de Microsoft tout en laissant subsister des protections incohérentes dans son catalogue plus large. Une couche de contrôle à l’échelle de la plateforme pourrait réduire cet écart.

Le Microsoft MAI Code of Conduct constitue donc un test utile pour la stratégie de superintelligence de l’entreprise. Microsoft veut simultanément faire progresser la frontière technologique, proposer des modèles spécialisés moins coûteux, assurer une large distribution et maintenir un contrôle humain significatif.

Ces objectifs ne sont pas automatiquement compatibles. Leurs conflits apparaîtront lors des réunions de mise en production, dans les autorisations des produits, les rapports d’évaluation et les réponses aux incidents.

Les développeurs et les dirigeants d’entreprise devraient conserver le principe de Nadella et le comparer à ces décisions. Demandez quels tests peuvent arrêter un déploiement, qui a l’autorité de les appliquer et quelles preuves les clients reçoivent.

Si Microsoft répond publiquement à ces questions, le rythme délibéré deviendra une discipline opérationnelle. Dans le cas contraire, le code restera une déclaration de valeurs attachée à un programme de modèles en accélération.