Extensions et modules (Plugins) : packager et installer des ensembles de capacités
📚 Navigation dans la série : Le chapitre précédent [22 · Définir des compétences réutilisables (Skills)] présentait la création de guides d'instructions réutilisables pour Codex. Ce chapitre présente la centralisation de ces outils sous la forme d'une extension (Plugin) : un module unique permettant de charger, désactiver et distribuer conjointement vos compétences, configurations MCP et intégrations. Le chapitre suivant [24 · Règles et points de contrôle d'exécution (Hooks)] abordera le déclenchement automatique d'actions sur des événements du cycle de vie de la session.
Messieurs, nous allons aborder aujourd'hui un sujet pratique et indispensable : les plugins (extensions).
On a tendance à considérer les plugins comme une simple option de confort ou de packaging secondaire, en se disant qu'il vaut mieux maîtriser les fonctions une à une. Cette analyse est erronée. J'ai moi-même commis cette erreur : j'avais configuré sur un projet un ensemble de compétences pour générer de la documentation de schéma de base de données, couplé à un serveur MCP local. Cette configuration m'a pris deux heures. Deux semaines plus tard, voulant réutiliser ce workflow sur un autre projet, j'ai copié les fichiers manuellement un par un. J'ai alors omis une variable d'environnement dans le fichier .mcp.json, et le connecteur a refusé de s'initialiser, m'obligeant à perdre trente minutes en diagnostic. Gérer ses outils de manière dispersée est source d'erreurs et de perte de temps.
La solution officielle de Codex à ce problème s'appelle le système de plugins : il permet d'assembler vos compétences (skills), intégrations applicatives (apps) et serveurs MCP au sein d'un unique module installable d'un clic. Les outils configurés sur un projet se déploient immédiatement sur une autre machine ou auprès de vos collègues, sans copie manuelle de fichiers.
À la fin de ce chapitre, vous aurez en main :
- Les trois composants packagés au sein d'un plugin, et comment choisir entre une compétence simple (Skill) et une extension (Plugin) d'après un comparatif.
- Le fonctionnement de la « Galerie des plugins » (Plugin Directory) pour rechercher et installer des modules via l'application ou en ligne de commande.
- Les commandes CLI pour déclarer une galerie de plugins, installer un module et l'appeler avec le symbole
@. - L'architecture des dossiers d'un plugin (le fichier de configuration
.codex-plugin/plugin.jsonet les sous-répertoires de composants). - Les règles de sécurité obligatoires concernant la validation des points de contrôle (hooks) lors de l'installation de plugins tiers.
01 Qu'est-ce qu'un plugin ?
En résumé : un plugin est un répertoire autonome regroupant un ensemble cohérent de compétences (skills), d'intégrations applicatives (apps) et de serveurs MCP, pouvant être chargé, désactivé ou distribué comme un ensemble unique.
La gestion individuelle des fichiers de configuration pose trois limites : la difficulté de réutilisation entre projets, le manque de partage d'équipe et la complexité des mises à jour. Pour utiliser vos configurations MCP et vos compétences sur un nouveau projet, vous devez copier les fichiers manuellement et informer vos collègues des modifications à apporter à leurs variables système. Le plugin résout cela en encapsulant ces composants dans un répertoire unique diffusable.
Analogie : L'aménagement complet livré en kit. Si vous achetez séparément chaque meuble d'un bureau — la table, les étagères, le luminaire et les bacs de rangement —, vous devez vérifier les dimensions de chaque élément, rechercher les références et assembler les composants manuellement. Une formule de kit complet vous livre l'ensemble des éléments dans un lot unique, prêts à être disposés. Le système de plugins de Codex applique cette approche : il regroupe les outils dans un kit d'extension prêt à l'emploi.
La documentation officielle liste les trois types de composants intégrables :
| Composant | Description | Mode d'utilisation |
|---|---|---|
| Skills (Compétences) | Instructions de traitement réutilisables lues par le modèle lors d'une tâche. | Déclenché automatiquement par correspondance sémantique ou appelé via @. |
| Apps (Intégrations applicatives) | Connecteurs vers des services cloud (GitHub, Slack, Google Drive, etc.) pour interagir avec vos données. | Requiert une autorisation de droits via votre compte ChatGPT lors du premier usage. |
| MCP servers | Outils de connexion locaux ou réseau (Model Context Protocol) pour étendre les capacités de Codex. | Peut nécessiter des déclarations de variables d'environnement pour l'accès. |
Le plugin unifie ces trois dimensions de Codex — les compétences (chapitre 22), les serveurs MCP (chapitre 20) et les intégrations d'applications externes (Gmail, Slack, Drive, etc.).
La documentation officielle indique comment choisir entre une compétence simple (Skill) et un plugin (Plugin) : privilégiez les compétences locales au projet pour les usages personnels ou temporaires au sein d'un dépôt unique. Utilisez les plugins pour le partage d'équipe, le regroupement de configurations complexes (MCP et Apps) ou pour la distribution de modules dotés d'un suivi de version.
| Dimension | Compétence locale (Skill) | Extension (Plugin) |
|---|---|---|
| Cas d'usage type | Usage personnel, cycle court, règles propres à un dépôt unique | Partage avec des tiers, intégration de connecteurs, déploiement global |
| Composants inclus | Généralement un unique fichier de consignes textuelles | Combinaison de compétences, serveurs MCP, applications et hooks |
| Mode de partage | Copie manuelle du dossier | Galerie partagée (marketplace) ou répertoire Git avec installation d'un clic |
| Gestion des versions | Non gérée nativement | Suivi par numéro de version (version) dans le fichier manifeste |
Retenez cette règle simple : si l'outil se résume à une consigne textuelle pour votre usage de tous les jours, utilisez une compétence. Si vous devez distribuer un enchaînement d'instructions intégrant des services réseau ou des serveurs de données, packagez l'ensemble dans un plugin.
💡 En résumé : Un plugin de Codex assemble des compétences, des connecteurs applicatifs et des serveurs MCP au sein d'un répertoire autonome. Utilisez les compétences pour vos besoins individuels locaux, et concevez des plugins pour la distribution de configurations complexes.
02 Les avantages du packaging unifié
Cette section détaille l'intérêt d'un module par rapport à des configurations éparses.
La centralisation des composants apporte trois gains majeurs dans un cadre professionnel :
1. Simplification de la réutilisation inter-projets : comme illustré dans l'introduction, un connecteur de base de données couplé à des scripts d'audit exige plusieurs fichiers (consignes, configurations MCP, jetons réseau). Packagez ces éléments dans un plugin : son installation sur un nouveau projet charge l'ensemble des dépendances d'un coup, éliminant les risques de mauvaise configuration. 2. Alignement des configurations d'équipe : le partage de fichiers d'instructions par copier-coller expose à des erreurs de manipulation ou de chemin d'accès. Un plugin publié sur une galerie partagée (ou sur le répertoire de travail de l'entreprise) s'installe d'un clic sur la machine de vos collaborateurs, garantissant que chacun utilise la même configuration. 3. Suivi de version et maintenance : le fichier manifeste du plugin intègre une clé version. Les modifications apportées à vos connecteurs ou consignes sont distribuées par mise à jour de version. Les paramètres d'autorisation (modes de validation, activation des outils) peuvent être configurés localement dans votre fichier utilisateur sans modifier le code source du plugin.
Analogie : Le profil de configuration d'un terminal d'entreprise. Lors de l'attribution d'une machine de travail, l'administrateur n'installe pas manuellement chaque certificat de sécurité, profil VPN et accès réseau un par un. Il déploie un fichier de profil de configuration unique qui applique l'ensemble des règles et accès d'un coup. Le système de plugins joue ce rôle de profil d'outils pour Codex : il applique un ensemble de capacités et d'accès en une seule opération.
Comparatif d'utilisation :
| Tâche d'administration | Avec des fichiers dispersés | Avec un plugin |
|---|---|---|
| Déploiement sur un nouveau dépôt | Copie manuelle des répertoires, avec risque d'oubli de clés | Commande d'installation unique |
| Partage de configuration | Documentation des variables à ajouter au fichier local | Publication sur une galerie interne ou dépôt partagé |
| Évolution des instructions | Modification manuelle obligatoire sur chaque machine | Mise à jour de version du plugin |
Dans un cadre d'équipe, l'intégration de nouveaux collaborateurs s'en trouve accélérée : la configuration des outils de développement internes passe d'une liste de consignes manuelles à une unique commande de déploiement de plugin.
💡 En résumé : Le packaging sous forme de plugin fiabilise le déploiement sur plusieurs projets, harmonise les outils de vos équipes et simplifie la maintenance grâce au suivi de version.
03 La galerie des plugins : L'espace d'installation de Codex
Où se situent les plugins mis à disposition ? Codex intègre une galerie de modules appelée « Galerie des plugins » (Plugin Directory).
La galerie classe les plugins en trois catégories :
| Catégorie | Description |
|---|---|
| Curated by OpenAI (Sélectionnés par OpenAI) | Modules officiels validés par l'éditeur, disponibles pour tous les utilisateurs. |
| Shared with you (Partagés avec vous) | Plugins développés et partagés par les membres de votre espace de travail ChatGPT. |
| Created by you (Créés par vous) | Vos propres extensions ou modules en cours de développement local. |
La recherche et l'installation s'effectuent par deux interfaces :
Via l'application de bureau : Ouvrez l'onglet Plugins dans les paramètres, parcourez les fiches de présentation et cliquez sur le bouton d'installation Add to Codex.
Via la ligne de commande (CLI) : Ouvrez la console de gestion en session active (notez l'usage de la commande slash au pluriel /plugins) :
codex
/pluginsL'interface console regroupe les plugins par galerie (marketplace). Utilisez les flèches ou onglets pour naviguer, sélectionnez un module et validez l'installation avec Install plugin. L'appui sur la touche Espace sur un module installé permet de modifier son activation (le suspendre temporairement sans le supprimer).
Pour utiliser les capacités du plugin installé :
- Par description sémantique : Formulez votre consigne en langage naturel, par exemple : « Récupère les dernières notes depuis Google Drive ». Codex identifie le connecteur approprié et l'appelle.
- Par appel explicite via le symbole
@: Si vous souhaitez forcer l'usage d'un plugin ou d'une de ses compétences, saisissez le symbole@suivi du nom de la ressource dans votre message.
Cette syntaxe @ correspond à celle présentée pour les compétences au chapitre 22, la ressource étant ici issue du lot du plugin.
💡 En résumé : La galerie propose des plugins officiels, partagés ou personnels. L'accès s'effectue via l'onglet de l'application de bureau ou en saisissant
/pluginsen console. L'appel se fait en langage naturel ou explicitement avec le symbole@.
04 Gestion des droits et authentification lors de l'installation
L'installation d'un plugin n'entraîne pas l'octroi automatique de droits d'accès. Codex maintient ses règles d'approbation et de bac à sable habituelles sur les modules installés.
Le périmètre d'accès dépend de la nature des composants du plugin :
| Composant | Comportement après installation |
|---|---|
| Skills | Immédiatement disponibles pour le modèle, sans action de validation réseau. |
| Apps | Requiert une connexion OAuth sur votre compte ChatGPT (lors de l'installation ou du premier appel d'outil). |
| MCP servers | Exige la présence de variables d'environnement de jeton d'accès ou d'une authentification spécifique. |
Les compétences textuelles s'exécutent dès l'installation, tandis que les connecteurs d'applications et serveurs MCP exigent une validation d'accès distincte.
Note de sécurité concernant le traitement des données : lorsqu'un plugin transmet des données via une application externe (comme GitHub ou Slack), le traitement des flux est régi par les conditions d'utilisation de ce tiers. Évaluez la conformité de ces services tiers avec vos exigences de confidentialité.
Analogie : L'installation d'une application de gestion sur votre mobile. L'installation de l'application est immédiate (le plugin est chargé). Toutefois, lors du premier lancement, le système mobile vous demande d'autoriser l'accès aux contacts ou de vous authentifier sur votre compte de stockage (l'authentification applicative). L'installation initiale et l'autorisation d'accès aux données sont deux étapes distinctes.
Pour supprimer ou désactiver un plugin :
- Désinstallation complète : Ouvrez la fiche du module dans
/pluginset sélectionnez Uninstall plugin. Note de nettoyage : La désinstallation retire le plugin de Codex, mais les autorisations d'applications associées au sein de votre compte ChatGPT doivent être révoquées manuellement dans les paramètres de votre compte. - Désactivation temporaire : Modifiez le paramètre d'activation dans votre fichier global
~/.codex/config.toml(en associant la cléenabled = falsesous le bloc du plugin) et relancez votre session Codex :
[plugins."gmail@openai-curated"]
enabled = falseLe nommage respecte la structure nom_plugin@nom_galerie. Cette clé correspond à l'action de la touche Espace de la console.
💡 En résumé : L'installation est distincte de l'authentification. Les applications exigent une liaison OAuth et les serveurs MCP des jetons d'accès. La désinstallation se gère dans la galerie de plugins, et la désactivation s'écrit sous la clé
enabled = falsedansconfig.toml.
05 En pratique : Déclarer une galerie, installer et utiliser un plugin
Voici un exercice pratique pour déclarer une galerie externe en ligne de commande, installer un plugin et l'appeler au sein d'une session.
Note technique : La gestion des galeries de plugins s'effectue via les commandes
codex plugin marketplacede votre terminal système. Ce sont des commandes d'administration indépendantes des sessions Codex actives.
Étape 1 : Déclarer une galerie de plugins
Pour associer une galerie hébergée sur un dépôt Git, exécutez la commande suivante dans votre console système (remplacez owner/repo par les identifiants réels de votre dépôt) :
codex plugin marketplace add owner/repoLe système supporte également d'autres syntaxes de déclaration selon vos sources :
codex plugin marketplace add owner/repo --ref main
codex plugin marketplace add https://github.com/exemple/plugins.git --sparse .agents/plugins
codex plugin marketplace add ./galerie-locale-testL'argument --ref permet de cibler une branche ou un tag Git spécifique. L'option --sparse PATH restreint le téléchargement au répertoire indiqué (valable pour les sources Git). Vous pouvez également cibler un répertoire local pour vos phases de test.
Étape 2 : Vérifier les galeries configurées
Affichez la liste des galeries enregistrées sur votre machine :
codex plugin marketplace listComportement attendu : Le terminal liste les sources actives de votre configuration (galerie officielle et galeries ajoutées) avec leurs chemins d'accès locaux ou distants.
D'autres commandes d'administration sont disponibles (pour mise à jour ou retrait) :
codex plugin marketplace upgrade # Met à jour l'ensemble des galeries
codex plugin marketplace upgrade nom_galerie # Met à jour une galerie spécifique
codex plugin marketplace remove nom_galerie # Supprime une galerie de votre configurationÉtape 3 : Installer un plugin depuis l'interface
Lancez une session Codex et ouvrez l'interface de gestion :
codex
/pluginsComportement attendu : L'interface console s'affiche. Naviguez vers l'onglet de votre galerie ajoutée, sélectionnez the plugin souhaité et validez son installation avec Install plugin.
Étape 4 : Utiliser le plugin dans une nouvelle session
Règle d'activation : Ouvrez un nouveau fil d'exécution (new thread) pour que Codex prenne en compte le plugin installé. Formulez ensuite votre demande ou utilisez le symbole @ pour appeler explicitement sa compétence :
@nom_competence_plugin applique l'analyse sur ce fichier de code.Comportement attendu : Codex charge le composant du plugin. Si le plugin utilise une application externe, l'invite de liaison OAuth s'affiche à l'écran. Validez la connexion pour finaliser le traitement.
Cet exercice valide la chaîne d'intégration d'un plugin depuis sa galerie source.
💡 En résumé : La configuration associe une galerie via
codex plugin marketplace add, installe le module dans la console de session avec/plugins, et appelle ses fonctions au sein d'un nouveau fil d'exécution avec la syntaxe@.
06 Structure de fichiers d'un plugin personnalisé
Si vous souhaitez assembler vos compétences et configurations au sein d'un plugin, vous devez en comprendre l'organisation.
Pour initialiser la structure, la documentation conseille d'utiliser l'assistant de création intégré en saisissant l'appel suivant dans votre session active :
@plugin-creatorCet assistant génère l'architecture des sous-répertoires et initialise le fichier manifeste indispensable .codex-plugin/plugin.json.
L'architecture d'un plugin s'organise autour d'un fichier manifeste d'identité et de répertoires de composants :
Le fichier manifeste .codex-plugin/plugin.json contient les métadonnées de l'extension :
{
"name": "mon-premier-plugin",
"version": "1.0.0",
"description": "Exemple de workflow de documentation de code.",
"skills": "./skills/"
}Le paramètre name sert d'identifiant et définit l'espace de noms (namespace) des outils associés. L'éditeur conseille d'utiliser un format d'écriture en minuscules avec tirets (kebab-case). Les clés skills, mcpServers, apps et hooks déclarent les chemins relatifs (débutant par ./) vers les répertoires correspondants.
Les répertoires de composants se placent à la racine du dossier du plugin, selon l'arborescence suivante :
| Composant | Emplacement recommandé | Clé du manifeste associée |
|---|---|---|
| Compétences (Skills) | skills/<nom_competence>/SKILL.md | skills |
| Points de contrôle (Hooks) | hooks/hooks.json | hooks (optionnel si chemin par défaut) |
| Serveur MCP | .mcp.json (à la racine) | mcpServers |
| Intégrations (Apps) | .app.json (à la racine) | apps |
| Éléments graphiques (assets) | ./assets/ | Référencés sous le bloc interface |
L'organisation des fichiers respecte l'arborescence suivante :
mon-premier-plugin/
├── .codex-plugin/
│ └── plugin.json ← Manifeste d'identité (seul fichier autorisé dans ce dossier)
├── skills/
│ └── hello/
│ └── SKILL.md
├── .mcp.json ← Fichier de configuration MCP à la racine
├── .app.json ← Fichier d'intégration d'applications à la racine
└── hooks/
└── hooks.json⚠️ Règle d'arborescence essentielle : Seul le fichier
plugin.jsondoit être placé dans le sous-dossier.codex-plugin/. Les dossiers de composants (skills/,hooks/,assets/,.mcp.json,.app.json) se situent directement à la racine du répertoire du plugin, au même niveau que le dossier.codex-plugin/. Placer un sous-dossier de composant dans.codex-plugin/empêcherait sa détection par Codex.
Notes de configuration :
- Recherche automatique des hooks : Si vos points de contrôle sont enregistrés sous le chemin par défaut
./hooks/hooks.json, la déclaration de la cléhooksdans le manifeste est facultative. Codex l'analysera de lui-même. - Paramètres de publication : Pour diffuser un plugin sur la galerie officielle, le manifeste intègre des blocs d'informations complémentaires (
author,homepage,license) et une tableinterfacedéfinissant l'affichage graphique (nom d'affichage, icône, couleur de marque et invites de démarrage).
💡 En résumé : Un plugin s'organise autour du fichier manifeste
.codex-plugin/plugin.json(utilisez@plugin-creatorpour l'initialiser). Les sous-dossiers de compétences et fichiers de configuration MCP se placent directement à la racine du répertoire, et non dans le dossier.codex-plugin/.
07 Enjeux de sécurité et validation des points de contrôle (Hooks)
Cette section aborde les consignes de sécurité indispensables lors de l'intégration de modules tiers (faisant écho aux règles de sécurité du chapitre 16).
Le fait qu'un plugin puisse embarquer des accès réseau (Apps), des connecteurs réseau (MCP) ou des scripts automatiques (Hooks) impose une vigilance stricte. L'activation d'un plugin tiers expose potentiellement vos données ou votre environnement d'exécution à ces composants.
Codex applique une sécurité spécifique concernant les scripts d'exécution automatique (hooks) issus de plugins :
L'installation ou l'activation d'un plugin n'entraîne pas la validation de ses scripts automatiques (hooks). Les hooks embarqués dans un plugin tiers sont considérés comme non gérés (non-managed). Codex ignorera leur exécution jusqu'à ce que vous ayez validé et approuvé explicitement la structure de ces scripts.
Ce comportement protège votre système : même en cas de chargement d'un plugin tiers contenant des scripts malveillants, ces derniers ne seront pas exécutés à votre insu. Une invite de confirmation s'affiche au premier appel de l'événement pour vous présenter le script ; vous devez l'auditer avant d'accorder votre approbation.
Règles d'évaluation de la confiance d'un plugin :
| Élément d'analyse | Action recommandée |
|---|---|
| Origine du plugin | Privilégiez les plugins de la galerie officielle (sélection OpenAI) ou de collaborateurs validés. |
| Périmètre des droits | Vérifiez la présence de clés d'applications (apps) ou de serveurs MCP et les autorisations associées. |
| Audit des hooks | Lisez le contenu des scripts du fichier hooks.json avant d'accorder votre confiance lors de l'invite. |
L'usage des fonctionnalités d'équipe s'effectue dans le cadre sécurisé de votre espace de travail d'organisation. Toutefois, la sécurité finale repose sur votre contrôle des permissions d'exécution.
État du déploiement (à titre indicatif d'après les notes de l'éditeur) : La publication ouverte sur la galerie officielle est répertoriée comme en cours de déploiement (coming soon). Le partage de plugins s'effectue actuellement par dépôt partagé ou au sein des espaces de travail de votre organisation.
💡 En résumé : Les plugins intègrent des capacités d'accès et d'exécution importantes. Par sécurité, les scripts automatiques (hooks) de plugins tiers ne s'exécutent pas à votre insu ; vous devez vérifier et valider leur comportement lors de la demande d'approbation.
08 Résumé
Ce chapitre a présenté le packaging et la distribution de composants de développement sous forme de plugins dans Codex.
Voici les points clés à retenir :
| Composant | Règle d'intégration |
|---|---|
| Utilité | Assemble des compétences, connecteurs applicatifs (apps) et serveurs MCP dans un module installable d'un clic. |
| Choix | Privilégiez les compétences locales pour un usage individuel, et le plugin pour la distribution et le partage de configurations complexes. |
| Installation | S'effectue dans l'onglet Plugins ou via la commande slash /plugins en console. |
| Galeries | Gérables avec les commandes codex plugin marketplace (add / list / remove). |
| Structure | Articulée autour du manifeste .codex-plugin/plugin.json ; les dossiers de composants se placent à la racine. |
| Sécurité | Les droits d'applications exigent des authentifications tierces ; les scripts (hooks) tiers exigent votre validation explicite avant exécution. |
Vous êtes désormais en mesure de faire la différence entre une compétence simple et un plugin, de parcourir la galerie de modules, de configurer de nouvelles sources de plugins en ligne de commande, d'appeler les fonctionnalités d'un plugin installé, de structurer l'arborescence des fichiers d'un plugin personnalisé, et d'auditer les scripts automatiques d'un module tiers avant de lui accorder votre confiance.
Le chapitre suivant 24 · Règles et points de contrôle d'exécution (Hooks) présente l'automatisation des actions : qu'est-ce qu'un point de contrôle (Hook) dans Codex, comment configurer un script pour qu'il s'exécute automatiquement avant la création d'un commit ou au lancement de l'application, et comment gérer sa sécurité ? Nous verrons comment intégrer des règles de validation automatiques.