Codex propose trois façons d’étendre un agent : les skills, qui transmettent votre processus, les serveurs MCP, qui accèdent aux systèmes en direct, et les plugins, qui regroupent les deux pour une équipe. Cet article montre à quoi ressemble chacun sur le disque, ce qu’il coûte en contexte et comment choisir entre eux.
Ouvrez le navigateur de plugins de Codex et vous verrez les skills, les serveurs MCP et les plugins listés côte à côte, comme s’il s’agissait de trois versions de la même chose. Ce n’est pas le cas. Les confondre, c’est finir par écrire un fichier d’instructions de 400 lignes alors qu’il fallait un simple connecteur de dix lignes, ou configurer un serveur alors qu’une checklist d’une page aurait suffi.
Voici d’abord la version courte. Un skill apprend à Codex comment accomplir une tâche. Un serveur MCP donne à Codex un accès en direct à un outil ou à une source de données. Un plugin est la boîte qui regroupe skills, serveurs et connexions d’applications, afin que quelqu’un d’autre puisse les installer en une seule étape. La suite de cet article montre à quoi ressemble chacun sur le disque, ce qu’il coûte en contexte, où il montre ses limites, et comment choisir le bon pour votre propre travail.
Trois objets posés sur un même établi rendent la distinction facile à retenir. La clé est un outil que l’on saisit. Le classeur indique comment mener une tâche. La caisse est un ensemble que quelqu’un a emballé pour le remettre à un collègue.
SKILL.md qui indique à Codex quand et comment exécuter un flux de travail répétable.Aucun ne remplace les autres. Un plugin n’est pas une quatrième sorte de capacité. C’est un conditionnement des deux premières, auquel s’ajoutent des connexions d’applications, avec un numéro de version.
Un skill est une fiche de recette : des étapes ordonnées, des quantités et une description de ce à quoi ressemble le résultat « terminé ». Un serveur MCP est un appareil branché au mur : il fait ce que le cuisinier ne peut pas faire à la main, comme mixer ou réfrigérer. Un plugin est le kit de repas : la fiche, les ingrédients et une note sur l’appareil nécessaire, le tout dans une seule boîte.
💡 Règle empirique : si le problème est « Codex ne connaît pas notre processus », écrivez un skill. Si c’est « Codex ne peut pas atteindre ce système », ajoutez un serveur MCP. Si c’est « mes coéquipiers me demandent sans cesse comment j’ai configuré ceci », créez un plugin.
Le Model Context Protocol est un standard ouvert, présenté par Anthropic à la fin de 2024, qui permet à un client d’IA de dialoguer avec des outils externes via une interface commune. Codex joue le rôle de client. Le serveur est ce que vous lui indiquez : un connecteur GitHub, un pont vers une base de données, une recherche dans la documentation, un générateur d’images.
Un serveur MCP répond à une seule question : que pouvez-vous faire maintenant, et avec quelles données ? Il liste des outils avec leurs noms, leurs descriptions et leurs schémas d’entrée. Lorsque Codex juge qu’un outil convient à la tâche, il l’appelle et lit le résultat. Rien dans le serveur n’indique la manière dont votre équipe préfère l’utiliser. Un serveur de base de données exécutera toute requête que vous autorisez, mais il ne dira pas à Codex que personne ne touche aux tables de facturation le vendredi après-midi.
C’est cet écart qui rend serveurs et skills si complémentaires. Le serveur fournit la portée. Le skill fournit le jugement.
Codex stocke les réglages MCP dans ~/.codex/config.toml, les réglages propres à un projet pouvant être placés dans .codex/config.toml. Un serveur local que Codex démarre lui-même (STDIO) s’écrit ainsi :
[mcp_servers.docs]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
Un serveur distant utilisant le HTTP en flux continu s’appuie plutôt sur une URL :
[mcp_servers.figma]
url = "https://mcp.figma.com/mcp"
bearer_token_env_var = "FIGMA_OAUTH_TOKEN"
Vous pouvez aussi lancer codex mcp add <name> -- <command> pour rédiger l’entrée à votre place, codex mcp list pour voir ce qui est configuré, et codex mcp login <server-name> pour exécuter OAuth pour les serveurs qui en ont besoin.
Quelques réglages méritent attention. startup_timeout_sec vaut 10 secondes par défaut, ce qui peut être juste pour un premier téléchargement npx lent. tool_timeout_sec vaut 60 secondes par défaut, ce qui coupera les tâches longues comme le rendu d’une vidéo. enabled_tools et disabled_tools vous permettent de réduire un serveur aux seuls appels que vous voulez réellement faire voir à l’agent.
Les coûts de MCP sont bien réels. Chaque serveur connecté ajoute des définitions d’outils que le modèle doit porter, un processus ou un saut réseau susceptible d’échouer, et une nouvelle frontière de confiance. Un serveur capable d’écrire dans votre dépôt peut aussi écrire quelque chose que vous n’aviez pas voulu.
Un skill est un dossier. À l’intérieur se trouve un fichier SKILL.md qui commence par un court en-tête YAML, placé entre deux lignes de délimitation en haut du fichier. L’en-tête contient un name et une description :
name: release-notes
description: Use when the user asks for release notes or a changelog built from merged pull requests. Do not use for commit message drafts.
Sous l’en-tête, les instructions sont en markdown simple :
1. List the pull requests merged since the last tag.
2. Group them under Added, Changed and Fixed.
3. Write one plain sentence per item.
4. Save the result to docs/releases/<version>.md.
Le dossier peut aussi contenir des scripts, des documents de référence, des modèles et des ressources vers lesquels pointent les instructions. Codex cherche les skills dans .agents/skills du dépôt (le répertoire de travail, ses parents et la racine du dépôt), dans $HOME/.agents/skills pour les skills personnels, dans /etc/codex/skills pour les skills partagés à l’échelle de la machine, et dans l’ensemble intégré livré avec Codex.
Les skills utilisent la divulgation progressive. Au début d’une session, Codex ne voit que la liste des noms et descriptions de skills, et cette liste est plafonnée à environ 2 % de la fenêtre de contexte (ou à 8 000 caractères lorsque la taille de la fenêtre est inconnue). Le SKILL.md complet ne se charge qu’une fois le skill sélectionné. Le fonctionnement est celui d’un meuble à fiches : vous lisez les fiches jusqu’à trouver le bon tiroir, puis vous sortez le fichier entier.
La conséquence est concrète. Vous pouvez garder des dizaines de skills installés sans payer pour chacun à chaque requête. Cela signifie aussi que la ligne description fait tout le travail. Une description vague, comme « aide pour la documentation », ne se déclenche jamais. Une description précise, qui indique quand utiliser le skill et quand s’en abstenir, se déclenche de façon fiable.
Il existe deux façons d’exécuter un skill. Explicite : tapez $release-notes dans la CLI de Codex ou dans l’extension pour l’IDE (ChatGPT utilise @release-notes). Implicite : Codex choisit le skill de lui-même lorsque votre demande correspond à la description. Un fichier agents/openai.yaml facultatif ajuste la façon dont le skill apparaît dans l’interface, sa politique d’appel et les outils dont il dépend.
💡 Si un skill ne se déclenche jamais seul, réécrivez sa description avant de réécrire ses instructions. La description est le déclencheur.
La prise en charge des plugins est arrivée dans Codex en mars 2026, et le lancement comprenait plus de 20 plugins, dont Box, Figma, Linear, Notion, Sentry, Slack, Gmail et Hugging Face. Les plugins existent pour la distribution. Un skill peut être copié dans un dossier et un serveur collé dans un fichier de configuration, mais remettre les deux à dix coéquipiers avec des versions concordantes est fastidieux et source d’erreurs.
my-plugin/
plugin.json
mcp.json
skills/
release-notes/
SKILL.md
hooks/
assets/
scripts/
plugin.json à la racine est le manifeste, et .codex-plugin/plugin.json reste accepté en solution de repli. Il contient le name en kebab case, une version, une description et les coordonnées de l’auteur. Les skills se trouvent dans skills/<skill-name>/SKILL.md et sont repris depuis ce dossier sans avoir à être déclarés. Les serveurs MCP vont dans mcp.json sous mcpServers, avec "type": "streamable-http" pour les points d’accès distants. Les hooks exécutent des commandes à des moments définis du cycle de vie.
Pour tester en local, ajoutez une entrée dont source.path pointe vers votre dossier dans un fichier de marketplace situé à ~/.agents/plugins/marketplace.json ou $REPO_ROOT/.agents/plugins/marketplace.json, puis installez-la depuis le répertoire de plugins. L’assistant @plugin-creator peut créer le dossier et l’entrée de marketplace à votre place.
Dans la CLI de Codex, lancez /plugins pour ouvrir le navigateur de plugins et installer depuis les marketplaces configurées. Dans l’application de bureau ChatGPT ou sur le web, ouvrez l’onglet Plugins, recherchez, cliquez sur le bouton plus et connectez n’importe quel service externe lorsque cela vous est demandé. Ensuite, vous pouvez formuler votre demande en langage naturel (« Résume les fils Gmail non lus d’aujourd’hui ») ou taper @ suivi du nom du plugin pour l’appeler explicitement.
Un plugin ajoute aussi un manifeste, une version à maintenir et une entrée de marketplace. Si vous êtes la seule personne à utiliser ce flux de travail, un skill dans $HOME/.agents/skills et un bloc dans config.toml font le même travail avec moins de cérémonie.
💡 La documentation de Codex évolue vite. Les noms de fichiers et les commandes ci-dessus suivent les pages d’OpenAI consacrées aux plugins, à MCP et aux skills, en octobre 2026. Vérifiez-les avant de vous lancer.
| Skill | Serveur MCP | Plugin | |
|---|---|---|---|
| Ce que c’est | Dossier contenant SKILL.md | Service d’outil ou de données en cours d’exécution | Paquet installable |
| Apporte à Codex | Une procédure | Un accès en direct et des actions | Les deux, plus les connexions d’applications |
| Se trouve dans | .agents/skills | config.toml | plugin.json et mcp.json |
| Chargement | Nom et description d’abord, corps à la demande | Définitions d’outils à la connexion | Tout ce qu’il regroupe |
| Nécessite du code | Non | Oui, ou un serveur hébergé | Seulement s’il regroupe un serveur |
| Idéal pour | Processus d’équipe répétable | Systèmes que Codex ne peut pas atteindre | Partager une configuration complète |
| Risque principal | Une description vague ne se déclenche jamais | Permissions trop larges | Dérive de version, serveurs groupés cachés |
Les skills sont les moins coûteux des trois, car seule une courte description reste dans le contexte tant que le skill n’est pas nécessaire. Un serveur MCP est plus lourd : sa liste d’outils est transportée dans la session, que la tâche l’utilise ou non, si bien que dix serveurs bavards peuvent étouffer le travail réel. Un plugin hérite du coût de tout ce qu’il contient.
Une habitude fait économiser beaucoup de tokens. Avant d’ajouter un serveur, demandez-vous si un skill accompagné d’un script court pourrait faire la même chose. Les scripts d’un skill ne s’exécutent que lorsque le skill tourne. Un serveur reste connecté en permanence.
Un skill est du texte accompagné de scripts facultatifs, son danger réside donc dans les commandes que les instructions demandent à Codex d’exécuter. Un serveur est un processus actif doté de ses propres identifiants, ce qui fait des permissions la préoccupation principale. Réduisez-les avec enabled_tools et disabled_tools, et utilisez default_tools_approval_mode pour décider de ce que Codex peut faire sans demander.
Un plugin peut regrouper serveurs, skills et hooks en même temps. Ouvrez donc le plugin.json, le mcp.json et le dossier des hooks avant d’installer l’un d’eux venant d’un inconnu. Conservez les tokens dans des variables d’environnement, comme bearer_token_env_var les attend, et jamais dans un fichier que vous versionnez.
AGENTS.md suffit.En cas de doute, partez du plus petit élément. Commencez par un prompt. Si vous le répétez trois fois, transformez-le en skill. Si le skill a besoin d’un système que Codex ne peut pas atteindre, ajoutez un serveur. Si d’autres personnes ont besoin de ce même duo, enveloppez-le dans un plugin.
Mettre le processus dans un serveur. Les descriptions d’outils servent à expliquer ce que fait un outil, pas la manière dont travaille votre équipe. Un long texte de politique dans un serveur alourdit chaque session. Déplacez-le dans un skill.
Reconstruire un connecteur avec des scripts shell. Si un serveur MCP maintenu existe déjà pour le système visé, un skill rempli de commandes curl sera plus long à écrire et plus difficile à faire fonctionner durablement.
Empaqueter trop tôt. Un plugin avec un seul auteur et un seul utilisateur représente une charge inutile. Attendez qu’une seconde personne demande votre configuration.
Imaginez une petite équipe marketing qui a besoin de photos cohérentes pour son blog. Les trois éléments se répartissent proprement. Le skill, appelons-le brand-photos, contient les règles : format 16:9 pour les images d’articles, lumière naturelle, aucun texte dans l’image, un schéma de nommage des fichiers et la personne qui valide l’ensemble final. Le serveur MCP assure la génération proprement dite. Le plugin livre les deux à chaque coéquipier, afin que personne n’ait à modifier un fichier de configuration à la main.
PicassoIA propose une API pour développeurs à api.picassoia.com/v1 et un connecteur MCP pour ses modèles d’images et de vidéos, dont PicassoIA Image et PicassoIA Image Editor Pro. Cela rend disponible aujourd’hui la partie serveur de ce schéma. Les détails de connexion se trouvent dans votre compte, donc vérifiez que votre client prend en charge le connecteur avant de le brancher.
Le skill indique ensuite à Codex comment bien exploiter cette portée : quelle structure de prompt suivre, quel format demander et quand s’arrêter pour demander l’avis d’un humain. Le serveur n’a jamais besoin de rien savoir de tout cela.
Vous n’êtes pas obligé d’écrire le premier SKILL.md à la main. Un modèle de code comme GPT 5.6 Sol ou Claude Sonnet 5 peut produire un brouillon en quelques secondes.
.agents/skills/brand-photos/SKILL.md.$brand-photos et une demande réelle. Si Codex ne le reprend pas de lui-même, resserrez la description et recommencez.💡 Considérez la sortie du modèle comme un premier jet. Un skill ne vaut que par les vérifications que vous ajoutez après l’avoir observé sur une tâche réelle.
Skills, serveurs et plugins se jugent plus facilement lorsque vous les voyez produire quelque chose. Ouvrez Picasso IA et recréez les photos de cet article : un bureau en chêne de développeur à l’heure dorée, une trousse à outils en toile à côté d’une pile de fiches, une boîte en kraft emballée pour l’expédition. Commencez par PicassoIA Image, modifiez un seul détail à chaque essai, comme l’objectif, la direction de la lumière ou la texture de la surface, et observez comment l’image évolue.
Demandez-vous ensuite ce que le second essai a demandé et que le premier n’exigeait pas. Était-ce une règle que vous répétez sans cesse ? C’est un skill qui attend d’être écrit. Était-ce un système qu’il a fallu ouvrir à la main ? C’est un serveur. Était-ce une configuration que vous voulez offrir à un ami ? C’est un plugin. Testez quelques prompts sur Picasso IA dès aujourd’hui et laissez votre propre flux de travail vous dire celui dont vous avez besoin.
Choisissez votre langue
