Passer votre application codée avec Cursor en production
L'agent de Cursor vous a fait gagner des semaines. Nous relisons ce qu'il a produit, posons les garde-fous qui manquent 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 Cursor et nous contactent :
- L'agent a modifié des dizaines de fichiers en une seule demande, et personne n'a relu chaque changement
- 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
- Vos règles de sécurité sont écrites dans .cursor/rules, mais rien ne garantit qu'elles soient respectées
- Bugbot commente vos pull requests, mais rien n'empêche de fusionner malgré ses remarques
- Des dépendances ont été ajoutées sans que personne ne vérifie leur existence, leur maintenance ou leur licence
- Le fichier .env est dans le dossier ouvert par l'agent, avec vos vraies clés de production
- Vous n'osez pas déployer, parce que vous ne savez pas ce qui va casser
Aucune de ces situations n'est un échec : Cursor accélère l'écriture du code, pas sa relecture. La mise en production demande de remettre un contrôle humain et automatique là où l'agent est allé vite.
Ce que Cursor fait déjà, et ce qui reste à votre charge
Cursor est un éditeur de code avec un agent capable de modifier plusieurs fichiers et d'exécuter des commandes. Vous pouvez lui donner des consignes durables avec des règles de projet (des fichiers .mdc dans .cursor/rules, versionnés avec le code) ou un fichier AGENTS.md. Bugbot, son relecteur de pull requests, signale bugs, failles et problèmes de qualité directement sur GitHub.
Ces outils aident, mais ils ne garantissent rien. Les règles sont des consignes données au modèle, pas des contrôles : la documentation de Cursor rappelle elle-même que les consignes à l'IA ne doivent pas être votre seule protection. Et par défaut, les remarques de Bugbot n'empêchent pas une fusion. Contrairement à Lovable ou Bolt, Cursor n'impose ni hébergement ni base de données : l'architecture, l'infrastructure et le déploiement dépendent entièrement des choix faits pendant le développement.
Ce que nous vérifions en priorité sur un projet codé avec Cursor
La cohérence du code. Un agent qui travaille demande par demande produit souvent des solutions différentes au même problème : plusieurs façons d'appeler l'API, de gérer les erreurs ou de vérifier les droits. Nous identifions ces doublons et unifions ce qui doit l'être, en priorité sur l'authentification et l'accès aux données.
Les tests. Nous vérifions que les tests existants échouent bien quand le code est faux, puis nous couvrons les parcours critiques avec des tests dont le résultat attendu ne vient pas de l'agent qui a écrit le code.
Les dépendances et les secrets. Chaque paquet ajouté est vérifié : il existe, il est maintenu, sa licence est compatible et il n'a pas de faille connue. Les secrets sont sortis du code et de l'historique Git, et les clés de production n'ont plus à être présentes sur les postes de développement.
Les garde-fous. Une chaîne d'intégration continue qui fait passer les tests et l'analyse de sécurité à chaque pull request, une branche principale protégée, et une relecture humaine obligatoire avant fusion. Bugbot devient un relecteur de plus, pas le seul.
Continuer à coder avec Cursor, en toute sécurité
L'objectif n'est pas de vous faire arrêter Cursor. Nous configurons le projet pour que l'agent travaille mieux : règles de projet qui décrivent l'architecture et les conventions, fichier BUGBOT.md avec vos exigences de relecture, et tests automatisés qui détectent immédiatement une régression introduite par une demande.
Pour un code confidentiel, nous faisons aussi le point avec vous sur le mode de confidentialité de Cursor et sur les serveurs MCP connectés à l'éditeur, qui donnent à l'agent un accès à des outils externes.
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. Cursor ne produit pas un code de moindre qualité par nature, mais il permet d'en écrire beaucoup très vite, souvent sans relecture complète. 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. Les règles orientent l'agent, elles ne l'obligent à rien. Les contrôles qui comptent sont ceux qui s'exécutent sans dépendre du modèle : tests automatisés, analyse de sécurité dans la chaîne d'intégration, branche protégée et relecture humaine.
Non. Bugbot est un bon relecteur supplémentaire, qui repère des erreurs qu'un humain peut manquer. Mais il ne connaît pas vos règles métier, et par défaut ses remarques ne bloquent pas la fusion. Nous le configurons comme une étape de la relecture, pas comme la relecture elle-même.
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 respecte mieux 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é.