Introduction

Il suffit d’une seule ligne de commande pour lancer une base de données PostgreSQL, un cache Redis ou un serveur web complet en quelques secondes, sans même demander l’avis du service informatique. Avec l’arrivée de la conteneurisation, Docker a démocratisé l’infrastructure au point de la rendre invisible.

Si cette flexibilité est une bénédiction pour l’agilité des équipes, elle représente le cauchemar moderne des administrateurs système et des RSSI : le Shadow IT conteneurisé.

Pourquoi Docker est le carburant idéal du Shadow IT

Historiquement, le Shadow IT reposait sur des tableurs Excel partagés en cachette ou de petits abonnements SaaS souscrits avec une carte bancaire d’entreprise. Aujourd’hui, il s’est professionnalisé. N’importe quel développeur, chef de projet ou analyste un tant soit peu technique peut déployer des piles logicielles entières sur une machine de bureau, un serveur de test isolé ou un VPS cloud non répertorié.

Plusieurs facteurs expliquent pourquoi Docker alimente ce phénomène :

• L’immédiateté : Plus besoin d’attendre des semaines qu’un ticket de provisionnement de VM soit validé et traité par l’infrastructure.
• L’isolation parfaite : Un conteneur s’exécute de manière prévisible, sans polluer l’OS hôte, ce qui le rend idéal pour des PoC (Proof of Concept) improvisées.
• La richesse des images officielles : En un docker pull, on récupère des applications complexes prêtes à l’emploi (CMS, moteurs de recherche, outils de monitoring).

Les risques invisibles des conteneurs non gérés

Si un conteneur tourne dans un coin sans que la DSI ne le sache, le problème n’est pas seulement d’ordre bureaucratique ; il touche directement la sécurité et la gouvernance de l’organisation :

1. Les angles morts de la sécurité et des vulnérabilités

Combien de conteneurs lancés à la hâte reposent sur des images de base obsolètes, bourrées de CVE non corrigées ? Sans politique de scan centralisée (via des outils de type Trivy ou Grype) ni registre interne approuvé (harbor ou autre), les portes d’entrée se multiplient.

2. La souveraineté et la fuite des données

Un conteneur de test stocke souvent des données sensibles (dumps de production, credentials en clair dans les variables d’environnement). Si ce serveur de test est mal configuré ou exposé directement sur Internet, c’est la porte ouverte aux fuites de données.

3. L’opacité opérationnelle

Lorsqu’un incident survient, impossible de résoudre un problème sur une architecture dont on ignore l’existence. Pas de supervision centralisée, pas de sauvegardes automatisées (type Proxmox Backup Server ou équivalent), et une gestion du cycle de vie totalement anarchique.

Comment passer de l’interdiction à la maîtrise ?

Tenter d’interdire Docker ou de bloquer les ports par la force est une bataille perdue d’avance. Les équipes trouveront toujours un moyen de contourner les blocages pour gagner en efficacité. Plutôt que la contrainte stérile, la bonne approche réside dans l’accompagnement et l’outillage :

La règle d’or : Ne combattez pas l’agilité, offrez un cadre qui la rend sûre.

• Mettre en place un registre d’entreprise de confiance : Proposer un catalogue d’images pré-approuvées, sécurisées et maintenues à jour, afin que les équipes n’aient plus besoin de piocher aveuglément sur Docker Hub.
• Déployer une supervision des actifs : Utiliser des outils de découverte réseau ou de gestion de parc pour identifier les hôtes exécutant des runtimes de conteneurs.
• Encourager la standardisation via l’orchestration : Centraliser les déploiements sur des plateformes managées (comme des clusters Swarm ou Kubernetes internes) ou des outils de gestion unifiés (Portainer, etc.) pour garder une visibilité globale.

Conclusion

Docker n’est ni le coupable ni l’ennemi. C’est un outil d’une efficacité redoutable qui ne fait que révéler un besoin fondamental : la soif d’autonomie des équipes techniques.

Plutôt que de faire l’autruche face au Shadow IT, les organisations ont tout à gagner à transformer cette énergie en opportunité, en transformant le « bricolage » en une infrastructure agile, maîtrisée et sécurisée.