Codex devient 10x meilleur avec ces 6 astuces

Voici six astuces qui vont changer votre vie sur Codex. J'ai fait pas mal de recherches et voici vraiment les astuces du mois de mai 2026 pour Codex. C'est parti. Premier truc, sans doute le plus important, c'est le fichier agents.m. Et ici, on a trois chiffres pour poser le décor. De un, c'est utilisé par plus de 60000 projets open source sur Geitub. De le ripo principal d'Open AI, c'est la boîte qui fait Codex, a lui-même 88 fichiers agents.m. Et de 3, c'est maintenu par la Linux Foundation. Donc c'est pas juste un gadget d'open AI, ça devient un standard pour tous les outils de l'industrie. En gros, le agent.m, c'est comme un RIDmi. Mais pour les agents, c'est un endroit dédié, prévisible où tu mets le contexte et les instructions dont un agent a besoin pour travailler sur ton projet. Et c'est pas la même chose qu'un rythme humain. C'est plus détaillé, plus opérationnel avec les commandes exactes de build et de test. Et comme dit, ça peut être aussi utilisé par d'autres agents. On voit très bien ici que Codex l'utilise mais aussi Cursor et plein d'autres agents. Alors, le seul qui ne l'utilise pas, c'est Cloude. Cloud a son fichier qui est nommé cloude. MD, mais depuis peu, il a quand même la possibilité, s'il n'y a pas de cloud.m, de lire les fichiers agents.m en fallback, c'est-à-dire en repli, s'il y a rien d'autre ici à lire. Et pour avoir un agent.md MD correct, il y aura six sections clés. Donc ce fichier agents.m va venir quelque part représenter, décrire votre projet. Il sera la racine ici de votre projet. Et je vous conseille de mettre six sections. La première, ça sera la structure du dépôt. La deuxième, ça sera quelle commande il faut écrire pour lancer le projet. Ensuite, bah il y aura d'autres commandes, des commandes pour construire le projet, pour le tester, pour le linter. Ensuite, on aura les conventions et les règles de PR, de pool request. sur Git et ce que je vous conseille aussi de faire, c'est un fichier des contraintes, ce qu'il ne faut pas faire. Et enfin, on aura aussi la définition du fini. Qu'est-ce qui fait que le projet est terminé? Et détail super important, si tu mets par exemple une commande comme PNPM test pour lancer les tests et si tu mets cette commande dans le fichier agents.m, Codex va tenter d'exécuter ses commandes et va tenter de fixer ce qui ne va pas avant de te rendre la main. Donc ici, on a agent.md me dit qu'il n'est pas que de la documentation, c'est aussi de l'exécutable. D'où l'intérêt justement de lister des vraies commandes et pas juste des principes vague. Et ce qu'il faut savoir aussi, c'est qu'il y a plusieurs hiérarchies ici de agents.m. Vous n'êtes pas limité que à un fichier agents.m sur votre ordinateur ou sur le projet. Vous pouvez empiler trois niveaux. Donc, on aura déjà la possibilité d'avoir un fichier global pour tous les projets sur l'ordinateur. Ensuite, un autre. Pourquoi pas la racine du projet courant pour les standards de l'équipe? Mais surtout, on pourra aussi avoir des fichiers spécifique pour les différentes fonctionnalités du projet. Maintenant, mais quel agent.mmd est sélectionné? Bah, c'est le plus proche de ton dossier de travail qui est sélectionné. Il faut aussi savoir qu'on peut créer des agentsoverride. Qui prend la priorité sur l'agence.md du même dossier. Donc ça c'est pas mal pour tester des choses temporairement. Une fois que c'est testé, que c'est passé, ben tu viens supprimer l'override et tu reviens sur le paramétrage d'équipe avec legents.m. Et je finirai sur les boucles de rétrospective. Quand Codex se trompe deux fois sur la même chose, tu lui demandes de faire un retour sur l'erreur et surtout tu mets à jour ton agents.m parce que si ici on a Codex qui se trompe deux fois sur la même chose, a priori c'est mieux quand même ici qu'il comprennent ce qu'il ne va pas. Pour qu'il puisse comprendre ça, tu viens éditer le agents.mmd. Et ça c'est vraiment le mieux. Il viendra s'enrichir par conséquent ici de choses réelles et pas juste de choses abstraites. Maintenant prochaine astuce et ça ça vient directement de la documentation de Codex dans vraiment la partie les meilleures pratiques. Il propose une structure de prompt en quatre points. Quand tu donnes une tâche complexe à codex, tu vas mettre quatre parties explicites dans ton prompt. Déjà l'objectif, qu'est-ce que tu veux faire ou construire? Exemple, ben je vais ajouter un endpoint get user ID qui renvoie le profil d'utilisateur ou si tu fais des choses plus simples, ben ça sera un peu plus simple et si tu fais des choses plus complexes, ça sera plus complexe. Ensuite, on aura la partie contexte, les fichiers, doc, exemple ou erreur pertinente. Donc là, avec le @obase, tu vas renseigner les fichiers à placer dans le contexte. Et encore une fois, dans tout ce qui est agent IA, le contexte est sans doute le plus important. Ensuite, les contraintes standard, convention, contrainte de sécurité, choix imposé. Là, tu vas aller un peu plus loin en le dirigeant vers la façon de faire. Et enfin, qu'est-ce qui doit être vrai pour considérer que la tâche est terminée? Très important. Et là, met des critères d'acceptation explicite. Et je pense que malheureusement, c'est le point le plus sous-utilisé. Alors qu'au final bah on a envie de faire quelque chose. Donc autant dire bah à quel moment on considère que cette tâche est terminée. Et ça c'est absolument indispensable pour se faire bien comprendre par les agents I que ce soit Codex ou autre. Et ensuite comme dit, n'hésitez pas dans le contexte à renseigner grâce au arobas directement les fichiers concernés. Mais par moment, on a aussi un peu le syndrome de la page vide. On ne sait pas exactement ce que l'on veut faire et par conséquent quand vous avez des idées flouses, ben vous allez directement demander à Codex de vous interviewer et vous allez dire "Pose-moi des questions pour transformer cette idée floue en quelque chose de concret avant d'écrire du code." Et à ce moment-là, bah Codex remet tes hypothèses en question et le résultat est bien plus net. Et ça, je le fais très souvent parce que je me suis rendu compte avec le temps que au final, j'étais pas toujours sûr à 100 % exactement de ce que je voulais faire. Donc même si je sais exactement ce que je veux faire, je lui dis quand même ben n'hésite pas à me poser des questions si tu en as. Et je trouve que le résultat à la fin est toujours mieux. Prochain type, le plan mode bien configuré. Tu peux activer le plan mode avec slash plan dans le cit et d'ailleurs aussi dans l'app. Et la codex sort un plan en Markdown. Tu édites, tu valides, puis tu lances l'exécution. Et le truc documenté officiellement mais que personne ne configure, c'est ici. Dans codex config.Tomel. Là, tu peux préciser différentes choses. Déjà, le modèle reasoning est fort, tu peux le mettre en médium. Et par exemple, tu peux changer l'effort si tu fais du plan mode. Donc ça, tu peux le configurer. Maintenant, il y a plusieurs efforts. On a cinq niveaux. Minimal, low, medium, high. XI. La recommandation officielle est la suivante: Tu vas te mettre en low pour les tâches où tu sais exactement ce que tu veux et c'est des tâche rapide et sur du médium ou du high pour des changements plutôt complexes et tu peux te mettre en extra high pour les sessions agentiques longues et tout ce qui sera aussi lourd en raisonnement et aussi pour les workflow avec plusieurs étapes qui durent plusieurs sessions. La doc officielle recommande un fichier plans.m. Là, tu vas mettre ton plan dans un fichier Markdown qui est persistant et tu viens le référencer depuis agents.m. Là, on vient référencer le pattern execpl. Alors, je vous invite à vous renseigner euh plus sur tout ce qui est template exacte plane, c'est super important. Mais quand tu mets ton plan dans un fichier qui persiste et que tu le références depuis agents.m, la codex peut revenir au plan, revenir où il en était et ce même après un fork ou un redémarrage. Et ensuite, on va quand même un peu revenir sur l'exc plane. Tu auras toujours un peu la même chose, les progrès, ce qui est fait, ce qui reste, les surprises et les découvertes, les imprévus rencontrés en cours aussi. Ensuite, le log de décision, les décisions prises et le pourquoi, mais aussi les résultats et les rétrospectives, le bilan à chaque jalon, à chaque step. Et le principe clé, le plan doit être autosuffisant pour qu'un agent sans état puisse repartir uniquement à partir de ce fichier. De toute façon, alors pour des petites tâches, il y a pas forcément besoin d'utiliser le plan, mais à partir du moment où ça devient un minimum complexe, il faut absolument utiliser un plan que ce soit sur Codex d'ailleurs ou sur Cloud. Le plan mode est toujours beaucoup plus efficace. Le prochain type, c'est d'utiliser Whisper Flow. La dictation est officiellement recommandée par Open AI. C'est écrit noir sur blanc dans les meilleures pratiques sur la documentation officielle de Codex. Alors pour ceux qui sont sur Cloud, vous savez que quand vous voulez parler dans le micro et que ce soit converti en texte, c'est souvent super galère. Cloud est vraiment très mauvais là-dedans. Open AI est un peu meilleur. Cependant, les outils comme Whisper Flow sont vraiment utilisés par les plus grands, par les plus gros. Et c'est assez logique, quand on parle, on est beaucoup plus rapide que lorsque l'on écrit. Quand tu viens communiquer avec Codex, tu vas écrire, tu vas aller taper 40 60 mots par minute. Quand tu viens parler, bah tu peux en dire jusqu'à 130 150 sans problème. C'est trois fois plus rapide et forcément puisque tu peux parler, tu peux aussi dire plus de choses, apporter plus de précision, de contexte. Alors le prix est de 12 € par mois par utilisateur, mais je pense que ça en vaut le coup, que c'est largement rentabilisé. Une autre astuce, c'est d'utiliser Paper Design. C'est un Canva type un peu Figma mais construit sur une idée différente. Tout ce que tu dessines c'est du HTML et du CSS réel. C'est pas un format propriétaire. Chaque élément est quelque part du vrai web et par conséquent à l'export c'est zéro conversion. Et le truc intéressant pour Codex c'est leur MCP bidirectionnel. Tu connectes Codex à Paper via MCP et là tu viens dessiner quelque chose unei Codex lit le design. génère le code dans ton repo et tu vois le rendu en live dans le Canva ou l'inverse he d'ailleurs, Codex peut aussi modifier le design depuis un prompt. Et attention, petit warning, c'est ici paper en mode desktop. Ils ont désormais une application qui vient débloquer ce concept de MCP. Alors bien entendu, on a une version web qui existe. Je suis actuellement dessus, mais c'est leur version desktop sur laquelle se joue vraiment ici le workflow Codex. Et je vois énormément ici de youtubeurs l'utiliser, mais aussi on a Versel qui l'utilise mais aussi Perplexity, Tailwind, Lovable, Z, Replicate et bien d'autres. Ensuite, prochain type, utiliser les skills. Si d'une façon globale vous faites toujours la même chose, transformer cet élément en skill. Une skill, c'est un dossier avec un fichier point MD dedans. C'est tout simple. Et là, tu viens écrire dans ce fichiermd ta procédure, ton process, tes conventions, tes étapes et Codex vient la rejouer à chaque fois que c'est utile. Il y a deux trucs à retenir. Le nom sert à l'appel et la description sert à codex pour savoir quand l'utiliser tout seul. Et pour l'exemple, il y a vraiment trois cas super intéressants. Des exemples concrets. On pourrait déjà avoir une skill de review de PR de pool request qui vient rappeler à Codex tes règles de relecture maison. la nomenclature, les tests obligatoires, le format des commentaires et tu viens taper bah par exemple dollar et le nom de la skill pour venir la déclencher sur la branche sur laquelle tu es actuellement. de assez intéressants, une skill newsletter qui sait dans quel format tu écris, comment tu rédiges tes titres, où vont les images et là tu viens lui passer tes notes brutes et elle génère un brouillon ou même la newsletter finale dans ton style ou encore une skill deploy connaît tes commandes versell, tes variables d'environnement, ton ordre de vérification et ça te permet ici d'aller plus vite lors de la mise en production. tu as pas besoin de te rappeler la séquence, l'ordre des choses. Et surtout ce qu'il faut savoir, c'est que on a un dollar skill- creator. Donc tu as pas besoin ici de créer tes skills, tes fichiers point MD tout seul à la main. On a un outil interne à Codex qui permet de créer des skills tout seul à partir du travail par exemple que tu viens de faire. Et ce qu'il faut savoir aussi, c'est que si tu mets ça dans un dossier pointagents, ensuite bah si tu viens commiter et pusher ça, ton autre équipe, tes autres membres de l'équipe qui vont venir faire un pool vont avoir aussi cette skill. Voilà, si vous avez aimé cette vidéo, n'hésitez pas à liker, commenter et à partager. et on se retrouve très bientôt dans la prochaine vidéo.