Le faux débat du « meilleur modèle »

Dans le débat public IT, l'agent IA est souvent réduit à un duel de modèles. Il y aurait d'un côté les modèles « les plus intelligents », et de l'autre les « outsiders ». Et, au milieu, des entreprises persuadées qu'un changement de fournisseur suffira à régler la qualité des réponses, la sécurité, la fiabilité et la valeur.

Et ce raccourci se comprend tout à fait. Les modèles sont en effet visibles, ils ont des noms, des versions, des benchmarks… Mais il occulte l'essentiel. Dans les systèmes d'information, la valeur n'est presque jamais dans un composant isolé. Elle se fabrique dans l'assemblage, le flux de données, les permissions, la logique métier, les garde-fous, la supervision, la maintenance. Les agents IA ne font pas exception, ils la rendent même plus évidente, parce qu'ils introduisent de l'automatisation et de l'incertitude au cœur d'environnements qui, eux, n'aiment ni l'une ni l'autre.

La plupart des experts insistent d'ailleurs moins sur la « qualité » d'un modèle que sur ses vulnérabilités et ses erreurs de conception : injection de prompt, gestion hasardeuse des sorties, dépendances de chaîne d'approvisionnement, déni de service, etc.

Du POC à l'agent exploitable, la marche est haute

En matière d’IA, le proof of concept est devenu inévitable. En quelques jours, on branche un modèle à un corpus documentaire, on obtient des réponses séduisantes, on conclut que « ça marche ».

Puis vient la question que personne n'aime, « comment on met ça en production ? ».

La différence entre un POC IA et un agent IA exploitable se joue sur des contraintes classiques du logiciel, répétabilité, contrôle d'accès, gestion des erreurs, tests, supervision, coûts, résilience, etc.

Là où le POC tolère l'à-peu-près, la production le facture.

L'agent ajoute une marche supplémentaire. Il n'est pas seulement un système qui répond, il est un système qui agit ou qui propose d'agir. Il enchaîne des étapes, interroge des outils, appelle des API, exécute des actions, parfois dans des systèmes critiques. C'est là qu'apparaît la réalité du métier, on ne « déploie » pas un agent, on déploie une chaîne d'exécution.

Un agent IA, c'est d'abord une architecture

L'architecture d'un agent IA ressemble finalement moins à un prompt qu'à une application moderne. Vous y trouverez une interface, des services, des intégrations, des limites, des logs, des métriques… et, au centre, une orchestration.

Cette orchestration est d‘ailleurs le vrai cœur du sujet, puisqu’elle décide quand le modèle doit « raisonner », quand est-ce qu’il doit aller chercher une source, appeler un outil ou s'arrêter, et comment il doit rendre une sortie exploitable. En d'autres termes, elle transforme une capacité probabiliste en un comportement logiciel.

Trois briques reviennent dans les projets qui cherchent à durer.

D'abord, l'API. Un agent sérieux n'a pas un accès direct et informel aux systèmes. Il passe par des interfaces maîtrisées, versionnées, avec des permissions explicites. Ensuite, la sécurité, qui ne se limite pas au chiffrement. Elle inclut la séparation des rôles, la réduction des droits, la gestion des secrets, et la prévention des attaques typiques des systèmes LLM, dont l'injection de prompt. Enfin, l'observabilité, parce qu'un agent qui ne se trace pas devient un agent qui ne s'audite pas. Et un agent qui ne s'audite pas finit par être désactivé, souvent après un incident…

Cette exigence est renforcée par le contexte de menace. L'ANSSI rappelle souvent à ce sujet que les usages offensifs et défensifs évoluent rapidement et qu'il faut réévaluer régulièrement les risques liés à l'IA générative.

Brancher un agent au SI, c'est là que tout se complique

C'est souvent au moment de l'intégration que le débat sur le modèle s'éteint. Un agent utile doit parler aux outils de l'entreprise, CMS, ERP, CRM, GED, ITSM, bases de connaissances, référentiels métiers... Or ces systèmes ont chacun leurs contraintes, leurs droits, leurs logs, leurs erreurs, leurs formats. Et ils n'ont pas été conçus pour dialoguer avec un moteur probabiliste.

C'est aussi là qu'il faut décider de la place de l'agent. Va-t-il travailler « à côté » du SI, comme une couche d'assistance ? Ou alors « dans » le SI, comme un opérateur d'actions ?

Dans un CMS, par exemple, l'agent peut suggérer des modifications, reformuler un contenu, proposer une structure, mais qui publie, qui valide, qui assume ? Dans un ERP, l'agent peut préparer une commande, détecter une incohérence, proposer une correction, mais qui écrit dans le système, avec quels droits, et sous quel contrôle ?

« Lorsqu’un agent IA est amené à interagir avec des systèmes existants, le sujet n’est plus le modèle mais l’architecture dans laquelle il s’inscrit. La difficulté consiste à maîtriser les points de connexion, les flux et les responsabilités entre l’agent et le SI. Sans cadre clair, on introduit rapidement des composants difficiles à auditer, à sécuriser et à faire évoluer. Chez Eleven Labs, notre agence de développement IA aborde les agents IA comme des composants logiciels à part entière, soumis aux mêmes exigences d’architecture, de gouvernance et de sécurité que le reste du SI. Des mécanismes comme le MCP ne résolvent pas ces enjeux à eux seuls, mais ils permettent de structurer les échanges en séparant l’agent des accès directs au SI, de formaliser les capacités exposées et de réintégrer des pratiques classiques de gouvernance, de sécurité et d’observabilité. C’est une condition nécessaire pour rendre des agents IA réellement industrialisables en production. », Fabien Pasquet Développeur Fullstack Node.js / React chez Eleven Labs.

Le point est important, parce qu'il déplace le débat. Le MCP, justement, s'est imposé comme une tentative de standardisation des connexions entre applications LLM et sources de données ou outils externes, via un protocole et des serveurs dédiés. Autrement dit, il aide à mieux découpler, mais il ne remplace ni la gouvernance des accès, ni la maîtrise des flux, ni les tests, ni l'observabilité. Il remet de l'architecture là où beaucoup de projets bricolent des connecteurs.

Gouvernance, traçabilité, responsabilité, le triptyque qui décide de la survie du projet

Un agent IA pose une question simple et redoutable, qui est responsable. Responsable d'une recommandation fausse, d'une action inadaptée, d'une donnée divulguée, d'un biais, d'une décision automatisée. Dès lors que l'agent dépasse le statut de gadget, la réponse doit être formalisée.

Cette formalisation a un volet juridique, mais aussi un volet d'ingénierie. La traçabilité n'est pas seulement un outil de conformité. C'est un outil de débogage et de confiance. Qui a demandé quoi, sur quelles données, avec quelles permissions, quel outil a été appelé, quelle réponse a été produite, puis utilisée comment.

Sur ces sujets, les recommandations françaises poussent à structurer. La CNIL a publié des recommandations sur l'application du RGPD au développement des systèmes d'IA, avec une attention portée aux responsabilités, aux finalités, à la minimisation, et à la gestion des droits. Dans un projet d'agent, cela se traduit en décisions d'architecture, séparation des environnements, gestion des journaux, contrôle d'accès, conservation, documentation.

C'est aussi le moment où le principe "l'assistant suggère, ne décide pas" cesse d'être une formule. Il devient une règle de design. L'agent peut proposer, préparer, préremplir, expliquer. Il ne franchit pas seul le seuil de l'action irréversible. Ce garde-fou est autant une protection pour l'entreprise qu'un moyen d'obtenir l'adhésion des équipes.

La valeur est dans l'orchestration, pas dans le modèle

On revient alors à l'essentiel. Dans la majorité des cas d'usage, plusieurs modèles feront « à peu près » le travail. Le différentiel se jouera dans la capacité à les faire travailler avec le reste du système. Dans la qualité des outils disponibles. Dans la pertinence du routage, quand utiliser un modèle, quand faire une recherche, quand appeler une base, quand demander une validation... Dans la capacité également à gérer les erreurs, et à rester utile même quand le modèle se trompe.

Dit autrement, beaucoup de risques proviennent de la façon dont on connecte le modèle au monde extérieur et dont on traite ses sorties. Un agent n'est pas « plus intelligent » parce qu'il a un meilleur modèle, il est simple plus fiable parce qu'il a une meilleure architecture.

Run > Build, et la dette cachée des agents

Un agent IA est avant tout un service qui vit dans la durée, et c'est là que les projets se révèlent. Les données changent, les outils évoluent, les droits se modifient, les coûts varient, les prompts dérivent, les usages se déplacent. Aussi, l'agent doit être piloté, mis à jour, observé, et corrigé.

On est plus dans une une culture du run plus que du build.

Elle impose des pratiques classiques, gestion de versions, tests automatisés, environnements de staging, revues de sécurité, monitoring, alerting, etc. Elle impose aussi une discipline budgétaire, avec des risques de déni de service ou d'explosion de coûts qui font partie des catégories explicitement identifiées par l'OWASP pour les applications LLM.

IA et expérience utilisateur, une personnalisation raisonnée

« IA et expérience utilisateur », la formule revient souvent, parfois comme un slogan. Elle recouvre pourtant une question concrète, comment rendre un agent utile sans le rendre intrusif ?

La personnalisation est un levier évident, mais elle doit rester raisonnée. Personnaliser, cela peut vouloir dire adapter les réponses au profil, au rôle, au contexte, à l'historique, au niveau de maturité. Cela peut aussi vouloir dire ajuster l'interface, ce que l'agent propose, quand il le propose, comment il demande une validation, comment il explique une recommandation.

Le risque, ici, n'est pas seulement l'effet « waouh » qui s'éteint, c'est l'opacité. Plus un agent personnalise sans expliquer, plus il perd la confiance. Une architecture bien pensée traite la personnalisation comme une couche contrôlée, avec des sources explicites, des règles, et des limites. Et elle garde l'humain dans la boucle là où les enjeux sont élevés.

Ce guide de Globalis MS peut servir de point d'entrée pour cadrer ces attentes côté métier, en rappelant que l'agent n'est pas un produit magique mais une fonctionnalité qui doit se mesurer à des parcours, des frictions, des validations.

Ce que cela change, concrètement, dans une méthode de cadrage

Déplacer le débat vers l'architecture commence par un cadrage fonctionnel précis, que doit faire l'agent, pour qui, avec quelles limites, avec quels systèmes, avec quels critères de succès. Elle continue par une cartographie des données et des permissions. Elle se traduit ensuite en choix d'architecture, orchestration, connecteurs, sandbox et observabilité. Et elle se termine, non par une mise en ligne, mais par une organisation de run.

C'est aussi ce qui permet de faire un tri utile. Entre un agent qui « répond », et un agent qui « sert ». Entre un prototype qui impressionne et un composant qui tient… y compris quand il se trompe !