Sandbox (bac à sable)

Comment ça marche

Dès qu’un agent peut agir, il peut se tromper en agissant : effacer un fichier, modifier le mauvais enregistrement, envoyer un e-mail de test à un client, exécuter un programme qui fait autre chose que prévu. Le bac à sable est la réponse : un espace où l’agent a le droit de tout faire, et dont rien ne sort sans qu’on l’ait décidé.

En pratique, ça prend plusieurs formes selon le niveau de risque. Un dossier de travail dédié, hors duquel l’agent ne peut pas écrire. Un conteneur ou une machine virtuelle, isolés du reste du réseau. Des comptes et des clés de test, qui pointent vers des environnements factices. Une copie des données. Les outils d’agents proposent souvent ces isolations ; la responsabilité reste de les activer, et de ne lever les barrières qu’une par une.

Un exemple concret

1. La tâche : appliquer la nouvelle grille tarifaire du fournisseur à 1 400 références, avec des règles de marge par famille de produits.
2. Étape 1, bac à sable complet : l’agent travaille sur un export des références dans un dossier isolé, sans accès à l’outil de gestion. Il produit un fichier des modifications proposées et un rapport des cas douteux.
3. Étape 2, environnement de test : l’agent applique les modifications sur une copie de l’outil de gestion, avec un compte de test. L’équipe vérifie par échantillon, et compare les totaux.
4. Étape 3, production, sous contrôle : l’agent applique les modifications validées sur le vrai outil, par lots de 100, avec une relecture entre chaque lot, et une sauvegarde avant de commencer.

À l’étape 1, l’agent avait proposé une marge négative sur 12 références à cause d’une règle mal formulée. Dans un bac à sable, c’est une ligne dans un rapport. En production, c’était 12 produits vendus à perte.

Ce que ça change pour une équipe

• On peut expérimenter sans peur. Un agent dans un bac à sable, on le laisse essayer, se tromper, recommencer. C’est comme ça qu’on apprend ce qu’il sait faire.
• Les erreurs restent des informations. Au lieu d’un incident, une erreur devient une ligne dans un rapport, qui améliore la consigne.
• La mise en production devient une décision. On lève une barrière à la fois, en sachant ce qu’on ouvre. Pas de passage brutal de l’essai au réel.
• La confiance se construit sur des preuves. Un agent qui a fait ses preuves sur des copies et des tests mérite des accès réels. Pas avant.

Les limites et les erreurs fréquentes

• Le bac à sable qui fuit. Un dossier « isolé » avec un lien vers les données réelles, un compte de test qui a des droits en production, une clé d’API qui est la vraie. Vérifier ce que l’agent peut réellement atteindre.
• Sauter l’étape. « C’est juste un petit script » : les incidents viennent presque toujours de tâches jugées trop simples pour un test.
• Tester sur des données qui ne ressemblent pas au réel. Des données de test trop propres cachent les cas limites. Une copie anonymisée des vraies données vaut mieux.
• Oublier la sortie. Un agent isolé qui peut quand même envoyer un e-mail ou appeler un service externe n’est pas isolé. La sandbox couvre les actions, pas seulement les fichiers.