Sécurité de l'IA : qu'est-ce qu'un sandbox et pourquoi votre PME en a besoin

Vous avez un modèle d'IA tournant sur votre serveur. Vous lui donnez accès à votre base de données clients. Vous lui donnez accès à votre système de facturation. Vous lui donnez accès à votre messagerie. Et puis vous vous demandez : "Et s'il fait quelque chose qu'il ne devrait pas ?"

Bonne question. La réponse s'appelle un sandbox.

Qu'est-ce qu'un sandbox

Un sandbox est un environnement isolé où un programme peut s'exécuter sans affecter le reste du système. C'est comme une pièce capitonnée : ce qui s'y passe, s'y reste.

Si le modèle tente d'accéder à un fichier qu'il ne devrait pas, le sandbox le bloque. S'il tente de se connecter à Internet, le sandbox le coupe. S'il tente d'exécuter une commande du système d'exploitation, le sandbox l'ignore. Le modèle peut penser ce qu'il veut, mais il ne peut faire que ce que vous lui permettez.

Ce n'est pas un concept nouveau. Les navigateurs web utilisent des sandboxes depuis des décennies. Les mobiles exécutent chaque application dans son propre sandbox. Les bacs à sable littéraux existent pour que les enfants jouent sans sortir du parc. Le principe est le même : délimiter l'espace d'action.

Pourquoi votre PME en a besoin

Si vous utilisez ChatGPT ou Claude dans le navigateur, vous utilisez déjà un sandbox. C'est le fournisseur qui décide de ce que le modèle peut et ne peut pas faire. Vous ne pouvez pas exécuter de code arbitraire depuis l'interface web. Vous ne pouvez pas accéder au système de fichiers du serveur. C'est de la sécurité par conception — mais c'est son sandbox, pas le vôtre. C'est aussi une forme de lock-in : vous dépendez de ses règles, pas des vôtres, et vous n'avez pas la transparence de l'open source pour l'auditer.

Le problème apparaît quand vous déployez une IA souveraine sur votre propre infrastructure. Là, personne ne vous protège par défaut. Vous décidez des permissions du modèle. Et si vous lui en donnez trop, les conséquences vous incombent.

Exemples concrets :

• Un agent qui gère les retours. Vous lui donnez accès à la passerelle de paiement pour traiter les remboursements. Qu'est-ce qui l'empêche de traiter un remboursement de 50 000 € vers un compte arbitraire ? Seules les instructions que vous lui avez données. Si ces instructions ont une faille, la faille est exploitée.
• Un assistant qui lit les courriels. Vous lui donnez accès à la messagerie pour classer les demandes. Qu'est-ce qui l'empêche d'envoyer des courriels au nom de votre entreprise ? Seule une couche de permissions que vous n'avez peut-être pas configurée.
• Un modèle qui interroge votre ERP. Vous lui donnez un accès en lecture à la base de données. Et si une astucieuse injection de prompt lui fait exécuter une requête DELETE ? Les bases de données ne distinguent pas un utilisateur d'un modèle si les deux ont les mêmes identifiants.

Comment ça marche en pratique

Un sandbox pour l'IA, ce n'est pas seulement "limiter les permissions". Il a des couches :

1. Isolement réseau

Le modèle n'a pas besoin d'Internet. S'il tourne localement, ses réponses se génèrent à partir des données qu'il possède déjà. Coupez l'accès au réseau et vous éliminez la possibilité d'exfiltration de données ou que le modèle télécharge quelque chose qu'il ne devrait pas.

2. Système de fichiers en lecture seule

Le modèle lit des documents, il ne les modifie pas. Montez le répertoire de données en lecture seule. S'il doit écrire des résultats, qu'il les écrive dans un répertoire séparé qui n'affecte pas les données source.

3. Permissions minimales

L'agent qui classe les courriels n'a pas besoin d'accès à la facturation. Celui qui traite les factures n'a pas besoin d'accès aux ressources humaines. Chaque agent reçoit strictement les permissions nécessaires. Pas une de plus. Cela s'appelle le principe du moindre privilège et c'est l'ABC de la sécurité.

4. Journaux et audit

Tout ce que fait le modèle est enregistré. Chaque requête, chaque action, chaque accès aux données. Non seulement pour détecter des problèmes a posteriori, mais pour pouvoir auditer que le système se comporte comme prévu. Cette traçabilité est indispensable à une démarche RGPD structurée.

5. Couche de validation

Avant que toute action du modèle ne soit réellement exécutée (envoyer un courriel, traiter un paiement, modifier un enregistrement), elle passe par une couche de validation qui vérifie que l'action est dans les paramètres autorisés. Le modèle propose, la validation dispose.

Le mythe du "si c'est local, c'est déjà sécurisé"

Faire tourner l'IA localement est plus sûr qu'envoyer vos données à un fournisseur cloud. C'est vrai. Mais ce n'est pas la même chose que sécurisé.

Local signifie que vos données ne quittent pas votre réseau. Mais un modèle local avec des permissions excessives, c'est comme avoir une porte blindée à l'entrée et laisser les fenêtres ouvertes. Le modèle n'enverra pas vos données à OpenAI, mais il peut faire des choses dans votre système que vous ne vouliez pas.

La combinaison gagnante est IA souveraine + sandbox. Données sur votre serveur, permissions sous contrôle, actions auditées.

L'analogie qui clarifie tout

Imaginez que vous embauchez quelqu'un pour classer des documents dans votre bureau. Option A : vous lui donnez les clés de tout l'immeuble, le code du coffre-fort et le mot de passe du système informatique. Option B : vous lui donnez accès uniquement à la salle des documents, un bureau, et une règle : "classez ces papiers, mais ne touchez à rien d'autre".

Les deux options fonctionnent. L'option A est plus rapide parce que vous n'avez pas à configurer de permissions. L'option B est plus sûre parce que, si cette personne commet une erreur — ou si quelqu'un la trompe pour qu'elle fasse quelque chose qu'elle ne devrait pas —, le dommage est contenu.

Un sandbox, c'est l'option B. Pour votre IA.

Quoi faire maintenant

1. Auditez les permissions. Si vous avez déjà de l'IA en production, vérifiez à quoi elle a accès. Cela peut vous surprendre.
2. Appliquez le moindre privilège. Chaque agent, uniquement les permissions dont il a besoin. Rien de plus.
3. Isolez le réseau. Si le modèle n'a pas besoin d'Internet, ne lui donnez pas Internet.
4. Ajoutez des journaux. Si vous ne voyez pas ce qu'il fait, vous ne pouvez pas améliorer ce qu'il fait.
5. Créez une couche de validation. Avant toute action irréversible, un humain ou une règle confirme.

Vous n'avez pas besoin de tout faire à la fois. Commencez par auditer les permissions. C'est ce qui a le plus d'impact pour le moins d'effort.

Chez Neurosint, nous concevons des déploiements d'IA avec la sécurité par défaut. Sandboxes, moindre privilège, audit intégré. Si vous allez intégrer l'IA dans votre entreprise, qu'elle soit sécurisée dès le premier jour. Parlons.