Souverain

Libre, à condition d’en garder la maîtrise

Choisir l’open source permet-il réellement de sortir des dépendances numériques ? Derrière la liberté offerte par les licences peuvent subsister des contraintes liées au support, aux compétences, à l’interopérabilité ou aux coûts de migration. À travers les regards de Florian Caringi et de Cédric Ravalec, une question est parfois négligée : comment adopter l’open source sans recréer, ailleurs, l’enfermement que l’on cherchait précisément à quitter ?

Il y a près de deux mois, grâce à Genma, j’assistais à OW2con, la conférence annuelle organisée par OW2 autour des logiciels libres et open source. J’ai notamment pu participer à la présentation de Florian Caringi, directeur adjoint chargé des données et de l’open source au sein du groupe BPCE (Banque Populaire et Caisse d’Épargne).

Le sujet n’était évidemment pas de nous expliquer comment fonctionne une banque. Non pas que la question soit inintéressante, mais ce n’est pas vraiment le genre de conférence qu’organise OW2.

Florian Caringi était venu présenter la manière dont il avait contribué à mettre en place, au sein du groupe BPCE, une véritable organisation consacrée à l’open source : des méthodes, des règles, des bonnes pratiques et une gouvernance permettant de mieux gérer son utilisation dans l’entreprise. Autrement dit, il expliquait comment l’open source pouvait devenir une brique solide de l’organisation, et non plus seulement une succession d’initiatives techniques dispersées.

Sa présentation m’avait particulièrement plu, car c’était l’une des premières fois que je voyais une organisation de cette nature réellement mise en œuvre sur le terrain. Et pas dans la plus simple des structures : nous parlons tout de même d’un grand groupe bancaire.

Comme je l’expliquais dans mon article consacré à OW2con 2026 et à l’open source européen, j’avais pu échanger avec Florian à la suite de sa présentation. J’avais apprécié son accessibilité, sa manière de transmettre son expérience et une forme d’humilité devenue, me semble-t-il, trop rare.

Nous nous sommes revus quelques semaines plus tard, lors de la soirée À la French.
Cédric Ravalec, directeur opérationnel chez Open Source Experts, était également présent.

Bref, pour moi, il y avait là du lourd !

Au regard de mon expérience personnelle autour de la souveraineté numérique et de l’open source, il était assez évident que je ne faisais pas le poids face à leur expérience professionnelle. Mais là n’était finalement pas la question. Florian et Cédric faisaient preuve d’une réelle disponibilité et d’une grande générosité dans notre échange. Ils partageaient leurs connaissances, répondaient à mes questions et acceptaient volontiers de discuter avec quelqu’un qui, comme moi, n’est pas du tout un professionnel de l’informatique et encore moins du sérail.

Au fil de la conversation, nous sommes arrivés à une conclusion qui peut sembler évidente, mais qui mérite pourtant d’être rappelée : lorsqu’on parle de souveraineté numérique et d’open source, il faut se garder de tomber dans l’idéologie ou dans l’illusion d’un monde parfait, entièrement gratuit et dépourvu de zones d’ombre.

L’open source apporte des libertés essentielles. Mais il ne fait pas disparaître pour autant les intérêts économiques, les rapports de force, les contraintes techniques ni les risques de dépendance.

Florian et Cédric m’ont alors mis la puce à l’oreille sur un sujet que je connaissais peu, voire pas du tout : la situation dans laquelle une organisation choisit une distribution Linux, puis découvre que les conditions de support rendent très difficile sa sortie de cet environnement.

À vrai dire, je ne savais même pas que le sujet existait sous cette forme.

Dans mon esprit, une distribution Linux et, plus largement, une solution open source étaient précisément censées permettre d’échapper à l’enfermement que l’on reproche régulièrement aux logiciels propriétaires. Puisque le code est ouvert, il devrait être possible de changer de prestataire, de reprendre la solution, de la faire évoluer ou de migrer vers une autre. En théorie, oui.

Mais ils m’ont fait prendre conscience qu’entre la liberté prévue par la licence et celle réellement exercée par une organisation, il peut exister un écart considérable.

Lorsqu’une entreprise décide de s’appuyer sur l’open source pour administrer une partie importante de son infrastructure, et qu’elle souhaite réellement renforcer sa souveraineté sans reproduire les erreurs commises avec certaines solutions propriétaires, elle doit regarder de fond en comble ce que ce choix implique.

Elle doit notamment étudier les frais de migration d’un système vers un autre ; dans ce cas, le passage d’un système propriétaire à un système dit ouvert, mais aussi les conditions du support technique.

Elle doit également vérifier si son organisation lui permet de recourir à ce que les professionnels appellent le dual sourcing, ou « double approvisionnement » en français.
Cette stratégie, issue à l’origine de la gestion des chaînes d’approvisionnement, consiste à pouvoir s’appuyer sur deux fournisseurs différents pour un même composant, un même matériau ou un même service. Appliquée à l’informatique, elle permet d’éviter qu’un fournisseur devienne le seul acteur capable de maintenir, de faire évoluer ou de supporter une solution pourtant ouverte.

Il faut aussi prendre en considération le footprint, c’est-à-dire l’empreinte globale prise par un éditeur au sein d’une organisation. Cette empreinte peut être mesurée par le nombre de produits utilisés, de serveurs concernés, de projets déployés, d’utilisateurs, de souscriptions ou d’abonnements.

Plus cette empreinte grandit, plus le changement peut devenir complexe, coûteux et risqué.

Et puis il y a l’interopérabilité, c’est-à-dire la capacité de différents logiciels, services et systèmes à fonctionner ensemble sans dépendre d’un environnement unique.

Nous avons donc échangé autour de ces différents sujets. C’est à ce moment-là qu’est apparue, au cours de la discussion, la comparaison entre les écosystèmes de Red Hat et de SUSE. Non pas pour débattre des différences techniques entre les deux distributions ou pour déterminer laquelle serait la meilleure, mais pour nous intéresser à leurs modèles d’accompagnement et de support, notamment autour d’OpenShift chez Red Hat et de Rancher Prime chez SUSE.

L’idée n’était absolument pas d’affirmer que l’un serait meilleur que l’autre.

Ce n’est pas l’objet de cette réflexion.

L’enjeu était plutôt de comprendre comment deux acteurs de l’open source pouvaient proposer des approches différentes et, surtout, comment le support, les certifications, les compétences disponibles, les outils complémentaires et l’ensemble des services qui entourent une technologie pouvaient influencer la capacité d’une organisation à changer de fournisseur.

Car même lorsqu’un projet repose sur des logiciels open source, il est possible de retomber dans une forme de dépendance.

Dans ce cas, la dépendance n’est pas juridique. Personne ne vous interdit formellement de partir et la licence du logiciel peut parfaitement vous en donner le droit. Elle peut en revanche devenir opérationnelle : la sortie reste théoriquement possible, mais elle devient tellement difficile, coûteuse ou risquée que l’organisation ne peut plus raisonnablement l’envisager.

L’idée a commencé à germer à la suite de cette conversation. Elle a continué à mûrir au fil des semaines. Puis, dans le rapport de la commission d’enquête parlementaire sur nos vulnérabilités et nos dépendances numériques, un chiffre m’a particulièrement interpellé : celui des dépenses publiques consacrées aux logiciels :

Près de 30 millions d’euros de dépenses étaient associés à IBM et à Red Hat et sans oublier que Red Hat est passé sous le contrôle d’IBM en 2019.

Sur les 268 millions d’euros de dépenses bénéficiant à des acteurs extra-européens, IBM et Red Hat représentaient ainsi un peu plus de 11 %.

Autrement dit, un peu plus d’un euro sur dix dépensé auprès d’acteurs extra-européens revenait à ces deux entreprises de l’IT.

Ce chiffre ne permet évidemment pas, à lui seul, de conclure que ces dépenses seraient injustifiées, ni que Red Hat constituerait nécessairement un mauvais choix. Mais il permet de mesurer l’importance qu’un acteur issu de l’open source peut prendre au sein des systèmes informatiques publics.

Il rappelle également une réalité que l’on oublie parfois : choisir une technologie ouverte ne signifie pas choisir une technologie sans éditeur, sans modèle économique, sans prestations de support ou sans risque de concentration.

J’ai donc eu le privilège de pouvoir retrouver Florian et Cédric lors d’un entretien en visioconférence afin de comprendre et d’en apprendre beaucoup plus.

Contexte

La question était de savoir comment une organisation pouvait adopter l’open source sans recréer les dépendances dont elle cherchait précisément à se libérer, comment distinguer un support indispensable d’un support qui finit par devenir un verrou et, surtout, quelles interrogations une entreprise ou une administration devrait se poser avant de faire un choix qui l’engagera parfois pour de nombreuses années.

Car adopter de l’open source ne suffit pas toujours à garantir sa liberté.

Encore faut-il savoir comment la préserver.

Florian Caringi, de la data à la gouvernance de l’open source

Pour comprendre le regard que Florian Caringi porte sur l’open source, il faut d’abord s’intéresser à son parcours. Ingénieur diplômé de Télécom Bretagne, devenue IMT Atlantique (après sa fusion avec l’École nationale supérieure des mines de Nantes et de Télécom Bretagne), il a commencé sa carrière dans l’univers de la banque et de la finance. Il a notamment occupé plusieurs fonctions au sein de la banque de financement et d’investissement de Natixis, où il travaillait déjà sur les données et leurs usages.
Dès 2019, il était ainsi présenté comme leader Big Data de Natixis lors d’une intervention consacrée à l’utilisation de la science des données dans les activités bancaires.

Son parcours l’a ensuite conduit à prendre la responsabilité d’une équipe composée d’ingénieurs et d’architectes de données au sein de l’entité transverse Tech Expertise & Solutions du groupe BPCE. Sa mission ne consiste pas seulement à déployer des technologies : elle vise aussi à accélérer les projets liés aux données, à construire et faire évoluer les plateformes du groupe, puis à accompagner leur utilisation dans une organisation particulièrement vaste et décentralisée. Il occupe aujourd’hui la fonction de directeur adjoint chargé des données et de l’open source au sein du groupe BPCE.

Cette double responsabilité est importante. Florian Caringi ne regarde pas l’open source uniquement comme un ensemble de logiciels ou de licences. Il l’aborde depuis le terrain, au sein d’un grand groupe bancaire où les choix techniques doivent répondre à des exigences élevées de sécurité, de continuité, d’industrialisation et de maîtrise des risques. Son expertise se situe précisément à la rencontre de plusieurs mondes : l’architecture des données, l’intelligence artificielle, les infrastructures informatiques et la gouvernance de l’open source. Ses interventions publiques portent d’ailleurs régulièrement sur la manière d’arbitrer entre solutions ouvertes, services en ligne et modèles propriétaires.

Mais son engagement dépasse le cadre de BPCE. Florian Caringi est vice-président du TOSIT : The Open Source I Trust, une association qui réunit de grandes entreprises et des administrations souhaitant mutualiser leurs expériences, leurs besoins et certains développements open source. Il y représente notamment le groupe BPCE et participe à des travaux portant sur les plateformes de données, l’intelligence artificielle, les standards ouverts et la maîtrise des dépendances technologiques.

Florian a également mis son expérience au service du Comité d’organisation des Jeux olympiques et paralympiques de Paris. De mars à septembre 2024, il a occupé la fonction de responsable adjoint des infrastructures technologiques des cérémonies d’ouverture. Il a participé à la coordination et au pilotage des infrastructures technologiques et de télécommunications nécessaires à la cérémonie olympique organisée sur la Seine, puis à la cérémonie paralympique organisée place de la Concorde. Une mission particulièrement exigeante, au croisement de la technologie, de la coordination opérationnelle et de la gestion d’un événement suivi dans le monde entier.

En mars 2026, il a également été élu président d’OW2, communauté internationale consacrée au développement et à la promotion de logiciels open source, dont le siège est en France. Cette responsabilité le place au contact d’un écosystème beaucoup plus large, composé de développeurs, d’entreprises, d’administrations, d’établissements de recherche, d’associations et d’éditeurs. Elle témoigne aussi d’un engagement qui ne se limite pas à utiliser l’open source : il s’agit de contribuer à organiser, à faire vivre et à renforcer les communautés qui le rendent possible.

Son parcours comporte enfin une dimension de transmission. En parallèle de ses responsabilités professionnelles et associatives, Florian Caringi enseigne à l’ESCP et à l’ESG. Depuis 2021, il met également bénévolement ses compétences au service du Paris FC, en contribuant notamment à l’architecture applicative et aux sujets liés aux données du club. Ces engagements sont cohérents avec une conviction qu’il exprime régulièrement : les compétences, les expériences et les technologies prennent davantage de valeur lorsqu’elles sont partagées.

C’est sans doute ce qui caractérise le mieux son profil : Florian Caringi n’est pas seulement un spécialiste de la donnée devenu responsable de l’open source dans un grand groupe.
C’est un praticien qui cherche à relier les contraintes très concrètes de l’entreprise aux principes de coopération, d’ouverture et de mutualisation portés par les communautés du logiciel libre.

Et c’est précisément parce qu’il connaît à la fois les promesses de l’open source et les conditions réelles de son déploiement qu’il peut en parler sans naïveté. Son discours n’est ni celui d’un opposant aux éditeurs ni celui d’un défenseur d’un monde où tout devrait être gratuit. Il nous invite plutôt à regarder ce qui se joue autour du code : le support, les compétences, la gouvernance, le modèle économique et, surtout, la capacité à conserver la maîtrise de ses choix.

Préparer la sortie avant même d’entrer

Lors de notre entretien, Florian a beaucoup insisté sur un point qui traverse l’ensemble de son raisonnement : le caractère open source d’une technologie ne suffit pas, à lui seul, à garantir la liberté d’une organisation.

Pour conserver la maîtrise de son système d’information, la direction doit penser bien au-delà de la licence. Elle doit regarder la manière dont la solution est assemblée, déployée, maintenue et intégrée au reste de son infrastructure. Elle doit surtout se demander, dès le début du projet, dans quelles conditions elle pourra un jour la faire évoluer, changer de prestataire ou la remplacer.

Le principe de l’appliance

Florian accorde notamment beaucoup d’importance au principe de l’appliance. Dans le vocabulaire informatique, cela désigne une solution conçue et préparée pour remplir une fonction précise. Elle peut prendre la forme d’un équipement réunissant le matériel et les logiciels nécessaires, mais aussi celle d’une machine virtuelle préconfigurée comprenant le système d’exploitation, les composants techniques et l’application. L’ensemble est fourni comme un produit cohérent, prêt à être déployé et, généralement, pris en charge par un même support. IBM définit ainsi une appliance comme une offre unique associant des composants matériels et logiciels pour assurer une fonction déterminée ; une virtual appliance rassemble, quant à elle, le système d’exploitation, les logiciels intermédiaires et les applications au sein d’un même ensemble préconfiguré.

L’intérêt est notamment de réduire la complexité du déploiement et de clarifier la responsabilité du support. Lorsqu’un logiciel, son système d’exploitation et son matériel proviennent de fournisseurs différents, chacun peut être tenté, lorsqu’un problème survient, d’en attribuer la responsabilité à l’autre. Avec une appliance, l’organisation dispose en principe d’un interlocuteur capable de prendre en charge l’ensemble de la solution. C’est précisément l’un des avantages mis en avant dans la discussion du site Developpez.net que Florian m’avait indiquée.

Cette « simplicité » ne doit cependant pas être confondue avec l’indépendance. Une solution parfaitement intégrée peut être très facile à installer et à maintenir, tout en devenant difficile à remplacer. L’appliance doit donc être étudiée avec les mêmes précautions que le reste de l’infrastructure :

• Les interfaces sont-elles documentées ?
• Les données peuvent-elles être récupérées facilement ?
• Peut-elle fonctionner sur plusieurs environnements ?
• Un autre prestataire peut-il en assurer le support ?
• Les composants qui la constituent reposent-ils sur des standards ouverts ?

Les standards ouverts comme condition de la mobilité

La mise en place de standards ouverts par les DSI est justement une condition essentielle pour faciliter les futures stratégies de migration et renforcer l’interopérabilité.

Un standard ouvert permet à plusieurs logiciels, plateformes ou fournisseurs de s’appuyer sur des règles communes, publiquement documentées et utilisables par différents acteurs. L’organisation ne construit alors plus son système d’information autour des seuls choix techniques d’un éditeur. Elle conserve davantage de possibilités pour faire communiquer plusieurs solutions, remplacer un composant ou transférer ses données.

Cela ne signifie pas qu’une migration devient simple ou gratuite. Mais plus les formats, les interfaces et les protocoles sont ouverts et partagés, moins l’organisation dépend d’un savoir-faire détenu par un seul fournisseur.

L’interopérabilité ne doit donc pas être considérée comme une étape abstraite que l’on ajouterait à la fin d’un projet. Elle doit être pensée dès la conception de l’architecture. Une DSI qui impose des standards ouverts prépare en réalité ses possibilités futures : elle se donne davantage de latitude pour intégrer de nouvelles solutions, faire travailler plusieurs prestataires et éviter qu’un composant ou un logiciel ne devienne indissociable du reste du système d’information.

Surveiller le footprint

Florian est également revenu à plusieurs reprises sur le footprint, c’est-à-dire l’empreinte qu’un éditeur, une technologie ou un écosystème prend progressivement dans une organisation.

Cette empreinte ne se limite pas au nombre de licences achetées. Elle peut correspondre au nombre de serveurs concernés, de produits utilisés, de projets déployés, de souscriptions, d’utilisateurs dépendants de la solution ou encore d’applications développées autour de ses technologies.

Pris séparément, chacun de ces choix peut sembler raisonnable. Mais leur accumulation peut progressivement donner à un fournisseur une place centrale dans le système d’information.

Une première solution est installée pour répondre à un besoin précis. Puis viennent les outils de supervision, les bases de données, les mécanismes de sécurité, les services cloud, les formations, les certifications et les applications développées en interne. Au fil du temps, les équipes acquièrent des compétences très spécialisées dans cet environnement et les processus de l’organisation commencent eux aussi à en dépendre.

Le footprint permet donc de regarder la dépendance dans son ensemble. Il ne s’agit plus seulement de savoir si un logiciel peut être remplacé, mais de mesurer tout ce qui s’est progressivement construit autour de lui.

Cette empreinte doit être suivie par les DSI comme un véritable indicateur stratégique.
Plus elle s’étend, plus il devient nécessaire de vérifier que l’organisation conserve des solutions de remplacement et une capacité réelle de négociation.

Ne pas dépendre d’un seul fournisseur grâce au dual sourcing

Le second principe sur lequel Florian a beaucoup insisté est celui du dual sourcing, ou double approvisionnement en français.

Dans le domaine informatique, cette stratégie consiste à ne pas confier un composant, une technologie ou un service critique à un fournisseur unique. L’organisation cherche à maintenir au moins deux sources possibles de compétences, de prestations ou de support.

Dans un environnement open source, cette possibilité devrait théoriquement constituer l’un des grands avantages du modèle. Le code étant accessible, plusieurs entreprises peuvent intervenir sur une même technologie. Une organisation peut donc choisir un éditeur, un intégrateur ou une société de support sans abandonner définitivement la possibilité d’en solliciter un autre.

Mais cette liberté théorique doit être organisée concrètement.

Si toutes les compétences internes ont été formées aux outils spécifiques d’un seul fournisseur, si les procédures dépendent de ses propres interfaces et si les contrats ont été construits de manière à lui réserver l’essentiel du support, l’existence du code source ne suffira pas à rendre le changement facile.

Le dual sourcing consiste donc à entretenir volontairement plusieurs options. Il peut s’agir de travailler avec deux prestataires, de préserver des compétences en interne, de vérifier qu’un second acteur serait capable de reprendre le support ou encore d’éviter que les développements réalisés autour de la solution ne reposent exclusivement sur des extensions propres au fournisseur principal.

L’objectif n’est pas nécessairement de diviser chaque contrat entre deux entreprises ni de mettre constamment les fournisseurs en concurrence. Il s’agit de s’assurer qu’une alternative crédible existe et qu’elle pourra réellement être mobilisée en cas de besoin.

Pour Florian, les concepts de footprint et de dual sourcing sont ainsi étroitement liés : Le premier permet de mesurer l’ampleur prise par un acteur dans l’organisation. Le second préserve la possibilité du choix lorsque cette empreinte devient (trop) importante.

Ces deux notions conduisent directement à celles sur lesquelles il a également beaucoup insisté : le lock-in et le coût de sortie.

Le lock-in (ou vendor lock-in : verrouillage fournisseur)

Le lock-in désigne une situation dans laquelle une organisation devient tellement dépendante d’un logiciel, d’un éditeur ou d’un fournisseur cloud, qu’il devient difficile de le remplacer.

Cette dépendance peut venir de :

• formats de données propriétaires ;
• applications conçues autour de technologies spécifiques ;
• interfaces incompatibles avec les solutions concurrentes ;
• compétences internes concentrées sur un seul environnement ;
• contrats ou licences complexes ;
• nombreuses intégrations avec le reste du système d’information.

Le client n’est pas juridiquement obligé de rester. Il peut théoriquement partir, mais le changement devient trop difficile, trop risqué ou trop coûteux.

Le coût de sortie

Il représente tout ce qu’une organisation doit supporter pour quitter une solution ou un fournisseur. Il ne s’agit pas seulement du prix d’un nouveau logiciel.

Il faut prendre également en considération :

• la récupération et la migration des données ;
• la reconstruction des applications et des interfaces ;
• la formation des équipes ;
• le recours possible à des consultants ou intégrateurs ;
• les interruptions de service ;
• les pénalités contractuelles (dans certains cas) ;
• les risques de perte de données ou de fonctionnalités ;
• le temps consacré au projet de migration.

Ce coût peut donc être financier, technique, humain, contractuel et opérationnel.

La différence entre les deux notions

Le lock-in est la situation de dépendance.
Le coût de sortie mesure la difficulté réelle pour en sortir.

Plus le coût de sortie est élevé, plus le verrouillage est fort.

Une solution peut ainsi être peu coûteuse au départ, mais devenir très chère à abandonner après plusieurs années, lorsque les données, les applications, les compétences et les processus de l’organisation se sont construits autour d’elle.

Exemple concret

Une entreprise utilise pendant dix ans les services cloud propriétaires d’un fournisseur.
Ses applications dépendent de ses bases de données, de ses outils de sécurité, de ses mécanismes d’intelligence artificielle et de ses interfaces techniques.

Changer de fournisseur suppose alors de :

• transférer plusieurs pétaoctets de données ;
• réécrire une partie des applications ;
• remplacer les outils propriétaires ;
• former les équipes ;
• maintenir temporairement les deux environnements.

L’entreprise reste donc chez son fournisseur, non parce qu’elle en est totalement satisfaite, mais parce que le prix et le risque du départ sont devenus supérieurs aux inconvénients de rester.

Le véritable pouvoir d’un fournisseur ne tient pas seulement à la qualité de ses produits, mais au coût qu’il impose pour les quitter. Plus les données, les applications et les compétences d’une organisation dépendent de son environnement, plus le coût de sortie augmente et plus le verrouillage se renforce.

Il est également possible dans cette situation, de parler de réversibilité : une solution réellement réversible permet de récupérer ses données, de transférer ses applications et de changer de fournisseur dans des conditions maîtrisées. Le coût de sortie constitue donc, pour une DSI, un indicateur concret du niveau de dépendance numérique.

Le regard de Florian conduit finalement à renverser la manière dont une organisation évalue ses choix informatiques. Il ne suffit pas de se demander combien coûtera l’entrée dans une solution, quelles fonctions elle propose ou avec quelle rapidité elle pourra être déployée.

Il faut aussi se demander combien coûtera sa sortie.

Une architecture réellement maîtrisée n’est pas celle que l’on ne quittera jamais. C’est celle que l’on pourra quitter sans mettre en péril l’activité de l’organisation.

Dans cette perspective, l’open source n’est pas une garantie automatique contre l’enfermement. Il constitue plutôt un ensemble de libertés qu’il faut rendre opérationnelles grâce aux standards ouverts, à l’interopérabilité, à la maîtrise du footprint, au dual sourcing et à une véritable stratégie de réversibilité.

La liberté ne dépend donc pas seulement de l’accès au code source. Elle dépend de la capacité réelle à exercer le choix que cet accès est censé permettre.

Cédric Ravalec, vingt-cinq ans au cœur de l’open source

Le parcours de Cédric Ravalec se confond en grande partie avec l’histoire de l’open source professionnel en France. Il travaille dans cet univers depuis plus de vingt-cinq ans, près avoir commencé sa carrière au moment où l’open source professionnel se développait avec l’essor d’Internet. En effet, la grande majorité des infrastructures d’Internet sont basées sur l’open source, qui s’est progressivement installé dans les organisations à mesure que le web s’étendait.

Ses premiers pas professionnels se font chez Alcôve, l’une des toutes premières SSII (ou ESN : Entreprises de Services du Numérique) spécialisées dans les logiciels libres.
Il occupe ensuite différentes responsabilités commerciales et managériales chez OpenTrust (rachetée par Atos en 2019) et Linagora.

Cette trajectoire lui a permis d’observer l’évolution de l’open source depuis une période où son adoption dans les entreprises restait encore marginale, parfois même dissimulée dans les infrastructures, jusqu’à son rôle désormais central dans le cloud, les systèmes embarqués, les applications mobiles et les systèmes d’information des grandes organisations.

En 2011, après une douzaine d’années passées dans le conseil et les services informatiques open source, Cédric Ravalec reconnaît dans Android le même phénomène d’émergence technologique majeure qu’il avait observé avec l’arrivée de Linux à l’époque d’Internet.
C’est lors d’une réunion du Paris Android User Group qu’il se convainc du potentiel du système d’exploitation mobile. Il s’y implique ensuite très fortement.

Cette même année, il décide de se lancer dans l’aventure entrepreneuriale et cofonde Genymobile, une des premières sociétés de services dédiée à Android. Cédric aura vu juste, car Android équipe aujourd’hui plus de 4 milliards de smartphones dans le monde.
En 2013, il reçoit le prix de l’innovation d’avenir lors des Prix EY de l’Entrepreneur.
Son entreprise sera rachetée par Shadow en 2023.

Son intérêt pour les systèmes mobiles ouverts se poursuit notamment autour de Firefox OS. Cédric y voit un enjeu commercial majeur : rendre accessible le smartphone à des milliards d’individus dans les pays en voie de développement, en permettant le passage du téléphone à touches vers le smartphone. Cofondateur, avec Loïc Cuguen, de Phoxygen, il participe activement à l’animation de la communauté française de Firefox OS, en organisant des rencontres régulières consacrées au système d’exploitation mobile de Mozilla. Leur engagement est publiquement salué par Mozilla en 2015.

Il développe ensuite une expertise particulière dans les domaines des systèmes embarqués, de l’Internet des objets et des infrastructures ouvertes. Chez Smile, il occupe notamment des responsabilités autour de l’offre « Embarqué et IoT », puis du Cloud. Cédric contribue également au livre blanc Android pour l’embarqué, principalement rédigé par Pierre Ficheux, alors directeur technique de Smile-ECS. Il en signe le dernier chapitre, consacré aux marchés actuels et futurs d’Android dans l’industrie et l’Internet des objets.

Son expertise ne s’arrête pas là. Elle porte aussi sur une question décisive pour les entreprises et les administrations : comment rendre ces technologies réellement exploitables, faciles à maintenir et correctement supportées dans la durée ?
Dans le monde propriétaire, l’éditeur reste généralement l’interlocuteur naturel en cas de problème. Avec l’open source, le paysage est plus éclaté : une communauté, plusieurs sociétés de services, des contributeurs indépendants ou différents intégrateurs peuvent intervenir autour d’un même projet. Cette diversité élargit les possibilités, mais elle oblige aussi à identifier les bons partenaires et à organiser le support pour éviter que la liberté de choisir ne se transforme en incertitude.

En cette même année, Cédric prend la direction d’Open Source Experts : une structure cofondée par cinq acteurs de référence dans l’open source : FactorFX, Worteks, Arawa, Bluemind et Inno3 et créée dans le but de fédérer cet écosystème français, d’aider les entreprises à trouver les compétences nécessaires pour maintenir leurs solutions ouvertes et d’organiser un support technique adapté à cet environnement fragmenté.

La liberté de choisir existe, mais encore faut-il savoir vers qui se tourner et comment garantir la continuité du support.

Cédric participe régulièrement aux événements de l’écosystème open source français.
Son expertise est également reconnue par l’écosystème professionnel : en 2023, il participe à la direction du programme d’Open Source Experience en tant que vice-président de la thématique consacrée aux systèmes embarqués, à l’IoT, à l’Open Hardware et à l’industrie.

Le recul de l’expérience, sans perdre la passion

Son parcours dessine ainsi un profil à la croisée de plusieurs mondes : les technologies ouvertes, le développement commercial, l’accompagnement des organisations, le support professionnel et l’animation des communautés. Il connaît l’open source non seulement comme utilisateur ou observateur, mais comme une activité économique qu’il faut structurer pour qu’elle puisse répondre aux exigences des entreprises et des administrations.

Cette expérience lui permet de distinguer ce que l’open source promet de ce qu’il exige réellement sur le terrain. Après avoir accompagné l’évolution pendant plus de vingt-cinq ans, il en connaît les possibilités, mais aussi les fragilités : la dispersion des compétences, le manque de support sur certains projets, la difficulté à identifier les bons interlocuteurs et le risque de voir une technologie ouverte devenir malgré tout une nouvelle source de dépendance.

Entre la publication d’un code source et son utilisation durable dans une organisation, il existe tout un écosystème à construire : des compétences, des entreprises, des communautés, des contrats, du support et une véritable stratégie industrielle.

Le regard de Cédric sur ces questions est donc celui d’un professionnel qui a traversé plusieurs périodes de l’open source. Cette ancienneté ne fait pas de lui un observateur tourné vers le passé. Elle lui donne surtout du recul.

Il rejoint Florian Caringi sur de nombreux sujets : l’importance du coût de sortie, la nécessité de surveiller l’empreinte prise par un fournisseur, le besoin d’interopérabilité et l’intérêt de ne pas dépendre d’un seul prestataire.

Mais Cédric élargit également le paysage.

Canonical, une troisième voie

Lorsque nous parlons des solutions d’entreprise construites autour de Linux et de Kubernetes, deux noms reviennent rapidement : Red Hat et SUSE.

Pour Cédric, il ne faut cependant pas oublier une troisième voie : celle de Canonical, l’entreprise qui développe Ubuntu et commercialise notamment Ubuntu Pro ainsi que différentes prestations de support autour d’Ubuntu, de Kubernetes, d’OpenStack, de Ceph et d’autres composants open source.

Une précision est toutefois nécessaire : OpenShift, Rancher Prime et les offres de Canonical ne sont pas trois produits parfaitement équivalents.

OpenShift est une plateforme applicative d’entreprise construite autour de Kubernetes.

Rancher Prime est principalement une plateforme permettant de déployer et de gérer des environnements Kubernetes, y compris différentes distributions certifiées.

Canonical propose de son côté un ensemble de souscriptions, de technologies et de services autour d’Ubuntu et d’une infrastructure ouverte plus large.

La comparaison porte donc moins sur des fonctions strictement identiques que sur la manière dont ces entreprises transforment des technologies ouvertes en offres professionnelles accompagnées, maintenues et supportées.

La véritable question n’est donc pas de déterminer quel produit est le meilleur, mais de comprendre comment chaque éditeur relie les différentes briques de son offre : le système d’exploitation, les logiciels intermédiaires qui font fonctionner les applications et la plateforme proposée au client. Plus ces éléments sont étroitement liés, plus il peut devenir difficile d’en remplacer un sans remettre en cause l’ensemble.

Le couplage, critère décisif

Dans ce contexte, le couplage désigne le degré de dépendance entre les différentes briques d’une offre informatique : le système d’exploitation, les logiciels intermédiaires et la plateforme.

Plus le couplage est fort, plus ces éléments sont conçus pour fonctionner ensemble et plus il devient difficile d’en remplacer un sans modifier tout le reste ou rester dépendant du même éditeur.

C’est sur ce critère que les trois modèles se différencient réellement.

• Chez Red Hat, les différents logiciels sont conçus pour fonctionner ensemble et sont commercialisés sous la forme d’une offre complète. OpenShift s’appuie généralement sur l’environnement Red Hat : le système d’exploitation, la plateforme qui fait fonctionner les applications, les outils d’administration et les logiciels certifiés sont étroitement liés.
  C’est l’une des grandes forces du modèle : tout est pensé pour être cohérent et bien intégré.
  Mais c’est aussi ce qui peut rendre un changement de fournisseur difficile et coûteux. Il ne suffit pas toujours de remplacer un seul logiciel : il faut parfois revoir une grande partie de l’ensemble.
  

• SUSE défend une approche différente. Avec Rancher Prime, l’entreprise met en avant la possibilité de gérer des environnements Kubernetes très variés, y compris lorsqu’ils ne fonctionnent pas avec les systèmes de SUSE. L’outil de gestion peut donc être séparé du système d’exploitation utilisé en dessous.
  Cette indépendance fait partie des principaux arguments de SUSE.
  

• Canonical suit une troisième voie. Elle ne structure pas son offre autour d’une plateforme applicative unique directement équivalente à OpenShift. Elle propose plutôt plusieurs briques et plateformes d’infrastructure qui peuvent être adoptées séparément ou assemblées dans une architecture intégrée : Ubuntu pour le système d’exploitation, Kubernetes pour les applications, OpenStack pour le cloud et Ceph pour le stockage.

Ces différentes solutions peuvent être utilisées séparément. Une entreprise peut choisir Ubuntu sans acheter d’autres services auprès de Canonical. Elle peut aussi utiliser Ceph sans adopter le reste de son catalogue. Les différentes couches sont donc relativement indépendantes les unes des autres.

Que se passe-t-il lorsque l’on arrête de payer ?

Cette différence est importante lorsqu’une direction informatique cherche à savoir si elle pourra facilement changer de fournisseur.
La question essentielle à prendre en compte : que se passe-t-il lorsque l’entreprise arrête de payer son abonnement ?

Avec Red Hat Enterprise Linux, l’accès aux mises à jour et aux correctifs de sécurité dépend de la souscription. Sans contrat actif, le système ne s’arrête pas de fonctionner. En revanche, il ne reçoit plus les mises à jour nécessaires à sa maintenance et à sa sécurité.

Autrement dit, pour continuer à bénéficier d’un système correctement sécurisé, il faut conserver un abonnement.

Avec Ubuntu, le fonctionnement est différent. Les versions dites LTS (versions maintenues à long terme) bénéficient gratuitement de cinq années de mises à jour de sécurité, y compris lorsqu’elles sont utilisées en entreprise.

L’abonnement Ubuntu Pro permet d’obtenir une protection sur un plus grand nombre de logiciels et de prolonger la durée de maintenance. Mais il vient compléter un système qui reste déjà utilisable et maintenu gratuitement.

Dans un cas, le contrat est indispensable pour continuer à recevoir les mises à jour de sécurité. Dans l’autre, il permet surtout d’obtenir davantage de services et une protection plus longue. La difficulté et le coût d’une sortie ne sont donc pas comparables.

Canonical ne peut donc pas être présenté comme un simple modèle intermédiaire entre Red Hat et SUSE. Par la manière dont ses solutions peuvent être utilisées séparément et par les conditions prévues en cas d’arrêt de l’abonnement, son modèle est sensiblement plus ouvert que celui de Red Hat.

Canonical n’est pas pour autant totalement indépendant

Cela ne signifie pas que Canonical échappe à toute forme de dépendance. Canonical conserve une influence déterminante sur les orientations, les versions, l’infrastructure et le financement d’Ubuntu, même si le projet comprend également des instances de gouvernance communautaires.

Certains de ses choix ont d’ailleurs suscité des critiques dans la communauté. C’est notamment le cas du Snap Store, la plateforme de distribution de logiciels Snap, dont l’infrastructure reste largement contrôlée par Canonical.

L’objectif n’est donc pas de désigner un bon et un mauvais modèle. Il s’agit plutôt de comprendre que Red Hat, SUSE et Canonical organisent différemment les relations entre leurs logiciels, leur support, leurs partenaires et leurs clients.

Or, dans la pratique, cette organisation compte souvent davantage que la licence elle-même. C’est elle qui détermine la liberté réelle d’une entreprise, sa capacité à changer de fournisseur et le coût d’un éventuel départ.

Le cas particulier de Debian

La situation est encore différente avec Debian.

Debian n’est pas le produit d’une entreprise chargée de développer la distribution puis de vendre directement son support. Il s’agit d’un projet communautaire mondial, organisé autour de contributeurs, de développeurs et d’associations.

Il n’existe donc pas, pour Debian, d’offre commerciale centralisée exactement comparable à Red Hat Enterprise Linux, Ubuntu Pro ou aux souscriptions proposées par SUSE.

Si l’on observe la manière dont le système d’exploitation, les logiciels intermédiaires et la plateforme sont liés, Debian constitue un cas à part. La distribution n’appartient à aucun éditeur et aucune entreprise ne dispose d’une offre commerciale officielle ou exclusive contrôlant l’ensemble du projet. Il est donc beaucoup plus difficile de se retrouver enfermé dans l’écosystème d’un fournisseur précis. Avec Debian, la question n’est pas tant de savoir comment en sortir, mais plutôt de choisir soi-même les prestataires et les outils qui l’accompagnent.

Cela ne signifie pas qu’une entreprise utilisant Debian serait privée de support professionnel. Le projet publie d’ailleurs une liste de consultants, d’organisations et de sociétés proposant des prestations payantes autour de la distribution. Mais l’utilisateur ne trouve pas, derrière Debian, un éditeur unique qui engagerait directement sa responsabilité sur l’ensemble de la solution.

Cédric cite notamment Freexian, une société de services spécialisée dans les logiciels libres et fortement engagée dans l’écosystème Debian.

Freexian coordonne et finance une partie du support à long terme de Debian. Elle propose également un programme commercial de support étendu, ou Extended Long Term Support (ELTS), qui permet de maintenir certaines versions bien au-delà de leur cycle normal. Ce programme joue un rôle important, notamment pour les organisations qui ne peuvent pas migrer rapidement leurs systèmes. Mais Debian précise elle-même que l’ELTS constitue une offre commerciale et non un projet officiel de Debian.

La différence de modèle est fondamentale.

Avec Red Hat, SUSE ou Canonical, l’entreprise qui pilote la distribution propose également une offre commerciale structurée autour de celle-ci. Avec Debian, le projet reste indépendant des sociétés qui proposent du support. Une entreprise comme Freexian intervient autour de Debian, contribue à son maintien et organise des services professionnels, mais elle ne possède pas la distribution et ne parle pas au nom de l’ensemble du projet.

Cette absence d’éditeur central peut représenter une liberté supplémentaire. Elle évite qu’un seul acteur concentre tout le pouvoir économique et technique.

Ce modèle présente un intérêt particulier lorsqu’il est question de souveraineté numérique. Debian est développée et dirigée par une communauté internationale indépendante. Une entreprise ou une administration peut ensuite choisir une société française ou européenne pour l’accompagner et assurer le support, sans que cette société contrôle Debian ni que Debian dépende d’elle.

Mais elle peut aussi rendre la situation plus difficile à appréhender pour une grande organisation. Une DSI doit alors identifier elle-même les bons prestataires, construire son dispositif de support et déterminer qui sera responsable lorsqu’un incident critique surviendra.

Cette liberté a toutefois une contrepartie : Debian demande davantage d’autonomie. L’entreprise ou l’administration doit conserver les compétences nécessaires, suivre les évolutions techniques et organiser elle-même le support. Autrement dit, ce qui n’est pas fourni sous la forme d’une offre prête à l’emploi par un éditeur doit être construit en interne ou assemblé avec l’aide de différents prestataires.

L’angle mort : la certification

L’absence d’un interlocuteur unique chez Debian a une conséquence souvent sous-estimée : elle rend plus difficile la certification du matériel et des logiciels professionnels.

Lorsqu’un fabricant de serveurs, un éditeur de logiciels ou un fournisseur de bases de données veut certifier son produit pour une distribution Linux, il doit pouvoir s’entendre avec une entreprise clairement identifiée. Les deux parties fixent alors les versions prises en charge, les règles de compatibilité, la durée du support et les responsabilités de chacun en cas de problème. Red Hat, SUSE et Canonical peuvent conclure ce type d’accord. Debian, qui est portée par une communauté et non par une entreprise, ne dispose pas du même interlocuteur commercial.

C’est pourquoi Debian apparaît moins souvent dans les listes officielles de compatibilité publiées par les grands fabricants et éditeurs, même lorsque sa base technique est proche de celle d’autres distributions. Cela ne signifie pas qu’elle est moins fiable. Cela signifie surtout que très peu d’entreprises s’engagent contractuellement au nom du projet Debian.

Pour une direction informatique, cette différence peut avoir des conséquences très concrètes : un serveur peut fonctionner sans être officiellement pris en charge, un logiciel métier peut être installé en dehors des configurations certifiées et, en cas de panne, le fournisseur peut refuser d’assumer la responsabilité.

Nous retrouvons ici toute l’ambivalence de l’open source : la décentralisation réduit le risque de dépendre d’un acteur unique, mais elle peut également compliquer la construction d’une offre industrielle lisible.

Ce que Red Hat avait compris avant les autres

Cédric rappelle également que Red Hat disposait, dès le départ, d’un avantage qui n’était pas seulement technique.

L’entreprise avait compris très tôt que, pour entrer durablement dans les grandes organisations, il ne suffisait pas de proposer une bonne distribution Linux. Il fallait construire autour d’elle tout ce qu’attendent les entreprises : des cycles de maintenance prévisibles, des certifications, des relations avec les constructeurs, des engagements de support, une documentation complète et un interlocuteur clairement identifié.

Dès 2001, Red Hat a choisi de développer une édition destinée aux entreprises et vendue sous la forme d’un abonnement. Red Hat Enterprise Linux est ensuite devenu son produit central, avec une première version publiée en 2002 et un travail particulier mené avec les fabricants afin d’assurer la compatibilité du matériel, des pilotes et des différentes couches logicielles.

Red Hat n’a donc pas seulement vendu Linux.

L’entreprise a vendu aux grandes organisations la possibilité d’utiliser Linux avec le niveau de prévisibilité, de responsabilité et de sécurité contractuelle qu’elles avaient l’habitude d’attendre d’un éditeur propriétaire.

Et c’est précisément sur cette intuition que repose une grande partie de son succès.

Même PostgreSQL finit par avoir besoin d’une offre industrielle

Cette logique ne concerne pas uniquement les systèmes d’exploitation ou les plateformes Kubernetes. Cédric rappelle que l’on retrouve les mêmes mécanismes autour des bases de données libres.

PostgreSQL est un logiciel open source reconnu, mature et largement utilisé. Une organisation peut librement le télécharger, l’installer et l’administrer. Mais lorsqu’il s’agit de gérer des bases de données critiques, réparties sur une très grande infrastructure, les besoins changent. Il faut garantir la haute disponibilité, organiser les sauvegardes, préparer la reprise après incident, surveiller les performances, gérer les mises à jour, sécuriser les accès et disposer d’une assistance capable d’intervenir rapidement.
Cédric prend alors l’exemple d’IBM, qui commercialise une offre appelée EDB Postgres Enterprise and Standard with IBM. Elle associe PostgreSQL aux technologies et aux services professionnels d’EDB afin de répondre aux besoins des environnements d’entreprise. IBM propose également un service PostgreSQL entièrement administré dans son propre cloud.
Il faut toutefois éviter un raccourci : IBM ne possède pas PostgreSQL et ne constitue pas le seul chemin possible pour l’exploiter à grande échelle.
Le projet PostgreSQL recense lui-même de nombreuses entreprises proposant du support professionnel. En Europe, des sociétés comme Dalibo, CYBERTEC et plusieurs autres accompagnent déjà des infrastructures critiques.

Mais l’exemple cité reste révélateur. Même lorsqu’une organisation choisit une base de données libre, elle peut finalement se tourner vers un acteur comme IBM pour obtenir la structure, les garanties et la capacité de support nécessaires à une utilisation massive.

Le logiciel reste ouvert. Le besoin de réassurance commerciale et opérationnelle, lui, ne disparaît pas.

Le DSI ne cherche pas seulement une technologie : il cherche à être rassuré

Pour Cédric, la logique suivie par Red Hat est donc compréhensible. Un directeur des systèmes d’information ne sélectionne pas uniquement un logiciel sur la qualité de son code ou sur les libertés inscrites dans sa licence. Par ses décisions, il engage la continuité des services utilisés par des milliers, voire des millions de personnes, ainsi que la sécurité d’applications critiques et de données sensibles.

Il cherche naturellement à être rassuré.

Il veut savoir qui répondra lorsqu’un incident se produira. Il veut connaître la durée de maintenance du produit, les délais d’intervention, les responsabilités contractuelles et les compétences disponibles. Il veut pouvoir présenter à sa direction un fournisseur identifié, un contrat, un budget et des engagements mesurables.

Red Hat a su apporter cette réponse.

Le problème n’est donc pas que cette entreprise ait construit un modèle économique autour du support. Le support est indispensable, et il est légitime que les entreprises qui le fournissent puissent financer leurs ingénieurs, leurs infrastructures et leurs contributions.

Le véritable problème apparaît lorsque cette réassurance ne peut plus être obtenue qu’auprès d’un acteur unique, avec des conditions qui réduisent progressivement les possibilités de choix du client.

L’Europe doit construire ses propres offres

Sans désigner une entreprise particulière, Cédric estime que les intégrateurs, les éditeurs et les entreprises de services numériques européennes devraient davantage unir leurs forces.

L’Europe dispose de développeurs, d’experts, de sociétés de support et d’intégrateurs de grande qualité. Elle dispose également de technologies reconnues et de nombreuses communautés open source.

Ce qui lui manque encore, ce sont des offres communes suffisamment lisibles, puissantes et rassurantes pour concurrencer les grands acteurs internationaux.

Une grande organisation ne veut pas seulement entendre qu’une solution existe. Elle veut savoir qui l’installera, qui la maintiendra, qui assurera son support vingt-quatre heures sur vingt-quatre, qui garantira les mises à jour de sécurité et qui prendra la responsabilité du service pendant dix ou quinze ans.

Pour rivaliser avec Red Hat, il ne suffit donc pas de proposer une autre distribution ou de rappeler que le code source est disponible. Il faut bâtir tout l’écosystème industriel qui l’accompagne.

On observe cependant une certaine frilosité parmi les acteurs européens.

Construire une offre commune suppose d’investir, de partager les responsabilités, d’accepter une gouvernance collective et de financer des équipes avant même de disposer d’un volume important de clients. Or le modèle économique de l’open source ne repose pas nécessairement sur la vente de licences. Il dépend du support, de l’expertise, de l’intégration, de la maintenance et des services.

L’écosystème cherche encore son équilibre.

Chaque entreprise peut être tentée de préserver ses propres clients, ses propres compétences et son propre catalogue plutôt que d’investir dans une offre commune dont la valeur serait partagée entre plusieurs acteurs.

Pourtant, c’est précisément cette capacité à s’unir qui pourrait permettre de construire une véritable alternative européenne : une offre suffisamment solide pour rassurer les DSI, mais suffisamment ouverte pour ne pas transformer cette réassurance en nouvelle dépendance.

IA et communs numériques : l’open source change de modèle

Enfin, Cédric voit se dessiner deux évolutions susceptibles de transformer en profondeur l’open source :

L’intelligence artificielle modifie déjà la manière de travailler des développeurs, en automatisant certaines tâches et en déplaçant une partie de leur travail vers la vérification, la correction et l’intégration du code.

Dans le même temps, les communs numériques, comme LaSuite de l’État, font émerger une autre manière de concevoir et de gouverner les logiciels. Les acteurs publics et privés ne se contentent plus d’utiliser des solutions existantes : ils peuvent contribuer à une infrastructure commune, en partager la gouvernance et en assurer collectivement la pérennité.

Selon lui, cette convergence pourrait ouvrir une troisième voie entre la dépendance à un éditeur propriétaire et les fragilités de projets open source trop dispersés. La souveraineté technologique reposerait alors moins sur la propriété exclusive du code que sur sa maîtrise et sa gouvernance collective.

Deux générations, une même exigence

Les regards de Florian Caringi et de Cédric Ravalec ne se confondent pas, et c’est justement ce qui fait leur intérêt.

Florian n’appartient pas à la génération historique de l’open source professionnel. Son arrivée plus récente dans cet écosystème constitue une force. Il porte un regard neuf, apporte une énergie différente et montre que l’open source n’est pas un domaine réservé à celles et ceux qui le fréquentent depuis les débuts de Linux.

Son parcours peut aussi susciter des vocations.

Il montre à une nouvelle génération qu’il est possible de travailler dans l’open source au cœur d’un grand groupe, de participer à sa gouvernance, de construire des politiques ambitieuses et de rapprocher les enjeux techniques des questions de souveraineté.

L’open source n’est plus un sujet périphérique. Il offre désormais des parcours professionnels d’avenir, modernes, stratégiques et profondément utiles.

Cédric apporte pour sa part la mémoire de cette transformation. Il a connu l’époque où l’open source devait encore démontrer qu’il n’était pas seulement une affaire de passionnés, de bricoleurs ou de geeks. Il fait partie de celles et ceux qui ont contribué à le faire entrer dans les entreprises, à construire des offres, à créer des sociétés, à organiser des communautés et à faire reconnaître la valeur du support professionnel.

Cette longue expérience ne l’a rendu ni cynique ni désabusé, et n’a rien retiré à sa passion.

Elle lui permet au contraire de regarder le chemin parcouru sans oublier ce qui reste à construire. L’open source a démontré qu’il constituait une alternative sérieuse, robuste et crédible aux systèmes propriétaires. Ses fondations n’ont plus à rougir de la comparaison.

Le temps de la démonstration technique est largement derrière nous.

Le temps de la construction industrielle, lui, est MAINTENANT.

C’est maintenant qu’il faut investir.
Maintenant qu’il faut faire émerger des offres européennes communes.
Maintenant qu’il faut sécuriser les compétences, financer le support et transformer les réussites dispersées en véritables acteurs capables de rivaliser à l’échelle internationale.

Il était donc important de dresser le portrait de ces deux personnalités.

Leurs parcours sont différents, leurs expériences appartiennent à des moments distincts de l’histoire de l’open source, mais leurs chemins se croisent sur des questions essentielles : la maîtrise, la réversibilité, l’interopérabilité et la capacité à ne pas remplacer une dépendance propriétaire par une dépendance commerciale construite autour d’un logiciel ouvert.

Tous deux m’ont mis sur une piste particulièrement intéressante : celle d’une comparaison approfondie entre Red Hat OpenShift et SUSE Rancher Prime.

Mais cette comparaison ne doit pas, elle non plus, devenir une nouvelle illusion.

Cette complémentarité ne se limite d’ailleurs pas à leurs témoignages. Florian et Cédric sont également à l’origine du Data & AI Sovereignty Summit : Florian en est le cofondateur et président, tandis que Cédric siège au comité de direction de l’événement. Cette rencontre consacrée à la donnée et à l’intelligence artificielle place la souveraineté au cœur de sa réflexion : comment continuer à innover tout en gardant la maîtrise de ses données, de ses infrastructures et de ses choix technologiques ?
Il ne s’agit pas de prétendre tout construire seul, mais de limiter les dépendances subies, de préserver sa capacité de décision et de concevoir des systèmes plus ouverts et plus résilients. Prévue le 25 février 2027 à Paris, la première édition réunira des décideurs, des experts et des professionnels venus partager des solutions et des retours d’expérience concrets.

Et si SUSE changeait de mains ?

Il serait tentant de considérer SUSE comme l’alternative européenne qui permettrait de disperser les dépenses aujourd’hui concentrées autour d’IBM et de Red Hat.

Mais la localisation actuelle d’une entreprise ne garantit pas éternellement son indépendance.

IBM a achevé l’acquisition de Red Hat en 2019 pour environ 34 milliards de dollars. Comme cela a été rappelé au début de cet article, le rapport de la commission d’enquête parlementaire indique qu’en 2025, les administrations de l’État ont consacré 17,1 millions d’euros à Red Hat et 12,6 millions à IBM, soit près de 30 millions d’euros pour les deux entreprises.

Que se passerait-il si SUSE était à son tour rachetée par un grand groupe américain ou par un consortium extra-européen ?

La question n’est d’ailleurs plus entièrement théorique. SUSE est aujourd’hui contrôlée par le fonds d’investissement suédois EQT, qui l’a retirée de la Bourse en 2023. En mars 2026, Reuters a rapporté qu’EQT étudiait une éventuelle cession de SUSE, dans une opération qui pourrait valoriser l’entreprise autour de six milliards de dollars. Les discussions étaient alors présentées comme préliminaires et aucune vente n’était acquise.

Si SUSE passait demain sous le contrôle d’un groupe extra-européen, la nature fondamentale du problème ne changerait pas.

Au lieu de voir les dépenses concentrées sur une seule ligne correspondant au duo IBM-Red Hat, une deuxième ligne apparaîtrait simplement dans les comptes. L’argent serait mieux réparti entre plusieurs fournisseurs, ce qui réduirait peut-être certaines dépendances opérationnelles, mais il continuerait à bénéficier à des entreprises contrôlées depuis l’extérieur de l’Europe.

La diversification est nécessaire, mais elle ne constitue pas à elle seule une politique de souveraineté.

Il serait peut-être temps de poser une question plus ambitieuse : pourquoi l’Europe ne construirait-elle pas un acteur capable de concurrencer sérieusement Red Hat ?

Pourquoi ne pas imaginer un consortium européen, réunissant des industriels, des intégrateurs, des entreprises de services, des investisseurs de long terme et éventuellement des acteurs publics, afin de sécuriser durablement l’ancrage européen d’une entreprise comme SUSE ?

Et pourquoi limiter cette réflexion à SUSE ?

D’autres distributions, d’autres plateformes et d’autres communautés pourraient servir de fondation à des offres européennes capables d’associer support professionnel, standards ouverts, interopérabilité et véritable réversibilité.

Un simple drapeau européen ne suffirait évidemment pas. Il faudrait garantir une gouvernance durable, empêcher qu’une nouvelle concentration ne recrée les mêmes dépendances et inscrire l’ouverture, la portabilité et le coût de sortie au cœur même du modèle.

Mais rien n’interdit de l’imaginer. Et surtout, rien ne justifie d’attendre davantage pour commencer à le construire.