--- title: "Codex : 7 cas d’usage concrets, tous vécus" url: https://jacquesao.com/fr/posts/codex-7-real-use-cases/ lang: fr author: Jacques AO date: 2026-10-19 category: "Tendances tech" tags: ["Codex", "AI 编程", "案例", "工作流", "Agent"] description: "Sept tâches réelles confiées à Codex : script de publication, réparation des commentaires, verrou de synchro bloqué, marques des produits, script de mesure, recherche documentaire, essai sur une copie. Ce qu’il a fait, pourquoi ça a marché, où il s’est arrêté." alternates: zh: https://jacquesao.com/zh/posts/codex-7-real-use-cases/index.md fr: https://jacquesao.com/fr/posts/codex-7-real-use-cases/index.md en: https://jacquesao.com/en/posts/codex-7-real-use-cases/index.md --- # Codex : 7 cas d’usage concrets, tous vécus Les tâches que j’ai confiées à Codex ont bien marché quand elles avaient trois points communs : **une frontière nette, un moyen de vérifier le résultat et un retour en arrière possible**. Voici sept cas réels, dans l’ordre où je les ai vécus, sans chiffres d’entreprise ni informations sur des clients. Je ne lance pas toujours Codex moi-même : souvent, c’est Claude Code qui lui envoie la tâche, puis relit ce qui revient (la répartition est décrite dans [Claude Code ou Codex](https://jacquesao.com/fr/posts/claude-code-vs-codex-how-i-split-the-work/)). Ce qui suit raconte ce que Codex a fait ; je ne parle de l’envoi et du contrôle que quand c’est utile. ## Cas 1 : un script de publication de blog Je voulais publier un article sans retoucher des pages web à la main : **lire un fichier de données, générer les pages, puis mettre à jour le plan du site et le flux RSS**. J’ai demandé à Codex de concevoir la structure des données, d’écrire le script de publication et celui du flux RSS, puis de corriger les erreurs une à une. C’est la base de ce blog, et j’ai raconté le processus dans [OpenClaw + Codex](https://jacquesao.com/fr/posts/openclaw-codex-ai-assistant-combo/). Ça a marché parce que la demande était précise : Python, lire du JSON, analyser l’article, générer du HTML, mettre à jour le sitemap, gérer les erreurs. Pour le même travail, un simple « écris-moi du code pour publier un blog » donne un résultat bien plus dispersé. J’ai comparé les deux façons de demander dans cet article. ## Cas 2 : réparer un système de commentaires L’API des commentaires ne répondait pas, la configuration Nginx était fausse et le service Python plantait. **J’ai demandé à Codex de lire d’abord les journaux d’erreurs, puis de corriger le script Python, de réécrire la configuration Nginx et de créer un service systemd pour que le programme se relance seul après un plantage.** À l’époque, j’avais séparé le travail : redémarrer, vérifier l’état, tester les points d’accès et confirmer que les commentaires étaient bien enregistrés, c’était un autre outil qui l’exécutait sur le serveur. Codex ne faisait que lire les journaux et modifier le code. Sa frontière restait nette, et il n’exécutait rien sur mon serveur. ## Cas 3 : un verrou qui ne se libérait jamais Fin mai, la synchronisation horaire des produits entre deux systèmes échouait à chaque passage. La cause : **un traitement de synchro était mort en route, l’état restait « en cours » pour toujours, et chaque tâche horaire qui voyait le verrou s’arrêtait aussitôt**. Elle avait été refusée 38 fois en une journée. C’est Claude Code qui a trouvé la cause. J’ai ensuite demandé à Codex d’ajouter trois choses : si rien ne bouge depuis plus de 30 minutes, considérer le traitement comme mort et reprendre le verrou ; écrire régulièrement une trace « je suis vivant » pendant les longues synchros ; déplacer une étape de préchargement dans le bloc de gestion d’erreurs. Claude Code a relu les modifications, les a déployées après une sauvegarde, puis a vérifié que la synchro incrémentale suivante allait au bout. Une tâche dont la cause est connue et dont les modifications sont listées se confie facilement. ## Cas 4 : remettre la bonne marque sur les produits En juillet, j’ai contrôlé les données produits envoyées à Google Shopping et j’ai vu que **un grand nombre de produits avaient comme « marque » le nom de ma propre boutique, et non celui du fabricant**, ce qui risquait un refus. Codex a écrit un correctif d’extraction de marque : un dictionnaire de plus de 60 marques, avec une règle contre les faux positifs, par exemple une « coque pour iPhone » ne doit pas être étiquetée comme un produit Apple. Le correctif a d’abord été essayé sur un lot de produits échantillons, et 10 cas pièges que j’avais prévus sont tous passés, avant la mise en ligne. Ensuite, beaucoup moins de produits restaient sans marque. ## Cas 5 : un script de mesure sur plusieurs sites, et savoir s’arrêter Début octobre, j’ai demandé à Codex d’ajouter un petit script de mesure d’audience aux pages de sites statiques. **La règle : comparer chaque fichier à l’original en ligne et n’autoriser que ce bloc en plus.** Pour deux des sites, 11 pages au total, la marche à suivre était : sauvegarder, modifier, comparer ; la page d’accueil et deux pages intérieures répondaient 200, le script n’apparaissait qu’une fois, tous les autres octets étaient inchangés, et la commande de retour arrière était écrite elle aussi. Sur un autre site, il n’a rien touché : la politique de sécurité de ce site n’autorise que ses propres scripts, et le navigateur aurait bloqué le script de mesure. Codex n’a modifié aucun fichier et a écrit la raison dans son rapport. Une autre tâche, au périmètre écrit noir sur blanc, a traité le même site : elle a ajouté ce seul domaine à la politique de sécurité de la configuration du serveur (deux lignes), puis inséré le script dans 10 pages, toutes répondant 200. ## Cas 6 : une recherche documentaire **Tout le travail n’est pas de l’écriture de code.** Je construis pour mon usage un outil de dictée vocale. J’ai demandé à Codex de lire la documentation officielle de 14 produits et systèmes représentatifs et de 5 types de plateformes de reconnaissance vocale, puis de la confronter à deux logiciels similaires installés sur mon ordinateur, en lecture seule, sans rien modifier. Résultat : un rapport de 376 lignes qui traite ensemble le marché et la conception de mon outil. Le rapport apporte de la matière, pas des décisions. Ce que je garde et ce que j’écarte, c’est à moi de le trancher, après avoir vérifié moi-même les sources. ## Cas 7 : répéter sur une copie, s’arrêter au seuil Ma boutique en ligne devait proposer des prix dégressifs selon la quantité achetée. Les conditions données à Codex : **travailler uniquement sur une copie de la boutique réelle, fixer plusieurs seuils de sécurité et s’arrêter si l’un d’eux n’est pas respecté.** Une version ralentissait la page et l’ajout au panier au-delà du plafond de +10 % que j’avais fixé, avec une mesure entre +24 % et +27 %. Une autre a montré qu’enregistrer une catégorie dans l’administration déclenchait un crochet qui supprimait des entrées du cache. Les deux fois, Codex n’a pas forcé le passage : il a remis la copie dans son état d’origine et a rendu un rapport qui dit non, pas un paquet « prêt à déployer ». La boutique réelle n’a été consultée qu’en lecture, jamais modifiée. Une version suivante est passée et a été mise en ligne. Pour moi, un résultat qui s’arrête et rend compte honnêtement vaut mieux qu’un simple « c’est fait ». ## Ce qu’ils ont en commun Aucune des sept tâches n’était « optimise-moi ça ». Chacune pouvait dire ce qu’il fallait changer, ce qu’il ne fallait pas changer et ce qui comptait comme terminé. - La mise en ligne, la suppression, le paiement et tout envoi vers l’extérieur ne lui sont pas confiés : c’est moi qui donne le feu vert. - Dans le mode isolé que j’utilise, il n’a pas de réseau par défaut et ne peut pas enregistrer le code lui-même ; seule une tâche qui a besoin du réseau l’indique, sur sa première ligne. - Je lui demande à chaque fois de lancer ses propres vérifications (tests, comparaisons, échantillons), puis je contrôle par sondage. Pour comprendre d’abord ce qu’est l’outil, lisez [Codex, c’est quoi](https://jacquesao.com/fr/posts/what-is-codex-and-how-to-use-it/).