Les agents ne se limitent plus à une succession de trois appels. Ils peuvent inspecter des fichiers, exécuter des commandes, utiliser un navigateur, modifier un projet et travailler sur une tâche pendant une durée importante. En avril 2026, OpenAI a notamment présenté une évolution de son Agents SDK incluant des environnements sandbox contrôlés et une séparation plus nette entre le harness et le compute.
Cette autonomie augmente la valeur, mais aussi l’impact d’une erreur. Un agent peut répéter une mauvaise action, suivre une instruction malveillante contenue dans un fichier ou poursuivre une stratégie coûteuse pendant des heures. La fiabilité doit donc être conçue au niveau de la plateforme.
Les SDK, modèles et primitives de sandbox évoluent rapidement. Vérifier les versions et conditions au moment de l’implémentation.
Le modèle ne constitue pas l’agent
Un système agentique comprend :
- un modèle ;
- un harness qui gère la boucle ;
- des instructions ;
- des outils ;
- une politique ;
- un environnement d’exécution ;
- un état ;
- une mémoire ;
- des approbations ;
- de l’observabilité ;
- un mécanisme d’arrêt.
La qualité du modèle compte, mais le harness détermine comment il planifie, interprète un résultat, réessaie, compacte le contexte et termine.
Un modèle plus capable dans un environnement trop permissif augmente parfois le risque plus vite que la productivité.
Définir une unité de travail
Une tâche longue doit être bornée par un contrat :
- objectif ;
- entrée ;
- artefacts attendus ;
- critères d’acceptation ;
- interdictions ;
- budget ;
- durée ;
- propriétaire ;
- état final ;
- procédure d’escalade.
Éviter les objectifs ouverts comme « améliore le projet ». Préférer « corriger ces trois scénarios, ajouter les tests et produire une pull request sans modifier le schéma de données ».
L’agent doit pouvoir déclarer qu’il est bloqué ou que les critères sont contradictoires.
Séparer le harness du compute
Le harness orchestre la conversation, les outils, la politique et l’état. Le compute exécute les commandes dans une sandbox : conteneur, VM, navigateur isolé ou environnement spécialisé.
Cette séparation permet :
- de remplacer le compute ;
- de limiter ressources et réseau ;
- de détruire l’environnement ;
- de conserver l’état utile ailleurs ;
- de paralléliser ;
- de reprendre après panne ;
- d’auditer les actions.
La sandbox est éphémère par défaut. Les artefacts explicitement sélectionnés sont copiés dans un stockage durable après contrôle.
Outil local de cadrage
Atelier de cadrage
Structurez les décisions principales avant de lancer un atelier métier. Les réponses restent dans votre navigateur.
Architecture séparant le harness agentique, le modèle, la politique, le compute en sandbox, les outils, secrets, checkpoints et la supervision.
Appliquer le moindre privilège aux outils
Chaque tâche reçoit une liste de capacités, pas les droits de l’utilisateur complet. Les outils sont classés :
- lecture locale ;
- lecture externe ;
- proposition ;
- écriture réversible ;
- action irréversible ou à fort impact.
Lire un dépôt n’autorise pas à publier. Préparer un email n’autorise pas à l’envoyer. Générer une migration n’autorise pas à l’exécuter en production.
Les permissions sont temporaires, limitées à une ressource et révocables. Un outil non déclaré est inaccessible.
Contrôler le réseau
L’accès Internet complet est rarement nécessaire. Prévoir :
- aucun réseau ;
- allowlist de domaines ;
- proxy journalisé ;
- téléchargements limités ;
- upload interdit ;
- inspection des types et tailles ;
- résolution DNS contrôlée.
Le contenu téléchargé est non fiable. Il est analysé dans un espace séparé et ne peut pas modifier les instructions système.
Le scénario le plus dangereux combine une source externe malveillante, un secret, un outil d’écriture et un réseau sortant. La politique doit empêcher cette composition.
Fournir les secrets à la demande
Un secret n’est jamais inscrit dans le prompt ni dans l’image de la sandbox. Un broker délivre un jeton court, limité à l’action, avec une audience et une durée.
Le journal indique qu’un accès a eu lieu sans enregistrer la valeur. Les secrets sont révocables et renouvelables. Lorsque possible, l’outil effectue l’opération pour le compte de l’agent sans lui remettre le secret brut.
Un agent n’obtient pas des identifiants de production pour préparer un rapport.
Budgéter l’autonomie
Une tâche longue possède plusieurs budgets :
- temps ;
- étapes ;
- tokens ;
- appels modèle ;
- coût ;
- CPU ;
- mémoire ;
- stockage ;
- réseau ;
- erreurs et retries.
À l’approche d’une limite, l’agent résume son état, sauvegarde les artefacts et demande une décision. Il ne poursuit pas automatiquement avec une dépense supérieure.
Les retries utilisent backoff et idempotence. Une erreur permanente n’est pas répétée cent fois.
Sauvegarder des checkpoints utiles
Le contexte du modèle n’est pas un stockage durable. Un checkpoint contient :
- objectif et contraintes ;
- plan courant ;
- étapes terminées ;
- décisions ;
- fichiers modifiés ;
- résultats de tests ;
- erreurs ;
- prochaine action ;
- budget restant ;
- version des outils et du modèle.
Le checkpoint est atomique et versionné. La reprise vérifie que l’environnement n’a pas changé. Si une action a peut-être réussi avant la panne, une clé d’idempotence ou une lecture d’état évite le doublon.
Compacter la mémoire sans effacer les contraintes
Sur une longue tâche, le contexte doit être résumé. Une mauvaise compaction peut perdre une interdiction ou une décision.
Séparer :
- instructions immuables ;
- faits vérifiés ;
- décisions ;
- historique compressible ;
- artefacts externes ;
- résultats d’outils.
Le résumé est structuré et contrôlé. Les contraintes de sécurité ne sont jamais uniquement présentes dans un texte produit par le modèle.
Détecter les boucles et la dérive
Les signaux sont :
- mêmes commandes ;
- mêmes erreurs ;
- fichiers modifiés puis annulés ;
- absence de progression ;
- plan qui s’élargit ;
- multiplication d’outils ;
- coût sans artefact ;
- critères d’acceptation ignorés.
Le harness calcule des indicateurs de progression et arrête après un nombre de cycles. L’agent produit un diagnostic et demande de l’aide.
Introduire des approbations aux bons endroits
Demander une confirmation à chaque lecture rend le système inutilisable. Ne jamais en demander avant une action critique est dangereux.
Les portes typiques :
- accès à une nouvelle donnée sensible ;
- ajout d’un domaine réseau ;
- utilisation d’un secret ;
- écriture externe ;
- envoi ;
- publication ;
- dépense ;
- suppression ;
- changement de permissions ;
- passage en production.
L’écran d’approbation explique l’action, la cible, les données, le risque, l’alternative et la possibilité d’annuler.
Produire des artefacts vérifiables
Le résultat ne doit pas être uniquement une phrase « tâche terminée ». Il comprend :
- fichiers ;
- diff ;
- rapport ;
- sources ;
- tests ;
- logs synthétiques ;
- décisions ;
- limites ;
- éléments non terminés.
Les artefacts passent des contrôles de malware, secret, format et taille avant de quitter la sandbox.
Observer sans tout enregistrer
Les traces servent à comprendre les erreurs, mais peuvent contenir des données. Séparer :
- métriques ;
- événements d’outils ;
- décisions ;
- prompts masqués ;
- contenus sensibles ;
- artefacts.
La rétention dépend du risque. Les équipes disposent d’un tableau montrant tâches actives, budgets, blocages, erreurs, approbations et kill switch.
Tester les comportements adverses
Les scénarios obligatoires incluent :
- instruction malveillante dans un document ;
- lien vers un domaine non autorisé ;
- tentative d’exfiltration ;
- commande destructive ;
- secret affiché par erreur ;
- boucle ;
- faux succès ;
- panne au milieu d’une écriture ;
- reprise avec version différente ;
- outil indisponible ;
- dépassement de budget.
Le test vérifie le système complet, pas seulement la réponse du modèle.
Concevoir le kill switch et la révocation
L’opérateur doit pouvoir :
- suspendre une tâche ;
- couper le réseau ;
- révoquer les tokens ;
- figer les artefacts ;
- arrêter une classe de tâches ;
- revenir à une version ;
- empêcher les nouvelles exécutions.
La procédure est testée. Un bouton non relié au compute ne constitue pas un arrêt.
Choisir les tâches adaptées
Les meilleurs premiers cas sont bornés, vérifiables et réversibles : analyse documentaire, préparation de tests, rapport sourcé, transformation de fichiers ou proposition de modification.
Éviter d’abord les actions financières, décisions sur des personnes, administration globale ou publication autonome.
Partitech peut construire le harness, les sandboxes, la passerelle d’outils, les politiques, les checkpoints et l’observabilité. L’objectif n’est pas un agent qui « peut tout faire », mais une plateforme capable de prouver ce qu’il a fait, de limiter ce qu’il peut faire et de reprendre proprement lorsqu’il échoue.
Parlons de votre projet
Concevoir et sécuriser une plateforme d’agents longue durée avec Partitech. Contactez Partitech.