Créer un agent IA en entreprise : guide pratique pour DSI

Un agent IA, ça marche très bien en démo. Trois outils branchés, un GPT-5 ou un Claude 4.6 Sonnet derrière, une boucle de raisonnement bien huilée, et le keynote du COMEX se passe à merveille. Le problème commence trois mois plus tard, quand on essaie de basculer le même agent en production sur 200 utilisateurs internes : les coûts explosent, les boucles infinies apparaissent, les hallucinations propagées font remonter des incidents qu'on ne sait pas reproduire, et personne ne sait expliquer pourquoi tel ticket a été clôturé automatiquement.

L'écart entre l'agent qui impressionne en réunion et l'agent qui tient en production est aujourd'hui le principal piège des projets d'GenAI en grande entreprise. Il ne se résout pas en empilant des frameworks — il se résout en faisant des choix architecturaux explicites sur l'orchestration, l'observabilité, l'intégration au SI et la maîtrise des coûts. Ce guide reprend les arbitrages que nous voyons revenir systématiquement chez nos clients CAC40 et ETI 500+ qui industrialisent leurs premiers agents.

Un agent, ce n'est pas un chatbot avec plus d'étapes

La confusion la plus fréquente dans les comités de pilotage IA consiste à présenter un agent comme « un chatbot qui peut faire des actions ». Techniquement, c'est faux, et ça mène à de mauvaises décisions d'architecture. Un chatbot, même avec du RAG, suit un schéma déterministe : question → recherche → génération → réponse. Un agent introduit deux capacités supplémentaires qui changent la nature du système.

D'abord, la planification : l'agent décompose une tâche en sous-étapes qu'il n'a pas reçues à l'avance. Ensuite, l'itération outillée : il choisit dynamiquement quel outil appeler (API, base de données, fonction métier), observe le résultat, ajuste son plan, et recommence jusqu'à atteindre l'objectif. Anthropic résume cette distinction de façon utile dans son guide Building Effective Agents : un workflow exécute un script écrit à l'avance, un agent décide à l'exécution.

Cette distinction a une conséquence opérationnelle directe. Sur un workflow, vous pouvez tester tous les chemins. Sur un agent, l'espace des trajectoires possibles explose combinatoirement — et chaque trajectoire coûte des tokens. La supervision et l'observabilité ne sont plus des options, elles deviennent le cœur du système.

Trois architectures à connaître avant de choisir

Avant de débattre du framework, il faut trancher sur la topologie. Les architectures multi-agents qu'on rencontre en production se ramènent à trois patterns, qu'on peut combiner mais qu'il vaut mieux ne pas confondre.

Trois topologies multi-agents — patterns de référence

L'orchestrateur central est le pattern le plus simple à mettre en production : un agent superviseur reçoit la requête, décide quel sous-agent appeler, agrège les résultats. C'est lisible, débogable, et ça concentre la logique métier dans un seul endroit. C'est aussi un goulot d'étranglement et un point de défaillance unique.

Le swarm distribue le contrôle entre pairs qui se passent la main par handoff — un agent décide d'envoyer le contexte à un autre quand sa zone de compétence s'arrête. Très puissant pour des assistants conversationnels qui couvrent plusieurs domaines (l'agent commercial passe au juridique, qui repasse à la facturation), mais cauchemardesque à observer si vous n'avez pas mis en place un traçage global de bout en bout.

L'architecture hiérarchique est l'extension naturelle de l'orchestrateur quand le périmètre dépasse une dizaine d'outils. Un agent racine délègue à des « managers » spécialisés, chacun pilotant ses propres sous-agents. C'est le pattern qu'on retrouve typiquement chez les éditeurs qui exposent des agents-produits couvrant plusieurs métiers. Les coûts deviennent rapidement un sujet — chaque niveau ajoute des tokens de contexte.

LangGraph, CrewAI, AutoGen, LlamaIndex : sur quels critères trancher

Les quatre frameworks dominent les conversations d'architectes en 2026. Aucun ne gagne sur tous les critères. Le choix dépend de la maturité de votre équipe Python, de votre tolérance à la dépendance, de votre besoin de contrôle bas niveau, et de la complexité du graphe d'orchestration cible.

Le résumé pragmatique que nous donnons à nos clients : LangGraph pour tout ce qui doit tourner en production avec exigences de reprise sur incident, traçabilité fine et workflows longs (plusieurs minutes à plusieurs heures). CrewAI pour prototyper vite avec une équipe métier qui pense en termes de rôles. AutoGen quand la valeur est dans le dialogue entre agents (par exemple : un « relecteur » qui challenge un « rédacteur »). LlamaIndex quand l'agent est avant tout un agent de recherche sur du corpus structuré.

Un point souvent négligé : ces frameworks ne sont pas exclusifs des SDK natifs. Pour des cas d'usage simples, l'API function calling d'OpenAI ou le function calling de Mistral sans framework reste la solution la plus robuste. La règle empirique : un seul agent avec moins de 10 outils ne justifie pas LangGraph.

Le choix du modèle : les compromis 2026

La génération 2026 — GPT-5, Claude 4.6 Sonnet, Mistral Large 3 — a stabilisé un constat important : le tool use est devenu fiable. Les trois modèles atteignent désormais des taux de succès suffisants sur les benchmarks d'appel d'outils pour qu'on n'ait plus à compenser au niveau du prompt. Reste trois critères de choix opérationnels.

La gestion du contexte long diffère encore sensiblement : Claude 4.6 Sonnet conserve l'avantage sur les agents qui doivent tenir un état conversationnel sur des heures. GPT-5 reste imbattable sur la planification multi-étapes complexe. Mistral Large 3 apporte la souveraineté européenne et un coût/token compétitif sur les workloads à fort volume — un argument qui pèse de plus en plus dans les directions juridiques sensibles à l'extraterritorialité américaine.

Pour les agents avec contraintes de latence (relation client en temps réel), une architecture mixte est devenue le standard : un modèle « rapide et économique » (Haiku, Mistral Small, GPT-5 mini) pour le routage et les classifications intermédiaires, un modèle premium pour les nœuds de raisonnement critique. Sur un graphe LangGraph, cette différenciation se fait nœud par nœud — c'est l'un des arguments forts du framework.

L'observabilité n'est pas une option, c'est le système

Tant que l'agent tourne sur un poste de développeur, vous voyez tout dans la console. Dès qu'il passe en production, sans observabilité dédiée, vous êtes aveugle. Et un agent aveugle qui boucle sur une API LLM premium peut générer une facture à cinq chiffres avant qu'on s'en aperçoive — chaque itération empile contexte, outils invoqués et tokens de sortie.

Trois couches d'observabilité doivent être posées avant la mise en production, pas après :

• Tracing distribué — chaque trajectoire d'agent doit produire une trace OpenTelemetry contenant tous les appels LLM, les outils invoqués, les tokens consommés, les durées. LangSmith, Arize Phoenix, Helicone ou Langfuse remplissent cette fonction. Le critère de choix : la facilité d'export vers votre stack d'observabilité existante (Datadog, Grafana, Splunk).
• Évaluation continue — un échantillon des trajectoires doit être noté automatiquement (LLM-as-a-judge) ou par échantillonnage humain. Sans cette boucle, vous découvrirez les régressions par les tickets utilisateurs.
• Garde-fous coûts — circuit breaker sur le nombre maximal d'itérations par session, plafonds de tokens par utilisateur et par jour, alertes sur les déviations de coût moyen. Ce n'est pas du nice to have : c'est ce qui sépare un agent en production d'un agent retiré en urgence.

Cinq pièges qui font dérailler les agents en production

Intégration au SI : le sujet qui décide du go/no-go

Un agent qui n'accède à rien ne sert à rien. Un agent qui accède à tout est un risque opérationnel et un cauchemar de conformité. La question d'intégration au SI est, dans la pratique, ce qui détermine si le projet passe en production ou reste un POC indéfiniment.

Trois principes que nous appliquons systématiquement chez nos clients :

Exposer les outils via une couche dédiée, pas en direct sur les API métier. Une API gateway « tools » devant les systèmes existants permet d'appliquer les contrôles d'authentification, le throttling, les filtres de données, le logging d'audit. Un agent qui appelle directement le SAP ou le CRM est un agent qu'on ne pourra pas auditer après coup. Le standard Model Context Protocol est en train d'émerger comme normalisation de cette couche.

Identité propre de l'agent, pas usurpation d'identité utilisateur. L'agent doit avoir son propre compte de service avec ses propres droits. Quand il agit pour un utilisateur, il transmet le contexte d'autorisation, mais les actions sont tracées comme « agent X agissant pour utilisateur Y ». Cette séparation est non négociable pour les audits AI Act et ISO 27001.

Lecture massive, écriture chirurgicale. Un agent peut lire largement (read-only access) sur les sources de connaissance. Pour toute action en écriture, sas de validation : preview, confirmation, double validation au-dessus d'un seuil de criticité métier. C'est le seul moyen de cadrer le risque sans tuer l'intérêt de l'agent.

Sur ces sujets d'intégration et d'industrialisation, notre expertise Agents IA couvre l'ensemble du cycle, en complément de notre expertise GenAI. Pour les projets qui s'appuient massivement sur des bases de connaissances, le sujet rejoint celui que nous avons traité dans RAG en entreprise, et le choix du modèle de base reprend les arbitrages de choisir un LLM en production.

Ce qui distingue un agent qui tient en production

Les projets qui survivent à leur première année partagent quatre caractéristiques. Un périmètre fonctionnel volontairement étroit au démarrage — un seul cas d'usage, dix outils maximum. Une observabilité posée avant le premier utilisateur, jamais après. Une architecture qui sépare clairement la couche orchestration (LangGraph ou équivalent), la couche outils (API gateway), et la couche modèle (interchangeable). Et un dispositif d'évaluation continue qui détecte les régressions sans dépendre des remontées utilisateur.

Ce qui les distingue surtout, c'est l'absence d'illusion sur la maturité du sujet. Construire un agent fiable en 2026 reste un travail d'ingénierie sérieux, pas une intégration de SDK. Les frameworks aident, les modèles aident, mais c'est l'architecture et les garde-fous qui font la différence entre un projet qui scale et un projet qui se fait débrancher au premier incident.