LangChain et LlamaIndex

Comment ça marche

LangChain et LlamaIndex sont des bibliothèques, c’est-à-dire du code prêt à l’emploi que les développeurs intègrent dans leurs programmes. LangChain fournit les composants pour construire des chaînes de traitement et des agents : appel de modèles, gestion des consignes, outils, mémoire, et un cadre pour orchestrer des agents complexes. LlamaIndex se concentre sur les documents : les charger, les découper, les indexer, les retrouver, et construire des RAG de qualité. Chacune propose aussi des services payants (observabilité, hébergement, traitement de documents).

Pour un dirigeant, l’important n’est pas de les utiliser mais de savoir ce qu’elles sont quand un prestataire les nomme. Elles accélèrent les projets complexes et structurent le code. Elles ajoutent une couche entre votre application et les modèles, qui évolue vite et qu’il faut maintenir. Les questions à poser : pourquoi cette bibliothèque plutôt qu’un appel direct, quelle version, qui met à jour, et à quel coût.

Un exemple concret

1. Le besoin : un assistant interne qui répond à partir de 5 000 documents : modèles d’actes, notes, jurisprudence sélectionnée.
2. Devis A : architecture avec LlamaIndex pour l’indexation et la recherche, LangChain pour l’orchestration et l’agent, base vectorielle, interface. Riche en fonctions, évolutif. Maintenance annuelle estimée à 20 % du coût initial, « en raison du rythme des bibliothèques ».
3. Devis B : appels directs à l’API du modèle, une base vectorielle, quelques centaines de lignes de code maison pour le découpage et la recherche. Moins de fonctions, code lisible par n’importe quel développeur. Maintenance estimée à 8 %.
4. Les questions posées : à A, ce que les bibliothèques apportent concrètement pour ce besoin ; à B, ce qui manquera si le besoin grandit. Les deux ont répondu honnêtement.
5. La décision : B, parce que le besoin était simple et que la lisibilité du code comptait pour un cabinet sans équipe technique. Avec une clause : si l’usage grandit, l’architecture sera revue.

Les deux devis étaient sérieux. Comprendre ce que les noms voulaient dire a permis de choisir sur le besoin, pas sur le vocabulaire.

Ce que ça change pour une équipe

• Le vocabulaire des prestataires se décode. On sait ce qu’on achète quand ces noms apparaissent dans un devis.
• La question de la maintenance se pose avant. Qui met à jour, à quel rythme, à quel coût : négocié dès le départ.
• Le choix simple ou complexe devient conscient. Appel direct pour un besoin simple, bibliothèque pour une application riche.
• Les projets complexes gagnent du temps. Pour un vrai système multi-agents ou un RAG sophistiqué, ces briques évitent des mois.

Les limites et les erreurs fréquentes

• Une bibliothèque pour un besoin simple. De la complexité et de la maintenance pour rien. Quelques lignes d’appel direct suffisent souvent.
• Ignorer la dette de mise à jour. Une application figée sur une vieille version devient un fardeau. La maintenance se prévoit au contrat.
• Confondre la bibliothèque et la qualité. Un RAG médiocre avec LlamaIndex reste médiocre. La qualité vient des documents, du découpage et des tests.
• Dépendre d’un seul sachant. Si le prestataire part, qui comprend le code ? Exiger une documentation et du code lisible.