Dernière mise à jour : 8 septembre 2026. Informations vérifiées à partir de la publication de recherche d’OpenAI du 6 septembre 2026 et de la documentation actuelle d’OpenAI Agents SDK.
Un agent peut travailler plusieurs heures, mais une tâche réussie peut encore nécessiter une intervention humaine : la solution la plus rapide consiste à classer les outils en actions en lecture seule, écritures réversibles et opérations externes à haut risque, puis à suspendre l’exécution aux points critiques, à persister l’état et à reprendre dans un espace de travail isolé. Cette procédure convient si vous utilisez Codex ou un agent de recherche pour modifier du code, lancer des expériences, analyser des données ou piloter des outils macOS.
Cet article s’adresse aux équipes de recherche qui veulent diminuer l’attente humaine sans laisser un agent agir sans contrôle, aux ingénieurs de plateforme qui construisent une file d’approbation transférable, et aux responsables techniques qui doivent séparer les tâches Xcode, audio, vidéo ou design exécutées sur un Mac distant du reste de l’infrastructure.
Le bon compromis : superviser les effets, pas chaque réponse du modèle
Le point de départ n’est pas de demander à un chercheur de regarder chaque étape produite par Codex. Ce fonctionnement transforme la supervision en travail manuel permanent et ne protège pas nécessairement les ressources partagées. À l’inverse, une approbation unique pour toutes les actions mélange une requête de lecture, une modification locale et une écriture externe irréversible.
OpenAI indique, dans sa publication du 6 septembre 2026, avoir atteint en interne un objectif d’« Automatic Research Intern » tout en précisant que les tâches complexes réussies demandent encore souvent une orientation humaine. Cette observation concerne le dispositif de recherche et sa méthode de mesure ; elle ne constitue pas une promesse de taux de réussite ou de productivité pour votre équipe. Consultez la publication de recherche d’OpenAI avant d’extrapoler ce résultat à vos propres agents.
Pour votre déploiement, proposez plutôt trois niveaux :
| Niveau de décision | Exemples d’actions | Décision recommandée | Preuve à conserver |
|---|---|---|---|
| Lecture seule | Lire un dépôt, interroger un jeu de données temporaire, consulter les journaux | Exécution automatique si les ressources sont déjà autorisées | Nom de l’outil, paramètres résumés, résultat |
| Écriture réversible | Créer un fichier temporaire, produire un correctif Git, lancer une expérience isolée | Approbation conditionnelle ou automatique selon le dépôt et l’espace de travail | Diff, identifiant de l’environnement, résultat de reprise |
| Effet externe ou difficilement réversible | Publier un artefact, modifier une base partagée, déclencher un service ou envoyer des données | Approbation humaine obligatoire | Identité de l’approbateur, portée, version, résultat et éventuel retour arrière |
L’approbateur doit voir les paramètres observables de l’appel d’outil, la cible, la version du dépôt et la portée des écritures. Il ne doit pas être invité à inspecter une chaîne de pensée cachée, à en déduire une intention privée du modèle ou à valider une justification narrative qui ne correspond pas aux effets techniques.
Première étape : transformer les opérations en décisions vérifiables
Avant de connecter un modèle, découpez chaque tâche de recherche en cinq familles opérationnelles : inférence, modification de fichiers, commande Shell, soumission d’expérience et écriture dans un système externe. Ce découpage évite qu’une capacité comme « exécuter du code » devienne une autorisation indifférenciée.
Pour chaque outil, documentez les éléments suivants :
- les entrées acceptées et leur type ;
- les fichiers ou services pouvant être touchés ;
- le caractère réversible de l’action ;
- la présence éventuelle d’un réseau, d’un secret ou d’une ressource partagée ;
- le propriétaire responsable de l’approbation ;
- la procédure de reprise après refus ou expiration.
La décision ne doit pas dépendre uniquement du nom de l’outil. Une commande Shell en lecture seule dans un environnement jetable n’a pas la même portée qu’une commande identique exécutée dans un dépôt de production. De même, une modification de code peut rester à faible risque dans une branche temporaire, mais devenir sensible si elle déclenche automatiquement une publication.
Votre matrice de configuration peut prendre cette forme :
| Élément | Mode automatique | Mode avec approbation | Mode interdit ou isolé |
|---|---|---|---|
| Lecture de code et journaux | Oui, dans un dépôt autorisé | Non nécessaire | Accès aux secrets ou données non classifiées |
| Génération de fichiers temporaires | Oui dans un espace jetable | Oui si le fichier sort de l’espace | Écriture dans un répertoire partagé |
| Correctif de code | Non dans la branche protégée | Oui, avec diff visible | Fusion ou publication directe |
| Expérience longue | Oui si les limites sont préconfigurées | Oui avant allocation sensible | Lancement sans quota ni propriétaire |
| Action sur Mac distant | Oui pour l’état local préalablement autorisé | Oui pour Xcode, périphériques ou données externes | Accès transversal entre espaces de travail |
Cette séparation répond à la question de savoir quelles opérations doivent attendre une personne : celles dont la portée, la destination ou l’effet externe ne peuvent pas être bornés automatiquement. Elle ne signifie pas que chaque sortie du modèle doit être relue.
Dans la première heure : état persistant contre conversation fragile
Le premier test utile consiste à prouver qu’un appel d’outil en attente peut survivre à la fermeture du terminal, au redémarrage du processus Agent et au changement d’opérateur. Dans OpenAI Agents SDK, le mécanisme d’interruption permet de suspendre un parcours lorsqu’une approbation est nécessaire ; l’objet d’état doit ensuite être sérialisé et conservé par votre application. La documentation officielle sur l’intervention humaine décrit le principe d’interruption et de reprise, tandis que la référence RunState précise le rôle de l’état sérialisable.
Ne laissez donc pas l’état dans le navigateur du chercheur, dans une mémoire de processus ou dans une conversation difficile à retrouver. Enregistrez au minimum :
- l’appel d’outil en attente et son résumé de paramètres ;
- la version de la tâche et du dépôt ;
- l’identifiant de l’espace de travail et de l’environnement d’exécution ;
- les étapes déjà terminées et le prochain point de reprise.
Ces quatre éléments forment un dossier d’exécution, pas une copie du raisonnement interne du modèle. Avant la persistance, éliminez les clés API, jetons de dépôt, certificats, variables d’environnement sensibles et données qui ne doivent pas franchir la frontière entre l’agent et la file d’approbation. Les informations de contexte servent à l’exécution ; elles ne doivent pas devenir un canal de transport involontaire des secrets. La documentation officielle sur le contexte aide à distinguer les données nécessaires au parcours des données qui doivent rester dans votre coffre de secrets.
Conservez aussi une empreinte de la définition de l’outil. Si le schéma change alors qu’une approbation attend, vous ne devez pas reprendre silencieusement l’ancien accord avec une nouvelle opération.
Première exécution : réversible pour vous, explicite pour l’agent
Ne commencez pas par une publication, une migration ou une expérimentation coûteuse. Sélectionnez un correctif dans une branche temporaire, la création d’un fichier de sortie ou une requête d’analyse en lecture seule. Le but de ce premier essai est de vérifier le comportement d’arrêt, non de démontrer une performance scientifique.
Exécutez successivement les trois chemins suivants :
- approbation : l’agent reprend avec exactement l’appel validé et produit un résultat identifiable ;
- refus : la tâche se termine proprement ou propose un nouveau plan conforme à la politique ;
- absence de réponse : la tâche reste en attente sans exécuter prématurément l’outil.
Un refus n’est pas une erreur réseau. Si votre orchestrateur le traite comme une panne transitoire, il peut relancer indéfiniment une action que l’humain vient précisément de bloquer. Le résultat attendu doit donc contenir un statut explicite, par exemple « refusé », « à replanifier » ou « annulé », avec la raison opérationnelle si votre politique l’autorise.
À chaque essai, sauvegardez le nom de l’outil, un résumé de ses paramètres, l’identité de la personne qui a décidé, la décision, l’horodatage et le résultat de la reprise. La documentation OpenAI Agents SDK consacrée aux résultats est utile pour séparer le résultat de l’exécution de l’état de contrôle de votre application.
Premier jour : file d’approbation ou validation improvisée
Une file d’approbation exploitable ne doit pas afficher uniquement la phrase produite par l’agent. Elle doit rattacher la demande à une tâche, un dépôt, un environnement et une portée technique. Pour plusieurs tâches Codex parallèles, répartissez la responsabilité par combinaison de propriétaire et de niveau de risque, plutôt que de faire tourner une personne sur toutes les demandes.
Un opérateur peut, par exemple, traiter les actions de lecture et les correctifs réversibles d’un espace de recherche donné, tandis qu’un responsable de plateforme garde les opérations externes ou les environnements partagés. La file doit empêcher l’approbation d’un appel destiné à une autre machine ou à une autre branche.
| Champ présenté à l’approbateur | Pourquoi il est nécessaire | Décision possible |
|---|---|---|
| Identifiant de tâche et propriétaire | Évite les validations orphelines | Accepter ou transférer |
| Outil et paramètres résumés | Rend l’effet observable | Accepter, refuser ou demander une nouvelle proposition |
| Dépôt, branche et version | Empêche l’approbation d’un contenu modifié | Rejeter si la version ne correspond plus |
| Hôte et espace de travail | Évite l’erreur de machine cible | Autoriser uniquement l’environnement attendu |
| Écritures et effets externes prévus | Mesure la portée réelle | Exiger un approbateur différent ou bloquer |
| Expiration de la demande | Empêche une décision trop ancienne | Replanifier après dépassement |
La documentation officielle sur l’exécution des agents doit être rapprochée de votre propre système de file : le SDK fournit des mécanismes d’exécution et d’interruption, mais ne définit pas à votre place la rotation des approbateurs, la conservation des journaux ou la politique d’accès à vos dépôts.
Mac distant : séparation nette entre approbation et exécution
Les expériences générales peuvent utiliser un espace de travail jetable, mais les tâches qui exigent macOS, Xcode, des outils audio ou vidéo, un simulateur ou une application graphique doivent être placées dans un environnement Mac distant séparé. L’approbation doit porter sur cet environnement précis : hôte, dépôt, branche, état des fichiers et outils disponibles.
Un Mac distant n’est pas simplement une autre adresse réseau. Il ajoute des risques propres : session graphique laissée ouverte, projet Xcode modifié par une autre tâche, données de test conservées après la fin, accès à des périphériques ou réutilisation d’un répertoire de travail. Si vous devez évaluer la compatibilité de conteneurs et de dépendances avant d’y placer un agent, consultez notre guide sur la compatibilité de Docker sur Mac.
Le tableau de coût doit rester séparé de la décision d’autorisation. Une équipe peut choisir une machine temporaire pour un test court, ou une capacité persistante pour une suite d’expériences qui doit rester disponible ; cela ne modifie pas les droits accordés à l’agent.
| Option d’environnement | Avantage opérationnel | Coût ou contrainte à vérifier | Usage conseillé |
|---|---|---|---|
| Poste de développement partagé | Accès immédiat | Conflits de fichiers, état difficile à nettoyer | Lecture ou démonstration courte |
| Espace Mac distant temporaire | Isolation et suppression programmée | Transfert de données, installation des dépendances | Test Xcode, audio, vidéo ou interface |
| Mac distant réservé | État stable et reprise plus simple | Paiement de la durée réservée, maintenance | Expériences longues et répétées |
| Environnement non isolé | Mise en route rapide | Mélange des secrets, dépôts et sessions | À éviter pour une validation sérieuse |
Si le poste existant ne peut pas maintenir une session indépendante sans gêner les développeurs, comparez le Mac mini à acheter ou à louer pour un agent IA. La location ne convient pas à un besoin permanent de forte charge, ni à une équipe qui doit conserver un accès physique ou des périphériques spécifiques ; elle est plus intéressante pour un banc d’essai, un pic de tâches ou une validation avant achat. Les tarifs MacPull doivent être vérifiés au moment de dimensionner la durée, car le coût dépend du mode de mise à disposition retenu.
Dans les quarante-huit heures : transfert, expiration et reprise après dérive
La reprise humaine de l’Automatic Research Intern d’OpenAI n’est pas validée tant que l’équipe n’a testé que le bouton « approuver ». Dans les quarante-huit heures suivant le premier essai, provoquez les incidents qui révèlent les défauts d’orchestration : l’approbateur initial devient indisponible, le processus redémarre, l’état est chargé sur une autre machine, ou la définition d’un outil évolue.
À chaque incident, vérifiez quatre choses :
- la demande reste attribuée à la bonne tâche ;
- le nouvel opérateur possède effectivement les droits nécessaires ;
- aucun outil n’est appelé pendant l’attente ;
- la reprise réutilise la version attendue, et non un état plus récent ou ambigu.
Pendant l’attente, gelez les entrées critiques : version du dépôt, données utilisées, modèle sélectionné, consigne applicable, schéma de l’outil et identifiant de l’espace de travail. Au moment de reprendre, comparez ces éléments. Si le modèle, le schéma, la consigne ou l’environnement a changé, l’ancien accord n’est plus automatiquement valable. Il faut replanifier ou demander une nouvelle approbation.
Sur un Mac distant, un refus peut donc être récupéré sans perdre toute la tâche, à condition que l’étape refusée soit isolée et que l’état précédent soit cohérent. L’agent peut terminer, proposer une variante sans effet externe ou attendre une nouvelle décision. Il ne doit pas contourner le refus en reformulant immédiatement la même commande sous un autre nom.
Liste de contrôle : décider si vous pouvez élargir le pilote
Utilisez cette liste comme condition de sortie du pilote, et non comme simple documentation. Si une case critique reste vide, maintenez les approbations humaines et réduisez la portée des outils.
- [ ] Chaque outil est classé en lecture seule, écriture réversible ou effet externe à haut risque.
- [ ] Le résumé de paramètres montre la cible, la portée et l’environnement, sans exposer les secrets.
- [ ] Un appel interrompu est enregistré dans une base ou une file durable, et non uniquement dans le terminal.
- [ ] La version du dépôt, du modèle, de la consigne et du schéma d’outil est conservée avec la demande.
- [ ] Une approbation ne peut pas être réutilisée pour un autre espace de travail ou une autre version.
- [ ] Le chemin d’acceptation reprend l’appel validé sans exécution anticipée.
- [ ] Le chemin de refus arrête ou replanifie la tâche sans boucle de nouvelle tentative automatique.
- [ ] Une demande non traitée reste en attente ou expire explicitement.
- [ ] Un autre opérateur autorisé peut reprendre la file après l’indisponibilité du premier.
- [ ] Un redémarrage du processus ne fait perdre ni l’appel d’outil ni les étapes terminées.
- [ ] Les tâches macOS, Xcode, audio, vidéo et interface disposent d’un espace de travail identifiable.
- [ ] Le nettoyage de l’environnement distant est vérifié après la fin ou l’annulation.
- [ ] Une revue indépendante confirme le résultat final au lieu de considérer l’approbation comme une validation scientifique.
- [ ] La journalisation permet de distinguer sortie du modèle, état d’agent, décision humaine, fichiers modifiés et résultat d’exécution.
Cette liste couvre aussi les tâches créatives : un agent peut préparer une session audio, exporter une séquence vidéo ou modifier un projet de design sur Mac, mais la validation de l’export, la conservation des fichiers sources et l’écriture dans un stockage partagé doivent rester séparées de la génération.
Première semaine : promouvoir selon les preuves, pas selon l’ambition
Au cours de la première semaine, regroupez les exécutions par type de tâche et consignez la raison de chaque intervention, le temps d’attente, les refus, les effets secondaires répétés et le résultat d’une vérification indépendante. Ces informations servent à choisir une politique, non à reproduire directement les mesures internes d’OpenAI.
Ne passez à des tâches plus longues ou à davantage d’agents parallèles que si quatre conditions sont réunies : l’état se restaure, les permissions bloquent réellement les actions interdites, les espaces de travail restent isolés et le résultat final est vérifié séparément. Sinon, réduisez la liste d’outils ou revenez à une exécution manuelle.
Le résultat peut conduire à trois décisions différentes :
| Résultat du pilote | Décision de déploiement | Action suivante |
|---|---|---|
| État fiable, refus correctement appliqué, espace isolé | Élargissement contrôlé | Ajouter des tâches réversibles et des approbateurs secondaires |
| Reprise fiable mais trop d’attente humaine | Automatisation conditionnelle | Autoriser seulement les outils bornés par règle |
| Dérive d’environnement, doublons ou refus contournés | Maintien ou retour arrière | Corriger l’orchestrateur avant d’ajouter des agents |
| Dépendance forte à macOS ou aux interfaces graphiques | Environnement dédié | Constituer un pool Mac distant séparé du calcul général |
Le cadre proposé ici s’appuie sur les capacités documentées d’OpenAI Agents SDK, notamment l’interruption, la sérialisation de l’état et l’exécution persistante ; OpenAI n’a pas publié une architecture universelle de reprise humaine applicable à tous les agents de recherche. Le SDK ne supprime pas les effets externes, ne remplace pas une politique de permissions et ne transforme pas une décision humaine en validation de la qualité scientifique. Pour approfondir les mécanismes d’exécution continue et d’observation, consultez aussi la documentation de diffusion des événements du SDK.
Si votre solution actuelle repose sur un poste partagé, une session laissée ouverte ou une machine difficile à nettoyer, ses défauts sont concrets : les tâches se disputent les fichiers, une approbation peut viser le mauvais environnement, et une panne de session peut forcer une nouvelle exécution complète. Après le premier test de pause et de reprise, vous pourrez donc comparer objectivement cette organisation avec un Mac distant isolé fourni par MacPull, surtout pour les tâches temporaires qui exigent macOS, Xcode ou des outils audio et vidéo. Pour un besoin permanent, l’achat d’un Mac local peut rester plus rationnel ; pour un banc d’essai ou une capacité transitoire, une location vous permet de séparer l’environnement sans immobiliser immédiatement une machine dédiée.