Framework ou SDK natif : le choix du projet

Le constat dans le code

Dans le pyproject.toml du projet : langchain-core seulement — pas de langchain, pas de langchain-anthropic. Le LLM est appelé au SDK natif (module 4), l'orchestration est LangGraph pur (module 6), et langchain-core n'est là que comme socle de LangGraph (les types de base, RunnableConfig).

Ce que le framework coûte (et qui a motivé le choix)

1. Le contrôle chirurgical du provider : les breakpoints de prompt caching, output_config.effort, la gestion fine de stop_reason=max_tokens, les événements de stream input_json_delta… sont des features Anthropic pointues. À travers l'abstraction multi-provider, elles arrivent tard, à moitié, ou pas du tout — et la latence/facture s'en ressentent directement ;
2. La profondeur de pile : un bug dans prompt | llm | parser traverse des dizaines de frames de Runnables ; l'équivalent SDK a une stack de trois niveaux, et le prompt exact envoyé se logge trivialement ;
3. La vélocité de l'écosystème : les versions bougent vite ; moins de couches = moins de migrations subies ;
4. Le besoin réel : le projet n'a pas besoin de 50 intégrations — il a UN provider principal, deux annexes (Cohere, Mistral), et ses propres abstractions fines (LLMRuntime, ToolBus) taillées pour ses invariants (model_view/ui_events, idempotence).

Ce que le framework apporte (et quand le choisir)

Prototypage éclair, intégrations innombrables (vector stores, loaders, providers), standardisation d'équipe, et l'entrée naturelle vers LangGraph/LangSmith. L'arbre de décision honnête :

• POC, exploration multi-providers, équipe junior, besoin d'intégrations variées → LangChain complet ;
• produit mûr, un provider dominant, exigences fines de coût/latence/privacy → SDK natif + LangGraph pour l'orchestration (le choix du projet) ;
• dans tous les cas : les concepts (messages, tools, structured output) sont les mêmes — c'est l'épaisseur de la couche qui change.