Recueil de cas d’usage de Codex

• OpenAI a publié dans sa documentation officielle 12 cas d’usage montrant comment appliquer directement l’outil de codage agentique Codex en conditions réelles, chaque cas incluant l’équipe/catégorie recommandée, un starter prompt et des informations sur les Skills à utiliser
• Classement en 6 catégories : Engineering, Front-end, Data, Integrations, Mobile et Evaluation

1. Relire rapidement une Pull Request (Integration / Automation)

• En ajoutant Codex code review à une organisation ou à un dépôt GitHub, il est possible d’activer des revues automatiques pour toutes les PR
  • Ou de faire une demande manuelle en ajoutant @codex review dans un commentaire de PR
• Starter prompt : @codex review for security regressions, missing tests, and risky behavior changes
• En cas de problème détecté, un commentaire @codex fix it permet de créer immédiatement une tâche cloud de correction et de mettre à jour la PR
• Il est possible de personnaliser le comportement en ajoutant une section de guidelines de revue dans AGENTS.md
  • Exemple : fautes de frappe/erreurs grammaticales → P0, documentation manquante/tests manquants → P1, etc. pour définir les priorités
  • Les instructions du AGENTS.md le plus proche du fichier s’appliquent, ce qui permet de placer des consignes distinctes dans un sous-répertoire pour certains packages
• Cible idéale : les équipes qui ont besoin d’un signal de vérification supplémentaire avant validation de merge, ainsi que les grandes bases de code en production
• Skill utilisé : Security Best Practices — revue ciblée sur les zones à risque comme les secrets, l’authentification ou les changements de dépendances

2. Construire un design front-end responsive (Front-end / Design)

• En fournissant une capture d’écran, un brief design ou une image de référence, Codex convertit cela en code d’interface responsive en réutilisant les composants et tokens du design system existant
• Exigences clés du prompt :
  • réutiliser les composants et le design system existants (sans créer un nouveau système en parallèle)
  • faire correspondre au mieux l’espacement, la mise en page, la hiérarchie et le comportement responsive à la capture
  • respecter les patterns du dépôt pour le routing, la gestion d’état et le data fetching
  • en cas d’ambiguïté, choisir l’implémentation la plus simple puis expliciter les hypothèses retenues
• Avec le skill Playwright, il peut ouvrir un vrai navigateur, comparer le rendu à la capture et itérer sur les corrections
  • Le redimensionnement de la fenêtre permet aussi de vérifier la mise en page sur différents breakpoints
• Cible idéale : démarrer un nouveau projet front-end ou implémenter un écran designé dans une base de code existante
• Pour de meilleurs résultats, il est recommandé de fournir des références dans différents états : desktop/mobile, hover/sélection, écrans vides ou de chargement, etc.

Je vais récupérer les pages détaillées des autres cas d’usage. La navigation est trop longue et coupe le corps du texte. Je vais donc passer à une extraction ciblée du contenu principal avec view_range. J’essaie de récupérer uniquement le corps via curl + grep en bash. La page étant rendue en JavaScript, curl ne permet pas de récupérer le contenu principal. Je vais utiliser l’outil web_fetch pour récupérer chaque page, puis extraire uniquement le contenu après la navigation. Une partie du contenu apparaît. Je récupère maintenant le reste des pages en parallèle. Je vérifie aussi la page api-integration-migrations que j’ai récupérée. J’ai désormais l’ensemble des détails des cas d’usage. Je vais résumer les 10 cas restants dans le même format que les cas 1 et 2 mis en avant.

3. Comprendre une grande base de code (Engineering / Analysis)

Difficulté : Easy | Temps requis : 5 minutes

• Lorsqu’on arrive sur un dépôt inconnu, le point de départ consiste à demander à Codex d’expliquer l’ensemble de la base de code
• Si l’on doit contribuer à une zone précise du système, plus la demande est cadrée, plus l’explication obtenue sera spécifique
• Starter prompt : Explain how the request flows through <name of the system area> in the codebase. Include: which modules own what / where data is validated / the top gotchas to watch for before making changes. End with the files I should read next.
• Cible idéale : nouveaux ingénieurs en onboarding sur un dépôt, développeurs devant comprendre le fonctionnement avant de modifier une fonctionnalité

4. Itérer sur des problèmes difficiles (Engineering / Analysis)

Difficulté : Advanced | Temps requis : Long-running

• En fournissant un script d’évaluation (eval), Codex peut lancer une boucle d’amélioration automatique basée sur un score
• Structure clé du starter prompt :
  • lire AGENTS.md → trouver le script ou la commande qui note la sortie actuelle
  • appliquer une seule amélioration à la fois → relancer la commande d’eval → journaliser le score et les changements
  • s’il s’agit d’une sortie visuelle, l’inspecter directement avec view_image
  • itérer jusqu’à ce que le score global et le score moyen du LLM atteignent tous deux au moins 90 %
• Contraintes : ne pas s’arrêter au premier résultat acceptable / ne pas revenir à une version précédente tant que le nouveau résultat n’est pas clairement moins bon
• Cible idéale : problèmes évaluables à chaque itération, sorties visuelles ou subjectives nécessitant à la fois des vérifications déterministes et des scores de type LLM-as-a-judge, sessions longues où il faut suivre la progression

5. Créer un jeu basé sur le navigateur (Engineering / Code)

Difficulté : Intermediate | Temps requis : Long-running

• Le processus suit l’ordre suivant : brief du jeu → rédaction d’un plan détaillé dans PLAN.md → construction effective du jeu
• Skills utilisés :
  • Playwright : jouer au jeu dans un navigateur réel, inspecter l’état courant, puis ajuster en boucle les contrôles, le timing et le ressenti de l’interface
  • ImageGen : générer le concept art, les sprites, les arrière-plans et les assets UI, tout en conservant les prompts pour des générations en lot ultérieures
  • OpenAI Docs : consulter les guides officiels les plus récents avant d’ajouter des fonctionnalités OpenAI au jeu
• Starter prompt : Use $playwright-interactive, $imagegen, and $openai-docs to plan and build a browser game in this repo. Implement PLAN.md, and log your work under .logs/
• Cible idéale : création d’un jeu navigateur from scratch, développement nécessitant des tests itératifs sur les contrôles, le visuel et le déploiement

6. Analyser un dataset et générer un rapport (Data / Analysis)

Difficulté : Intermediate | Temps requis : 1 heure

• Il peut nettoyer des fichiers de données désordonnés, les joindre, mener une analyse exploratoire puis de la modélisation, et empaqueter le tout en artifacts réutilisables
• Exigences du starter prompt : lire AGENTS.md → charger le dataset → expliquer le contenu des fichiers, les clés de jointure et les problèmes de qualité de données → proposer un workflow reproductible allant de l’import à la visualisation, la modélisation et la sortie du rapport
• Contraintes : privilégier les scripts et artifacts persistés plutôt qu’un état de notebook éphémère / ne pas inventer de valeurs manquantes ni de clés de fusion
• Skills utilisés : Spreadsheet (inspection CSV, TSV, Excel), Jupyter Notebook (analyse exploratoire), Doc (rapport .docx), Pdf (rendu PDF final)
• Cible idéale : travaux d’analyse qui commencent avec des fichiers désordonnés et doivent aboutir à des graphiques, notes, dashboards ou rapports, avec des scripts reproductibles

7. Générer automatiquement un slide deck (Data / Automation)

Difficulté : Easy | Temps requis : 30 minutes

• Il peut éditer directement des fichiers pptx par le code et combiner cela avec la génération d’images pour appliquer, slide par slide, des règles de layout répétables
• Skills utilisés :
  • Slides : création et édition de decks .pptx avec PptxGenJS, avec scripts de rendu et de validation pour vérifier les débordements, chevauchements et polices
  • ImageGen : génération d’illustrations, de cover art, de diagrammes et de visuels de slide, avec maintien d’une direction visuelle réutilisable
• Points clés du starter prompt : ajouter logo.png en bas à droite de toutes les slides / déplacer le texte à gauche sur certaines slides et générer une image à droite / conserver le branding existant / exécuter les vérifications de débordement et de substitution de police avant livraison
• Cible idéale : équipes qui transforment des notes ou des entrées structurées en slides répétables, ou qui reconstruisent un deck à partir de captures, PDF ou présentations de référence

8. Lancer une tâche de code depuis Slack (Integrations / Automation)

Difficulté : Easy | Temps requis : 5 minutes

• Configuration en trois étapes : installation de l’app Slack → connexion du dépôt et de l’environnement → ajout de @Codex dans un canal
• En mentionnant @Codex dans un thread, on peut démarrer une tâche avec la demande, les contraintes et le résultat attendu
• Starter prompt : @Codex analyze the issue mentioned in this thread and implement a fix in <name of your environment>
• Une fois le lien de travail ouvert et le résultat vérifié, il est possible de faire un suivi directement dans Slack si d’autres corrections sont nécessaires
• Conseil : si le thread ne contient pas assez de contexte ou de proposition de correctif, il faut les inclure directement dans le prompt
• Cible idéale : handoff asynchrone démarrant dans un thread Slack, équipes ayant besoin de triage d’issues, de correction de bugs ou d’implémentations cadrées sans changer de contexte

9. Créer une app ChatGPT (Integrations / Code)

Difficulté : Advanced | Temps requis : 1 heure

• Toute app ChatGPT se compose de 3 éléments : un serveur MCP (définition des tools) + un widget React optionnel + la connexion à ChatGPT
• Skills utilisés :
  • ChatGPT Apps : planification des tools, connexion des ressources MCP et guidage du flow de build
  • OpenAI Docs : consultation des guides les plus récents de l’Apps SDK avant d’écrire le code
  • Vercel : usage des guides de l’écosystème Vercel et du serveur MCP officiel de Vercel
• Exigences du starter prompt : choisir un résultat utilisateur principal → proposer 3 à 5 tools avec un nom, une description et des entrées/sorties claires → décider si un widget est nécessaire pour la v1 → privilégier TypeScript pour le serveur MCP et React pour le widget → préciser les besoins en authentification, déploiement et tests
• Sorties attendues : plan des tools / arborescence de fichiers proposée / ensemble de prompts Golden / risques et questions ouvertes
• Cible idéale : première conception d’une app ChatGPT, scaffolding d’un serveur MCP, boucle courte allant des tests HTTPS en local à la validation en mode développeur de ChatGPT

10. Construire des apps iOS et macOS (Mobile / Code)

Difficulté : Advanced | Temps requis : 1 heure

• Du scaffolding d’un projet SwiftUI au build et au debug, le processus privilégie le CLI (xcodebuild ou Tuist)
• S’il existe déjà un projet Xcode, XcodeBuildMCP permet d’itérer sur la liste des targets, le choix du schéma, le build, l’exécution et la capture de captures d’écran
• Skill utilisé : Build iOS Apps — build et refactor de UI SwiftUI, adoption de patterns iOS récents comme Liquid Glass, audit des performances runtime sur simulateur et debug
• Contraintes du starter prompt : rester en priorité sur le CLI / réutiliser les modèles, patterns de navigation et utilitaires partagés existants / conserver la compatibilité iOS et macOS sauf si le périmètre est explicitement limité / exécuter une petite boucle de validation après chaque changement
• Sorties attendues : scaffold de l’app ou tranche fonctionnelle demandée / scripts de build et d’exécution / étapes minimales de validation exécutées / spécification du schéma, du simulateur et des vérifications utilisées
• Cible idéale : apps SwiftUI greenfield scaffoldées par Codex, ou projets Apple existants nécessitant schémas, sorties simulateur, captures d’écran et automatisation UI

11. Transformer un design Figma en code (Front-end / Design)

Difficulté : Intermediate | Temps requis : 1 heure

• Via le serveur MCP Figma, il récupère un contexte de design structuré, les variables, les assets et les variantes exactes, puis les convertit en code aligné sur le design system du dépôt
• Skills utilisés :
  • Figma : démarrer par get_design_context, puis get_screenshot pour récupérer le contexte et la capture avant l’implémentation / utiliser le mapping Code Connect pour relier les composants publiés à leurs fichiers source / créer des règles de design system propres au projet pour un workflow Figma-to-code répétable
  • Playwright : vérifier le comportement responsive dans un vrai navigateur, comparer au référentiel Figma et itérer sur les corrections
• Flux clé du starter prompt :
  1. récupérer le contexte exact du nœud ou frame avec get_design_context
  2. si la réponse est tronquée, cartographier la structure du fichier avec get_metadata puis ne récupérer à nouveau que les nœuds nécessaires
  3. obtenir avec get_screenshot la capture exacte de la variante à implémenter
  4. télécharger les assets puis commencer l’implémentation — réutilisation obligatoire des composants existants et des design tokens, sans créer de système séparé
  5. si Figma renvoie des images localhost ou des sources SVG, les utiliser telles quelles, sans placeholders ni ajout d’un nouveau package d’icônes
  6. vérifier l’UI dans le navigateur avec Playwright, puis corriger en boucle les écarts visuels et d’interaction
• Recommandations de préparation du fichier Figma :
  • utiliser des variables ou des design tokens pour les couleurs, la typographie et l’espacement
  • transformer les éléments UI répétés en composants, éviter de répéter des calques détachés
  • exploiter autant que possible auto layout plutôt qu’un positionnement manuel
  • nommer les frames et les calques de façon à distinguer clairement écran, état et variante
  • conserver les vraies icônes et images dans le fichier
• Les sorties du MCP Figma (au format React + Tailwind) doivent être considérées comme une référence structurelle ; le style final du code doit être traduit selon les utilitaires, wrappers de composants, système de couleurs, échelle typographique, tokens d’espacement, routing, gestion d’état et patterns de data fetching réellement utilisés dans le projet
• Cible idéale : implémentation dans une base de code existante d’écrans ou de flows déjà finalisés dans Figma, équipes souhaitant que Codex travaille à partir d’un contexte de design structuré

12. Mettre à niveau une intégration API (Evaluation / Code)

Difficulté : Intermediate | Temps requis : 1 heure

• Il met à niveau une intégration OpenAI API existante vers les modèles et fonctionnalités API les plus recommandés, tout en vérifiant l’absence de régressions
• Skill utilisé : OpenAI Docs — consulter les guides les plus récents sur les modèles, les migrations et l’API avant de modifier le code
• Exigences du starter prompt :
  • dresser l’inventaire des hypothèses actuelles du dépôt sur les modèles, endpoints et tools
  • établir le plan de migration minimal vers le chemin pris en charge le plus récent
  • conserver le comportement existant sauf si un changement est requis par la nouvelle API ou le nouveau modèle
  • mettre à jour les prompts selon les recommandations les plus récentes pour les modèles
  • signaler les changements de prompt, de tool ou de format de réponse nécessitant une revue manuelle
• Cible idéale : équipes migrant depuis d’anciens modèles ou interfaces API, avec besoin d’une migration conservatrice du comportement accompagnée de validations explicites