API directe, Bedrock, Vertex ou Foundry : par où faire entrer Claude dans l’entreprise ?

Le canal d’accès à Claude se choisit sur trois critères : qui est le sous-traitant de vos données (Anthropic ou l’hyperscaler), où l’inférence peut être contenue (l’API directe ne propose pas de géographie européenne, Bedrock et Google Cloud si, Foundry pas encore), et quelles fonctionnalités arrivent en premier (l’API directe). Le contrat cloud déjà signé tranche le reste.

En 2026, les portes ne sont plus trois mais cinq. À l’API d’Anthropic, Amazon Bedrock et Google Cloud se sont ajoutés Claude Platform on AWS (disponibilité générale le 11 mai 2026) et Microsoft Foundry (le 5 juillet 2026). Ce choix engage toute l’architecture Claude : il se prend au cadrage.

Qui traite vos données ? La question que les comparatifs oublient

Sur Amazon Bedrock, c’est AWS qui opère la pile d’inférence et qui est le sous-traitant de vos entrées et sorties ; Anthropic ne les conserve pas, et son programme de rétention zéro n’a tout simplement pas lieu de s’y appliquer. Sur l’API directe, Claude Platform on AWS et Microsoft Foundry, Anthropic reste le sous-traitant, sous ses propres conditions d’utilisation des données. Sur Google Cloud, ce sont les conditions de service de Google qui s’appliquent, avec leur clause de restriction d’entraînement.

La distinction n’est pas théorique. Elle décide du contrat de sous-traitance à examiner, de la ligne à inscrire au registre des traitements et de la manière d’obtenir une rétention zéro : de fait sur Bedrock, sur demande et après éligibilité partout où Anthropic est le sous-traitant. C’est l’angle à instruire en premier pour un déploiement de Claude conforme au RGPD.

Nuance récente : sur Claude Platform on AWS, Anthropic traite le contenu sur l’infrastructure AWS pour les espaces de travail créés à partir du 18 septembre 2026, et possiblement hors d’AWS pour les plus anciens. Hébergeur et sous-traitant ne sont donc pas toujours la même entité.

Où l’inférence peut-elle être contenue ?

Sur l’API directe, le paramètre de géographie d’inférence n’accepte que « global » et « États-Unis », et la géographie de stockage d’un espace de travail ne connaît que les États-Unis. Aucune option Union européenne, et épingler l’inférence aux États-Unis est facturé 1,1 fois le tarif standard. Claude Platform on AWS reprend ces deux géographies : la région AWS choisie fixe où vivent IAM, CloudTrail et la facture, pas où tourne le modèle.

Amazon Bedrock est le canal le plus précis sur ce point. Un profil d’inférence géographique garde les requêtes à l’intérieur d’une zone (États-Unis, Union européenne, Asie-Pacifique), AWS s’engage à ne jamais en modifier la liste des régions de destination, et CloudTrail consigne la région qui a servi chaque requête. Le profil global, lui, coûte environ 10 % de moins : chez AWS comme chez Anthropic, contenir la géographie vaut à peu près un dixième du prix.

Sur Google Cloud, les modèles Claude disposent de points d’accès multirégionaux, dont un pour l’Union européenne, en disponibilité générale depuis le 15 mai 2026 ; détail dans notre comparaison entre Claude et Gemini sur la même plateforme Google. Microsoft Foundry ne connaît que deux types de déploiement, Global Standard et zone de données États-Unis : aucune zone de données européenne n’existe à ce jour, la page de conformité régionale d’Anthropic l’annonçant seulement comme à venir.

Quelles fonctionnalités arrivent en premier, et lesquelles manquent ?

L’API directe reçoit tout en premier : Agent Skills, agents managés, exécution de code, traitement par lots et fonctionnalités bêta. Claude Platform on AWS expose la même API, en-têtes bêta compris, avec l’authentification IAM et l’audit CloudTrail ; il lui manque le mode rapide et OAuth, et la rétention zéro y est à activer explicitement.

Amazon Bedrock n’accepte pas les en-têtes bêta et ne propose pas les Agent Skills, qui exigent l’exécution de code côté Anthropic. En contrepartie, il s’intègre à ce que votre équipe cloud sait déjà faire : politiques IAM et de contrôle de service pour borner les régions, points de terminaison privés, journalisation.

Sur Microsoft Foundry, les déploiements hébergés sur Azure n’offrent ni exécution de code, ni Agent Skills, ni API de fichiers, ni traitement par lots. Claude Code fonctionne sur les cinq canaux, détecte ces limites, et ses paramètres gérés permettent de restreindre les fournisseurs autorisés sur un parc de postes.

Comment chaque canal se facture et s’achète-t-il ?

Le critère le moins technique est souvent le plus décisif : faut-il référencer un nouveau fournisseur ?

• API directe : facture Anthropic, paiement à l’usage, tarif par million de tokens.
• Claude Platform on AWS : mêmes tarifs, via AWS Marketplace sur la facture AWS ; les paliers d’usage montent avec l’historique de factures.
• Amazon Bedrock : facture AWS, prix calculé sur la région d’appel, profil global environ 10 % moins cher que le profil géographique.
• Google Cloud : facture et engagements Google Cloud, sous le contrat déjà négocié par la DSI.
• Microsoft Foundry : Azure Marketplace, unités de consommation Claude facturées mensuellement à terme échu, sans prépaiement, éligibles aux engagements de consommation Azure.

La règle de décision que nous appliquons

Quatre situations couvrent la quasi-totalité des cadrages que nous menons.

• Traitement imposé en Union européenne (clause client, secteur régulé) : Bedrock avec un profil géographique UE, ou Google Cloud avec le point d’accès européen. API directe, Claude Platform on AWS et Foundry sont exclus pour l’instant.
• Besoin des fonctionnalités de dernière génération, Skills et agents managés en tête : l’API directe, ou Claude Platform on AWS si la dépense doit passer par AWS, en acceptant un traitement global ou américain.
• Exigence que l’hyperscaler soit le seul sous-traitant : Bedrock ou Google Cloud, qui opèrent eux-mêmes l’inférence.
• Déjà sur Azure, sans contrainte européenne : Foundry hébergé sur Azure, après vérification que les fonctionnalités absentes ne figurent pas au cahier des charges.

Deux canaux derrière une passerelle, le complet pour le développement et le contenu pour la production, forment une configuration courante. Elle ne reste saine qu’avec une seule couche d’évaluations, de garde-fous et de connecteurs, celle du harness d’entreprise, indépendante des deux.

Prochaine étape : trancher au cadrage, pièces en main

La décision tient en trois pièces à réunir avant la première ligne de code : les contrats cloud en vigueur, les clauses de localisation imposées par vos clients ou votre régulateur, et la liste des fonctionnalités que le cas d’usage exige vraiment. Avec elles, le canal se déduit en une réunion ; sans elles, il se rediscute à chaque revue de sécurité.

C’est l’objet d’un cadrage d’architecture : poser ce choix une fois, le documenter, et bâtir dessus la couche qui vous appartient. Pour le mener avec un consultant Claude qui a déjà instruit ces arbitrages, c’est par là que nous commençons.