Codex élargit fortement sa collection de cas d’usage

• OpenAI a largement remanié la page des cas d’usage de Codex, en l’élargissant de 12 à 52 use cases
• Le positionnement évolue : au-delà du simple assistant de code, Codex est désormais présenté comme une plateforme à laquelle des équipes entières — ingénierie, design, data, finance, opérations, QA, ventes, etc. — délèguent du travail
• Computer Use (automatisation sur Mac), gestion de la boîte de réception Gmail, Slack, Zoom, documents, feuilles de calcul, modélisation financière (DCF, flux de trésorerie, budgets), développement natif iOS/macOS, workflows pour les ventes et le marketing, QA, automatisation, déploiement, Evals et même l’app ChatGPT : l’ensemble est organisé autour de flux de travail réels confiés à Codex

1. Configurer Codex comme collègue de travail (Automation / Integrations)

Difficulté : Easy | Temps requis : Long-running

• Il s’agit de connecter, dans un même thread Codex, les outils où le travail circule réellement — Slack, Gmail, Calendar, Notion, GitHub, Linear, notes locales, etc. — pour l’utiliser comme « un collègue qui connaît le contexte de mon travail »
• Lors de la première exécution, Codex est chargé de repérer les demandes importantes faciles à manquer, les documents modifiés, les décisions enfouies et les handoffs bloqués, puis l’utilisateur lui indique ce qui est utile et ce qui relève du bruit
• Ensuite, il est possible d’ajouter une automatisation au même thread pour lui faire vérifier régulièrement le contexte. Les décisions nécessitant du jugement sont conçues pour être remontées à l’utilisateur plutôt que traitées arbitrairement par Codex
• Public visé : personnes, responsables des opérations, managers, PM et ingénieurs qui doivent suivre en continu un contexte de travail dispersé entre plusieurs outils

2. Transformer le feedback en actions (Data / Integrations)

Difficulté : Easy | Temps requis : 30m

• Le feedback issu de plusieurs sources — canaux Slack, issues GitHub/Linear, CSV d’enquête, notes d’entretiens clients, documents Google Drive, etc. — est rassemblé et structuré dans un livrable révisable au format Google Sheet ou Google Doc
• Codex regroupe les retours par thème, liens de preuve, questions de suivi et actions à attribuer, puis peut prolonger le travail vers une mise à jour Slack ou un brouillon d’issue
• Si les sources de feedback évoluent en continu, on peut ajouter une automatisation au même thread pour ne signaler que les nouveaux thèmes ou les éléments dont les preuves se sont renforcées
• Public visé : équipes qui doivent transformer en actions produit les retours bêta, la voix du client, les threads d’issues et les notes de recherche

3. Nettoyer et préparer des données désordonnées (Data / Knowledge Work)

Difficulté : Easy | Temps requis : 5m

• Lorsqu’un CSV ou une feuille de calcul mélange plusieurs formats de date, des chaînes monétaires, des lignes en double, des valeurs manquantes, des lignes de synthèse ou des alias, on peut demander la création d’une copie nettoyée tout en préservant l’original
• L’utilisateur précise clairement les problèmes déjà visibles et le format de sortie souhaité, par exemple un CSV nettoyé, un fichier prêt à l’import ou un nouvel onglet dans la feuille
• Codex laisse à la fois le fichier nettoyé et une note sur la qualité des données afin qu’un humain puisse vérifier le tout avant analyse ou import
• Public visé : équipes qui doivent remettre en forme des fichiers de données provenant de plusieurs systèmes pour l’analyse ou l’alimentation d’outils opérationnels

4. Interroger des données tabulaires (Data / Knowledge Work)

Difficulté : Easy | Temps requis : 30m

• En posant des questions sur des CSV, feuilles de calcul, exports de dashboard, Google Sheets ou fichiers de données locaux, Codex inspecte les colonnes puis effectue calculs, agrégations et génération de graphiques
• Au-delà d’une simple réponse, le workflow recommandé consiste à produire une visualisation HTML consultable directement dans l’app Codex
• Après une première analyse, on peut enchaîner dans le même thread avec des comparaisons supplémentaires par région, cohorte, produit, semaine, version de modèle ou segment client
• Public visé : métiers pilotés par la donnée ayant besoin de calculs rapides, de graphiques simples ou de résumés pour des réunions

5. Relire des GitHub Pull Requests (Integrations / Workflow)

Difficulté : Easy | Temps requis : 5s

• Il est possible de connecter Codex code review à une organisation ou à un dépôt GitHub pour obtenir une revue automatique sur chaque PR, ou de demander une revue manuellement depuis les commentaires de PR
• L’objectif principal est d’ajouter des signaux de revue que les humains ratent facilement : régressions de sécurité, tests manquants, changements de comportement risqués, documentation absente, etc.
• En documentant dans AGENTS.md les priorités de revue et les règles par fichier, on peut personnaliser les critères de revue de Codex selon le dépôt
• Public visé : équipes ayant besoin de signaux de revue supplémentaires avant le merge, notamment sur de grandes bases de code en production

6. Gérer sa boîte de réception (Automation / Integrations)

Difficulté : Easy | Temps requis : 5m

• En connectant Gmail, Codex repère les emails qui nécessitent une réponse et rédige des brouillons dans le ton de l’utilisateur en s’appuyant sur ses emails récemment envoyés ou sur des exemples d’écriture validés
• Si le contexte manque dans les seuls emails, il peut aller chercher les dernières décisions, responsables, fichiers ou blocages dans des outils de travail comme Slack, Google Drive ou des notes de projet
• La première exécution doit être vue comme une phase de calibration : après avoir donné du feedback sur les emails à ignorer et le ton à adopter, on peut faire évoluer le tout vers une automatisation régulière
• Public visé : personnes souhaitant traiter de façon répétée le tri de la boîte de réception et la rédaction de brouillons de réponse

7. Implémenter un design front-end responsive (Front-end / Design)

Difficulté : Intermediate | Temps requis : 1h

• À partir de captures d’écran, d’un brief design et d’images de référence, Codex les transforme en UI responsive en réutilisant le design system, les tokens et les composants du dépôt existant
• Codex ouvre un vrai navigateur avec Playwright et itère en comparant le résultat sur les breakpoints desktop/mobile avec la référence
• En cas d’ambiguïté, il vaut mieux lui demander de choisir l’implémentation la plus simple conforme aux patterns existants, plutôt que de créer un nouveau design system, tout en explicitant ses hypothèses
• Public visé : implémentation de nouveaux écrans front-end ou intégration d’écrans designés dans une application existante

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

Difficulté : Easy | Temps requis : 5m

• En arrivant sur un dépôt ou une zone fonctionnelle inconnue, on peut demander à Codex d’expliquer le flux des requêtes, la responsabilité des modules, l’emplacement des validations de données, les effets de bord et les fichiers à lire ensuite
• Plus on précise une zone du système plutôt que de demander un résumé global, plus l’explication obtenue est utile en pratique
• Comme questions de suivi, il est recommandé de vérifier où se trouve la logique métier, quels sont les points de validation, quels traitements en arrière-plan sont faciles à manquer et quels tests exécuter après une modification
• Public visé : onboarding de nouveaux ingénieurs et développeurs qui doivent comprendre rapidement le flux du code avant de modifier une fonctionnalité

9. Créer le shell d’une app Mac (macOS / Code)

Difficulté : Advanced | Temps requis : 1h

• En utilisant le plugin Build macOS Apps, on crée le shell d’une app SwiftUI native sur Mac, avec une structure basée sur NavigationSplitView pour la barre latérale, le panneau de détail et l’inspecteur
• Il est recommandé de lui faire concevoir dès le départ une structure naturelle pour une app desktop, avec menus, barre d’outils, raccourcis clavier et scène Settings
• L’objectif est une véritable architecture d’app Mac — et non une simple adaptation étirée d’une app iPad ou web — où fenêtres, état de sélection, commandes et réglages fonctionnent de manière fiable
• Public visé : apps Mac de type éditeur, bibliothèque, outil d’administration ou de revue nécessitant une barre latérale et un inspecteur

10. Contrôler mon ordinateur avec Codex (Knowledge Work / Workflow)

Difficulté : Easy | Temps requis : 5m

• Avec Computer Use, Codex peut voir, cliquer et saisir directement dans des apps Mac afin d’exécuter des tâches en naviguant entre plusieurs apps et fenêtres
• Convient aux tâches situées dans l’interface d’apps classiques sans plugin dédié, par exemple récupérer des informations dans Notes pour les saisir dans un autre système, ou consulter le contenu de Messages et rédiger une réponse
• Il est recommandé de commencer la requête par @Computer et d’indiquer à la fois le résultat souhaité et les actions risquées qu’il faut interrompre
• Cas adaptés : tâches répétitives possibles uniquement dans l’UI d’une app, travail intellectuel impliquant plusieurs fenêtres et fichiers

11. Automatiser le triage des bugs (Automation / Quality)

Difficulté : Intermédiaire | Temps nécessaire : 1 h

• Codex peut parcourir les endroits où se concentrent les signaux de bug, comme les alertes Sentry, les fils Slack, les tickets Linear/GitHub, les échecs de PR, les logs ou les tickets de support
• On commence par un balayage manuel pour établir une liste de candidats, puis on ajuste dans le même fil ce qui est utile avant de passer à une automatisation régulière
• Une fois la confiance suffisante, on peut faire rédiger par Codex des tickets Linear, des mises à jour Slack, des commentaires GitHub et même des brouillons de notes de passation
• Cas adaptés : équipes produit/ingénierie devant prioriser chaque jour des rapports de bug dispersés dans plusieurs outils

12. Générer un deck de slides (Data / Integrations)

Difficulté : Facile | Temps nécessaire : 30 min

• Codex peut modifier directement des fichiers PowerPoint par le code et combiner cela avec la génération d’images pour mettre à jour un deck existant ou en créer un nouveau
• Il faut préciser les règles avant livraison, comme l’emplacement du logo, la disposition du texte et des images sur certaines slides, le respect du branding existant, ainsi que les vérifications d’overflow et de remplacement de police
• Il est recommandé de conserver les slides dans un format .pptx modifiable, Codex appliquant des règles de mise en page répétables slide par slide
• Cas adaptés : équipes qui transforment des entrées structurées ou des notes en supports de présentation, ou qui doivent modifier en masse des decks existants

13. Lancer des tâches de code depuis Slack (Integrations / Workflow)

Difficulté : Facile | Temps nécessaire : 5 min

• Après avoir installé l’app Slack et connecté le dépôt ainsi que l’environnement, il suffit de mentionner @Codex dans un fil pour lancer une tâche de code
• Si la demande, les contraintes et le résultat attendu sont suffisamment détaillés dans le fil, Codex exécute une tâche cloud en s’appuyant sur ce contexte
• Il est ensuite possible d’ouvrir le lien de résultat pour vérifier, puis de poursuivre les ajustements nécessaires dans le même fil Slack
• Cas adaptés : équipes qui veulent déléguer directement depuis une discussion Slack le triage d’un ticket, un correctif de bug ou une petite implémentation

14. Itérer rapidement sur de petits changements UI (Front-end / Design)

Difficulté : Facile | Temps nécessaire : 5 min

• Lorsque la structure de l’app existe déjà, Codex traite rapidement de petits changements UI un par un, comme le spacing, l’alignement, la couleur, le copy, le responsive behavior ou les états
• Il est recommandé d’utiliser un modèle rapide comme Codex-Spark avec une boucle du type « une note visuelle à la fois, une petite modification à la fois, une vérification navigateur à la fois »
• Il faut définir précisément le périmètre du changement et demander la préservation des composants existants, des tokens, des primitives de layout et du flux de données
• Cas adaptés : retouches UI fines issues d’une revue design, changements à appliquer immédiatement pendant une revue produit

15. Coordonner l’onboarding des nouvelles recrues (Integrations / Data)

Difficulté : Intermédiaire | Temps nécessaire : 30 min

• Codex rassemble la liste des nouvelles recrues approuvées, le tracker d’onboarding, la correspondance managers/équipes, l’état de préparation du matériel et des comptes, ainsi que les jalons de calendrier pour produire un pack d’onboarding révisable
• Il est recommandé de garder la première passe en lecture seule, puis de n’autoriser les invitations réelles, DM, e-mails, créations de canaux et mises à jour systèmes qu’après validation explicite
• Il peut aussi préparer des résumés par équipe, les écarts de préparation, les noms des espaces d’accueil, les listes d’invitation, la checklist de première semaine et des brouillons d’annonce
• Cas adaptés : People, Recruiting, IT, Workplace Operations et managers accueillant de nouvelles recrues

16. Apprendre un nouveau concept (Knowledge Work / Data)

Difficulté : Intermédiaire | Temps nécessaire : 30 min

• Codex peut lire des contenus denses comme des articles scientifiques, supports de cours ou longs documents, puis en synthétiser la problématique, les contributions, la méthode, les expériences, les limites et les concepts préalables
• En utilisant des Subagents, on peut répartir les rôles entre compréhension de la structure du document, recherche de connaissances préalables, analyse des figures/formules et rédaction du rapport final
• Le livrable a intérêt à prendre une forme réexaminable plus tard, comme un rapport Markdown, un diagramme Mermaid, une concept map ou un tableau liant affirmations et preuves
• Cas adaptés : personnes devant apprendre rapidement un domaine de recherche inconnu, un concept technique complexe ou un long support de cours

17. Mettre à niveau une intégration API (Evaluation / Engineering)

Difficulté : Intermédiaire | Temps nécessaire : 1 h

• Codex peut migrer une intégration OpenAI API existante vers les modèles et fonctionnalités d’API actuellement recommandés, tout en préservant le comportement et en vérifiant les régressions
• Il ne s’agit pas seulement de changer le nom du modèle : il faut d’abord inventorier les endpoints actuels, les hypothèses sur les tools, le format de réponse, les prompts et le parcours d’évaluation
• Il est recommandé d’utiliser openai-docs pour vérifier les guides récents sur les modèles et les prompts, puis de valider le comportement avant/après avec un pipeline d’eval comme Promptfoo
• Cas adaptés : produits utilisant des modèles ou endpoints anciens, équipes ayant besoin de tests de régression lors d’une montée de version modèle

18. Déployer une app ou un site web (Front-end / Integrations)

Difficulté : Intermédiaire | Temps nécessaire : 30 min

• À partir d’un dépôt, de captures d’écran, d’un brief design, d’une idée produit, d’une documentation API et de sources de données, Codex peut créer ou modifier une web app puis la déployer jusqu’à une URL de preview Vercel
• Le point clé consiste à lui faire exécuter une vérification du projet avant déploiement, les builds/tests, l’analyse des logs d’échec et la validation de la preview
• Même après le déploiement, on peut continuer dans le même fil avec des corrections de layout mobile, l’intégration de données récentes ou la correction d’un build log en échec
• Cas adaptés : équipes voulant transformer rapidement une idée ou un design en preview web partageable

19. Transformer des designs Figma en code (Front-end / Design)

Difficulté : Intermédiaire | Temps nécessaire : 1 h

• Via le serveur MCP Figma, Codex récupère le contexte de design précis d’un nœud, les variables, assets et variants, puis les traduit en code en respectant le design system du dépôt existant
• L’approche recommandée consiste à récupérer d’abord structure et références avec get_design_context, puis get_metadata et get_screenshot si nécessaire, avant de commencer l’implémentation
• Avec Playwright, on compare dans le navigateur le résultat implémenté à la référence Figma afin de corriger de façon itérative les écarts de responsive behavior et d’interactions
• Cas adaptés : équipes design/front-end devant implémenter dans une codebase existante un écran ou un flux finalisé dans Figma

20. Faire la QA d’une app avec Computer Use (Automation / Quality)

Difficulté : Intermédiaire | Temps nécessaire : 30 min

• Computer Use observe l’interface réelle, clique, saisit du texte, fait défiler la page, exécute les principaux parcours utilisateurs et consigne les points d’échec
• Il faut lui indiquer clairement l’environnement, les parcours clés à tester, le format des rapports de bug, les critères de sévérité, les étapes de reproduction ainsi que les résultats attendus et réels
• Il peut détecter à la fois des bugs fonctionnels et des problèmes d’interface, et les résultats sont structurés sous forme de triage summary à transmettre à l’équipe QA ou aux ingénieurs
• Convient pour : la validation des parcours critiques avant une release, les équipes qui veulent structurer leur QA manuelle

21. Analyser des jeux de données et produire des rapports (Data / Analysis)

Difficulté : Intermediate | Temps nécessaire : 1h

• Charge des fichiers de données désordonnés, les nettoie, les joint, réalise une analyse exploratoire, des visualisations et de la modélisation, puis les transforme en rapports ou tableaux de bord utiles à la prise de décision
• Il est important de laisser Codex identifier d’abord l’environnement Python du projet, le gestionnaire de paquets, le dossier de sortie et les conventions de scripts
• Pour le nettoyage répétitif de notebooks, l’export de feuilles de calcul et le packaging du rapport final, il est utile de créer une reusable skill afin de réutiliser plus facilement le même flux d’analyse
• Convient pour : les analystes et équipes produit qui ont besoin de livrables d’analyse reproductibles, du nettoyage des données jusqu’aux graphiques, notes et rapports

22. Traiter les tâches issues de messages (Knowledge Work / Integrations)

Difficulté : Easy | Temps nécessaire : 5m

• Computer Use repère dans un fil Messages des tâches implicites comme des réservations, des recherches, de la coordination d’agenda, l’envoi de reçus ou la collecte d’informations, puis les exécute
• Il est possible de cibler un expéditeur ou un fil précis, puis de lui faire rédiger un brouillon de réponse à renvoyer dans le fil d’origine une fois la tâche terminée
• Pour les actions difficiles à annuler, comme un paiement, une commande ou une confirmation de réservation, il est essentiel de lui demander de s’arrêter et d’obtenir une validation
• Convient pour : les personnes qui veulent traiter sans rien oublier les petites tâches d’exécution nées de messages personnels

23. Passer d’une idée à un PoC (Front-end / Engineering)

Difficulté : Intermediate | Temps nécessaire : 1h

• On crée d’abord une maquette UI de haute qualité avec GPT Image/ImageGen pour définir la direction visuelle, puis on implémente un prototype fonctionnel à partir de cette maquette avec Build Web Apps ou le plugin Game Studio
• Convient aux idées produit en phase initiale pour lesquelles un PoC réellement cliquable apporte plus de réponses qu’un simple plan documentaire
• Il est préférable de joindre les images à implémenter dans un nouveau turn afin que Codex puisse les utiliser directement comme référence
• Convient pour : les équipes qui veulent visualiser et valider rapidement des idées de dashboard, d’outils, d’app web ou de jeux

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

Difficulté : Intermediate | Temps nécessaire : Long-running

• Au lieu de coder directement à partir du brief du jeu, on lui fait d’abord rédiger un PLAN.md contenant l’objectif du joueur, la boucle principale, les contrôles, les conditions de victoire et d’échec, le rendu et le plan des assets
• Avec ImageGen, il crée le concept art, les sprites, les arrière-plans et les assets UI, puis itère avec Playwright en testant les sensations de jeu et l’état de l’écran dans un vrai navigateur
• Comme un jeu exige des vérifications continues du code, de l’UI, des assets, de l’équilibrage et du déploiement, c’est un bon exemple d’usage des itérations longues de Codex
• Convient pour : créer un jeu navigateur de zéro ou itérer sur les sensations de jeu et les visuels d’un prototype

25. Améliorer de façon itérative des problèmes difficiles (Engineering / Analysis)

Difficulté : Advanced | Temps nécessaire : Long-running

• On fournit un système d’évaluation clair, des scripts de scoring et des artefacts vérifiables pour que Codex exécute une boucle d’amélioration guidée par les scores
• On utilise à la fois des deterministic checks et des scores de type LLM-as-a-judge, avec une règle d’arrêt sur l’overall score et la moyenne du judge
• La structure consiste à faire répéter à Codex, à chaque itération, la vérification de la sortie actuelle, la mesure du score, l’application d’une seule amélioration, la réévaluation et la journalisation
• Convient pour : les problèmes d’optimisation qui ne se résolvent pas en une fois, les tâches nécessitant d’améliorer plusieurs fois une qualité visuelle ou subjective

26. Enregistrer un workflow comme Skill (Engineering / Workflow)

Difficulté : Easy | Temps nécessaire : 5m

• Les fils Codex efficaces, règles de revue, commandes de test, checklists de release, règles de design, exemples de rédaction et scripts propres à un dépôt peuvent être enregistrés comme reusable skill
• Avec $skill-creator, on structure quand elle doit s’activer, quels documents et commandes utiliser et quelles sorties sont attendues
• Les skills du répertoire personnel peuvent être utilisées dans tous les repo, tandis que les skills internes au projet peuvent être commit et partagées avec l’équipe
• Convient pour : les équipes qui veulent faire mémoriser à Codex des tâches répétitives au lieu de coller un long prompt à chaque fois

27. Mettre la documentation à jour (Engineering / Code)

Difficulté : Easy | Temps nécessaire : 30m

• Lit en même temps les changements de code, les tests, les notes de release et le contexte des PR/issues pour mettre à jour le README, la documentation développeur, les migration notes et les runbooks
• Il est préférable de faire commencer Codex par repérer dans la documentation existante les noms de features, clés de config, commandes et exemples concernés, puis de ne modifier que le strict minimum
• S’il s’agit d’une documentation publique, il faut lui interdire explicitement de mélanger feuille de route interne, informations clients ou contexte confidentiel
• Convient pour : les équipes de documentation technique et d’ingénierie qui doivent faire évoluer la documentation au rythme des changements du produit

28. Construire une app iOS (iOS / Code)

Difficulté : Advanced | Temps nécessaire : 1h

• Codex scaffold une app iOS en SwiftUI et met en place une boucle de build/exécution CLI-first basée sur xcodebuild ou Tuist
• Sur un projet existant, il peut travailler en vérifiant via XcodeBuildMCP les informations de scheme, simulateur, captures d’écran et automatisation UI
• En ajoutant des skills iOS comme SwiftUI expert, Liquid Glass ou SwiftUI performance, on peut fiabiliser davantage l’implémentation UI, l’adoption des API récentes et les contrôles de performance
• Convient pour : une app SwiftUI greenfield, ou des projets iPhone/iPad existants nécessitant une validation basée sur simulateur

29. Refactoriser une codebase (Engineering / Code)

Difficulté : Advanced | Temps nécessaire : 1h

• Recherche le code mort, la logique dupliquée, les modules trop volumineux, les abstractions vieillissantes et les patterns legacy, puis les remet en ordre par petites unités faciles à relire
• Le refactoring n’est pas une migration de stack mais un travail d’amélioration de la forme du système sans en changer le comportement ; il faut donc préciser que le comportement public doit être conservé
• Il est recommandé d’utiliser un ExecPlan ou une reusable skill pour découper les gros chantiers de nettoyage en checkpoints, puis répéter les tests et validations
• Convient pour : les équipes avec une ancienne codebase où l’ajout de fonctionnalités devient de plus en plus coûteux et qui ont besoin d’un nettoyage à comportement constant

30. Ajouter des App Intents iOS (iOS / Code)

Difficulté : Advanced | Temps nécessaire : 1h

• Identifie les actions et entités clés dans l’app afin de les rendre utilisables sur des surfaces système comme Shortcuts, Siri, Spotlight, les widgets et les contrôles
• Conçoit d’abord non pas l’ensemble de l’écran, mais quelques actions que l’utilisateur voudra pouvoir lancer sans ouvrir l’app, ainsi que les objets que le système doit comprendre
• Le flux consiste à laisser Codex analyser les modèles, la navigation et les chemins d’accès aux données de l’app existante, puis implémenter une première surface d’intent de petite taille
• Convient pour : les apps déjà utiles, mais peu visibles dans l’automatisation et la recherche du système iOS

31. Créer une app macOS (macOS / Code)

Difficulté : Advanced | Durée : 1h

• Pour créer une app macOS basée sur SwiftUI, fait d’abord choisir un modèle de scène comme WindowGroup, Window, Settings, MenuBarExtra ou DocumentGroup
• Met en place une boucle de build/exécution orientée shell via xcodebuild ou swift build, ainsi que le script/build_and_run.sh local au projet
• À mesure que l’app grossit, traite les questions de fenêtres, menus, barre latérale, Settings, interopérabilité AppKit et signature du point de vue d’une app desktop
• Convient pour : les nouvelles apps Mac nécessitant une architecture desktop native, ainsi que l’amélioration de l’UI, du build ou du déploiement d’apps Mac existantes

32. Appliquer Liquid Glass (iOS / Code)

Difficulté : Advanced | Durée : 1h

• Avec iOS 26 et Xcode 26 comme référence, build une app SwiftUI existante et distingue le verre système obtenu automatiquement via les contrôles standard de l’UI personnalisée à remplacer manuellement
• Fait migrer les piles personnalisées de blur/material vers glassEffect, GlassEffectContainer, le style de bouton glass et les transitions glassEffectID natifs
• Si la prise en charge des versions antérieures d’iOS est nécessaire, il faut conserver clairement #available(iOS 26, *) et un chemin de repli
• Convient pour : les équipes qui veulent migrer en toute sécurité les parcours les plus utilisés d’une app existante vers Liquid Glass sur iOS 26

33. Ajouter de la télémétrie sur Mac (macOS / Code)

Difficulté : Advanced | Durée : 30m

• Ajoute des logs à fort signal basés sur Logger d’Apple à des flux comme l’ouverture de fenêtre, la sélection dans la barre latérale, les commandes de menu ou les jalons de synchronisation d’une app Mac
• Fait en sorte que Codex build et exécute l’app, puis prouve dans Console ou via log stream que les événements réels se produisent bien dans l’ordre attendu
• La méthode consiste à éviter les payloads sensibles, à définir clairement subsystem/category et à permettre de décider du patch suivant avec des éléments concrets dans une boucle de débogage agentique
• Convient pour : les fonctionnalités d’apps Mac dont les flux sont difficiles à suivre en simple revue de code, ainsi que les boucles de débogage basées sur les logs

34. Déboguer dans le simulateur iOS (iOS / Code)

Difficulté : Advanced | Durée : 1h

• Codex et XcodeBuildMCP trouvent le scheme et le simulateur, buildent et exécutent l’app, puis lisent la hiérarchie UI et effectuent des tap, type, swipe, screenshot et capture de logs
• Si nécessaire, attache LLDB pour inspecter les stack frames, variables locales et breakpoints, et transforme un vague rapport de bug en correction réduite et reproductible
• Après modification, l’essentiel est de relancer le même parcours sur le simulateur afin de conserver une preuve que le bug a disparu
• Convient pour : les bugs UI iOS qui n’apparaissent que dans certains flux d’onglet, de scroll ou de saisie, ainsi que les problèmes de crash, de blocage ou de navigation

35. Auditer un incident de dépendance (Engineering / Quality)

Difficulté : Advanced | Durée : 1h

• Lorsqu’un advisory de package public ou un incident de supply chain survient, ne lance pas immédiatement un patch, mais commence par élaborer un plan d’audit conservateur en lecture seule
• Codex distingue les sources faisant autorité des commentaires généraux, définit les preuves permettant de démontrer ou d’exclure l’exposition, puis examine les manifestes, lock files, workflows CI et scripts
• Le principe de base est d’éviter toute exécution de code non fiable, installation, build ou test avant approbation explicite
• Convient pour : les équipes sécurité/ingénierie et les mainteneurs qui doivent réagir vite à un incident de dépendance

36. Préparer un brief de réunion (Integrations / Knowledge Work)

Difficulté : Easy | Durée : 30m

• Rassemble depuis les documents Drive, fils Slack, Gmail et notes précédentes le contexte de réunion qui manque à la seule invitation Calendar, puis l’organise en objective, agenda, open questions et modèle de notes
• Fait en sorte que Codex crée d’abord un inventaire des sources, puis sépare le contexte confirmé, les lacunes de sources et les questions ouvertes
• Les supports de préparation de réunion doivent être courts, faciles à parcourir et permettre de tracer l’origine de chaque information
• Convient pour : les managers, PM, responsables des opérations, recruteurs et toute personne devant rapidement structurer le contexte avant une réunion

37. Exécuter un playbook événementiel (Integrations / Knowledge Work)

Difficulté : Intermediate | Durée : 1h

• Regroupe le canal de planification de l’événement, les documents/decks/sheets/templates approuvés et les échéances du calendrier pour créer un playbook appuyé sur des sources
• Le point clé est de gérer séparément le texte public de la page de l’événement, la checklist opérationnelle interne, les responsables, les approvals et les questions ouvertes
• S’il s’agit d’un événement récurrent, on peut ajouter une automatisation sur le même fil pour suivre les échéances, approvals, documents manquants et l’état de la checklist de lancement
• Convient pour : la gestion des programmes événementiels des équipes communauté, DevRel, marketing et opérations

38. Mener une migration de code (Engineering / Code)

Difficulté : Advanced | Durée : 1h

• Lors d’un passage d’une stack legacy vers une stack cible, commence par inventorier routing, modèles de données, auth, config, background jobs, build, déploiement, tests et contrats externes
• Choisit une stratégie incrémentale comme une couche de compatibilité, un portage module par module, le branch-by-abstraction ou un remplacement de type strangler
• Effectue une validation de parité à chaque checkpoint, et traite explicitement comme exception tout changement visible imposé par la migration elle-même
• Convient pour : les équipes qui doivent faire évoluer framework, runtime, langage ou système de build par étapes maîtrisées

39. Refactoriser un écran SwiftUI (iOS / Code)

Difficulté : Advanced | Durée : 1h

• Divise un énorme fichier d’écran SwiftUI en petites section views et en un flux de données explicite, tout en conservant le comportement et la mise en page
• La compétence de refactorisation de vues SwiftUI du plugin Build iOS Apps recommande une approche MV-first, évite d’ajouter des view models inutiles et déplace les effets de bord hors de body
• Il est important d’ajouter une petite boucle de validation pour vérifier que l’UI n’a pas changé et que le comportement fonctionnel a bien été conservé
• Convient à : écrans SwiftUI où body mélange mise en page, branches conditionnelles, tâches async et actions inline

40. Rédiger une ébauche de PRD à partir du contexte interne (Integrations / Knowledge Work)

Difficulté : Easy | Durée : 30 min

• Rassemble un projet Linear, un canal de planification Slack, des documents Notion/Google Drive, des notes de réunion et des documents de recherche pour rédiger un PRD révisable
• Il est préférable de définir clairement un contrat de sections couvrant le problème, les utilisateurs, les exigences, l’UX, les considérations techniques, le plan de lancement, le calendrier, les décisions prises et les questions ouvertes
• Vérifiez d’abord l’appendice des sources pour voir quel contexte Codex a utilisé, puis affinez les exigences et les questions ouvertes
• Convient à : PM et équipes produit qui veulent transformer des informations issues de discussions internes en PRD, proposition, launch brief ou note de décision

41. Prévoir les flux de trésorerie (Data / Knowledge Work)

Difficulté : Intermediate | Durée : 30 min

• Saisit la trésorerie de départ, les encaissements attendus, la paie, les paiements fournisseurs, la dette, les taxes, les capex, le besoin en fonds de roulement et les hypothèses de calendrier pour créer un classeur de prévision de flux de trésorerie modifiable
• Demande la création d’un onglet récapitulatif qui conserve la cadence d’origine et montre les hypothèses provoquant un passage sous le solde de sécurité et des tensions de trésorerie
• Ouvre le .xlsx généré dans Codex pour examiner les formules, les scénarios et les hypothèses de calendrier, puis le modifie dans le même fil
• Convient à : équipes finance/opérations qui produisent des prévisions de trésorerie sur 13 semaines ou mensuelles

42. Créer un modèle de valorisation DCF (Data / Knowledge Work)

Difficulté : Intermediate | Durée : 30 min

• Saisit les données financières historiques, les hypothèses de valorisation et les notes de modélisation pour créer un classeur DCF incluant croissance du chiffre d’affaires, marge, capex, besoin en fonds de roulement, WACC et valeur terminale
• Codex crée un .xlsx modifiable avec des onglets de modèle, des formules, des hypothèses et un résumé de valorisation, que l’utilisateur peut examiner/modifier directement dans Codex
• Il est possible de continuer dans le même fil avec la vérification des liens entre formules, la modification des hypothèses, l’ajout de scénarios et le resserrement du modèle
• Convient à : équipes analystes/finance qui doivent créer et revoir rapidement un classeur de valorisation

43. Examiner les écarts entre budget et réalisé (Data / Knowledge Work)

Difficulté : Easy | Durée : 30 min

• Saisit le plan budgétaire, l’export des réalisés et les notes de clôture pour mapper les réalisés aux catégories du plan et calculer les écarts dans un classeur de revue
• Préserve les entrées d’origine, le mapping, les formules d’écart et l’onglet de synthèse, tout en séparant les problèmes de rapprochement des questions financières ouvertes
• Permet d’enchaîner dans le même fil sur la correction du mapping des catégories, l’ajout d’une découpe par département et la rédaction d’une ébauche de synthèse finance
• Convient à : équipes finance qui doivent expliquer à la direction les écarts de dépenses lors des revues de clôture mensuelle

44. Suivre des objectifs (Engineering / Automation)

Difficulté : Advanced | Durée : Long-running

• Utilise /goal pour permettre à Codex de poursuivre un travail de longue durée jusqu’à une condition d’arrêt vérifiable, sans s’interrompre après un seul tour
• Spécifie clairement l’objectif, la condition d’arrêt, les fichiers/documents/logs/plans à lire en premier, ainsi que les commandes ou artefacts prouvant l’avancement
• Convient à des tâches comme une migration, un gros refactor, une boucle de reprise de déploiement, une expérimentation, un jeu ou un prototype, où Codex peut avancer de manière autonome par checkpoints
• Convient à : travaux de code qui doivent se poursuivre pendant plusieurs heures, mais avec un objectif et une boucle de validation clairs

45. Ajouter des Evals à une application IA (Evaluation / Quality)

Difficulté : Intermediate | Durée : 1 h

• Analyse les prompts, appels de modèle, tools, retrieval, agents et exigences produit d’une application IA existante pour y ajouter une suite d’evals Promptfoo
• Plutôt que d’essayer d’évaluer tout le système d’un coup, commencez par un comportement visible par l’utilisateur, comme la classification, l’extraction, la synthèse, le routage, le grounding, l’usage d’outils ou une règle de format
• Codex crée la configuration et les données de test, exécute l’eval en local, puis laisse des commandes réutilisables ensuite
• Convient à : équipes d’applications IA qui veulent mettre en place des tests de régression avant des changements de modèle/prompt/retrieval/agent

46. Transformer des user stories en maquettes UI (Integrations / Knowledge Work)

Difficulté : Easy | Durée : 30 min

• Rassemble des retours dispersés dans Slack, Linear, Google Drive, des notes d’appels clients, etc., puis les organise en user stories et contraintes avant de générer une direction de maquette UI avec ImageGen
• S’il existe une user story claire, démarre immédiatement ; sinon, Codex commence par rassembler le contexte pour normaliser le problème et les besoins
• La maquette retenue est ensuite rattachée dans un nouveau tour pour être implémentée en prototype fonctionnel réutilisant le design system et les composants du codebase existant
• Convient à : équipes produit/design/ingénierie qui veulent transformer des retours produit épars en direction visuelle et obtenir une maquette à faire relire par l’équipe

47. Intégrer une app à ChatGPT (Integrations / Code)

Difficulté : Advanced | Durée : 1 h

• Concevoir l’application ChatGPT autour d’un seul outcome utilisateur étroit, et créer de bout en bout le serveur MCP, un composant web optionnel et les métadonnées des outils
• Codex est bien adapté pour prendre en charge la conception de la surface des outils et des métadonnées, le scaffold du serveur MCP, l’implémentation du widget, la connexion à ChatGPT et les tests de golden prompts
• Dès la v1, déterminer d’abord si un widget est ნამდვილად nécessaire, si l’authentification et le déploiement sont requis, et s’il est possible de valider les tests HTTPS en local ainsi que le developer mode
• Convient à : les équipes qui créent leur première application ChatGPT ou qui veulent démarrer sans faire grossir excessivement le serveur MCP ni les métadonnées des outils

48. Créer une application React Native avec Expo (Mobile / Engineering)

Difficulté : Intermédiaire | Durée : 1 h

• Utiliser les plugins Expo pour scaffold une application React Native, avec Expo Router, les conventions de packages natives d’Expo et une boucle de test rapide basée sur Expo Go
• Ne passer à un dev client ou à un build EAS que lorsqu’il faut du code natif personnalisé, une distribution sur store ou des capacités non prises en charge par Expo Go
• Codex permet de créer un workflow complet incluant une navigation au rendu natif, ainsi que les états loading/empty/error, puis de le valider par le chemin le plus rapide
• Convient à : les développeurs qui veulent prototyper rapidement une application mobile avec Expo ou la préparer à la sortie avant de travailler dans un IDE natif

49. Créer une CLI utilisable par Codex (Engineering / Code)

Difficulté : Intermédiaire | Durée : 1 h

• Envelopper dans une CLI composable les API, sources de logs, export inbox, bases de données locales et scripts d’équipe auxquels Codex doit accéder de façon répétée, afin de pouvoir l’exécuter dans n’importe quel repo
• Une bonne CLI propose des comportements agent-friendly comme la recherche paginée, la lecture exacte par ID, un JSON prévisible, le téléchargement, un index local et le draft-before-write
• Créer la CLI avec $cli-creator et produire en parallèle, avec $skill-creator, une skill compagnon qui documente quand cette CLI doit être utilisée
• Convient à : les équipes qui ont besoin que Codex lise, recherche et manipule en toute sécurité les mêmes services ou sources de données de façon fréquente

50. Prioriser les actions à mener dans Slack (Automation / Integrations)

Difficulté : Facile | Durée : 30 min

• Lire les DM Slack, group DM, mentions dans les canaux et réponses dans les threads, afin de distinguer les demandes directes, les follow-up implicites, les éléments déjà résolus et les actions encore actives
• Codex lit jusqu’à la fin la plus récente du thread, détermine si quelque chose reste unresolved, puis construit une file d’actions classée selon l’urgence et l’impact
• Il peut produire des brouillons de réponse ou de handoff, mais il vaut mieux limiter les véritables post/send à une exécution après revue
• Convient à : les workstreams launch, support, product, operations et community où le travail arrive via Slack

51. Exécuter des workflows opérationnels vérifiables (Automation / Integrations)

Difficulté : Intermédiaire | Durée : 30 min

• Faire exécuter par Codex des tâches opérationnelles répétitives comme les mises à jour d’accès, les lots d’invitations, les changements de quota, la configuration client, les vérifications de routage ou les suivis de migration
• Fournir clairement la table d’entrée, la source d’approbation, la policy, les scripts/API/CLI/skills à exécuter, l’activation ou non du dry run et les limites de retry, sans le laisser deviner les champs manquants
• Exiger des artifacts de vérification contrôlables par un humain, comme un CSV de résultats, un fichier de logs, un lien de dashboard, une capture d’écran ou un contrôle PR
• Convient à : les opérations qui nécessitent des entrées structurées et une trace d’approbation/audit claire

52. Transformer les réunions en tâches de suivi (Automation / Integrations)

Difficulté : Intermédiaire | Durée : 5 min

• Utiliser la transcription Zoom et le résumé AI Companion pour structurer les principaux enseignements, risques, opportunités, décisions et actions issus des réunions clients
• Codex peut rédiger des brouillons d’e-mail de suivi, de plan de compte, de mise à jour CRM ou de notification Slack, mais l’envoi ou l’enregistrement doivent avoir lieu après validation par l’utilisateur
• L’efficacité augmente lorsqu’on connecte ensemble l’enregistrement cloud Zoom, la transcription, le résumé AI Companion et des outils de destination comme Gmail, Slack, Google Docs ou le CRM
• Convient à : les équipes en contact avec les clients qui doivent gérer des suivis répétitifs après des appels de discovery, de renouvellement, d’implémentation ou avec un sponsor exécutif