Cursor en équipe : ce que .cursorrules ne règle pas tout seul

Installer Cursor sur tous les postes, ce n'est pas une adoption. C'est une distribution de licences. Trois mois plus tard, vous avez autant de façons d'utiliser l'outil que de développeurs : un senior qui a un CLAUDE.md de 400 lignes, un junior qui prompt dans le chat sans ouvrir le repo, un lead qui a désactivé l'agent parce que « ça casse les tests ».

Un fichier .cursorrules partagé est utile. Il ne suffit pas.

Ce que les rules font réellement

Elles injectent du contexte dans chaque session : conventions de nommage, stack autorisée, « n'invente pas de librairie », « passe par le design system ». C'est le minimum vital, le même rôle qu'un CONTRIBUTING.md que personne ne relit — sauf que l'agent, lui, le relit.

Elles ne règlent pas :

• Qui a le droit de merger du code généré sans revue humaine.
• Quel modèle on autorise sur quel type de repo (prod vs sandbox).
• Comment on mesure si Cursor accélère vraiment, ou s'il accélère le volume de PR médiocres.
• Que faire quand deux devs ont des rules contradictoires en local.

Sans ça, .cursorrules devient un totem : tout le monde dit qu'il est en place, personne n'a le même comportement.

Le cadrage en quatre livrables

Avant d'écrire la moindre rule, documentez quatre choses. Une page chacune, pas un wiki.

1. Périmètre. Quels repos, quels langages, quels secrets. Cursor n'a rien à faire sur un repo qui contient des dumps clients ou des clés en clair. Si c'est le cas, le problème n'est pas l'IA.

2. Niveaux d'usage. Trois paliers suffisent : autocomplete seulement / agent sur branche jetable / agent sur la branche de travail. Le palier se décide par séniorité et par criticité du service, pas par envie.

3. Revue. Toute PR dont plus de la moitié du diff est générée porte un label. Le reviewer sait qu'il lit autre chose qu'un diff humain. Les garde-fous vibe coding s'appliquent ici, pas « plus tard ».

4. Interdits explicites. Secrets, données perso, code d'un client sous NDA dans un modèle grand public. Le détail RGPD est dans notre guide Claude Code / entreprise — les mêmes règles valent pour Cursor.

Un .cursorrules qui tient

Gardez-le court. Moins de 80 lignes. S'il ressemble à un roman, l'agent le dilue et les humains le forkent en silence.

Structure qui marche :

1. Stack et versions (une liste, pas un manifeste).
2. Ce qu'on ne fait jamais (secrets, deps non listées, fichiers générés commités).
3. Où poser le code (dossiers, nommage des routes, tests à côté).
4. Comment échouer : si l'agent n'est pas sûr, il s'arrête et pose une question.

Le reste — architecture, patterns d'agents, MCP — vit dans des fichiers ciblés (CLAUDE.md, .cursor/rules/ par dossier), pas dans un fourre-tout racine. On détaille ces patterns dans 5 patterns d'agents Claude Code : ils se transposent tel quel dans Cursor.

Ce qui scale, ce qui ne scale pas

Scale : une convention unique, un canal #ia-usage où on poste les ratés, une revue de rules une fois par trimestre. Les outils bougent ; vos interdits, beaucoup moins.

Ne scale pas : former les gens « à Cursor » deux jours puis les laisser seuls. L'outil change toutes les six semaines. La méthode — cadrer, générer, relire, merger — tient. C'est ce qu'on installe en Devcraft Intra, sur vos repos, pas sur un sandbox générique.

Si votre équipe a déjà Cursor et que ça part dans tous les sens, commencez par l'audit : cartographie réelle des usages, puis rules, puis formation. Dans cet ordre. L'inverse produit des slides et zéro standard.