🚀 Architecture d’agent IA : boucle & outils (2026)
Découvrez l’architecture d’agent IA : boucle agentique, outils IA et choix d’exécution. Réduisez coûts & risques, renforcez la sécurité. Guide 2026.
Agents IA : pourquoi leur architecture compte autant que le modèle
Un agent d'intelligence artificielle ne se résume pas au modèle qui génère ses réponses. Pour comprendre ce qu'il peut vraiment faire - et les risques qui vont avec - il faut aussi regarder la boucle qui orchestre ses actions et les outils auxquels il accède. Ensemble, ces éléments constituent son architecture opérationnelle.
Cette distinction compte surtout si vous intégrez un agent dans un produit, ou si vous sélectionnez un assistant de programmation pour automatiser des tâches internes. Et selon où s'exécutent le modèle, la boucle et les outils, les coûts, la confidentialité, l'expérience utilisateur et le périmètre d'incident peuvent changer du tout au tout. Une démonstration "wow" peut devenir un casse-tête à sécuriser et à faire tenir à l'échelle.
L'objectif n'est donc pas de trouver une architecture universelle : ça n'existe pas. Il s'agit plutôt de cartographier les composants, d'identifier les compromis et de choisir une configuration cohérente avec votre cas d'usage. Voici une méthode pour y arriver, avec des exemples concrets et des repères utiles pour des organisations en France et en Europe.
Les trois composants d'un agent IA
Un agent se décompose en trois éléments : un modèle, une boucle d'exécution et un ensemble d'outils. Sur le papier, ça paraît simple, mais ça permet de répondre à une question cruciale : qu'est-ce qui s'exécute, où, et avec quels accès ?
Le modèle interprète les demandes et produit des réponses, ou bien déclenche des appels d'outils. La boucle (souvent appelée harness) conserve l'historique, décide quand solliciter le modèle, transmet les appels aux outils et renvoie le résultat à l'utilisateur. Les outils, eux, donnent à l'agent une capacité d'action : lire un fichier, interroger une base, lancer un test, ou créer un ticket.
La boucle et les outils sont parfois regroupés sous le terme de harness. Cette séparation est utile, parce qu'un agent n'est pas juste un modèle "avec des instructions". Un modèle qui répond une seule fois à une question n'a rien à voir avec un système capable d'examiner un dépôt de code, modifier un fichier, lancer des tests, analyser leurs résultats, puis recommencer.
Une architecture, plusieurs lieux d'exécution
Ces composants peuvent tourner au même endroit ou être répartis. Le modèle peut être hébergé par un fournisseur, pendant que la boucle s'exécute sur l'ordinateur d'une équipe, et que les outils sont proposés par des serveurs distants. Dans d'autres cas, tout tourne dans le nuage d'une entreprise ou, pour certains usages, directement sur un appareil.
Cette répartition dessine la topologie de l'agent. Et elle a des effets concrets :
- Coût : qui paie les appels au modèle, l'exécution des outils et les ressources informatiques ?
- Confidentialité : quelles données sortent du poste ou du système d'information ?
- Capacités : l'agent peut-il accéder aux fichiers, aux applications et aux environnements nécessaires ?
- Sécurité : où sont stockés les secrets, et jusqu'où une action imprévue peut-elle se propager ?
- Expérience : l'interface montre-t-elle correctement les fichiers, les images, les pièces jointes et les retours d'exécution ?
Au fond, ce n'est pas seulement "quel modèle choisir ?". Deux produits basés sur le même modèle peuvent offrir des capacités, des coûts et des niveaux de risque très différents. Pour une entreprise, choisir un agent, c'est aussi choisir une architecture de traitement et un périmètre d'accès.
Où exécuter le modèle : cloud ou local
Dans la plupart des cas, le choix se fait entre un modèle hébergé par un fournisseur et un modèle exécuté sur une infrastructure contrôlée par l'organisation. Il n'y a pas de règle universelle : le bon choix dépend de la sensibilité des données, des contraintes de latence, du budget et du niveau de performance attendu.
Un modèle distant donne souvent accès à des capacités avancées sans gérer d'accélérateurs matériels, sans s'occuper des mises à jour des poids, ni d'une partie de l'exploitation. C'est fréquemment le moyen le plus rapide de tester un cas d'usage. En échange, les requêtes partent chez un tiers, les coûts varient avec l'usage et l'organisation dépend des conditions de service du fournisseur.
Un modèle local garde les données sur un appareil ou dans une infrastructure maîtrisée. Il convient bien aux tâches qui tolèrent une exécution plus lente (par exemple classer des documents numérisés pendant la nuit) ou aux contextes où le réseau est limité. Mais "local" ne veut pas dire "automatiquement simple" : il faut le matériel, suivre les mises à jour et vérifier que les performances suffisent réellement pour la tâche.
Confidentialité et confiance dans le fournisseur
Le principe est simple : si une donnée ne doit absolument pas quitter votre environnement, ne l'envoyez pas à un service distant avant d'avoir vérifié le cadre applicable. Attention : ça ne veut pas dire que tout transfert est forcément interdit ou dangereux. Ça veut dire qu'il faut regarder la conservation des données, les conditions d'utilisation, la manière dont les données sont traitées et les garanties contractuelles, notamment au regard du RGPD.
Par exemple, une entreprise française peut utiliser un modèle distant pour reformuler des contenus publics et un modèle local pour traiter des documents internes sensibles. Cette approche par niveaux de sensibilité est souvent plus réaliste qu'une politique "tout ou rien".
La confiance porte aussi sur le logiciel et sur les modèles. Les poids du modèle, les dépendances et la chaîne de compilation font partie de la surface de confiance. Et le sujet n'est pas nouveau : "du code visible" ne garantit pas que le programme exécuté se comporte exactement comme prévu. Il faut donc évaluer les fournisseurs, les contrôles disponibles et le processus de mise à jour, plutôt que de considérer le modèle comme une boîte neutre.
Qui paie les appels au modèle ?
Les modèles peuvent aussi faire bouger l'économie d'un logiciel en ligne. Avant l'intégration d'un agent, une fonctionnalité coûte souvent surtout en stockage et en opérations "classiques". Après coup, une demande formulée en langage naturel peut déclencher plusieurs appels au modèle, des recherches et des exécutions d'outils. Résultat : un seul client peut peser plus lourd que prévu sur la facture.
Il faut donc décider qui assume la note : l'éditeur, le client, ou les deux. Une option "apportez votre propre modèle" (où le client connecte son abonnement ou ses clés) peut limiter le risque financier côté éditeur. Mais elle ajoute de la configuration et peut dégrader l'expérience si ce point est mal expliqué.
Avant de lancer, estimez le coût par tâche réussie, pas uniquement le prix d'un appel. Regardez aussi les usages anormaux, mettez des limites, et dites clairement qui paie. Une fonctionnalité très utilisée, mais impossible à facturer durablement, n'est pas un succès produit : c'est un problème en retard.
La boucle agentique : le moteur de l'expérience
La boucle organise les échanges entre l'utilisateur, le modèle et les outils. Elle ajoute la réponse de l'utilisateur à l'historique, envoie le contexte au modèle, récupère une réponse ou des appels d'outils, puis décide de la suite. Et ça continue jusqu'à ce que l'agent réponde, ou jusqu'à ce qu'il déclenche une nouvelle action.
Dans un assistant en ligne, la boucle tourne généralement sur les serveurs du fournisseur. Dans un agent de programmation, elle peut tourner sur l'ordinateur du développeur. Elle peut aussi s'exécuter dans un navigateur ou dans l'infrastructure de l'entreprise. Ce n'est pas un détail d'implémentation : ça influence la manière dont l'agent garde son état, affiche les résultats et accède aux systèmes de travail.
L'historique et l'Ă©tat de la conversation
Un modèle ne se "souvient" pas forcément d'une conversation comme le ferait une personne. La boucle lui envoie un historique (ou une sélection de l'historique) pour qu'il comprenne la demande en cours. D'où des questions très concrètes : où stocker les messages, pendant combien de temps, et comment gérer les informations devenues inutiles ou sensibles.
Pour un prototype ou un outil interne, une base locale simple peut suffire. Pour un service multi-utilisateur, il faut aussi gérer les droits d'accès, la sauvegarde, la suppression et l'isolation des conversations. Une solution techniquement "très avancée" n'est pas forcément meilleure : une base légère, bien comprise et bien maîtrisée, peut être plus fiable qu'une architecture distribuée que personne n'arrive à opérer.
L'enjeu, c'est d'avoir juste assez de contexte pour de bons résultats, sans accumuler des données à l'infini ni gonfler inutilement la taille et le coût des requêtes. La gestion de l'historique, en clair, fait partie du produit - pas seulement du stockage.
Une interface adaptée au travail
La boucle fournit aussi l'interface. Un agent de programmation doit pouvoir montrer des modifications, des journaux de tests et des erreurs. Un outil d'analyse documentaire peut avoir besoin d'afficher des images ou des pièces jointes. Un assistant limité au texte ne répondra pas aux mêmes besoins qu'un outil capable de suivre des retours structurés.
C'est aussi pour ça qu'un agent "généraliste" n'est pas automatiquement le meilleur choix pour chaque tâche. L'interface qui convient à un chatbot ne colle pas forcément à une équipe d'exploitation qui doit analyser des alertes, ni à un concepteur qui veut modifier un schéma. Une boucle plus spécialisée peut rendre les actions plus lisibles et permettre un retour plus précis.
Le contrôle humain doit être pensé à ce niveau. Pour une action réversible (proposer une modification, par exemple), une confirmation légère peut suffire. Pour une action qui envoie un paiement, supprime des données ou déploie en production, une validation explicite et traçable est généralement nécessaire. En bref : adaptez les contrôles aux conséquences, pas l'inverse.
Les outils : capacités, coûts et périmètre de risque
Sans outils, un modèle peut produire une réponse, mais il ne peut pas forcément vérifier le résultat dans le monde réel. Un agent qui lance un test, interroge une base de données ou consulte une documentation à jour peut produire un travail plus utile, parce qu'il confronte ses hypothèses à des faits observables.
La contrepartie est simple : chaque outil ouvre un accès en plus. Si l'agent peut modifier des fichiers, utiliser le réseau ou accéder à des identifiants, une erreur (ou une instruction malveillante) peut avoir des effets qui dépassent la conversation. Les outils définissent donc à la fois la valeur de l'agent et son périmètre de risque.
Choisir le bon niveau d'isolation
L'exécution de code généré doit être traitée comme potentiellement dangereuse. Le code peut supprimer des fichiers, consommer trop de ressources, communiquer avec un service externe, ou exploiter des secrets accessibles depuis son environnement. Dans un agent de programmation, ces risques ne sont pas théoriques : compiler, tester, ou traiter des fichiers implique forcément d'exécuter du code.
Une machine virtuelle aide à isoler les tâches, mais elle ne règle pas tout. Il faut aussi cadrer l'accès réseau, la présence d'identifiants, les limites de mémoire et la durée d'exécution. Une VM avec trop de droits peut déplacer le risque au lieu de le supprimer.
Pour des tâches plus limitées, des environnements restreints peuvent suffire : exécuter du Python dans un environnement WebAssembly, travailler sur une base en lecture seule, ou n'autoriser que quelques opérations prédéfinies. Le niveau de protection doit être proportionné au travail. Si l'agent n'a besoin que de lire des données, ne lui donnez pas le droit de les modifier.
Outils distants et serveurs MCP
Les outils ne sont pas obligés de tourner dans le même processus que la boucle. Ils peuvent être exposés à distance, notamment via le protocole MCP, qui permet à un agent de communiquer avec des outils ou des ressources externes. Un assistant hébergé dans le nuage peut alors accéder à un environnement de développement ou à un service métier situé ailleurs.
Cette séparation facilite parfois l'intégration, mais elle rend aussi le chemin moins évident. Il faut cartographier les échanges : quel composant détient les jetons d'authentification ? Où sont-ils stockés ? Quels droits accordent-ils ? L'accès est-il limité à une action précise, ou donne-t-il la possibilité de toucher à tout un compte ? Une connexion "pratique" n'est pas une raison pour donner un accès illimité.
Appliquez le principe du moindre privilège : autorisations minimales, limitées au besoin, et révocables. Pour les actions sensibles, séparez la lecture de l'écriture, journalisez les opérations et prévoyez un mécanisme d'arrêt. L'objectif n'est pas d'interdire les outils : c'est de rendre leurs conséquences prévisibles et contrôlables.
Cartographier un agent avant de le déployer
Il n'y a pas de boucle "universelle". Un agent d'assistance générale, un agent de programmation et un assistant de traitement de factures n'ont ni la même interface, ni les mêmes contraintes, ni les mêmes besoins en outils. La bonne architecture, c'est celle qui sert la tâche sans ajouter des accès ou des coûts inutiles.
Avant un déploiement, dessinez le trajet d'une demande, de l'utilisateur jusqu'au résultat. Pour chaque étape, précisez où le composant s'exécute, quelles données il reçoit, quels systèmes il peut appeler, et qui paie. Cette carte révèle souvent les problèmes plus vite qu'une longue discussion centrée sur le choix du modèle.
Une grille de décision en cinq questions
- Quelle tâche l'agent doit-il accomplir ? Visez un résultat vérifiable, pas une ambition floue comme "automatiser le support".
- Quelles données sont nécessaires ? Séparez données publiques, internes et sensibles. Réduisez le contexte transmis au minimum utile.
- Où s'exécute chaque composant ? Notez l'emplacement du modèle, de la boucle, des outils et du stockage de l'historique.
- Quels droits sont indispensables ? Commencez en lecture seule quand c'est possible, puis ajoutez des capacités au fur et à mesure que le besoin se confirme.
- Comment mesurez-vous le coût et la qualité ? Suivez le coût par tâche terminée, les erreurs, les reprises et les interventions humaines.
Cette grille évite deux erreurs fréquentes. La première, c'est de choisir un modèle très puissant avant d'avoir défini le travail attendu. La seconde, c'est de connecter l'agent à tous les systèmes disponibles, puis de chercher après coup comment réduire les risques.
Un déploiement progressif plutôt qu'un accès total
Commencez par une version qui observe ou propose, plutôt qu'une version qui modifie directement les systèmes. Un agent qui résume des alertes sans les acquitter vous aide à évaluer la pertinence sans lui donner le contrôle de l'exploitation. Un assistant qui prépare une modification pour validation réduit le risque par rapport à un agent qui déploie seul.
Ensuite, élargissez les permissions à partir de résultats mesurés. Si la tâche est stable, si les erreurs sont détectées et si le coût reste acceptable, certaines actions peuvent être automatisées. Gardez des journaux et un moyen de révoquer l'accès. Un déploiement progressif donne des informations réelles sur le comportement du système, au lieu de reposer uniquement sur des hypothèses d'ingénierie.
Pour les éditeurs, la même logique s'applique au produit : donner des fonctionnalités à des agents peut être un avantage, mais il faut prévoir des interfaces lisibles, des permissions compréhensibles et une tarification soutenable. L'agent ne remplace pas forcément l'application : il peut aussi agir comme couche de coordination entre plusieurs outils, à condition que ces outils exposent des capacités claires et contrôlables.
Conclusion : choisir une architecture que l'on peut maîtriser
Pour évaluer un agent IA, ne vous arrêtez pas au nom du modèle. Cherchez plutôt : la boucle, les outils, les données qui circulent, les droits accordés et la personne (ou l'entité) qui paie les ressources. C'est l'architecture qui détermine ce que l'agent peut accomplir - et ce qui peut mal tourner.
Commencez par un cas d'usage précis, appliquez des permissions minimales et mesurez coût et qualité sur des tâches réelles. Ensuite seulement, élargissez le périmètre si les résultats le justifient. Une architecture imparfaite mais comprise, contrôlable et utile vaut mieux qu'une idée ambitieuse que l'équipe ne saura ni exploiter ni sécuriser.
Pour aller plus loin, consultez le texte d'origine sur la topologie des agents et les recommandations de la CNIL sur l'intelligence artificielle.