Chaîne d’approvisionnement 2026 : le fournisseur non choisi

Près d’une violation de données sur deux implique désormais un tiers (fournisseur, partenaire). Le chiffre est de 48 %, tiré du Data Breach Investigations Report 2026 de Verizon publié le 19 mai 2026, et l’implication de tiers progresse de 60 % sur un an. On le lit presque toujours comme un verdict sur la gestion des fournisseurs : la preuve que les entreprises ne contrôlent pas assez.

Regardez les incidents de l’année et le tableau change. Deux des trois voies de 2026 échappent en grande partie à ce qu’un questionnaire fournisseurs peut trancher : du code que personne n’a choisi, et des prestataires informatiques qui détiennent, par construction, un accès d’administration. La quasi-totalité des contrôles dont dispose une PME vise le fournisseur défaillant, et ce n’est que l’une des trois voies de 2026.

Les 48 % ne notent pas votre gestion fournisseurs

Une violation de données impliquant un tiers (fournisseur, partenaire) n’est pas la même chose qu’une défaillance de fournisseur. Les 48 % comptent des relations, et la plupart des organisations en entretiennent bien plus qu’elles n’ont de contrats. Une ETI française ou belge peut suivre quarante fournisseurs à son grand livre et plusieurs milliers de composants logiciels en production, sans recouvrement entre les deux listes et sans personne chargé de les rapprocher.

L’Europe n’est pas spectatrice. Le 2026 European Cyber Risk Report de Black Kite, publié le 25 juin 2026, a analysé 2 066 incidents rançongiciels dans 31 pays entre janvier 2025 et avril 2026. Les incidents rendus publics ont progressé de 55,1 % sur les quatre premiers mois de 2026 par rapport aux mêmes mois de 2025, de 441 à 684 ; le rythme mensuel est passé de 108 au premier semestre 2025 à 171 début 2026. L’Allemagne en a enregistré le plus, devant le Royaume-Uni, la France, l’Italie et l’Espagne : à eux cinq, près de 70 % du total. L’industrie manufacturière a concentré 27,9 % des incidents publiés. Le sous-secteur le plus visé est celui des services informatiques, et 64 organisations du jeu de données ont été compromises via un tiers plutôt que directement.

Ces deux derniers constats résument toute l’affaire. Le sous-secteur que les attaquants visent le plus est celui qui détient les accès de tous les autres.

Trois voies d’entrée, une seule prévue par vos contrats

Trois voies d’entrée dans une PME en 2026 — une seule correspond au risque prévu par vos contrats.

Le code que vous n’avez pas écrit. Les paquets open source arrivent en production par dépendances de dépendances. Votre développeur en a choisi quatre ; l’installation en a tiré neuf cents. Aucune des neuf cents n’a été achetée, évaluée ni signée.

Le prestataire qui détient vos accès. Infogérance, outils d’administration à distance, support externalisé : ces acteurs disposent d’un accès administrateur sur le parc, par construction. Une compromission chez eux n’est pas une attaque contre un fournisseur — elle arrive sous les traits de votre propre informatique.

Le fournisseur qui fait tourner vos opérations. La plateforme logistique, le prestataire de paie, l’outil de planification. C’est la seule voie pour laquelle vos contrats ont été écrits, et la seule qui se comporte comme le risque qu’ils anticipent.

Notre service vRSSI consacre plus de temps, sur son premier trimestre, à rapprocher ces trois listes qu’à toute autre tâche — parce que dans la plupart des organisations, elles n’ont jamais été posées côte à côte.

Ce que ChainDrop a fait en quelques minutes

En août 2026, un ver auto-propagé appelé ChainDrop — successeur de la campagne Shai-Hulud — a compromis plus de 400 paquets npm totalisant des centaines de millions de téléchargements par semaine. Il s’exécutait à l’installation, récupérait les jetons npm et GitHub, les identifiants cloud, les clés SSH et les secrets des chaînes d’intégration continue, puis republiait les autres paquets du mainteneur avec lui-même à l’intérieur.

La vitesse est ce qu’un conseil doit retenir. Palo Alto Unit 42 a recensé 453 dépôts d’exfiltration répartis sur cinq comptes, le plus ancien créé le 11 mai 2026, et a observé une version empoisonnée arriver six minutes après la précédente.

Aucun questionnaire ne pose la question qui aurait arrêté cela. Il ne s’agit pas de savoir si votre fournisseur impose l’authentification multifacteur. Il s’agit de savoir si un paquet installé un mardi après-midi par votre prestataire a atteint votre serveur de build avant que quiconque ne lui ait donné un nom.

Le point que tout le monde cite, et celui qui s’applique

C’est ici que le texte est plus intéressant que ses résumés.

L’article 21, paragraphe 2, point d) de NIS2 impose « la sécurité de la chaîne d’approvisionnement », et les relations qu’il nomme sont celles entre chaque entité et ses « fournisseurs ou prestataires de services directs ». L’article 21, paragraphe 3 demande ensuite aux entités de tenir compte des vulnérabilités propres à chaque fournisseur direct et de la qualité globale des produits et des pratiques de cybersécurité de ses fournisseurs et prestataires de services, y compris de ses procédures de développement sécurisé. C’est une obligation de prise en compte, pas de garantie, et elle est formulée autour des fournisseurs directs. Pour les rangs suivants, le considérant 85 indique seulement que les entités « pourraient prendre en considération » les risques qui en découlent : une faculté, pas une obligation.

Le point que tout le monde cite en comité fournisseurs n’oblige donc pas à regarder une dépendance transitive située plusieurs niveaux plus bas. Celui qui la couvre est l’article 21, paragraphe 2, point e) : la sécurité de « l’acquisition, du développement et de la maintenance » des réseaux et des systèmes d’information, y compris le traitement et la divulgation des vulnérabilités. Nous ne l’avons encore jamais vu classé sous « chaîne d’approvisionnement » dans une matrice de conformité. C’est pourtant là que vit votre chaîne de build.

Deux points de droit méritent d’être posés pour la France. Depuis le 11 septembre 2026, le règlement sur la cyberrésilience oblige les fabricants de produits comportant des éléments numériques à signaler les vulnérabilités activement exploitées : certains de vos éditeurs vous doivent désormais un avertissement qu’ils ne vous devaient pas l’an dernier. Ce règlement s’applique de plein droit, en métropole comme dans les DROM. NIS2, en revanche, est une directive : elle produit ses effets par la loi française de transposition, et celle-ci, retirée de l’ordre du jour de l’Assemblée nationale le 6 octobre sans nouvelle date, n’était toujours pas adoptée au 7 octobre 2026. La mise en conformité NIS2 anticipée reste donc un choix de gouvernance, pas encore une contrainte légale en France — ce qui n’est déjà plus le cas en Belgique ni au Luxembourg.

La moitié « premier rang » du problème est résolue, et nous en avons publié l’outil : le questionnaire que vous devriez envoyer couvre les fournisseurs que vous avez choisis. Cet article porte sur l’autre moitié.

Quatre chantiers pour les 30 prochains jours

Les quatre questions à traiter sous 30 jours. Aucune n’exige d’acheter quoi que ce soit.

1. Produire une liste de ce qui tourne réellement. Pas le grand livre fournisseurs : la nomenclature logicielle de ce que vous construisez ou déployez, et l’inventaire de tout ce qu’un tiers a installé.
2. Nommer tous les détenteurs d’accès privilégiés externes. Prestataires, sous-traitants, intégrations à jetons permanents. Pour chacun, notez qui, en interne, l’a autorisé.
3. Décider qui vous appelleriez. Pour chacune des trois voies, une personne nommée, joignable en dehors des heures ouvrées. C’est la réponse qui manque le plus souvent.
4. Répéter une coupure. Pas un exercice sur table : une révocation réelle de l’accès d’un prestataire et d’un identifiant de build, chronométrée. Si personne ne sait combien de temps cela prend, c’est précisément le constat.

Rien de tout cela n’exige l’achat d’une plateforme. Il faut que quelqu’un porte la question — un sujet de gouvernance avant d’être un sujet technique.