Open source européen : arrêtez de compter les licences, commencez à compter les compétences

# Open source européen : arrêtez de compter les licences, commencez à compter les compétences

Il y a une erreur de calcul que font encore trop de DSI européens en 2026. Elle consiste à comparer le coût d'une licence propriétaire américaine avec le coût apparent d'une solution open source — et à conclure, souvent, que l'écart ne justifie pas la migration. C'est une erreur de comptabilité, pas une erreur de jugement. Parce que le vrai coût n'est pas dans la ligne "licences" du budget IT. Il est dans la dépendance structurelle que vous avez laissé s'installer, contrat après contrat, renouvellement après renouvellement.

Ce texte ne cherche pas à vous vendre l'open source comme une idéologie. Il cherche à vous donner les outils pour recalculer honnêtement ce que vous payez réellement — et ce que vous pourriez récupérer.

Ce que votre CFO appelle "économie", votre fournisseur US appelle "verrouillage"

La mécanique est bien rodée. Un acteur américain dominant propose un bundle à prix compétitif à l'entrée. Les équipes s'adaptent, les processus se calquent sur l'outil, les formats de données deviennent propriétaires, les intégrations se multiplient. Trois ans plus tard, quand arrive la renégociation, vous n'êtes plus en position de négocier : vous êtes captif.

Ce phénomène — le vendor lock-in — n'est pas nouveau. Ce qui est nouveau, c'est son intensité en 2026, dans un contexte géopolitique où la question de la souveraineté numérique est devenue une question de compétitivité industrielle, pas seulement de conformité réglementaire. Le Cloud Act américain n'a pas disparu. Les restructurations tarifaires des grands éditeurs US se sont accélérées. Et les ETI européennes qui avaient misé sur la stabilité de ces partenariats découvrent que la stabilité était unilatérale.

La vraie question n'est donc pas "l'open source coûte-t-il moins cher ?". La vraie question est : quel est le coût réel de ne pas contrôler votre infrastructure ?

Ce coût a plusieurs composantes que les budgets IT classiques n'isolent pas :

• Le différentiel entre le tarif d'entrée et le tarif de renouvellement, une fois le lock-in installé
• Le coût de conformité RGPD lié à des flux de données dont vous n'avez pas la maîtrise effective
• Le coût d'opportunité sur les évolutions fonctionnelles que vous ne pouvez pas décider vous-même
• Et surtout : le coût de la dépendance compétentielle — vos équipes savent utiliser l'outil, pas le comprendre

C'est ce dernier point qui tue les projets de migration ouverte. Pas le budget. Les compétences.

Le vrai déficit : ce n'est pas le code, c'est la capacité interne à le piloter

L'open source n'est pas gratuit. Il faut l'installer, le maintenir, le sécuriser, l'adapter, le faire évoluer. La communauté fournit le code. Elle ne fournit pas vos ingénieurs.

Là où l'équation devient favorable — et elle peut le devenir très significativement — c'est quand vous internalisez les bonnes compétences plutôt que de les externaliser perpétuellement vers des prestataires qui, souvent, sont eux-mêmes dépendants des éditeurs US.

La distinction est fondamentale : il y a une différence entre un prestataire qui vous déploie une solution open source et une équipe interne qui la maîtrise. Le premier vous libère d'un fournisseur US pour vous enfermer dans une dépendance de service. Le second vous donne réellement de l'autonomie.

Concrètement, qu'est-ce que cela signifie pour un DSI d'ETI en 2026 ?

Cela signifie identifier, pour chaque composant critique de votre SI, si vous avez en interne au moins une personne capable de comprendre l'architecture de la solution — pas seulement l'administrer. Cette distinction entre *administrateur* et *architecte maîtrisant le fonctionnement profond* est le premier diagnostic à faire.

Sur les périmètres les plus stratégiques — gestion des identités, stockage des données sensibles, orchestration des workflows métier — l'absence de cette compétence interne est un risque de continuité, pas seulement un risque de coût.

Le paradoxe, c'est que les ETI européennes ont souvent des profils capables de monter en compétence sur ces sujets. Mais ces profils ont été orientés vers la maîtrise d'outils propriétaires US, parce que c'est ce que le marché valorisait. Il s'agit maintenant d'inverser cette logique de formation.

Gouvernance de la transition : ne pas migrer, transformer

L'erreur classique dans les projets de bascule open source, c'est de les traiter comme des projets de migration technique. Remplacer l'outil A par l'outil B, valider que les fonctionnalités sont équivalentes, fermer le ticket.

Cette approche échoue pour une raison simple : elle ne change pas la logique organisationnelle sous-jacente. Les équipes continuent de travailler comme si elles utilisaient l'outil propriétaire. Les processus restent calqués sur les contraintes de l'ancien système. Et quand la solution open source ne se comporte pas exactement comme son prédécesseur américain — ce qui arrivera — la frustration s'installe, et le retour en arrière devient tentant.

La transformation souveraine doit donc être pilotée comme un projet organisationnel autant que technique. Cela implique plusieurs décisions de gouvernance que le DSI doit porter, pas seulement valider :

Créer un rôle de "référent souveraineté SI" au sein de la DSI, dont la mission est de maintenir à jour la cartographie des dépendances US dans le SI et de proposer des jalons de réduction. Ce n'est pas un poste à plein temps dans une ETI — c'est une responsabilité formalisée, avec un mandat clair et un reporting direct à la direction.

Intégrer un critère de souveraineté dans les appels d'offres IT. En 2026, la réglementation européenne (NIS2, Data Act, DORA pour les secteurs financiers) impose déjà des exigences qui vont dans ce sens. Mais au-delà de la conformité, ce critère doit être un filtre stratégique : toute solution qui ne permet pas l'export des données dans un format standard ouvert, ou dont l'hébergement ne peut être localisé en Europe, doit être traitée comme un risque, pas comme une option neutre.

Établir une politique de formation pluriannuelle orientée compétences ouvertes. Pas un catalogue de formations, mais une carte des compétences critiques à développer en interne sur 24 à 36 mois, avec des objectifs mesurables. Quels périmètres du SI devez-vous maîtriser en interne d'ici fin 2027 ? Qui dans l'équipe porte cette montée en compétence ? Avec quel accompagnement ?

Cette gouvernance n'est pas spectaculaire. Elle est surtout continue — et c'est précisément pourquoi elle est difficile à maintenir dans des organisations où l'urgence opérationnelle écrase régulièrement le temps long.

Les compétences à ancrer en interne : le vrai capital souverain de votre DSI

Parlons concrètement de ce que signifie "développer les bonnes compétences" dans une ETI européenne qui engage une démarche de souveraineté SI.

Il ne s'agit pas de former tout le monde à tout. Il s'agit d'identifier les nœuds critiques où la dépendance externe est aujourd'hui totale — et de les ouvrir progressivement.

La gestion des identités et des accès est souvent le premier périmètre à adresser. C'est un domaine où la dépendance aux solutions propriétaires américaines est forte, où les implications RGPD sont directes, et où des alternatives européennes robustes existent et sont matures. Avoir en interne une compétence réelle sur ce périmètre — comprendre l'architecture, savoir diagnostiquer un incident, être capable d'évaluer une évolution — est un prérequis de souveraineté opérationnelle.

**La gestion documentaire et collaborative** est le second périmètre à examiner sérieusement. C'est là que résident souvent les données les plus sensibles — les données métier, les données de décision. Et c'est là que la dépendance aux suites propriétaires américaines est la plus naturalisée, la plus invisible. Des acteurs européens comme Nextcloud ont atteint en 2026 un niveau de maturité fonctionnelle qui rend la comparaison honnête. Mais le vrai travail n'est pas d'installer la solution : c'est d'accompagner les équipes métier dans une transformation de leurs habitudes de travail, ce qui requiert des compétences en conduite du changement autant qu'en administration système.

La sécurité et la supervision du SI est le troisième domaine critique. Dépendre d'un SOC externalisé dont les outils et les données transitent par des infrastructures américaines, c'est une contradiction de souveraineté que beaucoup d'ETI n'ont pas encore pleinement réalisée. Ici, la montée en compétence interne ne signifie pas tout faire soi-même — cela signifie être en capacité de qualifier ses prestataires, de comprendre leurs architectures, et de maintenir une maîtrise effective des données de sécurité qui concernent votre organisation.

La règle simple pour prioriser : là où une perte de service ou une fuite de données vous serait insupportable, vous devez avoir de la compétence interne. Là où l'impact est limité et réversible, l'externalisation reste une option rationnelle.

Inverser le ratio sur 36 mois : une feuille de route, pas une révolution

Il n'existe pas de migration souveraine réussie en six mois. Il existe des organisations qui ont décidé, à un moment donné, de commencer — et qui mesurent leurs progrès sur la durée.

La bonne métrique n'est pas le pourcentage de l'infrastructure basculée sur de l'open source. C'est le pourcentage de vos composants SI critiques pour lesquels vous avez une compétence interne réelle, une alternative qualifiée, et un plan de sortie documenté si votre fournisseur actuel change ses conditions.

Sur 36 mois, une ETI européenne avec une DSI de taille raisonnable peut réalistically :

• Identifier et documenter l'intégralité de ses dépendances US critiques
• Former deux à trois référents internes sur les périmètres les plus exposés
• Migrer un à deux composants non critiques pour acquérir de l'expérience organisationnelle
• Intégrer les critères de souveraineté dans tous les nouveaux appels d'offres
• Bâtir une relation avec un ou deux acteurs européens de confiance sur lesquels capitaliser

C'est moins spectaculaire qu'une bascule totale. C'est infiniment plus durable.

Le ratio coûts/bénéfices de l'open source européen ne s'inverse pas en changeant les outils. Il s'inverse en changeant la logique organisationnelle : passer d'une DSI qui consomme des services à une DSI qui maîtrise son infrastructure. C'est un choix politique autant que technique. Et en 2026, c'est devenu un choix de compétitivité.