En 18 mois, on a déployé l’IA dans 12 produits clients. La majorité voulait au départ “un GPT-4 fine-tuné sur notre data”. À la sortie, on a fine-tuné 2 fois. Le reste est passé en RAG, ou en agents. Voilà la grille qu’on applique pour ne pas se planter d’archi IA.
RAG : pour des données qui bougent
Retrieval-Augmented Generation = on indexe vos données dans une base vectorielle (Pinecone, Qdrant, pgvector), à chaque question utilisateur on cherche les chunks pertinents, et on les injecte dans le prompt du LLM.
Avantages : data toujours à jour (réindexation en temps réel), zéro entraînement, citations sources possibles, coût marginal faible. Idéal pour : helpdesk produit, search interne entreprise, copilote sur documentation, Q&A sur catalogue.
Limite : le LLM “voit” vos données mais ne devient pas votre data. Le style des réponses reste celui du modèle de base.
Fine-tuning : pour un style ou un format propriétaire
Fine-tuning = on prend un modèle de base, on l’entraîne sur vos exemples pour qu’il adopte votre ton, votre structure de sortie, votre jargon.
Avantages : sortie structurée fiable, ton de marque cohérent, réduction du prompt (donc latence + coût). Idéal pour : génération de copy à votre style, classification ultra-spécifique, sortie JSON avec un schéma propriétaire complexe.
Limites majeures : il faut 500 à 5 000 exemples annotés, ça coûte du temps humain (le vrai coût caché), et les données de base sont figées au moment du fine-tuning. Et l’évaluation est dure : comment mesure-t-on “c’est mieux écrit qu’avant” ?
Agents : pour orchestrer plusieurs actions
Un agent = un LLM qui peut décider d’appeler des outils (function calling), enchaîner plusieurs étapes, et auto-corriger ses sorties. Au lieu de “répondre”, il “fait”.
Exemples concrets de nos projets : un agent de research qui fait 6 recherches Tavily, lit 20 pages web, rédige une note de synthèse avec sources. Un agent de support qui lit un ticket, requête la base produit, propose une réponse, escalade si besoin.
Limites : latence (3-12 secondes par cycle), coût (10-50× un appel LLM simple), et la fragilité — un agent qui se perd en boucle coûte cher et frustre l’utilisateur.
Comparatif d’usage
| Use case | Archi recommandée | Latence | Coût marginal |
|---|---|---|---|
| Helpdesk sur ta doc | RAG | 1-2 s | Faible |
| Génération copy au style brand | Fine-tuning + prompts | 0,5-1 s | Très faible |
| Classifieur de tickets | Fine-tuning | <300 ms | Très faible |
| Assistant qui exécute des actions | Agent | 3-10 s | Élevé |
| Q&A sur catalogue produit | RAG | 1-2 s | Faible |
| Génération de rapports structurés | Fine-tuning + RAG | 2-4 s | Modéré |
| Workflow multi-étapes (analyse + email) | Agent | 5-15 s | Élevé |
Notre stack IA 2026 par défaut
- LLM : Claude Opus 4.7 / Sonnet 4.6 (Anthropic), GPT-5 (fallback), Llama 3.3 70B (souveraineté)
- Embeddings : Voyage AI ou OpenAI text-embedding-3-large
- Vector DB : pgvector (si Postgres déjà en place), Qdrant Cloud sinon
- Orchestration : Vercel AI SDK + Anthropic SDK pour les agents
- Observability : Langfuse pour tracer les agents en prod
- Eval : Promptfoo pour les tests offline, A/B tests en prod via feature flags
Quand combiner les trois
Le pattern le plus puissant qu’on a déployé : agent qui orchestre des outils, dont un de ces outils est un RAG, et le LLM de base est fine-tuné pour adopter le ton de la marque. C’est complexe à débugger, cher à scaler, mais ça produit les expériences IA les plus différenciantes du marché.
On voulait fine-tuner Claude. Ardaris nous a fait shipper un RAG en 5 semaines. 6 mois plus tard on tourne toujours en RAG, et c’est très bien comme ça.
La règle : commence simple, mesure, complexifie quand le problème le justifie. La majorité des projets IA qui échouent ne le font pas par manque d’archi sophistiquée — ils le font par manque de données propres et d’éval rigoureuse.
