Choisir un framework d'agent.

À la fin de cette leçon

Vous saurez choisir un framework d'agent IA pour votre stack (TypeScript / Python / no-code) et reconnaître les compromis structurants.

Chaque acteur a son framework

OpenAI Agents SDK (Python et TypeScript, adossé à la Responses API). LangGraph (issu de LangChain, le plus mature en 2026 sur les graphes d'états). Mastra (TypeScript d'abord). Vercel AI SDK, complété par Workflow pour l'exécution durable. À côté d'eux, le Claude Agent SDK et Google ADK complètent le peloton de tête.

Attention au vocabulaire d'OpenAI, qui coûte cher si on s'y trompe : AgentKit n'est pas le framework, c'est la suite produit posée au-dessus, avec le canevas visuel Agent Builder, l'interface ChatKit, le registre de connecteurs et les Evals. Le framework de code, c'est l'Agents SDK. Et la suite se réduit : depuis l'avis du 3 juin 2026, Agent Builder et la plateforme Evals ferment tous deux le 30 novembre 2026, les évaluations existantes passant en lecture seule dès le 31 octobre. Seuls ChatKit et le registre de connecteurs restent.

Le défi se déplace : du « comment construire un agent » au « quel framework choisir ». Conséquence pratique : choisir un framework n'est pas neutre. C'est un choix de stack qui durcit votre architecture pour 18-24 mois, ce qui interdit de bâtir sur une brique annoncée en fin de vie.

Framework d'agent, ce que c'est

Un framework d'agent = abstraction sur le LLM + outils + boucle d'exécution + état.

Économise le code boilerplate (boucle agent, parsing tool calls, gestion retries, persistance d'état), impose des choix d'architecture (graphe d'états vs flow linéaire, TypeScript vs Python, intégrations natives vs DIY).

Trois implications structurantes : le langage (TypeScript ou Python décide votre écosystème pour 2 ans), la maturité (un framework jeune = bugs d'arête tranchante, breaking changes fréquents), l'intégration stack (le Vercel AI SDK pour une app Vercel, l'Agents SDK pour une app OpenAI Responses, LangGraph pour une stack agnostique).

Quatre frameworks dominants

Choisir selon le cas

Quatre critères de choix

Le critère décisif change selon votre contexte. Aucun framework n'est dominant sur les quatre axes simultanément.

Les pièges courants

Un cas d'agent tranché avant d'écrire une ligne

Le projet. Un agent qui traite les demandes de remboursement : lire la demande, vérifier l'éligibilité dans les règles internes, calculer le montant, préparer le virement, ou escalader vers un humain si le dossier sort des clous.

Critère 1, le langage. L'équipe est TypeScript, sans compétence Python en interne. Cela écarte d'emblée tout ce qui est plus mature côté Python.

Critère 2, la maturité. Un agent qui déclenche des virements n'est pas un terrain d'expérimentation. La maturité pèse ici plus lourd que l'élégance de l'interface de programmation.

Critère 3, l'intégration. L'application tourne déjà sur une stack Next.js. Rester dans le même écosystème évite une couche d'exploitation supplémentaire.

Critère 4, la complexité du graphe. C'est le critère décisif et le plus souvent sous-estimé. Le flux paraît linéaire jusqu'à ce qu'on liste les cas réels : pièce justificative manquante, montant au-dessus du seuil, client déjà remboursé deux fois cette année, devise étrangère. On dépasse les dix états et les branches conditionnelles se multiplient.

La décision. Un framework orienté graphe, malgré la préférence de langage, parce que le critère 4 domine les trois autres dès qu'il bascule.

À retenir

30 minutes pour choisir

Identifiez 1 cas d'agent IA que vous envisagez de construire dans les 3 mois. Pour ce cas, appliquez les 4 critères : langage de votre équipe, maturité requise, intégration stack existante, complexité du graphe (nombre d'états, transitions). Choisissez le framework cible. Si vous hésitez entre 2, codez un prototype 30 lignes sur chacun pour comparer la DX.