Un document de position affirmant que la conteneurisation au niveau du système d'exploitation, dont Docker est l'exemple canonique, n'est pas simplement un choix d'outils utile, mais une technologie fondamentale pour la convergence des technologies opérationnelles et informatiques. L’argument s’attaque directement aux objections les plus fortes et conclut qu’elles sont traitables plutôt que disqualifiantes.
Préambule
Un scepticisme persistant entoure l’introduction des conteneurs dans les environnements industriels. Les objections sont familières : les systèmes industriels ont des cycles de vie mesurés en décennies, et non des cycles de déploiement mesurés en minutes ; les exigences de performances en temps réel ne peuvent pas tolérer l'imprévisibilité d'un environnement d'exécution à usage général ; les implications en matière de sécurité de l'exécution d'un noyau Linux exposé à des dizaines de conteneurs ne sont pas suffisamment comprises ; la maturité opérationnelle du personnel chargé des technologies opérationnelles (OT) ne correspond pas à la complexité opérationnelle des outils cloud natifs modernes.
Chacune de ces objections a une part de vérité. Aucun d’entre eux, affirme cet article, ne résiste à un examen sérieux.
La thèse est directe : la conteneurisation au niveau du système d’exploitation – dont Docker est l’exemple canonique – est le bon substrat fondamental pour les logiciels industriels. Son adoption n’est pas une question de mode mais de nécessité architecturale. Les alternatives sont pires. Les objections, bien que réelles, identifient des problèmes d'ingénierie avec des solutions connues plutôt que des incompatibilités fondamentales.
Cet article se déroule en huit sections. Le premier établit ce que Docker est techniquement, en distinguant la technologie de la surface marketing. La seconde situe les conteneurs dans leur lignée historique pour dissiper l’impression qu’il s’agit d’une technologie nouvelle et non éprouvée. La troisième caractérise la problématique du déploiement de logiciels industriels pour laquelle les conteneurs sont particulièrement bien adaptés. Le quatrième argument avance dans l’affirmative. La cinquième affronte les principales objections. Le sixième décrit les modèles architecturaux qui ont émergé dans les déploiements industriels de production. La septième examine les problèmes ouverts et les conditions d’une adoption responsable. Le huitième réitère et défend la revendication centrale.
Le public visé est l'architecte ou le responsable de l'ingénierie qui se demande s'il convient d'engager une gamme de produits industriels dans une infrastructure conteneurisée. Cet argument se veut utile précisément parce qu’il ne flatte pas la technologie.
Qu'est-ce que Docker en réalité
Un argument propre nécessite un objet propre. Docker est un terme très surchargé, et une confusion substantielle dans les discussions industrielles sur les conteneurs est directement due à l'imprécision sur ce qui est discuté.
Au sens strict, Docker fait référence à une implémentation particulière de la virtualisation au niveau du système d'exploitation sous Linux, initialement publiée en 2013 par dotCloud (plus tard Docker, Inc.) [1]. Dans la pratique actuelle, le terme englobe plusieurs composants distinctifs : un environnement d'exécution de conteneur (à l'origine "libcontainer", plus tard "containerd" et "runc"), un format d'image et un protocole de registre, un outil de ligne de commande et une architecture de démon.
Les primitives techniques sous-jacentes sont des fonctionnalités du noyau, et non des inventions spécifiques à Docker :
Les espaces de noms Linux [2] fournissent une isolation des ressources système au niveau du processus. Les sept types d'espaces de noms — PID, réseau, montage, UTS, IPC, utilisateur et groupe de contrôle — permettent collectivement à un groupe de processus de fonctionner dans une vue isolée des identifiants de processus, des interfaces réseau, des montages de système de fichiers, du nom d'hôte et du domaine, des canaux de communication inter-processus, des identifiants d'utilisateur et de groupe et des hiérarchies de groupes de contrôle. Un conteneur est, au niveau du noyau, une arborescence de processus dont l'état visible du système est contraint par ces espaces de noms.
Les groupes de contrôle (cgroups) [3], développés à l'origine chez Google et fusionnés dans le noyau Linux en 2007, assurent la comptabilité et la limitation des ressources. Les partages de processeur, les limites de mémoire, la bande passante d'E/S et l'accès aux périphériques peuvent être limités par groupe de processus. cgroups v2, la hiérarchie unifiée introduite dans le noyau 4.5 (2016) et devenue la hiérarchie par défaut dans la plupart des distributions d'ici 2021, a considérablement amélioré le modèle de contrôle des ressources.
OverlayFS [4] et les systèmes de fichiers Union similaires activent le modèle d'image en couches qui distingue Docker des systèmes de conteneurs antérieurs. Une image est une pile de calques en lecture seule ; un conteneur en cours d'exécution ajoute une couche inscriptible par-dessus. Des couches identiques sont partagées entre les conteneurs et entre les hôtes, ce qui permet d'obtenir une efficacité de stockage et de réseau substantielle.
Le stockage adressable par le contenu des couches d'images, identifiées par hachage cryptographique, permet une garantie sans équivalent dans les modèles de déploiement traditionnels : la reproductibilité octet par octet de l'artefact déployé. L'image identifiée par « sha256:abc... » sur le poste de travail d'un développeur est bit-identique à l'image identifiée par le même hachage sur une passerelle de production, quel que soit le moment ou l'endroit où elle est extraite.
Ces primitives ne sont pas des inventions de Docker. Il s'agit de fonctionnalités du noyau Linux que Docker a assemblées dans un produit. Leur existence et leur stabilité sont bien antérieures à l’adoption populaire des conteneurs, et ils sont désormais régis par une spécification ouverte.
Depuis 2015, l'écosystème des conteneurs a été standardisé dans le cadre de l'Open Container Initiative (OCI) [5], produisant trois spécifications : la spécification d'exécution, la spécification d'image et la spécification de distribution. La conséquence pratique est que la société Docker est désormais un implémenteur parmi plusieurs d'un standard ouvert, et les environnements d'exécution de conteneurs utilisés en production - containersd, CRI-O, Podman - interagissent via ces spécifications. « Utiliser Docker » en 2025, c'est utiliser des conteneurs OCI ; la marque et la technologie se sont découplées.
Cette homonymie est importante car les objections à Docker portent souvent soit sur l'entreprise, soit sur l'architecture démoniaque historique, soit sur les outils périphériques, plutôt que sur les primitives techniques sous-jacentes, qui constituent la substance durable de l'argument.
La lignée historique de la conteneurisation
Les conteneurs ne sont pas nouveaux. Le récit populaire qui situe leur origine dans la version 2013 de Docker obscurcit une lignée de quatre décennies qui affecte matériellement la façon dont la technologie devrait être évaluée pour une utilisation industrielle. Une technologie mature avec un long pedigree mérite une norme de preuve différente de celle de la technologie émergente, et les conteneurs sont sans ambiguïté la première.
La lignée commence par « chroot », introduit dans la version 7 d'Unix en 1979 [6]. chroot permettait à un processus d'être confiné à un sous-arbre du système de fichiers, la première primitive d'isolation systématique au niveau du système de fichiers largement utilisée. Ses limites en matière de sécurité ont été reconnues très tôt — « chroot » n'a jamais été conçu comme une limite de sécurité — mais il a établi la base conceptuelle de la virtualisation du système de fichiers.
FreeBSD Jails [7], introduit en 2000 par Poul-Henning Kamp et Robert Watson à la demande d'un fournisseur d'hébergement, a étendu le « chroot » avec une isolation des processus et du réseau, produisant ce qui était reconnaissable comme un conteneur au sens moderne du terme. Les prisons ont été conçues dès le départ comme barrière de sécurité et sont utilisées dans la production depuis près d’un quart de siècle. Leur adoption dans les appareils réseau (pfSense, opnSense, NetApp) fournit un long historique de conteneurs dans des rôles critiques.
Solaris Zones [8], lancé en 2004, offrait une conteneurisation de qualité commerciale avec de solides garanties d'isolation, intégrée à Solaris Service Management Facility et utilisée dans la production d'entreprise dès son lancement. L'investissement d'ingénierie de Sun Microsystems dans Zones a été substantiel et la technologie a été déployée dans des environnements (commutateurs de télécommunications, systèmes de transactions financières) au moins aussi critiques que les déploiements industriels classiques.
Les conteneurs Linux (LXC) [9], apparus à partir d'environ 2008, ont apporté la fonctionnalité de conteneur à Linux via les primitives d'espaces de noms et de groupes de contrôle évoquées ci-dessus. LXC était l'antécédent technique direct de Docker ; les premières versions de Docker étaient, en fait, une couche d'expérience de développeur sur LXC.
La contribution de Docker en 2013 ne constituait pas une nouveauté technique au sens du noyau. Les espaces de noms existaient depuis des années ; les groupes de contrôle ont été fusionnés en 2007. La contribution de Docker était le format d'image, le protocole de registre et une expérience de développement qui rendait les primitives du noyau existantes accessibles aux développeurs d'applications ordinaires. La technologie avait trente-cinq ans lorsque Docker l'a rendue utilisable.
Le système Borg de Google [10], le précurseur de Kubernetes, faisait fonctionner l'ensemble de la flotte de production de Google sur des conteneurs depuis environ 2003, soit une décennie avant l'existence de Docker. Au moment où Docker a atteint la version 1.0 en 2014, Google exécutait des milliards de conteneurs par semaine. L’argument selon lequel la technologie des conteneurs n’a pas fait ses preuves dans la production à grande échelle se heurte à ce constat empirique.
Pour l’adoption industrielle, la question pertinente n’est pas de savoir si la technologie est mature – c’est manifestement le cas – mais si les modèles de déploiement spécifiques à l’industrie sont matures. Cette question est abordée dans la section 6.
Le problème du déploiement de logiciels industriels
Pour plaider en faveur des conteneurs dans l’industrie, le problème que les conteneurs résolvent doit être caractérisé avec précision. Le déploiement de logiciels industriels a historiquement été affecté par un ensemble de pathologies qui ne sont pas accessoires au contexte industriel mais découlent directement de ses caractéristiques structurelles.
Les longs cycles de vie des équipements produisent une dérive de dépendance. Un contrôleur industriel déployé en 2010 pourrait encore être opérationnel en 2030, soit une durée de vie de deux décennies. L’environnement logiciel de 2010 n’est cependant pas celui de 2030. Les versions des bibliothèques, les chaînes d’outils du compilateur, les interpréteurs d’exécution et les noyaux du système d’exploitation évoluent tous. La réponse conventionnelle – geler l’intégralité de la pile au moment du déploiement – produit un artefact impossible à maintenir : le contrôleur peut exécuter son logiciel d’origine, mais ne peut pas être mis à jour, corrigé ou modifié en toute sécurité sans risquer de rompre les dépendances de manière imprévisible. C'est le problème de la dérive des dépendances.
Les cibles de déploiement hétérogènes multiplient la complexité de l'intégration. Un logiciel industriel peut être nécessaire pour fonctionner sur une demi-douzaine de plates-formes cibles : différentes architectures SoC, différentes distributions Linux, différentes versions de noyau, différentes versions de glibc. La combinatoire consistant à tester chaque modification logicielle sur chaque plate-forme cible est insoluble sans une forte isolation entre l'application et son environnement hôte. Sans isolement, les tests d'intégration doivent être exhaustifs ; avec l'isolement, il peut être sélectif.
Les mécanismes de mise à jour ont toujours été fragiles. La mise à jour industrielle conventionnelle (une image du micrologiciel flashée sur un stockage flash, avec une restauration nécessitant généralement un accès physique) ne prend pas en charge les mises à jour granulaires, fréquentes et observables qu'exigent les postures de sécurité modernes. Des vulnérabilités critiques apparaissent désormais et nécessitent des correctifs dans des délais allant de quelques jours à quelques semaines ; Les cycles de mise à jour des micrologiciels industriels mesurés en mois ou en années sont de moins en moins adaptés aux modèles de menaces.
La reproductibilité est essentielle sur le plan opérationnel mais techniquement insaisissable. Lorsqu'un système industriel tombe en panne, le processus de diagnostic nécessite de reproduire la panne dans un environnement contrôlé. Si l'environnement logiciel du système de production ne peut pas être reproduit exactement (parce qu'il a été construit à partir d'une combinaison particulière de versions de bibliothèque, de fichiers de configuration et d'état d'exécution que personne n'a entièrement documenté), le diagnostic devient archéologique. C'est la crise de reproductibilité appliquée aux logiciels industriels, et elle a coûté cher à l'industrie en temps de réponse aux incidents.
La frontière entre application et système d'exploitation s'est érodée. Les applications industrielles modernes dépendent d'une part substantielle de l'environnement d'exploitation : bibliothèques spécifiques, modules de noyau spécifiques, unités systemd spécifiques, configurations de système de fichiers spécifiques. Le modèle historique — « déployer l'application, le système d'exploitation est le problème de quelqu'un d'autre » — ne correspond pas à la réalité opérationnelle, où les applications et leurs dépendances sont étroitement liées et doivent être déployées ensemble.
Chacune de ces pathologies peut, en principe, être traitée uniquement par une discipline d'ingénierie minutieuse. En pratique, l’étude empirique des logiciels industriels montre que la discipline de l’ingénierie à elle seule est insuffisante, car les pathologies sont structurellement produites par le décalage entre l’application et son environnement. Les conteneurs comblent cette lacune en déployant l'application avec ses dépendances comme un seul artefact immuable. Il ne s’agit pas d’une préférence stylistique ; c'est un remède structurel à un problème structurel.
Le cas affirmatif
Une fois le problème caractérisé, les arguments en faveur des conteneurs dans les logiciels industriels peuvent être avancés pour six raisons.
Container suitability for industrial software criteria
bar chart4.1 Reproductibilité cryptographique
L'image identifiée par un résumé SHA-256 spécifique est identique en termes de bits sur chaque hôte qui l'extrait. Il s’agit d’une garantie plus solide que n’importe quel mécanisme de déploiement conventionnel. Lorsqu'un incident survient en production, l'environnement logiciel exact dans lequel l'incident s'est produit peut être reproduit — sur un poste de travail de développeur, dans un environnement de test, lors d'un audit réglementaire — avec une certitude mathématique.
La valeur diagnostique de cette garantie est difficile à surestimer. Le coût des diagnostics « impossibles à reproduire » dans la réponse aux incidents industriels est, d'après l'expérience de chaque praticien, substantiel. La reproductibilité cryptographique élimine ce mode de défaillance de la couche logicielle, ne laissant que les facteurs environnementaux véritablement difficiles à reproduire (bruit des capteurs, interférences électromagnétiques, usure mécanique) comme sources restantes d'irreproductibilité.
La même garantie soutient la conformité et l’audit. Lorsqu'un déploiement industriel doit démontrer, à des fins réglementaires, que le logiciel exécuté sur le terrain est exactement le logiciel qui a été validé et approuvé, le résumé d'image fournit cette démonstration sous une forme qui résiste cryptographiquement à la falsification.
4.2 Déploiement atomique et restauration
Les mises à jour industrielles conventionnelles ont la propriété de ne pas être directement annulées. Une mise à jour du micrologiciel qui s'avère problématique en production nécessite soit un accès physique pour le re-flash, soit un mécanisme de mise à jour complexe comprenant des partitions A/B et une prise en charge explicite de la restauration - et même ces mécanismes sont généralement tout ou rien au niveau du micrologiciel.
Le déploiement de conteneurs est atomique au niveau de la granularité de la charge de travail individuelle. Une nouvelle image de conteneur est extraite, validée et démarrée ; l'ancienne image est arrêtée. Si la nouvelle image échoue à l’une de ses vérifications d’état, la transition est annulée. L'état du système à la fin d'un déploiement ayant échoué est identique à son état au début du déploiement.
Cette propriété a des conséquences opérationnelles importantes. Il permet des cadences de mise à jour agressives sans augmentation proportionnelle du risque opérationnel. Il permet des déploiements Canary – en testant une nouvelle image sur un sous-ensemble de la flotte avant un déploiement plus large. Il permet une restauration automatique en réponse aux signaux de télémétrie. Aucun de ces modèles n'est réalisable avec les mécanismes conventionnels de mise à jour du micrologiciel.
4.3 Isolement des dépendances
Chaque conteneur porte ses propres dépendances. Deux conteneurs sur le même hôte peuvent dépendre de versions incompatibles de la même bibliothèque, et les deux fonctionneront correctement. Le système d'exploitation hôte doit uniquement fournir le noyau ; les dépendances de l'espace utilisateur sont encapsulées dans l'image.
L'importance industrielle de cette propriété réside dans le fait qu'une passerelle industrielle peut héberger plusieurs applications - peut-être développées par différents fournisseurs, peut-être déployées à des moments différents, peut-être en fonction de différentes versions de bibliothèques communes - sans la complexité d'intégration qui accompagne historiquement une telle co-résidence. Le déploiement d'une nouvelle application ne risque pas de casser les applications existantes, car les dépendances n'interagissent pas.
Il s’agit du catalyseur structurel du modèle de marché d’applications tenté, avec un succès limité, pour les contrôleurs industriels depuis plusieurs décennies. La distribution d'applications basées sur des conteneurs rend le marché réalisable car le problème d'intégration – historiquement le principal obstacle – est en grande partie résolu.
4.4 Portabilité de la charge de travail
Une image de conteneur qui s'exécute dans l'environnement local d'un développeur s'exécute, avec une haute fidélité, sur une passerelle de production. La même image s'exécute sur un serveur x86 dans un centre de données ou sur une passerelle industrielle basée sur ARM, étant donné une image multi-architecture. L’environnement d’exécution est largement invariant selon les contextes de déploiement.
Cette portabilité a deux conséquences importantes pour les logiciels industriels. Premièrement, il élimine une classe importante de bogues d’intégration, ceux causés par les différences entre les environnements de développement et de production. Deuxièmement, cela fait de la frontière entre cloud et edge une décision de déploiement plutôt qu'une décision architecturale. La même charge de travail peut s'exécuter dans n'importe quel emplacement, et l'emplacement peut être modifié sans modification du code. Il s’agit du catalyseur pratique de la co-conception Edge-Cloud [11], dans laquelle les charges de travail migrent entre les niveaux en fonction des besoins opérationnels.
4.5 Améliorations de la sécurité par rapport au déploiement sans système d'exploitation
Une idée fausse fréquente considère les conteneurs comme une limite de sécurité plus faible que les machines virtuelles et conclut que les conteneurs représentent une régression en matière de sécurité. La comparaison est correcte mais la conclusion est fausse, car la comparaison pertinente n'est pas conteneur contre VM mais conteneur contre non-conteneur — c'est-à-dire que l'alternative historique au déploiement industriel conteneurisé n'est pas le déploiement virtualisé ; il s’agit d’un déploiement nu sans isolation.
Par rapport à cette référence historique, les conteneurs constituent sans ambiguïté une amélioration. Ils fournissent :
La publication spéciale NIST 800-190 [12] fournit une référence faisant autorité pour la configuration de la sécurité des conteneurs dans les environnements réglementés. Les conteneurs correctement configurés, avec exécution sans racine, suppression de capacités, filtrage seccomp et analyse d'images, représentent une posture de sécurité nettement plus forte que les déploiements industriels sans système d'exploitation qu'ils remplacent.
La préoccupation légitime – à savoir que le noyau constitue une surface d’attaque plus grande qu’un hyperviseur – s’applique dans des circonstances restreintes et est abordée dans la section 5.
- Isolation des processus via des espaces de noms, empêchant les interférences accidentelles ou malveillantes entre les applications co-résidentes.
- Limites de ressources via les groupes de contrôle, empêchant une seule application d'épuiser les ressources de l'hôte.
- Suppression de fonctionnalités, supprimant par défaut les fonctionnalités Linux dangereuses des processus de conteneur.
- Systèmes de fichiers racine en lecture seule, éliminant une classe majeure de persistance post-exploitation.
- Filtres Seccomp, limitant les appels système disponibles à un processus conteneurisé.
- Intégration AppArmor et SELinux, fournissant des contrôles d'accès obligatoires.
4.6 Convergence opérationnelle avec les pratiques logicielles modernes
Le dernier élément de la thèse affirmative est peut-être le plus important, bien qu’il soit le plus difficile à quantifier. Les conteneurs intègrent les logiciels industriels dans la même chaîne d'outils opérationnels que l'industrie du logiciel au sens large. Les pipelines d'intégration continue, les outils de sécurité de la chaîne d'approvisionnement, les piles d'observabilité, les systèmes d'automatisation du déploiement, tous sont natifs des conteneurs.
L’implication est que le développement de logiciels industriels peut recruter sur le marché du travail plus large du génie logiciel, adopter des pratiques et des outils validés à une échelle hyperscale et s’intégrer à l’écosystème cloud natif sans adaptation sur mesure. L’isolement historique du développement de logiciels industriels par rapport à l’écosystème logiciel plus large – avec les pénuries de talents, les lacunes en matière d’outillage et les déficits de sécurité – est dissous par l’adoption des conteneurs.
Cet effet est structurel et de long terme. Ses conséquences se feront sentir sur une décennie ou plus, mais la direction à suivre est claire : le développement de logiciels industriels devient indiscernable, en termes d’outillage et de pratique, du développement d’applications modernes.
Faire face aux objections
Un plaidoyer sérieux doit s’attaquer aux formes les plus fortes des objections auxquelles il est confronté, et non aux plus faibles. Cette section aborde les quatre objections les plus fréquemment soulevées contre la conteneurisation industrielle.
5.1 L’objection relative aux performances en temps réel
Les conteneurs introduisent une planification non déterministe et des conflits de ressources qui les disqualifient des charges de travail industrielles en temps réel.
L’objection a du mérite dans sa forme la plus forte, mais la forme sous laquelle elle est habituellement formulée est trop radicale. Les charges de travail industrielles en temps réel ne sont pas monolithiques ; ils vont du contrôle de mouvement dur en temps réel (délais en microsecondes, délai manqué équivaut à un incident de sécurité) au contrôle de processus en temps réel doux (délais en dizaines de millisecondes, échecs occasionnels tolérables) jusqu'à l'analyse en temps différé (pas de délai).
Pour les charges de travail difficiles en temps réel, les conteneurs ne sont en effet pas adaptés, tout comme Linux conventionnel. Le temps réel dur sous Linux nécessite un noyau corrigé avec PREEMPT_RT [13] ou équivalent, une affinité CPU minutieuse, l'isolation des cœurs temps réel du planificateur et l'exclusion des charges de travail non temps réel du domaine temps réel. Ces exigences sont indépendantes de la conteneurisation. Un système Linux en temps réel correctement configuré peut héberger des charges de travail en temps réel dans des conteneurs avec des garanties complètes en temps réel, à condition que la discipline de configuration soit respectée.
Les mesures quantitatives le confirment. Les benchmarks des charges de travail conteneurisées en temps réel sur PREEMPT_RT Linux [14] montrent une surcharge de latence de l'ordre de quelques microsecondes par rapport à une exécution sans système d'exploitation – bien dans la tolérance des charges de travail industrielles, même les plus exigeantes. La surcharge provient en grande partie de la comptabilité des groupes de contrôle, qui peut être désactivée de manière sélective pour les groupes de contrôle en temps réel où la latence déterministe est plus importante que la comptabilité fine des ressources.
Pour les charges de travail logicielles en temps réel et non temps réel (qui englobent la grande majorité des logiciels industriels), les conteneurs introduisent une surcharge de l'ordre de 1 à 3 % pour les charges de travail liées au processeur et une surcharge statistiquement négligeable pour les charges de travail liées aux E/S. Ce n'est pas un obstacle sérieux.
5.2 L’objection relative aux limites de sécurité
Des vulnérabilités liées à l'évasion des conteneurs sont régulièrement découvertes ; les conteneurs ne peuvent pas être considérés comme une frontière de sécurité pour les charges de travail industrielles de grande valeur.
L’objection amalgame deux affirmations distinctes. La première – à savoir qu’il existe des vulnérabilités d’évasion de conteneur – est vraie. La seconde, à savoir que cela disqualifie les conteneurs d'une utilisation industrielle, ne s'ensuit pas, car les évasions de machines virtuelles existent également et les déploiements sans système d'exploitation n'ont aucune frontière pour s'échapper. La question pertinente est celle de la situation de sécurité par rapport aux alternatives, et non par rapport à la perfection.
L’historique des vulnérabilités liées à l’évasion des conteneurs est instructif. Les principaux CVE – runc CVE-2019-5736, Dirty Pipe CVE-2022-0847, CVE-2024-0132 dans NVIDIA Container Toolkit – ont, dans chaque cas, été corrigés quelques jours après leur divulgation et propagés dans l'écosystème en quelques semaines. La fenêtre d’exposition pour des systèmes correctement entretenus a été courte.
Pour les charges de travail nécessitant une isolation de niveau hyperviseur, des environnements d'exécution de conteneurs légers basés sur des machines virtuelles - Kata Containers [15], Firecracker [16], gVisor [17] - le fournissent tout en préservant l'interface du conteneur. Ces technologies permettent un déploiement hybride dans lequel la plupart des charges de travail s'exécutent dans des conteneurs conventionnels tandis que les charges de travail spécifiquement sensibles s'exécutent dans des microVM, toutes gérées par la même couche d'orchestration.
Le sérieux défi de sécurité pour la conteneurisation industrielle n’est pas la surface d’attaque du noyau ; c'est la chaîne d'approvisionnement. Une image de conteneur construite à partir d'images de base non fiables, à partir de packages extraits de référentiels compromis, à partir de pipelines de construction sans provenance, est un vecteur de compromission que l'isolation des conteneurs ne résoudra pas. La réponse à ce défi — abordée dans la section 6 — est l'adoption de cadres de sécurité de la chaîne d'approvisionnement tels que SLSA [18] et la distribution d'images signées via Sigstore [19].
5.3 L'objection relative à la charge de travail avec état
Les conteneurs ont été conçus pour les charges de travail sans état. Les applications industrielles sont profondément dynamiques, et les imposer dans un modèle sans état produit de mauvaises architectures.
La prémisse est en partie correcte – les premières directives sur les conteneurs mettaient l’accent sur l’apatridie – mais la conclusion ne l’est pas. Le modèle de conteneur s'adapte aux charges de travail avec état via des montages de volumes, des volumes persistants dans des environnements orchestrés et des primitives de gestion de données explicites. La discipline requise est de rendre l'état adressable de l'extérieur et géré explicitement, plutôt qu'implicite dans la mémoire d'exécution de l'application.
Cette discipline constitue en fait un avantage pour les applications industrielles et non un coût. Une application industrielle avec état dont l'état est implicite, non documenté et intriqué avec la mémoire d'exécution est précisément le type d'application impossible à déboguer, impossible à migrer et impossible à récupérer après une panne. Le processus de conteneurisation force l'externalisation et la gestion explicite de l'état, produisant des applications qui sont plus résilientes, pas moins.
Pour les charges de travail industrielles véritablement dynamiques (bases de données historiques, données d'étalonnage, magasins de configuration), l'écosystème de conteneurs fournit des outils matures : des volumes persistants avec un support de système de fichiers approprié, des modèles d'opérateur pour la gestion des cycles de vie des bases de données et des primitives de sauvegarde intégrées à la couche de stockage.
5.4 L’objection liée à la complexité opérationnelle
L'orchestration de conteneurs introduit une complexité opérationnelle que les équipes OT ne sont pas prêtes à gérer. L’alternative – de simples mises à jour du micrologiciel – est plus simple sur le plan opérationnel, même si elle est techniquement inférieure.
L’objection bénéficie d’un soutien empirique substantiel. Kubernetes est largement considéré comme complexe sur le plan opérationnel, et les compétences requises pour le faire fonctionner ne sont pas généralement présentes dans les équipes OT.
Toutefois, deux observations nuancent l’objection. Premièrement, le déploiement de conteneurs ne nécessite pas Kubernetes. Pour les déploiements industriels à nœud unique – qui décrivent la grande majorité des scénarios de passerelle Edge – Docker Compose, Podman ou les unités de conteneurs gérées par systemd offrent une surface opérationnelle dont la complexité est comparable à celle de la gestion de services conventionnelle. La pile d'orchestration complète n'est nécessaire que pour les déploiements à l'échelle d'une flotte, et à cette échelle, la complexité de l'orchestration est compensée par les avantages opérationnels.
Deuxièmement, l’orchestration légère – K3 [20], KubeEdge [21], MicroK8 – a considérablement réduit la complexité opérationnelle des déploiements périphériques à l’échelle de la flotte. Le profil de complexité historique de Kubernetes reflète ses origines dans les charges de travail hyperscalers ; les variantes légères sont explicitement conçues pour les réalités opérationnelles du déploiement en périphérie.
La réponse la plus profonde à l’objection de la complexité opérationnelle est que la complexité opérationnelle des logiciels industriels non conteneurisés a été sous-estimée pendant des décennies. Les dépendances non documentées, les incidents irréproductibles, les processus de déploiement qui n'existent que comme savoir tribal chez les chefs d'ingénieurs notamment, sont des formes de complexité opérationnelle qui ne se mesurent pas parce qu'elles ne sont pas visibles. La complexité visible de l’orchestration des conteneurs remplace la complexité invisible qui était toujours présente. Qu’il s’agisse d’une augmentation ou d’une diminution nette de la charge opérationnelle dépend du déploiement spécifique, mais l’hypothèse selon laquelle la base de référence non conteneurisée est opérationnellement simple ne résiste pas à un examen minutieux.
Modèles architecturaux pour le déploiement industriel
La transition de la défendabilité théorique à la pratique déployable dépend de la maturité des modèles architecturaux. Les modèles qui ont émergé dans les déploiements industriels de production méritent une description explicite.
6.1 Déploiement d'une passerelle à nœud unique
Le modèle le plus courant est la passerelle à nœud unique : une passerelle industrielle exécutant un petit nombre d'applications conteneurisées, avec Docker Compose ou des unités de conteneurs gérées par systemd fournissant la surface d'orchestration. Les mises à jour sont extraites d'un registre central, éventuellement selon un calendrier défini par une boucle de réconciliation de type Watchtower. L’état est conservé sur les volumes locaux avec sauvegarde sur l’infrastructure centrale.
La force de ce modèle réside dans sa simplicité opérationnelle. Sa faiblesse réside dans le fait que la gestion à l’échelle de la flotte n’est pas directement prise en charge : chaque passerelle est gérée indépendamment. Pour les déploiements de dizaines à quelques centaines de passerelles, cela est acceptable. Pour les flottes plus importantes, le modèle suivant est plus approprié.
6.2 Orchestration à l'échelle de la flotte
Pour les déploiements à l'échelle de la flotte, les distributions Kubernetes légères (K3, KubeEdge) assurent l'orchestration à travers la flotte. Chaque passerelle devient un nœud (soit en tant que cluster à nœud unique, soit en tant que nœud de travail dans un cluster plus grand) et les charges de travail sont planifiées, mises à jour et observées via les outils Kubernetes standard.
La force de ce modèle réside dans la gestion à l’échelle de la flotte avec un écosystème mature. Sa faiblesse réside dans la complexité opérationnelle évoquée à la section 5.4, qui ne justifie ce modèle qu’à une échelle suffisante.
6.3 GitOps pour la configuration Edge
Dans les deux cas, la configuration des passerelles (quels conteneurs s'exécutent, quelles images sont déployées, quelles ressources sont allouées) est décrite de manière déclarative dans un référentiel à version contrôlée. Un contrôleur de réconciliation (Flux, Argo CD, Fleet) exécuté sur la passerelle ou sur un contrôleur dans le cloud, observe l'écart entre l'état observé et l'état souhaité et applique les modifications nécessaires pour le combler.
La force de ce modèle réside dans l’auditabilité et l’atomicité au niveau de la flotte. L'historique complet de la configuration de la flotte est capturé dans Git. La restauration est une opération Git. Le modèle a été emprunté presque sans modification aux opérations cloud natives et s’applique bien à la périphérie.
6.4 Sécurité de la chaîne d'approvisionnement
Pour les déploiements industriels, la sécurité de la chaîne d’approvisionnement des images de conteneurs est essentielle sur le plan opérationnel. Le modèle mature comprend :
Ceci n’est pas facultatif pour les déploiements industriels. Les attaques de la chaîne d’approvisionnement qui ont eu lieu contre les écosystèmes d’empaquetage de logiciels au cours des cinq dernières années – SolarWinds, les différents compromissions npm et PyPI – établissent que la menace est réelle et que les défenses sont nécessaires.
- Création d'images dans une infrastructure CI de confiance avec provenance documentée (cadre SLSA [18])
- Signature d'image avec Sigstore [19] ou équivalent
- Attestation de provenance suivant la spécification in-toto [22]
- Génération de nomenclatures logicielles suivant SPDX [23] ou CycloneDX
- Analyse continue des vulnérabilités avec Trivy, Grype ou équivalents commerciaux
- Contrôle d'admission au niveau de la passerelle qui refuse les images non signées ou vulnérables
6.5 Modèles d'accès au matériel
Les charges de travail industrielles nécessitent fréquemment l'accès à du matériel physique : ports série, broches GPIO, bus CAN, bus de terrain industriels, accélérateurs GPU. Le modèle de conteneur prend en charge cela via des groupes de contrôle de périphériques et des montages de périphériques explicites.
Le modèle discipliné consiste à exposer des appareils spécifiques à des conteneurs spécifiques plutôt que d’exécuter des conteneurs privilégiés avec un accès complet à l’hôte. Le contrôleur de groupe de contrôle de périphérique du noyau permet un contrôle d'accès précis. Les règles udev peuvent mapper des périphériques physiques à des noms stables auxquels les conteneurs font référence. Pour l'accès au GPU, NVIDIA Container Toolkit et équivalent fournissent un accès matériel sans élévation de privilèges.
6.6 Augmentation en temps réel
Pour les déploiements avec des exigences en temps réel, le modèle combine un noyau PREEMPT_RT, une isolation du processeur via le paramètre de démarrage « isolcpus », des groupes de contrôle dédiés en temps réel et un placement minutieux de la charge de travail. L'interface du conteneur est préservée, mais le planificateur sous-jacent est configuré pour les charges de travail en temps réel.
Il s'agit d'un travail d'ingénierie, pas d'un indicateur de fonctionnalité, mais il s'agit d'un travail d'ingénierie bien documenté [13] [14] qui fournit des profils de latence répondant aux exigences de toutes les charges de travail en temps réel difficiles, à l'exception des plus exigeantes.
Problèmes ouverts et adoption responsable
Les arguments en faveur de la conteneurisation industrielle sont solides, mais pas sans réserve. Plusieurs problèmes ouverts méritent une reconnaissance explicite.
Discipline de taille d'image. Les images de conteneurs atteignent fréquemment des gigaoctets en raison des dépendances accumulées, des outils de débogage et du gonflement de l'image de base. Pour les déploiements industriels limités en bande passante – où les images sont extraites via des liaisons cellulaires ou satellite – cela s'avère coûteux sur le plan opérationnel. Des pratiques disciplinées (images de base sans distribution [24], builds en plusieurs étapes, gestion minutieuse des dépendances) maintiennent les images de production en dessous de 100 Mo pour la plupart des charges de travail, mais la discipline n'est pas automatique.
Développement des compétences. L'écosystème des conteneurs suppose un niveau de sophistication opérationnelle qui n'est pas uniformément présent dans les équipes d'ingénierie industrielle. Combler cet écart nécessite un investissement explicite dans la formation, dans des outils réduisant la surface opérationnelle et dans des modèles permettant aux équipes OT d'exploiter l'infrastructure de conteneurs sans devenir des spécialistes de Kubernetes.
Observabilité à l'échelle de la flotte. La télémétrie d'un millier de passerelles conteneurisées génère sa propre télémétrie. La sélection des métriques à émettre, à quelle granularité et comment les agréger est un problème d'ingénierie non résolu à la périphérie. OpenTelemetry [25] a amélioré la situation, mais les modèles spécifiques aux bords restent sous-développés.
Préservation de l'image à long terme. Une image de conteneur déployée aujourd'hui doit rester exécutable sur le matériel déployé aujourd'hui, dans quinze ans, après que le registre qui hébergeait initialement l'image ait changé de propriétaire ou ait cessé d'exister. Les déploiements industriels nécessitent une préservation explicite des images (registres locaux, images archivées, dépendances documentées), ce qui n'est pas le mode opérationnel par défaut de l'écosystème de conteneurs plus large.
Limites d'abstraction matérielle. Certains matériels industriels, en particulier les FPGA, les cartes d'E/S spécialisées et le matériel doté de pilotes de noyau propriétaires, ne s'abstiennent pas proprement dans le modèle de conteneur. Pour ces charges de travail, la conteneurisation est partielle : le composant espace utilisateur est conteneurisé tandis que le pilote du noyau reste une préoccupation au niveau de l'hôte. Ceci est acceptable mais introduit un couplage qu’un déploiement discipliné doit explicitement gérer.
Ces problèmes sont réels et nécessitent un investissement continu en ingénierie. Ils n’invalident pas le cas affirmatif ; ils le qualifient.
Argument final
L’argument peut être énoncé de manière compacte. Les logiciels industriels ont historiquement souffert d'un problème structurel : l'écart entre l'application et l'environnement d'exploitation est incontrôlé, produisant une dérive de dépendance, des échecs de reproductibilité, une fragilité du déploiement et des postures de sécurité difficiles à défendre. Les conteneurs comblent cette lacune en déployant l'application avec ses dépendances en tant qu'artefact isolable, reproductible cryptographiquement, pouvant être mis à jour de manière atomique. La technologie a quatre décennies dans ses fondements conceptuels, régie par des normes ouvertes et validée opérationnellement à une échelle hyperscaler. Les objections soulevées contre l'adoption industrielle sont réelles mais traitables : elles identifient des problèmes d'ingénierie avec des solutions connues, et non des incompatibilités structurelles.
L’alternative structurelle à la conteneurisation est la continuation des pratiques historiques : déploiement sur mesure par plateforme, environnements de production irréproductibles, mécanismes de mise à jour fragiles et isolement opérationnel de l’écosystème logiciel plus large. Cette alternative n’est pas un équilibre stable. C’est le statu quo dont les limites sont désormais suffisamment visibles pour que l’industrie s’en éloigne, et la question n’est pas de savoir s’il faut adopter les conteneurs mais comment bien les adopter.
La recommandation qui suit est directe. Les gammes de produits industriels doivent être conçues dès le départ pour un déploiement conteneurisé. Les investissements requis – dans la sécurité de la chaîne d’approvisionnement, dans les outils d’observabilité, dans le développement des compétences, dans la discipline de préservation de l’image – doivent être planifiés et budgétisés explicitement. Les modèles décrits dans la section 6 doivent être adoptés, adaptés et évolués à mesure que la pratique mûrit.
L’alternative est de rester dans un régime architectural qui a fait son temps. La transition ne sera pas gratuite. Cela coûtera beaucoup moins cher que de ne pas le faire.
References
[1] S. Hykes. "L'avenir des conteneurs Linux." PyCon États-Unis, 2013.
[2] EW Biederman. «Instances multiples des espaces de noms Linux globaux». Symposium Linux, 2006.
[3] P.B. Ménage. «Ajout de conteneurs de processus génériques au noyau Linux». Symposium Linux, 2007.
[4] N. Brun. "Système de fichiers superposé." Documentation du noyau Linux, 2014.
[5] Initiative de conteneurs ouverts. Spécification d'exécution, spécification d'image et spécification de distribution. 2017-présent. https://opencontainers.org
[6] DM Ritchie et K. Thompson. Manuel du programmeur Unix, septième édition. Bell Laboratories, 1979.
[7] P.-H. Kamp et R.N.M. Watson. « Prison : confiner la racine omnipotente. » Deuxième conférence internationale SANE, 2000.
[8] D. Price et A. Tucker. « Zones Solaris : prise en charge du système d'exploitation pour la consolidation des charges de travail commerciales. » USENIX LISA, 2004.
[9] D. Lezcano et al. Projet Linux Containers (LXC). 2008-présent. https://linuxcontainers.org
[10] A. Verma et coll. "Gestion de clusters à grande échelle chez Google avec Borg." EuroSys, 2015.
[11] B. Burns et coll. "Borg, Omega et Kubernetes." Communications de l'ACM, 59(5), 2016.
[12] Institut national des normes et de la technologie. Guide de sécurité des conteneurs d'applications. Publication spéciale NIST 800-190, 2017.
[13] T. Gleixner et I. Molnar. PREEMPT_RT : correctifs de préemption en temps réel pour le noyau Linux. https://wiki.linuxfoundation.org/realtime/
[14] L. Abéni et al. « Planification en temps réel basée sur des conteneurs dans le noyau Linux ». Revue ACM SIGBED, 16(3), 2019.
[15] Projet de conteneurs Kata. Kata Containers : la vitesse des conteneurs, la sécurité des VM. https://katacontainers.io
[16] A. Agache et coll. "Firecracker : virtualisation légère pour les applications sans serveur." USENIX NSDI, 2020.
[17] Projet gVisor. gVisor : noyau d'application pour conteneurs. Google, 2018. https://gvisor.dev
[18] Google et coll. Niveaux de chaîne d'approvisionnement pour les artefacts logiciels (SLSA). Open Source Security Foundation, 2021-présent. https://slsa.dev
[19] Fondation Linux. Sigstore : signature de logiciels pour tout le monde. https://sigstore.dev
[20] Rancher Labs/SUSE. K3s : Kubernetes léger. https://k3s.io
[21] CNCF. KubeEdge : un framework de calcul Edge natif Kubernetes. https://kubeedge.io
[22] S. Torres-Arias et coll. "in-toto : Fournir des garanties de la ferme à la table pour les bits et les octets." Sécurité USENIX, 2019.
[23] Fondation Linux. Spécification SPDX (Software Package Data Exchange). ISO/IEC 5962:2021.
[24]Google. Images de conteneurs Distroless. https://github.com/GoogleContainerTools/distroless
[25] Projet OpenTelemetry. Spécification OpenTelemetry. CNCF, 2019-présent. https://opentelemetry.io
[26] C. Fowler. "Mettez vos serveurs à la poubelle et gravez votre code : infrastructure immuable et composants jetables." 2013.
[27] J. Cappos et coll. « Compromis clé survivant dans les systèmes de mise à jour logicielle. » ACM CCS, 2010. (Le cadre de mise à jour / TUF.)
[28] Commission électrotechnique internationale. IEC 62443-4-1 : Exigences du cycle de vie du développement de produits sécurisés. 2018.
[29] B. Cantrill et J. Bonwick. "Concurrence dans le monde réel." Communications de l'ACM, 51(11), 2008.
[30] M. Souppaya, J. Morello et K. Scarfone. NIST SP 800-204C : implémentation de DevSecOps pour une application basée sur des microservices avec Service Mesh. 2022.
Cet article fait partie de la série technique Modibus. La passerelle industrielle Modibus MB213 est conçue comme une plate-forme informatique conteneurisée de première classe, prenant en charge les distributions Docker, Podman et Kubernetes légères, avec une accélération matérielle accessible aux charges de travail conteneurisées via les modèles décrits dans la section 6. Pour une discussion technique ou des demandes de renseignements sur la plate-forme, contactez [info@modibus.com](mailto:info@modibus.com).