L'IA agentique en entreprise : comment éviter l'enfermement technologique ?

Les équipes de machine learning (ML) dans les grandes entreprises doivent aujourd'hui faire fonctionner des systèmes d'IA agentique dans un environnement « multi-tout » : plusieurs cadres de travail, modèles et fournisseurs cohabitent, chacun évoluant à son propre rythme. La question n'est plus de savoir comment orchestrer des agents dans un seul système, mais comment faire coexister de nombreux systèmes différents sans perdre le contrôle.

L'IA AGENTIQUE À GRANDE ÉCHELLE : UN DÉFI DE TAILLE

Dans un premier article de cette série, nous avions exploré comment optimiser le comportement des agents au sein d'un système unique. Mais à l'échelle d'une entreprise, le problème change radicalement. L'option n'est plus une simple question d'expérimentation : elle devient une contrainte à gérer délibérément. Les tentatives pour imposer une standardisation au niveau des cadres de travail ou des modèles créent souvent des frictions. Les équipes contournent les restrictions, l'adoption ralentit, ou les systèmes divergent hors des architectures approuvées. À l'inverse, lier trop étroitement les applications à des modèles ou fournisseurs spécifiques limite la capacité à s'adapter quand le paysage évolue.

POURQUOI LES ENTREPRISES DEVIENNENT-ELLES HÉTÉROGÈNES PAR DÉFAUT ?

Les équipes adoptent des cadres de travail différents selon leurs besoins. Certaines privilégient les workflows structurés, d'autres se concentrent sur les interactions collaboratives entre agents, et d'autres encore optimisent des pipelines déterministes pilotés par des modèles. En parallèle, les organisations combinent des agents personnalisés avec des capacités de type SaaS et des systèmes existants. Le niveau des modèles ajoute une autre dimension de variabilité : les modèles de fondation (FM) évoluent rapidement, chacun offrant différents compromis en termes de coût, de latence et de capacité. Résultat, la plupart des entreprises utilisent plusieurs fournisseurs de modèles plutôt que de se standardiser sur une seule option.

Avec le temps, cette diversité conduit à une situation stable : des systèmes utilisant plusieurs modèles, plusieurs cadres de travail et plusieurs fournisseurs, opérés par différentes équipes et pour divers cas d'usage. Le défi n'est pas d'éviter cette situation, mais de la gérer sans introduire de fragmentation.

LES PIÈGES D'UNE GESTION FRAGMENTÉE

À mesure que les systèmes gagnent en diversité, un ensemble prévisible de défis émerge. La gouvernance devient difficile à appliquer de manière cohérente dans des cadres de travail qui définissent chacun leurs propres modèles de contrôle. La complexité d'intégration augmente car les agents, Outils et services exposent des interfaces incompatibles. Les compromis entre coût et performance deviennent plus difficiles à gérer sans optimisation dynamique, ce qui conduit souvent à une utilisation inefficace des ressources.

Parallèlement, les frontières de sécurité s'étendent à mesure que les agents interagissent dynamiquement avec des outils, des données et d'autres agents, rendant les schémas d'accès moins prévisibles. La mémoire persistante ajoute une complexité supplémentaire autour de la rétention des données, de l'isolation et de la cohérence. Enfin, les cas d'usage en entreprise exigent des performances spécifiques à un domaine qui ne peuvent pas être atteintes par des configurations génériques seules.

Ces défis sont interconnectés et s'aggravent avec le temps. Les gérer nécessite une approche systémique plutôt que des solutions isolées.

LES PRINCIPES ARCHITECTURAUX POUR MAÎTRISER LA COMPLEXITÉ

Les organisations qui réussissent dans des environnements « multi-tout » convergent vers un ensemble de principes architecturaux qui équilibrent flexibilité et contrôle. Un principe fondamental est la séparation des plans de contrôle et d'exécution. L'identité, l'application des politiques, l'observabilité et l'attribution des coûts sont centralisées pour faciliter la cohérence dans toute l'entreprise, tandis que l'exécution et le développement des agents restent décentralisés pour soutenir l'autonomie des équipes et la scalabilité.

L'observabilité devient une condition préalable pour faire fonctionner ces systèmes efficacement. En établissant une couche de télémétrie unifiée, les organisations obtiennent une visibilité sur le comportement des agents dans tous les cadres de travail et environnements. Cette visibilité les aide à surveiller les performances, tracer les échecs et améliorer continuellement le système sans dépendre d'outils spécifiques à un cadre.

LE ROUTAGE DYNAMIQUE : UNE FONCTION CLÉ POUR L'ÉVOLUTION

À mesure que les charges de travail se diversifient, le routage devient une fonction centrale du système. Plutôt que d'assigner statiquement des modèles ou des infrastructures, les organisations font correspondre dynamiquement les tâches aux ressources en fonction des exigences de coût, de latence et de précision. Cela aide le système à s'adapter en temps réel et à maintenir son efficacité à grande échelle.

Les systèmes de production doivent également être conçus avec des garanties explicites. Les exigences en matière de latence, de disponibilité et d'isolation doivent être clairement définies, ainsi que les mécanismes pour gérer les défaillances. Les réessais, les disjoncteurs et les chemins de repli facilitent la résilience dans des conditions réelles.

De nombreuses organisations commencent avec des modèles d'orchestration centralisés pour maintenir une visibilité et un contrôle sur les interactions des agents. À mesure que les systèmes grandissent, elles évoluent vers des architectures plus distribuées et pilotées par des événements, qui offrent une plus grande scalabilité tout en préservant la cohérence.

L'OPTIMISATION : UNE PRIORITÉ DÈS LE DÉBUT

Enfin, l'optimisation doit être intégrée au système dès le départ. Les considérations de coût et de performance sont fondamentales pour fonctionner à grande échelle. Des techniques comme la sélection dynamique de modèles, la mise en cache et des schémas d'exécution efficaces aident à faciliter l'efficacité à long terme.

Ensemble, ces principes fournissent un cadre pratique pour gérer la complexité inhérente des environnements « multi-tout ».

LES BLOCS DE CONSTRUCTION POUR UNE PLATEFORME AGNOSTIQUE

Les principes architecturaux décrits précédemment nécessitent des capacités qui fonctionnent de manière cohérente dans tous les cadres de travail, modèles et équipes. Les services AWS fournissent ces blocs de construction que les organisations peuvent utiliser pour implémenter une plateforme agnostique tout en préservant la flexibilité.

À grande échelle, le niveau des modèles devient l'une des principales sources de complexité. Différents cas d'usage nécessitent des modèles différents, des stratégies de personnalisation et des schémas d'inférence.

Amazon SageMaker sert de couche centrale d'exécution et de personnalisation pour gérer cette complexité à grande échelle. Il fournit une couche unifiée pour le développement, l'affinage, le déploiement et l'inférence des modèles, permettant aux organisations de standardiser la manière dont les modèles sont construits et opérés dans toute l'entreprise. En prenant en charge l'inférence en temps réel, asynchrone et par lots, ainsi que des capacités telles que les composants d'inférence et la surveillance des modèles, Amazon SageMaker aide les équipes à aligner l'infrastructure sur les exigences des charges de travail. Cela maintient un modèle opérationnel cohérent dans toute l'entreprise.

Amazon SageMaker permet également de personnaliser les modèles à grande échelle tout en offrant une flexibilité dans le choix des infrastructures et des cadres de travail. Les équipes peuvent ainsi adapter les modèles à leurs besoins spécifiques sans être limitées par les contraintes d'un fournisseur unique.

ACCESSIBILITÉ RAPIDE AUX MODÈLES : AMAZON BEDROCK

Complémentairement, Amazon Bedrock fournit une interface simplifiée et gérée pour accéder aux modèles de fondation, prenant en charge l'expérimentation rapide sans gérer l'infrastructure sous-jacente. Si Amazon Bedrock accélère l'accès et l'intégration des modèles, Amazon SageMaker apporte la profondeur, le contrôle et la scalabilité nécessaires pour la personnalisation et l'inférence de niveau production. Ensemble, ils permettent aux organisations de séparer l'accès aux modèles de l'exécution des modèles, soutenant ainsi des architectures flexibles et résilientes.

ORCHESTRATION ET CONTRÔLE : LES OUTILS AWS

L'orchestration et le contrôle sont implémentés via des services comme AWS Lambda, AWS Step Functions et Amazon API Gateway, qui prennent en charge le routage dynamique et la coordination des workflows. Des capacités émergentes comme l'orchestration d'agents sur AWS étendent davantage cette couche. Elles fournissent des abstractions spécialement conçues pour l'orchestration d'agents qui aident les équipes à gérer des workflows multi-agents complexes avec une plus grande cohérence et un meilleur contrôle.

L'identité et la gouvernance restent centralisées via AWS Identity and Access Management (IAM) et AWS Organizations, tandis que l'observabilité est standardisée avec Amazon CloudWatch et AWS X-Ray. Amazon EventBridge, Amazon ElastiCache et Amazon CloudFront prennent en charge l'intégration et l'optimisation des performances.

LE SAVOIR-FAIRE CLÉ : UNE ARCHITECTURE FLEXIBLE SANS VERROUILLAGE

Amazon SageMaker fournit le socle opérationnel pour la personnalisation et l'inférence des modèles à grande échelle, tandis qu'Amazon Bedrock prend en charge l'accès rapide aux modèles de fondation gérés. Ensemble, ils soutiennent des architectures flexibles et agnostiques des cadres de travail à l'échelle de l'entreprise.

Le tableau suivant résume comment ces principes architecturaux s'intègrent aux services natifs AWS qui prennent en charge une scalabilité agnostique des cadres de travail.

LES PATRONS ARCHITECTURAUX POUR LES ENTREPRISES

Lorsque ces principes sont appliqués, les organisations convergent généralement vers un petit nombre de patrons architecturaux. Ces patrons ne sont pas prescriptifs. Ils reflètent comment les équipes structurent les systèmes d'agents en fonction des exigences des charges de travail et des contraintes opérationnelles.

Il est important de noter que ces patrons ne sont pas mutuellement exclusifs. La plupart des entreprises implémentent une combinaison de ceux-ci dans différentes unités commerciales et cas d'usage. Le défi n'est pas de sélectionner un seul patron, mais de les faire coexister dans un environnement partagé.

LE PATRON DE LA PLATEFORME AGENT INTERNE

Un point de départ courant est la plateforme agent interne, qui émerge lorsque plusieurs équipes commencent à construire des agents indépendamment. Avec le temps, cela peut conduire à une infrastructure dupliquée, à une gouvernance incohérente et à une réutilisation limitée dans toute l'organisation.

Pour remédier à cela, les organisations introduisent un modèle de plateforme centralisée ou hybride. Une couche de plateforme partagée fournit des capacités communes telles que l'accès aux modèles, la gouvernance, l'observabilité et la gestion des coûts, tandis que les équipes individuelles conservent l'autonomie sur la manière dont elles construisent et déploient leurs agents.

Dans ce modèle, la plateforme agit comme un plan de contrôle, standardisant la manière dont les agents accèdent aux modèles, appliquent les politiques et émettent des télémétries. En même temps, l'exécution reste décentralisée. Les unités commerciales continuent de posséder leur logique applicative, leurs intégrations de données, leurs pipelines CI/CD et leurs choix de cadres de travail.

Cette séparation réduit la duplication et impose une cohérence sans contraindre l'innovation, tout en prenant également en charge la réutilisation des capacités communes dans plusieurs cas d'usage.

QUAND LES AGENTS SONT EXPOSÉS À L'EXTERNE : LE PATRON MULTI-LOCATAIRES

Lorsque les agents sont exposés à l'extérieur, les priorités architecturales se déplacent vers la multi-locataire, l'isolation et la fiabilité. Dans ce patron, les systèmes sont conçus pour imposer des limites de locataire fortes. Chaque requête transporte le contexte du locataire dans tout le système, garantissant que les agents n'accèdent qu'aux données et outils spécifiques à ce locataire. L'identité et la gestion des accès deviennent des préoccupations centrales, s'intégrant souvent avec des fournisseurs d'identité externes tout en maintenant une application cohérente au sein de la plateforme.

Les décisions d'infrastructure évoluent également. De nombreuses organisations adoptent des modèles de locataire hybrides, combinant une infrastructure partagée pour les charges de travail standard avec des environnements dédiés pour les clients ayant des exigences réglementaires ou de performance plus strictes. Cette approche équilibre l'efficacité des coûts avec le besoin d'isolation et de conformité.

La fiabilité est une caractéristique définissante de ce patron. Les systèmes doivent répondre à des attentes explicites en matière de latence, de disponibilité et de débit, même sous des charges de travail inégales. En conséquence, des mécanismes de résilience tels que la bascule, la limitation du débit et la dégradation gracieuse deviennent des capacités centrales de la plateforme.

LE PATRON POUR LES SYSTÈMES EN TEMPS RÉEL : LATENCE ET OPTIMISATION

Pour les systèmes en temps réel, la latence devient la contrainte architecturale dominante. Les applications telles que les assistants conversationnels et les workflows interactifs nécessitent des réponses dans des limites de temps serrées, où les retards impactent directement l'expérience utilisateur.

Dans ces environnements, l'optimisation doit être conçue dans le système dès le départ. Les décisions de routage sont dynamiques, évaluant chaque requête en fonction de la complexité, de la sensibilité à la latence et des considérations de coût. Ce routage sélectionne le modèle et le niveau d'infrastructure le plus approprié en temps réel.

Les stratégies d'exécution évoluent également pour prendre en charge le parallélisme, permettant aux opérations indépendantes de s'exécuter simultanément et de réduire le temps de réponse global. La mise en cache joue un rôle critique en réduisant les calculs redondants et en améliorant à la fois la latence et l'efficacité des coûts.

Ce patron met l'accent sur l'optimisation au niveau du système, où la performance est traitée comme une contrainte de conception primaire plutôt que comme une réflexion après coup.

POURQUOI UNE PLATEFORME UNIFIÉE EST INDISPENSABLE

Chacun de ces patrons répond à un ensemble spécifique d'exigences. Cependant, dans un environnement « multi-tout », ils existent rarement de manière isolée. Les entreprises exécutent souvent simultanément des agents d'automatisation internes, des systèmes destinés aux clients et des applications en temps réel. Ces systèmes sont fréquemment construits par différentes équipes utilisant différents cadres de travail et modèles.

Sans une base partagée, ces patrons peuvent devenir cloisonnés. La gouvernance diverge, les intégrations se multiplient et les efforts d'optimisation sont dupliqués entre les systèmes.

La plateforme agent unifiée relève ce défi en fournissant un ensemble commun de capacités qui se situent sous les patrons individuels. Elle standardise les préoccupations transversales telles que l'identité, l'application des politiques, l'observabilité et le routage, tout en permettant à chaque système d'évoluer indépendamment.

Cette distinction est importante. Les patrons décrivent comment les systèmes d'agents sont structurés pour des charges de travail spécifiques. La plateforme garantit que ces systèmes peuvent évoluer ensemble dans le cadre d'une architecture d'entreprise cohérente.

DE L'ORCHESTRATION SIMPLE À LA GESTION D'ENTREPRISE

Dans la première partie de cette série, nous nous étions concentrés sur l'orchestration multi-agents au sein d'un seul cas d'usage, où plusieurs agents sont nécessaires pour gérer la complexité au sein d'un domaine défini.

Dans cet article, nous avons élargi la portée à l'entreprise, où le défi devient de gérer de nombreux systèmes similaires dans un environnement « multi-tout ».

Les organisations qui réussissent ne sont pas celles qui éliminent la complexité, mais celles qui la structurent. En standardisant les couches de contrôle critiques telles que l'identité, les politiques, l'observabilité et le routage, tout en préservant la flexibilité dans l'exécution, elles peuvent faire fonctionner des systèmes hétérogènes sans perdre le contrôle.

ET APRÈS ?

Les prochains articles de cette série exploreront comment les équipes de plateforme ML peuvent évoluer pour passer du soutien d'un seul cas d'usage métier à l'exploitation d'une plateforme agent partagée à l'échelle de l'entreprise. Nous couvrirons les abstractions, les modèles de gouvernance et les services partagés qui permettent aux équipes individuelles de conserver leur flexibilité à mesure que l'adoption grandit.