La plupart des développeurs utilisent d'abord les agents de codage pour le code : inspecter un dépôt, créer un diff, exécuter des tests et ouvrir une pull request.
C'est encore le cœur de l'activité pour Codex. Mais une grande partie du travail sur un ordinateur passe déjà par du code : exécuter des commandes shell, naviguer sur le web, appeler des API, exporter des documents, répondre à des événements et déclencher des automatismes. Au fur et à mesure que ces surfaces deviennent accessibles à Codex, il ressemble moins à un assistant de codage au sens étroit et plus à un système pour accomplir du travail informatique.
L'application Codex concrétise ce changement. Un fil de discussion peut conserver le contexte, utiliser des outils, faire apparaître des artefacts et continuer d'une invite à l'autre, au lieu de se réinitialiser après chaque échange.
Tirer davantage parti de Codex, c'est utiliser ces capacités ensemble :
- des fils durables qui préservent le contexte
- la voix, le pilotage et la mise en file d'attente pendant que l'utilisateur est encore dans la boucle
- le navigateur, l'utilisation de l'ordinateur, les serveurs MCP et les connecteurs qui permettent à Codex d'agir au-delà d'un dépôt
- les automatismes de fils et les objectifs qui poursuivent le travail en l'absence de l'utilisateur
- le panneau latéral, où les utilisateurs peuvent examiner le code, les documents, les présentations et autres artefacts
Fils durables
Fils durables :
Des fils de discussion Codex de longue durée qui préservent le contexte de travail à travers des sessions répétées.
Les fils épinglés sont un moyen de garder les fils durables à portée de main. Ils sont utiles pour des flux de travail récurrents tels que :
- un fil "Chef de cabinet"
- un fil de publication
- un fil de relecture de documentation
- un fil dédié à la veille externe
Ce sont des espaces de travail persistants, pas des discussions courtes. Codex peut y revenir au fil du temps, en préservant les décisions antérieures, les préférences et le contexte de travail qui autrement devraient être reconstruits de zéro.
Les raccourcis vers les fils épinglés rendent cela pratique. Commande-1 à Commande-9 permettent d'accéder directement aux fils sauvegardés.
Saisie vocale
La saisie vocale est précieuse car elle capture la version brute d'une pensée avant qu'elle ne soit compressée en prose soignée.
Codex dispose d'une saisie vocale intégrée. Elle fonctionne particulièrement bien pour des points de départ vagues, naturels à dire mais maladroits à taper :
Je crois que quelqu'un nommé Ben a mentionné ça dans Slack.
Je ne me souviens pas des détails.
Va voir, s'il te plaît.
Pour un agent capable de chercher, de rassembler du contexte et de faire un rapport, c'est souvent suffisant.
Cela fonctionne aussi bien pour un déversement de pensée de deux ou trois minutes avant que la tâche ne soit complètement formée.
Les transcriptions fonctionnent de la même manière. Une transcription brute de réunion ou une note de planification dictée fournit souvent un meilleur matériau source qu'un résumé court, car elle préserve l'incertitude, l'emphase et les pistes de réflexion inachevées.
Pilotage et mise en file d'attente
La voix devient encore plus utile lorsqu'elle est associée à un contrôle explicite sur une tâche active.
Pilotage :
Interrompre une tâche Codex en cours avec une nouvelle direction avant que l'étape actuelle ne se termine.
Le pilotage est utile lorsque l'agent va dans la mauvaise direction et a besoin d'une correction avant d'avoir terminé. Lors d'une révision de site web, par exemple, l'utilisateur peut interrompre le travail tout en annotant la surface dans le panneau latéral :
- rends ceci plus petit
- l'espacement entre ces deux éléments semble décalé
- ce texte est faux
Mise en file d'attente :
Ajouter du travail à effectuer par Codex après la fin de l'étape en cours.
La mise en file d'attente est différente. Elle n'interrompt pas la tâche en cours. Elle ajoute la tâche suivante à la file. Un utilisateur pourrait dire :
Une fois le travail terminé, envoie le lien de prévisualisation au relecteur dans Slack.
Le pilotage change ce que Codex fait maintenant. La mise en file d'attente change ce qui devrait se passer ensuite. Les deux maintiennent l'utilisateur proche du travail pendant qu'il se déroule.
Outils et portée
Une fois qu'un fil a de la continuité, la question suivante est sur quoi il peut agir. Codex peut se déplacer en couches :
- $browser pour le navigateur intégré dans le panneau latéral, où Codex peut inspecter et annoter des surfaces web
- @chrome pour l'état de navigation connecté et les workflows basés sur Chrome
- @computer pour le travail qui n'existe qu'à travers une interface graphique de bureau
$browser correspond à la révision de navigateur dans le panneau latéral. @chrome correspond au travail de navigation connecté qui dépend du contexte Chrome de l'utilisateur. @computer correspond aux tâches qui n'existent qu'à travers une interface graphique de bureau.
Les serveurs MCP et les connecteurs étendent la même idée au reste d'un workflow. Slack, Gmail et Calendrier comptent car de nombreuses tâches importantes apparaissent d'abord sous forme de messages, d'éléments de boîte de réception ou de problèmes de planification avant de devenir du code.
Les compétences rendent les workflows répétés réutilisables. Une fois qu'un workflow s'avère utile, conditionnez-le en tant que compétence pour que Codex puisse l'exécuter à nouveau sans réapprendre la routine depuis le début.
Travailler de n'importe où
L'application mobile Codex change le moment où l'utilisateur doit être à son bureau. Une tâche peut commencer sur un Mac où les fichiers, les autorisations et la configuration locale existent déjà, puis continuer pendant que l'utilisateur se connecte depuis un téléphone.
Cela compte dans les petits moments. Quelqu'un peut quitter son bureau pendant que Codex exécute une tâche plus longue, répondre à une question depuis l'extérieur, approuver l'étape suivante ou rediriger le fil avant de revenir. L'environnement local reste en place ; l'utilisateur n'a pas à le faire.
Automatismes
Les automatismes exécutent le travail de Codex selon un planning. Utilisez un automatisme planifié lorsque la tâche récurrente doit démarrer à partir d'un espace de travail vierge, comme un rapport quotidien ou une vérification régulière de dépôt. Utilisez un automatisme de fil lorsque le planning doit revenir à une conversation active avec son contexte en cours.
Automatismes de fil :
Des réveils récurrents de type battement de cœur qui reviennent sur le même fil Codex selon un planning.
Les fils épinglés sont utiles, mais ils attendent toujours que l'utilisateur revienne. Un automatisme de fil peut vérifier quelque chose toutes les quelques minutes ou toutes les quelques heures, continuer jusqu'à ce qu'une condition soit remplie, et ajuster la cadence au fil du temps.
Un fil "Chef de cabinet" pourrait s'exécuter toutes les 30 minutes :
Toutes les 30 minutes, vérifie Slack et Gmail pour les messages sans réponse qui nécessitent mon attention.
Aide-moi à prioriser ce qui compte le plus.
Si quelqu'un me pose une question, recherche la réponse aussi profondément que possible et rédige une réponse pour moi, mais ne l'envoie pas.
Lorsque l'utilisateur revient, la partie coûteuse de la collecte de contexte est souvent terminée. L'humain décide toujours de ce qui est envoyé.
Les automatismes de fil s'adaptent également aux boucles de rétroaction. Un automatisme de fil peut surveiller les commentaires de pull request, les commentaires Google Docs ou les réponses Slack et maintenir le travail environnant en mouvement pendant l'absence de l'utilisateur.
Pensez à un workflow d'animation où un relecteur partage une vidéo dans Slack. Un automatisme de fil peut vérifier le fil selon un planning, générer une version mise à jour lorsque des commentaires arrivent, et répondre dans le même fil en taguant le relecteur. Si une intégration ne peut pas terminer le téléchargement final, l'automatisation de bureau peut terminer l'étape via l'interface graphique.
La boucle couvre Slack pour les commentaires, le codebase pour le rendu, et l'automatisation de bureau pour le téléchargement final.
Objectifs
Les objectifs sont les plus puissants lorsque la tâche a une véritable ligne d'arrivée vers laquelle l'agent peut continuer à pousser. Un objectif faible est :
Objectifs :
Des tâches Codex de plus longue durée avec une ligne d'arrivée vers laquelle l'agent peut continuer à travailler au fil du temps.
Implémente le plan dans ce fichier Markdown.
Un objectif plus fort a un critère de succès mesurable.
Par exemple, un ingénieur pourrait migrer un outil interne de Python vers Rust en configurant le nouveau répertoire, en définissant l'objectif, et en rendant la ligne d'arrivée explicite : la nouvelle implémentation n'est pas terminée tant que les tests unitaires ne passent pas.
Un objectif combine une exécution continue avec un vérificateur. L'utilisateur définit le résultat, la condition d'arrêt, et le signal qui indique si Codex se rapproche.
Les vérificateurs utiles incluent :
- une suite de tests
- un benchmark
- une reproduction de bogue
- une matrice de validation
- un workflow de bout en bout qui doit continuer à passer
L'ambition compte, mais sans vérification, ce n'est qu'un vœu.
Le panneau latéral
Le panneau latéral garde le travail à côté de la conversation qui l'a produit. Au lieu d'exporter un artefact et de changer de contexte, l'utilisateur peut le réviser sur place. La sortie peut être du code, mais aussi une présentation, un PDF, une page de navigateur, un tableau ou un autre artefact créé en cours de route.
Il prend en charge quatre tâches particulièrement bien :
- Inspecter les artefacts
- Annoter ce qui doit changer
- Opérer sur les surfaces web
- Réviser les modifications
Le panneau latéral permet aux utilisateurs de réviser sur place du Markdown, des feuilles de calcul, des tableaux de données, des documents et des diapositives. Ils peuvent inspecter, annoter et réviser les artefacts sans interrompre la boucle.
Annotations
La présentation ou le PDF peut rester ouvert à côté du fil qui l'a produit, prêt pour une révision et une réparation directes.
Feuilles de calcul dans Codex
Le navigateur intégré permet à Codex d'inspecter une page rendue, de la contrôler et de répondre aux annotations directement sur la surface en cours de révision. Les commentaires sur une page ou un artefact restent à l'intérieur de la boucle de travail au lieu de devenir une passation séparée.
Le web devient à la fois sortie et surface de contrôle. Codex peut construire un artefact, l'ouvrir dans le panneau latéral, l'inspecter, le déboguer et continuer à affiner le même objet sur place.
Ces surfaces fonctionnent particulièrement bien :
- index.html pour les artefacts statiques légers
- Storybook pour la révision d'interface utilisateur
- Remotion Studio pour l'animation programmatique
- les présentations basées sur navigateur pour les exposés
- les applications de données pour les workflows d'analyse
Un seul fichier index.html peut devenir un artefact interactif durable sans nécessiter de serveur. Les automatismes de fil peuvent également rafraîchir les artefacts statiques au fil du temps, de sorte qu'un fil ait quelque chose de nouveau à attendre lorsque l'utilisateur revient.
Mémoire partagée
Les fils de longue durée deviennent plus utiles lorsqu'ils partagent une mémoire en dehors d'une seule conversation.
Mémoire partagée :
Contexte durable stocké en dehors d'un seul fil, afin que les travaux futurs puissent reprendre à partir de quelque chose d'explicite et de révisable.
Un modèle durable consiste à ancrer les fils persistants dans un coffre Obsidian. En pratique, cela signifie un dossier de fichiers plats qui reste simple à inspecter, modifier, déplacer et conserver sur une longue période. Les équipes peuvent stocker ce dossier dans le cloud, Git, Dropbox, Google Drive ou une autre couche de synchronisation qui correspond à leur workflow.
Un coffre pourrait ressembler à ceci :
coffre/
├── TODO.md
├── personnes/
├── projets/
├── agent/
└── notes/
Au niveau supérieur, AGENTS.md peut définir comment Codex doit mettre à jour cet espace de travail à mesure qu'il en apprend davantage sur les personnes, les projets, les décisions et les boucles ouvertes.
Ne copiez pas une structure de coffre exacte. Apprenez à l'agent où le contexte durable doit résider, quel contexte préserver et quand ne pas créer de remous.
Un AGENTS.md pratique pourrait dire :
- Traite ~/coffre comme une mémoire de travail durable.
- Préfère les notes canoniques à la prolifération de notes.
- Achemine explicitement les TODOs, les personnes, les projets, les résumés quotidiens et les notes de brouillon.
- Préserve les décisions, les blocages, les responsables, les dates et les liens utiles.
- Si rien de significatif n'a changé, ne remue pas le coffre.
Les dépôts contiennent le code. Le coffre contient le contexte roulant : les personnes impliquées, ce qui a changé, ce qui est bloqué, ce qui nécessite un suivi et ce qui disparaîtrait autrement entre les sessions.
Un contexte important ne devrait pas vivre uniquement à l'intérieur d'une transcription de conversation. Écrivez-le quelque part où le prochain fil pourra le reprendre.
Codex dispose également de fonctionnalités de mémoire propriétaires dans Réglages > Personnalisation > Mémoires. Elles fournissent une couche de rappel locale pour les préférences, les workflows récurrents et les pièges connus. Elles complètent le contexte écrit explicite, sans le remplacer. Chronicle va dans le même sens en aidant Codex à construire une mémoire à partir du contexte récent de l'écran.
Du code vers l'extérieur
Codex part toujours du code. Mais une plus grande partie du travail autour du code est désormais accessible via le même système : serveurs MCP, surfaces de navigateur, contrôles de bureau, automatismes de fil et artefacts révisables.
Cela change le modèle de contrôle. Le pilotage interrompt le travail en cours. La mise en file d'attente organise la tâche suivante. Les automatismes de fil maintiennent un fil actif lorsque l'utilisateur s'éloigne. Les objectifs ajoutent une ligne d'arrivée concrète vers laquelle Codex peut continuer à travailler.
Codex peut désormais porter un workflow de l'instruction à l'exécution, en passant par la révision des artefacts, même lorsque le travail quitte le dépôt.
