Google Gemma 4 pousse les entreprises à repenser le contrôle de l'IA sur les appareils locaux

Google Gemma 4 complique la vie des équipes de sécurité en entreprise : les modèles à poids ouverts peuvent désormais tourner directement sur les portables des employés, sans passer par les passerelles cloud ni par les points de contrôle habituels. Pour les RSSI (CISO), ce n'est pas un modèle de plus, mais un changement de l'architecture même du risque : l'inférence et les scénarios d'agents migrent vers les terminaux.

Le périmètre ne protège plus

Pendant deux ans, de nombreuses entreprises ont bâti leur défense sur une hypothèse simple : si les employés utilisent des LLM externes, tout le trafic peut être acheminé via des passerelles d'entreprise, des CASB et des systèmes de journalisation. Cette approche a fonctionné tant que l'IA générative vivait surtout dans le cloud.

La sortie de Google Gemma 4 change la donne. Ce modèle à poids ouverts, sous licence Apache 2.0, peut être téléchargé, déployé en local et transformer un portable de travail ordinaire en nœud de calcul autonome, qui n'a pas besoin de dialoguer en permanence avec une infrastructure externe.

Google a renforcé ce basculement non seulement avec le modèle, mais aussi avec des outils associés comme Google AI Edge Gallery et la bibliothèque LiteRT-LM. Ils simplifient l'exécution locale, accélèrent l'inférence et aident à construire des scénarios d'agents plus structurés. Résultat : un agent local peut lire des instructions, planifier plusieurs étapes d'affilée et exécuter des tâches sur l'appareil sans l'empreinte réseau habituelle. Pour une équipe de sécurité, c'est un scénario douloureux : si les requêtes ne sortent pas, le périmètre réseau ne voit tout simplement pas ce qui se passe.

«

Qu'est-ce qui s'exécute exactement, en ce moment, sur les terminaux ? » : c'est la question à laquelle les RSSI vont désormais devoir faire face.

Audit et conformité

Le principal problème de l'inférence locale n'est pas que les données quittent forcément l'entreprise, mais que l'observabilité disparaît. Quand un ingénieur traite un document sensible avec un agent local, le tableau de bord central de sécurité peut ne recevoir aucun signal. Pas de requête vers une API externe, pas d'entrée dans un journal cloud, pas de chaîne d'événements claire pour une enquête ultérieure. C'est particulièrement dangereux dans les environnements où il ne suffit pas de protéger les données : il faut aussi pouvoir prouver comment le système a fonctionné.

• Le trafic réseau peut ne pas apparaître du tout si le modèle fonctionne hors ligne
• Les journaux centralisés n'enregistrent pas les étapes de l'agent sur l'appareil
• Un agent local peut lire des fichiers, accéder à des bases de données et lancer des commandes
• Les erreurs, fuites et hallucinations sont plus difficiles à examiner a posteriori

Les banques, les assureurs et la santé sont les plus touchés. Les établissements financiers ont déjà investi des millions pour contrôler les appels d'API vers les modèles génératifs afin de répondre aux exigences des régulateurs. Mais si une stratégie de trading, un scoring de risque interne ou des données clients sont traités par un agent local sans journalisation, l'entreprise perd à la fois la visibilité technique et son périmètre de conformité. Dans la santé, la situation est comparable : même si les données du patient ne quittent physiquement pas le portable, l'absence d'audit vérifiable mine les exigences de base du traitement des informations médicales.

Du contrôle plutôt que des interdictions

La réaction instinctive de la direction, dans ce cas, est d'ajouter des validations, des comités de revue et des politiques d'interdiction. Mais l'auteur de l'article y voit un piège de gestion : la bureaucratie arrête rarement un développeur dont l'échéance approche. Bien plus souvent, elle repousse les expériences dans l'ombre, où naît une nouvelle couche de shadow IT, non plus autour des services SaaS, mais autour d'agents locaux autonomes. Sur le papier, le contrôle se renforce ; en pratique, l'entreprise perd ce qui lui restait de transparence et se retrouve avec un environnement encore moins maîtrisable.

L'accent se déplace donc de l'interdiction du modèle vers le contrôle de l'intention et des accès. Même un agent Gemma 4 exécuté en local se heurte aux droits système : accès aux fichiers, aux bases d'entreprise, aux dépôts internes et aux commandes shell. C'est cette couche qui doit devenir le nouveau périmètre numérique. Les CTO et les RSSI devront déployer des outils d'endpoint capables de repérer une inférence locale anormale, de suivre une charge GPU non autorisée et de distinguer le travail ordinaire d'un développeur d'un agent autonome qui parcourt massivement l'arborescence de fichiers pour exécuter un prompt.

Ce que cela signifie

L'époque où l'IA d'entreprise pouvait se contrôler uniquement via des passerelles cloud touche à sa fin. Google Gemma 4 montre que les modèles d'agents puissants migrent vite vers les appareils des employés, et que toute la logique de la sécurité change avec eux. Les gagnantes seront les entreprises qui sauront voir non seulement le trafic réseau, mais aussi le comportement réel des systèmes d'IA locaux sur les terminaux.