Règles Cursor pour le travail d'ingénierie RevOps

Un fichier Cursor .cursorrules calibré pour l’ingénieur RevOps (ou la personne adjacente à l’ingénierie GTM) qui livre du SOQL, de l’Apex, du code personnalisé HubSpot, des flows n8n, et des modèles dbt contre des données de revenu. L’artefact est un fichier unique — apps/web/public/artifacts/cursor-rules-revops-engineer/.cursorrules — que vous déposez dans le répertoire .cursor/rules/ de votre projet et cessez de rediscuter « doit-on bulkifier cela » ou « a-t-on besoin d’un test dbt sur ce modèle » avec l’assistant IA pour le reste du trimestre.

La propriété définissante du code RevOps est qu’il touche les chiffres du pipeline que le CRO rapportera lors du prochain bilan trimestriel. Une écriture dupliquée à grande échelle, une clé de déduplication manquante, ou un bug de progression d’étape ne casse pas seulement un script — il casse les prévisions. Les règles de ce bundle encodent la bulkification, l’idempotence, les vérifications de limites explicites, et les écritures conservatives afin que les suggestions de Cursor reflètent le vrai impact d’une erreur RevOps.

Quand utiliser

Vous êtes un ingénieur RevOps, un ingénieur GTM, ou un responsable RevOps qui écrit du code d’intégration (Python, TypeScript, Apex, flows n8n, modèles dbt) contre Salesforce ou HubSpot. Votre équipe livre au moins quelques modifications par mois qui touchent des données de pipeline. Cursor est votre IDE.

Quand NE PAS utiliser

• Vous ne gérez pas une pratique d’ingénierie en RevOps — votre « automatisation » est constituée de workflows d’administration construits dans l’interface CRM, pas de code dans un dépôt. Les règles supposent des révisions de code, un contrôle de version, et un pipeline de déploiement ; elles n’aident pas un cabinet configuration uniquement.
• Vous êtes un SI externe qui construit des solutions Salesforce pour des clients. Les règles sont calibrées pour l’opérateur interne qui vit avec les conséquences pendant des années ; l’économie de consultant est différente (périmètre de livrable, documentation de passation, modèle de support post-engagement).
• Vous livrez une fonctionnalité d’attribution marketing dans votre produit. Les règles sont destinées à l’ingénierie ops à l’intérieur de l’entreprise qui utilise un CRM, pas aux équipes d’ingénierie qui construisent des produits adjacents au CRM.

Configuration

1. Copier l’artefact. Récupérez .cursorrules du bundle ci-dessus (ou téléchargez le zip) et déposez-le dans le répertoire .cursor/rules/ de votre projet. L’indicateur Project Rules de Cursor confirme qu’il est chargé.
2. Réduire les sections d’outils. Le fichier est livré avec des sections pour Salesforce (SOQL/Apex), le code personnalisé HubSpot, n8n, et dbt. Supprimez les sections que vous n’utilisez pas — laisser des conseils que le modèle doit peser contre un contexte non pertinent dilue le signal.
3. Définir la politique de secrets. Les règles interdisent les credentials codés en dur et dirigent le modèle vers votre gestionnaire de secrets. Modifiez la section « Secrets et accès » afin que le modèle suggère le bon appel (1Password CLI, Doppler, AWS Secrets Manager, Vault — choisissez-en un).
4. Corriger la destination d’audit. Plusieurs règles exigent une référence d’objet d’audit (Cleanup_Audit__c est le placeholder par défaut). Modifiez selon l’objet d’audit réel de votre équipe, ou les suggestions référenceront un nom qui n’existe pas dans votre org.
5. Tester sur une tâche représentative. Demandez à Cursor : « écrire un trigger Apex qui met à jour le Last_Activity_Date__c de l’opportunité chaque fois qu’une tâche associée est clôturée. » La sortie devrait être bulkifiée, inclure une vérification Limits.getQueries(), être livrée avec une classe de test, et ne pas contenir d’Apex anonyme. Si ce n’est pas le cas, les règles ne sont pas chargées — vérifiez l’indicateur Project Rules de Cursor.

Ce que les règles font réellement

Le bundle est structuré en cinq couches, appliquées à chaque prompt Cursor :

1. Un préambule « avant d’écrire du code, demander ». Cinq questions que le modèle remonte avant de générer : quel système est la source de vérité, quel est le volume de données, que signifie l’échec pour le reporting des revenus, est-ce ponctuel ou récurrent, qui lit la piste d’audit. Les questions semblent évidentes. Elles ne sont pas posées assez souvent.
2. Guidance spécifique aux outils pour SOQL/Apex (limites du gouverneur, patterns en lot, WITH SECURITY_ENFORCED), le code personnalisé HubSpot (SDK v4, circuit breaker de quota quotidien, timeout de 20 secondes), n8n (executionOrder, fuseau horaire, nœud IF-vs-Code), dbt (tests unique, ref(), stratégie incrémentale, fraîcheur des sources), et secrets (credentials nommés, tokens Private App, accès limité). Chaque sous-section cite des limites réelles et des versions SDK actuelles.
3. Valeurs par défaut à appliquer à travers la bulkification, l’idempotence, les limites/circuit-breakers, l’observabilité, et les secrets. Chaque valeur par défaut a une valeur concrète : les lots en masse par défaut à 25 enregistrements, le quota quotidien HubSpot s’arrête à 80 % consommé, les flows n8n plafonnent à 1 000 éléments par exécution.
4. Anti-patterns à refuser. Des patterns spécifiques que le modèle rejette : Apex anonyme contre la production, boucles HubSpot sans circuit breakers, nœuds IF n8n avec 5+ conditions, modèles dbt sans tests unique, écritures directes en production depuis des notebooks.
5. Une section « quand l’utilisateur a tort ». Les raccourcis que les ingénieurs atteignent sous la pression des délais que le modèle devrait repousser plutôt qu’exécuter. La règle la plus économique : refuser de contourner une règle de validation Salesforce pour un import, car le contournement produit des enregistrements que les rapports en aval ne peuvent pas agréger, apparaissant comme une variance de prévision que le CRO doit expliquer.

Réalité des coûts

• Coût en tokens : zéro. Les règles Cursor sont du contexte local envoyé sur chaque prompt — aucun frais API par requête au-delà des ~5 Ko qu’elles occupent dans la fenêtre de contexte.
• Temps de configuration : ~10 minutes pour déposer le fichier, définir le gestionnaire de secrets, pointer l’objet d’audit vers un vrai nom dans votre org.
• Surcoût par tâche : le préambule ajoute 1 à 2 tours de dialogue avant la génération. Pour un script de 3 lignes, c’est lourd. Pour une vraie tâche d’intégration, cela fait émerger des décisions qui autrement apparaîtraient en révision de code ou lors d’un walkthrough SOX.
• Maintenance : ~30 minutes par trimestre. Les versions SDK dérivent (v3 → v4 dans HubSpot déjà ; v4 → v5 arrivera). Les limites du gouverneur Salesforce sont stables entre les versions mais valent la peine d’être confirmées sur un Trailhead refresh par version majeure.

À quoi ressemble le succès

• Les variances de prévisions liées à des bugs de qualité des données baissent. Les patterns en lot et les écritures idempotentes empêchent la classe de bugs de lignes dupliquées qui gonfle silencieusement le pipeline.
• La révision de code se concentre sur la logique, pas sur « as-tu bulkifié ». Les règles suggèrent le pattern en lot inline ; les réviseurs arrêtent de noter son absence.
• Les walkthroughs SOX remontent la piste d’audit sans impliquer l’ingénieur. Chaque écriture produit une ligne dans Cleanup_Audit__c (ou l’équivalent de votre équipe) avec (timestamp, utilisateur, objet, record_id, champ, ancienne_valeur, nouvelle_valeur) — l’auditeur peut répondre à ses questions depuis l’objet d’audit, pas depuis un fil Slack avec l’ingénieur.
• La session de débogage « ça marchait avant » sur un SDK obsolète ne se produit pas. Les règles versionées garantissent que le modèle utilise les endpoints actuels ; le code obsolète n’entre jamais dans le dépôt.

Par rapport aux alternatives

• Aucune règle du tout (statu quo). Cursor génère de l’Apex plausible qui échoue aux tests de charge à 200 enregistrements. La première fois que le script en lot tronque silencieusement et que les prévisions dévient de 400 000 $, l’absence de règles devient le goulot d’étranglement.
• Un document de conventions de codage d’équipe dans Notion. Fonctionnellement équivalent à l’absence de règles — le document n’est pas chargé dans le contexte de l’IA. Le fichier de règles Cursor est le document de conventions qui est chargé sur chaque prompt.
• Un linter/analyseur statique (PMD pour Apex, dbt-checkpoint pour dbt). Attrape les patterns après que le code est écrit. Coexiste avec les règles Cursor ; les règles empêchent le code d’être écrit d’abord, le linter attrape les cas qui passent à travers.

Points de vigilance

• Dérive des règles. Les équipes ajoutent des règles et ne les suppriment jamais. Le fichier devient un musée de conseils « c’est comme ça qu’on le faisait » que le modèle essaie encore d’appliquer. Garde : révision trimestrielle avec git blame — tout ce qui a plus de 18 mois est re-justifié ou supprimé.
• Règles conflictuelles. Cursor applique toutes les règles correspondantes ; les directives conflictuelles produisent une sortie confuse. Plafonnement strict du fichier à ~300 lignes. Garde : à l’ajout d’une règle, rechercher les règles existantes sur la même surface ; consolider plutôt qu’ajouter.
• Rotation des versions d’outils. « Utiliser le SDK HubSpot v4 » devient incorrect quand v5 est livré. Garde : versionner chaque règle qui mentionne une version SDK (ex. # HubSpot SDK v4 (vérifié 2026-T2)) afin que le prochain réviseur sache quand revérifier.
• Remplacements par dépôt. Une règle qui est juste dans votre dépôt de prévisions peut être incorrecte dans votre dépôt de routage des leads (ex. valeurs par défaut écriture-vs-lecture). Utilisez le support de règles par répertoire de Cursor ; documentez la divergence dans le README du dépôt. Garde : préférez un fichier de règles partagé avec des exceptions documentées plutôt que de forker le fichier.
• Les règles ne remplacent pas le QA sur les modifications de données en production. Elles façonnent ce que Cursor suggère. Elles ne s’exécutent pas en CI, elles ne valident pas les données que le script touchera, et elles ne constituent pas un contrôle SOX. Garde : maintenez les tests dbt, les règles de validation, et la révision de code comme couches d’application séparées.

Stack

• Cursor — IDE et moteur de règles
• .cursor/rules/revops-engineer.md — versionné dans le dépôt, soumis à révision de code
• Gestionnaire de secrets de choix — référencé depuis les règles, jamais inline
• Objet d’audit — Cleanup_Audit__c ou objet personnalisé équivalent, nommé explicitement afin que les suggestions pointent vers le vrai nom