Agence web : sécuriser diff, PR et mise en ligne avec Codex Desktop

Une landing page validée le matin peut encore partir en production avec un formulaire muet, un ancien tarif ou une balise de suivi absente. En agence, le diff, la PR, la staging URL et l’accord client vivent souvent dans des outils séparés. Une review réussie dans Codex ne réunit pas, à elle seule, ces preuves ni ces décisions.

Le risque apparaît quand l’équipe demande à Codex de « tout vérifier » sans définir ce qui relève du code, du rendu en staging et de l’autorisation de publier. Le résultat peut être techniquement propre tout en restant faux pour le client. La méthode ci-dessous transforme donc la revue en dossier de décision, sans déléguer le go/no-go à l’agent.

L’essentiel avant d’ouvrir la review

• Séparez trois colonnes : corrections de la PR, contrôles sur la staging URL et obstacles à la production.
• Donnez un périmètre explicite : branche de base, fichiers modifiés, demande client, critères de recette et procédure de rollback.
• Utilisez Codex pour préparer les preuves : résumé du diff, commande /review, risques repérés, proposition de correctif et commandes de vérification.
• Gardez les décisions métier côté humain : prix, texte juridique, promesse publicitaire, accord client, date de publication et validation de production.
• Écrivez les règles récurrentes dans AGENTS.md : largeurs mobiles, soumission du formulaire, CTA, OGP, tracking, fichiers interdits et contrôle du rollback.

Dans cet article, Codex Desktop sert d’étiquette pratique pour une surface de travail qui peut inclure la ChatGPT desktop app, le review pane, la CLI et l’IDE extension. Les références utilisées sont les documentations OpenAI sur la ChatGPT desktop app, la Code review, AGENTS.md, les Subagents, les bonnes pratiques et les approbations et la sécurité. Pour un flux de livraison proche dans un autre environnement, consultez aussi le guide agence sur Azure DevOps.

Ce que Codex prépare et ce que l’humain décide

Codex doit recevoir un dossier borné : périmètre du diff, branche de base, PR URL, staging URL, liste des fichiers modifiés, contrôles humains attendus et note de rollback. Une consigne comme « relis cette release » est trop vague. Elle ne dit ni quelle version comparer, ni quels éléments ont déjà été approuvés, ni ce qui bloque réellement la publication.

La séparation suivante évite de confondre une observation technique avec une autorisation commerciale :

Étape	Travail confié à Codex	Preuve à remettre	Décision humaine obligatoire
Diff et PR	Résumer les changements, exécuter /review, classer les risques, préparer un correctif	Fichiers et lignes concernés, commande lancée, résultat du test	Accepter le périmètre et le correctif
Staging	Parcourir la checklist fournie, relever les écarts et organiser les captures disponibles	staging URL, largeur testée, résultat du formulaire, liens et OGP	Valider le rendu, le message et le parcours client
Préproduction	Regrouper les éléments manquants et la note de rollback	Tableau des bloqueurs avec responsable et statut	Valider prix, juridique, campagne, date et go/no-go
Production	Signaler qu’une validation manque	Accord explicite et traçable	Déclencher ou autoriser la mise en production

L’humain conserve la décision métier; Codex prépare les éléments nécessaires à cette décision. Cette limite est essentielle en agence : un composant peut passer les tests et afficher malgré tout une offre expirée, un wording non validé ou le mauvais numéro de contact. Aucun résultat de /review ne remplace l’accord du client, du responsable de compte ou de la personne habilitée à publier.

Avant de transmettre le dossier, retirez les secrets, les données personnelles et les accès qui ne sont pas nécessaires à la revue. Donnez uniquement les fichiers, URL et commandes utiles au périmètre. Si une action demande une permission supplémentaire ou touche la production, l’agent doit s’arrêter et demander une validation explicite plutôt que d’élargir lui-même son mandat.

Quatre cas d’usage en agence

Cas d’usage 1 : livrer une landing page de campagne

Entrées : PR URL, branche de base, fichiers modifiés, staging URL, brief approuvé et note de rollback. Travail de Codex : comparer le diff au brief fourni, exécuter /review, lister les écarts par fichier et préparer les commandes de vérification. Contrôle humain : prix affiché, allégation publicitaire, date de campagne, accord client et publication.

La sortie utile n’est pas un long commentaire. Demandez un tableau avec « code », « staging » et « décision client ». Si le CTA est correct dans le composant mais pointe vers une ancienne route sur la staging URL, l’écart reste visible dans la bonne colonne et ne disparaît pas au milieu des remarques de style.

Cas d’usage 2 : traiter les commentaires d’une PR sans dépasser le devis

Entrées : commentaires de review, fichiers et lignes concernés, fichiers à ne pas toucher, commande de test et périmètre vendu. Travail de Codex : reformuler chaque commentaire en action, proposer les fichiers à modifier et associer une vérification. Contrôle humain : changement de design, extension du scope, impact sur le devis et date de livraison.

Le piège courant consiste à corriger une remarque locale par une refonte plus large. Inscrivez dans AGENTS.md les répertoires protégés et exigez un arrêt si le correctif sort des fichiers annoncés. Le chef de projet peut alors arbitrer l’avenant ou demander une correction plus ciblée.

Cas d’usage 3 : recetter formulaire, CTA et tracking en staging

Entrées : staging URL, largeurs d’écran à contrôler, exemple de soumission, destination du CTA, balises attendues, note de rollback et nom du reviewer. Travail de Codex : organiser une checklist desktop/mobile, consigner le résultat du formulaire, relever les liens et préparer la liste des bloqueurs. Contrôle humain : destinataire réel du lead, contenu du message, conformité des données collectées et go/no-go.

Un statut « formulaire OK » ne suffit pas. La preuve doit préciser la page testée, le jeu de données non sensible utilisé, le résultat visible et la destination attendue. En cas d’échec, la correction consiste à joindre l’erreur observée et à renvoyer le point vers la PR, sans déclarer la campagne prête.

Cas d’usage 4 : préparer une release multisite

Entrées : liste des sites concernés, diff par dépôt, staging URL de chaque variante, éléments mutualisés et ordre de rollback. Travail de Codex : repérer les contrôles communs, séparer les écarts propres à chaque site et produire une synthèse par responsable. Contrôle humain : ordre de publication, dépendances entre équipes, validation de chaque marque et décision d’interrompre la release.

Les Subagents peuvent aider pour des lectures indépendantes, par exemple vérifier des liens, résumer des logs ou comparer des listes de fichiers. Évitez toutefois les modifications concurrentes sur la même landing page : les résultats de lecture reviennent dans le fil principal, puis un seul intervenant prépare les changements soumis à review.

Un dossier de release que le client peut relire

Le dossier minimal tient dans une table partagée. Chaque ligne indique le point contrôlé, la preuve, le responsable humain et le statut. « Codex n’a rien signalé » n’est pas une preuve; « codex review --base main exécuté sur telle PR, formulaire testé sur telle staging URL, accord client joint » est exploitable lors du passage de relais.

Pour mesurer l’intérêt du flux sans inventer un ROI, suivez des données déjà disponibles : nombre d’allers-retours de recette, réouvertures de PR, formulaires cassés détectés avant production, incidents après publication et temps passé à reconstituer l’accord client. Comparez des projets de nature proche et notez les changements de périmètre; le nombre de lignes modifiées ne mesure pas la qualité d’une livraison.

Prompt à copier dans Codex Desktop

Tu prépares la revue d’une livraison d’agence web avant utilisation de Codex Desktop.
Entrées : PR URL, branche de base, staging URL, fichiers modifiés, note d’accord client, checklist de release et note de rollback.
Sortie :
1. Travail que Codex peut faire : résumé du diff, /review, liste des risques, brouillon de correctif, commande de vérification.
2. Décisions réservées aux humains : prix, texte publicitaire, formulation juridique, accord client, date de publication, validation de production.
3. Tableau à trois colonnes : correctifs PR, contrôles staging, obstacles à la production.
4. Règles AGENTS.md courtes pour cette agence.
5. Une première action réalisable en 30 minutes.
Règles : ne considère jamais les résultats de review comme une validation de production. Ne réécris pas un texte approuvé par le client sans review explicite.

Remplacez les libellés génériques par les valeurs du projet. Si la note d’accord client ou le rollback manque, la bonne sortie est un bloqueur attribué à un humain, pas une supposition. Le prompt produit un dossier de revue; il ne donne aucune autorité de publication.

Code de vérification du dossier

Le script suivant contrôle que les champs indispensables sont présents. Il ne contacte ni la PR ni la staging URL : il valide la structure du dossier fourni. Enregistrez-le dans release-review.mjs, adaptez les valeurs, puis lancez node release-review.mjs. Une table vide avec un code de sortie nul indique que les champs attendus sont renseignés; elle ne prouve pas que le site fonctionne.

const releaseReview = {
  project: "campaign-lp",
  headBranch: "feature/lp-copy",
  baseBranch: "main",
  diffScope: "feature/lp-copy vs main",
  reviewCommand: "codex review --base main",
  stagingUrl: "https://staging.example.com/campaign",
  pullRequestUrl: "https://github.com/example/site/pull/42",
  filesChanged: ["src/pages/campaign.astro", "src/components/LeadForm.tsx"],
  humanChecks: ["mobile layout", "form submit", "tracking tag", "client approval", "rollback note"],
  productionRequirements: ["client approval", "rollback note", "analytics check"],
  clientApprovalReference: "approval-example-001",
  rollbackPlan: "Redeploy the previous production commit, then rerun form and analytics checks.",
  releaseOwner: "human release owner",
  codexCanDo: ["summarize diff", "run review", "list risks", "draft fix prompts"],
  humanMustDecide: ["publish timing", "legal wording", "pricing claim", "production approval"]
};

const hasText = (value) => typeof value === "string" && value.trim().length > 0;
const hasChecklist = (value) =>
  Array.isArray(value) && value.length > 0 && value.every(hasText);
const expectedDiffScope = `${releaseReview.headBranch} vs ${releaseReview.baseBranch}`;
const expectedReviewCommand = `codex review --base ${releaseReview.baseBranch}`;

const required = [
  ["head branch", hasText(releaseReview.headBranch)],
  ["base branch", hasText(releaseReview.baseBranch)],
  ["diff scope matches branches", releaseReview.diffScope === expectedDiffScope],
  ["review command matches base branch", releaseReview.reviewCommand === expectedReviewCommand],
  ["staging URL", hasText(releaseReview.stagingUrl)],
  ["pull request URL", hasText(releaseReview.pullRequestUrl)],
  ["changed files", hasChecklist(releaseReview.filesChanged)],
  ["human checks", hasChecklist(releaseReview.humanChecks)],
  ["production requirements", hasChecklist(releaseReview.productionRequirements)],
  ["client approval reference", hasText(releaseReview.clientApprovalReference)],
  ["rollback plan", hasText(releaseReview.rollbackPlan)],
  ["release owner", hasText(releaseReview.releaseOwner)],
  ["production approval stays human", hasChecklist(releaseReview.humanMustDecide) && releaseReview.humanMustDecide.includes("production approval")]
];

const findings = required
  .filter(([, ok]) => !ok)
  .map(([item]) => ({ item, fix: "add this before using Codex for release review" }));

console.table(findings);
if (findings.length > 0) process.exitCode = 1;

Pièges fréquents et corrections

1. Lire /review comme une validation de production

La première cause d’échec est de transformer l’absence de signalement en feu vert. Correction : nommez la sortie « observations sur le diff » et conservez une case distincte « go/no-go humain ». Si cette case n’a ni nom ni date, la release reste bloquée.

2. Laisser AGENTS.md dans le flou

La deuxième cause est une règle du type « vérifie que tout fonctionne ». Correction : inscrivez des portes concrètes adaptées à l’agence : largeur mobile, soumission du formulaire, destination du CTA, OGP, balise de tracking, commande de test et note de rollback. Ajoutez aussi les fichiers qui ne doivent pas être modifiés sans accord.

3. Modifier la même page en parallèle

La troisième cause est de confier simultanément le même fichier à plusieurs fils ou Subagents. Les correctifs peuvent se chevaucher et rendre la review difficile à attribuer. Correction : déléguez les contrôles de lecture, puis centralisez les résultats dans le fil principal; une seule séquence de modification repart ensuite en PR.

4. Sauter la staging URL

La quatrième cause est de conclure à partir du diff seul. Le code peut être cohérent alors que l’environnement affiche une mauvaise variable, un cache ancien ou une intégration indisponible. Correction : réunissez diff de la PR, staging URL, captures utiles, résultat du formulaire et note de rollback dans le même tableau de release. Un contrôle manquant devient un bloqueur visible.

Questions fréquentes

Codex Desktop est-il le nom officiel du produit ?

La documentation distingue notamment ChatGPT desktop app, Codex CLI, IDE extension et review pane. Cet article emploie Codex Desktop comme libellé pratique pour le poste de travail d’agence qui rassemble ces surfaces; il ne présente pas ce libellé comme un nouveau produit officiel.

Une agence doit-elle commencer avec la desktop app ou la CLI ?

Le choix dépend du rôle et du dépôt. Une personne qui coordonne la recette peut préférer le review pane de la desktop app; une personne qui implémente peut préférer la CLI ou l’IDE extension pour lancer les vérifications locales. Commencez sur une PR non urgente et gardez les mêmes portes de validation dans les deux cas.

La commande /review suffit-elle avant la release ?

Non. Elle contribue à la revue du diff. L’accord client, le calendrier publicitaire, le prix, la formulation juridique et l’autorisation de production restent des décisions humaines, documentées séparément.

Faut-il utiliser des Subagents ?

Ils sont adaptés aux contrôles principalement fondés sur la lecture, tels que les liens, les logs et les résumés. Évitez les éditions concurrentes de la même landing page et faites relire les résultats avant tout correctif ou publication.

Mettre ce flux en place dans l’agence

Le livrable à viser n’est pas « une review faite par l’IA », mais un dossier de release que le développeur, le chef de projet et le responsable de compte comprennent de la même manière. Apportez une PR représentative, sa staging URL, votre AGENTS.md et votre checklist à la formation et consultation Claude Code pour construire un flux de revue reproductible.

Résultat de la vérification pratique

Pour cette mise à jour, la structure du script JavaScript, la syntaxe officielle codex review --base main, les liens vers la documentation OpenAI, le lien interne français, le CTA, le frontmatter et le slug ont été contrôlés. Le premier geste à reproduire sur un projet réel est simple : placez les correctifs de PR, les contrôles sur la staging URL et les validations de production dans trois colonnes distinctes, puis attribuez chaque décision humaine.