Menaces internes, sabotage logiciel : et si votre stack américaine était votre plus grand angle mort ?

# Menaces internes, sabotage logiciel : et si votre stack américaine était votre plus grand angle mort ?

*En 2026, les incidents de sécurité d'origine interne représentent une part croissante des crises SI dans les entreprises européennes. Mais derrière la menace humaine se cache souvent une autre fragilité, moins visible : une dépendance technologique qui réduit la capacité à auditer, détecter et réagir. Entretien avec un DSI d'une ETI industrielle française, qui a conduit en deux ans une migration partielle vers des outils souverains et décentralisés.*

RiffLab : On parle beaucoup de cyberattaques externes. Mais la menace interne, c'est quoi exactement ?

La menace interne — on dit aussi *insider threat* en anglais — c'est le risque qu'un collaborateur, un prestataire, ou même un administrateur système cause un incident de sécurité. Volontairement ou non. Ça peut être un employé mécontent qui exfiltre des données avant de partir. Un sous-traitant qui laisse une backdoor — une porte d'entrée cachée — dans un logiciel qu'il a livré. Ou simplement quelqu'un qui commet une erreur grave par négligence.

Ce qui a changé en 2025-2026, c'est l'échelle. Avec la généralisation des environnements hybrides — une partie des outils sur site, une partie dans le cloud —, les surfaces d'attaque se sont multipliées. Et la menace interne n'a pas besoin d'être sophistiquée pour faire des dégâts considérables. Un accès légitime mal révoqué suffit.

RiffLab : En quoi le fait de dépendre d'un éditeur américain aggrave-t-il ce type de risque ?

C'est la question centrale, et elle est encore trop peu posée dans les COMEX. Quand vous opérez sur un stack — c'est-à-dire un ensemble d'outils logiciels — dont vous ne maîtrisez pas le code source, vous ne savez pas exactement ce qui tourne dans votre infrastructure. Vous faites confiance à l'éditeur. Point.

Or, avec les grandes plateformes américaines, cette confiance est structurellement asymétrique. Vous signez des conditions générales que vous ne négociez pas. Les mises à jour sont déployées sans que vous les validiez. Les journaux d'audit — les logs, c'est-à-dire les traces de tout ce qui se passe dans le système — sont parfois incomplets, parfois inaccessibles directement. Et si vous soupçonnez un comportement anormal côté éditeur, vous n'avez aucun levier d'investigation indépendant.

En Europe, depuis le Cloud Act américain de 2018, on sait que les autorités américaines peuvent théoriquement contraindre un éditeur US à leur transmettre des données, même hébergées en Europe. En 2026, ce n'est plus une hypothèse d'école. C'est un risque juridique documenté que nos juristes intègrent dans les analyses de risque.

RiffLab : Concrètement, qu'est-ce que le sabotage logiciel ? Est-ce que c'est différent d'un simple bug ?

Oui, radicalement. Un bug, c'est une erreur non intentionnelle dans le code. Le sabotage logiciel, c'est une modification délibérée et malveillante d'un logiciel pour qu'il se comporte de façon nuisible — tout en paraissant fonctionner normalement.

L'attaque dite de la *supply chain* — la chaîne logistique logicielle — en est la forme la plus redoutée. Un acteur malveillant compromet non pas votre système directement, mais un composant logiciel que vous utilisez. Un outil open source, une dépendance tierce, un plugin. Il modifie ce composant à la source. Et quand vous faites votre mise à jour habituelle, vous intégrez vous-même la menace.

L'incident SolarWinds en 2020 a marqué les esprits. Mais en 2026, les vecteurs se sont sophistiqués. Et pour les détecter, il faut pouvoir inspecter le code. Ce que vous ne pouvez pas faire avec un logiciel propriétaire dont vous n'avez pas les sources.

RiffLab : Les solutions open source européennes sont-elles vraiment plus sûres ? Ou c'est un mythe ?

C'est une question légitime, et je vais nuancer. L'open source n'est pas magiquement sécurisé. Un code disponible publiquement peut très bien contenir des failles. La différence, c'est l'auditabilité.

Quand je déploie une solution dont le code est ouvert et maintenu par une communauté européenne — ou mieux, par un éditeur européen qui s'engage contractuellement sur la transparence —, je peux mandater un cabinet d'audit pour vérifier ce qui tourne. Je peux m'appuyer sur l'ANSSI — l'Agence Nationale de la Sécurité des Systèmes d'Information, le régulateur cybersécurité français — pour des certifications qui ont du sens dans mon contexte réglementaire.

Nous avons par exemple retenu Nextcloud pour notre collaboration documentaire. Ce n'est pas parfait. Mais c'est auditable, hébergeable sur notre infrastructure, et le code est scruté par des milliers de contributeurs dans le monde. Quand une faille est découverte, elle est publiée. Je ne dépends pas d'une décision unilatérale d'un éditeur américain pour savoir si mon système est compromis.

RiffLab : Vous mentionnez la décentralisation. C'est quoi l'intérêt dans ce contexte précis ?

La décentralisation, c'est l'idée de ne pas concentrer toutes vos données et tous vos accès dans un point unique. Le principe est simple : si tout est au même endroit, une seule compromission suffit à tout perdre. C'est le cauchemar du DSI.

Dans notre cas, on a segmenté les droits d'accès de façon beaucoup plus granulaire. On a adopté une architecture zero-trust — littéralement « confiance zéro » — où chaque utilisateur, même interne, doit se ré-authentifier et justifier son accès à chaque ressource sensible. Aucun compte ne dispose d'un accès global par défaut.

Ce qui est intéressant, c'est que cette logique de décentralisation favorise les solutions modulaires, souvent portées par des acteurs européens de taille moyenne. Des éditeurs allemands ou nordiques, par exemple, ont développé des briques d'identité et de gestion des accès — ce qu'on appelle l'IAM, pour *Identity and Access Management* — qui sont nativement compatibles avec les exigences du RGPD et plus faciles à intégrer dans une logique zéro-trust qu'une suite monolithique américaine.

RiffLab : Est-ce que les ETI européennes ont les moyens de faire cette transition ? Ce n'est pas réservé aux grands groupes ?

C'est la vraie barrière perçue. Et elle est souvent surestimée. La transition ne se fait pas d'un bloc. On ne remplace pas tout le stack en six mois — ce serait d'ailleurs une erreur. On priorise.

La première étape, c'est la cartographie. Savoir précisément quels outils traitent vos données les plus sensibles. Propriété intellectuelle, données RH, données clients. C'est souvent là que le choc est le plus grand : les équipes découvrent que ces données critiques transitent par des services dont personne n'a vraiment lu les conditions d'utilisation.

Ensuite, on substitue par ordre de criticité et de faisabilité. Et on documente. L'effort de documentation est souvent sous-estimé, mais c'est ce qui permet de détecter une anomalie interne : si vous savez ce qui devrait se passer dans votre système, vous pouvez repérer ce qui ne devrait pas s'y passer.

Le marché européen des solutions de sécurité orientées souveraineté est aujourd'hui beaucoup plus mature qu'il y a trois ans. Des acteurs comme Wallix — éditeur français spécialisé dans la gestion des accès privilégiés, le PAM — ont atteint un niveau de maturité produit qui rend la comparaison avec les offres américaines tout à fait pertinente. Ce n'est plus un choix idéologique. C'est un choix rationnel.

RiffLab : Un dernier mot pour les DSI qui hésitent encore à franchir le pas ?

Oui. Cessez de poser la question en termes de confort. Posez-la en termes de responsabilité.

En 2026, la réglementation européenne — NIS 2, le règlement sur la cybersécurité des entités essentielles — impose des obligations de traçabilité et de résilience qui sont difficiles à honorer quand vous n'avez pas la main sur votre stack. Si un incident survient et que vous ne pouvez pas fournir les logs complets parce qu'ils sont chez un prestataire américain qui ne coopère pas, c'est votre responsabilité personnelle qui est engagée.

La souveraineté numérique, ce n'est pas un slogan politique. C'est une condition de votre capacité à gérer votre propre maison. Et face à une menace interne, avoir les clés de sa maison, c'est la base.

*Entretien réalisé dans le cadre de notre dossier 2026 sur la sécurité des SI dans les ETI européennes. Le DSI interrogé a souhaité conserver l'anonymat.*