Fine-tuning vs prompt engineering : choisir avec le ROI comme boussole

Le schéma qu'on observe chaque semaine

Une entreprise constate que GPT-4 classe systématiquement mal les tickets de support dans son domaine métier. La réaction immédiate de l'équipe technique : «il faut faire du fine-tuning». Six semaines plus tard, 40 000 exemples annotés, 3 000 € de compute, et les résultats sont moins bons qu'un prompt bien écrit.

Nous avons vu cette séquence au moins dix fois au cours des douze derniers mois. Le fine-tuning n'est pas en cause — c'est le recours prématuré qui l'est.

---

Ce qui distingue vraiment les deux approches

Le prompt engineering consiste à instruire un modèle de base à l'exécution, en incluant dans le contexte des exemples, des instructions, des contraintes de format et des chaînes de raisonnement. Les poids du modèle ne sont pas modifiés.

Le fine-tuning consiste à mettre à jour les poids du modèle sur un jeu de données spécifique. Le modèle «apprend» des patterns qu'il n'a plus besoin de recevoir via le prompt.

La distinction opérationnelle :

| Dimension | Prompt Engineering | Fine-tuning | |---|---|---| | Coût initial | Faible (heures/jours) | Élevé (dataset, annotation, compute) | | Coût courant | Élevé (longs tokens en entrée) | Faible (prompts courts) | | Latence | Dépend du nombre de tokens | Généralement inférieure | | Mise à jour | Immédiate | Nécessite un ré-entraînement | | Données requises | Zéro | Minimum 500–1 000 exemples |

---

Quand le prompt engineering suffit (ce qui est souvent le cas)

Si le comportement cible peut être décrit en langage naturel avec des exemples dans le contexte, le fine-tuning est du sur-ingénierie.

Exemple concret : extraction structurée de données depuis des factures PDF. Un prompt few-shot avec 5 à 10 exemples atteint facilement 90 à 95 % de précision sur des factures standard. Le fine-tuning pourrait amener ce chiffre à 97 %, mais le delta ne justifie pas les coûts si le volume est inférieur à 50 000 documents par mois.

# Exemple de prompt few-shot
EXTRAIS les champs suivants de la facture en format JSON :
- numero_facture
- date_emission
- montant_total
- tva_fournisseur

Exemple 1 :
Entrée : "Facture n° 2024/001 du 15/01/2024 – Total 1 220,00 € – TVA 12345678901"
Sortie : {"numero_facture": "2024/001", "date_emission": "2024-01-15", "montant_total": 1220.00, "tva_fournisseur": "12345678901"}

[ajouter 4 à 9 exemples similaires avec des variations de format]

Extrait maintenant depuis la facture suivante :
{{input}}

Cette approche demande une après-midi, pas un mois.

---

Quand le fine-tuning change vraiment les chiffres

Il existe trois scénarios où le fine-tuning a du sens économiquement :

1. Volume de tokens élevé et stable

Si vous utilisez GPT-4o avec des prompts de 2 000 tokens sur 500 000 appels par mois, vous dépensez environ 5 000 €/mois rien qu'en tokens d'entrée. Un modèle fine-tuné avec des prompts de 200 tokens réduit ce coût de 70 à 80 %. Le seuil de rentabilité sur le coût d'entraînement est atteint en 2 à 3 mois.

Formule rapide :

seuil_rentabilite_mois = cout_finetuning / economies_tokens_mensuelles

# Exemple :
# cout_finetuning = 8 000 €
# economies_tokens_mensuelles = 3 500 €
# seuil = 8 000 / 3 500 ≈ 2,3 mois

2. Style ou format non descriptible via prompt

Un modèle qui doit générer de la documentation technique dans le style interne de l'entreprise — avec des conventions de nommage spécifiques, une structure de paragraphe propriétaire, un ton juridique précis — ne peut pas être instruit uniquement par des instructions textuelles. Des exemples dans le jeu de données d'entraînement sont nécessaires.

3. Latence critique avec contexte long

Si votre application exige des réponses en moins de 500 ms et que le contexte nécessaire dépasse 3 000 tokens, le fine-tuning permet d'éliminer une grande partie de ce contexte. Avec des modèles plus petits fine-tunés (Mistral 7B, Llama 3 8B), la latence p95 peut passer de 2 à 3 secondes à 300-400 ms.

---

Le chemin de décision opérationnel

Avant de lancer un projet de fine-tuning, répondez à ces questions :

Disposez-vous d'au moins 500 exemples annotés de haute qualité ? Si non, arrêtez-vous. Le fine-tuning avec moins de données dégrade presque toujours le modèle de base.
Le comportement cible est-il descriptible par des instructions ? Si oui, testez d'abord un prompt structuré avec chain-of-thought.
Le volume mensuel dépasse-t-il 100 000 appels ? En dessous de ce seuil, les économies de tokens compensent rarement les coûts fixes.
Le domaine évolue-t-il fréquemment ? Si les règles métier changent toutes les semaines, un modèle fine-tuné devient obsolète avant d'être rentable.

if exemples_annotes < 500:
    return "prompt engineering"
elif volume_mensuel < 100_000 and style_descriptible:
    return "prompt engineering"
elif latence_critique or volume_mensuel > 500_000:
    return "évaluer le fine-tuning"
else:
    return "benchmarker les deux, puis décider"

---

Une approche hybride sous-estimée : RAG + prompt engineering

De nombreux cas qui semblent nécessiter du fine-tuning se résolvent avec le Retrieval-Augmented Generation : le contexte pertinent est récupéré depuis une base de connaissances vectorielle et injecté dynamiquement dans le prompt. Coûts de mise en place comparables au fine-tuning, mise à jour immédiate, aucun ré-entraînement.

Quand le problème est «le modèle ne connaît pas notre domaine», la réponse est presque toujours le RAG. Quand le problème est «le modèle ne se comporte pas comme on le souhaite», la réponse pourrait être le fine-tuning.

---

Points opérationnels à retenir

Commencez toujours par le prompt engineering. C'est réversible, rapide et mesurable.
N'envisagez le fine-tuning qu'après avoir quantifié le ROI avec des chiffres réels : coût du dataset, coût d'entraînement, économies de tokens attendues, horizon temporel.
Calculez le seuil de rentabilité avant de démarrer le projet, pas après.
Le RAG est souvent la troisième voie ignorée : évaluez-le avant d'investir dans l'entraînement.
Les modèles open-source (Llama 3, Mistral, Phi-3) réduisent considérablement le coût du fine-tuning : un modèle à 8B paramètres sur GPU A100 coûte environ 2 à 4 € l'heure sur cloud.

---

Si vous évaluez quelle approche adopter pour un projet IA interne ou pour un client, l'équipe d'Evviva Group peut réaliser une analyse de faisabilité rapide avant que le budget soit engagé.