OneAdvanced a construit une plateforme d’IA souveraine britannique exécutant plus de 50 agents spécialisés sur une infrastructure hébergée dans la région AWS de Londres, selon une étude de cas du blog AWS Machine Learning. L’éditeur britannique de logiciels d’entreprise a auto-hébergé Llama 4 Maverick et Llama Guard 4 de Meta après que les modèles n’étaient pas disponibles via les services AWS gérés qu’il souhaitait utiliser dans la région.

Le déploiement est conçu pour les clients de OneAdvanced dans des secteurs réglementés tels que la santé et les services juridiques, où la résidence des données est une exigence centrale en matière d’achat et de conformité. Son architecture combine Amazon SageMaker AI pour la diffusion des modèles, Amazon ECS pour les charges de travail des agents, et un système de récupération basé sur Amazon Aurora PostgreSQL-Compatible Edition avec pgvector.

Le projet illustre un compromis pratique pour les équipes d’IA d’entreprise : les services de modèles gérés peuvent accélérer l’expérimentation, mais les exigences de souveraineté peuvent obliger les clients à exploiter eux-mêmes les modèles, les GPU, l’orchestration, les contrôles de sécurité et les pipelines de données.

Du prototype Bedrock aux modèles auto-hébergés

OneAdvanced a d’abord prototypé ses capacités d’IA avec Amazon Bedrock. AWS indique que l’entreprise a produit en deux semaines un sprint fonctionnel couvrant la complétion de chat, un agent pour interroger le droit statutaire du Royaume-Uni, l’intégration Snowflake et la génération de graphiques.

Cette approche ne satisfaisait pas l’exigence de l’entreprise selon laquelle les modèles devaient s’exécuter exclusivement dans ses propres comptes AWS basés au Royaume-Uni. Au moment de l’engagement décrit par AWS, Llama 4 Maverick et Llama Guard 4 n’étaient pas disponibles via les services gérés concernés dans la région britannique. OneAdvanced est donc passé à une conception auto-hébergée utilisant une infrastructure britannique qu’il pouvait contrôler directement.

La plateforme AWS souveraine britannique qui en résulte sert Llama 4 Maverick et Llama Guard 4 via vLLM sur des endpoints Amazon SageMaker AI. Les modèles s’exécutent sur des instances p5.48xlarge dans la région de Londres, en utilisant des modèles Hugging Face et AWS Deep Learning Containers. AWS indique que OneAdvanced utilisait initialement des instances p4d.24xlarge avant de passer au matériel P5 pour la production et des exigences de contexte plus longues.

L’entreprise vise des fenêtres de contexte d’environ 120 000 à 128 000 jetons pour l’analyse de grands documents et les conversations à plusieurs tours. AWS rapporte que les tests de charge menés pendant son accompagnement ont validé les exigences de débit, bien que l’étude de cas ne fournisse pas de chiffres sur la latence, le volume de requêtes, la disponibilité ou les coûts.

Comment fonctionne la plateforme d’agents

La couche d’agents principale se compose de plus de 50 agents spécialisés par tâche, construits avec le SDK Strands Agents et déployés sur Amazon ECS. Chaque agent possède son propre prompt système et sa propre configuration d’outils, tandis que des formulaires de saisie optionnels aident les utilisateurs qui ne souhaitent pas interagir via une interface de chat ouverte. La configuration des agents est stockée dans Amazon DynamoDB.

AWS indique que OneAdvanced est passé de son premier agent à plus de 50 en trois semaines, la plupart des agents ayant été créés en moins d’une journée. La bibliothèque couvre des domaines tels que la santé, le travail juridique, les ressources humaines, le marketing, la logistique et l’éducation. Parmi les exemples cités par AWS figurent un assistant de réponse aux incidents de soins, un générateur de bulletins de sécurité clinique, un outil de comparaison de documents, un assistant d’évaluation des performances et un AWS Architect Agent.

Le flux de travail commence lorsque Llama Guard 4 contrôle la requête d’un utilisateur pour y détecter du contenu nuisible. Si la requête passe le filtre, elle est acheminée vers l’agent approprié sur Amazon ECS. L’agent peut appeler des outils spécialisés, récupérer des informations pertinentes à partir de documents stockés dans Amazon S3 et interroger un index vectoriel alimenté par pgvector.

Les documents téléversés dans S3 sont convertis en Markdown, découpés en fragments et vectorisés pour la récupération. Cette couche de génération augmentée par récupération, ou RAG, vise à maintenir les réponses ancrées dans les propres matériaux d’une organisation plutôt que de s’appuyer uniquement sur la connaissance interne du modèle.

Ce que les preuves montrent — et ce qu’elles ne montrent pas

Le compte rendu technique détaillé provient d’AWS, qui a conseillé OneAdvanced et publié l’architecture sous forme d’étude de cas client. Les affirmations les plus fortes sur l’adoption et la rapidité — y compris l’ampleur de la bibliothèque d’agents, la période de construction de trois semaines et l’affirmation selon laquelle la plupart des agents ont pris moins d’une journée — sont donc rapportées par le fournisseur et non auditées de manière indépendante.

La même réserve s’applique aux résultats de tests de charge rapportés. AWS indique que le déploiement a satisfait aux exigences de débit de OneAdvanced, mais la source ne divulgue pas la méthodologie de test, le profil de trafic, les objectifs de temps de réponse, les taux d’échec ou l’utilisation en production. Elle n’indique pas non plus combien des plus de 50 agents sont utilisés activement par les clients ni ne fournit de ventilation de leur impact commercial.

Le résultat en matière de souveraineté est plus concret en tant que description architecturale. AWS indique que la solution conserve l’hébergement des modèles et les données clients dans l’environnement britannique et a aidé à soutenir la certification ISO 42001 de OneAdvanced pour la gouvernance de l’IA. Cela ne doit pas être interprété comme une preuve que chaque obligation de conformité en aval est automatiquement satisfaite : la résidence, le contrôle d’accès, la conservation, l’auditabilité et la gouvernance des fournisseurs dépendent toujours de la manière dont le service complet est configuré et exploité.

Le CTO de OneAdvanced, Andrew Henderson, a décrit la souveraineté des données britanniques comme une exigence incontournable pour de nombreux clients du secteur public et des secteurs réglementés. Cette justification exécutive explique le choix de conception central, mais elle reste une position de l’entreprise plutôt qu’une évaluation indépendante de la posture de conformité de la plateforme.

Pourquoi ce déploiement compte pour les créateurs d’IA

Pour les équipes produit, le cas met en lumière le coût d’ingénierie caché derrière une exigence aussi simple que « garder les données dans le pays ». Lorsque les modèles souhaités ne sont pas disponibles dans un catalogue local de services gérés, les équipes peuvent devoir obtenir des licences de modèles, sécuriser une capacité GPU rare, déployer des serveurs d’inférence, mettre en œuvre la mise à l’échelle et maintenir elles-mêmes les couches de sécurité et de récupération.

L’architecture sépare aussi des responsabilités souvent regroupées dans une API d’IA hébergée. SageMaker AI gère les endpoints des modèles, ECS exécute les agents et les outils, S3 stocke les documents sources, Aurora PostgreSQL fournit la base de données vectorielle et DynamoDB stocke la configuration des agents. Cette modularité donne du contrôle à OneAdvanced, mais elle crée davantage d’interfaces opérationnelles à surveiller, sécuriser et dépanner.

Le passage de Llama Guard 3 à Llama Guard 4 est un autre signal pratique. AWS indique que OneAdvanced a constaté des taux élevés de faux rejets avec le modèle précédent et l’a remplacé. Le filtrage séquentiel des requêtes avant le modèle principal peut réduire certains risques, mais il ajoute aussi une porte qui doit être testée pour les faux positifs, les faux négatifs, la latence et la couverture linguistique ou sectorielle.

Pour les acheteurs d’entreprise, le nombre d’agents importe moins que le modèle de gouvernance qui le sous-tend. Une bibliothèque de 50 agents peut faciliter la mise en paquet de flux de travail spécialisés, mais chaque agent introduit des prompts, des outils, des autorisations, des sources de récupération et potentiellement des modes de défaillance différents. Un générateur d’agents sans code peut élargir l’accès aux utilisateurs non techniques, tout en augmentant le besoin de workflows d’approbation, de tests, de contrôle de version et de supervision de l’utilisation.

Ce qu’il faut surveiller ensuite

Les prochains signaux utiles seront opérationnels plutôt que le simple nombre d’agents en gros titres. OneAdvanced pourrait divulguer l’utilisation en production, les objectifs de temps de réponse et de fiabilité, l’utilisation des GPU ou la différence de coût entre l’auto-hébergement et l’inférence gérée. Ces chiffres aideraient les acheteurs à évaluer si la souveraineté justifiait la charge d’infrastructure supplémentaire.

Il vaut aussi la peine de surveiller si les modèles Llama concernés deviennent disponibles via des services AWS gérés au Royaume-Uni et si cela modifie l’architecture de OneAdvanced. Une option gérée locale pourrait réduire la maintenance de la plateforme tout en préservant les exigences de résidence, même si l’entreprise pourrait conserver l’auto-hébergement pour garder le contrôle des versions et de la configuration des modèles.

Des preuves supplémentaires devraient aussi montrer comment les agents sont gouvernés après le déploiement : qui peut publier de nouveaux outils, comment les sources de récupération sont approuvées, comment les décisions relatives au contenu nuisible sont auditées, et si les processus ISO 42001 couvrent l’ensemble du cycle de vie des agents. Ces détails compteront davantage pour les clients réglementés que la vitesse du prototype initial.

Perspective Creati.ai

Le déploiement de OneAdvanced est remarquable non pas parce que « 50 agents » serait une mesure universelle de maturité de l’IA, mais parce qu’il expose la frontière pratique entre une démo d’IA et une plateforme d’entreprise souveraine. L’entreprise a utilisé des services gérés pour l’expérimentation initiale, puis a accepté la complexité opérationnelle de l’auto-hébergement lorsque la disponibilité régionale des modèles ne correspondait pas à ses exigences en matière de données.

Pour les bâtisseurs, la leçon est de considérer la résidence, la disponibilité des modèles, le filtrage de sécurité, la qualité de la récupération et l’économie des GPU comme une seule décision d’architecture. Pour les acheteurs, le compte rendu d’AWS constitue une preuve utile d’un schéma viable, mais les métriques de production manquantes signifient qu’il doit être évalué comme un plan de mise en œuvre — et non encore comme une référence validée indépendamment.