La rivalité entre Amazon et Google Cloud s’intensifie alors qu’AWS GovCloud ajoute plusieurs modèles d’IA

Amazon a étendu AWS GovCloud avec six familles de modèles d’IA nommées le 30 août, remettant en cause les stratégies fondées sur un modèle unique sur le marché fédéral du cloud. La compétition entre Amazon et Google dépasse désormais les capacités d’infrastructure. Elle porte de plus en plus sur le fournisseur qui offre aux agences la voie la plus crédible et la plus large pour déployer une IA réglementée.

AWS affirme que les clients gouvernementaux peuvent accéder à Amazon Nova, Anthropic Claude, Meta Llama, Nvidia Nemotron, aux modèles OpenAI et à xAI Grok via Amazon Bedrock. L’entreprise promet également l’accès à d’autres modèles de pointe à mesure que son catalogue s’étoffe. Google Gemini en est visiblement absent, car il reste au cœur de la stratégie concurrente de Google Cloud pour l’IA gouvernementale.

Cette annonce est importante, car les acheteurs fédéraux choisissent rarement un modèle sur la seule base des résultats de benchmarks. Les périmètres d’autorisation, la résidence des données, les contrôles sur le personnel, les règles de passation des marchés et les contrats cloud existants déterminent ce que les équipes peuvent déployer. AWS parie que le choix des modèles au sein d’un environnement contrôlé l’emportera sur la fidélité à un seul développeur d’IA.

Cette stratégie met Google et Microsoft sous pression de façons différentes. Google positionne Gemini for Government comme une plateforme intégrée construite autour de ses modèles et de sa technologie d’agents. Microsoft propose des modèles OpenAI et des services dédiés au secteur public via Azure. AWS se présente comme une place de marché neutre pour les modèles, tout en promouvant sa propre famille Nova.

La compétition entre Amazon et Google porte désormais sur l’accès aux modèles

AWS a fait de la diversité des modèles un argument central de vente pour le cloud gouvernemental, et non plus une fonctionnalité secondaire destinée aux développeurs.

L’annonce du 30 août sur le choix des modèles indique que plusieurs familles de modèles sont désormais disponibles via Amazon Bedrock dans AWS GovCloud. Bedrock est le service géré d’AWS permettant de créer des applications avec des modèles fondamentaux grâce à des interfaces communes et à des outils de support.

L’annonce cite Amazon Nova, Anthropic Claude, Meta Llama, Nvidia Nemotron, les modèles OpenAI et xAI Grok. Elle évoque aussi d’autres modèles de pointe sans identifier chaque offre. Les agences doivent néanmoins consulter la documentation actuelle relative à l’accès aux modèles afin de confirmer la disponibilité exacte selon les régions et les exigences de conformité.

Il ne s’agit pas seulement d’un catalogue plus vaste. AWS souhaite que les agences considèrent le modèle comme un composant remplaçable au sein d’une architecture cloud plus large. Une équipe pourrait tester plusieurs modèles sur une même charge de travail sans déplacer l’intégralité de son application vers un autre fournisseur.

Cette structure répond à un cas d’usage gouvernemental concret. Un modèle léger pourrait classifier les documents entrants, tandis qu’un modèle de raisonnement analyserait des dossiers complexes. Un autre modèle pourrait générer ou réviser du code. Bedrock offre à ces composants une couche d’accès commune dans l’environnement AWS.

L’architecture réduit également la dépendance au cycle de publication d’un seul développeur de modèles. Si un fournisseur retire une version, modifie son comportement ou devient moins performant sur une tâche précise, une agence dispose d’alternatives. La substitution de modèles exige toutefois toujours des tests, car les résultats, les comportements de sécurité, les limites de contexte et la prise en charge des outils diffèrent.

AWS décrit ce changement comme faisant partie de son engagement à investir jusqu’à 50 milliards de dollars dans des infrastructures d’IA et de calcul haute performance destinées au gouvernement des États-Unis. Cet engagement donne à l’annonce du catalogue une portée concurrentielle plus large. AWS n’ajoute pas simplement des endpoints ; l’entreprise protège sa position à mesure que les agences augmentent leurs dépenses en IA.

La rivalité entre Amazon et Google devient plus claire à travers une omission. Gemini ne figure pas parmi les familles de modèles Bedrock nommées dans AWS GovCloud. Google se retrouve donc en concurrence avec une plateforme capable de réunir plusieurs grands développeurs de modèles tout en excluant son modèle propriétaire le plus important.

Pour les responsables technologiques du secteur public, cela soulève une nouvelle question d’achat. Ils doivent déterminer si la diversité des modèles au sein d’AWS offre davantage de flexibilité stratégique qu’une intégration plus poussée de Gemini sur Google Cloud. La réponse variera selon la mission, l’architecture existante et le périmètre d’autorisation.

Pourquoi le choix des modèles est devenu une exigence opérationnelle

L’argument le plus solide en faveur de plusieurs modèles repose sur la continuité opérationnelle, même si AWS doit encore voir cette promesse validée par ses clients en production.

Les modèles fondamentaux ne sont pas aussi performants pour toutes les tâches. L’un peut bien traiter de longs documents, tandis qu’un autre produit un meilleur code ou des classifications avec une latence plus faible. Les charges de travail gouvernementales accentuent ces différences, car les erreurs peuvent affecter les prestations, les enquêtes, la cybersécurité ou les services publics.

AWS cite l’adéquation entre modèles et tâches comme l’une des raisons de l’élargissement du catalogue. Les agences peuvent évaluer les modèles à partir de leurs propres données et exigences, au lieu de sélectionner un fournisseur sur la base de benchmarks publics. C’est important, car les scores de benchmarks généraux reflètent rarement les documents, la terminologie ou la tolérance au risque d’une agence.

La maîtrise des coûts est un autre facteur, même lorsque les agences évitent de publier les dépenses par modèle. Utiliser le plus grand modèle pour chaque requête peut gaspiller des ressources de calcul. Un système de routage peut envoyer les demandes simples vers des modèles plus petits et réserver le raisonnement avancé aux tâches difficiles.

Cette approche sous-tend les agents multimodèles. Un agent d’IA est un logiciel qui planifie des étapes, appelle des outils et agit vers un objectif défini. Un modèle de routage peut classifier les requêtes avant d’envoyer certaines tâches vers des modèles spécialisés ou des systèmes gouvernementaux.

Prenons un flux de travail de cybersécurité au sein d’un sous-traitant de la défense. Un modèle pourrait catégoriser les alertes, un autre résumer les éléments de preuve, et un modèle axé sur le code proposer un correctif. Des examinateurs humains conserveraient le contrôle de l’exécution, mais le système ne dépendrait pas d’un seul modèle à chaque étape.

Le même schéma pourrait soutenir des activités civiles riches en documents. Une agence pourrait utiliser un modèle pour la classification des dossiers et un autre pour l’analyse des politiques publiques. Elle pourrait ensuite comparer les résultats lorsqu’une décision comporte un risque juridique ou opérationnel inhabituel.

Une API commune simplifie la couche d’ingénierie, mais elle ne rend pas les modèles interchangeables. Les formats de prompts, les paramètres pris en charge, l’appel d’outils, les filtres de sécurité et les limites de tokens peuvent varier. Les équipes ont toujours besoin de suites d’évaluation et de logique de repli pour chaque modèle mis en service.

Les achats restent également plus complexes qu’un simple changement d’endpoint. AWS soutient qu’un service unifié peut réduire l’intégration de fournisseurs distincts et les besoins de réarchitecture. Les agences doivent néanmoins vérifier si chaque modèle et chaque fonctionnalité se trouvent dans le périmètre d’autorisation exigé pour une charge de travail donnée.

Le choix des modèles apporte donc sa plus grande valeur lorsque les agences conçoivent dès le départ pour la substitution. Une application étroitement couplée peut tirer peu de bénéfices d’un vaste catalogue. Une application modulaire peut comparer les modèles, router les charges de travail et remplacer les composants peu performants avec moins de perturbations.

C’est pourquoi cette annonce crée une pression qui dépasse les fournisseurs de modèles. Les intégrateurs de systèmes et les éditeurs de logiciels doivent prouver que leurs applications peuvent utiliser plusieurs modèles en toute sécurité. Les acheteurs remettront de plus en plus en question les architectures qui ne fonctionnent qu’avec l’interface propriétaire d’un seul fournisseur.

AWS vend la neutralité tout en promouvant Amazon Nova

La tension centrale consiste à savoir si AWS peut rester un courtier de modèles de confiance tout en concurrençant les fournisseurs présents dans son propre catalogue.

Amazon Bedrock présente des modèles de plusieurs entreprises via un seul service géré. Ce positionnement permet à AWS de mettre l’accent sur le choix du client plutôt que d’affirmer que Nova doit traiter toutes les charges de travail. Il offre aussi aux développeurs de modèles un accès à des clients déjà engagés dans l’infrastructure AWS.

AWS possède toutefois la plateforme, la relation commerciale et la famille de modèles Nova. L’entreprise contrôle la manière dont les services apparaissent dans sa console, sa documentation, ses outils d’évaluation et ses architectures de référence. Cela crée une incitation structurelle à favoriser ses modèles par rapport aux fournisseurs externes.

Les acheteurs gouvernementaux ont déjà observé des dynamiques similaires sur les places de marché cloud. Une plateforme peut prendre en charge des produits tiers tout en utilisant l’activité de cette place de marché pour renforcer ses propres services. La préoccupation n’est pas nécessairement qu’AWS restreindra ses concurrents. Elle tient au fait que la neutralité doit être démontrée par des conditions et des comportements observables.

La disponibilité des modèles fournit un premier test. AWS indique que les clients peuvent modifier un endpoint et des profils d’accès pour passer d’un modèle pris en charge à un autre. Les acheteurs devraient vérifier que les quotas, la couverture fonctionnelle, la latence et le calendrier des mises à jour restent comparables entre fournisseurs.

Les outils d’évaluation fournissent un autre test. Un processus de comparaison neutre devrait permettre aux agences de définir des mesures propres à leur mission et d’examiner les échecs. Il ne devrait pas réduire la sélection d’un modèle à des scores génériques ou à des benchmarks choisis par les fournisseurs.

La gestion des données est tout aussi importante. AWS affirme que les données clients ne sont pas utilisées pour entraîner ou améliorer les modèles disponibles. Les agences devraient confirmer comment cette promesse s’applique aux prompts, aux résultats, aux journaux, aux enregistrements d’évaluation et à chaque intégration activée.

Une question de continuité se pose également. Un catalogue réduit la dépendance à un fournisseur de modèles, mais accroît la dépendance au courtier. Les agences utilisant les API Bedrock, les garde-fous, les agents et les fonctionnalités de base de connaissances peuvent avoir du mal à quitter AWS, même lorsque le changement de modèle devient plus simple.

C’est le paradoxe qui se cache derrière l’argument du choix. AWS peut réduire le verrouillage lié aux modèles tout en renforçant le verrouillage lié à la plateforme. Le modèle devient plus portable au sein de Bedrock, mais l’application qui l’entoure peut se trouver davantage attachée aux services AWS.

Cela n’efface pas la valeur du catalogue. Cela change la façon dont les acheteurs devraient mesurer cette valeur. La comparaison pertinente ne porte pas sur un modèle face à un autre. Elle concerne l’architecture complète de l’application, y compris l’identité, les données, l’orchestration, la supervision, les contrôles de sécurité et les options de sortie.

Un processus d’achat bien conçu devrait donc demander des éléments probants pour les deux formes de portabilité. Les équipes doivent savoir avec quelle facilité elles peuvent remplacer un modèle au sein d’AWS. Elles doivent également comprendre ce qu’exigerait le déplacement de l’application au-delà de Bedrock.

La concurrence entre Amazon et Google s’inscrit dans cette distinction. Google peut faire valoir qu’une pile Gemini intégrée réduit la complexité opérationnelle. AWS peut affirmer que son catalogue plus large préserve le choix. Aucune de ces promesses ne supprime la dépendance ; chacune la place à un niveau différent.

Google et Microsoft font face à des pressions de nature différente

Google doit défendre une stratégie Gemini intégrée, tandis que Microsoft doit montrer qu’Azure Government peut égaler l’étendue et la flexibilité opérationnelle d’AWS.

Google a construit sa position en matière d’IA fédérale autour de Gemini, d’outils de productivité et d’une plateforme d’agents en expansion. Ses conseils de déploiement gouvernemental indiquent que Gemini for Government peut prendre en charge des déploiements FedRAMP High et DoD Impact Level 4 via des environnements Assured Workloads configurés.

Cette position en matière d’autorisation est significative. Google a également annoncé l’autorisation FedRAMP High pour Gemini dans les applications Workspace et l’application Gemini en 2025. Ces produits ciblent la collaboration et la productivité des employés, tandis que l’annonce d’AWS se concentre sur la création d’applications personnalisées via Bedrock.

Cette distinction donne à Google un récit cohérent. Les agences peuvent utiliser Gemini dans le développement cloud, la recherche d’entreprise, les agents et les logiciels de productivité. Une intégration profonde peut réduire le nombre d’interfaces que les équipes de sécurité et d’exploitation doivent gérer.

Pourtant, l’intégration peut devenir une faiblesse lorsque les acheteurs souhaitent des modèles indépendants. Si une agence décide que Claude, un modèle OpenAI ou un modèle à poids ouverts est plus performant, AWS propose un accès direct via son catalogue. Google doit déterminer si les avantages d’intégration de Gemini compensent cette faculté de choix.

Google pourrait réagir en élargissant l’accès aux modèles tiers, en renforçant l’interopérabilité ou en améliorant suffisamment Gemini pour que les agences acceptent une stratégie plus concentrée. L’entreprise pourrait également mettre en avant les domaines où elle maîtrise davantage la pile technologique, notamment la recherche, l’analytique de données, la productivité et le développement de modèles.

Microsoft fait face à un défi différent. Azure Government fournit déjà des modèles OpenAI et d’autres services d’IA par l’intermédiaire de Microsoft Foundry. Son catalogue de modèles gouvernementaux documente les différences régionales et de déploiement des modèles pris en charge.

Microsoft bénéficie également de l’utilisation existante, par les agences, de Microsoft 365, des services d’identité, des outils de développement et d’Azure. Ces relations peuvent faciliter l’introduction de ses services d’IA dans des flux de travail établis. Toutefois, la disponibilité des fonctionnalités dans Azure Government ne correspond pas toujours à celle du cloud commercial.

La documentation de Microsoft illustre cet écart. Son environnement Foundry gouvernemental prend en charge plusieurs fonctionnalités d’entreprise, mais certaines capacités d’évaluation et d’optimisation restent indisponibles. Les différences entre modèles et fonctionnalités peuvent influer sur la rapidité avec laquelle une agence passe de l’expérimentation à un système de production autorisé.

AWS exploite précisément cette préoccupation. Son argumentaire affirme que les agences ne devraient pas attendre un seul modèle, une seule feuille de route fonctionnelle ou un seul fournisseur. Les équipes devraient plutôt s’appuyer sur un catalogue qui évolue à mesure que de nouveaux modèles deviennent éligibles aux environnements réglementés.

Cependant, la taille d’un catalogue ne peut à elle seule trancher la concurrence. Les clients gouvernementaux se soucient des preuves d’autorisation, des coûts d’intégration, du support, des conditions contractuelles et des performances du système. Un modèle théoriquement disponible offre une valeur limitée si des quotas ou des fonctionnalités manquantes empêchent son utilisation en production.

La prochaine phase de la rivalité entre Amazon et Google dépendra donc de la disponibilité réellement exploitable. Les acheteurs compareront les modèles exécutables dans quelles régions, sous quels contrôles et avec quels services de support. Les listes marketing compteront moins que les preuves de production.

L’héritage de conformité n’élimine pas le risque pour les agences

AWS GovCloud peut fournir des contrôles réutilisables, mais ne peut pas autoriser le système d’IA complet d’une agence ni valider chaque décision générée par un modèle.

AWS décrit GovCloud comme une infrastructure isolée destinée aux charges de travail gouvernementales sensibles. Son annonce cite la résidence des données aux États-Unis, l’exploitation par du personnel américain qualifié, le chiffrement, l’isolation matérielle et plusieurs programmes de conformité.

L’entreprise affirme que les charges de travail d’IA couvertes peuvent hériter de l’autorisation FedRAMP d’AWS GovCloud. Cet héritage peut réduire la duplication du travail d’évaluation, car les agences réutilisent des contrôles déjà mis en œuvre et évalués au niveau du service cloud.

Cela ne signifie pas qu’une agence reçoit automatiquement une autorisation d’exploitation. Les orientations d’autorisation fédérales indiquent que les agences autorisent toujours leurs propres systèmes d’information. Les responsables doivent évaluer les informations traitées, la configuration choisie, les intégrations et les contrôles exploités par le client.

Le propre modèle de responsabilité d’AWS établit une distinction similaire. AWS sécurise le cloud sous-jacent, tandis que les clients restent responsables des données, des autorisations, du comportement des applications et de la configuration propre à la charge de travail.

Cette distinction devient cruciale pour l’IA générative. Un point de terminaison d’inférence conforme ne garantit pas qu’une application produise des résultats exacts, équitables ou juridiquement valides. Il ne détermine pas non plus si un jeu de données particulier doit être transmis à un modèle.

Les agences doivent tester les hallucinations, c’est-à-dire des sorties de modèle plausibles mais non étayées. Elles ont également besoin de contrôles contre l’injection de prompts, l’utilisation non autorisée d’outils, l’exposition de données sensibles et des autorisations utilisateur excessives. Ces risques apparaissent dans la couche applicative, et pas seulement dans l’infrastructure cloud.

Une supervision humaine reste nécessaire pour les décisions importantes. Un modèle peut résumer des éléments de preuve ou suggérer une action, mais l’agence doit décider à quel moment une personne examine le résultat. Elle doit aussi conserver les dossiers appropriés et expliquer comment une sortie a influencé une décision.

Les systèmes multimodèles ajoutent une complexité supplémentaire. Chaque modèle peut réagir différemment à une même politique de sécurité. Les mises à jour peuvent modifier les schémas de sortie sans changer l’application environnante. L’évaluation doit donc se poursuivre après le déploiement.

AWS propose Bedrock Guardrails pour le filtrage de contenu, les contrôles des informations sensibles et les restrictions par sujet. Ces contrôles peuvent soutenir la politique d’une agence, mais ne remplacent pas les tests spécifiques à la mission. Un filtre réglé pour un chatbot destiné aux citoyens peut ne pas convenir à l’analyse du renseignement ou à la réponse aux incidents.

L’annonce formule également plusieurs affirmations nécessitant une validation attentive. AWS indique qu’aucun opérateur ne peut accéder aux prompts, aux complétions ou aux poids des modèles pendant l’inférence. Les clients devraient consulter la documentation technique et les documents d’autorisation applicables à leurs services et configurations exacts.

La publication détaillée d’AWS donne une autre raison de rester prudent. Son introduction cite Meta Llama parmi les familles disponibles, mais le résumé numéroté ultérieur des modèles ne consacre pas d’entrée distincte à Llama. Cette incohérence éditoriale ne prouve pas une lacune de service, mais elle renforce la nécessité de consulter les registres de disponibilité en temps réel.

De même, l’expression « modèles frontier supplémentaires » ne désigne ni produits ni dates précis. Les agences devraient la considérer comme un signal de feuille de route, et non comme une disponibilité actuelle. Les documents d’approvisionnement devraient nommer les modèles, versions, régions, fonctionnalités et niveaux de conformité requis.

La plus grande question non résolue concerne les performances dans des conditions gouvernementales réelles. AWS fournit des exemples portant sur la classification de capteurs, l’évaluation des menaces, l’examen de documents et le déploiement de correctifs. Il s’agit de scénarios illustratifs, et non de déploiements d’agences vérifiés indépendamment et décrits dans l’annonce.

Les acheteurs devraient demander des preuves propres à chaque charge de travail. Cela comprend l’exactitude sur des données représentatives, la latence de réponse, les taux d’échec, les procédures de mise à jour des modèles, le comportement de repli et les exigences de revue humaine. Sans ces mesures, le choix du modèle demeure une affirmation de capacité plutôt qu’un résultat de mission.

Trois signaux montreront si la stratégie fonctionne

AWS doit désormais prouver qu’un vaste catalogue permet des déploiements plus rapides et plus sûrs, plutôt que des évaluations et une gouvernance plus complexes.

Le premier signal est la disponibilité de production documentée. Les agences devraient surveiller les versions exactes des modèles, la prise en charge régionale, les quotas et les correspondances de conformité dans AWS GovCloud. Davantage de modèles nommés ne renforceront l’argument de marché d’AWS que lorsque les clients pourront les utiliser sous les contrôles requis.

Un écart croissant entre les annonces et la documentation affaiblirait cet argument. Les équipes gouvernementales ne peuvent pas fonder des systèmes autorisés sur une promesse générale de modèles futurs. Elles ont besoin d’identifiants stables, de calendriers de support et de politiques de retrait claires.

Le deuxième signal est la preuve de déploiements multimodèles réels. L’affirmation la plus forte d’AWS concerne les applications qui orientent différentes tâches vers différents modèles. Les études de cas publiques devraient expliquer pourquoi les équipes ont choisi chaque modèle et comment l’architecture a fonctionné après le déploiement.

Des éléments probants utiles incluraient les méthodes d’évaluation, la fiabilité opérationnelle et des réductions mesurables du travail de migration. Des témoignages génériques ne suffiront pas à déterminer si la variété des modèles améliore les résultats. Les acheteurs ont besoin d’exemples liés à de véritables flux de travail gouvernementaux ou de la base industrielle.

Ce signal met également à l’épreuve les intégrateurs de systèmes. Les prestataires qui vantent la flexibilité multimodèle devraient démontrer des chemins de repli fonctionnels et une évaluation reproductible. Ils devraient montrer que le remplacement de modèles ne compromet pas les contrôles de sécurité, la journalisation ou les hypothèses d’autorisation.

Le troisième signal est la réponse concurrentielle de Google et Microsoft. La réponse de Google compte le plus, car Gemini ne semble pas figurer dans le catalogue AWS annoncé. Tout élargissement des choix tiers dans l’environnement gouvernemental de Google remettrait directement en cause l’avantage de neutralité d’AWS.

À l’inverse, Google pourrait renforcer son intégration. L’entreprise pourrait connecter Gemini plus profondément aux services de recherche, de données, d’espace de travail et d’agents autorisés. Une forte adoption suggérerait que les agences accordent davantage de valeur à une pile unifiée qu’à un vaste menu de modèles.

La réponse de Microsoft montrera si AWS peut revendiquer durablement cette étendue. De nouveaux modèles, une parité avec les régions gouvernementales ou des fonctionnalités d’évaluation élargies dans Foundry réduiraient l’écart. Des lancements lents dans le cloud gouvernemental renforceraient l’argument d’AWS en faveur de l’indépendance vis-à-vis des feuilles de route.

Les lecteurs devraient également surveiller la manière dont les fournisseurs parlent de conformité. Des données d’autorisation plus claires au niveau des modèles renforceraient les trois plateformes. Les déclarations vagues qui présentent l’autorisation du cloud comme une approbation complète de l’application devraient susciter un examen attentif.

Pour les développeurs, la leçon immédiate est architecturale. Intégrez l’évaluation et l’abstraction dans l’application avant de sélectionner un modèle par défaut permanent. Consignez pourquoi un modèle traite chaque tâche, quelles données il reçoit et ce qui se passe lorsqu’il échoue.

Pour les acheteurs d’entreprise, la leçon est contractuelle. Exigez la transparence des versions, un préavis de retrait, des options d’exportation et des preuves pour chaque affirmation de conformité. L’accès aux modèles n’est utile que lorsque les conditions d’exploitation assurent la continuité.

Les travailleurs du savoir constateront les conséquences par l’intermédiaire des services gouvernementaux et des prestataires réglementés. Une meilleure adéquation des modèles peut améliorer l’analyse de documents, la gestion des dossiers, la cybersécurité et la recherche interne. Une gouvernance insuffisante peut diffuser des réponses incohérentes dans des systèmes qui semblent tout aussi autorisés.

Les équipes qui construisent leur propre base de preuves peuvent tenir une base de connaissances IA consultable pour les résultats d’évaluation, les décisions de politique et les changements de modèles. Cette trace devient plus importante à mesure que les applications combinent plusieurs fournisseurs.

La compétition entre Amazon et Google ne sera pas décidée par la plus longue liste de modèles. Elle dépendra de la capacité des agences à changer de modèles sans perdre en sécurité, en fiabilité ou en contrôle. Surveillez les catalogues en temps réel, les études de cas de production et les lancements concurrents dans les clouds gouvernementaux. Ces signaux montreront si le choix des modèles est devenu un avantage de mission ou une couche supplémentaire de dépendance aux plateformes.