Calipia : le blog

Pendant dix-huit mois, le mode opératoire des équipes sécurité face à l’IA générative s’est articulé autour d’une idée simple : contrôler ce qui sort du réseau. Renforcer les politiques CASB (Cloud Access Security Broker), surveiller le trafic vers les API connues, passer les usages par des passerelles sanctionnées. Le raisonnement était cohérent : si une donnée sensible quitte le périmètre réseau pour rejoindre un service externe, on peut l’observer, la journaliser, l’intercepter.

Ce modèle est en train de se fissurer silencieusement.

L’inférence locale qui devient une pratique courante

Il y a encore deux ans, faire tourner un LLM performant sur un laptop d’entreprise relevait du défi technique réservé aux passionnés. Aujourd’hui, c’est une réalité opérationnelle pour les équipes techniques. Trois évolutions convergentes expliquent cette bascule.

D’abord, les accélérateurs grand public sont devenus sérieux. Un MacBook Pro équipé de 64 Go de mémoire unifiée peut faire tourner des modèles de classe 70B à des vitesses exploitables pour de nombreux cas d’usage réels (c’est typiquement la configuration que j’utilise personnellement et qui donne des résultats très impressionnant). Ce qui nécessitait des serveurs multi-GPU il y a dix-huit mois tient désormais dans un petit sac à dos.

Ensuite, la quantisation est devenue accessible. Les formats compressés permettent de faire tenir des modèles capables dans la mémoire d’un ordinateur portable, avec des compromis de qualité souvent acceptables pour les tâches courantes de développement.

Enfin, la distribution est devenue triviale. Les modèles open-weight se téléchargent en une ligne de commande, et l’écosystème d’outils (Ollama, llama.cpp, LM Studio) rend la séquence « télécharger, lancer, interroger » accessible à tout développeur intermédiaire. Nous reparlerons de tout cela lors du prochain Briefing Calipia avec démonstrations à l’appui.

Le résultat pratique est troublant : un ingénieur peut récupérer un modèle de plusieurs gigaoctets, couper le Wi-Fi, et exécuter localement des workflows sensibles. Revue de code source interne, synthèse de documents confidentiels, rédaction de communications clients, analyse exploratoire de données régulées. Aucun paquet sortant, aucun log de proxy, aucune trace dans un audit cloud.

Du point de vue de la sécurité réseau, cette activité peut être strictement indiscernable de « rien ne s’est passé. »

La menace ne vient plus de l’exfiltration, mais de l’intérieur du device

Pourquoi un RSSI devrait-il s’en préoccuper si rien ne quitte le poste ? Parce que les risques dominants basculent de l’exfiltration vers l’intégrité, la provenance et la conformité. Un article très intéressant de VentureBeat identifie trois catégories de points aveugles que la plupart des entreprises n’ont pas encore opérationnalisés.

Le premier est le risque d’intégrité du code et des décisions. Les modèles locaux sont souvent adoptés précisément parce qu’ils sont rapides, privés et « sans processus d’approbation ». L’inconvénient de cette agilité, c’est qu’ils sont fréquemment non vérifiés pour l’environnement enterprise. Un scénario courant : un développeur senior télécharge un modèle de code fine-tuné par la communauté parce qu’il performe bien sur les benchmarks. Il lui soumet une logique d’authentification interne ou des scripts d’infrastructure pour « les nettoyer ». Le modèle renvoie quelque chose qui compile, passe les tests unitaires, semble propre. Mais qui dégrade subtilement la posture de sécurité : validation d’entrées insuffisante, valeurs par défaut non sécurisées, choix de dépendances non validées en interne. Le développeur commite. Et si cette interaction s’est déroulée hors ligne, il n’existe aucune trace que l’IA a influencé ce chemin de code.

Le deuxième risque concerne la conformité des licences. De nombreux modèles performants sont assortis de licences qui incluent des restrictions d’usage commercial, des obligations d’attribution, ou des limites de domaine incompatibles avec le développement de produits propriétaires. Quand des collaborateurs les exécutent localement, cet usage contourne les processus normaux de procurement et de revue juridique. Le problème n’est pas uniquement la clause de licence elle-même : c’est l’absence d’inventaire et de traçabilité. Sans hub de modèles gouverné, impossible de prouver ultérieurement quel modèle a été utilisé pour générer tel composant, lors d’une due diligence M&A ou d’un audit client.

Le troisième risque touche à la chaîne d’approvisionnement logicielle des modèles eux-mêmes. Les endpoints commencent à accumuler des artefacts de modèles volumineux et tout l’écosystème d’outillage associé : téléchargeurs, convertisseurs, runtimes, plugins, interfaces locales, packages Python. Il existe ici une nuance technique critique : le format de fichier importe. Les formats récents comme Safetensors sont conçus pour prévenir l’exécution de code arbitraire. En revanche, les fichiers PyTorch au format Pickle peuvent exécuter des charges malveillantes simplement au moment du chargement. Un développeur qui récupère des checkpoints non vérifiés depuis Hugging Face ne télécharge pas seulement de la donnée. Il télécharge potentiellement un exploit…

Des pistes concrètes pour reprendre la main

L’article propose trois axes de réponse qui méritent d’être traduits en actions concrètes pour les DSI et RSSI.

• Le premier consiste à descendre la gouvernance au niveau de l’endpoint. Les outils réseau (DLP, CASB) restent pertinents pour les usages cloud, mais ils sont insuffisants pour le BYOM (Bring Your Own Model). Il faut traiter l’usage local des modèles comme un problème de gouvernance de poste de travail : inventaire et détection des fichiers .gguf supérieurs à 2 Go, surveillance des processus comme llama.cpp ou Ollama, détection des ports d’écoute sur le port 11434 (port par défaut d’Ollama), monitoring des pics GPU/NPU depuis des runtimes non approuvés. L’enjeu n’est pas de sanctionner l’expérimentation, mais de récupérer de la visibilité.
• Le deuxième axe consiste à offrir une voie officielle confortable. Le shadow AI est souvent la conséquence du manque de friction du chemin non officiel et de la lourdeur du chemin officiel. La réponse pragmatique est de proposer un hub interne de modèles curatés : modèles approuvés pour les cas d’usage courants (génération de code, synthèse, classification), licences vérifiées, versions épinglées avec hashes, priorisation des formats sécurisés comme Safetensors, documentation claire sur ce qui est acceptable de soumettre ou non. Si l’on veut que les développeurs cessent de butiner ailleurs, il faut leur proposer mieux.
• Le troisième axe est la mise à jour des politiques d’usage acceptable. La plupart des chartes informatiques évoquent les « services SaaS et cloud », sans mention des modèles téléchargés localement. Une politique adaptée à 2026 doit explicitement couvrir le téléchargement et l’exécution d’artefacts de modèles sur les endpoints d’entreprise, les sources autorisées, les exigences de conformité des licences, les règles d’usage avec des données sensibles, et les attentes en matière de journalisation locale. Pas nécessairement une politique lourde. Mais une politique sans ambiguïté.

La ligne de flottaison se déplace vers le endpoint

Pendant une décennie, la stratégie de sécurité a consisté à pousser les contrôles « vers le haut » dans le cloud. L’inférence locale tire une part croissante de l’activité IA « vers le bas », vers le silicium posé sur le bureau ou dans le sac à dos du développeur.

Les signaux d’alerte à surveiller sont au nombre de cinq : consommation de stockage inexpliquée par des fichiers .gguf ou .pt ; processus à l’écoute sur le port 11434 ; pics de GPU en mode hors ligne ou sans VPN ; impossibilité de tracer les sorties de code vers des versions spécifiques de modèles ; présence de modèles « non commercial use only » dans des builds de production.

Le Shadow AI 2.0 n’est pas un scénario futur hypothétique. C’est la conséquence prévisible de l’accélération matérielle, de la facilité de distribution et de la demande développeur. Les RSSI qui concentrent leur attention sur les contrôles réseau vont manquer ce qui se passe sur le silicium installé dans les laptops de leur parc.

Cela rappelle sans doute aussi pour certains, dont votre serviteur, les débuts des PCs en entreprise, où les DSI voyaient ces curieux engins comme des outils dangereux capables d’aspirer les données des mainframes en donnant aux utilisateurs un peut trop d’autonomie…

La prochaine phase de la gouvernance IA sera moins une question de blocage d’URLs et davantage une question de maîtrise des artefacts, de la provenance, et des politiques au niveau du poste de travail, sans tuer la productivité dans l’opération.