Un fournisseur vous envoie une proposition. Les slides montrent un diagramme avec des blocs et des flèches : un LLM au centre, des bases de données sur les côtés, quelques icônes d’API. L’ensemble paraît complet. Mais le diagramme ne vous dit pas si le système se comportera de manière fiable sous charge, ce qui se passe quand une API tombe, combien coûte chaque conversation ou si vous pourrez changer de fournisseur dans deux ans.
Ces réponses se trouvent dans l’architecture. Et vous n’avez pas besoin d’être ingénieur pour poser les bonnes questions.
Cet article traduit l’architecture des agents IA dans les termes qui comptent pour les achats : fiabilité, coût d’exploitation et dépendance fournisseur. Considérez-le comme une checklist pour auditer la conception d’un prestataire avant de signer.
Les quatre piliers que toute architecture d’agents IA possède (que le fournisseur les nomme ou non)
Un agent IA prêt pour la production est construit sur quatre composants logiques. Les fournisseurs les appellent différemment, les combinent de diverses façons et les regroupent parfois dans une seule plateforme opaque. Mais ils sont toujours là.
1. Le Planner (la couche de « raisonnement »)
Le planner est le large language model (LLM) au cœur de l’agent. Il reçoit un objectif ou un message utilisateur, détermine ce qu’il faut faire ensuite et décide quels outils appeler. Certaines architectures utilisent un seul appel LLM par étape ; d’autres exécutent plusieurs cycles de raisonnement avant d’agir.
Ce qu’il faut demander au fournisseur :
- Quel modèle LLM alimente le planner, et comment est-il mis à jour ? (Une mise à jour de modèle qui modifie le comportement sans préavis est un risque pour la fiabilité.)
- Le planner est-il déterministe ou probabiliste ? Peut-on fixer des seuils de confiance ou des conditions de fallback ?
- Comment le planner est-il instruit ? Avez-vous une visibilité ou un contrôle sur le system prompt ?
2. Les outils (les « mains » de l’agent)
Les outils sont les connexions avec le monde extérieur : requêtes en base de données, appels API, soumissions de formulaires, lectures de fichiers, envois d’e-mails. Un agent sans outils n’est qu’un chatbot. La couche d’outils est l’endroit où les agents font réellement des choses.
Le nombre, la fiabilité et le périmètre des outils déterminent ce que l’agent peut accomplir — et ce qu’il pourrait faire par accident. Un outil capable d’envoyer des e-mails est utile ; un outil qui peut en envoyer à n’importe qui sans étape de validation est une source de risque.
Ce qu’il faut demander au fournisseur :
- À quels outils l’agent a-t-il accès, et cet ensemble peut-il être restreint ?
- Les appels d’outils sont-ils journalisés de manière auditable ?
- Que se passe-t-il quand un appel d’outil échoue — l’agent réessaie-t-il, escalade-t-il vers un humain ou échoue-t-il silencieusement ?
3. La mémoire (ce que l’agent retient)
La mémoire dans l’architecture des agents IA est plus nuancée qu’il n’y paraît. Il existe au moins trois types distincts :
- Mémoire à court terme : le contexte de la conversation en cours, maintenu dans la context window du LLM. Elle est réinitialisée à la fin de la session.
- Mémoire à long terme : des faits stockés dans une base de données et récupérés selon les besoins — historique client, connaissances produit, interactions passées.
- Mémoire procédurale : règles, workflows et schémas intégrés dans les instructions de l’agent ou son fine-tuning.
La conception de la mémoire a un impact direct sur l’expérience utilisateur et les coûts. Les agents dotés d’une mémoire à long terme bien conçue paraissent cohérents et conscients du contexte. Les agents qui reposent uniquement sur la mémoire à court terme reposent des questions auxquelles les utilisateurs ont déjà répondu.
Ce qu’il faut demander au fournisseur :
- Quels types de mémoire l’architecture inclut-elle ?
- Où les données clients sont-elles stockées et sous quelle juridiction ? (Pour les entreprises suisses, cela est déterminant pour la conformité à la nLPD — voir notre article sur Agents IA et protection des données en Suisse.)
- La mémoire à long terme peut-elle être effacée ou corrigée si elle contient des informations erronées ?
4. Les guardrails (la couche de sécurité et de contrôle)
Les guardrails sont les contraintes qui maintiennent l’agent dans sa mission et dans un comportement acceptable. Ils opèrent à plusieurs niveaux : filtrage des entrées (blocage des requêtes nuisibles ou hors périmètre), validation des sorties (vérification des réponses avant envoi), limites de scope (empêcher l’agent d’agir en dehors de son rôle défini) et logique d’escalade (savoir quand passer la main à un humain).
C’est le composant le plus souvent sous-spécifié dans les démos fournisseurs. Une démo fonctionne parce que le fournisseur contrôle les entrées. La production fonctionne parce que les guardrails tiennent quand les entrées sont imprévisibles.
Ce qu’il faut demander au fournisseur :
- Que se passe-t-il quand un utilisateur tente de faire faire à l’agent quelque chose hors de son périmètre ?
- Existe-t-il une option human-in-the-loop pour les actions à fort enjeu (transactions importantes, accès à des données sensibles) ?
- Comment les règles de guardrail sont-elles mises à jour à mesure que le business évolue ?
Comment les choix architecturaux déterminent vos coûts d’exploitation
Les coûts d’un agent IA ne se résument pas à une licence. L’architecture détermine une part significative du coût par interaction, qui s’accumule à l’échelle.
Le principal poste de coût est la consommation de tokens LLM. Chaque message dans la context window a un coût. Un agent qui transmet l’intégralité de l’historique de conversation à chaque étape — plutôt que d’utiliser une mémoire à long terme structurée — consomme des tokens de façon linéaire avec la longueur de la conversation. Pour une entreprise traitant des centaines d’interactions par jour, ce choix architectural verrouille la courbe des coûts.
D’autres postes de coût méritent d’être examinés :
- Fréquence des appels d’outils : davantage d’appels par interaction signifie plus de latence et parfois des coûts d’API tiers supplémentaires.
- Tier du modèle : certaines architectures utilisent des modèles frontier coûteux pour chaque étape ; d’autres les réservent au raisonnement complexe et utilisent des modèles plus légers pour les sous-tâches simples (un schéma parfois appelé « model cascade »).
- Logique de retry : un agent qui relance des appels d’outils échoués sans circuit-breaker peut multiplier les coûts lors d’une interruption de service.
Le lock-in se trouve dans l’architecture, pas dans le contrat
Le risque d’achat le plus négligé dans les projets d’agents IA est le lock-in architectural. Un contrat peut inclure des clauses de sortie ; une architecture ne peut pas toujours être migrée à faible coût.
Le lock-in s’accumule généralement en trois endroits :
Stores de mémoire propriétaires : si la mémoire à long terme de l’agent est stockée dans un format de base de données spécifique au fournisseur, la migration implique de réimporter et de revalider tout le contexte historique — souvent des mois de données accumulées.
Intégrations d’outils codées en dur : les agents construits directement sur le SDK d’un fournisseur via des API de tool-calling propriétaires nécessitent une réécriture lors d’un changement de plateforme. C’est différent des agents construits sur des standards ouverts comme le Model Context Protocol (MCP), où les outils sont plus portables. Nous approfondissons ce sujet dans Lock-in des plateformes d’agents IA : les risques que personne ne chiffre.
Dépendance au modèle : si la logique du planner a été fortement optimisée autour des particularités d’un modèle spécifique (par exemple un modèle depuis déprécié ou significativement mis à jour), migrer vers un autre LLM peut nécessiter de recalibrer l’ensemble du système.
Les architectures les plus sûres maintiennent ces couches faiblement couplées : le planner peut changer de modèle, la couche mémoire utilise des patterns de retrieval standard, les outils se connectent via des API documentées ou des protocoles ouverts. Ce n’est pas toujours réalisable dans les contraintes de budget ou de délai, mais c’est la question à poser.
Une checklist d’audit pratique avant de s’engager
Lors de l’évaluation d’une proposition d’agent IA, ces questions révèlent la qualité de conception plus vite que n’importe quelle démo :
Fiabilité
- Quel est le comportement en cas de failover quand l’API LLM est indisponible ?
- Comment l’agent gère-t-il des entrées ambiguës ou contradictoires ?
- Existe-t-il un mécanisme pour détecter et interrompre les boucles infinies ou les chaînes d’outils incontrôlées ?
Coûts
- Quel est le coût estimé en tokens par interaction, et comment évolue-t-il avec la longueur de la conversation ?
- L’architecture utilise-t-elle un seul modèle pour toutes les tâches, ou une approche à niveaux de coût différenciés ?
Lock-in
- Quels composants sont propriétaires, et lesquels utilisent des standards ouverts ?
- Où les données sont-elles stockées, et dans quel format sont-elles exportables ?
- Si vous changiez de fournisseur LLM, que faudrait-il réécrire ?
Contrôle
- Quels guardrails sont en place, et qui peut les modifier ?
- Existe-t-il un audit log complet des appels d’outils et des décisions de l’agent ?
Quand les revues d’architecture sont vraiment nécessaires
Tous les projets d’agents IA ne justifient pas une revue architecturale approfondie à l’achat. Un simple chatbot FAQ sans accès aux outils ni persistance des données présente un risque faible quelle que soit sa conception.
Les enjeux architecturaux s’élèvent avec :
- L’accès aux outils sur des systèmes sensibles (CRM, ERP, données financières, données clients)
- Un volume d’interactions élevé où le coût par interaction s’accumule
- Des workflows autonomes multi-étapes où une mauvaise décision précoce se propage
- L’exposition réglementaire — tout ce qui touche aux données personnelles sous le RGPD, la nLPD suisse, ou les deux — de nombreuses entreprises suisses sont soumises simultanément aux deux régimes
Si votre cas d’usage entre dans l’une de ces catégories, comprenez l’architecture avant le contrat, pas après. Pour une vue d’ensemble de la conception agentique, voir Orchestration d’agents IA : faire fonctionner les agents comme un système et Que sont les agents IA ? Un guide sans hype pour les dirigeants.
La décision build-vs-buy est également façonnée par l’architecture : les plateformes échangent la configurabilité contre la rapidité ; les développements sur mesure échangent la rapidité contre le contrôle. Build vs Buy : un cadre de décision pour les agents IA examine directement ce compromis.
À quoi ressemble une bonne revue d’architecture
Chez Orange ITS, lorsque nous évaluons un projet d’agent IA — que nous le construisions ou que nous examinions un système existant — nous cartographions explicitement les quatre composants avant d’écrire la moindre ligne de code. Cela signifie : définir le modèle du planner et son comportement de fallback, préciser quels outils l’agent peut invoquer et dans quelles conditions, concevoir le modèle de mémoire pour les performances et la résidence des données, et rédiger la logique de guardrail avant le happy path.
Ce n’est pas spectaculaire. C’est aussi la raison pour laquelle les systèmes construits de cette façon ne surprennent pas leurs propriétaires six mois plus tard avec des factures API en spirale, des questions de conformité ou un fournisseur qui annonce que la migration coûtera plus cher que le développement initial.
Si vous évaluez un projet d’agent IA et souhaitez un second avis sur une proposition fournisseur — ou une vision claire de l’architecture adaptée à votre cas d’usage — un appel de 30 minutes avec notre équipe est le moyen le plus rapide d’y parvenir. Nous cartographierons les quatre composants au regard de vos exigences et signalerons où la conception est solide et où elle cache des risques.