Brotli, patchs US et dépendance invisible : le réveil d'une ETI industrielle européenne

# Brotli, patchs US et dépendance invisible : le réveil d'une ETI industrielle européenne

Il y a des moments où une vulnérabilité technique devient une leçon politique. La faille découverte en 2025 dans la bibliothèque de compression Brotli — intégrée dans des dizaines de navigateurs, de serveurs web et d'outils DevOps — en est un exemple presque parfait. Pas spectaculaire au premier regard. Pas du niveau d'une fuite massive de données. Mais révélatrice, pour qui veut bien regarder, d'un problème structurel que les DSI et RSSI européens ne peuvent plus se permettre d'ignorer en 2026 : la dépendance asymétrique aux cycles de patch décidés à San Francisco ou à Seattle.

Voici le retour terrain d'une ETI industrielle de 800 salariés, fabricant de composants mécaniques de précision, dont le nom restera confidentiel à sa demande. Ce qu'elle a traversé mérite d'être raconté. Les conclusions sont transférables.

Le jour où la bibliothèque de compression est devenue un problème de gouvernance

La RSSI de cette ETI — appelons-la simplement L. — n'avait pas Brotli en haut de sa liste de risques. Personne n'avait Brotli en haut de sa liste. C'est précisément le problème.

Brotli est partout, silencieusement. Développée à l'origine par Google, open-sourcée, intégrée nativement dans Chromium, Firefox, dans nginx, dans des proxies reverse, dans des CDN, dans des pipelines CI/CD. Quand la vulnérabilité a été rendue publique et qu'un patch a été émis, L. a lancé ce qui devait être un audit de routine. Ce qu'elle a découvert l'a conduite à poser une question bien plus large que "est-ce qu'on a patché ?"

> « On a mis trois semaines à cartographier tous les endroits où Brotli était présent dans notre infrastructure. Trois semaines. Et on n'est pas une grande organisation. On a trouvé Brotli dans des composants qu'on ne savait même pas qu'on utilisait directement. »

L'ETI avait, comme la majorité de ses homologues européennes, bâti son infrastructure par sédimentation. Des couches d'outils, souvent d'origine américaine, souvent hébergés sur des clouds américains, souvent mis à jour selon des calendriers décidés par des éditeurs américains. Brotli n'était pas le problème. Brotli était le révélateur.

Ce que l'audit a vraiment mis au jour

L. et son équipe ont conduit un exercice que je considère comme indispensable — et que trop peu d'ETI réalisent avant d'y être forcées par un incident : un audit de dépendance de leur chaîne de patches.

La question n'était pas seulement « quelles sont nos vulnérabilités ? » mais « de qui dépendons-nous pour les corriger, et dans quel délai, et sous quelle juridiction ? »

Le résultat a été inconfortable.

Une part significative des composants logiciels critiques de l'ETI — du navigateur utilisé par les opérateurs sur les postes industriels aux outils de supervision réseau — était sous la dépendance directe de cycles de release pilotés par des acteurs américains. Concrètement : la capacité de L. à protéger ses systèmes dépendait, en dernière instance, de décisions prises hors de son contrôle, hors de la juridiction européenne, sans obligation contractuelle de délai.

Et ce n'est pas une question théorique. Sous le Cloud Act américain, un éditeur US peut être contraint de coopérer avec des autorités fédérales américaines sans nécessairement en informer ses clients européens. Quand vos cycles de patch — et donc votre fenêtre d'exposition — sont pilotés par ces mêmes éditeurs, vous n'êtes pas seulement dépendant techniquement. Vous êtes dépendant politiquement.

L. l'a formulé sobrement : *« On a compris qu'on avait externalisé notre capacité de réaction. »*

NIS2, DORA et la question qui gêne

L'ETI en question opère dans un secteur qui entre dans le périmètre NIS2 — la directive européenne sur la cybersécurité des entités essentielles et importantes, dont les obligations de signalement et de gestion des risques de la chaîne d'approvisionnement sont entrées pleinement en vigueur. DORA, de son côté, impose aux entités financières (et par extension à leurs prestataires technologiques) une traçabilité des risques liés aux tiers.

Voici la question que ces cadres réglementaires posent, et que trop peu de juristes et de DSI croisent explicitement : si votre capacité à appliquer un patch critique dépend du bon vouloir d'un éditeur hors UE, et que cet éditeur subit une pression gouvernementale ou décide unilatéralement de modifier sa politique de support — que répondez-vous à votre autorité de contrôle nationale ?

NIS2 exige une gestion des risques de la chaîne d'approvisionnement. Pas une gestion des risques *techniques*. Une gestion des risques *systémiques*, incluant les dépendances géopolitiques. L'audit Brotli de cette ETI a mis en évidence que sa chaîne d'approvisionnement logicielle était, sur plusieurs points critiques, ni auditable de façon indépendante, ni substituable rapidement.

Je pense que c'est là le vrai sujet de 2026 pour les RSSI européens : la conformité réglementaire ne peut plus être dissociée de la question de souveraineté opérationnelle.

Ce que l'ETI a changé — sans tout révolutionner

L. est pragmatique. Elle ne prétend pas avoir résolu la dépendance en quelques mois. Ce serait mentir. Mais l'audit a produit trois changements concrets que je trouve instructifs.

Premier changement : la cartographie des dépendances est devenue un livrable récurrent. Pas un one-shot, pas un audit annuel. Un processus vivant, intégré dans les rituels de l'équipe sécurité. L'objectif n'est pas l'exhaustivité parfaite — elle est impossible — mais la capacité à répondre rapidement à la question : *« Où est ce composant dans notre SI, et qui contrôle son cycle de vie ? »*

**Deuxième changement : la criticité des composants a été re-qualifiée selon un critère de substituabilité.** Un composant n'est plus seulement noté sur sa vulnérabilité potentielle, mais sur sa remplaçabilité par une alternative sous juridiction européenne. Cela a notamment conduit l'ETI à engager une conversation sérieuse avec Nextcloud — l'acteur allemand de collaboration et de gestion documentaire — pour des usages où elle utilisait jusqu'alors des outils sous dépendance américaine. Pas par idéologie, mais parce que la substituabilité est devenue un critère de résilience.

Troisième changement : la relation avec les éditeurs a été renégociée sur les SLA de patch. L. a exigé, dans les renouvellements contractuels, des engagements explicites sur les délais de notification et de mise à disposition des correctifs pour les composants critiques. Certains éditeurs ont accepté. D'autres ont refusé ou botté en touche. Ces refus sont devenus, en eux-mêmes, des signaux de risque documentés.

La leçon que je tire de ce cas

Brotli n'est pas une anecdote. Brotli est un cas d'école de ce que les analystes commencent à appeler la *dépendance de patch* — cette forme particulière de dépendance où ce n'est pas l'usage d'un outil qui vous lie à un acteur extérieur, mais votre capacité à vous protéger.

Les GAFAM et leurs écosystèmes ont construit, souvent en open-source, des infrastructures sur lesquelles l'industrie européenne s'est reposée. Ce n'est pas un complot. C'est le résultat d'un rapport de force technologique et économique que l'Europe a mis du temps à prendre au sérieux. Mais en 2026, avec NIS2 en vigueur, avec DORA qui mord, avec un contexte géopolitique qui rend l'extraterritorialité américaine plus prégnante que jamais, ce rapport de force a des conséquences concrètes sur la capacité des organisations européennes à répondre de leur propre sécurité.

Il faut nommer les choses clairement : dépendre du calendrier de patch d'un acteur sous juridiction américaine, c'est avoir externalisé une partie de votre souveraineté opérationnelle. Ce n'est pas une posture idéologique. C'est une réalité de gestion des risques.

L'ETI dont je viens de raconter l'histoire n'a pas tout résolu. Mais elle a fait quelque chose de plus difficile qu'il n'y paraît : elle a rendu visible l'invisible. Elle a nommé une dépendance que personne n'avait jugé utile de cartographier, parce que tout fonctionnait.

C'est souvent quand tout fonctionne qu'on oublie de demander : *de qui dépend ce fonctionnement ?*

C'est exactement la question que les DSI et RSSI européens doivent poser — pas après le prochain incident, mais maintenant.