Politiques d'usage et contrôle

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 techniques la rendent effective, à commencer par le choix des modèles autorisés selon le contexte de travail :

Développement courant → GPT-5.6 Terra (par défaut)
Tâches complexes → GPT-5.6 Sol (approbation manager)
Raisonnement logique → GPT-5.6 Sol, raisonnement élevé (cas spécifiques)
Tâches simples → GPT-5.6 Luna (économique)

Le deuxième levier restreint les types de tâches autorisés par repository. Un dépôt de production et un dépôt d’outillage interne n’appellent manifestement pas la même tolérance, et l’auto-correction de CI, qui pousse un commit sans relecture, n’a rien à faire sur le premier :

repo: production-api
  - review : ✅ autorisé
  - code generation : ⚠️ avec approbation
  - auto-fix CI : ❌ interdit

repo: internal-tools
  - review : ✅ autorisé
  - code generation : ✅ autorisé
  - auto-fix CI : ✅ autorisé

Le troisième levier concerne le budget et repose sur un principe simple : une alerte avant la limite, un blocage à la limite, et une visibilité hiérarchique sur les usages atypiques avant qu’ils ne deviennent des lignes de facture.

Alerte à 80% du budget mensuel
Blocage à 100% du budget mensuel
Notification au manager si un dev dépasse 50$/jour
Rapport hebdomadaire au CTO

Propriété intellectuelle et responsabilité

Le code généré par Codex vous appartient : OpenAI ne revendique aucun 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