Red Hat Summit 2026 : quand l’open source propulse l’ère industrielle de l’IA agentique

Red Hat Summit 2026 : l’open source comme socle industriel pour exécuter l’IA agentique sans boîte noire

À Atlanta, au Georgia World Congress Center, le Red Hat Summit a pris un virage résolument « usine » : moins de slogans, davantage de méthodes, d’outils et de garde-fous. L’idée qui traverse les annonces est simple à formuler, mais redoutable à mettre en œuvre : faire fonctionner des agents IA en production tout en gardant la main sur l’architecture, les données, les identités et les journaux d’audit. Là où d’autres événements promettent l’entreprise « autonome » en quelques clics, Red Hat s’est plutôt attaché à une question beaucoup plus concrète : où tourne l’agent, que touche-t-il, comment sait-on qu’il n’a pas dévié, et comment l’arrêter proprement ? 🔎

Le message s’inscrit dans la continuité des grandes messes technologiques du moment. Google a mis en avant une plateforme agentique intégrée et la sécurisation « par des agents ». IBM, de son côté, martèle que la victoire se joue dans l’exploitation hybride et la gouvernance. Red Hat, fidèle à son ADN, s’installe au niveau du socle d’exécution : Linux, Kubernetes, automatisation, chaîne logicielle, et désormais IA agentique. Autrement dit, l’éditeur ne cherche pas à imposer « le » modèle, mais la couche qui rend les modèles et les agents portables, observables et contrôlables.

Cette posture répond à une anxiété très actuelle des DSI : les POC d’IA générative se multiplient, les copilotes prolifèrent, mais l’industrialisation fait surgir une nouvelle dépendance, plus insidieuse que les précédentes. Un agent peut appeler des outils, déclencher un workflow, lire un document, générer du code… et devenir un point d’entrée inattendu dans le SI. Voilà pourquoi Red Hat insiste sur l’idée d’une infrastructure qui « encadre » l’autonomie au lieu de la nier. Le but n’est pas de ralentir l’innovation, mais de la rendre assurable et auditable ✅.

Pour illustrer cette logique, imaginons une entreprise fictive, AtelierNova, un industriel européen avec des sites de production, une DSI centralisée et des contraintes de conformité. AtelierNova veut déployer des agents : l’un pour aider le support à diagnostiquer des incidents, un autre pour optimiser la chaîne d’approvisionnement, un troisième pour assister les développeurs. Sur le papier, tout est simple. Dans la réalité, ces agents ont besoin d’accès à des tickets, des logs, des dépôts Git, parfois à des environnements de test, voire à des outils d’automatisation. Sans un socle robuste, l’agent devient un opérateur invisible et incontrôlé. Red Hat positionne précisément ses briques comme les « rails » qui empêchent le déraillement.

Cette industrialisation a aussi un coût et une pression budgétaire : tokens, GPU, stockage, sécurité, mise en conformité… Un clin d’œil s’impose à l’inflation technologique vécue par les DSI, qui se retrouve amplifiée dès que l’IA passe du labo au run. Le Summit propose une réponse pragmatique : standardiser l’exécution et la gouvernance avec de l’open source d’entreprise, au lieu d’empiler des solutions isolées.

Le fil conducteur de l’événement devient alors limpide : l’IA agentique, oui, mais avec des frontières de confiance. Et ces frontières, chez Red Hat, se dessinent de RHEL à OpenShift, d’Ansible à Red Hat AI, en cherchant à transformer l’autonomie en processus industriel plutôt qu’en magie marketing. La suite logique mène directement vers la pièce maîtresse côté IA : Red Hat AI 3.4.

Red Hat AI 3.4 et la stratégie « metal-to-agent » : gouverner modèles, inférence et AgentOps à grande échelle

Le cœur battant des annonces IA se nomme Red Hat AI 3.4, présenté comme un chaînon complet entre le matériel et l’agent en production. Derrière la formule « metal-to-agent », l’ambition est très opérationnelle : couvrir l’inférence distribuée, l’accès gouverné aux modèles, la traçabilité, l’observabilité, et tout ce qui permet de ne pas rester bloqué au stade « démo impressionnante ». Car dans les entreprises, le gouffre entre un agent qui marche sur un laptop et un agent qui tourne 24/7 est immense. Et ce gouffre n’est pas seulement technique : il est aussi juridique, budgétaire et sécuritaire. ⚙️

Une des avancées structurantes est l’idée d’un Model-as-a-Service gouverné. Concrètement, les équipes de développement obtiennent une interface cohérente pour consommer des modèles, tandis que l’exploitation conserve des leviers : suivi des usages, politiques d’accès, règles de consommation, et contrôle des dérives. Pour AtelierNova, cela change la donne : le responsable plateforme n’a plus besoin d’autoriser « au cas par cas » des endpoints exotiques. Il peut définir une offre interne (modèles validés, quotas, logs), et laisser les produits IA avancer sans transformer l’infrastructure en marché noir de GPU.

Sur le plan performance, la plateforme s’appuie sur des moteurs d’inférence reconnus pour leur capacité à distribuer la charge, notamment vLLM et llm-d. Cela répond à une réalité de terrain : l’agentique n’est pas un simple flux de chat, mais une succession de requêtes, d’outils appelés, de validations, parfois de boucles de réflexion. Une minute d’un agent « long cours » peut coûter bien plus cher qu’une requête de FAQ. Optimiser l’inférence, c’est donc optimiser le passage à l’échelle, et éviter l’effet “facture surprise” 💸.

AgentOps : traiter les agents comme des workloads critiques (et non comme des gadgets)

Le point le plus enthousiasmant, parce qu’il est profondément industriel, tient au volet AgentOps. Red Hat pousse l’idée que les agents doivent être gérés comme on gère des services critiques : cycle de vie, identités, audit, observabilité. Cette bascule culturelle est décisive. Un agent n’est pas seulement un « assistant » : c’est un acteur qui peut déclencher des actions. Et dès qu’il agit, il doit être soumis aux mêmes exigences qu’une application de paiement ou qu’un outil d’administration.

Dans les environnements régulés, la traçabilité devient le graal : journaliser les appels, comprendre quel outil a été utilisé, quelles données ont été consultées, et sur quelles bases l’agent a produit une recommandation. Cela rejoint une inquiétude très concrète : la falsification de contenus et de preuves par IA. Les entreprises veulent savoir si un document a été modifié, si une justification a été « inventée », ou si une action a été effectuée sur de mauvaises hypothèses. Sur ce sujet, l’éclairage de l’essor des documents falsifiés par IA rappelle que l’audit n’est plus une option, mais une ceinture de sécurité.

Dans le cas d’AtelierNova, un agent de support pourrait analyser des logs et proposer un correctif. Très bien. Mais qui prouve que ce correctif est cohérent, qu’il n’a pas exfiltré d’informations, qu’il n’a pas touché des secrets d’infrastructure ? Red Hat place au centre des notions comme l’identité cryptographique de l’agent et la capacité à reconstruire une chronologie fiable. C’est exactement le type de mécanisme qui transforme une expérimentation en produit durable.

Un repère utile : ce qu’une DSI doit exiger d’une plateforme agentique

Pour éviter le flou, voici une liste de critères concrets que le Summit remet sous les projecteurs. Elle sert de check-list pour distinguer l’agentique « show » de l’agentique « run » :

• 🧭 Gouvernance des modèles : catalogue, approbations, politiques d’usage, quotas.
• 🔍 Observabilité : métriques, traces, journaux, corrélation avec incidents.
• 🧾 Audit des actions : qui a fait quoi, avec quel outil, et à quel moment.
• 🔐 Identité et secrets : authentification forte, gestion des clés, rotation.
• 🧯 Mécanismes d’arrêt : kill switch, limites, validation humaine si nécessaire.
• 📦 Portabilité : éviter l’enfermement, conserver la capacité d’arbitrer.

Cette grille a un mérite : elle transforme l’IA agentique en discipline d’exploitation. Et quand l’exploitation entre dans la danse, la question suivante surgit naturellement : quelles fondations matérielles et logicielles permettent de sécuriser et d’isoler ces agents, surtout lorsqu’ils consomment du GPU et qu’ils manipulent des données sensibles ? La réponse prend le nom d’un partenariat clé : l’AI Factory avec NVIDIA.

Pour approfondir les annonces, une recherche vidéo sur les temps forts du Summit aide à visualiser les démonstrations et les retours d’expérience.

Red Hat AI Factory with NVIDIA : isolation, confidential computing et exécution durable des agents IA en cloud hybride

Le partenariat Red Hat AI Factory with NVIDIA vise un point souvent sous-estimé : l’agentique devient réellement intéressante quand elle est durable, outillée, et branchée sur des systèmes réels. Or, dès qu’un agent interagit avec des données sensibles (RH, finance, production) ou des environnements critiques (automates, supervision, ticketing), la discussion se déplace vers l’isolation, la segmentation et la confiance. Ici, l’objectif n’est pas seulement de « faire tourner » de l’IA, mais de la faire tourner en toute confiance dans des environnements hybrides, parfois contraints, parfois souverains. 🛡️

La promesse est de fusionner les apports de Red Hat AI et de NVIDIA Enterprise AI pour fournir une base logicielle robuste : prise en charge des accélérateurs, outillage d’inférence, politiques de sécurité, mécanismes de confidential computing. Le Summit a particulièrement insisté sur la capacité à mettre des barrières autour des agents : conteneurs confidentiels, sandboxing, et protections bas niveau. Le vocabulaire n’est pas décoratif : il décrit une réalité où l’agent devient un composant qui doit être « enfermé proprement » pour mieux être libéré là où c’est utile.

Quand la sécurité devient une propriété de l’infrastructure

Dans un scénario AtelierNova, un agent d’optimisation logistique pourrait traiter des historiques de production et des données fournisseur. Ces informations sont stratégiques. La question n’est pas seulement « l’agent est-il performant ? », mais « les données sont-elles protégées pendant le traitement ? ». Le confidential computing répond précisément à cette inquiétude : protéger la donnée non seulement au repos et en transit, mais aussi en mémoire pendant l’exécution. C’est un changement de paradigme qui colle parfaitement à l’agentique, car les agents manipulent beaucoup de contexte.

À cela s’ajoutent des briques de durcissement déjà bien connues des équipes infrastructure : SELinux, le mode FIPS pour les environnements exigeants, et des protections côté NVIDIA (notamment autour de DOCA). Le résultat recherché est une chaîne d’exécution où l’agent n’est jamais « tout-puissant ». Il est performant, mais encadré. Autonomie oui, impunité non ✅.

API compatibles et traçabilité : le nerf de la guerre en production

Pour accélérer l’adoption, la Factory met en avant des API compatibles OpenAI. Cela peut sembler anodin, mais c’est un accélérateur industriel : les applications et agents existants peuvent migrer ou basculer plus facilement, sans réécrire chaque intégration. Toutefois, le Summit a surtout insisté sur ce que ces API doivent transporter en plus : de la traçabilité, des logs d’appels, des détails d’étapes de raisonnement (quand c’est possible), et des éléments permettant l’audit.

Cette discipline s’inscrit dans une réalité cyber inquiétante : la surface d’attaque explose quand l’IA génère du code, assemble des dépendances et manipule des secrets. Les incidents récents autour de plateformes de distribution ou de communautés techniques rappellent que le risque supply chain n’est pas théorique. Une lecture parallèle de cas d’attaque illustrant la mécanique des intrusions aide à comprendre pourquoi les entreprises veulent des environnements cloisonnés, surveillés, et réversibles.

Tableau : ce que l’AI Factory vise à stabiliser dans un projet agentique

🔧 Dimension	🎯 Problème terrain	✅ Réponse visée par l’AI Factory
🧠 Inference	Coûts et latence quand les agents enchaînent des appels	Optimisation et distribution via moteurs adaptés et architecture gouvernée
🔐 Isolation	Un agent ne doit pas voir tout le SI	Sandbox, conteneurs confidentiels, segmentation forte
🧾 Audit	Qui prouve ce qu’a fait l’agent ?	Traçabilité des appels LLM, des outils et des actions
🧰 Portabilité	Risque d’enfermement sur une pile unique	Standards, open source, API compatibles et exécution hybride
🧯 Conformité	Contraintes secteur (santé, industrie, défense)	Durcissement, FIPS, politiques et contrôles continus

Ce tableau met en évidence un point essentiel : l’agentique n’est pas une fonctionnalité, c’est une chaîne complète à stabiliser. Et pour stabiliser une chaîne, il faut aussi s’occuper de là où naît le code et de la façon dont il est assemblé. Ce basculement amène naturellement vers le sujet développeurs, où Red Hat a été particulièrement offensif.

Développeurs et supply chain : Red Hat Desktop, trusted software factory et Fedora Hummingbird pour l’ère des agents codeurs

La fabrique logicielle est en pleine accélération : les agents écrivent du code, proposent des correctifs, génèrent des tests, modifient des configurations. C’est grisant… et dangereux. Chaque gain de vitesse ajoute une couche de risque : dépendances non maîtrisées, composants compromis, bibliothèques obsolètes, secrets exposés. Red Hat a donc consacré une part majeure du Summit à l’outillage développeur, avec une promesse très claire : accélérer sans fragiliser 🚀.

Red Hat Desktop (avec support commercial du build Red Hat de Podman Desktop) incarne cette volonté de rapprocher les environnements locaux de la production OpenShift. Pour les équipes, cela réduit les surprises du type « ça marche sur mon poste ». Pour AtelierNova, c’est aussi un moyen de standardiser les pratiques : mêmes images de base, mêmes règles, mêmes contrôles. Le Summit a également mis en avant l’idée de sandboxing local pour exécuter et observer des agents dans un environnement isolé avant qu’ils n’approchent des ressources sensibles.

Advanced Developer Suite : verrouiller la chaîne sans étouffer l’open source

La suite se renforce autour de trois éléments qui, combinés, ressemblent à une stratégie anti-chaos :

• 🏭 Trusted software factory : une chaîne de build plus contrôlée, avec signature et contrôles automatiques.
• 📚 Trusted Libraries : un catalogue de bibliothèques prévalidées pour éviter le “copier-coller Internet”.
• 🧠 Exploit intelligence : prioriser les vulnérabilités réellement exploitables, plutôt que subir des listes de CVE interminables.

Dans la vie réelle, ce trio répond à une scène désormais banale : une équipe sécurité reçoit 800 alertes, une équipe produit doit livrer, et personne ne sait quelles failles sont concrètement exploitables dans le contexte. L’intelligence « orientée exploitation » vise à remettre du sens dans le bruit. On retrouve le même esprit que dans l’agentique : ne pas se contenter de produire, mais rendre l’ensemble opérationnel et défendable.

Cette obsession de la chaîne logicielle rejoint un besoin culturel : développer vite, oui, mais avec une hygiène technique accessible. Certains outils et communautés open source jouent déjà ce rôle de “filtre” côté poste de travail. Pour prolonger cette logique, il est pertinent de regarder aussi des alternatives maîtrisées côté distribution applicative, comme F-Droid et ses applications open source, qui incarnent une philosophie de sélection, de transparence et de contrôle. Même si le contexte est mobile, l’idée de base — réduire l’exposition à l’aléatoire — résonne fortement avec la supply chain d’entreprise.

Fedora Hummingbird : quand le système d’exploitation vise aussi les agents

L’annonce la plus surprenante, et probablement la plus révélatrice, reste Fedora Hummingbird Linux. Cette distribution pensée par images système et mises à jour continues vise des environnements conteneurisés modernes. Mais le twist est ailleurs : elle cible explicitement l’IA agentique, y compris des agents capables de préparer eux-mêmes leur environnement de travail.

Il faut mesurer la portée de ce changement. Historiquement, un OS de développement est conçu pour un humain : installation, configuration, réglages, préférences. Avec Hummingbird, Red Hat et la communauté Fedora anticipent un monde où un agent peut instancier un environnement reproductible en quelques instants, tirer la bonne image, installer les dépendances, lancer des tests, produire une preuve de concept. Ce n’est pas une fantaisie : dans une grande entreprise, la perte de temps liée aux environnements hétérogènes est massive. Si un agent réduit ce temps tout en restant dans un cadre maîtrisé, l’impact est immédiat.

Pour AtelierNova, cela signifie qu’un agent interne pourrait créer un “bac à sable” de développement pour un nouveau microservice, y intégrer les bibliothèques approuvées, exécuter des tests de sécurité et proposer une MR (merge request) conforme. Tout l’enjeu est de garder un contrôle sur ce que l’agent a fait. Et cela renvoie au prochain pilier : l’automatisation d’infrastructure, là où Red Hat propose un garde-fou très concret avec Ansible.

Pour mettre des images et des voix sur ces sujets, une deuxième recherche vidéo est utile : on y retrouve souvent des retours d’expérience de développeurs et d’architectes sur la sécurisation du cycle de vie.

Ansible, RHEL et OpenShift : la couche d’exécution de confiance pour automatiser, virtualiser et limiter la dérive opérationnelle

Quand l’IA agentique arrive, l’infrastructure redevient stratégiquement visible. Longtemps, beaucoup d’entreprises ont vécu sur un compromis : une plateforme stable, quelques scripts d’automatisation, et une migration progressive vers le cloud. Désormais, les agents introduisent une pression nouvelle : ils peuvent déclencher des actions à une vitesse qui dépasse les processus humains. Sans cadre, c’est la recette d’une panne rapide… ou d’un incident de sécurité. Red Hat a donc repositionné ses fondamentaux comme un système nerveux prêt pour l’ère agentique : Ansible pour exécuter, RHEL pour stabiliser et sécuriser, OpenShift pour orchestrer et hybrider. 🧩

Ansible Automation Platform 2.7 : l’agent propose, Ansible exécute

Avec Ansible Automation Platform 2.7, l’objectif est de synchroniser plusieurs styles d’automatisation : déterministe (playbooks), événementielle (réactions à des alertes), et workflows enrichis par IA. Une préversion technologique d’automation orchestrator vise des scénarios plus complexes, où une alerte peut déclencher une analyse, une décision, une validation humaine, puis une action. Cela ressemble à une chaîne d’assemblage : chaque étape est contrôlée, traçable, et reproductible.

Un ajout clé est l’apparition d’un serveur MCP destiné à connecter des agents IA aux playbooks existants. C’est un point crucial, car il évite de réinventer l’intégration à chaque fois. Dans AtelierNova, l’agent de support peut diagnostiquer un incident et suggérer une remédiation, mais la remédiation passe par Ansible, qui impose des garde-fous : inventaire, droits, logs, contrôle de conformité. Résultat : l’agent devient un “cerveau” d’analyse, tandis qu’Ansible reste le “bras” contrôlé. Cette séparation est une idée simple, mais extraordinairement efficace 💡.

RHEL 10.2 et 9.8 : cryptographie post-quantique, confidential computing et réduction de la dérive

Sur le socle Linux, les futures versions RHEL 10.2 et RHEL 9.8 mettent en avant des avancées majeures : meilleure prise en charge de la cryptographie post-quantique, progression du confidential computing, et davantage d’automatisation assistée pour configurer et corriger plus vite. Le thème de la dérive opérationnelle est particulièrement parlant : au fil des mois, l’écart entre ce qui est documenté et ce qui tourne réellement en production devient un risque. Avec l’agentique, ce risque s’amplifie, car l’exécution s’accélère. Réduire la dérive, c’est réduire l’imprévisible.

Le Summit a aussi insisté sur des cycles de support adaptés aux environnements qui ne peuvent pas migrer au rythme habituel. Le Long-Life Add-On répond à des secteurs comme l’industrie, les télécoms, la santé ou les infrastructures critiques. Dans AtelierNova, une chaîne de production ne se met pas à jour comme un smartphone. Avoir un support étendu annualisé, c’est rendre possible une stratégie d’IA en gardant un socle stable.

Images durcies et stratégie Zero-CVE : le retour des fondamentaux… en plus exigeant

Red Hat Hardened Images (disponibles en disponibilité générale) ciblent une réduction drastique de la surface d’attaque, avec une logique « minimaliste et durcie ». Dans un monde où l’IA augmente la quantité de code et de dépendances, l’image de base redevient un point de contrôle central. Le bénéfice est double : moins de composants inutiles, et une capacité plus forte à prouver l’état de sécurité d’un déploiement.

Cette approche fait écho à des pratiques plus “terrain” côté poste client : nettoyer l’excès, limiter le bruit, maîtriser ce qui est installé. La même philosophie se retrouve dans des démarches de rationalisation comme le debloat de Windows 11, transposée ici à l’échelle des conteneurs et de la production : réduire pour sécuriser.

OpenShift Virtualization : un pont entre VM, conteneurs et workloads IA

OpenShift reste la colonne vertébrale, et la virtualisation y joue un rôle stratégique, notamment dans un marché en recomposition. L’enjeu est de permettre une coexistence : VM existantes, applications conteneurisées, et charges IA plus gourmandes. Dans la pratique, c’est un accélérateur de modernisation : on migre sans tout casser, on consolide l’exploitation, on prépare l’avenir.

Le fait qu’IBM annonce des services managés autour de l’inférence IA gouvernée et de la virtualisation sur OpenShift souligne ce mouvement : le socle devient une plateforme d’industrialisation. Et cette industrialisation se prolongera naturellement vers une question politique et juridique : comment garder le contrôle quand les déploiements sont hybrides, multicloud, et parfois soumis à des exigences nationales ? C’est précisément le terrain de la souveraineté, abordée ici comme une affaire d’architecture plutôt que de slogans.

Souveraineté et cloud hybride : contrôle architectural, portabilité et extension jusqu’à l’edge… et l’orbite

La souveraineté a été omniprésente, mais traitée de manière concrète : pas comme un badge marketing, plutôt comme un ensemble de capacités permettant de déployer, administrer, auditer et évoluer sur l’infrastructure de son choix. Red Hat s’aligne sur une vision proche de celle d’IBM : la souveraineté se gagne par la pile logicielle, par la maîtrise des clés, des identités, des journaux, et par la portabilité. Cela ne résout pas à lui seul tous les sujets juridiques, mais cela donne aux organisations des leviers opérationnels immédiats 🔐.

Pour AtelierNova, l’enjeu est très clair : certaines données et certains modèles doivent rester sur site, d’autres charges peuvent partir dans un cloud public, et certaines filiales doivent utiliser des fournisseurs locaux. L’entreprise veut éviter que l’IA agentique devienne une nouvelle prison propriétaire. La promesse Red Hat consiste à fournir une couche cohérente — RHEL/OpenShift/Ansible/Red Hat AI — capable de tourner on-prem, chez des hyperscalers, ou dans des clouds qualifiés, sans perdre l’unité d’administration.

Une souveraineté qui se prouve : identités, journaux, politiques et réversibilité

Ce qui change avec l’agentique, c’est que la souveraineté n’est plus seulement une question de localisation des données. Elle devient une question de capacité à prouver : prouver qui a accédé à quoi, prouver quelles actions ont été exécutées, prouver que les politiques ont été respectées. Sans cela, impossible de convaincre un régulateur, un client industriel, ou une direction des risques.

Dans cette logique, la portabilité est une arme anti-dépendance. Elle permet d’arbitrer : déplacer un workload, changer de fournisseur, répartir les traitements. Et cela devient critique dès que les coûts GPU, l’accès à l’énergie ou les contraintes réglementaires changent. Dans un univers mouvant, la souveraineté est aussi une assurance économique.

Edge durci : Device Edge préchargé pour les environnements contraints

Le Summit a également montré que l’exécution ne se limite plus aux datacenters. Avec Panasonic Connect, Red Hat Device Edge sera préchargé sur des terminaux TOUGHBOOK destinés à des usages industriels, gouvernementaux ou manufacturiers. La promesse : traiter localement des données, parfois en environnement déconnecté, avec une plateforme durcie.

Pour AtelierNova, c’est un cas d’école : un site de production en zone blanche réseau peut avoir besoin d’un agent local pour diagnostiquer des anomalies, guider un technicien, ou corréler des capteurs. Tout remonter au cloud n’est pas réaliste. L’edge devient donc une extension du cloud hybride, avec ses propres exigences de sécurité et de maintenance.

De l’edge terrestre à l’orbite : RHEL et UBI dans un micro-datacenter à bord de l’ISS

Le moment le plus spectaculaire reste l’annonce avec Voyager Technologies : le déploiement de RHEL 10.1 et de la Red Hat Universal Base Image dans le micro-datacenter Space Edge à bord de la Station spatiale internationale. L’objectif affiché : rapprocher calcul, IA et pratiques DevSecOps des données produites en orbite. Symboliquement, c’est puissant : le cloud hybride ne s’arrête plus au datacenter, ni même à l’edge. Il s’étend jusqu’à l’orbite basse 🛰️.

Au-delà de la vitrine, le message est clair : si la pile peut fonctionner dans des conditions extrêmes, elle peut aussi être standardisée pour des environnements industriels exigeants. Et cela boucle la boucle : l’IA agentique devient un phénomène industriel dès lors qu’elle s’appuie sur une exécution standardisée, gouvernée et portable. La dynamique de l’open source, ici, n’est pas romantique : elle est stratégique.