Choisir et configurer ses outils et modèles : Claude, Cursor et LLMs
- arrow_forwardDistinguer les cas d'usage de Claude Code et de Cursor pour orienter le choix selon la tâche
- arrow_forwardComprendre les différentes familles de modèles (raisonnement, généraliste, rapide) et savoir quand les utiliser
- arrow_forwardÊtre capable de configurer un projet pour que l'agent dispose du contexte minimal nécessaire
- arrow_forwardComprendre pourquoi la configuration du projet importe autant que le choix de l'outil et du modèle
Le choix de l'outil est rarement le problème. Ce qui fait la différence, c'est la configuration : un agent mal configuré dans un projet sans contexte produira du code générique qui ne respecte pas vos conventions. Un agent bien configuré dans un projet qui lui donne les bons repères peut livrer quelque chose de mergeable dès le premier essai.
Les deux outils principaux
Claude Code est un agent CLI : il tourne dans votre terminal, lit et modifie vos fichiers, lance des commandes, peut opérer en mode autonome supervisé. Il est idéal pour les tâches qui touchent plusieurs fichiers, les refactors transverses, les ajouts de feature bout-en-bout.
Cursor est un éditeur AI-first : il embarque un modèle directement dans l'IDE, avec complétion contextuelle, chat ancré sur des fichiers sélectionnés, et un mode « Composer » qui peut appliquer des changements multi-fichiers. Il est idéal pour l'édition fine, les questions sur du code existant, les petites modifications en contexte.
Les deux ne sont pas en compétition : ils se combinent. Claude Code pour les tâches d'agent autonome, Cursor pour l'édition quotidienne. Beaucoup de développeurs AI-first utilisent les deux dans la même journée selon la nature de la tâche.
Ce que l'outil doit savoir sur votre projet
Un agent sans contexte projet est comme un développeur junior qui arrive le premier jour sans onboarding. Il va produire quelque chose — mais pas forcément dans le bon langage de framework, pas dans le bon pattern, peut-être avec des dépendances qui entrent en conflit avec les vôtres.
Le contexte minimal qu'un agent doit avoir :
- Quel framework / quelle version (Next.js 15, pas Next.js 13 — les APIs diffèrent)
- Les conventions du projet (où vivent les types, comment sont nommés les fichiers, quel style d'import)
- Les patterns déjà en place (comment vous gérez l'auth, comment vous structurez les composants, quel ORM et comment vous l'utilisez)
- Ce qu'il ne faut pas faire (les anti-patterns que vous avez bannis, les bibliothèques à ne pas ajouter)
Tout ça se met dans un fichier CLAUDE.md à la racine du projet pour Claude Code, ou
dans les règles du projet Cursor. Le module suivant est entièrement dédié à ces fichiers
de contexte.
Configuration minimale de Claude Code
Après installation (npm install -g @anthropic-ai/claude-code), la première chose à
faire dans un nouveau projet :
claude— lancer l'agent interactif> /init— Claude Code analyse votre projet et génère unCLAUDE.mdde départ- Relire ce fichier et le compléter avec vos conventions réelles (il ne les connaît pas toutes — il part du code visible)
Le CLAUDE.md généré par /init est un point de départ, pas un livrable. Vous allez
l'enrichir au fil des sessions dès que vous constatez qu'un agent a raté une convention.
Configuration minimale de Cursor
Dans Cursor, le contexte projet se configure dans .cursor/rules (des fichiers .mdc
ou .md selon la version). La logique est identique à CLAUDE.md : vous décrivez le
projet, les conventions, ce qui est interdit.
Un point important : dans Cursor, vous pouvez ancrer une conversation à des fichiers
spécifiques (@fichier.ts). C'est utile pour poser des questions précises sur un
module sans que l'agent hallucine sur le reste du projet.
Choisir le bon LLM : le moteur derrière l'outil
L'outil (Cursor, Claude Code, Aider, GitHub Copilot) n'est que la carrosserie. Le moteur, c'est le grand modèle de langage (LLM) que vous choisissez pour l'alimenter. Aujourd'hui, vous n'êtes plus limité à un seul modèle. Choisir le bon LLM dépend de trois facteurs : la complexité de la tâche, le coût (ou la vitesse), et la taille du contexte requis.
On peut diviser les modèles de code en trois grandes familles :
1. Les modèles de raisonnement (Reasoning / Thinking)
Exemples : OpenAI o1 / o3-mini, DeepSeek-R1.
- Comment ils fonctionnent : Contrairement aux LLM classiques qui génèrent leur réponse mot à mot immédiatement, les modèles de raisonnement passent par une phase invisible de « réflexion » (chaîne de pensée). Ils planifient, testent des hypothèses et corrigent leurs propres erreurs avant d'écrire la moindre ligne de code.
- Quand les choisir : Pour concevoir une architecture complexe, écrire un algorithme d'optimisation difficile, ou déboguer un bug particulièrement vicieux et multi-fichiers.
- Pourquoi : Ils réduisent drastiquement le taux d'erreur sur les tâches complexes, au prix d'une latence plus élevée et d'un coût supérieur.
2. Les modèles généralistes haut de gamme (Frontier Models)
Exemples : Anthropic Claude 3.5 / 3.7 Sonnet, OpenAI GPT-4o, Google Gemini 1.5 Pro.
- Comment ils fonctionnent : Ce sont des modèles extrêmement polyvalents, rapides pour répondre, et entraînés sur d'immenses volumes de code de haute qualité.
- Quand les choisir : Pour le développement quotidien en mode agent, la génération de fonctionnalités standards (CRUD, formulaires, routes API), et la rédaction de tests.
- Pourquoi : Claude 3.5/3.7 Sonnet est la référence actuelle pour sa précision syntaxique, son respect strict des instructions et sa capacité à naviguer dans une codebase. Gemini 1.5/2.5 Pro se démarque lorsque vous devez lui passer une quantité gigantesque de documentation technique ou de fichiers grâce à son contexte de plus d'un million de tokens.
3. Les modèles rapides et économiques (Fast / Lightweight)
Exemples : Google Gemini 2.0 Flash, Anthropic Claude 3.5 Haiku, OpenAI GPT-4o-mini.
- Comment ils fonctionnent : Des modèles plus petits, ultra-rapides et très peu coûteux.
- Quand les choisir : Pour la complétion automatique en cours de frappe (inline completion), les revues de code automatisées sur la CI, ou les questions rapides de syntaxe.
- Pourquoi : Leur latence quasi nulle permet de coder sans interruption de flux de travail.
Tableau de décision rapide pour les LLMs
| Modèle / Famille | Cas d'usage idéal | Points forts | Points faibles | |---|---|---|---| | Claude Sonnet (3.5/3.7) | Développement quotidien (Agent / Composer) | Précision du code, respect des conventions | Coût modéré | | Reasoning (o3-mini, R1) | Algorithmes complexes, bug complexe, architecture | Logique pure, auto-correction | Lent, pas de complétion inline | | Gemini Pro (1.5/2.5) | Lecture de bases de code géantes, grosses docs | Contexte géant (1M+ tokens), multimodal | Parfois moins rigoureux sur la syntaxe fine | | Modèles Flash (Gemini Flash, Haiku) | Complétion inline, tâches simples de script, CI | Vitesse (latence ultra-faible), coût très bas | Capacité de raisonnement limitée |
Comparaison pratique pour choisir
| Tâche | Claude Code | Cursor | |---|---|---| | Ajouter une feature (plusieurs fichiers) | ✓ mode agent | ✓ Composer | | Refactor transversal (renommage, pattern) | ✓ agent autonome | Possible mais lent | | Question sur un fichier existant | Possible | ✓ Chat ancré | | Édition fine / complétion | Non | ✓ inline | | Pipeline CI / scripts | ✓ | Non |
Ne pas confondre « mode complétion » et « mode agent ». En complétion, l'IA suggère du code ligne par ligne — vous gardez la main constamment. En mode agent, l'IA exécute une séquence d'actions autonomes sur vos fichiers. Ce sont des niveaux d'autonomie très différents qui demandent des garde-fous différents. La leçon suivante couvre ça en détail.
À votre tour
Sur un projet existant que vous avez sur votre machine :
- Lancez
claude /init(ou créez manuellement unCLAUDE.md) et regardez ce que l'agent a compris du projet. - Identifiez deux conventions importantes que le fichier généré n'a pas capturées. Ajoutez-les manuellement.
- Lancez une tâche simple (ajouter un test, documenter une fonction) et observez si l'agent respecte ces conventions.
L'objectif : comprendre ce que le fichier de contexte change réellement sur la qualité du résultat.
En résumé
- L'outil n'est que la carrosserie, le LLM est le moteur. Sélectionnez le modèle selon la complexité et le besoin (raisonnement pour les tâches complexes, généraliste pour le dev quotidien, rapide pour l'inline).
- Claude Code = agent CLI autonome, fort sur les tâches multi-fichiers et les workflows de bout en bout.
- Cursor = éditeur AI-first, fort sur l'édition contextuelle et les questions sur le code.
- Les deux demandent un fichier de contexte projet pour produire un résultat pertinent dans votre codebase.
- La config n'est pas un one-shot : vous l'enrichissez au fil des sessions.
Vérifiez votre compréhension
4 questions · répondez puis validez.