Politiques d'usage et contrôle

Leçon corrigée le 3 novembre 2026 d’après les pages Workspace model availability, ChatGPT usage limits and spend controls et Pricing de la documentation de Codex : le routage de modèles en GPT-5.6 est remplacé par la famille GPT-6, les valeurs de départ de l’espace de travail sont présentées comme des valeurs par défaut et non des permissions, et les restrictions par « type de tâche », qui n’existent pas dans le produit, sont présentées comme une politique appliquée par la CI, le bac à sable et GitHub. Sources : Workspace model availability · Usage limits.

Définir les règles d’utilisation de Codex

Une fois Codex déployé dans votre organisation, il vous revient d’établir des politiques claires : qui peut faire quoi, sur quels projets, avec quels modèles et dans quelles conditions. Faute de ce cadre, chaque développeur fixe sa propre limite en fonction de son tempérament, et vous découvrez l’écart le jour où une PR entièrement générée par l’agent modifie une routine d’authentification sans que personne n’ait jugé utile de s’en inquiéter.

Ce qu’on autorise, ce qu’on encadre, ce qu’on interdit

Le document de politique interne s’organise autour de trois cercles. Le premier rassemble les usages sans risque particulier, où la relecture ordinaire suffit largement. Le deuxième couvre les domaines dans lesquels une erreur se paie cher et qui exigent donc une approbation préalable. Le troisième énonce les interdits, ceux qui ne se négocient pas au cas par cas un vendredi soir.

## Utilisations recommandées
- Génération de tests unitaires et d'intégration
- Refactoring de code existant (avec review humaine)
- Documentation automatique (JSDoc, README, API)
- Code review en première passe
- Debugging à partir de logs et de stack traces
- Migrations de bibliothèques et de frameworks

## Utilisations nécessitant une approbation
- Modifications de code lié à la sécurité (auth, crypto)
- Changements de schéma de base de données
- Modifications d'infrastructure (Dockerfile, CI/CD)
- Code touchant aux données financières ou médicales

## Utilisations interdites
- Génération de code sans review humaine en production
- Accès à des repos contenant des données clients brutes
- Utilisation de Codex pour contourner les processus de review

La dernière interdiction est celle qu’il faut formuler avec le plus de netteté, parce qu’elle décrit une dérive naturelle et progressive : un développeur pressé finit toujours par se convaincre qu’une relecture faite par l’agent équivaut à une relecture faite par un collègue. Écrire noir sur blanc que ce raisonnement est interdit coupe court au débat.

Qui valide quoi

L’approbation reste une notion floue tant que personne n’est nommé. Une matrice de responsabilité tranche la question en associant chaque type de modification à un émetteur autorisé et à un niveau de validation. Elle protège le code autant qu’elle fluidifie le travail : sans elle, la moindre décision remonte au tech lead, qui devient à son tour le goulot d’étranglement.

Traduire la politique en contrôles techniques

Une politique que rien n’applique reste un document de plus dans le wiki. Trois leviers la rendent effective, à condition de savoir lesquels relèvent du produit et lesquels de votre organisation.

Le premier concerne les modèles. Votre politique peut orienter les usages :

Développement courant → GPT-6.1 Sol
Travaux les plus exigeants → GPT-6 Astra (sur décision de l'équipe)
Tâches simples et répétitives → GPT-6 Luna
Rédaction, travail visuel → GPT-6.1 Terra

Côté produit, les propriétaires et administrateurs de l’espace de travail peuvent fixer des valeurs de départ séparées pour Chat d’une part, pour Work et Codex d’autre part : modèle, niveau de raisonnement, vitesse. Ce sont des valeurs par défaut, pas des permissions : les modèles réellement disponibles dépendent du siège, du rôle, de l’identité (compte ChatGPT ou clé d’API), des exigences imposées et de la surface utilisée. Un réglage de modèle de l’espace ChatGPT ne s’applique pas automatiquement à Codex dans le CLI, l’extension, le cloud ou l’API, et Codex Cloud ne permet pas de changer son modèle par défaut. Avec une clé d’API, l’accès aux modèles suit l’organisation et le projet de la plateforme associés à la clé.

Le deuxième levier restreint ce que l’on automatise par dépôt. Il n’existe pas de bouton « par type de tâche » : cette politique s’applique avec les moyens réels du dépôt — quels workflows CI y appellent Codex, avec quel bac à sable, quelles règles de commandes, quelles protections de branche côté GitHub :

repo: production-api
  - revue de PR : ✅ (revue automatique, sandbox read-only)
  - génération de code : ⚠️ proposée en patch, jamais poussée
  - correction automatique de CI : ❌ diagnostic seulement

repo: internal-tools
  - revue de PR : ✅
  - génération de code : ✅
  - correction de CI : ⚠️ en PR séparée, relue

Le troisième levier concerne le budget. Les contrôles de dépense de l’espace de travail permettent, selon votre offre, des garde-fous par utilisateur, des plafonds au niveau de l’espace et des notifications ; la facturation de l’API se pilote à part. Fixez vos seuils dans la politique, puis configurez-les :

Notification à 80 % du budget mensuel
Plafond à 100 % du budget mensuel
Revue des usages atypiques avec le responsable d'équipe
Rapport mensuel à partir des analyses de l'espace de travail

Propriété intellectuelle et responsabilité

Selon les conditions d’utilisation d’OpenAI, les contenus produits vous appartiennent : OpenAI ne revendique pas de droit de propriété sur les sorties de l’outil. Cette clarté juridique ne vous dispense pas de l’inscrire dans votre politique interne, car la question qui se pose réellement en équipe n’est pas celle de la propriété mais celle de la responsabilité. Qui répond d’une ligne de code que personne n’a écrite à la main ?

## Propriété intellectuelle
- Le code généré par Codex appartient à [votre entreprise]
- Les développeurs sont responsables du code qu'ils valident
- Codex est un outil — la responsabilité finale est humaine
- Les PRs de Codex doivent être reviewées comme n'importe 
  quelle PR d'un développeur

La réponse tient dans la deuxième ligne : celui qui valide assume. Cette formulation ferme la zone grise dans laquelle un développeur pourrait, après un incident en production, expliquer que le code venait de l’outil et non de lui.

Réviser la politique tous les trimestres

Une politique écrite au démarrage devient inadaptée en quelques mois, tout simplement parce que les usages évoluent plus vite que les documents qui les encadrent. Programmez une revue trimestrielle en cinq étapes :

1. Analysez les métriques d’utilisation (qui utilise quoi, combien)
2. Reviewez les incidents (erreurs de Codex, problèmes de sécurité)
3. Collectez le feedback des développeurs
4. Ajustez les quotas et permissions
5. Mettez à jour la documentation interne

Attendez-vous à assouplir autant qu’à durcir. Une bonne partie des restrictions posées par précaution au démarrage se révèlent inutiles une fois les usages réels observés, et les maintenir sans raison ne fait qu’entretenir le contournement.

Points clés à retenir

• Rédigez une politique d’utilisation claire et partagée avec toute l’équipe
• Définissez une matrice de responsabilité pour chaque type de modification
• Configurez des contrôles techniques : modèles, repos, coûts
• Le code généré vous appartient, mais la responsabilité est humaine
• Revoyez votre politique trimestriellement