Cursor Start from Scratch peut-il être mis en production directement ? Liste de contrôle 2026

Le 28 août 2026, la documentation officielle confirme que Cursor Start from Scratch peut lancer un Cloud Agent sans dépôt de code tiers, générer un projet Origin, afficher un aperçu en temps réel dans le navigateur et proposer une publication via Vercel ; Origin reste toutefois en phase « early beta » (journal officiel des mises à jour de Cursor, documentation Origin). La conclusion est donc opérationnelle : utilisez cette fonction pour valider rapidement un prototype, mais ne publiez jamais directement l’aperçu. Pour la validation de Cursor Start from Scratch, imposez d’abord une reprise par un dépôt identifiable, une construction reproductible, des tests automatisés, l’isolement des secrets, une revue humaine et un retour arrière vérifié.

Vous êtes concerné si vous développez seul une démonstration sans dépôt existant, si votre équipe de création veut faire produire un premier outil interne par Cursor Cloud Agents, ou si vous devez ensuite intégrer ce projet dans une chaîne CI et un environnement de production. Les équipes qui ciblent iOS, macOS, Xcode ou un outil audio et vidéo Apple doivent ajouter une étape spécifique sur un Mac indépendant.

Dernière mise à jour : 28 août 2026. Les capacités et l’état d’Origin sont à revérifier dans le journal officiel de Cursor, sa documentation Origin et la documentation des Cloud Agents avant toute décision durable.

Le même résultat visuel ne mérite pas le même niveau d’acceptation

Avant de lancer l’agent, écrivez ce que vous cherchez réellement à obtenir. Une page qui s’ouvre dans un aperçu est un signal utile pour discuter d’une idée, mais elle ne prouve ni la conservation des données, ni la gestion des erreurs, ni la sécurité des comptes, ni la capacité à reconstruire l’application après la disparition de la session.

Votre premier document doit préciser :

• le type de livraison : démonstration ponctuelle, outil interne ou service accessible à des clients ;
• la pile souhaitée, les commandes de démarrage et la plateforme d’exécution finale ;
• la nature des données : données fictives, informations internes, données personnelles ou contenus soumis à des obligations contractuelles ;
• les services externes nécessaires, comme une base de données, une API de paiement, un fournisseur d’authentification ou un stockage de fichiers ;
• la dépendance éventuelle à Xcode, aux SDK Apple, à un simulateur iOS, à des périphériques physiques ou à un environnement macOS ;
• le niveau de réversibilité attendu si la génération échoue.

Pour une maquette audio, une interface de montage vidéo ou un tableau de bord de design, la frontière est particulièrement importante : le rendu visuel peut être convaincant alors que l’export, la gestion des fichiers lourds, les droits d’accès et la reprise après interruption ne sont pas traités.

Le projet généré peut-il être publié directement ? Non, sauf si « publié » signifie uniquement montrer une démonstration isolée, avec des données sans valeur et un accès temporaire. Une production exige un niveau de preuve supplémentaire : un autre développeur doit pouvoir récupérer le code, comprendre ses dépendances, le reconstruire et annuler la version publiée sans retourner dans la conversation de l’agent.

La première génération doit produire un projet reprenable, pas seulement une session convaincante

Après la génération initiale, ne vous contentez pas de parcourir les écrans. Ouvrez l’arborescence et recherchez les éléments qui permettront à une personne extérieure à la session de reprendre le travail :

• un fichier de présentation expliquant le but, les prérequis et les commandes ;
• une liste explicite des dépendances et de leurs versions retenues ;
• une commande d’installation, une commande de démarrage et une commande de test ;
• une séparation lisible entre interface, logique serveur, accès aux données et configuration ;
• des fichiers de migration ou de création de schéma si une base de données est utilisée ;
• un exemple de configuration sans valeur secrète ;
• des tests ou, à défaut, une liste écrite des comportements qui restent à vérifier.

La question à poser à l’agent n’est pas seulement « l’application fonctionne-t-elle ? », mais « qu’est-ce qu’un autre développeur doit savoir pour la lancer sans cette conversation ? ». Les décisions importantes ne doivent pas rester dans une invite temporaire, un état de terminal ou une mémoire implicite de l’agent.

Comment conserver le code créé sans dépôt existant ? Demandez l’export complet des fichiers, puis créez un dépôt sous le compte ou l’organisation qui en assumera la responsabilité. Ajoutez d’abord un fichier de présentation, le fichier d’exemple de configuration, les règles d’ignorance des fichiers temporaires et la liste des dépendances. Contrôlez ensuite la différence de fichiers avant le premier envoi. La procédure standard de clonage décrite dans la documentation de Git servira de test indépendant : si le projet ne peut pas être cloné proprement, il n’est pas encore transférable.

Trois problèmes apparaissent fréquemment à cette étape :

• les clés d’API ou les jetons de démonstration sont copiés dans le code ;
• des données de test sont mélangées aux fichiers applicatifs ;
• le projet dépend de fichiers cachés ou de variables présentes seulement dans l’environnement de l’agent.

Supprimez les identifiants d’exemple, remplacez-les par des variables injectées à l’exécution et faites une recherche textuelle dans l’ensemble du projet. Une interface qui fonctionne avec une identité fictive n’est pas une preuve que le parcours d’authentification est acceptable.

L’aperçu navigateur doit être confronté aux limites du fonctionnement réel

L’aperçu Origin est utile pour observer l’interface et accélérer les retours, mais il concentre plusieurs fonctions dans un environnement contrôlé. Votre validation doit donc séparer ce qui est visible de ce qui est durable.

Commencez par tester un parcours normal, puis reprenez le même parcours avec une entrée vide, une valeur trop longue, un fichier invalide, une réponse lente du service externe et une autorisation refusée. Actualisez ensuite la page, redémarrez le service et vérifiez que l’état affiché correspond encore aux données réellement enregistrées.

Examinez séparément :

• l’interface statique et ses états de chargement ;
• les routes serveur et leur comportement en cas d’erreur ;
• la persistance après actualisation ou redémarrage ;
• les appels vers les API externes, leurs délais et leurs limites ;
• les journaux, les messages exposés à l’utilisateur et les informations sensibles qu’ils pourraient contenir ;
• la compatibilité entre l’environnement de prévisualisation et la cible de production.

Conservez les journaux de construction, les résultats de tests, les captures des erreurs et la liste des comportements non vérifiés. Cette collection devient la preuve de passage vers l’étape suivante. Si une fonctionnalité n’existe que dans l’aperçu mais disparaît lors d’un redémarrage, retournez à la génération au lieu de la masquer par une correction manuelle non documentée.

Origin et dépôt officiel doivent former une chaîne de responsabilité

La création d’un projet Origin ne répond pas automatiquement à la question « qui est responsable du code ? ». Vérifiez le propriétaire du dépôt, sa visibilité, les membres autorisés, les droits de lecture et d’écriture, ainsi que les réglages Privacy Mode applicables à votre équipe. Les fonctions d’accès et d’intégration doivent être confrontées à la documentation officielle sur la sécurité des Cloud Agents, car la génération distante ne doit pas être traitée comme une machine personnelle pleinement maîtrisée.

Que vérifier avant la mise en ligne d’un projet Cursor Origin ? Vérifiez au minimum l’identité du propriétaire, le périmètre des collaborateurs, les secrets accessibles, l’historique des modifications, la branche de référence et la méthode de retour à la version précédente. Le premier état accepté doit faire l’objet d’une revue humaine, même si l’agent affirme avoir terminé la tâche.

Réalisez ensuite les opérations Git ordinaires :

• cloner le dépôt dans un environnement vierge ;
• installer les dépendances sans réutiliser le cache de l’agent ;
• créer une modification volontaire et vérifier son historique ;
• pousser une branche de travail ;
• ouvrir une demande de modification ;
• fusionner uniquement après revue ;
• récupérer une version connue après une simulation d’échec.

Ce test distingue le code réellement livré d’un projet encore attaché à la session Cloud Agent. Il révèle aussi les droits excessifs, les fichiers générés à tort et les commandes de déploiement non documentées.

La CI doit prouver la reconstruction, pas seulement répéter l’aperçu

Une intégration continue utile commence dans un environnement neuf. Le premier passage doit installer les dépendances, exécuter le contrôle de formatage, lancer les tests unitaires, construire l’application et produire des journaux conservables. Ajoutez ensuite une analyse des secrets, une vérification des dépendances et une étape qui échoue lorsque la configuration obligatoire manque.

Ne remplacez pas une erreur par une valeur par défaut silencieuse. En production, l’absence d’une clé, d’une URL de base de données ou d’un certificat doit interrompre le processus avec un message exploitable. Les variables doivent être injectées par l’environnement prévu, jamais copiées dans le dépôt ou dans une invite réutilisable.

Pour une application web, testez également la création d’une version, son déploiement dans un environnement de préproduction et son retour à la version précédente. Une intégration avec Vercel peut être examinée à partir de la documentation officielle sur les connexions Git, mais l’existence d’une intégration ne dispense pas de vérifier les branches, les variables, les droits et la procédure d’annulation.

Pour un projet iOS ou macOS, la CI générique ne suffit pas. Xcode, les SDK Apple, la signature, les certificats et les simulateurs imposent une validation dans un environnement Mac séparé. La procédure Apple consacrée à la création d’un code Mac signé pour la distribution rappelle que l’archivage et l’export signé constituent des étapes distinctes. Si votre équipe n’a pas encore choisi son environnement de build, comparez les contraintes d’un Mac distant pour le développement avant de promettre une livraison régulière.

Les éléments qui bloquent le passage en production

La décision ne doit pas dépendre de l’impression laissée par la démonstration. Utilisez cette grille interne de notation : une ligne « validée » exige une preuve enregistrée ; une ligne « partielle » autorise uniquement un essai limité ; une ligne « absente » impose le retour à l’étape précédente.

Les coûts invisibles doivent également entrer dans la décision : temps de reprise du code, corrections manuelles, maintenance des dépendances, surveillance des erreurs, rotation des secrets et disponibilité d’un environnement Mac. Un prototype qui semble rapide à produire peut devenir coûteux si personne ne sait expliquer ses choix ou reconstruire son artefact.

Le passage final se décide entre publication, pilote et retour

À la fin de la chaîne, choisissez explicitement l’un des trois états. Le passage en production est justifié seulement si le code est récupérable, les droits sont compréhensibles, la construction est reproductible, les secrets sont séparés et le retour arrière a été essayé. Si une condition est partielle mais que le risque reste contenu, limitez l’accès à une équipe interne ou à un groupe pilote. Si une dépendance critique reste inconnue, retournez à l’étape de génération ou de reconstruction.

Pendant la première période d’exploitation, consignez les échecs de tâches, les corrections humaines, les différences entre environnements, les temps de construction et les incidents de publication. Ne transformez pas ces observations en promesse de performance : elles servent à décider si le flux Cursor Cloud Agents est adapté à votre projet réel.

Le choix de l’environnement compte autant que le choix de l’agent. Une solution locale est souvent préférable pour un besoin durable, très chargé ou dépendant d’interfaces physiques. Un autre environnement distant peut convenir si votre application ne requiert pas macOS. En revanche, une exécution temporaire sur Mac devient pertinente pour valider Xcode, les SDK Apple, la signature ou une chaîne de compilation que votre poste ne peut pas reproduire.

Si votre méthode actuelle repose uniquement sur l’aperçu navigateur, elle présente au moins quatre faiblesses concrètes : le code peut rester attaché à la session initiale, les variables sensibles peuvent être mal isolées, la construction peut dépendre d’un cache invisible et le retour arrière peut n’avoir jamais été essayé. Dans ce cas, louer un Mac avec MacPull offre un environnement séparé pour reconstruire le projet, vérifier la chaîne Apple et documenter la remise à une équipe, sans transformer immédiatement un prototype en achat matériel permanent. Vous pouvez examiner les contraintes d’un fonctionnement Mac distant continu, puis décider si un Mac loué pour un test ou une validation CI correspond à la durée et au niveau de contrôle requis.

Avant de cliquer sur « publier », exportez donc le projet dans un environnement vierge et exigez une preuve pour chaque ligne de la grille. Si Xcode, un SDK Apple ou un nœud macOS durable est nécessaire, poursuivez avec une validation Mac isolée ; si le besoin devient permanent et fortement chargé, comparez plutôt l’achat et la location à partir d’un guide de comparaison des Mac pour le développement.