L’UE place l’open source au cœur de la souveraineté technologique européenne. Nous étions prêts.

Le chiffre qui devrait interpeller chaque DSI européen

Récemment, la Commission européenne a publié le Paquet sur la souveraineté technologique européenne. Il comprend le Chips Act 2.0, le Cloud and AI Development Act, une feuille de route stratégique pour la numérisation et l’IA dans l’énergie et, pour la première fois dans l’histoire de la politique numérique de l’UE, une stratégie européenne Open Source complète.

Le chiffre mis en avant dans la fiche d’information : 264 milliards d’euros dépensés chaque année pour des produits et services de pays tiers. C’est ce chiffre qui devrait pousser chaque DSI et responsable des achats européen à lire ce document attentivement. Pas 264 millions. 264 milliards. Par an. Principalement versés à une poignée de grands fournisseurs propriétaires de cloud et de logiciels, dont les conditions d’utilisation, la tarification, les feuilles de route produits et les politiques d’accès aux données sont décidées en conseil d’administration, sans rendre de comptes aux institutions ou aux citoyens européens.

La Présidente de la Commission, Ursula von der Leyen, l’a dit sans détour : « Nous ne pouvons pas nous permettre de dépendre d’autres pour les technologies qui font fonctionner nos hôpitaux, stabilisent nos réseaux énergétiques et sécurisent nos services. Il s’agit de protéger nos citoyens, défendre nos intérêts et faire nos propres choix. »

Ce n’est pas une déclaration de politique technologique. C’est une déclaration géopolitique. Et elle intervient à un moment où la pression géopolitique sur l’infrastructure numérique européenne est plus forte que jamais depuis le RGPD.

L’Open Source n’est plus une note de bas de page

Les précédents documents stratégiques de l’UE mentionnaient l’open source en passant. Un point dans une liste, une référence à l’écosystème Free and Open Source Software (FOSS) ici ou là. Le Paquet sur la souveraineté technologique change la donne. La stratégie européenne Open Source place l’open source au cœur de la souveraineté technologique de l’UE. Le Cloud and AI Development Act réaffirme l’engagement de la Commission à œuvrer pour un environnement numérique ouvert, collaboratif et résilient.

La Commission trace explicitement la frontière entre l’enfermement propriétaire et la vulnérabilité stratégique, considérant la concentration de l’infrastructure numérique européenne entre les mains d’un petit nombre d’acteurs propriétaires dominants non seulement comme un problème de concurrence, mais comme une vulnérabilité stratégique. C’est un changement majeur. Pendant des années, l’argument en faveur de l’open source dans les marchés publics était économique (réduction du coût total de possession) ou idéologique (biens communs numériques). Le Paquet sur la souveraineté technologique en fait un enjeu stratégique. Dépendre de logiciels propriétaires de fournisseurs que vous ne contrôlez pas freine la souveraineté numérique. C’est la position de la Commission, publiée dans un document officiel.

La fiche d’information recense également 3 millions de contributeurs open source en Europe qui créent des solutions numériques. Voilà la force de travail. La stratégie, les contributeurs et la volonté politique sont désormais alignés.

Ce que « souveraineté » exige réellement

Je veux être précis ici, car « souveraineté numérique » est devenue une étiquette que chaque fournisseur de cloud colle sur son datacenter de Francfort pour se donner bonne conscience.

La véritable souveraineté repose sur quatre exigences. Le Paquet sur la souveraineté technologique, à son crédit, les adresse toutes.

  1. Vous devez pouvoir exécuter le logiciel vous-même.
    Un « cloud souverain » dont le code reste propriétaire, où le fournisseur peut résilier votre licence, modifier les conditions ou accéder à vos données à sa guise, n’est pas souverain. C’est une location déguisée en argument marketing. Peu importe le siège du fournisseur. Un verrou propriétaire dans un datacenter à Francfort reste un verrou. L’open source avec capacité d’auto-hébergement est la base. Le Cloud and AI Development Act introduit un cadre d’évaluation de la souveraineté précisément parce que la Commission a compris cette nuance.
  2. Vous devez comprendre ce que contient le logiciel.
    La sécurité de la supply chain n’est pas un mot à la mode. Il s’agit de savoir quel code tiers tourne dans votre infrastructure, d’où il provient et s’il a été audité. Les SBOM (Software Bill of Materials), les builds signés et les politiques de divulgation des vulnérabilités sont l’expression concrète de la souveraineté logicielle.
  3. Vous devez disposer d’une gouvernance vérifiable.
    Un fournisseur qui affirme « nous soutenons l’open source » sans charte de gouvernance publiée, sans comité consultatif communautaire, sans processus défini de prise de décision, fait une promesse marketing, pas un engagement structurel. La stratégie Open Source y répond en appelant à des capacités organisationnelles et de gouvernance qui pérennisent les projets open source.
  4. Vous devez avoir une clarté juridique.
    Les licences open source ne se valent pas toutes. La licence Apache 2.0 est permissive, sûre pour les achats publics et compatible avec la plupart des exigences des entreprises et du secteur public européen. L’AGPL est une licence copyleft, ce qui signifie que tout logiciel l’intégrant peut devoir être publié sous les mêmes termes (souvent un frein dans les marchés publics propriétaires). Comprendre votre pile de licences fait partie de l’hygiène de la commande publique souveraine.

Ce que nous avons construit avant l’arrivée de la politique

ownCloud a été fondé en 2010 en Allemagne. Il est déployé dans des écoles européennes, des agences gouvernementales, des instituts de recherche et des clouds publics depuis seize ans. Des millions d’utilisateurs font confiance à oCIS.

Le 5 mai, un mois avant la publication de ce paquet, nous avons lancé l’Open Source Program Office (OSPO) de Kiteworks. Tous les éléments de notre lancement OSPO correspondent exactement à ce que le Paquet sur la souveraineté technologique réclame désormais au niveau politique :

Apache 2.0 par défaut.
oCIS utilise la licence Apache 2.0. Les nouveaux dépôts sont par défaut sous Apache 2.0. Aucun risque copyleft dans vos achats. Pas d’ambiguïté de licence utilisée comme levier commercial. Nous l’avons écrit noir sur blanc dans notre manifeste.

Abandon du CLA, adoption du DCO.
Les contributeurs conservent leurs droits d’auteur. C’est essentiel pour la souveraineté, car cela signifie qu’aucun fournisseur unique ne possède l’ensemble du code. Le code appartient à ceux qui l’ont écrit, sous licence Apache 2.0 ouverte à tous.

Charte de gouvernance publiée.
Ce n’est pas une déclaration d’intention. C’est un document avec des rôles définis, des processus de décision, la résolution des conflits, un calendrier pour le Community Advisory Board et une période de consultation publique de 30 jours pour toute modification de politique. Il précise explicitement que Kiteworks pilote la feuille de route, et détaille les mécanismes communautaires permettant d’influencer cette orientation. Voilà l’engagement structurel que la stratégie Open Source attend.

SBOM, builds signés, VDP.
La sécurité de la supply chain n’est pas théorique pour nous. Nous avons publié une politique de divulgation des vulnérabilités, lancé un programme de bug bounty sur YesWeHack, générons des SBOM à chaque version, signons nos images de conteneur et publions des historiques de gestion de correctifs. Plus tôt cette année, nous avons géré un incident de compromission de la supply chain (CVE-2026-33634, Trivy) avec un rapport public, des notifications aux clients concernés dans leur langue et des images mises à jour pendant la fenêtre d’exposition. Voilà la souveraineté sous pression, pas juste dans un argumentaire marketing.

12 documents publiés.
Vision, mission, manifeste, charte de gouvernance, politique de contribution IA, politique de divulgation de sécurité, guide du contributeur, retours d’expérience, code de conduite, engagement, responsabilisation, vision produit (plus d’informations sur notre page OSPO). Tous nos engagements sont écrits et vérifiables publiquement.

Pourquoi l’OSPO est la bonne structure

Le Paquet sur la souveraineté technologique aborde l’open source au niveau politique. Les OSPO (Open Source Program Offices) sont la structure organisationnelle qui permet de concrétiser la politique dans les entreprises et les institutions publiques.

La stratégie Open Source de la Commission est l’avancée la plus significative de l’Europe pour bâtir un avenir numérique souverain et résilient grâce à l’open source. Mais une stratégie sans mise en œuvre reste un document. L’OSPO de Kiteworks existe pour rendre l’implémentation ownCloud concrète : politique de sécurité publiée, parcours contributeur défini, gouvernance communautaire, modèle de support commercial qui garantit la viabilité financière du produit open source sans compromettre son ouverture.

Les quatre piliers de notre modèle commercial répondent directement aux besoins des clients du secteur public européen pour déployer l’open source de façon responsable :

  1. Support et SLA.
    Le code est gratuit. Mais avoir quelqu’un qui répond à 2h du matin quand votre Virtual Data Room tombe en panne, ça ne l’est pas. Les niveaux de support offrent aux organisations publiques une réponse contractuelle pour les infrastructures critiques.
  2. Builds durcis et SBOM.
    L’auditeur ne s’intéresse pas au lien GitHub. Il veut un SBOM signé, un historique de gestion des correctifs et une attestation du fournisseur. Nous fournissons les trois.
  3. Documentation de conformité.
    Les organisations publiques en Allemagne et dans toute l’UE opèrent sous ces cadres. Nos offres d’abonnement Kiteworks incluent la cartographie de conformité, le support d’audit et un contact conformité dédié pour rendre ownCloud auditable dans les contextes réglementés.
  4. Protection juridique.
    Apache 2.0 est permissive. Nos abonnements support ajoutent une indemnisation propriété intellectuelle pour les organisations qui ont besoin d’un fournisseur qui s’engage sur la licence.

Le chiffre qui compte

264 milliards d’euros. Par an. Versés à des fournisseurs dont les feuilles de route, la tarification et les conditions ne peuvent pas être réellement influencées par les organisations européennes.

Le Paquet sur la souveraineté technologique ne fera pas baisser ce chiffre du jour au lendemain. Les processus législatifs prennent du temps. Les cycles d’achat sont longs. Les habitudes institutionnelles sont tenaces.

Mais la direction est donnée. L’UE veut renforcer la capacité européenne dans les semi-conducteurs, l’IA, le cloud et l’open source. La stratégie Open Source, les exigences de souveraineté du Cloud and AI Development Act, le mandat open source dans le secteur public : voilà les conditions structurelles pour que des alternatives ouvertes, gouvernées et auditables deviennent la norme.

Le problème n’a jamais été le siège du fournisseur. La vraie question, c’est : pouvez-vous auditer le code, le forker si besoin, vérifier la supply chain et l’exécuter sur votre propre infrastructure, sous votre propre cadre juridique ? Le verrou propriétaire échoue à ces quatre tests. L’open source, bien fait, les réussit tous.

ownCloud incarne cette alternative depuis 2010. L’OSPO rend les engagements de gouvernance et de communauté structurels, et non plus verbaux. Et le Paquet sur la souveraineté technologique, publié récemment, confirme que ce que nous construisons correspond exactement à ce qu’exige désormais la politique numérique européenne.

Ce n’est pas un hasard du calendrier. Le problème est visible depuis des années. Nous travaillons sur la solution.

Lire la fiche d’information sur la souveraineté technologique de l’UE : ec.europa.eu/commission/presscorner

ownCloud OSPO : kiteworks.com/opensource · owncloud.com/blogs

Essayez oCIS : github.com/owncloud/ocis · owncloud.dev

David Walter est VP of the Open Source Program Office chez Kiteworks, où il dirige la gouvernance open source, la gestion des licences et l’engagement communautaire pour ownCloud. Il évolue dans l’écosystème ownCloud depuis 2014.

Lancez-vous.

Il est facile de commencer à garantir la conformité réglementaire et à gérer efficacement les risques avec Kiteworks. Rejoignez les milliers d’organisations qui ont confiance dans la manière dont elles échangent des données privées entre personnes, machines et systèmes. Commencez dès aujourd’hui.

Table of Content
Partagez
Tweetez
Partagez
Explore Kiteworks