Codex Security : tarifs, configuration, analyses locales et Cloud, résultats

Codex Security est un agent de sécurité qui repère des vulnérabilités potentielles dans le code, vérifie les éléments de preuve et aide à préparer des correctifs. La première distinction à faire est entre le plugin utilisé dans votre environnement local Codex et Codex Security Cloud, qui se connecte à GitHub. Malgré leurs noms proches, leur configuration, leur environnement d’exécution et leurs conditions de facturation diffèrent.

Cet article explique comment choisir une option, les tarifs et quotas gratuits, la première analyse, les ressources nécessaires aux analyses approfondies, l’interprétation des résultats et la vérification des correctifs. Il s’appuie sur la documentation OpenAI consultée le 7 octobre 2026. Nous n’avons pas exécuté d’analyse avec le produit et ne présentons donc aucune mesure de précision, de durée ou de consommation réelle.

Sources : OpenAI, présentation de Codex Security et prise en main du plugin local.

Choisir entre analyses locales, Cloud et revues classiques

Pour une petite modification, vous pouvez aussi fournir un diff et vos critères de revue à votre conversation Codex habituelle. Cela ne signifie pas qu’elle produira automatiquement les fichiers d’un outil d’analyse dédié ou des relevés de couverture. Demander une revue de code et lancer une analyse Codex Security sont deux actions distinctes. Pour choisir plus généralement entre des outils de programmation, consultez notre comparaison entre Claude Code et Codex.

Cloud est une version préliminaire de recherche et exige un accès pour l’espace de travail concerné. Pour la CLI autonome également, la disponibilité publique du paquet ne signifie pas nécessairement que votre compte est autorisé à lancer des analyses. Selon le compte et le dépôt, une analyse complète du code peut aussi nécessiter un accès supplémentaire « Trusted Access for Cyber ». Le nom d’un abonnement, tel que Pro, ne garantit pas l’accès à toutes les options. Si une option n’apparaît pas, vérifiez l’activation du plugin, vos droits d’accès et les paramètres d’administration de votre organisation.

Sources : OpenAI, présentation et conditions d’accès et revues de sécurité des modifications de code.

Tarifs et quotas gratuits : à vérifier même avec Pro

Les analyses Cloud sont hors du quota habituel de l’abonnement

La FAQ Cloud d’OpenAI explique que les analyses de dépôts et les analyses continues configurées à partir du 1er octobre 2026 à 12 h 53, heure du Pacifique, sont facturées en crédits ou en dollars américains aux tarifs de tokens de l’abonnement. Elles ne sont pas incluses dans le quota habituel. Les crédits d’analyse gratuits des comptes éligibles sont utilisés avant la consommation payante.

Les 500 USD ne constituent ni un versement en espèces ni un avantage garanti à tous. Une fois le solde gratuit épuisé, les règles de facturation du compte ou de l’espace de travail s’appliquent. Avant de commencer, vérifiez votre éligibilité, le solde gratuit restant et les conditions d’utilisation payante dans l’interface.

Le « coût » affiché n’est pas nécessairement votre facture

Dans Cloud, ouvrez l’analyse concernée depuis « Scans » pour consulter ses tokens et son coût. Survolez le nombre de tokens pour voir la répartition entre entrée, entrée en cache et sortie. Le coût affiché est calculé avant les crédits gratuits ou les exonérations de facturation : distinguez donc la déduction des crédits gratuits du montant réellement facturé. Les analyses portant la mention « Exempt from billing. No charges apply. » ne sont pas facturées.

Source concernant la facturation, les quotas gratuits et les coûts affichés : OpenAI, FAQ Codex Security Cloud : facturation. L’échéance est exprimée en heure du Pacifique, conformément à la documentation.

N’appliquez pas le quota gratuit de Cloud au plugin local

Le plugin local s’exécute comme une tâche Codex. Selon les règles générales d’utilisation de Codex, la consommation dépend de l’abonnement, du modèle, de la charge de travail et de l’authentification ; le travail local supplémentaire authentifié par une clé API relève de la facturation API. Toutefois, le guide de configuration locale, la documentation Standard et Deep et la FAQ CLI que nous avons consultés ne fournissent ni tarif fixe par analyse ni grille distincte couvrant tous les usages du plugin. Nous ne pouvons pas affirmer que les analyses locales ne consomment rien ou qu’elles utilisent les 500 USD de Cloud.

Consultez votre quota Codex restant dans l’interface d’utilisation ou avec /status dans Codex CLI. Les coûts des analyses Cloud doivent aussi être vérifiés côté Cloud. Pour comparer les abonnements, consultez notre guide des tarifs et quotas d’utilisation de Pro.

Sources : OpenAI, tarifs et utilisation de Codex et Work et sélection de l’authentification dans la CLI.

Première analyse : étapes et exemple de demande

Voici les instructions officielles de configuration. Analysez uniquement du code qui vous appartient ou que vous êtes autorisé à inspecter. Pour une première analyse, vérifiez la branche et la révision ciblées, l’emplacement de sortie et l’authentification. Commencer avec Standard facilite le suivi du processus.

Le plugin local dans l’application de bureau

1. Recherchez « Codex Security » dans la liste des plugins, puis installez-le et activez-le. La version Cloud est un plugin distinct.
2. Ouvrez « Security » → « Scans » → « + Scan » dans la barre latérale.
3. Sélectionnez un dépôt et choisissez « Codebase » pour analyser sa base de code. Laissez « Deep scan » désactivé pour la première analyse.
4. Vérifiez les dossiers à inspecter, la branche et la révision actuelles, le modèle et l’effort de raisonnement.
5. Si nécessaire, ajoutez les points d’entrée publics, les règles d’autorisation et les opérations importantes dans « Additional context ».
6. Choisissez « Start scan » et suivez chaque étape. À la fin, lisez la couverture et les preuves.

Dans Codex CLI, installez-le via /plugins, puis utilisez /new pour créer une nouvelle conversation pour le dépôt ciblé. Nommer explicitement l’analyse dédiée et sa cible laisse une trace plus claire que la simple demande « vérifie la sécurité ».

Lance une analyse Standard avec Codex Security, centrée sur services/billing.
Donne la priorité aux entrées utilisateur, aux vérifications de propriété des informations de facturation et aux opérations d’administration.
Pour cette tâche, inspecte et rends compte uniquement. Ne modifie pas le code source, ne fais pas de commit, de push ou de déploiement et ne change pas les paramètres de facturation.
Indique la révision ciblée, le périmètre inspecté, les zones exclues ou inachevées et les preuves de reproduction.
Si un changement de paramètre est nécessaire, explique la proposition et sa raison, puis arrête-toi.

Il s’agit d’un exemple de demande, pas d’une configuration d’isolation qui impose des autorisations. Les analyses peuvent nécessiter des fichiers de sortie et un travail de validation. Ne supposez pas que des restrictions écrites suffisent à protéger tout l’ordinateur ; vérifiez aussi les droits d’exécution.

La version Cloud connectée à GitHub

1. Installez « Codex Security Cloud » et vérifiez sa connexion GitHub au dépôt ciblé.
2. Dans « Scan », sélectionnez le dépôt et l’environnement. « Auto » crée un environnement au lancement ; utilisez « Customize » pour vérifier un environnement déjà préparé.
3. Choisissez « One-Time Scan » pour une inspection ponctuelle ou « Continuous Scanning » pour surveiller les futurs commits.
4. Vérifiez les tarifs, le solde gratuit et la cible avant de choisir « Create » pour commencer.

L’analyse continue cible la branche par défaut du dépôt. Un historique de commits plus long allonge l’inspection initiale. Pour arrêter la surveillance, ouvrez « Repositories » → le dépôt ciblé → « Monitoring settings », mettez-la en pause et enregistrez. Fermer la fenêtre n’arrête pas la surveillance.

Sources : OpenAI, configuration du plugin et configuration et surveillance dans Cloud.

Standard et Deep : ajuster le périmètre et les ressources

Les paramètres officiels par défaut de Deep prévoient 4 workers simultanés, 3 sous-agents par worker et une durée maximale de 96 heures. Les 96 heures sont une limite configurée, pas une durée d’analyse typique. La configuration de la limite de temps exige la version 0.1.19 du plugin ou une version ultérieure. Lorsque la limite est atteinte, les workers inachevés s’arrêtent et les résultats terminés sont consolidés. Les zones non inspectées restent non inspectées.

Limitez d’abord la cible à un service cohérent et lisez les résultats de Standard avant de décider si Deep est nécessaire. Vous pouvez aussi concentrer l’inspection approfondie sur des zones importantes, comme les paiements ou l’authentification. Réduire le nombre de workers ou la durée peut diminuer les ressources nécessaires, mais aussi laisser davantage de problèmes inaperçus. Consignez le périmètre couvert par l’analyse rendue moins coûteuse ou plus rapide.

Utilisez « Changes » pour inspecter un diff. Vous pouvez choisir des modifications non commitées, un commit unique ou des révisions de base et cible, mais Deep n’est pas disponible pour les analyses Changes. Celles-ci inspectent le diff et le code directement lié ; elles ne deviennent pas automatiquement un audit complet du code.

Sources : OpenAI, Standard, Deep et paramètres par défaut, couverture des analyses Changes et limites de coût estimées.

Lire la couverture et les preuves, pas seulement le nombre de résultats

Le nombre de résultats ne suffit pas à établir la qualité d’une analyse. Une mauvaise cible, un arrêt en cours de route ou l’absence de règles d’autorisation peuvent produire zéro résultat sans rendre le code sûr. Le workflow officiel de Standard recommande lui aussi de commencer par la révision, les zones inspectées, les zones différées et les preuves individuelles.

1. La cible est-elle correcte ? Vérifiez le dépôt, la révision et le périmètre. N’utilisez pas des résultats sur du code ancien comme garantie pour la version actuelle.
2. Qu’est-ce qui n’a pas été inspecté ? Vérifiez les zones exclues, différées ou interrompues. Un indicateur de fin ne signifie pas que tout le code a été couvert.
3. Les preuves sont-elles solides ? Examinez le chemin de l’entrée au comportement dangereux, les défenses existantes ainsi que la méthode et les résultats de reproduction.
4. Faut-il corriger ? Évaluez la possibilité réelle d’atteindre le problème et son impact, puis corrigez les résultats acceptés un par un.

report.md est le point d’entrée lisible. Le fichier structuré coverage.json consigne les zones inspectées et différées, tandis que findings.json décrit les emplacements, la gravité, les preuves et les recommandations de correction des résultats. findings/ peut contenir des rapports détaillés et des fichiers de reproduction. Conservez les fichiers associés avec le rapport lorsque vous partagez ou archivez les résultats.

La CLI autonome classe la couverture comme complete, partial ou unknown. Une couverture marquée partial ou unknown produit le code de sortie 2. Même si un résultat disparaît lors d’une analyse ultérieure, vous ne pouvez pas le considérer comme corrigé si le chemin original n’a pas été inspecté. La validation automatique de Cloud tente elle aussi une reproduction. Un résultat non validé ne prouve pas que le code est sûr.

Sources : OpenAI, évaluation des analyses Standard, couverture et comparaisons de la CLI et validation automatique de Cloud.

Correctifs, vérification et informations confidentielles

Expliquez les règles d’autorisation pour faciliter l’évaluation

Précisez dans le contexte de l’analyse qui doit pouvoir effectuer quelles opérations. Par exemple : « Seuls le propriétaire et les administrateurs peuvent accéder à la facturation » ou « Seul le propriétaire d’un fichier peut le publier ». Dans le plugin local, SECURITY.md peut contenir la politique de sécurité durable, tandis que AGENTS.md peut contenir les instructions de compilation et de validation. Dans Cloud, revoyez le modèle de menace généré et complétez les lacunes concernant les points d’entrée publics, les opérations importantes et les frontières de confiance.

Un modèle de menace décrit brièvement la structure de l’application et les conditions à protéger. Les modifications dans Cloud s’appliquent aux analyses futures. Changer les hypothèses ne modifie pas rétroactivement ce qu’un rapport précédent a inspecté.

Corrigez un résultat à la fois et vérifiez la reproduction ainsi que le fonctionnement normal

1. Acceptez un résultat : Examinez les preuves et l’impact réel, puis choisissez un résultat à traiter.
2. Générez un petit correctif : Dans l’interface locale, choisissez « Patch » → « Generate patch ». Générer une proposition est distinct de son application au répertoire de travail ciblé.
3. Lisez le diff : Vérifiez qu’il ne contient pas de nettoyage sans rapport ni de changements affaiblissant d’autres défenses avant de choisir « Apply patch ».
4. Vérifiez le correctif : Utilisez « Verify fix » pour vérifier la reproduction originale et le fonctionnement normal. Si possible, conservez un test de régression qui échoue avant le correctif et réussit après.
5. Clôturez le résultat : La vérification ne le clôture pas automatiquement. Examinez les lacunes restantes des preuves et clôturez-le avec une justification ou poursuivez l’enquête.

Lorsque Cloud fournit un correctif, le workflow exige aussi de le revoir avant de créer un brouillon de PR. Consignez séparément la proposition, l’application, la vérification et le déploiement en production. Consultez aussi nos vérifications avant publication des applications créées avec l’IA , au lieu de confier toutes les décisions à un seul outil d’analyse.

« Local » ne signifie pas qu’aucune donnée ne quitte votre ordinateur

Même en exécution locale, vérifiez séparément le traitement des requêtes d’inférence du modèle et des informations de validation. Les instructions officielles de la CLI autonome avertissent que les analyses utilisent les autorisations du système d’exploitation local, ne s’arrêtent pas pour approuver chaque opération et peuvent hériter des variables d’environnement. Ne supposez pas qu’elles ont les mêmes droits qu’une conversation Codex classique. Préparez un environnement sans identifiants superflus.

Les journaux enregistrés ne sont pas nécessairement expurgés automatiquement et peuvent contenir du code source ou des identifiants. Les fichiers produits peuvent aussi inclure des étapes de reproduction et des détails de vulnérabilités. Vérifiez leur contenu et le périmètre de partage avant de créer un lien public ou de les transmettre à un tiers. Les paramètres d’entraînement des modèles sont traités séparément dans notre guide de confidentialité et de données d’entraînement de ChatGPT et Codex.

Sources : OpenAI, SECURITY.md et AGENTS.md, modèles de menace de Cloud, correctifs et vérification et autorisations, fichiers et journaux de la CLI autonome.

Liste de contrôle avant de commencer

Pour une première analyse, commencez par Standard sur le périmètre nécessaire et vérifiez que vous pouvez en évaluer vous-même les résultats. Envisagez Cloud pour la surveillance continue ou la CLI autonome pour intégrer les analyses à des workflows automatisés. Utilisez-le comme un outil d’aide à la découverte et à la validation, pas comme une preuve de sécurité remplaçant l’analyse statique existante (SAST) ou la revue humaine.

Questions fréquentes