Longtemps, l'open source a occupé dans le discours européen une place ambiguë : célébré dans les déclarations, marginal dans les budgets. Le paquet souveraineté du 3 juin 2026 change au moins le statut : la stratégie open source de l'Union y figure comme un des quatre piliers, au même rang que les semi-conducteurs, le cloud et l'IA. La logique est solide : les communs numériques offrent une transparence complète sur la pile technologique, réduisent l'enfermement propriétaire et permettent de mutualiser l'effort d'innovation. Face à des plateformes fermées soumises à des droits tiers, le code ouvert est la seule dépendance qu'on peut auditer, forker et héberger soi-même. Une fois les sources ou les poids obtenus, aucune décision étrangère ne peut les retirer.
Ce que juillet a montré : l'ouverture comme force…
L'incident de juillet, paradoxalement, a plaidé pour l'ouverture autant que contre elle. C'est grâce à des modèles à poids ouverts que les équipes de la victime ont pu déchiffrer les charges utiles de l'attaquant et reconstituer la chronologie — une capacité forensique qu'aucune API fermée, soumise à quotas et à conditions d'usage, n'aurait garantie au pire moment. Et c'est la culture de divulgation propre à l'écosystème ouvert qui a produit, en quelques semaines, le post-mortem technique le plus détaillé jamais publié sur un incident de ce type : chronologie horodatée, actions reconstituées, méthodes documentées. La communauté entière a appris de l'attaque. Un acteur fermé aurait publié quatre paragraphes.
… et comme surface d'attaque
Mais l'honnêteté oblige à regarder l'autre face. Une plateforme ouverte, conçue pour accélérer les contributions externes, expose structurellement davantage de surface qu'un jardin clos : dépôts publics, pipelines d'évaluation, composants tiers — c'est d'ailleurs un composant d'infrastructure tiers, exposé et vulnérable, qui a servi de porte d'entrée. L'incident est devenu une pièce centrale du débat sur la politique de l'IA open source : les partisans du contrôle y voient la preuve que la diffusion de capacités puissantes doit être restreinte ; les partisans de l'ouverture, la preuve que la défense collective ne fonctionne que par la transparence. Les deux camps ont raison sur un point : l'ouverture sans investissement de sécurisation est une promesse non financée.
La condition européenne : financer les communs
C'est ici que la stratégie européenne se jouera. L'open source ne devient un pilier de souveraineté qu'à trois conditions. Un : financer la maintenance et la sécurité des composants critiques — pas seulement l'innovation, la plomberie. Les défaillances viennent presque toujours de briques obscures maintenues par trois bénévoles. Deux : bâtir une capacité européenne d'audit et de réponse sur les communs (revue de code, SBOM systématiques, CVE traitées à la vitesse requise par le Cyber Resilience Act). Trois : que les acheteurs publics assument une préférence pour les solutions ouvertes lorsqu'elles existent, transformant le discours en carnet de commandes.
Ni illusion, ni évidenceL'open source n'est pas souverain par nature — un commun sous-financé est une dépendance comme une autre, avec un point de défaillance en moins et un orphelinat de maintenance en plus. Il est souverainisable : c'est une décision d'investissement, pas une propriété du code.
La réponse à la question du titre est donc conditionnelle. Pilier, oui — si l'Europe le traite comme une infrastructure qu'on entretient. Illusion, sûrement — si elle continue de le traiter comme une ressource gratuite qu'on consomme.