Une application Claude peut être techniquement excellente et pourtant être déployée sur la mauvaise plateforme.

Le choix de la plateforme détermine notamment :

l’identité utilisée ;
la facturation ;
le périmètre de compliance ;
la data residency ;
la disponibilité des fonctionnalités ;
les quotas ;
le modèle opérationnel ;
parfois même le cycle de vie des modèles.

La bonne question n’est donc pas :

Quelle plateforme préfère l’équipe ?

mais :

Quelle plateforme satisfait le mieux les requirements du workload ?

C’est une décision de Design.

Claude n’est pas disponible sur une seule plateforme

Aujourd’hui, Claude peut notamment être utilisé via :

la Claude API directe d’Anthropic ;
Claude Platform on AWS, exploitée par Anthropic mais accessible via AWS ;
Claude in Amazon Bedrock, exploitée par AWS ;
Claude sur Google Cloud / Vertex AI ;
d’autres intégrations cloud comme Microsoft Foundry.

Ces offres ne sont pas équivalentes.

Même lorsqu’elles exposent les mêmes modèles Claude, elles peuvent différer sur :

l’API ;
l’IAM ;
le billing ;
les fonctionnalités ;
les régions ;
la data residency ;
le cycle de release.

1. Claude API — accès first-party Anthropic

La Claude API est la plateforme first-party.

L’application appelle directement les endpoints Anthropic.

Le endpoint principal de la Messages API est :

POST /v1/messages

L’authentification et la gestion du compte sont réalisées côté Anthropic.

La documentation actuelle décrit https://api.anthropic.com comme l’API REST directe pour accéder aux modèles Claude.

Pourquoi choisir la Claude API ?

C’est généralement le chemin le plus direct lorsqu’on souhaite :

utiliser les capacités Anthropic sans couche cloud intermédiaire ;
accéder rapidement aux nouvelles fonctionnalités ;
utiliser la surface API native ;
simplifier l’intégration lorsque les contraintes de cloud provider ne sont pas dominantes.

Conceptuellement :

Application
     ↓
Claude API
     ↓
Anthropic-managed infrastructure

L’avantage principal : la surface native Anthropic

La Claude API constitue la référence fonctionnelle.

Lorsqu’une nouvelle capacité Anthropic est disponible, c’est généralement sur les plateformes opérées par Anthropic qu’elle apparaît en premier ou avec la parité la plus forte.

Cela ne signifie pas que les autres plateformes sont mauvaises.

Cela signifie qu’il faut vérifier la feature availability avant de supposer qu’une capacité disponible sur la Claude API existe exactement de la même manière sur Bedrock ou Google Cloud.

2. Claude Platform on AWS

C’est une distinction importante pour l’examen.

Claude Platform on AWS n’est pas Amazon Bedrock.

Claude Platform on AWS permet d’utiliser la plateforme Claude via un compte AWS, mais l’infrastructure d’inférence est exploitée par Anthropic.

AWS fournit notamment :

l’intégration commerciale ;
l’authentification AWS ;
IAM ;
la facturation via AWS Marketplace.

Anthropic reste l’opérateur du service d’inférence et le processeur des données d’inférence.

Architecture simplifiée

Customer AWS Account
       ↓
AWS authentication / IAM
       ↓
Claude Platform on AWS
       ↓
Anthropic-operated inference

C’est donc très différent de :

Customer AWS Account
       ↓
Amazon Bedrock
       ↓
AWS-operated Claude inference

Pourquoi cette distinction compte

Une organisation peut dire :

« Nous devons acheter via AWS. »

Cela ne signifie pas nécessairement :

« AWS doit être l’opérateur des données d’inférence. »

Claude Platform on AWS peut convenir au premier besoin.

Amazon Bedrock peut être nécessaire pour le second.

Anthropic-operated vs AWS-operated

La documentation actuelle distingue clairement :

Plateforme	Opérateur de l’inférence
Claude API	Anthropic
Claude Platform on AWS	Anthropic
Claude in Amazon Bedrock	AWS

Cette différence peut devenir déterminante pour les exigences :

compliance ;
processor/subprocessor ;
audit ;
contractual requirements.

Attention à la data residency

Un point important de la documentation actuelle :

la région AWS utilisée par le workspace ne détermine pas à elle seule l’endroit où l’inférence Claude est exécutée.

Pour Claude Platform on AWS, la localisation d’inférence est gérée par la configuration d’inference_geo lorsque le modèle la supporte.

La documentation actuelle mentionne notamment des géographies US et Global pour cette plateforme.

Donc :

AWS region
≠ automatically
Claude inference residency

C’est exactement le type de détail qu’il faut vérifier pendant la phase Design.

3. Claude in Amazon Bedrock

Amazon Bedrock est l’intégration AWS-native de Claude.

Ici, AWS opère la plateforme.

L’application utilise :

AWS IAM ;
AWS billing ;
les APIs Bedrock ;
les mécanismes de logging et quotas AWS.

Pour les nouvelles intégrations, AWS documente désormais un accès à Claude via une surface Messages API compatible Anthropic sur les endpoints Bedrock.

Deux générations d’intégration Bedrock

Le document de cours distingue utilement deux formes.

Bedrock moderne

Les versions récentes permettent d’utiliser la Messages API Anthropic via Bedrock.

Conceptuellement :

Application
   ↓
Amazon Bedrock endpoint
   ↓
Anthropic Messages API format
   ↓
Claude

AWS recommande actuellement le endpoint bedrock-runtime pour les nouvelles applications.

Bedrock legacy / APIs AWS historiques

Les intégrations plus anciennes peuvent utiliser :

InvokeModel ;
Converse API ;
des model IDs AWS spécifiques.

Ces APIs restent importantes à connaître parce que de nombreux workloads existants les utilisent encore.

IAM et identité

L’un des grands avantages de Bedrock est l’intégration native avec AWS IAM.

Un workload peut utiliser :

Application
   ↓
AWS Role
   ↓
Bedrock
   ↓
Claude

Cela permet d’intégrer Claude dans un système où :

les identities AWS existent déjà ;
les permissions sont gérées via IAM ;
les logs sont centralisés côté AWS.

Bedrock et data residency

Bedrock propose plusieurs mécanismes d’inférence selon les modèles :

in-region ;
geography-scoped ;
global cross-region.

Le choix de l’inference profile a des conséquences directes sur la residency.

AWS précise notamment qu’un profile Global peut router vers différentes régions commerciales, tandis qu’un profile lié à une géographie comme EU conserve les destinations dans cette géographie.

On ne doit donc jamais conclure :

« C’est Bedrock, donc les données restent dans ma région AWS. »

Il faut vérifier l’inference profile réellement utilisé.

Exemple

Conceptuellement :

global.anthropic...

peut permettre un routage global.

Alors que :

eu.anthropic...

exprime un périmètre géographique européen pour les modèles qui proposent ce profile.

Les IDs disponibles dépendent du modèle.

Il faut donc vérifier la fiche du modèle concerné.

4. Claude sur Google Cloud / Vertex AI

Claude est également disponible via Google Cloud.

L’intégration utilise notamment :

Google Cloud identity ;
IAM ;
billing GCP ;
les endpoints Vertex AI ;
le SDK Anthropic compatible Vertex.

Un exemple officiel utilise :

from anthropic import AnthropicVertex

client = AnthropicVertex(
    project_id=PROJECT_ID,
    region="us-east5",
)

Trois stratégies de localisation sur Google Cloud

Google Cloud propose désormais plusieurs niveaux de routage pour Claude :

Regional
Multi-region
Global

Regional endpoint

Un endpoint régional garde le traitement dans une région précise.

Il est particulièrement adapté lorsque :

la residency doit être stricte ;
la latency locale compte ;
l’organisation impose une région donnée.

Global endpoint

Un endpoint global permet à Google de router la requête vers une région disponible.

Avantage :

meilleure capacité globale ;
haute disponibilité.

Inconvénient :

pas de garantie de traitement dans une région précise.

Google recommande donc de ne pas utiliser le global endpoint lorsqu’un requirement impose une localisation stricte du traitement.

Multi-region endpoint

Google a ajouté des endpoints multi-région, notamment pour les géographies US et EU.

Ils représentent un compromis :

Regional
→ strict location / lower routing flexibility

Multi-region
→ routing within one geography

Global
→ maximum routing flexibility

Les endpoints multi-région permettent de conserver le traitement dans une géographie donnée tout en répartissant la charge entre plusieurs régions.

Le choix de plateforme commence par les requirements

Reprenons un workload.

Une banque européenne exige :

Data processing must remain in EU

L’équipe ne doit pas commencer par demander :

« Quelle plateforme connaissons-nous le mieux ? »

Elle doit demander :

Which deployment options
satisfy the EU processing requirement?

Puis comparer uniquement les options qui passent cette gate.

Compliance peut être un PASS/FAIL

C’est un point essentiel.

Supposons :

Plateforme	Latency	Cost	Compliance
A	excellente	faible	FAIL
B	bonne	moyenne	PASS

Si la compliance est obligatoire, la plateforme A est éliminée.

Même si elle est :

moins chère ;
plus rapide ;
plus facile à intégrer.

Le choix n’est donc pas un simple benchmark

On peut représenter la décision ainsi :

Requirements
     ↓
Mandatory constraints
     ↓
Eliminate FAIL platforms
     ↓
Compare remaining options
     ↓
Latency / cost / operations

Cette logique est bien plus robuste qu’un classement général de plateformes.

Comparaison conceptuelle

Critère	Claude API	Claude Platform on AWS	Amazon Bedrock	Google Cloud
Opérateur principal de l’inférence	Anthropic	Anthropic	AWS	Google Cloud / partner platform
Cloud IAM natif	Non AWS/GCP	AWS	AWS	GCP
Billing	Anthropic	AWS Marketplace	AWS	GCP
Surface Claude native	Référence	Très proche / forte parité	À vérifier selon release Bedrock	À vérifier selon release Google
Residency	Selon capacités Anthropic disponibles	`inference_geo` selon support	Region / geo / global profiles	Regional / multi-region / global
Cloud ecosystem	Anthropic	AWS	AWS	GCP

Les détails exacts évoluent : une décision de production doit toujours être validée contre la documentation actuelle.

Pourquoi feature parity doit être vérifiée

Une équipe peut écrire une application directement avec la Claude API et supposer :

« Nous pourrons la déplacer sur Bedrock sans aucune différence. »

C’est dangereux.

Les plateformes peuvent différer sur :

beta features ;
endpoints ;
SDK clients ;
model IDs ;
quotas ;
timing des releases ;
lifecycle.

La documentation Anthropic recommande explicitement de consulter les pages spécifiques à chaque plateforme pour confirmer la disponibilité des fonctionnalités.

Model IDs : pin what ships

Le choix de plateforme ne suffit pas.

Il faut également savoir quelle version exacte du modèle part en production.

Principe :

Pin what ships.

Le format actuel des model IDs

La documentation Anthropic actuelle distingue deux générations.

Claude 4.6 et versions ultérieures

Depuis la génération Claude 4.6, les model IDs utilisent un format sans date.

Par exemple, conceptuellement :

claude-{name}-{major}-{minor}

ou pour certaines major versions :

claude-{name}-{major}

Anthropic précise qu’un model ID identifie une version pinée et stable pendant la durée de vie de cet ID.

C’est important :

absence de date ne signifie plus nécessairement alias mouvant.

Avant Claude 4.6

Les modèles antérieurs utilisent généralement un snapshot daté.

Format Claude API :

claude-{name}-{major}-{minor}-{YYYYMMDD}

Sur Google Cloud, les anciens snapshots utilisent notamment :

claude-{name}-{major}-{minor}@YYYYMMDD

Sur Bedrock :

anthropic.claude-{name}-{major}-{minor}-{YYYYMMDD}-v1:0

Alias vs pinned model ID

Pour certains anciens modèles, Anthropic propose des aliases courts.

Exemple conceptuel :

claude-sonnet-x-y

qui peut pointer vers un snapshot correspondant.

Pour une production où la reproductibilité compte, le principe du module reste :

privilégier une référence dont le comportement est explicitement piné.

Pourquoi pinning est important

Sans pinning clair :

Application
   ↓
Model reference
   ↓
Underlying model changes
   ↓
Behavior may change

Avec pinning :

Application
   ↓
Pinned model ID
   ↓
Known model behavior

Cela améliore :

reproductibilité ;
debugging ;
evals ;
audit ;
rollback.

Versionner plus que le modèle

Un système Claude ne dépend pas seulement du modèle.

Il dépend aussi de :

prompt ;
tool schemas ;
agent logic ;
eval dataset ;
configuration ;
application code.

La vraie version de production ressemble donc davantage à :

Release 2.4
│
├── model ID
├── prompt version
├── tool schemas
├── agent code
├── configuration
└── eval baseline

Garder la version précédente

Une stratégie de déploiement robuste conserve également la version précédente.

Current production
      ↓
Version N

Candidate
      ↓
Version N+1
      ↓
Eval

Si la candidate régresse :

rollback → Version N

Attention au lifecycle des modèles

Le lifecycle peut également varier selon la plateforme.

Anthropic précise actuellement que les dates de dépréciation publiées par Anthropic s’appliquent aux plateformes opérées par Anthropic, tandis que les plateformes opérées par des partenaires comme Amazon Bedrock et Google Cloud peuvent définir leurs propres calendriers de retirement.

C’est une information importante pour la production.

Ne supposez pas :

Same model
=
Same retirement date everywhere

Exemple de décision de plateforme

Prenons trois workloads.

Workload A — SaaS généraliste

Requirements :

No mandatory cloud provider
Need latest Claude capabilities
Simple operational model

Une option naturelle à évaluer :

Claude API directe.

Workload B — entreprise fortement AWS

Requirements :

AWS IAM
AWS billing
AWS-native compliance controls
AWS-operated inference required

Une option logique à évaluer :

Claude in Amazon Bedrock.

Workload C — entreprise utilisant AWS Marketplace mais souhaitant la plateforme Anthropic

Requirements :

AWS procurement
AWS IAM integration
Anthropic-operated Claude platform
Latest Claude API capabilities

Une option possible :

Claude Platform on AWS.

Workload D — organisation standardisée sur GCP

Requirements :

GCP IAM
GCP billing
EU processing requirement
Need geographic redundancy

Une option possible à évaluer :

Claude sur Google Cloud avec un endpoint multi-région EU, si le modèle concerné le supporte.

Ne jamais choisir sur un slogan

Les mauvaises décisions ressemblent souvent à :

« Bedrock est plus sécurisé. »

« La Claude API est plus rapide. »

« Vertex est meilleur pour l’Europe. »

Ces affirmations sont trop générales.

La bonne approche consiste à mesurer et vérifier :

Specific workload
+
Specific region
+
Specific model
+
Specific endpoint
+
Specific compliance requirement

Principe → Exemple → Erreur fréquente → Bonne pratique

Principe

Choisir la plateforme à partir des infrastructure requirements, pas de la familiarité de l’équipe.

Exemple

Requirement :

AWS must operate inference

Conséquence :

évaluer Amazon Bedrock plutôt que Claude Platform on AWS.

Erreur fréquente

Voir « AWS » dans les deux noms et considérer les deux offres comme équivalentes.

Bonne pratique

Identifier :

operator
identity
billing
residency
feature support
model lifecycle

avant la décision.

Ce qu’il faut retenir pour l’examen

Plusieurs distinctions sont particulièrement importantes.

1. Claude Platform on AWS ≠ Amazon Bedrock

Claude Platform on AWS
→ Anthropic-operated

Amazon Bedrock
→ AWS-operated

2. Cloud region ≠ automatiquement inference residency

Il faut examiner :

inference_geo ;
regional endpoint ;
geo profile ;
global profile ;
multi-region endpoint.

3. Compliance peut éliminer une plateforme

Si une contrainte obligatoire échoue :

FAIL

on ne compense pas avec :

prix ;
latency ;
facilité de développement.

4. Feature parity n’est pas automatique

Toujours vérifier la documentation de la plateforme cible.

5. Pin what ships

La référence modèle en production doit être identifiable et reproductible.

6. Les model IDs ont évolué

Pour l’examen et la production :

Claude 4.6+
→ dateless model IDs can themselves be pinned IDs

Older generations
→ dated snapshots commonly used

Ne mémorisez donc pas la vieille règle :

« un ID sans date est forcément un alias mouvant ».

Elle n’est plus correcte pour les générations modernes.

Pièges d’examen

Proposition	Analyse
« Utiliser AWS signifie que l’inférence est opérée par AWS »	Faux : Claude Platform on AWS est opérée par Anthropic
« La région AWS garantit automatiquement la residency Claude »	Faux
« Le global endpoint maximise généralement la flexibilité de routage »	Oui
« Un global endpoint convient à une residency régionale stricte »	Généralement non
« Feature availability est identique partout »	Faux
« Claude 4.6+ nécessite obligatoirement une date dans l’ID pour être piné »	Faux
« Le lifecycle d’un modèle est toujours identique entre Anthropic, Bedrock et Google Cloud »	Faux

Fiche rapide

Concept	À retenir	Exemple	Piège
Claude API	First-party Anthropic	`/v1/messages`	Supposer cloud IAM
Claude Platform on AWS	AWS access, Anthropic-operated inference	IAM + AWS Marketplace	Confondre avec Bedrock
Amazon Bedrock	AWS-operated	AWS IAM	Supposer même features partout
Google Cloud	GCP integration	`AnthropicVertex`	Confondre global et regional
Regional endpoint	Location stricte	région précise	Moins de flexibilité
Multi-region	Routing dans une géographie	EU	Confondre avec global
Global endpoint	Maximum routing flexibility	global profile	Mauvais pour residency stricte
Model pinning	Identifier exactement ce qui part	stable model ID	Alias mouvant
Lifecycle	Dépend de la plateforme	retirement schedule	Supposer dates identiques

À retenir en une phrase

Le choix de la plateforme Claude est une décision de design guidée par l’identité, la compliance, la data residency, la latency, le coût et la disponibilité des fonctionnalités ; une fois la plateforme choisie, il faut pin et versionner précisément ce qui part en production afin de rendre le système reproductible, testable et rollbackable.

Explorer le phare info

📌 Contexte

📊 Les stratégies de greenwashing

1. Techniques utilisées par les multinationales

2. Exemples concrets de greenwashing

3. Les conséquences pour les consommateurs et l’environnement

⚠️ Décryptage des biais

🚀 Quelles solutions pour lutter contre le greenwashing ?

📝 Conclusion

Où déployer Claude ? API Anthropic, Claude Platform on AWS, Amazon Bedrock et Google Cloud

Claude n’est pas disponible sur une seule plateforme

1. Claude API — accès first-party Anthropic

Pourquoi choisir la Claude API ?

L’avantage principal : la surface native Anthropic

2. Claude Platform on AWS

Architecture simplifiée

Pourquoi cette distinction compte

Anthropic-operated vs AWS-operated

Attention à la data residency

3. Claude in Amazon Bedrock

Deux générations d’intégration Bedrock

Bedrock moderne

Bedrock legacy / APIs AWS historiques

IAM et identité

Bedrock et data residency

Exemple

4. Claude sur Google Cloud / Vertex AI

Trois stratégies de localisation sur Google Cloud

Regional endpoint

Global endpoint

Multi-region endpoint

Le choix de plateforme commence par les requirements

Compliance peut être un PASS/FAIL

Le choix n’est donc pas un simple benchmark

Comparaison conceptuelle

Pourquoi feature parity doit être vérifiée

Model IDs : pin what ships

Le format actuel des model IDs

Claude 4.6 et versions ultérieures

Avant Claude 4.6

Alias vs pinned model ID

Pourquoi pinning est important

Versionner plus que le modèle

Garder la version précédente

Attention au lifecycle des modèles

Exemple de décision de plateforme

Workload A — SaaS généraliste

Workload B — entreprise fortement AWS

Workload C — entreprise utilisant AWS Marketplace mais souhaitant la plateforme Anthropic

Workload D — organisation standardisée sur GCP

Ne jamais choisir sur un slogan

Principe → Exemple → Erreur fréquente → Bonne pratique

Principe

Exemple

Erreur fréquente

Bonne pratique

Ce qu’il faut retenir pour l’examen

1. Claude Platform on AWS ≠ Amazon Bedrock

2. Cloud region ≠ automatiquement inference residency

3. Compliance peut éliminer une plateforme

4. Feature parity n’est pas automatique

5. Pin what ships

6. Les model IDs ont évolué

Pièges d’examen

Fiche rapide

À retenir en une phrase

LAISSER UN COMMENTAIRE Annuler la réponse

Articles liés

Le sentier du savoir