Résumé

  • Le Cyber Safety Review Board a demandé au PDG et au conseil d'administration de Microsoft de publier un plan assorti d'échéances précises. Microsoft a publié des rapports datés, des objectifs par bandes, des dirigeants nommés et un lien avec la rémunération ; aucun de ces documents ne permet à un tiers de recalculer les pourcentages annoncés.
  • La couverture des pipelines de publication est passée de 94 % en novembre 2025 à 90 % en juillet 2026, variation que Microsoft explique par un élargissement du périmètre de mesure. Un chiffre qui se déplace avec son propre dénominateur n'est pas une assurance — et c'est pourtant sous cette forme qu'il circule dans les dossiers d'achat.

Le rapport du Cyber Safety Review Board sur l'intrusion de l'été 2023 dans Exchange Online — la copie consultée porte une date de couverture au 20 mars 2024 — ramène l'essentiel à une seule phrase, sa première recommandation : « The CEO and Board should develop, and share publicly, a plan with specific timelines to make fundamental, security-focused reforms » (rapport du CSRB, page 19 imprimée).

L'instrument demandé a trois propriétés, et il faut les tenir ensemble. Il s'adresse au sommet de l'entreprise, pas à une équipe d'ingénierie. Il exige des échéances précises, pas un programme en cours. Et il exige la publicité, donc un lecteur capable d'en juger. Deux propriétés sur trois ne font pas trois sur trois.

Le 3 mai 2024, Microsoft a répondu par des cibles d'ingénierie à 100 %, dont celle-ci : « 100% of access to source code and engineering systems infrastructure is secured through Zero Trust and least-privilege access policies. » (annonce du 3 mai 2024). L'adherence devait se mesurer par des objectifs et des résultats clés. Dans la page telle que publiée, aucune de ces cibles ne porte de date butoir individuelle, et aucune ne nomme de responsable unique.

La méthode, elle, est écrite noir sur blanc dans le rapport d'avril 2025 : « We calculated progress by recording the completed percentage of standards and key results, those defined initially and any additions. » (rapport d'avril 2025, page 4 imprimée). Traduction opérationnelle : le dénominateur grossit quand l'entreprise ajoute du travail. Ce n'est pas une tricherie, c'est une définition — et c'est précisément ce qui rend le chiffre inutilisable comme preuve de progrès par un lecteur extérieur.

Les résultats sont ensuite publiés par bandes plutôt que par points. En avril 2025, les objectifs 1 à 3 se situaient dans la bande 95–99 % et les objectifs 4 et 5 dans la bande 66–94 %. En novembre 2025, les objectifs 2 et 3 restaient à 95–99 %, tandis que les objectifs 1, 4 et 5 tombaient à 66–94 %, l'entreprise invoquant un inventaire élargi (rapport de novembre 2025). En juillet 2026, l'objectif 1 est déclaré « closed », les objectifs 2 et 3 restent à 95–99 % et les objectifs 4 et 5 à 66–94 % (rapport de juillet 2026). Une bande n'est pas un compte, et une clôture n'est pas un ratio d'actifs : ni l'une ni l'autre ne se recalcule.

Les chiffres de couverture, eux, sont datés et comparables — à condition de respecter ce que chaque rapport mesure. Septembre 2024 : 85 % des pipelines de production du cloud commercial utilisent des modèles de pipeline gouvernés centralement (rapport de septembre 2024). Avril 2025 : 92 % des pipelines de build, 54 % des pipelines de publication, et 56 % des accès de signature de code limités aux identités de production. Novembre 2025 : 94 % des pipelines de publication sous modèles gouvernés et 89 % d'isolation réseau. Juillet 2026 : 93 % des pipelines de build critiques et à forte valeur, et 90 % des pipelines de publication (synthèse Trust Center de juillet 2026).

La série des pipelines de publication mérite d'être lue lentement : 54 %, puis 94 %, puis 90 %. Microsoft commente le dernier mouvement ainsi : « Recent metric variation reflects expanded measurement scope, with final attribution under review. » (PDF de juillet 2026). Le lecteur qui cherche à savoir si les contrôles se sont dégradés, améliorés ou simplement redéfinis ne trouvera pas de réponse dans le document. L'entreprise elle-même écrit que l'attribution est encore à l'étude.

Le chiffre le plus repris est d'une autre nature : « achieving 99.5% detection and remediation of live secrets in code. » (annonce du 10 novembre 2025). Le document ne donne ni numérateur, ni dénominateur, ni méthode d'échantillonnage, et ne précise pas si la mesure décrit la couverture, la performance de détection ou l'achèvement de la remédiation. C'est une déclaration de l'entreprise sur elle-même, pas un taux de précision validé.

Les volumes publiés en juillet 2026 appellent la même prudence : plus de 550 000 occurrences de vulnérabilités open source critiques ou à haut risque corrigées, et un correctif automatisé de conteneurs traitant environ trois millions d'occurrences de vulnérabilités par mois (synthèse de juillet 2026). Une occurrence n'est pas une vulnérabilité unique ni un CVE ; le chiffre de 550 000 n'indique pas de fenêtre de mesure ; et un débit mensuel n'est pas l'élimination d'un arriéré. Deux autres données cadrent la lecture : environ 80 000 pipelines sont surveillés, et cinq des sept grandes catégories de journaux de sécurité atteignaient le niveau de conservation requis en avril 2025 (rapport d'avril 2025). Par ailleurs, les périodes de référence diffèrent d'une publication à l'autre : novembre 2025 compte des CVE depuis janvier 2025 alors que les primes de bug bounty couvrent juillet 2024 à juin 2025. Une date de publication n'est pas une date d'arrêté des comptes.

L'entreprise reconnaît d'ailleurs elle-même la limite : « We do not disclose the full body of work we are undertaking to advance an objective (such as standards and key results) » (rapport de novembre 2025). C'est de la franchise. C'est aussi la raison technique pour laquelle aucun audit externe ne pourrait, à partir de ces documents seuls, refaire le calcul.

Reste l'élément qui ressemble le plus à une conséquence. Satya Nadella a annoncé en mai 2024 que Microsoft basait « part of the compensation of the senior leadership team on our progress towards meeting our security plans and milestones » (blog officiel du 3 mai 2024), formulation reprise en septembre 2024 : « Microsoft’s senior leadership team now has security performance directly linked to compensation. » (point d'étape de septembre 2024). Aucun document consulté ne publie de pondération, de seuil de déclenchement ni de réduction automatique liée à un jalon précis. Un lien avec la rémunération sans barème reste un signal de priorité, pas une clause exécutable.

La gouvernance est nommée, elle aussi. Le CISO Igor Tsyganskiy pilote le Cybersecurity Governance Council des Deputy CISOs ; les Deputy CISOs et les équipes d'ingénierie sont collectivement responsables de la supervision, de la gestion des risques et du reporting ; les revues de direction sont hebdomadaires, les mises à jour du conseil trimestrielles, et la performance de sécurité entre dans les évaluations des salariés. Joy Chik est identifiée comme executive sponsor du programme (annonce de septembre 2024). Une supervision nommée n'est pas un registre nommant un propriétaire et une date par indicateur.

Il faut aussi créditer ce qui existe vraiment. Le programme comporte au moins une échéance calendaire : l'objectif de transition vers la cryptographie post-quantique dans les produits et services critiques d'ici 2029 (annonce du 10 juillet 2026). Dire que tout est sans date serait faux. Et l'annexe du rapport d'avril 2025 classe les recommandations 1 à 4 du CSRB comme « complete » — c'est l'appréciation de Microsoft sur sa propre conformité, pas une validation indépendante.

Le dernier rapport figure sur le hub SFI au titre de juillet 2026, avec une annonce datée du 10 juillet 2026 (hub Trust Center). La cadence est une promesse, pas un calendrier : « We plan to keep ourselves accountable and provide the latest SFI news to customers, partners, and the security community through regular updates. » Aucune échéance de publication fixe n'apparaît sur cette page, qui est par nature modifiable.

Sur la question qui décide de tout — qui, en dehors de Microsoft, atteste ces pourcentages — la réponse honnête est étroite : aucune attestation indépendante des pourcentages publiés n'apparaît dans les onze documents que j'ai lus à leurs dates de consultation indiquées, soit le rapport du CSRB, quatre rapports d'étape détaillés, quatre annonces datées de Microsoft, la synthèse du Trust Center de juillet 2026 et le hub SFI. Les tests internes, les correspondances de référentiels et l'analyse d'incident du conseil ne constituent pas une assurance indépendante sur les chiffres de progrès ultérieurs.

L'absence dans cet ensemble n'est pas une preuve d'absence ailleurs.

Ce que cela ajoute à ce que nous avions publié sur cette entreprise mérite d'être dit sans détour. Nos sept articles antérieurs la traitaient comme un acteur de produit et de marché : la consolidation de Copilot (19 mars 2026), les manoeuvres rapportées entre Microsoft, Amazon et OpenAI (19 mars 2026), l'avis de la CISA après l'intrusion chez Stryker touchant les contrôles administrateur d'Intune (19 mars 2026), la panne de Microsoft 365 (23 janvier 2026), l'extension de 200 MW aux Émirats avec G42 (7 novembre 2025) et les recommandations de l'autorité britannique de la concurrence sur le marché du cloud (1er août 2025). Aucun ne testait ce qui remplace un recours contraignant après une revue externe. Notre propre briefing sur le caractère non contraignant du conseil s'arrêtait là où celui-ci commence : à l'instrument que l'entreprise a construit à la place. La fiche de Microsoft Corporation dans le répertoire BTW est ici un point de repère d'identité, pas une source de faits opérationnels.

La question utile n'est donc pas de savoir si Microsoft travaille sérieusement — les documents montrent du travail, des effectifs nommés et des dizaines de milliers de pipelines instrumentés. La question est de savoir ce qu'un pourcentage auto-publié oblige. Appliqué à un contrat, un pourcentage de complétion ressemble à une garantie ; appliqué à un rapport annuel, il ressemble à un contrôle ; appliqué à une police d'assurance, il ressemble à un risque mesuré. Dans les trois cas, le lecteur achète une conclusion que seul le vendeur peut produire. Une mesure que le mesuré définit, calcule et commente n'est pas une vérification.

C'est une auto-évaluation avec des chiffres après la virgule.