27 juillet 2026
Claude Code en production : mon workflow d'ingénieur IA
Mon workflow concret avec Claude Code, Cursor et MCP pour livrer des builds clients IA : cadrage, contexte, agents de code, revues, evals et passage en équipe.
Je traite l'agent de code comme un atelier de production
Quand j'utilise Claude Code sur une mission client, je commence par le même réflexe que pour n'importe quel build IA sérieux : définir le système de travail avant de lancer l'outil. Le sujet concret peut être un assistant métier, un pipeline RAG, une interface interne, un connecteur MCP ou une suite d'evals. Dans tous les cas, je veux savoir ce qui doit changer dans le produit, quelle contrainte métier compte vraiment, quelles commandes prouvent que le changement tient, et quelle partie du repo sert de source de vérité.
Claude Code devient très efficace quand il entre dans un atelier déjà organisé. Je lui donne un périmètre, des chemins, des invariants, une Definition of Done et des conditions d'arrêt. Ensuite je le laisse prendre en charge une boucle d'exécution complète : lire, proposer, modifier, tester, résumer. Mon rôle reste celui d'un ingénieur produit : choisir la bonne bataille, protéger l'architecture, valider la valeur utilisateur, et garder le système assez simple pour être repris par l'équipe après mon départ.
Le cadrage avant le prompt : objectif, contexte, risques
La partie la plus rentable de mon workflow se joue avant la première ligne de code générée. Je transforme la demande en ticket opérable : résultat attendu, utilisateur concerné, fichiers à lire en priorité, comportement existant à préserver, métriques à vérifier, commandes de test, et zones hors périmètre. Pour un agent de code, ce cadrage vaut autant qu'une bonne architecture. Il réduit le bruit, accélère la recherche dans le repo, et rend la sortie beaucoup plus facile à auditer.
Je prépare aussi un petit dossier de contexte. Pour un build client, il contient souvent un schéma de données, un extrait de logs, les routes ou composants clés, les règles métier, quelques exemples réels et les erreurs déjà vues. J'évite le grand déversement de contexte. Claude Code travaille mieux avec un signal dense qu'avec un mur de fichiers. Cette discipline ressemble beaucoup au travail d'un tech lead : rendre l'intention lisible, puis laisser l'exécution avancer vite.
Claude Code pour l'exécution, Cursor pour le pilotage rapproché
J'utilise Claude Code et Cursor pour deux gestes différents. Claude Code est mon outil de boucle longue : il parcourt le repo, applique un changement sur plusieurs fichiers, corrige les types, met à jour les tests, ou prépare un refactor borné. Cursor reste mon cockpit de pilotage rapproché : je lis les diffs, je compare deux options, je réécris un passage sensible, je vérifie une hypothèse produit, je fais une revue ligne par ligne. Le duo marche bien parce qu'il sépare la mécanique d'exécution et le jugement de proximité.
Sur un vrai projet client, cette séparation change la vitesse. Je peux demander à Claude Code de prendre une tranche précise pendant que je garde Cursor ouvert sur les fichiers critiques. Quand la boucle revient, je ne cherche pas seulement si le code compile. Je regarde si l'intention produit est respectée, si la surface de changement reste saine, si les noms racontent la bonne histoire, si le test protège le bon invariant. Ce rythme me donne plus de temps pour le jugement, tout en compressant fortement la mécanique.
MCP donne aux agents un contexte exploitable
MCP est devenu une pièce importante de mon workflow parce qu'il transforme le contexte en interface. Au lieu de coller manuellement des extraits de documentation, des schémas ou des procédures, je préfère exposer des outils propres : recherche documentaire, accès aux tickets, lecture d'un catalogue de composants, requêtes contrôlées, génération de fixtures, ou inspection d'un environnement de test. Pour une équipe, c'est beaucoup plus durable qu'une collection de prompts privés dans les notes de chacun.
Le bon connecteur MCP est petit, lisible et orienté usage. Il donne à l'agent ce dont il a besoin pour agir, avec des sorties structurées et des limites claires. Dans mes builds, je commence souvent avec deux ou trois outils seulement : chercher une source, récupérer un objet métier, produire un rapport vérifiable. Ensuite j'ajoute ce qui améliore vraiment le cycle de livraison. MCP devient alors un rail de production pour les agents, pas une vitrine technique.
La boucle qui livre : plan, tranche, test, revue
Ma boucle standard tient en quatre temps. D'abord, Claude Code lit le périmètre et propose un plan court. Ensuite, il implémente une tranche qui peut être revue seule. Puis il lance les validations prévues : lint, build, tests ciblés, parfois une eval métier ou un scénario browser. Enfin, il revient avec les fichiers changés, ce qui a été vérifié, et les points qui méritent une décision humaine. Cette boucle crée une trace claire et évite l'effet tunnel.
Ce qui marche le mieux, ce sont les tâches avec un contrat visible : ajouter une route, stabiliser un composant, migrer un schéma, brancher un outil, compléter une suite de tests, durcir une erreur de production. Ce qui demande le plus de soin, ce sont les arbitrages produit, les compromis d'architecture, les migrations larges et les sujets où la donnée réelle manque. Dans ces cas, je réduis la taille de la tranche et je fais valider plus tôt par l'humain responsable du produit.
Passer de mon workflow à une équipe de production
Le vrai enjeu pour une équipe cliente est de transformer mon usage personnel en système partagé. Je documente donc les bons prompts sous forme de playbooks, j'ajoute des fichiers d'instructions dans le repo, je garde les commandes de validation visibles, je nomme les MCP par cas d'usage, et je définis une politique de revue adaptée aux agents de code. L'objectif est simple : que l'équipe sache quand lancer Claude Code, comment limiter son périmètre, comment relire sa sortie, et comment décider qu'un changement peut partir en production.
Quand cela fonctionne, l'agentic coding devient une pratique d'ingénierie, pas un moment magique réservé à une personne. Les développeurs juniors gagnent un cadre. Les seniors récupèrent du temps sur les tâches mécaniques. Les responsables produit obtiennent des cycles plus courts et des décisions plus explicites. C'est la version de Claude Code qui m'intéresse : un accélérateur de livraison, connecté à Cursor, outillé par MCP, mesuré par des tests et des evals, et suffisamment clair pour vivre dans une vraie équipe.