« L'open source n'est plus une option idéologique, c'est une armure réglementaire »

# « L'open source n'est plus une option idéologique, c'est une armure réglementaire »

*En 2026, les DSI européens ne choisissent plus l'open source par conviction militante. Ils le choisissent parce que les textes réglementaires — NIS2, DORA, le règlement sur les données — les y poussent mécaniquement. Entretien avec un DSI d'une ETI industrielle franco-allemande, qui a mené cette transition en dix-huit mois.*

RiffLab : En 2026, qu'est-ce qui a vraiment changé dans la façon dont vous justifiez un choix open source en interne ?

Ce qui a changé, c'est que je n'ai plus besoin de convaincre sur des principes. Avant, la direction financière voyait l'open source comme du bricolage à risque, et l'offre dominante américaine comme une garantie de sérieux. Aujourd'hui, la donne s'est inversée. Quand je présente un outil sous licence propriétaire hébergé aux États-Unis, la première question que me pose le DG, c'est : « Et si on nous coupe l'accès ? » Cette question n'existait pas il y a trois ans. Elle existe parce que des entreprises européennes ont vécu des ruptures contractuales unilatérales, parce que le Cloud Act n'a pas disparu, et parce que nos auditeurs NIS2 cochent désormais la case « dépendance à un fournisseur extraterritorial » comme un risque à part entière. L'open source, dans ce contexte, c'est devenu une réponse structurelle à un problème juridique concret.

RiffLab : Concrètement, comment NIS2 et DORA ont-ils modifié votre cartographie des risques liés aux briques logicielles ?

Ils l'ont forcée à grandir. Avant, je cartographiais des risques techniques — disponibilité, vulnérabilités, capacité de patch. Désormais, je dois documenter la chaîne de contrôle de chaque composant critique. Qui détient le code source ? Où sont les serveurs ? Quelle juridiction s'applique en cas de réquisition des données ? Sous DORA notamment, pour nos activités qui touchent à des services financiers, je dois démontrer la résilience opérationnelle de bout en bout, y compris chez les sous-traitants tiers. Une solution logicielle dont le code est opaque et dont les serveurs sont soumis au droit américain ne passe plus cette grille d'analyse sereinement. L'open source, lui, me donne accès au code, à l'audit, à la capacité de le déployer on-premise ou chez un hébergeur européen qualifié. Ce n'est pas une garantie absolue — un composant open source mal maintenu reste un risque — mais c'est une base sur laquelle je peux construire une conformité documentable.

RiffLab : Le Cloud Act reste le sujet qui fâche. Est-ce que vos équipes juridiques ont finalement tranché sur son applicabilité réelle à vos données ?

Ils ont tranché dans le sens que je redoutais : le risque est réel et non théorique. La position de nos avocats, confirmée par plusieurs avis que j'ai sollicités auprès de cabinets spécialisés en droit du numérique, c'est qu'une entreprise américaine — même opérant depuis un datacenter européen, même via une filiale de droit local — reste soumise à des injonctions fédérales américaines si le siège ou la société mère est aux États-Unis. Ce qui signifie que des données hébergées à Francfort ou à Dublin, dans l'infrastructure d'un acteur américain, ne sont pas à l'abri d'une demande de communication aux autorités américaines. Pour nous, qui traitons des données industrielles sensibles — plans, spécifications, données fournisseurs — ce risque n'est pas acceptable. Passer sur des solutions open source auto-hébergées ou confiées à des opérateurs européens souverains, c'est sortir de cette zone de risque. Pas complètement — aucune solution n'est parfaite — mais suffisamment pour que notre DPO puisse dormir.

RiffLab : Sur la sécurité pure, l'argument « l'open source est moins sécurisé car le code est visible » revient encore. Comment vous le gérez ?

Cet argument, je le retourne systématiquement. La visibilité du code, c'est ce qui permet l'audit indépendant. C'est ce qui a permis à des équipes de recherche européennes d'identifier des vulnérabilités critiques dans des composants largement utilisés, avant qu'elles ne soient exploitées. Avec une solution propriétaire américaine, vous faites confiance à l'éditeur sur parole. Vous ne savez pas ce qu'il y a dans la boîte noire. Et vous ne saurez jamais si une backdoor a été insérée à la demande d'une agence gouvernementale étrangère — ce qui n'est pas une hypothèse paranoïaque, c'est une réalité documentée historiquement. Ce qui est vrai, en revanche, c'est que l'open source mal gouverné est dangereux. Un composant que personne ne maintient, que vous n'avez pas pris le temps d'auditer, qui accumule des CVE sans patch — c'est un risque majeur. La réponse, ce n'est pas de fuir l'open source, c'est de se doter d'une vraie politique de gestion des composants : inventaire, veille, mise à jour, responsabilité interne. C'est ce que nous avons mis en place, et c'est ce que NIS2 attend de vous de toute façon.

RiffLab : Vous avez évoqué des hébergeurs européens qualifiés. Le label SecNumCloud de l'ANSSI est-il devenu un critère de sélection systématique dans vos appels d'offres ?

Oui, et ce n'est pas par idéologie. C'est parce que ce label est aujourd'hui l'un des rares référentiels qui donne une garantie juridiquement robuste sur la protection contre les lois extraterritoriales étrangères. Un prestataire qualifié SecNumCloud s'engage contractuellement sur l'absence de contrôle capitalistique non européen et sur des niveaux de sécurité audités. Pour nos données les plus sensibles, c'est devenu un pré-requis. Pour le reste, je regarde d'autres certifications européennes — le schéma EUCS en cours de finalisation au niveau de l'ENISA devrait d'ailleurs apporter une harmonisation bienvenue à l'échelle du marché unique. Ce qui m'importe, c'est que la chaîne de confiance soit européenne de bout en bout : le code, l'hébergement, le contrat.

RiffLab : Dernière question : quel est selon vous le piège dans lequel les DSI tombent encore le plus souvent sur ce sujet ?

Ils confondent open source et gratuité, ou open source et complexité insurmontable. Ces deux réflexes sont des héritages du passé. Le premier les conduit à sous-estimer le coût total réel — maintien en condition opérationnelle, expertise interne, intégration — et à baisser la garde sur la gouvernance. Le second les conduit à rester sur des offres américaines par confort, en se disant qu'ils feront le changement « quand ce sera mieux ». Mais « mieux » ne viendra pas tout seul. Les éditeurs et intégrateurs européens qui travaillent sur des solutions open source ont considérablement mûri. Il existe aujourd'hui des offres avec du support professionnel sérieux, des SLA documentés, des certifications. Le vrai piège, c'est l'attentisme. Parce que pendant qu'on attend, on renouvelle des contrats avec des acteurs américains, on enfonce des dépendances, on forme des équipes sur des outils dont on ne contrôle pas la roadmap. Et quand une rupture arrive — technique, tarifaire, géopolitique — on se retrouve sans alternative prête. La souveraineté numérique, ça ne s'improvise pas en trois mois. Ça se construit maintenant.

*Entretien réalisé en avril 2026. L'interlocuteur a souhaité conserver l'anonymat.*