Vous avez un projet, ou êtes en réflexion, sur un enjeu métier ou IT ?
Les environnements IT n’ont jamais été aussi complexes. Dans le même temps, les technologies Cloud Native s’imposent désormais comme un socle d’industrialisation qui fait autorité sur le marché. La CNCF indique que 82 % des utilisateurs de conteneurs exécutent désormais Kubernetes en production, signe que Kubernetes est devenu une couche d’exploitation commune pour les systèmes modernes, y compris les environnements liés à l’IA.
Pour les DSI, CTO et directions de la transformation, la question devient structurante : comment garder la maîtrise de son architecture, de ses coûts, de ses dépendances et de ses environnements critiques ?
Dans cette perspective, bâtir ses environnements s’appuyant sur des technologies Open Source représente un levier majeur qui rend les infrastructures plus ouvertes, évolutives et mieux adaptées aux contextes spécifiques de chaque entreprise.
Vincent Barthez, Responsable Digital Foundation chez Inside, partage dans cette interview sa vision : une infrastructure indépendante ne se résume pas à une stack technologique. Elle repose sur une architecture cohérente, des standards ouverts, une capacité d’exploitation réelle et une trajectoire de transformation maîtrisée.
Pourquoi l’indépendance technologique revient-elle comme un sujet prioritaire pour les DSI ?
Elle revient car beaucoup d’organisations ont pris conscience que la dépendance technologique ne se limite pas à un contrat fournisseur ou à une ligne de licence. Elle peut être beaucoup plus profonde : dépendance à une architecture, à une plateforme, à un modèle de pricing, à des compétences rares, voire à des processus internes trop complexes.
Chez les DSI, le sujet se pose rarement de façon binaire. Il ne s’agit pas de sortir du cloud public, ni de tout rapatrier dans des datacenters. Ce serait une mauvaise lecture du problème. Le cloud public garde une valeur très forte pour l’élasticité, certains services managés, la data, l’IA ou l’accélération de projets. À l’inverse, certains workloads, certaines données ou certaines contraintes d’exploitation justifient de conserver une capacité forte sur des environnements privés ou sur site.
Le vrai sujet, c’est donc la maîtrise. Est-ce que vous savez où sont vos dépendances critiques ? Est-ce que vous pouvez remplacer une brique sans reconstruire tout l’édifice ? Est-ce que vos équipes comprennent l’architecture qu’elles opèrent ? Est-ce que vos choix techniques peuvent évoluer sans remettre en cause toute votre trajectoire ?
A la KubeCon 2026 un acteur majeur du transport ferroviaire national, a présenté un projet de Cloud public sur lequel nous sommes intervenus, et précise que la souveraineté est vue comme la capacité à disposer de solutions performantes, fiables et interchangeables, de la même façon que si elles étaient exécutées dans un cloud public.
On entend d’ailleurs souvent parler d’“autonomie stratégique” plutôt que de souveraineté, expression plus opérationnelle et moins incantatoire.
C’est exactement cette nuance qui m’intéresse ! L’indépendance technologique n’est pas une posture. C’est une capacité d’action.
Le sujet n’est pas d’opposer cloud public et infrastructure sur site. C’est de gagner en maîtrise de son architecture.
Kubernetes : quelle distribution choisir pour votre stratégie de conteneurisation ?
Découvrez nos conseils et des valeurs ajoutées et bénéfices des orchestrateurs !
En quoi l’Open Source peut-il devenir un levier concret d’indépendance technologique ?
L’Open Source devient un levier quand il est considéré comme un choix d’architecture, pas comme une simple alternative économique.
Sa première valeur, c’est la réversibilité. En s’appuyant sur des standards ouverts, vous évitez de construire votre SI autour de mécanismes propriétaires impossibles à remplacer. Kubernetes pour l’orchestration, Terraform ou OpenTofu pour l’Infrastructure as Code, Prometheus pour le monitoring : ces briques permettent de bâtir des socles compréhensibles, documentés, adoptés largement et moins dépendants d’un acteur unique. C’est une conviction forte de notre centre d’excellence Digital Foundation : l’Open Source n’est pas seulement un choix de coût, mais une décision d’architecture stratégique pour garantir l’indépendance technique et la pérennité d’un système.
La deuxième valeur, c’est la maturité collective. Un projet Open Source porté par une communauté active, une fondation solide, une documentation robuste et des usages industriels réels bénéficie d’un niveau de revue, de retours d’expérience et d’amélioration continue difficile à reproduire seul. Dans l’écosystème Cloud Native, la CNCF a joué ce rôle de structuration : elle a contribué à rendre interopérables des composants qui font désormais référence dans l’industrie.
La troisième valeur, c’est l’accès à l’état de l’art. Les cycles d’innovation sont souvent plus courts dans les communautés Open Source que dans certains modèles éditeurs. Cela ne veut pas dire qu’il faut courir derrière chaque projet qui apparaît. Cela veut dire que les entreprises peuvent sélectionner des briques matures, les assembler intelligemment et garder la possibilité de les faire évoluer.
Cependant, attention : Open Source ne veut pas dire absence d’exigence. Tous les projets ne se valent pas. Il faut regarder la gouvernance du projet, la taille et la qualité de la communauté, la fréquence des releases, la sécurité, l’intégration dans l’écosystème, la capacité de support et surtout l’adéquation au contexte.
L’Open Source n’est pas un raccourci budgétaire. C’est un choix d’architecture, de maîtrise et de pérennité.
Comment atteindre une qualité de service comparable au cloud public avec une infrastructure maîtrisée en interne ?
La qualité de service ne vient pas du fait qu’une solution soit cloud, Open Source ou sur site. Elle vient de son niveau d’industrialisation.
Le cloud public a habitué les équipes à une expérience de consommation très fluide : provisionnement rapide, API, automatisation, self-service, supervision, scalabilité, catalogue de services. Si vous voulez proposer une alternative crédible en cloud privé ou en environnement maîtrisé, vous devez tendre vers ce niveau d’expérience. Cela suppose de raisonner comme un fournisseur de plateforme interne.
Un retour d’expérience de la SNCF lors des CloudNativeDaysFR, auquel notre expert Inside Matthieu STROHL a participé, illustre bien cette trajectoire. Le SI concerné représente environ 2 000 applications, réparties sur 4 datacentres et 3 cloud providers. L’équipe conteneurisation, composée de 14 experts, accompagne près de 30 % du SI, dans un contexte de montées de version infra régulières et de gestion de CVE critiques. L’objectif présenté : rendre une stack technologique sur site aussi automatisée et intégrée que les clouds déjà exploités.
Le chemin n’a pas été immédiat. La première approche était fonctionnelle, mais lourde : un an de développement, un RACI complexe, un cluster qui pouvait prendre un mois à provisionner, et chaque changement d’infrastructure devenait un défi associé à une feuille Excel. C’est un très bon exemple, parce qu’il montre que “ça marche” ne suffit pas. Une plateforme peut être opérationnelle sans être réellement consommable à l’échelle.
La trajectoire technique a ensuite consisté à réduire les frictions : OpenStack pour gagner en autonomie dans la consommation de l’infrastructure, Talos pour disposer d’un OS immuable, minimaliste et conçu pour Kubernetes, ArgoCD pour gérer le GitOps et le Day 2, puis Cluster API pour automatiser le cycle de vie des clusters, avec de l’autoscaling et de l’auto-healing des nœuds.
Ces choix techniques racontent une conviction plus large : pour atteindre une qualité de service comparable au cloud public, il ne suffit pas d’installer Kubernetes. Il faut industrialiser tout ce qui l’entoure : réseau, sécurité, observabilité, stockage, montée de version, patching, gestion des secrets, templates, pipelines, procédures de reconstruction.
Dans le retour d’expérience présenté, l’équipe montre même une logique d’upgrade pilotée via GitLab, ArgoCD et Cluster API : changement de version Kubernetes et Talos, modification du nombre de réplicas, évolution d’un nodepool, rollout des control planes puis des workers. Ce niveau d’automatisation transforme la plateforme : elle devient pilotable par déclaration, non par intervention manuelle répétée.
Si vous voulez offrir une expérience comparable au cloud public, vous devez concevoir votre plateforme, pas simplement administrer des serveurs.
Quels pièges faut-il éviter quand une organisation construit une plateforme Open Source ?
Le premier piège consiste à empiler des briques Open Source sans architecture globale. C’est tentant, parce que l’écosystème est riche. Mais plus vous ajoutez de composants sans vision d’ensemble, plus vous créez de complexité d’exploitation, de dette technique, de dépendances entre équipes et de risques lors des montées de version.
Le deuxième piège consiste à croire que l’Open Source supprime mécaniquement le lock-in. Il réduit certains verrouillages, mais il peut en créer d’autres si la plateforme devient trop spécifique, trop peu documentée ou trop dépendante de quelques experts internes. Une dépendance à un éditeur peut être remplacée par une dépendance à deux personnes qui comprennent réellement le socle. Ce n’est pas une indépendance, c’est une fragilité différente.
Le troisième piège est de négliger le Day 2. Installer une plateforme est rarement la partie la plus difficile. L’exploiter dans le temps l’est beaucoup plus : patcher, superviser, gérer les CVE, automatiser les montées de version, reconstruire des nœuds, tester les changements, maintenir la cohérence des environnements. Le REX CloudNativeDaysFR est intéressant parce qu’il montre précisément cette progression : des scripts utiles au départ, mais insuffisants à l’échelle ; puis une bascule vers ArgoCD, le pattern App-of-Apps, des contrôleurs, Cluster API et une automatisation plus événementielle.
Chez Digital Foundation, nous formulons souvent cela ainsi : la complexité n’est pas une fatalité. Le Platform Engineering sert précisément à créer un chemin balisé pour les équipes. L’objectif n’est pas que chaque développeur maîtrise l’ensemble de l’écosystème Cloud Native. L’objectif est de proposer une plateforme interne qui simplifie l’accès aux services, standardise les pratiques et masque la complexité inutile sans retirer la maîtrise aux équipes qui doivent l’opérer.
Le piège, c’est de quitter une dépendance visible pour construire une complexité que seules deux personnes savent maintenir.
L’Open Source permet-il vraiment de réduire les coûts ?
Oui, mais pas toujours comme les entreprises l’imaginent. Et pour moi ce n’est pas l’objectif premier !
L’Open Source peut réduire certains coûts de licence. Il peut aussi éviter certaines hausses tarifaires, ouvrir des alternatives, redonner du pouvoir de négociation et limiter les dépendances économiques à un acteur unique. Pour autant, cela ne veut pas dire que la plateforme coûte “moins cher” par défaut.
Les coûts se déplacent. Vous payez moins certaines licences, mais vous devez investir dans les compétences, l’architecture, l’exploitation, la supervision, la sécurité, la documentation, l’automatisation, parfois le support, et idéalement la contribution. C’est très sain, à condition d’en être conscient.
Chez Digital Foundation, nous partons d’une conviction simple : le coût est souvent le symptôme, la dette technique est la maladie. Une infrastructure vieillissante, mal documentée, trop spécifique ou sous-automatisée finit toujours par coûter cher : en run, en incidents, en délais, en risque cyber, en dépendance à quelques sachants.
C’est aussi pour cela que la démarche FinOps doit être structurée et appuyée sur une maîtrise réelle de l’existant. Il faut donner de la visibilité, créer un langage commun entre DSI, finance et métiers, et relier une hausse ou une baisse de coût à une valeur produite. L’outillage vient ensuite : il mesure, contrôle et améliore, mais il ne remplace pas la gouvernance. L’IA renforce encore cette exigence et déplace les sujets de maîtrise des coûts vers le cloud, le SaaS, les datacenters et les plateformes internes.
Pour une DSI, la bonne question n’est donc pas : “Combien coûte la licence ?” La bonne question est : “Quel est le coût complet de maîtrise ?” Si l’Open Source permet de réduire la dépendance, d’automatiser, de standardiser, d’améliorer la qualité de service et de sécuriser la trajectoire, le ROI peut être très fort. Cependant, il ne vient pas gratuitement !
Avec l’Open Source, les coûts ne disparaissent pas. Ils se déplacent vers la compétence, l’exploitation et la responsabilité
Par où commencer pour reprendre la main sur son infrastructure sans lancer un chantier démesuré ?
Il faut éviter de démarrer par une cible idéale. Elle n’existe pas. Une bonne architecture dépend du contexte : criticité des workloads, contraintes réglementaires, maturité des équipes, exposition cyber, besoins de scalabilité, contraintes de données, budget, dette existante.
Je conseille de commencer par une cartographie des dépendances critiques. Quelles briques vous enferment réellement ? Quelles applications doivent rester proches de certaines données ? Quels services managés seraient difficiles à remplacer ? Quelles compétences sont disponibles en interne ? Quels environnements concentrent le plus de risques, de coûts ou de dette ?
Ensuite, il faut qualifier les zones où la maîtrise crée de la valeur. Tout ne mérite pas le même niveau d’indépendance. Certaines applications peuvent rester en SaaS. Certains workloads peuvent rester en cloud public. D’autres justifient une plateforme privée, un environnement Kubernetes maîtrisé, une architecture hybride ou une trajectoire de modernisation par étapes.
Dans nos travaux autour de la modernisation et de la dévirtualisation, nous recommandons de penser en couches et en “boxes” : chaque composant doit rester remplaçable, et le ciment entre les briques doit reposer sur des standards ouverts plutôt que sur des mécanismes propriétaires. L’objectif n’est pas de remplacer une dépendance par une autre, mais de construire une architecture modulaire, cohérente et opérable.
L’IA doit également entrer dans cette réflexion, sans devenir un prétexte à tout reconstruire. Chez Inside, nous abordons cette trajectoire avec une conviction : une infrastructure moderne doit devenir un produit interne. Elle doit standardiser, sécuriser, accélérer et rendre les choix plus lisibles pour les équipes Dev, Ops, Sec, finance et métiers. C’est le rôle du Platform Engineering : transformer la complexité technologique en capacité d’action.
La bonne trajectoire n’est pas celle qui promet de tout remplacer. C’est celle qui redonne progressivement de la maîtrise là où elle crée le plus de valeur.
Pour conclure, l’Open Source n’est ni une garantie automatique d’indépendance, ni une solution magique pour réduire les coûts. C’est un levier puissant à condition d’être intégré dans une vision d’architecture, d’exploitation et de gouvernance.
L’indépendance technologique se construit dans les détails : choix des standards, modularité des composants, automatisation, observabilité, sécurité, compétences internes, pilotage des coûts, capacité à remplacer une brique sans fragiliser l’ensemble.
C’est précisément dans cette capacité d’assemblage, de recul et d’industrialisation qu’Inside accompagne les DSI : non pas pour imposer une vision technologique, mais pour construire des plateformes cohérentes et maîtrisées reliées aux enjeux métiers et avec pour seul objectif, la valeur perçue.
Discutons de votre indépendance technologique !
Parlons-en !
