Règles Cursor prêtes pour la production : Next.js, React TypeScript et FastAPI [Guide 2026]

Les assistants de programmation par IA ont tendance à utiliser des syntaxes dépassées si vous ne fixez pas de limites strictes. Sur des projets web récents, Cursor suggère régulièrement des méthodes obsolètes issues de l'ancien routeur Pages de Next.js, disperse des types any dans vos composants React ou écrit des requêtes synchrones bloquantes au sein de routes asynchrones Python FastAPI.

Les règles Cursor ajoutent des consignes pour réduire ces erreurs dans vos diffs git. En plaçant des fichiers ciblés dans .cursor/rules/, vous donnez au modèle des repères architecturaux ; leur application et l'absence de bugs ou d'hallucinations ne sont pas garanties.

Voici une collection de modèles prêts pour la production pour Next.js, React TypeScript et FastAPI en 2026, accompagnée de conseils pratiques pour structurer vos règles modulaires.

Modèles au 22 octobre 2026 : Cursor répertorie notamment Opus 5.5, Sonnet 5.5, Gemini 4 Argon et GPT 5.6 Sol. Leur disponibilité dépend du forfait, des crédits et des paramètres ; consultez la documentation officielle des modèles et tarifs. Les exemples de règles ci-dessous servent de consignes, pas de mécanisme de contrôle du code.

Fichier racine .cursorrules face aux règles modulaires .cursor/rules/*.mdc

Réponse directe : Cursor prend en charge les fichiers modulaires .cursor/rules/*.mdc ainsi que l'ancien fichier .cursorrules. Avec alwaysApply: false, une règle ciblée par globs est jointe lorsqu'un fichier correspondant entre dans le contexte, pas simplement dès son ouverture. Ce ciblage peut limiter les consignes inutiles ; il ne supprime pas les hallucinations. Voir la documentation des règles Cursor.

À ses débuts, Cursor utilisait un fichier unique .cursorrules déposé à la racine du dépôt. Bien que pratique au démarrage, cette approche charge l'ensemble des instructions de toutes vos technologies dans chaque prompt, consommant inutilement des jetons et créant des contradictions entre le frontend et le backend.

Les versions récentes de Cursor prennent en charge des fichiers de règles modulaires au format .cursor/rules/*.mdc. Chaque fichier .mdc associe un en-tête YAML à des recommandations techniques rédigées en Markdown :

---
description: Brève description de la règle
globs: pattern/ciblant/les/fichiers/**
alwaysApply: false
---

# Vos consignes techniques ici

Paramètres YAML clés

• globs : un motif de ciblage (comme src/app/**/*.tsx ou backend/**/*.py). Avec alwaysApply: false, la règle est jointe lorsqu'un fichier correspondant est présent dans le contexte.

• alwaysApply : à définir sur true uniquement pour des règles transversales (format des commits, licences). Laissez ce paramètre sur false pour les règles spécifiques aux frameworks.

• description : résume le périmètre de la règle, facilitant sa sélection automatique par Cursor lors des requêtes avec @.

Pour comparer l'assistance au sein de l'éditeur Cursor avec un agent de terminal autonome, lisez notre analyse complète Claude Code vs Cursor.

1. Meilleures règles Cursor pour Next.js (App Router)

Enregistrez ce fichier sous le nom .cursor/rules/nextjs.mdc. Il rappelle les conventions du routeur App, les précautions relatives aux données côté client et les pratiques de chargement dans les composants serveur. Une revue reste nécessaire.

---
description: Normes pour Next.js App Router et Server Components
globs: src/app/**/*.{ts,tsx},app/**/*.{ts,tsx}
alwaysApply: false
---

# Règles d'architecture Next.js

## Délimitation entre composants serveur et client
- Utiliser par défaut les React Server Components (RSC). N'ajouter "use client" que si le composant recourt à useState, useEffect, des gestionnaires d'événements du navigateur ou des API fenêtrées.
- Placer les composants client aux extrémités de l'arbre de rendu. Descendre les données depuis les composants serveur via des props sérialisables.
- Ne jamais importer de bibliothèques réservées au serveur (clients de base de données, secrets d'environnement) dans des composants client.

## Récupération de données et mutations
- Récupérer les données directement dans les Server Components avec async/await. Éviter le chargement de données via useEffect.
- Utiliser les Server Actions de Next.js pour l'envoi de formulaires et les changements d'état. Regrouper les actions dans le composant ou dans `actions.ts` avec la directive "use server" en tête de fichier.
- Valider systématiquement les paramètres des Server Actions avec des schémas Zod avant toute requête en base.
- Révalider immédiatement le cache des routes après une modification réussie avec `revalidatePath()` ou `revalidateTag()`.

## Navigation et routage
- Employer `next/link` pour la navigation interne ; proscrire les balises HTML `<a>` pour les liens locaux.
- Lire les paramètres de recherche par les props de page ou `useSearchParams()`. Encadrer les composants lisant l'URL par des balises Suspense.

2. Meilleures règles Cursor pour React et TypeScript

Enregistrez ce fichier sous le nom .cursor/rules/react-typescript.mdc. Il demande des types précis, des exports nommés et des composants visuels cohérents ; vérifiez le résultat avec TypeScript, le linter et une revue.

---
description: Normes de développement pour React et TypeScript
globs: **/*.{ts,tsx}
alwaysApply: false
---

# Recommandations React et TypeScript

## Rigueur du typage TypeScript
- Ne jamais utiliser le type `any`. Employer `unknown` pour les entrées non typées et restreindre avec des type guards.
- Privilégier `interface` pour décrire les objets et props de composants. Utiliser `type` pour les unions et types dérivés.
- Déclarer des types de retour explicites sur l'ensemble des fonctions exportées.
- Éviter les assertions non nulles (`!`). Traiter les cas nuls avec le chaînage optionnel (`?.`) ou des valeurs de repli.

## Architecture des composants
- Utiliser exclusivement des exports nommés : `export function UserProfile(...)`. Proscrire `export default`.
- Définir l'interface des props juste au-dessus du composant au format `<NomComposant>Props`.
- Déstructurer les props dans la signature : `function Button({ variant = "primary", children }: ButtonProps)`.
- Extraire la logique complexe dans des hooks personnalisés préfixés par `use`.

## Styles et accessibilité
- Appliquer directement les classes utilitaires de Tailwind CSS. Ne pas recourir aux objets de style inline `style={{ ... }}`.
- Regrouper les classes conditionnelles à l'aide de fonctions comme `cn()` (clsx + tailwind-merge).
- Veiller à l'accessibilité de tous les éléments interactifs (`aria-label`, navigation au clavier).

3. Meilleures règles Cursor pour Python et FastAPI

Enregistrez ce fichier sous le nom .cursor/rules/fastapi.mdc. Il demande des routes asynchrones non bloquantes, des modèles Pydantic v2 stricts et une injection de dépendances standardisée ; les tests doivent valider leur mise en œuvre.

---
description: Normes pour Python FastAPI et Pydantic
globs: **/*.py,backend/**/*.py,api/**/*.py
alwaysApply: false
---

# Directives de développement FastAPI

## Gestionnaires de routes asynchrones
- Déclarer impérativement tous les points d'entrée réalisant des entrées/sorties avec `async def`.
- Ne jamais exécuter d'opérations synchrones bloquantes (comme `requests.get()`, `time.sleep()` ou des pilotes SQL synchrones) dans les routes asynchrones.
- Utiliser `httpx.AsyncClient` pour les appels HTTP distants et des pilotes asynchrones pour la base de données.

## Modèles Pydantic v2
- Séparer nettement les données entrantes, les réponses d'API et les structures de base de données dans des modèles distincts.
- Nommer explicitement les schémas : `UserCreateRequest`, `UserUpdatePayload`, `UserResponse`.
- Configurer systématiquement `from_attributes = True` dans `model_config` lors de la conversion d'objets ORM.
- Employer `Field()` avec des contraintes claires (`min_length`, `gt`, `le`) et des exemples.

## Injection de dépendances et sécurité
- Injecter les sessions de base de données et contextes de sécurité avec la syntaxe `Depends()` de FastAPI.
- Encapsuler les transactions dans des context managers asynchrones pour garantir la fermeture des sessions en cas d'incident.
- Lever des exceptions `HTTPException` munies de statuts HTTP explicites au lieu de retourner des dictionnaires d'erreur bruts.

Harmoniser les règles Cursor avec les agents de terminal

Si votre équipe utilise également Claude Code pour les refactorisations lourdes ou les suites de tests en console, il est recommandé de maintenir vos règles alignées. Pendant que Cursor exploite .cursor/rules/*.mdc, Claude Code lit CLAUDE.md et des compétences agentiques modulaires.

Découvrez comment structurer vos procédures de test et de validation dans notre guide sur les meilleures skills Claude Code pour développeurs, ou explorez notre catalogue de compétences d'ingénierie vérifiées.

Tester et valider vos règles Cursor

Dès vos fichiers sauvegardés dans .cursor/rules/, contrôlez leur bonne prise en compte :

1. Vérifier l'association des globs : ouvrez un fichier ciblé (par exemple src/app/page.tsx).

2. Ouvrir le chat Cursor (Cmd+L) : examinez l'étiquette de contexte au bas de la fenêtre. nextjs.mdc doit figurer dans les règles du projet actives.

3. Appeler explicitement une règle : tapez @ dans le chat, choisissez Rules et sélectionnez la règle désirée.

4. Vérifier dans Composer (Cmd+I) : demandez à Cursor de produire un nouveau composant et observez si le diff respecte les normes définies (exports nommés et typage strict).

Pièges fréquents à éviter

Gardez en tête ces quatre recommandations pour préserver la vitesse de Cursor :

1. Fichiers trop denses : n'insérez pas tout le guide stylistique de votre entreprise. Limitez chaque fichier .mdc à moins de 80 lignes concises.

2. Mode d'association mal choisi : utilisez globs pour le ciblage par fichier et vérifiez alwaysApply ; les autres modes peuvent reposer sur une sélection automatique ou manuelle.

3. Directives contradictoires : harmonisez vos règles entre le fichier .cursorrules global et les sous-fichiers pour éviter que le modèle hésite.

4. Consignes imprécises : préférez des règles mesurables ("limiter les fonctions à 40 lignes") à des formulations vagues ("écrire du code élégant").

Tableau récapitulatif

En configurant des fichiers modulaires .cursor/rules/*.mdc, vous transformez Cursor d'un outil d'autocomplétion ordinaire en un coéquipier de programmation spécialisé, calibré exactement pour les exigences techniques de votre infrastructure.