Peut-on commencer par l'API, puis passer à un framework ?

Oui, c'est la démarche que suggère Anthropic. Un code qui appelle directement l'API reste lisible et se met plus facilement en bibliothèque plus tard, à condition de garder les appels au modèle dans une seule couche de votre code.

Un framework rend-il le code moins sûr ?

Pas nécessairement. Le risque tient surtout à la visibilité : Anthropic signale que des couches d'abstraction peuvent masquer les prompts et les réponses sous-jacents. Il faut donc pouvoir vérifier ce qui part vers le modèle, quelle que soit la solution retenue.

Framework IA ou appel direct à l'API : la méthode

Pour un projet qui appelle un modèle de langage, la première décision n'est pas la bibliothèque, mais la question : faut-il une bibliothèque ? Anthropic conseille de commencer par appeler directement les interfaces de programmation (API) des modèles, car, selon sa formule en anglais traduite ici, de nombreux motifs (« patterns ») tiennent en quelques lignes de code. Les frameworks deviennent utiles quand le projet dépasse ce seuil. Cette page donne une méthode pour trancher, avec des critères et un tableau. Les critères sont ceux de l'auteur de ce site ; les faits qui les soutiennent viennent des documentations lues le 15/11/2026.

Ce que fait un appel direct

Un appel direct envoie des messages et lit la réponse. Pour un agent, il faut aussi écrire la boucle : envoyer la demande, lire les blocs tool_use que le modèle renvoie, exécuter l'outil, puis renvoyer le résultat dans un bloc tool_result. La documentation d'outils d'Anthropic décrit exactement ce cycle. Elle précise aussi que le SDK peut exécuter les outils et renvoyer les résultats automatiquement, à l'aide d'un « tool runner », sans que le développeur écrive la boucle.

Pour une sortie structurée, l'appel direct suffit : le paramètre output_config.format accepte un schéma JSON, et le SDK Python propose client.messages.parse avec output_format. Le streaming est aussi couvert par le SDK. Ces fonctions sont donc disponibles sans framework.

Ce qu'apporte un framework

Les documentations lues décrivent des fonctions de plus haut niveau :

LangChain propose create_agent, un « harnais » qui assemble prompt, outils et intergiciels, et une interface commune pour plusieurs fournisseurs.
LangGraph ajoute un graphe d'étapes à état, la sauvegarde de l'état pour reprendre après une panne, et la suspension pour une validation humaine.
Haystack décrit des pipelines dont les composants (recherche, indexation, appel d'outils, mémoire, évaluation) sont reliés par le développeur.
LlamaIndex part des données : connecteurs, index, moteurs de requête, agents et workflows.

Ces fonctions valent le coût quand elles correspondent à un besoin réel. Elles coûtent en complexité, en dépendances et en mises à jour.

Les critères de décision

Une grille simple, à remplir pour chaque projet :

Taille du flux. Un appel, une réponse, pas de mémoire : l'appel direct suffit. Plusieurs étapes, des outils, des branches : le framework devient utile.
Besoin de reprise. Si une exécution doit pouvoir reprendre après une panne ou une pause de plusieurs heures, LangGraph ou un équivalent doit être regardé, ou une persistance à écrire soi-même.
Validation humaine. Si une personne doit valider certaines étapes, la suspension et la reprise doivent exister. Les frameworks les fournissent ; l'appel direct oblige à les coder.
Changement de fournisseur. Si le projet doit pouvoir changer de modèle sans réécrire, une couche commune est utile. Elle peut être écrite soi-même : voir éviter le verrouillage fournisseur.
Visibilité. Si l'équipe doit savoir exactement ce qui part vers le modèle, un appel direct reste le choix le plus simple à déboguer.
Dépendances et mises à jour. Chaque bibliothèque ajoute des paquets et un rythme de versions à suivre. Les paquets lus le 15/11/2026 sont publiés à quelques jours d'intervalle : LangChain en version 1.5.0 le 11/11/2026, LangGraph en 1.2.22 le 14/11/2026, LlamaIndex en 0.14.26 le 13/11/2026, Haystack en 3.5.0 le 10/11/2026.

Tableau de décision

Critère	Appel direct à l'API	Framework
Démarrage	Rapide pour un appel ou un petit outil	Plus de temps au départ, moins de code ensuite
Visibilité des messages	Totale	Dépend de la qualité des traces fournies
Reprise après panne	À écrire soi-même	Fournie (LangGraph)
Validation humaine	À écrire soi-même	Fournie par certains frameworks
Changement de fournisseur	Couche à écrire	Interface commune, avec des limites selon les fournisseurs
Dépendances	Peu	Plusieurs paquets, à maintenir
Mises à jour	Maîtrisées par l'équipe	Suivre les versions et leurs changements

Comment trancher en pratique

Commencer par un appel direct dans une petite fonction, puis noter ce qui manque : une reprise, une boucle d'outils, une recherche dans des documents. Si la liste des manques est courte et stable, un framework n'apporte pas grand-chose. Si elle s'allonge, comparer deux ou trois bibliothèques sur ces points précis, avec la comparaison des frameworks.

Pour les agents, le comparatif des frameworks d'agents reprend la même question. Et pour une recherche documentaire, le guide RAG détaille les briques à assembler selon le cas.

Dans tous les cas, la bibliothèque doit être choisie après une lecture de sa licence et de son activité : voir juger la maintenance d'un framework.