## Le bon outil pour le bon besoin

C'est **la** décision d'architecture la plus structurante — et la plus souvent ratée.

### Les trois leviers
- **Prompt engineering** — change *comment on demande*. Gratuit, immédiat. À essayer **en
  premier**, toujours.
- **RAG** — apporte de la **connaissance** factuelle, à jour, citable. Pour « que dit **ce
  document** / **notre procédure** ? ».
- **Fine-tuning** — change le **comportement / le style / le format** des réponses. Pour
  « réponds **toujours** dans ce format métier, ce ton ». ⚠️ **N'ajoute pas de connaissance
  fiable** : c'est l'erreur classique.

### L'arbre de décision
1. Le bon prompt suffit-il ? → souvent **oui**, on s'arrête là.
2. Manque-t-il de la **connaissance** (documents, données à jour) ? → **RAG**.
3. Le **comportement/format** doit-il être systématiquement spécifique ? → **fine-tuning**
   (en dernier, car coûteux).

On peut **combiner** : un modèle fine-tuné pour le format + RAG pour la connaissance.

> **📌 Cas concret — l'erreur du « fine-tuner les documents »**
> Une équipe veut un assistant qui connaît ses 500 circulaires. Réflexe erroné : « on va
> fine-tuner le modèle dessus ». Résultat : le modèle **invente des références plausibles
> mais fausses** (il n'a pas mémorisé fidèlement). La bonne réponse était le **RAG**. Règle :
> pour la **connaissance**, c'est RAG ; le fine-tuning, c'est pour le **comportement**.

> **À retenir** — Ordre par défaut : **prompt → RAG → fine-tuning**. Le RAG pour la
> **connaissance**, le fine-tuning pour le **style/format**. Ne jamais utiliser le
> fine-tuning comme substitut de connaissance.