Construire un Analyste de Données IA avec Python en Bac à Sable et Accès Contrôlé aux Paquets

Un analyste de données IA a besoin d’un environnement Python en bac à sable lorsque des jeux de données fournis par l’utilisateur, du code généré par le modèle, des installations de paquets, des graphiques générés et des résultats téléchargeables doivent être exécutés dans un environnement isolé et observable. Le flux de mise en œuvre pratique est le suivant : télécharger un fichier, inspecter le schéma avec du code de confiance, demander un plan au modèle, examiner le code Python généré, l’exécuter dans un bac à sable contraint, valider les artefacts produits, et montrer à l’utilisateur ce qui s’est passé.

Architecture de l’Analyste de Données IA : Téléchargement, Analyse, Révision

Le modèle produit est simple en apparence : un utilisateur télécharge un CSV, pose une question en langage naturel et s’attend à obtenir des tableaux utiles, des graphiques et des fichiers téléchargeables. En coulisses, l’application exécute un petit workflow d’agent avec de véritables effets de bord. Le modèle planifie l’analyse et rédige le code Python, tandis que l’application décide du code, des paquets, des fichiers, de l’accès réseau et des sorties autorisés.

Construisez la première version autour d’un chemin clair :

1. Acceptez un téléchargement CSV pour une seule tâche d’analyse.
2. Créez un espace de travail en bac à sable dédié à la tâche.
3. Exécutez un code d’inspection de schéma propriétaire avant de demander du Python au modèle.
4. Demandez au modèle un plan d’analyse, puis un script qui respecte vos règles de fichiers et de paquets.
5. Exécutez le script avec des limites de temps, mémoire, disque, paquets et réseau.
6. Collectez uniquement les artefacts validés depuis un répertoire de sortie connu.
7. Affichez à l’utilisateur la réponse, les graphiques, les avertissements, les journaux et les fichiers sélectionnés pour le téléchargement.

Cette séparation maintient des responsabilités claires. Le modèle propose et explique l’analyse. Le backend applique la politique produit et l’orchestration. Le bac à sable exécute le code avec des fichiers, paquets, temps, mémoire, accès réseau et secrets contraints.

Qu’est-ce qui s’exécute dans un Bac à Sable Python pour l’Analyse de Données ?

Placez l’espace de travail d’analyse dans le bac à sable, et non sur votre serveur d’application principal. Le bac à sable doit recevoir un ensemble d’entrées restreint pour une seule tâche d’analyse : le fichier téléchargé, un petit manifeste, un script généré et toute configuration d’exécution approuvée. Le backend de l’application doit conserver l’authentification, la facturation, l’identité utilisateur, le stockage à long terme et les secrets de production en dehors de cet espace de travail.

Pour un analyste de données IA, le bac à sable gère généralement ces tâches :

Tâche du bac à sable	Pourquoi elle appartient ici
Préparation des fichiers	Le CSV téléchargé peut être scanné et copié dans un répertoire de travail isolé avant que Python n’y touche.
Inspection du schéma	L’application peut déduire les noms de colonnes, types, taux de nullité, nombre de lignes et valeurs d’échantillon sans exposer l’intégralité du fichier au modèle.
Exécution Python	Le code généré par le modèle s’exécute loin du serveur d’application et peut être limité dans le temps.
Préparation des paquets	Seules les dépendances approuvées sont installées ou mises à disposition de la tâche.
Rendu des graphiques	Les images de tracés sont écrites sous forme de fichiers et examinées avant le téléchargement.
Conditionnement des résultats	Les artefacts finaux peuvent être collectés depuis un répertoire de sortie connu.
Nettoyage	Les fichiers temporaires, le code généré et l’état de session peuvent être supprimés ou autorisés à expirer.

Gardez le prompt du modèle plus petit que les données. Envoyez un résumé du schéma, quelques lignes représentatives si la politique le permet, des descriptions de colonnes, l’intention de l’utilisateur et des contraintes telles que « n’entraîne pas de modèle » ou « utilise uniquement les paquets approuvés ». Le jeu de données brut doit rester dans le système de fichiers du bac à sable, sauf si votre produit a une raison spécifique et examinée d’en exposer davantage.

Comment le Téléchargement CSV et l’Inspection du Schéma devraient-ils fonctionner ?

Commencez par traiter chaque téléchargement comme une entrée non fiable. Validez le type de fichier, la taille, l’encodage, le délimiteur, le nombre de lignes, le nombre de colonnes et les formules suspectes avant que le modèle n’intervienne. Un CSV peut encore contenir des valeurs qui déclenchent l’exécution de formules de tableur lorsqu’elles sont ouvertes ultérieurement. Les fichiers exportés doivent donc être nettoyés pour le format cible également.

Un flux de téléchargement pratique ressemble à ceci :

1. L’utilisateur télécharge un CSV vers l’application.
2. Le backend stocke le fichier original sous une clé d’objet ou un chemin de préparation dédié à la tâche.
3. Le backend crée une session de bac à sable pour la tâche.
4. Le backend copie le fichier dans un répertoire de travail du bac à sable.
5. Un petit script d’inspection déterministe lit le fichier et produit un résumé du schéma.
6. Le modèle reçoit le résumé du schéma, la question de l’utilisateur, les bibliothèques autorisées et les exigences de sortie.

L’étape d’inspection doit être un code déterministe que vous possédez, et non un code généré par le modèle. Elle peut produire un résumé JSON compact comme celui-ci :

{
  "file": "sales.csv",
  "rows": 84231,
  "columns": [
    {"name": "order_date", "type": "date", "null_rate": 0.01},
    {"name": "region", "type": "string", "sample_values": ["NA", "EMEA", "APAC"]},
    {"name": "revenue", "type": "number", "null_rate": 0.0}
  ],
  "safe_sample_rows": 5
}

Ce résumé donne au modèle suffisamment de contexte pour rédiger une analyse sans lui remettre l’intégralité du jeu de données. Pour les charges de travail sensibles, réduisez ou supprimez les valeurs d’échantillon, masquez les colonnes ou exigez que l’utilisateur approuve les colonnes pouvant être utilisées.

Comment le Modèle Génère-t-il et Exécute-t-il Python en Toute Sécurité ?

Le modèle doit produire un plan avant de produire du code. Un bon plan nomme les colonnes qu’il utilisera, les transformations qu’il compte effectuer, les graphiques qu’il prévoit de créer et les fichiers de sortie qu’il écrira. Cela donne à votre application un point de contrôle pour la politique et la révision par l’utilisateur.

Une fois le plan accepté, demandez du Python qui respecte un contrat strict :

• Lire les fichiers d’entrée uniquement depuis un répertoire input/.
• Écrire les artefacts uniquement dans un répertoire output/.
• Utiliser uniquement les paquets approuvés.
• Éviter les appels réseau, sauf si la politique de la tâche les autorise explicitement.
• Afficher un résumé structuré à la fin.
• Échouer clairement lorsque des colonnes obligatoires sont manquantes.

À un niveau conceptuel, la boucle d’orchestration ressemble à ceci :

job = create_analysis_job(user_id, uploaded_file)
sandbox = create_sandbox(job_id=job.id, timeout_seconds=300)

copy_file_to_sandbox(uploaded_file, sandbox_path="/work/input/data.csv")
schema = run_owned_schema_inspector(sandbox, "/work/input/data.csv")

plan = ask_model_for_analysis_plan(
    user_question=job.question,
    schema=schema,
    allowed_packages=["pandas", "numpy", "matplotlib"],
    output_contract={"directory": "/work/output", "formats": ["png", "csv", "json"]},
)

review_policy(plan)

script = ask_model_for_python(plan=plan, schema=schema)
review_static_code_policy(script)

result = run_python_in_sandbox(
    sandbox=sandbox,
    script=script,
    working_dir="/work",
    timeout_seconds=120,
    memory_limit_mb=1024,
)

artifacts = collect_outputs(sandbox, "/work/output")
review_outputs(artifacts)
return_answer_to_user(result.summary, artifacts)

Ceci est du pseudo-code, pas un contrat SDK produit. L’essentiel est la frontière : le code généré est examiné, exécuté avec un temps limite, contraint à des répertoires connus, et suivi d’une collecte et d’une révision des sorties.

Si le script échoue, renvoyez le message d’erreur et un petit extrait de code au modèle pour réparation. N’envoyez pas de journaux illimités. La réparation d’erreur doit conserver la même politique de paquets, fichiers, réseau et sortie que la première tentative.

Accès Contrôlé aux Paquets Python pour l’Analyse de Données IA

L’accès aux paquets est l’endroit où de nombreuses démonstrations d’analyse de données IA deviennent risquées. Un modèle peut demander une bibliothèque parce qu’il l’a vue dans un tutoriel, parce qu’un nom de paquet semble plausible, ou parce que le prompt de l’utilisateur l’a suggérée. Votre application ne doit pas transformer ces suggestions en installations de paquets non restreintes.

Utilisez une politique adaptée à la sensibilité des données :

Politique de paquets	Meilleure adaptation	Compromis
Image préconstruite uniquement	Charges de travail de production avec des besoins d’analyse prévisibles	Flexibilité la plus faible, surface de révision la plus simple
Paquets sur liste blanche	La plupart des assistants d’analyse CSV	Bon équilibre pour pandas, le traçage et les paquets statistiques courants
Installations avec version figée	Tâches d’analyse reproductibles	Nécessite une maintenance des paquets et une révision des vulnérabilités
Miroir interne en cache	Entreprises ou flux de données réglementés	Plus de travail opérationnel, meilleur contrôle de la chaîne d’approvisionnement
Installations approuvées par l’utilisateur	Outils exploratoires pour utilisateurs de confiance	Plus flexible, mais plus lent et nécessite des avertissements clairs

Pour une première version de production, commencez par un environnement préconstruit ou une liste blanche courte. La plupart des questions CSV peuvent être résolues avec un petit ensemble de bibliothèques : pandas, numpy, matplotlib, seaborn, scipy, et parfois scikit-learn. Si une tâche a besoin d’un autre paquet, demandez au modèle d’expliquer pourquoi, puis acheminez cette demande via une approbation humaine ou un workflow de révision de paquets.

Enregistrez le nom du paquet, la version, le registre source, le temps d’installation et la raison pour laquelle le paquet a été demandé. Si votre équipe de sécurité utilise des scanners de dépendances ou des registres privés, intégrez ce processus au lieu de laisser l’agent le contourner.

Comment Valider les Graphiques et les Fichiers de Sortie

Les fichiers générés font partie de l’expérience produit, mais ils font également partie de la frontière de confiance. Un graphique peut être erroné. Un CSV peut contenir des valeurs de type formule. Un notebook peut inclure du code caché. Un ZIP peut contenir des chemins inattendus. Traitez les sorties comme des artefacts à inspecter, pas seulement comme des fichiers à télécharger.

Définissez un contrat de sortie simple :

{
  "required_files": ["summary.json"],
  "optional_files": ["chart-*.png", "filtered-data.csv"],
  "blocked_extensions": [".exe", ".sh", ".bat", ".html"],
  "max_total_size_mb": 25
}

Pour chaque tâche terminée, collectez les fichiers uniquement depuis le répertoire de sortie attendu. Validez le type MIME, l’extension, la taille et le chemin. Pour les images, générez des vignettes pour l’aperçu. Pour les exportations CSV, échappez les formules de tableur si le fichier peut être ouvert dans Excel ou Google Sheets. Pour les résumés JSON, validez par rapport à un schéma avant de les utiliser dans l’interface utilisateur.

Offrez aux utilisateurs une étape de révision avant qu’ils ne téléchargent ou ne partagent les résultats. L’écran de révision doit afficher :

• La question originale.
• Le nom du jeu de données et le schéma utilisé.
• Les étapes d’analyse en langage clair.
• Les graphiques et tableaux générés.
• Toutes les colonnes exclues pour des raisons de politique.
• Les avertissements, erreurs, tentatives ou demandes de paquets.

Le modèle peut rédiger une explication narrative, mais l’application doit ancrer cette explication dans les fichiers et les journaux de l’exécution du bac à sable.

Points de Contrôle de Sécurité Avant la Production

Un analyste de données IA est un outil interne utile uniquement si les équipes de sécurité et de plateforme peuvent raisonner sur ce qu’il est autorisé à faire. La révision doit couvrir l’isolation, les limites de ressources, la politique de paquets, le comportement réseau, les secrets, les journaux et la suppression.

Utilisez cette liste de contrôle avant d’aller au-delà d’un prototype :

Point de contrôle	Question à répondre
Frontière d’isolation	Qu’est-ce qui sépare le code et les fichiers d’un utilisateur de l’hôte et des autres utilisateurs ?
Accès aux fichiers	Le code généré peut-il lire uniquement le répertoire de la tâche, ou peut-il voir un stockage plus large ?
Limites de ressources	Qu’est-ce qui limite le temps CPU, la mémoire, le disque, le nombre de processus et le temps réel écoulé ?
Politique réseau	L’accès réseau sortant est-il désactivé, sur liste blanche, proxyé ou complètement ouvert ?
Politique de paquets	Quels paquets peuvent être installés, depuis où, et avec quels contrôles de version ?
Frontière des secrets	Les clés API, les identifiants de base de données et les jetons de service sont-ils gardés hors du bac à sable, sauf s’ils sont explicitement délimités ?
Journaux	Les commandes, installations de paquets, erreurs, lectures/écritures de fichiers et artefacts de sortie sont-ils enregistrés ?
Révision humaine	Quels plans, extraits de code, demandes de paquets et sorties nécessitent une approbation ?
Nettoyage	Quand l’état du bac à sable, les fichiers téléchargés, les scripts générés, les journaux et les sorties sont-ils supprimés ?

Évitez les affirmations absolues telles que « le code ne peut pas s’échapper » ou « les données ne peuvent pas fuir ». La norme pratique est plus concrète : définissez la frontière, documentez les contrôles, testez les modes de défaillance et conservez suffisamment de pistes d’audit pour enquêter sur les comportements inattendus.

Pour la politique réseau et de paquets, rappelez-vous que l’installation de dépendances est une forme de sortie réseau, sauf si les paquets proviennent d’une image préconstruite ou d’un miroir contrôlé. Si le jeu de données est sensible, l’accès réseau doit être bloqué ou strictement limité par défaut. Si l’analyste a besoin de données externes en direct, faites-en un outil séparé avec son propre chemin d’approbation et de journalisation.

Utilisation de Novita Agent Sandbox comme Couche d’Exécution

Novita Agent Sandbox fournit des environnements d’exécution isolés et avec état pour les agents IA. La documentation actuelle de Novita décrit la prise en charge de l’exécution de code, de l’installation de dépendances, de l’accès aux fichiers, de l’utilisation de navigateurs et de la préservation de l’état d’exécution entre les sessions. Pour un analyste de données IA, ces primitives correspondent directement à la partie exécution de l’architecture : créer un espace de travail de tâche, déplacer des fichiers, exécuter du code d’analyse, collecter des artefacts et nettoyer ou préserver l’état en fonction de la conception de la session.

La documentation du SDK et CLI de Novita Agent Sandbox liste la prise en charge officielle du SDK pour Python et JavaScript/TypeScript, ce qui correspond aux backends d’application courants. La documentation du système de fichiers du bac à sable décrit un système de fichiers isolé avec un espace de stockage fixe de 20 Go pour les bacs à sable, utile pour préparer les fichiers CSV et les artefacts générés dans un espace de travail dédié à une tâche.

Gardez la distinction claire :

• Les conseils de mise en œuvre dans cet article décrivent une architecture générale pour les applications d’analyse de données IA.
• Novita Agent Sandbox peut fournir la couche d’exécution en bac à sable pour ces workflows.
• Votre application conserve la propriété de l’authentification utilisateur, de la politique de conservation des données, de l’approbation des paquets, de la politique réseau, de la révision des sorties et des décisions de publication/déploiement.

Cette séparation aide les équipes à construire avec un modèle de responsabilités clair. Le modèle suggère et explique l’analyse. L’application applique la politique produit. Le bac à sable fournit l’environnement d’exécution contrôlé où le code, les fichiers, les paquets, les graphiques et les journaux peuvent être traités loin du serveur d’application principal.

Conclusion

La conception la plus robuste d’un analyste de données IA n’est pas « laissez le modèle exécuter Python ». C’est une boucle contrôlée : inspecter le jeu de données, demander un plan au modèle, examiner le code généré, l’exécuter dans un bac à sable, collecter les artefacts validés, montrer à l’utilisateur ce qui s’est passé et nettoyer l’état une fois la tâche terminée. Cette structure maintient l’expérience utilisateur rapide tout en donnant aux équipes d’ingénierie et de sécurité des points de contrôle concrets à évaluer avant la production.

Pour les équipes qui construisent ce modèle, commencez modestement : téléchargement CSV, inspection du schéma, une courte liste blanche de paquets, sortie de graphiques, des délais d’attente stricts et un écran de révision visible. Ajoutez un accès plus large aux paquets, des outils réseau, de la persistance et de l’automatisation uniquement après que les frontières sont documentées et testées.

FAQ

Pourquoi un analyste de données IA a-t-il besoin d’un bac à sable ?

Il a besoin d’un bac à sable car le workflow combine des fichiers non fiables, du Python généré par le modèle, des demandes de paquets, la génération de graphiques et des artefacts téléchargeables. Exécuter ce travail dans un environnement séparé donne à votre application un endroit pour appliquer des contrôles de fichiers, de ressources, de paquets, de réseau, de journalisation et de nettoyage.

Le modèle doit-il voir l’intégralité du CSV ?

Généralement non. Commencez par envoyer au modèle un résumé du schéma, des échantillons sûrs, des descriptions de colonnes et la question de l’utilisateur. Conservez le fichier brut dans le bac à sable, sauf si votre produit a une raison examinée d’exposer plus de données au modèle.

Les installations de paquets peuvent-elles être autorisées ?

Oui, mais elles doivent être contrôlées. Utilisez une image préconstruite, une liste blanche, des versions figées, un miroir privé ou un workflow d’approbation. Ne laissez pas le code généré par le modèle installer des paquets arbitraires depuis l’internet public sans révision.

Quels fichiers l’application doit-elle retourner aux utilisateurs ?

Retournez uniquement les fichiers validés depuis un répertoire de sortie connu, tels que des images de graphiques, un JSON de résumé et des exportations CSV nettoyées. Bloquez les extensions inattendues, les fichiers volumineux, les chemins cachés et les artefacts qui ne faisaient pas partie du contrat de sortie.

Est-ce une garantie de conformité ?

Non. Un bac à sable est une partie de l’architecture d’exécution. L’approbation de conformité et de sécurité dépend de vos données, de votre modèle de menace, de vos contrôles, de votre journalisation, de votre conservation, de votre processus de révision et de votre environnement de déploiement.

Articles recommandés

• How Agent Sandboxes Power Secure, Scalable AI Innovation
• Building a Coding Agent with Novita’s Agent Sandbox
• Run Harbor Agent Evaluations on Novita Agent Sandbox