# La faille SharePoint que Microsoft a patchée puis oubliée d'annoncer

> L'agence américaine de cybersécuritéCISA a ajouté, le 1er juillet 2026, une nouvelle vulnérabilité critique affectant MicrosoftSharePoint Server à son catalogue des failles

- Auteur: Maxime Marquette
- Publication: MadMax (https://mad-max.co)
- Rubrique: Analyse
- Publié: 2026-07-05
- Adresse à citer: https://mad-max.co/fr/article/la-faille-sharepoint-que-microsoft-a-patchee-puis-oubliee-d-annoncer

## Introduction : une urgence fédérale née d'un oubli administratif

### Une échéance de 72 heures pour tout le gouvernement américain

L'agence américaine de **cybersécurité** **CISA** a ajouté, le **1er juillet 2026**, une nouvelle **vulnérabilité** critique affectant **Microsoft** **SharePoint** Server à son catalogue des **faille**s activement exploitées, avec une échéance de correction fixée au **4 juillet 2026** pour les **agences fédérales** civiles américaines, selon **The Hacker News**. Trois jours seulement pour corriger une **faille** qui, ironiquement, était déjà patchée depuis des semaines sans que personne n'en soit vraiment informé.

Cette **vulnérabilité**, identifiée sous le code **CVE-2026-45659** avec un score de gravité **CVSS** de 8,8 sur 10, permet l'exécution de code à distance via une **faille** de **désérialisation** de données non fiables, un type de **vulnérabilité** technique qui reste l'une des plus dangereuses en matière de sécurité applicative.

### Le détail qui change tout: un patch publié sans tambour ni trompette

Ce qui rend cette histoire particulièrement révélatrice, c'est que **Microsoft** avait déjà corrigé cette **faille** lors du cycle de mises à jour de **mai 2026**, mais n'a publié le bulletin de sécurité correspondant que le **21 mai**, plusieurs semaines après la sortie du **correctif**, selon **Threat-Modeling.com**. **Microsoft** aurait lui-même reconnu avoir «oublié de signaler l'existence de la **vulnérabilité**».

Ce genre de délai de divulgation, aussi involontaire soit-il, laisse les **équipes de sécurité** dans le noir pendant des semaines critiques, une réalité qui devrait alarmer quiconque s'occupe de **cybersécurité** en entreprise ou au gouvernement.

*Je trouve stupéfiant qu'une entreprise de la taille de **Microsoft**, dont les logiciels équipent des centaines de milliers d'organisations à travers le monde, puisse simplement «oublier» de publier un bulletin de sécurité pendant près d'un mois. Ce genre d'erreur administrative a un prix, et ce prix se mesure en serveurs compromis.*

## Anatomie technique d'une **faille** redoutable

### Comment fonctionne l'exploitation de **CVE-2026-45659**

La **vulnérabilité** repose sur une **désérialisation** de données non fiables (référencée **CWE-502**), un mécanisme qui permet à un **attaquant** authentifié de faire exécuter du code arbitraire sur le serveur **SharePoint** simplement en lui transmettant des données spécialement conçues à cet effet, selon le **Centre canadien pour la cybersécurité**. La complexité de l'attaque est jugée faible, ce qui signifie qu'aucune connaissance préalable approfondie de l'environnement ciblé n'est nécessaire.

Le seuil d'accès requis reste relativement bas: un **attaquant** n'a besoin que des **permissions** minimales de **Membre du site**, un niveau d'accès couramment accordé à des employés, des sous-traitants et des partenaires externes dans la plupart des déploiements **SharePoint** d'entreprise, selon **CybelAngel**.

### Aucune interaction humaine nécessaire pour l'attaque

L'aspect le plus préoccupant de cette **faille** est peut-être qu'elle ne nécessite **aucune interaction de l'utilisateur** ni aucun privilège administratif pour être exploitée avec succès. Un **attaquant** disposant du niveau d'accès minimal peut agir de façon autonome, sans avoir à convaincre qui que ce soit de cliquer sur un lien ou d'ouvrir un document piégé.

Cette caractéristique technique transforme une **vulnérabilité** déjà sérieuse en menace quasi automatisée, capable d'être exploitée à grande échelle par des outils scannant systématiquement internet à la recherche de serveurs **SharePoint** vulnérables.

*Chaque fois qu'une **faille** ne nécessite ni interaction humaine ni privilège élevé, je considère qu'elle mérite d'être traitée comme une urgence absolue, peu importe l'évaluation initiale du fournisseur. L'histoire de la **cybersécurité** regorge d'exemples où «l'exploitation improbable» s'est révélée être exactement le contraire.*

## L'ironie de l'évaluation initiale de **Microsoft**

### «Exploitation peu probable» dément par les faits

**Microsoft** avait initialement classé cette vulnérabilité comme présentant une **«exploitation moins probable»**, selon son propre avis de sécurité cité par **The Hacker News**. Cette évaluation, qui a probablement influencé la priorité accordée au **correctif** par de nombreuses équipes informatiques débordées, s'est révélée totalement erronée une fois les preuves d'**exploitation active** confirmées par **CISA**.

Ce décalage entre l'évaluation initiale du fournisseur et la réalité du terrain illustre un problème structurel récurrent: les entreprises technologiques ont souvent intérêt, consciemment ou non, à minimiser la gravité perçue de leurs propres failles.

### Un historique de sous-estimations chez Microsoft

Ce n'est pas la première fois qu'une évaluation initiale de Microsoft sur une faille **SharePoint** se révèle trop optimiste. La vulnérabilité **CVE-2026-20963**, ajoutée au catalogue KEV en **mars 2026**, avait vu son score CVSS relevé et sa description modifiée après que Microsoft eut réalisé qu'elle pouvait être exploitée par un attaquant non authentifié, selon **CERT-EU**.

Cette faille de mars, comme celle de juillet, ciblait le même type de mécanisme de désérialisation, un schéma qui devrait inciter Microsoft à revoir plus fondamentalement l'architecture de sécurité de **SharePoint** plutôt que de corriger faille après faille de façon réactive.

*Je remarque un motif troublant: ce n'est pas la première ni probablement la dernière faille de désérialisation critique dans **SharePoint** cette année. À un moment donné, corriger des symptômes individuels ne suffit plus; il faut s'attaquer à la cause architecturale profonde.*

## La course contre la montre du calendrier de **fin de vie**

### Une échéance qui s'ajoute à une autre échéance

Le timing de cette alerte est particulièrement délicat: **SharePoint Enterprise Server 2016** et **SharePoint Server 2019**, deux des versions affectées par cette faille, atteignent officiellement leur **fin de vie** le 14 juillet 2026, soit dix jours seulement après l'échéance de correction imposée par **CISA**, selon le **Centre canadien pour la cybersécurité**. Après cette date, Microsoft cessera de publier des **correctif**s de sécurité pour ces versions.

Les organisations qui utilisent encore ces versions vieillissantes se retrouvent donc face à un choix impossible en quelques jours: appliquer le **correctif** immédiatement, migrer vers une version supportée dans un délai extrêmement court, ou accepter un risque de sécurité permanent après la date de fin de vie.

### Des **migrations** d'entreprise qui prennent des mois, pas des jours

Quiconque a déjà participé à une migration de plateforme d'entreprise sait que ce type de projet prend généralement des mois de planification, de tests et de déploiement progressif, pas dix jours. Cette réalité opérationnelle crée une tension impossible à résoudre pour de nombreuses organisations prises entre l'urgence sécuritaire et la lenteur inévitable des processus de transformation numérique.

Je crois que cette situation devrait servir de leçon aux directions informatiques qui reportent année après année leurs **migrations** vers des versions supportées, pariant sur le fait que «ça tiendra encore un peu».

*Je comprends parfaitement les contraintes budgétaires qui poussent les organisations à retarder leurs migrations de systèmes critiques. Mais ce genre de calendrier resserré, où sécurité urgente et fin de vie du produit tombent à dix jours d'intervalle, illustre le prix concret de cette procrastination technologique.*

## Ce que révèle l'ampleur de la surface d'attaque

### SharePoint, colonne vertébrale de la collaboration d'entreprise

Microsoft SharePoint Server demeure l'une des plateformes de gestion documentaire et de collaboration les plus déployées au monde, utilisée par des centaines de milliers d'organisations, des petites entreprises aux plus grandes agences **gouvernementales**. Cette omniprésence transforme chaque faille critique de SharePoint en un événement de **cybersécurité** à l'échelle mondiale, bien au-delà du cercle restreint des experts en sécurité informatique.

Les versions affectées par cette faille précise, à savoir **SharePoint Server Subscription Edition**, **SharePoint Server 2019** et **SharePoint Enterprise Server 2016**, couvrent une portion substantielle du parc SharePoint mondial encore déployé sur des serveurs internes plutôt que dans le nuage.

### Le facteur aggravant des accès tiers

Le niveau de permission requis pour exploiter cette faille, celui de simple **Membre du site**, est couramment accordé à des sous-traitants, des partenaires commerciaux et des employés temporaires dans la plupart des environnements d'entreprise, selon **Daily Security Review**. Cette réalité élargit considérablement le bassin d'attaquants potentiels capables d'exploiter la faille, bien au-delà des seuls administrateurs système.

Cette caractéristique rend la faille particulièrement dangereuse dans les grandes organisations où la gestion rigoureuse des accès tiers reste, en pratique, un défi permanent pour les **équipes de sécurité** informatique.

*Je pense que cette faille illustre parfaitement pourquoi le principe du moindre privilège devrait être appliqué de façon beaucoup plus stricte dans les environnements de collaboration d'entreprise. Accorder un accès «Membre du site» ne devrait jamais équivaloir, dans les faits, à donner les clés du serveur.*

## La réponse coordonnée des agences **occidentale**s

### Une collaboration transatlantique bienvenue

L'alerte de **CISA** a été rapidement relayée par le **Centre canadien pour la cybersécurité**, qui a publié sa propre alerte détaillée incluant les numéros de version exacts pour identifier les systèmes vulnérables et les versions corrigées disponibles. Cette coordination entre agences **occidentale**s illustre un aspect positif de la réponse collective face aux menaces cybernétiques transfrontalières.

Je considère cette rapidité de coordination entre agences américaines et canadiennes comme un exemple encourageant de ce que devrait être la norme dans un monde où les cybermenaces ignorent complètement les frontières nationales.

### Les limites persistantes de la directive fédérale américaine

La directive opérationnelle contraignante **BOD 26-04**, qui impose ce délai de correction de trois jours aux **agences fédérales** civiles américaines, ne s'applique cependant qu'au **secteur public** fédéral, laissant les entreprises privées, les gouvernements locaux et les organisations non **gouvernementales** sans obligation légale équivalente de corriger rapidement.

Cette asymétrie réglementaire signifie que, même après l'échéance du **4 juillet**, un nombre potentiellement important de serveurs SharePoint vulnérables continueront d'exister dans le **secteur privé**, exposés aux mêmes risques d'**exploitation active**.

*Je crois que l'écart entre les obligations du **secteur public** fédéral et l'absence de contrainte équivalente pour le **secteur privé** représente une faille systémique presque aussi importante que la vulnérabilité technique elle-même. La cyber**sécurité nationale** ne s'arrête pas aux portes des agences gouvernementales.*

## Le précédent de l'été 2025, une histoire qui se répète

### Un motif saisonnier préoccupant

Cette crise SharePoint de juillet 2026 rappelle étrangement celle de l'été précédent: en **juillet 2025**, **CISA** avait déjà donné aux agences fédérales un délai extrêmement court, jusqu'à la fin de journée d'un lundi, pour corriger une vulnérabilité critique de type zero-day dans SharePoint, une crise qui avait vu plus de **9 000 systèmes vulnérables** compromis à l'échelle mondiale selon les chiffres compilés à l'époque.

Cette récurrence saisonnière de crises SharePoint majeures, à un an d'intervalle presque jour pour jour, mérite d'être documentée comme un motif plutôt que comme une simple coïncidence.

### Les leçons non retenues d'une année à l'autre

Si les mêmes types de vulnérabilités de désérialisation continuent d'apparaître année après année dans la même plateforme, cela soulève une question légitime sur la profondeur des audits de sécurité internes que Microsoft mène sur son propre code base SharePoint, un produit vieux de plusieurs décennies dont l'architecture historique complique probablement la modernisation complète de la sécurité.

Je pense que les organisations qui dépendent de SharePoint devraient désormais intégrer ce motif récurrent dans leur planification de sécurité annuelle, en prévoyant systématiquement une vigilance accrue durant les mois d'été.

*Voir le même scénario se répéter d'une année à l'autre, avec les mêmes types de failles et les mêmes délais de correction dans l'urgence, me pousse à me demander si l'industrie technologique tire réellement les leçons de ses propres crises passées, ou si elle se contente de gérer chaque incident isolément.*

## Ce que cela signifie pour la souveraineté numérique **occidentale**

### Une dépendance structurelle à quelques fournisseurs

Cette crise illustre, une fois de plus, la dépendance structurelle des gouvernements et entreprises occidentaux envers un nombre restreint de fournisseurs technologiques dominants, dont Microsoft demeure l'exemple le plus emblématique. Quand une faille critique touche une plateforme aussi répandue que SharePoint, c'est une part significative de l'**infrastructure** numérique occidentale qui se retrouve simultanément exposée.

Cette concentration du risque technologique mérite une réflexion stratégique plus large sur la diversification des **infrastructure**s critiques, particulièrement pour les agences gouvernementales qui gèrent des données sensibles pour la **sécurité nationale**.

### La cybersécurité comme enjeu géopolitique direct

Je considère la cybersécurité des **infrastructure**s **occidentales** comme un front à part entière dans la compétition stratégique plus large face à la **Chine**, la **Russie** et d'autres acteurs étatiques hostiles qui exploitent activement ce type de vulnérabilité pour l'espionnage industriel ou étatique. Chaque faille non corrigée dans une infrastructure occidentale critique représente une porte d'entrée potentielle pour des acteurs malveillants soutenus par des États rivaux.

L'origine exacte de l'exploitation actuelle de **CVE-2026-45659** demeure inconnue à ce stade, CISA n'ayant pas publiquement attribué cette campagne à un acteur spécifique, mais l'histoire récente des failles SharePoint a régulièrement impliqué des groupes soutenus par des États étrangers.

*Je reste convaincu que l'**Occident** sous-investit chroniquement dans la résilience de ses **infrastructures** numériques critiques, alors même que nos rivaux stratégiques, Chine en tête, consacrent des ressources considérables à l'exploitation systématique de nos vulnérabilités technologiques.*

## Le rôle des chercheurs et de la communauté de sécurité

### Un écosystème de veille qui fonctionne, malgré tout

Il faut reconnaître que l'écosystème de recherche en cybersécurité, incluant des organisations comme **CybelAngel**, **Aviatrix** et **Threat-Modeling.com**, a réagi rapidement pour documenter, analyser et diffuser des informations détaillées sur cette faille dès son ajout au catalogue KEV de CISA. Cette réactivité collective permet aux **équipes de sécurité** d'entreprise d'accéder rapidement à des informations techniques précises pour prioriser leurs actions correctives.

Cette rapidité de diffusion contraste d'ailleurs avec la lenteur de Microsoft à publier son propre bulletin de sécurité initial, un paradoxe qui illustre l'importance cruciale d'un écosystème de recherche indépendant en cybersécurité.

### Le rôle indispensable des bases de données publiques

Des ressources comme la base de données nationale des vulnérabilités américaine (**NVD**) et le catalogue **KEV** de CISA jouent un rôle indispensable de **transparence** publique, permettant à toute organisation, quelle que soit sa taille ou ses ressources, d'accéder gratuitement à des informations vérifiées sur les menaces actives.

Cette infrastructure d'information publique, financée par les contribuables américains, mérite d'être reconnue comme un bien public essentiel à la sécurité collective de l'écosystème numérique occidental tout entier.

*Je pense que ces bases de données publiques de vulnérabilités représentent l'un des meilleurs investissements gouvernementaux en matière de cybersécurité collective, un contre-exemple rassurant à la bureaucratie parfois trop lente dont on accuse souvent les agences fédérales.*

## Les recommandations pratiques pour les organisations exposées

### Vérifier, patcher, migrer: la séquence obligatoire

Pour toute organisation utilisant SharePoint Server dans une version affectée, la première étape consiste à vérifier immédiatement le numéro de version exact déployé via la commande **Get-SPProduct -Local**, puis à appliquer sans délai les mises à jour correctives disponibles, référencées sous les identifiants **KB5002863**, **KB5002868** et **KB5002870** selon les versions concernées.

Les organisations qui ne peuvent pas appliquer le correctif immédiatement devraient, à minima, limiter drastiquement l'exposition de leurs serveurs SharePoint à internet, en privilégiant un accès exclusivement interne ou via un réseau privé virtuel sécurisé le temps de compléter la mise à jour.

### Au-delà du correctif technique, une révision des accès

Je recommande fortement, au-delà du simple correctif technique, une révision complète des **permissions** accordées aux comptes utilisateurs de niveau **Membre du site**, en particulier pour les comptes appartenant à des sous-traitants ou partenaires externes qui n'ont pas nécessairement besoin d'un accès aussi large en temps normal.

Cette révision des accès, bien que fastidieuse, réduit structurellement la surface d'attaque disponible pour ce type de vulnérabilité, indépendamment des **correctifs** ponctuels appliqués par Microsoft au fil du temps.

*Je considère que la gestion rigoureuse des permissions utilisateur devrait être traitée avec autant de sérieux que l'application des **correctifs** eux-mêmes. Trop d'organisations traitent la gestion des accès comme une formalité administrative plutôt que comme un pilier fondamental de leur posture de sécurité.*

## Une industrie technologique sous pression de **transparence**

### Le prix réputationnel d'un oubli de divulgation

L'épisode du bulletin de sécurité «oublié» pendant près d'un mois représente un coût réputationnel significatif pour Microsoft, dans un contexte où la confiance dans la **transparence** des grands fournisseurs technologiques reste déjà fragilisée par des années d'incidents similaires à travers l'industrie entière.

Les clients d'entreprise et les agences gouvernementales sont en droit d'exiger des standards de divulgation plus stricts et plus rapides, particulièrement pour des vulnérabilités critiques touchant des **infrastructures** aussi sensibles que les plateformes de gestion documentaire d'entreprise.

### Vers une **réglementation** plus stricte de la divulgation

Cet incident pourrait alimenter les arguments en faveur d'une **réglementation** plus contraignante imposant des délais stricts de divulgation des vulnérabilités critiques aux fournisseurs technologiques, une mesure déjà discutée dans plusieurs juridictions occidentales mais rarement appliquée avec la rigueur nécessaire.

Je crois que ce type d'incident, aussi frustrant soit-il pour les équipes de sécurité concernées, peut paradoxalement servir de catalyseur pour des réformes réglementaires bénéfiques à l'ensemble de l'écosystème numérique occidental.

*Je pense sincèrement qu'une **réglementation** plus stricte sur les délais de divulgation des vulnérabilités, même si elle complique la vie des géants technologiques, servirait mieux les intérêts collectifs de **sécurité nationale** que la situation actuelle où chaque fournisseur gère la transparence selon son propre calendrier interne.*

## Ce que cette crise révèle sur la fatigue des équipes de sécurité

### Un rythme de correction insoutenable

Les équipes de sécurité informatique, déjà confrontées à un flux constant d'alertes et de **correctifs** à appliquer, doivent désormais gérer des délais de correction toujours plus courts, parfois de seulement trois jours comme dans le cas présent. Ce rythme, bien que compréhensible face à l'urgence des menaces actives, contribue à un épuisement professionnel documenté dans l'ensemble du secteur de la cybersécurité.

La multiplication de ces urgences successives, SharePoint en mars, puis à nouveau en juillet, sans compter les innombrables autres vulnérabilités critiques touchant d'autres plateformes durant la même période, illustre l'ampleur de la charge de travail imposée aux professionnels de la sécurité informatique.

### Le besoin urgent d'automatisation et de ressources supplémentaires

Je crois que cette pression constante justifie des investissements accrus dans l'automatisation des processus de correction et de détection, ainsi qu'un renforcement significatif des effectifs dédiés à la cybersécurité, tant dans le secteur public que privé, à travers l'ensemble du monde occidental.

Sans ces investissements structurels, les équipes de sécurité continueront de fonctionner en mode de gestion de crise perpétuelle, une situation intenable à long terme face à des adversaires de plus en plus sophistiqués et bien financés.

*Je pense que la fatigue chronique des équipes de sécurité informatique constitue elle-même un risque de sécurité nationale sous-estimé. Un analyste épuisé, débordé par des dizaines d'alertes urgentes simultanées, finit inévitablement par en laisser passer une, et cette faille-là pourrait être la plus dangereuse de toutes.*

## Le coût économique invisible d'une crise de cybersécurité

### Des heures supplémentaires qui ne figurent dans aucun budget

Derrière chaque alerte de **CISA** se cache une réalité économique rarement chiffrée: des équipes informatiques entières mobilisées en urgence, souvent durant un long week-end férié américain autour du **4 juillet**, pour appliquer des **correctifs** qui n'étaient pas prévus dans leur calendrier de travail habituel. Ces heures supplémentaires, ces contrats de consultants externes appelés en renfort, ces projets informatiques retardés pour libérer des ressources, représentent un coût économique réel qui ne figure jamais dans les communiqués officiels de **Microsoft** ou de **CISA**.

Pour une **petite ou moyenne entreprise** qui ne dispose pas d'une équipe de sécurité dédiée à temps plein, ce genre d'urgence peut représenter un choc budgétaire disproportionné, forçant parfois le recours à des prestataires externes facturés à des tarifs d'urgence nettement supérieurs aux tarifs habituels du marché.

### Le fardeau disproportionné pour les organisations sous-financées

Les **gouvernements municipaux**, les **hôpitaux régionaux** et les **petites institutions d'enseignement**, souvent parmi les utilisateurs les plus fidèles des anciennes versions de **SharePoint Server** déployées sur site plutôt que dans le nuage, sont précisément les organisations les moins bien équipées financièrement pour répondre à ce genre d'urgence en trois jours.

Cette asymétrie de ressources entre grandes entreprises technologiques dotées d'équipes de sécurité sophistiquées et petites organisations à budget limité crée un écart de vulnérabilité structurel qui mérite une attention particulière de la part des décideurs publics occidentaux.

*Je pense que les échéances uniformes imposées à toutes les organisations, quelle que soit leur taille ou leurs ressources, ignorent une réalité économique fondamentale. Une agence fédérale disposant d'une équipe de sécurité à temps plein n'est pas dans la même situation qu'une petite municipalité gérant son informatique avec un budget minimal.*

## Ce que les utilisateurs finaux devraient comprendre de cette crise

### Une vulnérabilité technique, mais des conséquences bien concrètes

Pour l'employé ordinaire qui utilise **SharePoint** au quotidien pour partager des documents avec ses collègues, cette crise technique peut sembler abstraite et lointaine. Pourtant, si son organisation ne corrige pas la faille à temps, les conséquences concrètes peuvent inclure le vol de documents confidentiels, l'installation de logiciels malveillants sur le réseau interne, ou encore une interruption complète des services de collaboration documentaire pendant la remédiation d'urgence.

Je crois qu'il est essentiel de vulgariser ce type de crise technique pour le grand public, car la cybersécurité des institutions n'est plus un sujet réservé aux spécialistes: elle touche directement la vie professionnelle quotidienne de millions de travailleurs occidentaux qui dépendent de ces plateformes sans même le savoir.

### Des gestes simples qui font une réelle différence

En attendant que leur service informatique applique les correctifs nécessaires, les employés peuvent contribuer à limiter les risques en signalant rapidement tout comportement inhabituel sur les plateformes de collaboration, en évitant de stocker des informations extrêmement sensibles sur des systèmes potentiellement vulnérables, et en respectant scrupuleusement les consignes de sécurité informatique diffusées par leur organisation durant cette période critique.

Cette vigilance collective, bien que modeste à l'échelle individuelle, contribue concrètement à réduire la fenêtre d'exposition durant laquelle une organisation reste vulnérable à une **exploitation active** de la faille.

*Je trouve important de rappeler que la cybersécurité n'est jamais uniquement l'affaire des experts techniques. Chaque employé qui clique, partage ou stocke un document participe, souvent sans le savoir, à la posture de sécurité globale de son organisation.*

## Conclusion : une leçon qui dépasse largement SharePoint

### Ce que cette crise nous enseigne collectivement

Cette crise autour de **CVE-2026-45659** dépasse largement le cadre technique d'une simple faille SharePoint corrigée dans l'urgence. Elle illustre, avec une clarté presque pédagogique, les failles structurelles de notre écosystème de cybersécurité collectif: la lenteur de divulgation des fournisseurs, la dépendance excessive envers un nombre restreint de plateformes dominantes, l'asymétrie réglementaire entre secteur public et privé, et l'épuisement croissant des équipes chargées de défendre nos **infrastructures** numériques.

Aucun de ces problèmes ne se résoudra avec un simple correctif logiciel, aussi urgent soit-il d'appliquer celui disponible aujourd'hui pour SharePoint.

### L'appel à une vigilance permanente plutôt qu'épisodique

Je termine cette analyse avec une conviction simple: la cybersécurité occidentale ne peut plus se permettre de fonctionner en mode réactif, courant d'une échéance de trois jours à l'autre. Elle exige une refonte structurelle de nos priorités d'investissement, de nos exigences réglementaires envers les fournisseurs technologiques, et de notre soutien envers les professionnels qui, chaque jour, protègent des infrastructures dont dépend concrètement notre souveraineté numérique collective.

D'ici le **14 juillet**, date de fin de vie de deux des versions affectées, chaque organisation encore exposée devra avoir fait son choix: patcher, migrer, ou assumer un risque que l'actualité de ces derniers jours a rendu impossible à ignorer.

*Je referme cette analyse avec un constat simple: nous continuerons de vivre ces crises à répétition tant que la cybersécurité occidentale restera pensée comme une série d'urgences ponctuelles plutôt que comme un chantier structurel permanent. **CVE-2026-45659** sera oubliée dans quelques semaines, remplacée par la prochaine alerte. Le vrai test sera de voir si, cette fois, les leçons collectives finissent par être retenues.*

**Signé Maxime Marquette, chroniqueur**

## Encadré de transparence du chroniqueur

### Positionnement éditorial

Je ne suis pas journaliste, mais **chroniqueur et analyste**. Mon expertise réside dans l'observation et l'analyse des dynamiques géopolitiques, économiques et stratégiques qui façonnent notre monde. Mon travail consiste à décortiquer les stratégies politiques, à comprendre les mouvements économiques globaux, à contextualiser les décisions des acteurs internationaux et à proposer des perspectives analytiques sur les transformations qui redéfinissent nos sociétés.

Je ne prétends pas à l'objectivité froide du journalisme traditionnel, qui se limite au rapport factuel. **Je prétends à la lucidité analytique**, à l'interprétation rigoureuse, à la compréhension approfondie des enjeux complexes qui nous concernent tous. Mon rôle est de donner du sens aux faits, de les situer dans leur contexte historique et stratégique, et d'offrir une lecture critique des événements.

### Méthodologie et sources

Ce texte respecte la distinction fondamentale entre **faits vérifiés et analyses interprétatives**. La règle de méthode est constante : une information factuelle n'est publiée que si une source vérifiable la porte, et les sources effectivement utilisées par cet article sont listées sous **Sources**, jamais ici.

**Familles de sources primaires** retenues par la publication, quand le dossier en comporte : communiqués officiels des gouvernements et institutions internationales, déclarations publiques des dirigeants politiques, rapports d'organisations intergouvernementales, dépêches d'agences de presse internationales reconnues.

**Familles de sources secondaires** : publications spécialisées, médias d'information reconnus internationalement, analyses d'institutions de recherche établies, rapports d'organisations sectorielles.

Quand un article cite des données statistiques, économiques ou géopolitiques, elles proviennent d'institutions productrices de données (organisations intergouvernementales, banques centrales, instituts statistiques nationaux), et l'institution exacte est nommée sous **Sources**.

### Nature de l'analyse

Les analyses, interprétations et perspectives présentées dans les sections analytiques de cet article constituent une **synthèse critique et contextuelle** basée sur les informations disponibles, les tendances observées et les commentaires d'experts cités dans les sources consultées.

Mon rôle est d'interpréter ces faits, de les contextualiser dans le cadre des dynamiques géopolitiques et économiques contemporaines, et de leur donner un sens cohérent dans le grand récit des transformations qui façonnent notre époque. Ces analyses reflètent une expertise développée à travers l'observation continue des affaires internationales et la compréhension des mécanismes stratégiques qui animent les acteurs globaux.

Cet article décrit un état documenté à sa date de publication, et non une prédiction : une évolution ultérieure peut en déplacer les perspectives. Aucune mise à jour n'est promise d'avance; lorsqu'un article est corrigé ou complété, la modification est datée dans le texte.

## Sources

### Sources primaires

- Centre canadien pour la cybersécurité, alerte sur la vulnérabilité critique SharePoint CVE-2026-45659 — 2 juillet 2026

- Aviatrix, faille RCE SharePoint activement exploitée — 2 juillet 2026

- NVD, fiche technique détaillée CVE-2026-45659 — 1er juillet 2026

### Sources secondaires

- The Register, Microsoft jugeait l'exploitation improbable, CISA l'a ajoutée au catalogue KEV — 2 juillet 2026

- CybelAngel, analyse détaillée de la faille SharePoint CVE-2026-45659 — 3 juillet 2026

- The Hacker News, la faille RCE SharePoint ajoutée au catalogue KEV après exploitation active — 2 juillet 2026

---

Source : Maxime Marquette, MadMax. Pour citer ce texte, nommer l’auteur et lier https://mad-max.co/fr/article/la-faille-sharepoint-que-microsoft-a-patchee-puis-oubliee-d-annoncer