Quand j’ai commencé à construire /tools/pdf-chat, le pitch s’écrivait tout seul : Gemini 2.5 Flash dispose d’une fenêtre de contexte d’un million de jetons. Vous pouvez charger un PDF de 1 500 pages et discuter de l’intégralité du document en une seule requête. Pas de découpage, pas de RAG, pas de pipeline d’embedding, pas d’erreurs de récupération. Magique.
La magie, quand on fait les calculs, s’avère plutôt coûteuse.
Ce billet dévoile les coulisses du coût réel d’un contexte d’un million de jetons, comment cela a façonné la tarification de GeminiOmni, et quand le RAG classique par chunks reste la bonne solution. Si vous construisez quoi que ce soit qui touche à des documents longs, c’est le compromis que vous devez comprendre avant de vous engager dans une structure de paliers.
Le chiffre clé
Gemini 2.5 Flash, actuellement le modèle grand public avec contexte de 1M le moins cher, est facturé 0,30 $ par million de jetons en entrée et 2,50 $ par million de jetons en sortie. C’est la tarification la plus basse publiée pour un contexte de 1M à ma connaissance, et c’est encore 8 fois moins cher que Gemini 2.5 Pro pour la même taille de contexte.
Un million de jetons, c’est beaucoup de jetons. Plus précisément :
- Un million de jetons ≈ 750 000 mots en anglais ≈ 1 500 pages de prose ≈ 3 000 pages denses d’articles académiques
- Pour un PDF scanné typique (où le modèle doit OCRiser les images), attendez-vous à 800 à 1 000 pages par million de jetons, car les images consomment elles-mêmes une partie du budget de jetons
Maintenant, la multiplication que personne ne veut faire publiquement :
- Envoyer un PDF de 200 pages (≈130k tokens) une fois coûte 0,039 $. C’est environ quatre cents. Pas cher.
- Envoyer un PDF de 1 500 pages (≈980k tokens) une fois coûte 0,294 $. Trente cents.
- Poser dix questions de suivi, où chacune renvoie le PDF complet pour le contexte, coûte 2,94 $ pour le document de 1 500 pages. Trois dollars.
Ce dernier chiffre est celui qui a fait exploser mon modèle tarifaire.
Pourquoi les questions de suivi renvoient le PDF complet
C’est la partie que personne ne mentionne dans les billets de blog enthousiastes sur le contexte de 1M. La fenêtre de contexte de Gemini est par appel, pas par session. Il n’y a pas d’état persistant côté serveur qui conserve votre document pour le message suivant.
Quand vous posez la deuxième question dans une session de chat, le client doit renvoyer le PDF complet, plus la nouvelle question, plus la réponse précédente du modèle (pour assurer la continuité). Chaque tour coûte à peu près la même chose que le premier tour. Il n’y a pas de réduction pour la mise en cache.
Google a lancé une fonctionnalité de « mise en cache de contexte » qui aide ici : vous pouvez mettre en cache une longue entrée jusqu’à une heure et payer un tarif par appel réduit pour la réutiliser — mais le cache lui-même n’est pas gratuit non plus. Le coût de stockage du cache tourne autour de 1 $ par million de jetons par heure pour Flash. Pour un document de 1 500 pages, c’est environ 1 $/heure rien que pour le garder chaud.
Trois scénarios réels découlent de cela :
- Questions ponctuelles sur un document frais. 0,04 à 0,30 $ par question. Vraiment pas cher. Ça vaut le coup.
- Session de chat de dix questions sur un document frais, sans mise en cache. 0,40 à 3,00 $. Encore acceptable pour une fonctionnalité payante, mais brutal pour une gratuite.
- Analyse approfondie d’une heure avec plus de 30 questions sur un document de 1 500 pages. Avec mise en cache : environ 1 $ pour le garder chaud + 0,05 $ par tour = environ 2,50 $ au total. Sans mise en cache : 9 $. La mise en cache compte une fois que la session dépasse un certain seuil de longueur.
Quand le RAG par chunks est en fait moins cher
Voici la partie hérétique : pour certaines charges de travail, le bon vieux pipeline chunk + embed + retrieve reste bien moins cher que le contexte de 1M.
Plus précisément, si vous avez un corpus de documents stable (pas un nouvel upload à chaque fois) et de nombreux utilisateurs posant de nombreuses questions, le RAG l’emporte :
- Embedding du corpus : Gemini Embedding 2 à 0,20 $/1M de tokens — embarqué un document de 1 500 pages une fois pour 0,20 $, stockez les vecteurs pour toujours.
- Par question : récupérez les 5 meilleurs chunks (~5k tokens), envoyez-les à Gemini 2.5 Flash. Coût par question : environ 0,0015 $. C’est un dixième de cent.
- Contre le contexte de 1M : 0,30 $ par question si vous renvoyez tout le document.
Pour un bot de support client sur une base de connaissances fixe, le RAG est 200 fois moins cher. Pour un assistant de recherche lisant un nouvel article que l’utilisateur vient de télécharger, les frais généraux d’embedding du RAG ne s’amortissent pas et le contexte de 1M l’emporte.
La règle de décision :
| Charge de travail | Utilisation |
|---|---|
| L’utilisateur télécharge un document ponctuel, pose 1 à 10 questions | Contexte de 1M (pas de configuration d’embedding, toute la récupération gérée par le modèle) |
| Base de connaissances statique, nombreux utilisateurs, nombreuses questions | RAG (amortir le coût d’embedding sur toutes les requêtes) |
| L’utilisateur télécharge plusieurs documents et souhaite un raisonnement inter-documents | Contexte de 1M (la récupération RAG rate les références entre documents) |
| Révision juridique/conformité sur un document dense unique | Contexte de 1M (le RAG peut manquer des clauses critiques à cause des limites des chunks) |
Le chat PDF de GeminiOmni se situe fermement dans la catégorie « téléchargement ponctuel, 1 à 10 questions » — c’est pourquoi nous utilisons le contexte de 1M sans condition.
Comment cela a façonné le palier tarifaire
Une fois que j’ai intégré le calcul par page, la structure de paliers pour l’outil PDF s’est dégagée presque mécaniquement :
Palier gratuit : moins de 200 pages, questions illimitées. Un PDF de 200 pages coûte ~0,04 $ par question. Même un utilisateur gratuit intensif posant 100 questions par mois me coûte 4 $. C’est un coût d’acquisition durable — je peux le couvrir en me basant sur le taux de conversion du gratuit vers le Pro.
Palier Pro : 9 $/mois, longueur de document illimitée, questions illimitées. Cas de base : un utilisateur télécharge trois documents de 1 500 pages par mois, pose 30 questions sur chacun = 90 questions × ~0,30 $ = 27 $. Cela inverserait l’économie unitaire. Deux choses le sauvent :
- La plupart des utilisateurs Pro ne poussent pas jusqu’à la limite. L’utilisateur intensif au 90e percentile me coûte environ 4 $/mois. La moyenne est plus proche de 0,80 $.
- La mise en cache de contexte réduit le coût par question sur les longues sessions d’environ 4 fois.
Je tolère une marge mince sur les utilisateurs Pro les plus lourds car ce sont les plus bruyants sur l’efficacité du produit, et ils convertissent leurs collègues. Essayer d’extraire la marge maximale des 10 % les plus lourds signifierait ruiner le produit pour eux.
Palier Équipe : 79 $/mois pour 3 sièges avec accès API. C’est là que se trouve la vraie marge. Les équipes paient 4 fois plus qu’un utilisateur Pro pour le même profil d’utilisation, parce qu’elles paient pour la collaboration, l’accès API et le SLA — pas pour l’inférence brute. Je suis à l’aise avec cela car cela reflète le fonctionnement de Notion, Linear et de tous les autres SaaS avec palier équipe.
Ce que je ferais différemment si je construisais aujourd’hui
Quelques opinions que j’oserais mettre sur la page seulement après deux mois de calculs :
Afficher le coût par question à l’utilisateur. Quand un utilisateur télécharge un document de 1 500 pages, l’interface devrait indiquer « chaque question sur ce document coûte environ 1 crédit. » Cacher le coût aux utilisateurs crée un aléa moral — ils posent 50 questions alors que 5 suffiraient, et je mange la marge. Une tarification transparente s’autorégule.
Activer par défaut la mise en cache pour les documents de plus de 500 pages. La réduction de coût de 4 fois sur les longues sessions est assez importante pour que « activer la mise en cache » ne soit pas une option réservée aux utilisateurs avancés. Cela devrait être le comportement par défaut, avec une option « désactiver le cache pour la vie privée » pour les rares utilisateurs qui s’en soucient.
Ne promettre « illimité » pour rien. J’ai fait l’erreur d’écrire « chat PDF illimité en pages » sur le plan Pro. C’est maintenant un texte engageant, et je dois faire fonctionner l’économie unitaire même pour l’utilisateur le plus lourd. Pour le futur produit, j’aurais écrit « jusqu’à 5 000 pages par document, limite d’usage raisonnable sur le volume mensuel. » Leçon apprise pour le prochain produit.
À lire ensuite
- Discutez avec n’importe quel PDF — contexte de 1M de jetons
- Pourquoi Veo 3.1 Fast bat Sora pour le travail vidéo indépendant
- Tarification GeminiOmni — comment j’ai choisi les paliers
— Lena
