Leçon 12/17 8 min

Choisir son modèle et son outil

Il n'existe pas de meilleur modèle universel : apprenez à accorder le bon modèle et le bon outil à chaque tâche, selon le coût, la vitesse et la qualité.

FR EN

Le marteau pour toutes les vis

Beaucoup de débutants choisissent un modèle IA une fois pour toutes et l'utilisent pour tout : renommer une variable, refactorer une architecture, générer cent lignes de HTML répétitif. C'est comme utiliser un marteau de chantier pour visser une étagère IKEA. Ça finit par marcher, mais c'est lent, cher et parfois maladroit.

La vérité que personne ne dit assez clairement : il n'existe pas de meilleur modèle universel. Il y a le bon modèle pour la bonne tâche. Un développeur efficace jongle entre plusieurs modèles dans la même journée, selon ce qu'il a à faire.

À retenir : les fabricants proposent en général une gamme : un grand modèle de raisonnement (puissant, lent, cher) et un petit modèle rapide (léger, instantané, économique). Le choix se fait selon la difficulté réelle de la tâche, pas par habitude.

Accorder le modèle à la tâche

Le principe est simple : plus la tâche demande du raisonnement, plus vous montez en gamme. Plus elle est répétitive et mécanique, plus vous descendez vers le rapide et l'économique.

  • Grand modèle de raisonnement (type Opus, GPT de haut niveau) : un refactor délicat, une décision d'architecture, un bug tordu que personne ne comprend. Là, payer plus cher et attendre quelques secondes de plus est rentable.
  • Modèle rapide et économique (type Haiku, modèles légers) : du boilerplate, des traductions de chaînes, de la génération répétitive, des reformulations. Inutile de sortir l'artillerie lourde.

Concrètement : on ne mobilise pas un cerveau d'architecte pour poser du carrelage, et on ne confie pas les plans de la maison à un poseur de carrelage. Chaque modèle a sa zone d'efficacité.

Astuce qui change tout : si un modèle bloque ou produit une réponse médiocre, copiez exactement le même prompt dans un autre modèle. Les modèles ont des forces différentes ; ce qui coince l'un se débloque souvent chez l'autre. C'est gratuit, immédiat, et ça évite des heures de lutte inutile.

Le paysage des outils

Le modèle, c'est le cerveau. L'outil, c'est la manière dont ce cerveau accède à votre code. On distingue trois grandes familles :

  • Assistants conversationnels (le chat dans le navigateur) : vous copiez-collez du code, vous discutez, vous récupérez la réponse. Idéal pour réfléchir, apprendre, prototyper une idée isolée. L'IA ne touche jamais directement à vos fichiers.
  • Assistants intégrés à l'éditeur (type Cursor, Copilot) : l'IA vit dans votre IDE, complète votre code, propose des modifications dans le contexte du fichier ouvert. Parfait pour coder au fil de l'eau sans changer de fenêtre.
  • Agents autonomes (type Claude Code) : l'IA lit votre projet, exécute des commandes, modifie plusieurs fichiers et teste son travail toute seule. Puissant pour les tâches longues et multi-fichiers, mais c'est là que la discipline Git (leçon précédente) devient indispensable.

Attention : plus l'outil est autonome, plus il peut faire de dégâts sans surveillance. Un agent qui modifie 15 fichiers tout seul a besoin d'un cadre (commits fréquents, relecture des diffs) que ne réclame pas un simple chat.

Coût, vitesse, qualité : choisissez-en deux

Comme souvent en ingénierie, vous arbitrez entre trois axes : le coût, la vitesse et la qualité. Le grand modèle de raisonnement maximise la qualité au prix de la vitesse et du coût. Le petit modèle maximise vitesse et coût au prix de la profondeur de raisonnement.

Voici une heuristique de décision simple à garder en tête :

La tâche demande-t-elle un vrai raisonnement ?
├─ OUI (archi, bug tordu, refactor delicat)
│   └─ Grand modele de raisonnement
└─ NON (boilerplate, repetitif, reformulation)
    └─ Petit modele rapide et economique

Le modele choisi bloque ou rend du mediocre ?
└─ Copier le MEME prompt dans un autre modele

L'IA doit-elle modifier plusieurs fichiers seule ?
├─ OUI → Agent autonome + discipline Git
└─ NON → Chat ou assistant integre a l'editeur

Règle d'or : ne soyez fidèle à aucun modèle ni à aucun outil. Soyez fidèle au résultat. Le bon professionnel change d'outil sans état d'âme dès qu'un autre fait mieux le travail du moment.

One hammer for every screw

Many beginners pick one AI model once and use it for everything: renaming a variable, refactoring an architecture, generating a hundred lines of repetitive HTML. It is like using a sledgehammer to screw together an IKEA shelf. It eventually works, but it is slow, expensive and sometimes clumsy.

The truth nobody states clearly enough: there is no single best model. There is the right model for the right task. An effective developer juggles several models in the same day, depending on what needs doing.

Keep in mind: vendors usually offer a range: a big reasoning model (powerful, slow, expensive) and a small fast model (light, instant, cheap). The choice depends on the real difficulty of the task, not on habit.

Match the model to the task

The principle is simple: the more reasoning the task needs, the higher up the range you go. The more repetitive and mechanical it is, the more you go down toward fast and cheap.

  • Big reasoning model (like Opus, top-tier GPT) — a tricky refactor, an architecture decision, a gnarly bug nobody understands. Here, paying more and waiting a few extra seconds pays off.
  • Fast, cheap model (like Haiku, lightweight models) — boilerplate, string translations, repetitive generation, rephrasing. No need to bring out the heavy artillery.

Concretely: you do not put an architect's brain to work laying tiles, and you do not hand the house blueprints to a tile layer. Each model has its zone of efficiency.

The trick that changes everything: if a model is stuck or gives mediocre output, paste the exact same prompt into another model. Models have different strengths; what jams one often unlocks in the other. It is free, instant, and saves you hours of pointless struggle.

The landscape of tools

The model is the brain. The tool is how that brain accesses your code. There are three big families:

  • Chat assistants (the chat in the browser) — you copy-paste code, you discuss, you grab the answer. Ideal for thinking, learning, prototyping an isolated idea. The AI never directly touches your files.
  • IDE assistants (like Cursor, Copilot) — the AI lives in your editor, completes your code, suggests edits in the context of the open file. Perfect for coding on the fly without switching windows.
  • Autonomous agents (like Claude Code) — the AI reads your project, runs commands, edits several files and tests its own work. Powerful for long, multi-file tasks, but this is where Git discipline (previous lesson) becomes essential.

Warning: the more autonomous the tool, the more damage it can do unsupervised. An agent editing 15 files on its own needs guardrails (frequent commits, diff review) that a simple chat does not.

Cost, speed, quality: pick two

As often in engineering, you trade off three axes: cost, speed and quality. The big reasoning model maximizes quality at the expense of speed and cost. The small model maximizes speed and cost at the expense of reasoning depth.

Here is a simple decision heuristic to keep in mind:

Does the task need real reasoning?
├─ YES (architecture, gnarly bug, tricky refactor)
│   └─ Big reasoning model
└─ NO (boilerplate, repetitive, rephrasing)
    └─ Small fast cheap model

Does the chosen model get stuck or return mediocre output?
└─ Paste the SAME prompt into another model

Must the AI edit several files on its own?
├─ YES → Autonomous agent + Git discipline
└─ NO → Chat or IDE assistant

Golden rule: do not be loyal to any model or any tool. Be loyal to the result. A good professional switches tools without hesitation as soon as another does the job at hand better.

Avec l'IA

Demandez à l'IA de vous aider à choisir le bon couple modèle + outil pour une tâche concrète, selon le compromis coût/vitesse/qualité :

Voici la tâche que je dois faire : [décris ta tâche, ex. refactorer un module de paiement de 600 lignes]. Aide-moi à décider : faut-il un grand modèle de raisonnement ou un petit modèle rapide ? Et quel type d'outil (chat, assistant dans l'éditeur, agent autonome) est le plus adapté ? Justifie ton choix avec le compromis coût / vitesse / qualité, et dis-moi quand il vaudrait mieux changer de modèle en cours de route.
Ré-explique sans regarder

Sans relire la réponse de l'IA : avec tes mots, sur quels critères décides-tu entre un grand modèle de raisonnement et un petit modèle rapide pour une tâche donnée ?

Une bonne explication part de la difficulté réelle de la tâche, pas de l'habitude : du raisonnement profond (architecture, bug tordu, refactor délicat) appelle le grand modèle, qu'on paie en coût et en vitesse ; une tâche répétitive et mécanique (boilerplate, traductions de chaînes, reformulations) appelle le petit modèle rapide et économique. Bonus : si le modèle choisi bloque ou rend du médiocre, on copie le même prompt dans un autre modèle avant d'insister.
Exercice : Accordez le modèle à la tâche

Pour chacune des tâches ci-dessous, indiquez si vous choisiriez un GRAND modèle de raisonnement ou un PETIT modèle rapide, et justifiez en une phrase avec le compromis coût/vitesse/qualité. Mentionnez aussi quel type d'outil (chat, éditeur, agent) vous utiliseriez.

Accepter ou rejeter la recommandation de l'IA

Tu demandes à l'IA quel modèle et quel outil utiliser pour traduire 200 chaînes d'interface FR vers EN. Voici sa réponse. Ton rôle : l'accepter ou la rejeter, et dire pourquoi.

Recommandation : grand modele de raisonnement (le plus
puissant disponible), lance via un agent autonome qui
parcourt le projet, repere les chaines et les remplace
dans tous les fichiers tout seul. Qualite maximale garantie.
À rejeter. Traduire des chaînes est une tâche répétitive et mécanique : c'est exactement le terrain du petit modèle rapide et économique, pas du grand modèle de raisonnement (on paierait le coût et la lenteur sans aucun gain de qualité réel). Et lâcher un agent autonome qui remplace dans tous les fichiers seul, c'est sortir l'artillerie lourde là où un chat ou l'assistant de l'éditeur suffit, en multipliant le risque de dégâts non surveillés. Le réflexe pro : accorder le modèle ET l'outil à la difficulté réelle, ici les deux les plus légers.
Rappel libre

Sans remonter dans la leçon : entre coût, vitesse et qualité, combien de ces trois axes peux-tu maximiser à la fois, et que fais-tu en premier si un modèle bloque sur une tâche ?

On n'en maximise que deux à la fois : c'est un compromis. Le grand modèle vise la qualité au prix de la vitesse et du coût ; le petit modèle vise vitesse et coût au prix de la profondeur de raisonnement. Premier réflexe quand un modèle bloque ou rend du médiocre : copier exactement le même prompt dans un autre modèle, dont les forces diffèrent. C'est gratuit et immédiat.
Quel est le meilleur modèle IA pour coder ?
Un modèle bloque et rend une réponse médiocre. Que faire en premier ?
Quel type d'outil modifie plusieurs fichiers et teste son travail tout seul ?
Prochaine étape

Même le meilleur modèle invente parfois une fonction, une option ou une API qui n'existe pas. La prochaine leçon, détecter les hallucinations, vous donne les signaux d'alerte et les vérifications rapides pour ne plus jamais coller du code qui ne tournera pas.

Leçon 13 : Détecter les hallucinations →
Besoin d'un développeur pour votre projet ?

Réponse sous 24h · Sans engagement