Je choisirais vos bibliothèques Python LLM selon votre vrai besoin : prototype, RAG, fine-tuning, agents ou production. Le piège, c’est d’empiler des outils. Ici je pose une lecture simple pour construire une app LLM utile, maintenable, et pas juste une démo jolie.
Quel rôle joue chaque bibliothèque ?
Chaque bibliothèque Python LLM doit couvrir une brique précise, pas tout faire à la fois. Construire une application LLM, ce n’est pas juste appeler un modèle dans une interface avec trois boutons. Il faut charger un modèle, préparer les prompts, connecter des données, orchestrer des étapes, optimiser l’inférence, parfois fine-tuner, parfois organiser plusieurs agents qui se passent le relais.
J’ai souvent vu des équipes commencer par LangChain ou par un agent avant même d’avoir clarifié les données disponibles. Ça donne des workflows fragiles, difficiles à débugger, avec des réponses jolies mais pas fiables. Le sujet n’est pas “quelle lib est la plus connue ?”. Le sujet, c’est “quelle brique je dois résoudre maintenant ?”.
| Bibliothèque | Usage principal | Moment où je l’utilise |
| Transformers | Charger, tokenizer, générer et fine-tuner des modèles open source. | Quand je veux travailler directement avec un modèle Hugging Face. |
| LangChain | Orchestrer prompts, outils, APIs, récupérateurs et appels modèles. | Quand l’application doit enchaîner plusieurs actions autour du LLM. |
| LlamaIndex | Connecter documents, PDF, bases et données métier à un LLM, surtout en RAG. | Quand la réponse doit venir de vos données internes. Le RAG, c’est le fait de rechercher les bons documents avant de générer une réponse. |
| vLLM | Servir des modèles open source avec une meilleure gestion GPU, débit et latence. | Quand je passe d’un prototype à une vraie API qui doit tenir la charge. |
| Unsloth | Fine-tuner efficacement avec LoRA et QLoRA avec moins de VRAM. | Quand je dois adapter un modèle sans exploser les coûts GPU. La VRAM, c’est la mémoire de la carte graphique. |
| CrewAI | Organiser des agents spécialisés dans des workflows structurés. | Quand plusieurs rôles doivent collaborer, par exemple recherche, analyse, synthèse. |
| Sentence Transformers | Créer des embeddings pour la recherche sémantique. Un embedding, c’est une représentation numérique du sens d’un texte. | Quand je dois retrouver les contenus les plus proches d’une question. |
| Haystack | Construire des pipelines RAG et recherche plus cadrés. | Quand le besoin ressemble plus à un moteur de recherche intelligent qu’à un simple chatbot. |
| LiteLLM | Unifier les appels à plusieurs fournisseurs de modèles. | Quand je veux switcher entre OpenAI, Anthropic, Mistral ou un modèle local sans tout réécrire. |
| Instructor | Obtenir des sorties structurées validées avec Pydantic. | Quand je veux du JSON propre, contrôlé, exploitable par une application métier. |
Comment l’AIoT transforme les données en valeur ?
Le bon choix vient rarement d’une bibliothèque magique. Il vient de l’assemblage juste entre vos données, le modèle, l’orchestration et les contraintes de production. C’est moins sexy qu’un agent autonome, mais c’est beaucoup plus solide.
Entre nous, on le sait bien, faire appel à un consultant en automatisation intelligente et en agent IA, c’est souvent le raccourci le plus malin. On en parle ?
Comment construire un RAG propre ?
Pour un RAG propre, je sépare clairement l’indexation des données, la recherche, le prompt et la réponse finale. RAG, c’est Retrieval Augmented Generation, autrement dit une façon de faire répondre un LLM avec vos propres documents au lieu de compter uniquement sur sa mémoire interne.
LlamaIndex est souvent très bon pour connecter une application LLM à des documents, des PDF, des bases de données ou des sources métier. Je l’aime bien quand le vrai sujet, c’est de préparer les données avant de les envoyer au modèle. Il aide à charger, découper, structurer et retrouver les bons morceaux.
Comment utiliser Claude Code avec un modèle local ?
LangChain peut prendre le relais quand il faut orchestrer plusieurs étapes. Appeler une API, brancher un outil interne, gérer une logique de conversation, router une demande vers plusieurs composants… Là, il devient pratique.
Les embeddings sont le cœur de la recherche sémantique. Un embedding, c’est juste une version numérique d’un texte, sous forme de vecteur. Sentence Transformers est très utile pour ça, parce qu’il transforme vos passages en vecteurs comparables. Si deux textes parlent du même sujet, leurs vecteurs seront proches, même s’ils n’utilisent pas exactement les mêmes mots.
Haystack est aussi une option solide, surtout quand la recherche documentaire et la structuration du pipeline deviennent centrales. Je le vois bien sur des projets où le moteur de recherche compte autant que le modèle.
Gemini Omni peut-il créer des vidéos par IA ?
Le point que je répète souvent en mission client, c’est qu’un RAG ne corrige pas des données sales. Si les documents sont mal découpés, trop vieux, contradictoires ou sans métadonnées, le LLM répondra avec assurance, mais pas forcément avec justesse. Dans la vraie vie, le gros du travail est souvent dans la préparation des contenus, pas dans le prompt.
# Exemple simplifié, sans clé API réelle
documents = [
"Le contrat Premium inclut un support prioritaire.",
"Le contrat Standard inclut un support par email.",
"Les remboursements sont possibles sous 14 jours."
]
query = "Quel support est inclus dans l'offre Premium ?"
# Créer des embeddings avec un modèle local type Sentence Transformers
doc_vectors = embed(documents)
query_vector = embed([query])[0]
# Retrouver les passages les plus proches
top_passages = search_nearest(query_vector, doc_vectors, documents, top_k=2)
# Construire un prompt avec le contexte trouvé
prompt = f"""
Réponds uniquement avec le contexte ci-dessous.
Contexte:
{top_passages}
Question:
{query}
"""
# Générer la réponse avec le LLM
answer = generate(prompt)
print(answer)| Bibliothèque | Connexion aux données | Orchestration | Recherche sémantique |
| LlamaIndex | Très forte | Moyenne | Bonne |
| LangChain | Bonne | Très forte | Bonne |
| Sentence Transformers | Faible | Faible | Très forte |
| Haystack | Bonne | Forte | Très forte |
Quand fine-tuner un modèle ?
Je fine-tune seulement quand le prompt, le RAG ou les règles métier ne suffisent plus. C’est vraiment ma règle. Avant ça, je préfère améliorer les instructions, nettoyer les données, ajouter des garde-fous, ou brancher un bon RAG, c’est-à-dire un système qui va chercher de l’information dans vos documents avant de répondre.
Transformers reste la base solide quand on veut travailler sérieusement avec des modèles open source. Je l’utilise pour charger un modèle, tokenizer le texte, générer des réponses, puis entraîner ou adapter le modèle si besoin. Le tokenizer, c’est simplement la couche qui transforme le texte en morceaux compréhensibles par le modèle. L’intérêt de Transformers, c’est son API cohérente. On peut commencer par tester vite, puis aller vers des usages plus avancés sans tout changer.
Quels articles lire pour comprendre les LLM ?
Unsloth devient intéressant quand le fine-tuning doit rester raisonnable côté ressources. Il simplifie pas mal le travail avec LoRA et QLoRA. LoRA permet d’adapter seulement une petite partie du modèle au lieu de réentraîner tous ses paramètres. QLoRA va plus loin en réduisant aussi la précision des poids pour consommer moins de VRAM, la mémoire de la carte graphique. Ça coûte moins cher, ça tourne sur des machines plus accessibles, mais ce n’est pas magique. Il faut de bons exemples, un dataset propre, et une vraie évaluation. Sinon on entraîne juste un modèle à répéter vos erreurs.
Je distingue trois besoins très différents :
- Améliorer le style de réponse, par exemple rendre le ton plus court, plus commercial, plus juridique.
- Apprendre un format de sortie, comme produire toujours un JSON propre ou une fiche structurée.
- Spécialiser un comportement, par exemple répondre comme un support niveau 2 sur un périmètre très précis.
Pour ajouter de la connaissance métier fraîche, je préfère souvent le RAG. Pour faire respecter un format ou un ton très spécifique à grande échelle, le fine-tuning peut devenir rentable.
| Critère | Prompt engineering | RAG | Fine-tuning |
| Coût | Faible | Moyen | Plus élevé |
| Vitesse de mise en place | Très rapide | Rapide si les données sont propres | Plus lent |
| Contrôle du comportement | Limité | Bon sur les réponses documentées | Très bon si le dataset est solide |
| Mise à jour des connaissances | Manuelle | Très bonne | Plus lourde |
| Risque opérationnel | Faible | Moyen | Plus élevé |
Observation honnête : beaucoup de projets veulent fine-tuner trop tôt parce que ça sonne sérieux. Dans les faits, un bon pipeline RAG avec des données propres ferait déjà 80 pour cent du travail. Je l’ai vu chez plusieurs clients, le modèle n’était pas le problème. Le bazar était dans les documents.
Comment passer en production ?
Pour passer en production, je regarde d’abord la latence, le coût GPU, la stabilité des réponses et la capacité à monitorer. C’est là qu’on voit la différence entre une démo sympa dans un notebook et une vraie application utilisée par des clients, des équipes support ou des commerciaux.
VLLM est souvent le bon réflexe quand on veut servir efficacement des modèles open source. Il est pensé pour mieux utiliser la mémoire GPU, augmenter le débit, c’est-à-dire le nombre de requêtes traitées, et garder une latence plus maîtrisée. Quand on quitte le test local pour gérer plusieurs utilisateurs en même temps, ça change tout. J’ai déjà vu des projets où le modèle était bon, mais l’infra autour rendait l’expérience inutilisable. Trop lent, trop cher, trop instable.
| Besoin | Brique utile |
| Servir un modèle open source avec performance | VLLM |
| Changer de fournisseur sans tout réécrire | LiteLLM |
| Obtenir des sorties propres et validées | Instructor ou Pydantic |
LiteLLM devient intéressant quand on veut standardiser les appels à plusieurs modèles ou fournisseurs derrière une interface commune. Ça évite de coller toute l’architecture à un seul provider. Dans un contexte business, c’est précieux. Vous pouvez tester un modèle moins cher, garder un fallback si un service tombe, ou router certains cas vers un modèle plus puissant sans casser toute l’application.
Instructor, lui, règle un problème très concret : les applications réelles n’ont pas seulement besoin d’une jolie réponse en texte libre. Elles ont besoin de JSON valide, de champs attendus, de validations, d’erreurs qu’on peut gérer proprement. Avec des schémas Pydantic, on décrit la forme attendue de la réponse, puis on force le modèle à rentrer dans ce cadre.
from pydantic import BaseModel, Field
class LLMResponse(BaseModel):
resume: str = Field(description="Résumé court de la situation")
score_confiance: float = Field(ge=0, le=1)
actions: list[str]
def call_llm_structured(prompt: str) -> dict:
# Appel LLM abstrait, via Instructor, LiteLLM, ou votre couche interne
return {
"resume": "Le client veut automatiser le tri des demandes entrantes.",
"score_confiance": 0.87,
"actions": [
"Classifier les demandes",
"Créer une règle de routage",
"Mesurer le taux d'erreur"
]
}
raw_response = call_llm_structured("Analyse cette demande client")
validated_response = LLMResponse.model_validate(raw_response)
print(validated_response.resume)
print(validated_response.score_confiance)
print(validated_response.actions)Avant de mettre ça devant des utilisateurs, je garde cette checklist sous les yeux :
- Mesurer la latence.
- Tracer les appels.
- Gérer les erreurs.
- Valider les sorties.
- Prévoir un fallback modèle.
- Surveiller le coût.
- Tester les prompts.
- Versionner les changements.
Les agents sont-ils utiles ?
Les agents sont utiles quand le workflow demande plusieurs rôles, plusieurs outils ou plusieurs décisions. Mais ils deviennent vite dangereux si on les lance sans cadre. J’ai vu des équipes ajouter trois agents là où un simple script suffisait, et le résultat était plus lent, plus cher, plus difficile à débugger.
CrewAI sert justement à construire des applications multi-agents. Chaque agent a un rôle spécialisé, peut utiliser des outils, déléguer une tâche, puis collaborer avec les autres dans un workflow structuré. L’idée n’est pas de “faire discuter des IA entre elles” pour le plaisir. L’idée, c’est de découper un travail métier en responsabilités claires.
Un exemple simple. Une demande client arrive par email. Un premier agent analyse l’intention et le niveau d’urgence. Un deuxième cherche dans la documentation interne. Un troisième prépare une réponse. Un dernier contrôle le format, le ton, les risques juridiques ou les infos sensibles. Là, ça commence à avoir du sens, parce que les étapes sont claires, répétables, et proches d’un vrai process métier.
Les agents ne remplacent pas l’architecture. Ils s’appuient dessus. LlamaIndex peut fournir le contexte documentaire, donc le contenu fiable à consulter. LangChain peut brancher des outils, des APIs, un CRM, un ticketing, une base interne. vLLM peut servir un modèle open source en production avec de bonnes performances. Instructor peut valider les sorties structurées, par exemple forcer un JSON propre avec un statut, une catégorie et un score de confiance.
Le piège, c’est l’emballement. Plus il y a d’agents, plus il y a de coûts, de latence, de logs à lire, et de chemins imprévisibles. Moi, je préfère commencer avec un workflow simple, observer où les humains perdent vraiment du temps, puis ajouter un agent seulement là où il enlève une vraie friction.
| Cas d’usage | Bibliothèque prioritaire | Niveau de complexité |
| Chatbot simple | LangChain ou SDK fournisseur | Faible |
| RAG documentaire | LlamaIndex | Moyen |
| Extraction structurée | Instructor | Faible à moyen |
| Fine-tuning | Transformers, Axolotl ou Unsloth | Élevé |
| Serving open source | vLLM | Moyen à élevé |
| Workflow multi-agent | CrewAI | Élevé |
Alors quelle stack je choisirais pour votre projet ?
Je ne choisirais pas une stack LLM en partant d’une liste à la mode. Je regarderais d’abord votre usage. Pour manipuler des modèles open source, Transformers reste une base. Pour connecter les données, LlamaIndex, Sentence Transformers ou Haystack font le job. Pour orchestrer, LangChain aide beaucoup. Pour produire vite et propre, vLLM, LiteLLM et Instructor deviennent précieux. Pour adapter un modèle, Unsloth peut réduire les coûts. Pour des workflows complexes, CrewAI peut avoir du sens. Le vrai bénéfice pour vous, c’est une architecture plus simple à maintenir, moins chère à faire tourner, et plus fiable côté business.
FAQ
- Quelles sont les meilleures bibliothèques Python LLM pour commencer ?
Je commencerais avec Transformers pour comprendre les modèles, LlamaIndex pour connecter vos données, LangChain si vous avez besoin d’orchestration, et Sentence Transformers pour les embeddings. Ça couvre déjà beaucoup de cas réels sans empiler trop d’outils. - LangChain et LlamaIndex font-ils la même chose ?
Pas vraiment. LlamaIndex est très orienté connexion aux données et RAG. LangChain est plus orienté orchestration entre prompts, outils, APIs, récupérateurs et modèles. Dans certains projets, j’utilise les deux, mais pas pour la même raison. - Quand utiliser vLLM dans une application LLM ?
J’utilise vLLM quand il faut servir un modèle open source avec de meilleures performances, surtout côté GPU, débit et latence. C’est une brique de production, pas forcément le premier outil à installer quand on teste une idée dans un notebook. - Le fine-tuning est-il obligatoire pour une app LLM sérieuse ?
Non. Dans beaucoup de cas, un bon prompt et un RAG propre suffisent. Le fine-tuning devient utile quand il faut adapter un comportement, un format ou un style de réponse de manière répétable. Unsloth aide à le faire avec moins de ressources, notamment via LoRA et QLoRA. - Les agents IA avec CrewAI sont-ils adaptés à tous les projets ?
Non, et c’est même le piège. CrewAI devient intéressant quand plusieurs rôles doivent collaborer dans un workflow clair. Pour un chatbot simple ou une extraction basique, des agents ajoutent souvent trop de complexité, de coût et de latence.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en Tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’accompagne des équipes comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor sur des sujets data, IA et automatisation très concrets. Si vous voulez cadrer une stack LLM, un RAG, une automatisation IA ou un projet data propre, contactez-moi, je peux vous aider.
⭐ Data Analyst, Analytics Engineer et expert dans l’automatisation IA ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.