npm sous tutelle américaine : ce que chaque ligne de code européen doit à Microsoft sans le savoir

# npm sous tutelle américaine : ce que chaque ligne de code européen doit à Microsoft sans le savoir

Il y a une infrastructure que presque personne dans votre organisation ne surveille, et pourtant elle conditionne chaque mise en production, chaque pipeline CI/CD, chaque livraison logicielle. Elle s'appelle npm. Elle appartient à Microsoft. Et depuis 2026, les signaux qui en émanent ne sont plus anodins pour un DSI européen qui se pose honnêtement la question de la maîtrise de son système d'information.

Ce n'est pas un article sur JavaScript. C'est un article sur la façon dont une infrastructure critique de votre chaîne logicielle a été privatisée, consolidée sous un pavillon américain, et positionnée de manière à rendre toute sortie structurellement coûteuse. Voici ce que ça implique concrètement pour votre budget IT et votre capacité à négocier.

Comment une infrastructure publique est devenue un actif Microsoft

Pour comprendre où vous en êtes aujourd'hui, il faut remonter à 2020. Cette année-là, GitHub — déjà acquis par Microsoft en 2018 pour 7,5 milliards de dollars — rachète npm, Inc., la société qui gérait le registre npm (Node Package Manager). Le registre npm est alors le plus grand écosystème de paquets logiciels au monde, avec des dizaines de milliards de téléchargements par mois.

La transaction est présentée comme une bonne nouvelle pour la communauté open source : npm allait enfin avoir les ressources pour se stabiliser, investir dans la sécurité, améliorer les outils. Et c'est en partie vrai. Sauf que personne ne pose la question fondamentale : qu'est-ce que ça signifie de confier une infrastructure publique critique — le canal par lequel circulent les dépendances de millions d'applications — à un acteur commercial dont l'intérêt est structurellement différent de celui de ses utilisateurs ?

En 2026, cette question n'est plus théorique. La consolidation est achevée. npm est intégré dans l'écosystème GitHub Actions, GitHub Packages, GitHub Advanced Security. Ce n'est plus un outil indépendant. C'est un composant d'une plateforme, et cette plateforme appartient à Redmond.

Pour un DSI d'ETI européenne, cela se traduit par un fait simple et inconfortable : une partie de votre chaîne de fabrication logicielle repose sur une infrastructure que vous ne contrôlez pas, dont vous ne négociez pas les conditions, et dont les évolutions tarifaires ou de gouvernance se décident sans votre input et sans obligation de préavis.

L'économie réelle de la dépendance : ce que coûte vraiment npm à votre SI

Parlons budget. La dépendance à npm a une économie propre que la plupart des directions informatiques ne modélisent pas correctement, parce qu'elle est en grande partie invisible dans les lignes budgétaires.

Le coût direct, d'abord. L'accès au registre public npm est gratuit pour la majorité des usages. Mais « gratuit » ne signifie pas « sans coût ». Les organisations qui utilisent des fonctionnalités avancées — paquets privés, gestion d'organisations, intégration avec GitHub Packages — entrent dans des modèles de facturation qui sont, depuis l'intégration complète dans GitHub, directement liés aux abonnements GitHub Enterprise ou GitHub Teams. Autrement dit, votre registre de dépendances n'est plus dissociable de votre contrat avec l'acteur américain dominant.

Le coût indirect, ensuite, est bien plus significatif. Il se décompose en trois postes que vos équipes supportent sans les avoir budgétés comme tels :

Premièrement, le coût de conformité réglementaire. Depuis l'entrée en vigueur du Data Act européen et les discussions en cours autour du Cyber Resilience Act, les organisations doivent être en mesure de tracer l'origine, la chaîne de custody et la sécurité de chaque dépendance logicielle embarquée dans leurs produits. Lorsque cette chaîne passe par une infrastructure dont les logs, les politiques de rétention et les mécanismes d'audit sont gouvernés par le droit américain (notamment le Cloud Act), produire la documentation nécessaire à une conformité européenne devient un exercice coûteux et incomplet. Vos équipes sécurité passent du temps à pallier une lacune structurelle.

Deuxièmement, le coût de friction opérationnelle. Chaque incident sur le registre npm — et il y en a eu, y compris des suppressions de paquets critiques qui ont mis en évidence la fragilité de l'écosystème — se répercute directement sur vos pipelines de déploiement. Quand votre CI/CD s'appuie sur un registre que vous ne maîtrisez pas, le rayon d'explosion d'une défaillance externe est potentiellement illimité. En termes actuariels, ce risque non couvert devrait figurer dans votre analyse de risques SI.

Troisièmement, le risque tarifaire à horizon 24-36 mois. L'histoire récente des hyperscalers montre un pattern cohérent : phase d'adoption gratuite ou subsidisée, consolidation de l'écosystème, puis monétisation progressive des usages critiques. npm n'échappe pas à cette logique. Aujourd'hui, les fonctionnalités avancées sont déjà payantes et liées à l'abonnement GitHub. La question n'est pas de savoir si la pression tarifaire va augmenter, mais quand et sous quelle forme. Un DSI qui ne modélise pas ce risque dans son plan pluriannuel informatique fait une erreur de gestion.

Le vrai problème : la chaîne logicielle comme angle mort souverain

La dépendance à npm est symptomatique d'un problème plus large que les DSI européens ont collectivement sous-estimé : la chaîne logicielle elle-même est devenue un vecteur de dépendance stratégique, au même titre que les clouds, les messageries ou les suites bureautiques.

On parle beaucoup de souveraineté cloud. On parle de moins en moins — et c'est une erreur — de souveraineté de la chaîne de dépôt et de distribution logicielle. Or cette chaîne inclut aujourd'hui, pour une ETI européenne standard : un dépôt de code (souvent GitHub), un système de gestion des dépendances (souvent npm ou équivalent), un système d'intégration continue (souvent GitHub Actions ou un équivalent lié à la même infrastructure), et un registre d'artefacts (souvent GitHub Packages ou un service cloud américain).

L'effet de verrouillage n'est pas théorique. Il est mécanique. Chaque outil de cette chaîne produit des formats, des API, des conventions qui créent des coûts de migration. Chaque semaine qui passe sans avoir construit une alternative internalise un peu plus la dépendance. Et chaque ingénieur recruté qui commence sa carrière sur ces outils renforce l'inertie organisationnelle.

Du point de vue du risque géopolitique — qui est devenu une catégorie de risque SI légitime depuis 2022 —, cette situation est préoccupante. Une décision réglementaire américaine, une modification des conditions d'utilisation, ou un incident de sécurité majeur sur l'infrastructure GitHub/npm pourrait avoir des conséquences directes sur la capacité de vos équipes à livrer du code. Ce n'est pas de la paranoïa. C'est de la gestion de risques.

Ce que font les organisations européennes qui ont commencé à reprendre la main

Le marché européen n'est pas désarmé. Des alternatives existent, et certaines organisations ont commencé à restructurer leur chaîne logicielle sans attendre un incident pour le justifier.

L'approche la plus pragmatique — celle qui minimise le coût de transition tout en réduisant l'exposition — consiste à introduire un registre de proxy et de cache intermédiaire hébergé sur infrastructure européenne. Ce registre agit comme un miroir contrôlé du registre npm public : il valide, scanne, et met en cache les paquets utilisés par vos équipes, tout en leur offrant une surface d'audit conforme aux exigences réglementaires européennes. En cas de défaillance ou de modification des conditions d'accès au registre npm originel, vos pipelines continuent de fonctionner.

Cette approche ne résout pas tout — elle ne supprime pas la dépendance à l'écosystème npm en tant que format —, mais elle réduit significativement l'exposition opérationnelle et budgétaire à court terme. Son coût est maîtrisable et elle est réversible.

Du côté des acteurs qui adressent ce problème, Gitea (projet open source, déployable en auto-hébergement ou via des hébergeurs européens) et Forgejo (le fork communautaire de Gitea, qui a gagné en maturité) permettent de reconstruire une chaîne de dépôt code et de gestion de paquets sans dépendance à une infrastructure américaine. Ils ne sont pas aussi riches fonctionnellement que GitHub — et il faut être honnête sur ce point avec vos équipes de développement — mais ils offrent une base viable pour les organisations dont la posture souverainiste est un choix stratégique assumé.

La vraie question pour un DSI n'est pas « est-ce que Forgejo remplace GitHub à fonctionnalités égales ? ». La vraie question est : « quel est le coût acceptable de ne pas avoir cette alternative quand j'en aurai besoin ? »

Plan d'action pour le DSI : trois décisions à prendre avant la fin de l'année

L'enjeu ici n'est pas de lancer une migration massive qui mobilisera vos équipes pendant deux ans pour un gain incertain. C'est de prendre des décisions qui réduisent votre exposition sans bloquer votre productivité. Voici ce qui est actionnable à horizon court terme.

Première décision : auditer votre exposition réelle. Cartographiez précisément quelles parties de votre chaîne logicielle dépendent du registre npm, dans quelles conditions et avec quelles garanties de service. Cet audit doit inclure une analyse juridique de la position de ces données vis-à-vis du Cloud Act américain. Si vous n'avez pas cette visibilité, vous ne pouvez pas gérer ce risque.

Deuxième décision : internaliser ou répliquer le registre de dépendances. Déployez un registre proxy sur infrastructure européenne — idéalement hébergé chez un prestataire certifié SecNumCloud ou équivalent dans votre juridiction. C'est une décision d'infrastructure, pas une décision architecturale majeure. Elle peut se prendre et s'implémenter rapidement. Elle vous offre une continuité opérationnelle en cas d'incident sur l'infrastructure américaine et une traçabilité auditée de vos dépendances.

Troisième décision : intégrer le risque tarifaire dans votre plan pluriannuel. Si votre budget IT est actuellement construit sans ligne de risque sur l'évolution des coûts GitHub/npm, corrigez cela dès le prochain cycle budgétaire. Modélisez des scénarios de hausse tarifaire et leurs impacts sur vos coûts de migration potentiels. Cette modélisation vous donnera aussi un argument objectif pour budgéter la transition vers des alternatives si vous choisissez de l'engager.

La dépendance à npm n'est pas une fatalité technique. C'est le résultat d'une série de décisions — souvent des non-décisions — prises à une époque où la question de la souveraineté numérique n'était pas posée avec la même acuité qu'aujourd'hui. En 2026, elle l'est. Et les organisations qui ont commencé à construire leur résilience sur ce point précis ont pris de l'avance que leurs concurrentes paieront, d'une manière ou d'une autre, pour rattraper.

Votre chaîne logicielle n'est pas un détail d'infrastructure. C'est la colonne vertébrale de votre capacité à livrer de la valeur. La laisser reposer entièrement sur une infrastructure dont vous ne maîtrisez ni la gouvernance, ni les tarifs, ni la conformité réglementaire, c'est accepter un risque que vous ne pouvez pas vous permettre de ne pas avoir évalué.