Quand l'IA s'installe sans demander la permission
Dans de nombreuses équipes de développement, la situation est devenue familière : un développeur utilise ChatGPT pour générer du code, un autre colle des logs de production dans Claude pour déboguer un bug complexe, un troisième connecte un agent IA directement à la base de données de staging. Chacun agit avec les meilleures intentions du monde — gagner du temps, mieux servir le client, livrer plus vite. Mais aucun responsable technique n'a validé ces usages. C'est ce qu'on appelle le Shadow AI : l'IA qui prolifère dans les angles morts de l'organisation.
Pour les TPE et PME qui développent en PHP/Symfony, ce phénomène pose des risques concrets : fuite de données clients, non-conformité RGPD, dépendances non maîtrisées à des services tiers, et perte de traçabilité sur les décisions techniques. La bonne nouvelle ? Docker a publié en août 2026 une réflexion structurante sur ce sujet, qui mérite qu'on s'y attarde.
La gouvernance IA n'est pas (seulement) un problème de sécurité
L'article original de Docker, signé Karan Verma, pose une thèse qui bouscule les approches classiques : la gouvernance IA est avant tout un problème d'expérience développeur. En d'autres termes, si les développeurs contournent les politiques de sécurité pour utiliser des outils IA, ce n'est pas parce qu'ils sont négligents — c'est parce que les alternatives approuvées sont trop lentes, trop contraignantes, ou tout simplement inexistantes.
Cette lecture change radicalement la façon d'aborder le problème. Plutôt que d'empiler des restrictions (liste noire de services, filtrage réseau, audits a posteriori), Docker propose d'intégrer la gouvernance dans le flux de travail naturel du développeur. Si l'outil sécurisé est aussi l'outil le plus pratique, le Shadow AI disparaît de lui-même.
Concrètement, Docker articule sa réponse autour de plusieurs briques complémentaires :
- Docker Model Runner : exécution locale de LLM (Local-first inference), ce qui signifie que les données ne quittent jamais le poste de travail ou le réseau interne de l'entreprise.
- Docker MCP Catalog and Toolkit : un registre centralisé d'outils MCP (Model Context Protocol) validés par l'équipe, qui remplace la jungle des intégrations artisanales.
- Docker Sandboxes : des environnements isolés pour que les agents IA puissent exécuter du code sans accès non contrôlé au système hôte.
- AI Governance : une couche de contrôle transverse qui permet de définir quels modèles, quels outils et quels accès sont autorisés, par équipe et par contexte.
Ce que ça change concrètement pour une équipe Symfony
Prenons un exemple concret. Votre équipe travaille sur une application Symfony multi-tenant avec des données sensibles (facturation, informations personnelles). Aujourd'hui, un développeur qui veut utiliser un agent IA pour générer des migrations Doctrine ou analyser des requêtes SQL lentes a deux options : utiliser un service cloud externe (risque de fuite de données) ou se passer d'IA (perte de productivité).
Avec l'approche Docker :
-
Le modèle tourne localement via Docker Model Runner. Aucune donnée de production ne sort du périmètre de l'entreprise. Pour une PME soumise au RGPD, c'est un argument décisif.
-
Les outils MCP disponibles sont listés et validés dans le Docker MCP Catalog. Le développeur choisit parmi des intégrations approuvées (accès à la base de données de dev, accès au dépôt Git, accès aux logs de staging) plutôt que de bricoler sa propre connexion.
-
L'agent s'exécute dans un sandbox : s'il génère et exécute du code PHP pour tester une migration, il le fait dans un conteneur isolé, sans accès au système de fichiers hôte ni aux credentials de production.
-
Chaque interaction est traçable : l'équipe technique peut auditer quels modèles ont été utilisés, quelles données ont été exposées, et par qui. C'est la conformité sans la friction.
Résultat : le développeur gagne en productivité, le responsable technique garde la visibilité, et l'entreprise reste conforme. Le Shadow AI n'a plus de raison d'exister, parce que la solution officielle est meilleure.
MCP : le protocole qui standardise la relation agent-outil
Un point technique mérite qu'on s'y arrête : le Model Context Protocol (MCP). Introduit par Anthropic et rapidement adopté par l'écosystème, MCP est un standard ouvert qui définit comment un agent IA interagit avec des outils externes (bases de données, APIs, systèmes de fichiers, services métier).
L'intégration de MCP dans l'écosystème Docker est significative. Plutôt que chaque développeur implémente sa propre façon de connecter un LLM à son environnement Symfony (et crée au passage des vecteurs d'attaque ou des fuites de données), Docker propose un catalogue d'outils MCP pré-intégrés, testés, et configurables par les administrateurs.
Pour une équipe PHP, cela ouvre des perspectives intéressantes :
- Un outil MCP qui expose l'API de votre application Symfony à un agent, avec des permissions granulaires (lecture seule, périmètre d'entités limité)
- Un outil MCP connecté à votre instance PostgreSQL de développement, permettant à un agent d'analyser le schéma et de suggérer des optimisations de requêtes
- Un outil MCP qui wrappe vos commandes
bin/consolepour qu'un agent puisse interagir avec votre application de façon contrôlée
La gouvernance, dans ce schéma, c'est simplement la politique qui définit quels outils MCP sont accessibles à qui, dans quel contexte.
Conclusion : gouverner par le design, pas par l'interdit
L'approche Docker sur la gouvernance IA s'inscrit dans une philosophie que les équipes Symfony connaissent bien : résoudre les problèmes par l'architecture plutôt que par les règles. De la même façon qu'on préfère un système de permissions bien conçu à une liste d'interdits, on préfère un environnement IA structuré à des politiques de blocage que tout le monde contournera.
Pour les TPE et PME, l'enjeu est particulièrement fort : elles n'ont ni la bande passante pour gérer des incidents de sécurité liés au Shadow AI, ni les ressources pour mettre en place des systèmes de gouvernance complexes. Une approche intégrée dans les outils du quotidien — Docker Desktop, les conteneurs, un registre MCP d'équipe — est précisément ce dont elles ont besoin.
La prochaine étape concrète pour votre équipe ? Identifier les usages IA informels qui existent déjà, évaluer quelles données sont exposées, et commencer à dessiner une architecture locale-first qui offre les mêmes capacités sans les risques. Docker fournit aujourd'hui les briques pour y arriver.
Source : Governance Is a Developer Experience Problem — Docker Blog, Karan Verma, août 2026.