Aller au contenu principal
PraktikPraktikLe guide IA utile
S'abonner
Intermédiaire8 min

Connecteurs et outils avec Codex

Ce que tu vas apprendre

Comment brancher Codex sur des sources externes (MCP, Slack, Linear) sans encombrer ta session. Quand rester local. Comment structurer un handoff clair.

Prerequis

  • Avoir lu les modules 01 a 05
  • Comprendre la difference entre contexte local et contexte externe
  • Avoir un repo ou tu peux tester codex exec

Le concept en 30 secondes

Codex lit ton repo par defaut. Quand la verite est ailleurs (API docs, ticket Linear, thread Slack), tu connectes la source minimale necessaire. Tu resumes ce que l’outil a prouve avant d’editer.

Etapes

1. Decider si tu as besoin d’un connecteur

Reste local quand :

  • Le repo contient assez d’indices (code, tests, config)
  • Tu peux reproduire le bug sans appel externe

Utilise un connecteur quand :

  • L’API a change et la doc officielle est la seule source
  • Le ticket Linear contient le cahier des charges
  • Le thread Slack a le contexte produit

2. Configurer un serveur MCP

Ajoute dans ton ~/.codex/config.toml :

[mcp.servers.docs]
command = "npx"
args = ["-y", "@modelcontextprotocol/server-fetch"]

Verifie que le serveur repond :

codex exec -- "list available mcp tools and confirm the docs server is reachable"

3. Interroger une source externe

Formule ta question avant d’appeler l’outil. Pas de “regarde si y’a des infos”.

Question : quelle est la signature de la fonction createUser dans l'API v2.4 ?
Source : doc officielle via MCP fetch
Fichiers affectes : src/services/user.ts
Donnees a exclure : cles API, donnees client

Dans Codex :

codex exec -- "use MCP to fetch the official API docs for createUser v2.4, summarize the signature, then check src/services/user.ts for drift"

4. Resumer l’evidence avant d’editer

Codex doit te dire :

  • Quelle source il a consultee
  • Ce qu’elle prouve
  • Quels fichiers locaux sont impactes

Puis seulement : proposer la modification.

5. Handoff Slack / Linear

Forme canonique d’un ticket a passer a Codex :

Utilise le ticket Linear lie comme contexte produit.

Objectif : une phrase.
Perimetre : fichiers ou sous-systeme.
Ne pas modifier : exclusions explicites.
Verification : commande exacte ou check manuel.
Retour : resume, fichiers modifies, resultat de verification, questions ouvertes.

Exemple concret :

Utilise le ticket LINEAR-42.

Objectif : ajouter la validation email cote serveur.
Perimetre : src/api/users.ts et les tests associes.
Ne pas modifier : le frontend, la base de donnees.
Verification : npm test -- users.test.ts.
Retour : fichiers changes, resultat des tests, risques restants.

Verification

  • La question externe est formulee avant l’appel
  • La source est la plus etroite possible (un serveur MCP, pas cinq)
  • L’output de l’outil est resume avant toute edition
  • La verification finale repose sur des checks locaux
  • Les donnees sensibles n’ont pas ete extraites sans raison

Pieges courants

  • Deviner l’etat externe → Toujours lire via le connecteur
  • Brancher un outil trop large → Un seul serveur MCP par question
  • Oublier de resumer → “L’outil dit X, donc je modifie Y”
  • Handoff sans definition de fin → Chaque ticket doit avoir une commande de verification

Recapitulatif

Situation Action Outil
Bug reproduisible localement Rester local Aucun
API doc a verifier Requete ciblee MCP fetch
Ticket Linear a implementer Handoff structure Integration Linear
Thread Slack avec contexte Resumer puis editer Integration Slack

Pour aller plus loin