Passer votre application codée avec Claude Code en production
Claude Code a écrit une bonne partie de votre application depuis le terminal. Nous relisons ce qu'il a produit, encadrons ce qu'il peut faire et mettons votre application en production, sans repartir de zéro.
Vous vous reconnaissez ?
Ces situations reviennent chez la plupart des équipes qui codent avec Claude Code et nous contactent :
- Claude Code a fait de nombreux changements en autonomie, et personne n'a relu chaque modification
- Vos consignes de sécurité sont écrites dans CLAUDE.md, mais rien n'empêche techniquement de les enfreindre
- Le fichier .env avec vos vraies clés est lisible par l'agent, faute de règle qui l'interdise
- Des serveurs MCP connectés à la session donnent à l'agent un accès à des outils externes que personne n'a revus
- Les tests ont été écrits par le même agent que le code, et vous ne savez pas s'ils vérifient vraiment quelque chose
- Claude Code tourne aussi dans votre CI ou sur vos pull requests, avec des droits que vous ne maîtrisez pas
- Vous n'osez pas déployer, parce que vous ne savez pas ce qui va casser
Aucune de ces situations n'est un échec : un agent qui travaille dans le terminal va très vite. La mise en production demande de reprendre la main sur ce qu'il a écrit et sur ce qu'il a le droit de faire.
Ce que Claude Code fait déjà, et ce qui reste à votre charge
Claude Code, l'agent de développement d'Anthropic, travaille dans votre terminal ou votre éditeur : il lit le dépôt, modifie les fichiers et exécute des commandes. Il propose plusieurs modes de permissions, de la validation de chaque action à un mode automatique où un modèle séparé bloque les actions jugées dangereuses. Il dispose aussi d'un bac à sable pour isoler les commandes et d'une commande de revue de sécurité des changements en cours.
Ces protections réduisent les risques, mais la documentation d'Anthropic est claire : la relecture du code et des commandes proposées reste de votre responsabilité. Et comme Cursor, Claude Code n'impose ni hébergement ni base de données : l'architecture, l'infrastructure et le déploiement dépendent des choix faits pendant le développement.
Ce que nous vérifions en priorité sur un projet codé avec Claude Code
Ce que l'agent a le droit de faire. CLAUDE.md donne des consignes, il ne bloque rien. Les contrôles se configurent dans les fichiers de réglages : règles qui interdisent la lecture des fichiers .env et des secrets, liste des commandes autorisées, hooks qui stoppent une action interdite avant son exécution, et bac à sable pour les commandes. Nous les mettons en place au niveau du projet, versionnés avec le code, pour que toute l'équipe travaille avec le même cadre.
Les accès externes. Nous revoyons les serveurs MCP déclarés dans le projet et ceux connectés en dehors, ainsi que les droits donnés à Claude Code dans la chaîne d'intégration ou sur les pull requests, pour qu'il n'ait accès qu'au strict nécessaire.
Le code lui-même. Nous relisons l'authentification, l'accès aux données et les parcours critiques, unifions les solutions différentes apportées au même problème et vérifions chaque dépendance ajoutée. Nous vérifions aussi que les tests existants échouent bien quand le code est faux.
Les garde-fous. Chaîne d'intégration continue qui fait passer tests et analyse de sécurité à chaque pull request, branche principale protégée, relecture humaine avant fusion, et séparation stricte entre les accès de développement et ceux de production.
Ce qui est inclus
Audit du code existant
Architecture, qualité du code, dépendances et failles de sécurité — un état des lieux écrit avant tout développement.
Sécurisation
Secrets sortis du code, authentification vérifiée, dépendances à jour, conformité RGPD si des données personnelles sont en jeu.
Mise en production
Tests automatisés, CI/CD, hébergement dimensionné et monitoring — pour déployer sans craindre chaque mise à jour.
Questions fréquentes
Oui. Claude Code ne produit pas un code de moindre qualité par nature, mais il permet d'en écrire beaucoup très vite, parfois en autonomie. Ce qui manque généralement, ce sont des tests fiables, une architecture cohérente et des garde-fous avant chaque fusion. C'est ce que nous mettons en place.
Non. CLAUDE.md oriente l'agent, il ne l'empêche de rien. Les règles de permissions, les hooks et le bac à sable sont les mécanismes qui bloquent réellement une action. Nous configurons les deux : des consignes claires dans CLAUDE.md et des contrôles dans les réglages du projet.
En combinant plusieurs protections : des règles qui interdisent la lecture des fichiers .env, un hook qui bloque toute tentative, le bac à sable pour les commandes, et surtout l'absence de clés de production sur les postes de développement. Une clé qui n'est pas là ne peut pas fuiter.
Rarement. L'audit détermine ce qui peut être conservé, ce qui doit être unifié et ce qui doit être remplacé. Dans la plupart des cas, la logique métier est conservée et ce sont la cohérence du code, les tests et l'outillage qui sont repris.
Oui, c'est même l'objectif. Nous configurons le projet pour que l'agent travaille dans un cadre défini et respecte votre architecture, et nous mettons en place les tests et la chaîne d'intégration qui détectent ses erreurs avant qu'elles atteignent la production.
Chaque projet est chiffré sur devis après l'appel découverte et l'audit du code, selon la taille du projet, son architecture et le périmètre visé. Le devis est fixé avant le démarrage.
Le détail complet de la méthode et du déroulé du projet est sur la page Vibe to Prod.
Pour préparer le terrain vous-même, lisez notre guide Combien coûte la mise en production d'un POC vibe-codé.