Le prix au token ne suffit pas : le vrai coût du codage IA intensif

Une IA peut être bon marché par token et chère par développeur. Il n’y a pas de contradiction : on compare souvent deux produits différents.

D’un côté, une API facturée à l’usage, où chaque token supplémentaire alourdit la facture. De l’autre, un abonnement de programmation avec une enveloppe d’usage : tant que l’utilisateur reste dans ses règles et ses plafonds, son budget est plus prévisible.

Pour un agent autonome qui relit continuellement des dépôts, transporte un contexte long et génère beaucoup de texte, la question n’est donc pas seulement « quel modèle a le token le moins cher ? ». Elle est plutôt : à quel moment mon coût marginal s’arrête-t-il, et l’offre supporte-t-elle réellement ma charge de travail ?

Un tarif unitaire faible ne fixe aucun plafond

GLM-5.2 est affiché à 1,40 $ par million de tokens d’entrée, 0,26 $ par million de tokens d’entrée lus depuis le cache, et 4,40 $ par million de tokens de sortie. 1 Ces tarifs sont attractifs pour un usage classique d’API, mais l’échelle change vite :

• 1 milliard de tokens d’entrée non mis en cache : 1 400 $ ;
• 1 milliard de tokens d’entrée mis en cache : 260 $ ;
• 1 milliard de tokens de sortie : 4 400 $.

Le dernier chiffre est crucial pour les agents de programmation. Ils ne se contentent pas de lire du code et de la documentation : ils produisent aussi des plans, des modifications, des tests, des explications, des appels d’outils et de nouvelles itérations. Une charge de travail riche en sorties peut donc coûter bien plus que ne le laisse penser un simple prix d’entrée.

Le cache peut changer fortement l’équation. Le contexte réutilisé est facturé à un tarif bien inférieur, mais le coût final dépend toujours du mélange effectif entre entrées non mises en cache, entrées mises en cache et sorties. 1

Le rapprochement avec 7 800 ¥ par jour exige des précisions

Une comparaison relayée place l’usage de l’API GLM-5.2 autour de 7 800 ¥ par jour, face à un coût fixe hebdomadaire bien plus faible pour un abonnement Codex. Elle illustre une différence réelle entre paiement à l’usage et enveloppe d’abonnement, mais le volume de tokens invoqué demande à être contextualisé.

Aux tarifs publiés pour GLM-5.2, des dizaines de milliards de tokens d’entrée non mis en cache, à eux seuls, représenteraient des dizaines de milliers de dollars par jour ; le coût serait encore beaucoup plus élevé pour des sorties à cette échelle. 1 Une facture de 7 800 ¥ par jour peut plutôt correspondre à un volume facturable effectif inférieur, à une très forte part de contexte en cache, à une combinaison spécifique entre entrées et sorties, à des tarifs remisés ou à une autre base de prix.

La leçon pratique est simple : un total de tokens ne suffit pas pour comparer un flux de travail de développement. Il faut mesurer :

1. les tokens d’entrée hors cache ;
2. les tokens d’entrée en cache ;
3. les tokens de sortie ;
4. les fenêtres de réinitialisation et plafonds de l’offre ;
5. le passage éventuel à une facturation additionnelle après dépassement.

Un abonnement plafonne le budget, pas forcément l’usage

Un abonnement ne rend pas l’inférence gratuite. Il déplace la variabilité des coûts.

Avec une formule mensuelle fixe, un utilisateur intensif mais autorisé peut recevoir davantage d’usage équivalent API que ce que le prix affiché de l’abonnement permettrait d’acheter sur un endpoint à la demande. L’utilisateur obtient un budget plus prévisible ; le fournisseur gère le risque par des fenêtres glissantes, des limites de débit, des règles de priorité, des crédits ou d’autres mécanismes d’usage équitable.

C’est pourquoi une API plus coûteuse peut coexister avec un abonnement de programmation relativement attractif. Le tarif API est un prix marginal direct du calcul. L’abonnement est une offre groupée, assortie de limites : elles peuvent convenir à de nombreux utilisateurs, sans pour autant garantir un débit illimité.

Les offres de coding chinoises peuvent elles aussi être fortement mesurées

La ligne de partage n’oppose pas les modèles chinois aux modèles étrangers. Elle sépare les produits qui se comportent comme un compteur de tokens ouvert, un portefeuille de crédits, ou une allocation assez généreuse avec réinitialisations.

GLM Coding Plan impose explicitement deux contraintes : une enveloppe de points sur une fenêtre glissante de cinq heures et une enveloppe hebdomadaire. Les limites publiées sont notamment de 12 000 points toutes les cinq heures et 60 000 points par semaine pour Pro, contre 28 000 et 140 000 pour Max. La consommation est calculée à partir des tokens d’entrée, des entrées en cache et des sorties, avec des coefficients propres à chaque modèle. 2

Qoder est encore plus explicite sur son système de crédits. Ses formules payantes incluent 2 000, 6 000 ou 20 000 crédits mensuels pour les modèles premium ; une fois ces crédits épuisés, Qoder bascule vers un modèle de base dont le nombre de messages est limité. Qoder précise aussi que les ressources premium incluses correspondent à la valeur de l’abonnement, à laquelle s’ajoutent d’éventuelles ressources bonus. 17

Pour un développeur qui exécute fréquemment des tâches d’agent longues et exigeantes, ces formules peuvent donc ressembler davantage à un crédit prépayé payé mensuellement qu’à un accès sans contrainte.

Les multiplicateurs aux heures de pointe rendent la capacité visible

Les plafonds ne sont pas la seule contrainte. Un fournisseur peut aussi modifier la vitesse à laquelle l’enveloppe est consommée lors des périodes chargées.

La documentation actuelle de Z.ai indique que GLM-5.3 consomme le quota avec un multiplicateur de 1× hors pointe et de 3× en période de pointe ; GLM-5.3-Flash est indiqué à 0,4× et 1,2× respectivement. 4 La présentation de GLM Coding Plan identifie aussi un créneau de pointe en semaine, de 14 h à 18 h en UTC+8. 2

C’est un outil de gestion de capacité : le prix de l’abonnement ne change pas, mais la quantité de travail couverte par l’allocation peut diminuer aux heures les plus demandées. Il ne faut toutefois pas étendre automatiquement cette règle à toutes les offres GLM-5.2 ni à toutes les périodes sans vérifier les conditions propres à l’offre concernée.

Ce que les sources établissent — et ce qu’elles n’établissent pas — sur les problèmes d’accès

Les récits faisant état de quotas quotidiens rapidement épuisés, d’un accès réduit à GLM-5.2, de fenêtres de cache courtes, d’un faible regroupement entre utilisateurs ou de pénuries d’inférence propres à certains fournisseurs peuvent être plausibles. Ils ne sont toutefois pas tous démontrés par les éléments examinés ici.

La documentation primaire disponible établit clairement l’existence de plafonds de quota, d’une comptabilisation des points pondérée par les tokens et de multiplicateurs selon l’horaire. 24 Elle ne suffit pas, à elle seule, à vérifier l’explication précise avancée par un fournisseur pour chaque difficulté d’accès signalée. Pour décider d’un achat, mieux vaut traiter les retours informels comme des signaux à tester, non comme des faits établis.

L’évaluation utile doit reproduire la charge réelle aux heures de travail de l’équipe : taille des dépôts, comportement du cache, longueur des sorties, nombre d’agents simultanés, mise en file d’attente et comportement de repli de l’offre comptent davantage qu’un prix annoncé isolé.

La règle d’achat pour les équipes qui codent intensivement avec l’IA

Les API chinoises à bas coût restent intéressantes pour une inférence légère ou prévisible, surtout lorsque le flux de travail réutilise efficacement le contexte en cache. 1 Elles constituent un bon choix pour les équipes qui veulent piloter directement l’API et suivre rigoureusement leur budget de tokens.

Mais le codage IA à très forte intensité est un autre problème d’achat. Quand un agent consomme durablement de gros volumes, l’option gagnante est souvent celle qui réunit :

• un plafond mensuel prévisible ;
• une allocation qui tient durant des journées de travail normales ;
• des règles claires de réinitialisation et de dépassement ;
• un accès stable aux heures de pointe ;
• assez de capacité pour les tâches parallèles.

En bref : comparez le travail réellement exploitable chaque mois, pas uniquement le tarif catalogue de l’API. Un modèle à la demande peu cher l’emporte quand l’usage est maîtrisé. Un abonnement ne l’emporte que si ses limites sont transparentes et assez larges pour la charge réelle des agents de développement.