Amazon Bedrock pour les PME : cas d'usage rentables et coûts à anticiper

Amazon Bedrock a franchi un cap en 2026 : catalogue élargi (Nova 2, modèles Anthropic les plus récents, et depuis cette année des modèles OpenAI disponibles nativement sur la plateforme), AgentCore pour orchestrer des agents en production, S3 Vectors en disponibilité générale depuis décembre 2025. Sur le papier, une PME peut lancer un chatbot RAG ou un pipeline de résumé documentaire en quelques jours.

Le problème n’est pas la techno — elle fonctionne. Le problème est que la facture Bedrock ne ressemble à aucune facture AWS habituelle : elle mélange tokens consommés, infrastructure vectorielle facturée à l’heure qu’on l’utilise ou pas, et une demi-douzaine de composants annexes qu’on découvre au premier relevé. C’est exactement ce qu’on audite en mission Audit IA & Bedrock : la question n’est jamais « est-ce que ça marche techniquement », mais « est-ce que ce cas d’usage reste rentable une fois la facture réelle sur la table ».

Les cas d’usage qui sont réellement rentables pour une PME

Tous les cas d’usage GenAI ne se valent pas économiquement. Sur les missions qu’on mène, trois patterns reviennent avec un ROI net positif :

• Extraction et résumé de documents en volume (contrats, factures, tickets support archivés). Traitement asynchrone, pas de contrainte de latence temps réel : c’est le candidat idéal pour l’inférence par batch, facturée 50 % moins cher que l’on-demand. Un cabinet qui traite 2 000 contrats/mois avec Claude Haiku en batch paie une fraction du coût d’un traitement synchrone équivalent.
• Support client augmenté sur base de connaissance interne (RAG sur documentation produit, FAQ, procédures). Le gain business est mesurable (temps de résolution, taux d’escalade), mais c’est aussi le cas d’usage où le coût d’infrastructure explose le plus facilement — détail plus bas.
• Recherche interne et copilotes métier (chat sur wiki d’entreprise, extraction depuis SharePoint/Salesforce via les connecteurs Knowledge Bases). Volume faible, valeur perçue élevée, bon candidat pour justifier un premier déploiement Bedrock avant d’étendre.

À l’inverse, un cas d’usage de génération de contenu ponctuelle et à faible volume (brouillons marketing, reformulation) n’a souvent aucune raison de passer par l’infrastructure Bedrock complète : un appel direct à l’API du modèle, sans Knowledge Base ni Guardrails, coûte moins cher et se met en place en une heure. C’est le même arbitrage « payer un tiers vs rester simple » qu’on applique partout ailleurs en FinOps : ne montez l’infrastructure managée que quand le volume la justifie.

Comment Bedrock facture réellement

Trois modes de facturation coexistent, et le choix du bon mode est le premier levier d’optimisation :

Sur les tarifs on-demand actuels, les écarts entre familles de modèles sont considérables — et c’est souvent là que se joue la rentabilité d’un cas d’usage :

• Amazon Nova (le moins cher) : Micro à environ 0,035 $ / 0,14 $ par million de tokens (entrée/sortie), Lite à 0,06 $ / 0,24 $, Pro à 0,80 $ / 3,20 $.
• Claude sur Bedrock : Haiku autour de 1 $ / 5 $ par million de tokens, Sonnet autour de 3 $ / 15 $, Opus autour de 5 $ / 25 $ — mêmes tarifs que l’API Anthropic directe, Bedrock n’ajoute pas de marge sur le token.

Ordre de grandeur utile : un résumé de contrat de 3 pages (≈ 4 000 tokens en entrée, 500 en sortie) traité avec Nova Lite coûte une fraction de centime ; le même traitement avec Claude Opus coûte environ 30 fois plus cher au token. Sur 2 000 documents/mois, l’écart de choix de modèle pèse largement plus que l’écart batch/on-demand — inutile d’optimiser le mode de facturation avant d’avoir choisi le bon modèle pour la tâche.

Le prompt caching (mise en cache du contexte répété — system prompt, documents de référence réutilisés d’un appel à l’autre) apporte une réduction additionnelle pouvant aller jusqu’à 90 % sur les tokens d’entrée mis en cache. Pertinent dès qu’un même contexte volumineux (base de connaissance, instructions longues) sert à plusieurs requêtes successives.

Le piège n°1 : le coût plancher des Knowledge Bases

C’est le point que la documentation Bedrock ne met pas en avant, et celui qu’on retrouve le plus souvent en audit : créer une Knowledge Base Bedrock pour du RAG provisionne par défaut une collection Amazon OpenSearch Serverless comme vector store — et cette collection est facturée à l’heure, indépendamment du trafic.

Le minimum technique est de 2 OCU (OpenSearch Compute Units) à 0,24 $/heure chacune, soit environ 345 €/mois de plancher — même à zéro requête. En configuration recommandée pour un usage production (4 OCU), on passe à environ 690 €/mois. Pour une PME qui veut tester un chatbot RAG sur quelques milliers de documents, ce plancher dépasse souvent le coût des tokens eux-mêmes sur plusieurs mois.

Deux points à vérifier systématiquement en mission :

1. Supprimer une Knowledge Base ne supprime pas la collection OpenSearch Serverless sous-jacente. Elle continue à facturer indéfiniment tant qu’elle n’est pas supprimée manuellement — dans un autre écran de la console. C’est la cause la plus fréquente de « ligne fantôme » qu’on retrouve sur les factures Bedrock en audit.
2. S3 Vectors, disponible en GA depuis décembre 2025, est désormais l’alternative par défaut à considérer. Jusqu’à 90 % moins cher qu’OpenSearch Serverless pour un usage RAG standard, sans plancher horaire fixe. Sauf dépendance spécifique à OpenSearch (recherche hybride avancée, filtres complexes), c’est le choix qui doit primer pour toute nouvelle Knowledge Base en 2026.

Les autres coûts à budgéter avant de lancer

Au-delà du vector store, la facture Bedrock agrège plusieurs lignes qu’il faut chiffrer dès le cadrage :

• Requêtes de retrieval : environ 0,01 $ par requête sur la Knowledge Base, en plus du coût du modèle qui génère la réponse finale.
• Embeddings : facturés à l’ingestion des documents (tokens en entrée uniquement), à refaire à chaque mise à jour significative du corpus.
• Bedrock Data Automation (extraction/parsing de documents complexes — PDF scannés, tableaux) : environ 0,01 $ par page.
• Guardrails : filtrage de contenu et détection de sujets sensibles, facturé séparément à l’usage.
• Cross-region inference : nécessaire pour accéder à certains modèles ou lisser la capacité, avec un impact tarifaire et de résidence des données à vérifier — point de vigilance particulier pour une PME soumise au RGPD.

Aucune de ces lignes n’est dramatique isolément. Cumulées sans budget prévu, elles expliquent une bonne partie des écarts entre l’estimation initiale (souvent faite sur le seul coût des tokens) et la facture réelle du premier mois.

Bedrock vs alternatives : quand rester natif, quand simplifier

Bedrock n’est pas toujours le bon niveau d’abstraction. Trois arbitrages reviennent en mission :

• Chat simple, faible volume, pas de données propriétaires sensibles → un appel direct à l’API du modèle (Anthropic, ou autre) sans Knowledge Base ni infrastructure managée est souvent plus rapide à livrer et moins cher tant que le volume reste faible.
• RAG avec corpus de quelques milliers de documents, budget serré → S3 Vectors + Bedrock plutôt qu’OpenSearch Serverless, ou une base vectorielle open source auto-hébergée (pgvector sur RDS, déjà présent dans beaucoup de stacks PME) si l’équipe a la compétence pour l’opérer.
• Volumes élevés et prévisibles, usage stable sur plusieurs mois → là seulement le Provisioned Throughput devient pertinent ; en dessous d’un certain seuil de volume, l’engagement horaire coûte plus cher que l’on-demand.

L’argument pour rester sur Bedrock plutôt que d’appeler les API directement : la conformité et la résidence des données (traitement dans le compte AWS, pas de sous-traitant supplémentaire à qualifier RGPD), l’intégration IAM native, et la bascule de modèle sans réécrire l’intégration. Ces bénéfices ont un prix — c’est ce prix qu’il faut chiffrer avant de démarrer, pas après.

Méthode : chiffrer un cas d’usage avant de committer

La séquence qu’on applique en cadrage de mission :

1. Estimer le volume réel (documents/mois, requêtes/jour) — pas le volume en pic marketing, le volume moyen constaté sur 3 mois d’usage réel ou projeté prudemment.
2. Choisir le modèle le moins cher qui tient la qualité requise — tester Nova Lite/Micro avant de partir sur Sonnet ou Opus par défaut ; l’écart de prix au token est souvent d’un facteur 10 à 50.
3. Chiffrer le vector store séparément du coût token si RAG — S3 Vectors par défaut, OpenSearch Serverless seulement si un besoin fonctionnel précis le justifie.
4. Lister les lignes annexes (retrieval, embeddings, Data Automation, Guardrails, cross-region) et les additionner au coût token avant de présenter un chiffrage au sponsor du projet.
5. Revisiter à 30 jours avec la facture réelle — pas l’estimation — pour ajuster modèle, mode de facturation et configuration du vector store.

Conclusion

Bedrock rend l’IA générative accessible à une PME sans équipe MLOps dédiée, et les cas d’usage à fort ROI existent bel et bien — traitement documentaire en batch, RAG interne, copilotes métier. Mais la facture Bedrock a une structure fondamentalement différente d’une facture EC2 ou RDS : elle mélange coût variable au token et coûts fixes d’infrastructure (vector store en tête), et ces derniers peuvent dépasser le coût du modèle lui-même sur un usage à faible volume.

Si vous envisagez un déploiement Bedrock ou si une Knowledge Base tourne déjà sans que la facture ait été auditée, c’est typiquement le périmètre d’un Audit IA & Bedrock — architecture, choix de vector store, et plan de réduction de coûts en deux semaines. Démarrons le cadrage.