Tarification dynamique de l'IA : ce que le passage de DeepSeek aux heures de pointe annonce

DeepSeek facture désormais ses appels d'API à un tarif qui dépend de l'heure. La documentation officielle est explicite : « Off-peak rates are half of the peak rates », les tarifs en heures creuses valent la moitié des tarifs en heures pleines.

C'est, à ma connaissance, le seul grand fournisseur de modèles à pratiquer aujourd'hui une tarification qui varie selon le moment de la journée. J'ai regardé ce que cela révèle, et surtout ce que cela ne permet pas encore de conclure.

Ce que dit exactement la grille

La documentation de DeepSeek définit la fenêtre de la façon suivante : « Peak hours are 01:00 - 04:00 and 06:00 - 10:00 UTC, Monday through Friday (all other hours are off-peak) ».

Il faut lire cette phrase attentivement, parce que sa structure est contre-intuitive.

Les heures pleines représentent trois heures plus quatre heures, soit sept heures par jour, du lundi au vendredi uniquement. Cela fait 35 heures par semaine sur 168. Autrement dit, près de 80 % du temps se situe au tarif réduit, week-ends compris.

Ce n'est donc pas une remise ponctuelle accordée la nuit sur un tarif de référence. C'est l'inverse : le tarif bas est l'état par défaut, et une surtaxe s'applique sur une fenêtre étroite. La différence de formulation n'est pas anodine pour qui construit un budget.

Sur les niveaux, à la date où j'écris, le modèle deepseek-v4-pro est facturé 1,32 dollar par million de jetons en entrée hors cache et 3,96 dollars en sortie pendant les heures pleines, contre 0,66 et 1,98 dollar en heures creuses. Le modèle deepseek-v4-flash descend à 0,44 et 1,32 dollar en heures pleines, contre 0,22 et 0,66 en heures creuses. Les entrées servies par le cache sont à des niveaux très inférieurs, de l'ordre de quelques centimes par million de jetons.

Ces chiffres bougent. Je donne la date de consultation plutôt que de les présenter comme stables, et je renvoie à la page de tarification officielle pour l'état courant.

L'observation qui explique tout : ce sont les horaires de bureau chinois

Convertissons les fenêtres d'heures pleines en heure de Pékin, qui est à UTC+8.

La première fenêtre, 01:00 à 04:00 UTC, correspond à 09:00 à 12:00 à Pékin. La seconde, 06:00 à 10:00 UTC, correspond à 14:00 à 18:00 à Pékin.

Le résultat saute aux yeux : ce sont exactement les horaires de travail chinois, matin et après-midi, avec la pause déjeuner découpée au milieu. Et cela ne s'applique que du lundi au vendredi.

Cette lecture change la nature de ce qu'on observe. Il ne s'agit pas d'un signal-prix sophistiqué destiné à lisser une charge mondiale, ni d'une indexation sur le coût de l'électricité. Il s'agit d'un fournisseur qui constate que sa capacité sature quand son marché domestique travaille, et qui facture plus cher à ce moment-là. C'est de la gestion de congestion, formulée de la façon la plus simple possible.

Pour un utilisateur européen, la conséquence pratique est plutôt favorable. En heure de Paris l'été, la première fenêtre de surtaxe tombe entre 3h et 6h du matin, donc au milieu de la nuit. La seconde tombe entre 8h et midi. Concrètement, la matinée de travail européenne est surtaxée, l'après-midi ne l'est pas. Décaler un traitement par lots de 11h à 14h suffit à diviser sa facture par deux, ce qui est un arbitrage assez trivial à mettre en œuvre pour du non-interactif.

Ce qu'il ne faut pas en conclure

C'est ici que je veux être prudent, parce que la tentation de généraliser est forte et que rien ne la soutient pour l'instant.

J'ai cherché des dispositifs équivalents chez les autres grands fournisseurs. Je n'ai trouvé aucune tarification variable selon l'heure chez OpenAI, chez Anthropic ni chez Mistral. Ce qui existe largement, en revanche, ce sont deux autres mécanismes qu'il ne faut pas confondre avec celui-ci : les remises très importantes sur les entrées servies par le cache, qui dépendent du contenu de la requête et non de l'heure, et les traitements par lots à tarif réduit contre un délai de livraison différé, qui dépendent de l'urgence acceptée et non de l'heure non plus.

Un seul acteur, sur un marché qui en compte plusieurs, cela s'appelle un point de donnée. Pas une tendance. Écrire que « l'industrie bascule vers la tarification dynamique » serait une extrapolation à partir d'un cas unique, et je n'ai rien trouvé qui la justifie.

Il faut ajouter que DeepSeek est dans une position particulière. C'est un acteur à forte contrainte de capacité, dont l'accès au matériel de calcul le plus récent est restreint par les contrôles à l'exportation, et dont la base d'utilisateurs est fortement concentrée sur un fuseau horaire. Ces trois caractéristiques réunies rendent la congestion horaire beaucoup plus aiguë que chez un fournisseur disposant d'une capacité mondiale répartie. La solution qu'il adopte est adaptée à sa contrainte, ce qui ne dit rien de la contrainte des autres.

Le signal réel, quand même

Cela dit, je ne crois pas que ce soit anecdotique, et voici pourquoi.

Jusqu'à présent, l'inférence était vendue comme une commodité au prix unitaire fixe, avec pour seul levier de négociation le volume. La logique implicite était celle d'une ressource abondante dont le prix ne pouvait que baisser. Introduire une variation horaire, c'est admettre publiquement que la capacité est rare à certains moments, et que cette rareté a un prix.

C'est cohérent avec ce que j'observais à propos des précommandes de capacité d'inférence : quand des acteurs se mettent à réserver de la capacité à l'avance, c'est que la disponibilité immédiate a cessé d'être acquise. La tarification horaire est l'autre face de la même pièce, côté demande plutôt que côté offre.

L'analogie avec le marché de l'électricité vient naturellement, et elle est instructive à condition de ne pas la pousser trop loin. Le point commun est réel : une ressource dont le stockage est difficile, une demande qui varie fortement selon l'heure, un prix qui sert de signal pour déplacer la consommation. La différence l'est tout autant : le prix spot de l'électricité varie en continu et peut devenir négatif, alors que DeepSeek applique deux paliers fixes sur un calendrier publié à l'avance. C'est une tarification par plages, comme les heures creuses domestiques, pas un marché.

Ce que ça change pour qui construit avec ces API

Trois conséquences pratiques, en attendant de voir si d'autres suivent.

Le coût d'un usage devient dépendant de son heure, donc de son architecture. Un traitement par lots nocturne, une réindexation, un enrichissement de base : tout ce qui n'a pas besoin d'être synchrone peut être déplacé. C'est un gain de 50 % pour une modification de planificateur. Sur un usage interactif en revanche, la marge de manœuvre est nulle, puisque c'est l'utilisateur qui décide de l'heure.

La comparaison entre fournisseurs se complique. Un tableau de prix au million de jetons ne suffit plus à comparer deux offres si l'une varie selon l'heure et l'autre non. Il faut pondérer par la distribution horaire réelle de son propre trafic, qui n'est pas la même pour un outil interne européen et pour un service grand public mondial.

La prévisibilité budgétaire se dégrade légèrement. Une même charge de travail ne coûte plus le même prix selon le jour de la semaine où elle tourne. Pour un budget annuel c'est du bruit, pour une refacturation interne à la consommation c'est une complication réelle.

Rien de tout cela ne remet en cause l'arbitrage de fond entre API et hébergement local, que j'ai détaillé dans mon article sur le coût réel d'une IA déployée en local. Une remise de 50 % sur une fenêtre horaire ne compense pas un écart d'un ordre de grandeur, et ne rend pas davantage pertinent d'acheter des GPU. Elle rend simplement l'API un peu moins chère pour les usages qu'on peut décaler.

Ce que je surveille

Une seule question, et elle est facile à formuler : est-ce qu'un deuxième fournisseur adopte une tarification horaire ?

Tant que la réponse est non, DeepSeek reste un cas particulier, explicable par sa contrainte de capacité et par la concentration géographique de ses utilisateurs. Si un fournisseur disposant d'une capacité mondiale répartie s'y met, alors la lecture change : cela signifiera que la tension sur la capacité d'inférence n'est plus une spécificité d'acteur contraint, mais une caractéristique du marché.

Je m'abstiens de parier sur l'issue. Je note simplement que le premier à l'avoir fait est aussi celui qui avait les meilleures raisons structurelles de le faire, ce qui est l'hypothèse la plus économe.

Sources : DeepSeek, tarification officielle de l'API · DeepSeek, documentation API