Au-delà des limites d'utilisation : adapter l'accès à Codex/Sora

Au cours de l'année passée, Codex et Sora ont tous deux connu une adoption rapide, leur utilisation dépassant rapidement nos prévisions initiales. Nous avons observé une tendance constante : les utilisateurs se lancent, y trouvent une vraie valeur, puis se heurtent à des limites d'utilisation.

Les limites d'utilisation peuvent contribuer à réguler la demande et à garantir un accès équitable ; cependant, lorsque les utilisateurs obtiennent de la valeur ajoutée, atteindre une limite stricte peut être frustrant. Nous recherchions un moyen pour les utilisateurs de continuer à progresser, tout en protégeant les performances du système et la confiance des utilisateurs dans notre approche.

Pour résoudre ce problème, nous avons développé un moteur d'accès en temps réel qui comptabilise l'utilisation. L'une des fonctionnalités de ce moteur est la possibilité d'acheter des crédits. Lorsque les utilisateurs dépassent leurs limites d'utilisation, les crédits leur permettent de continuer à utiliser nos produits en utilisant leur solde de crédits.

Ceci repose sur un système complexe qui combine les limites, le suivi de l'utilisation en temps réel et les soldes de crédit dans un modèle d'accès unique. Cet article explique pourquoi l'évolution de Codex et Sora a nécessité de repenser le contrôle d'accès, comment un système en temps réel dont la fiabilité est prouvée combine limites de débit et crédits par requête, et comment cette base permet désormais d'accéder à des fonctionnalités supplémentaires pour les deux produits.

En prenant du recul, les modèles d'accès traditionnels tendent à imposer un choix :

• Les limites d'utilisation peuvent être utiles au début, mais laisse aux utilisateurs une mauvaise impression lorsqu'ils en ont besoin : « veuillez revenir plus tard »
• La facturation à l'usage est flexible, mais elle oblige les utilisateurs à payer dès le premier token, ce qui n'est pas idéal pour soutenir l'exploration précoce

Pour Codex et Sora, aucun des deux n'était suffisant à lui seul. Si nous avions simplement augmenté les limites d'utilisation, nous aurions perdu d'importants contrôles de régulation de la demande et d'équité, et nous aurions épuisé notre capacité à répondre aux besoins de tous. Si nous avions entièrement misé sur la facturation asynchrone de l'utilisation, nous aurions introduit des retards, des dépassements ou des problèmes de rapprochement, soit exactement le type de problèmes que les utilisateurs remarquent lorsqu'ils sont le plus engagés.

Ce dont nous avions besoin, c'était d'un système hybride unique combinant des limites en temps réel et un accès avec paiement à l'utilisation :

Ce système devait :

• Application de limites d'utilisation jusqu'à ce qu'elles soient atteintes
• Transition fluide vers les crédits au sein d'une même demande
• Prendre cette décision en temps réel
• Être rigoureusement précis et auditable lors du suivi de la consommation de crédits

L'un des principaux changements conceptuels que nous avons apportés a été de modéliser l'accès comme une cascade de décisions. Plutôt que de demander « est-ce autorisé ? », nous nous demandons «  quelle quantité est autorisée et par qui ? » Lors du calcul de l'utilisation, le système suit la séquence suivante :

Ce modèle reflète comment les utilisateurs perçoivent réellement le produit. Les limites d'utilisation, les formules gratuites, les crédits, les promotions et les droits d'accès des entreprises ne sont que des couches d'une même pile de décisions. Du point de vue de l'utilisateur, il ne « change pas de système » : il continue simplement à utiliser Codex et Sora. C'est pourquoi les crédits paraissent invisibles : ils ne sont qu'un élément de plus dans la cascade.

Nous avons évalué des plateformes tierces de facturation et de mesure de la consommation afin de gérer la consommation de crédit. Elles sont bien adaptées à la facturation et au reporting, mais ne répondaient pas à deux exigences essentielles :

Lorsqu'un utilisateur atteint une limite et qu'il dispose de crédits, le système doit en être informé immédiatement. Le comptage au mieux ou différé se traduit par des blocages inattendus, des soldes incohérents et des frais incorrects. Pour les produits interactifs tels que Codex et Sora, ces défaillances deviennent visibles et peuvent être source de frustration.

Nous devions également offrir de la transparence pour chaque résultat :

• Pourquoi une requête a été autorisée ou bloquée
• Quelle quantité d'utilisation a été consommée
• Quelles limites ou équilibres ont été appliqués

Cette fonctionnalité devait être étroitement intégrée à notre processus décisionnel plutôt que d'être traitée de manière isolée dans une plateforme de facturation distincte qui ne voyait qu'une partie de ce qui se passait. Pour permettre aux utilisateurs d'accéder à nos produits sans compromettre la confiance, nous devions avoir un contrôle total sur l'exactitude, le timing et l'observabilité. Cela nous a conduits à opter pour une solution interne.

Pour ce faire, nous avons mis en place un système distribué d'utilisation et d'équilibrage spécialement conçu pour les décisions d'accès synchronisées.

À un niveau général, le système :

• Suit l'utilisation par utilisateur et par fonctionnalité.
• Gère les fenêtres de limitation d'utilisation
• Gère les soldes de crédit en temps réel
• Débit des soldes de manière idempotente via un processeur asynchrone en continu

Chaque demande suit un parcours d'évaluation unique qui détermine en temps réel l'utilisation autorisée en consommant de manière synchrone à partir des limites d'utilisation et, si nécessaire, en vérifiant que les crédits sont suffisants. Il renvoie ensuite un résultat définitif tout en réglant les débits de crédit de manière asynchrone. Cela garantit un comportement cohérent entre les produits et élimine les doublons logiques entre les équipes.

L'un des principes clés de conception de ce système est que nous devons pouvoir prouver que notre facturation est correcte. Cela reflète les origines de notre offre de crédit, qui a vu le jour auprès de nos clients professionnels. Dans le schéma ci-dessus, nous avons trois jeux de données distincts qui sont tous liés entre eux :

• Événements liés à l'utilisation du produit : ce que l'utilisateur a réellement effectué
• Événements de monétisation : ce que nous facturons à l'utilisateur pour son utilisation
• Mises à jour du solde : montant de l'ajustement du solde de crédit de l'utilisateur et raison de ce réajustement

Ces jeux de données ne sont pas un simple sous-produit ; ils sont en réalité le moteur du système, chaque jeu de données déclenchant le suivant. En séparant les événements, les frais associés et les montants débités, nous pouvons auditer, rejouer et rapprocher chaque couche de manière indépendante. Il s'agit d'un compromis délibéré qui nous permet de privilégier la précision vérifiable, au détriment d'un léger retard dans la mise à jour des soldes créditeurs. Comment nous y sommes parvenus :

• Les événements liés à l'utilisation des produits sont publiés pour toutes les activités des utilisateurs, qu'elles entraînent ou non une consommation de crédit. Cela fournit une piste d'audit pour les activités des utilisateurs et nous permet d'expliquer pourquoi nous avons facturé ou non des crédits.
• Chaque événement comporte une clé d'idempotence stable, de sorte que les nouvelles tentatives, les relectures ou les redémarrages des agents ne peuvent jamais débiter deux fois un solde, ce qui empêche les doubles facturations. Cela nous permet également d'effectuer un rapprochement par lots pour vérifier notre travail hors ligne.
• Nous effectuons des mises à jour asynchrones (mais toujours en temps quasi réel) du solde au lieu de mises à jour synchrones afin de créer une piste d'audit. Nous acceptons un léger retard dans la mise à jour du solde de l'utilisateur afin de pouvoir prouver que le système fonctionne correctement et garantir à nos utilisateurs qu'ils ne sont pas facturés de manière erronée. Lorsque ce bref retard nous amène à dépasser le solde créditeur d'un utilisateur, nous le remboursons automatiquement ; nous privilégions la véracité démontrable et la confiance des utilisateurs plutôt que l'application stricte des règles.
• Nous réduisons le solde créditeur et insérons un enregistrement de mise à jour du solde dans une seule transaction de base de données atomique. Les mises à jour du solde sont sérialisées par compte, de sorte que les demandes simultanées ne peuvent jamais se disputer l'utilisation des mêmes crédits. L'enregistrement de mise à jour du solde contient à la fois le montant débité et l'attribution à l'événement de monétisation qui a déclenché la mise à jour ; le fait de regrouper cela dans une seule transaction de base de données garantit que nous disposons d'une piste d'audit pour chaque ajustement du solde créditeur.

Toute cette rigueur vise un seul objectif : rendre l'accès simple et sécurisé. Lorsque les utilisateurs créent ou codent, ils ne devraient pas avoir à se demander si une demande sera acceptée, s'ils seront surfacturés ou si leur solde est exact. En garantissant l'exactitude de l'utilisation, de la facturation et des soldes, nous offrons aux utilisateurs un système qui ne perturbe pas leur expérience. C'est ce qui nous permet de remplacer les interruptions brutales par un accès continu, et c'est ce qui rend les crédits utilisables au cours du travail réel, et pas seulement sur une facture.

Le principe directeur de notre approche est de préserver la dynamique des utilisateurs. Chaque décision architecturale a une incidence sur l'expérience utilisateur : les soldes en temps réel évitent les interruptions inutiles, la consommation atomique empêche les doubles facturations et la logique d'accès unifiée garantit un comportement prévisible. Il en résulte que les utilisateurs peuvent travailler plus longtemps, explorer plus en profondeur et mener à bien leurs projets sans être confrontés à des interruptions brutales ou à des changements de plan prématurés.

Lorsque les utilisateurs sont engagés, le système devrait les aider à poursuivre leur action, et non les gêner. Les limites et les crédits sont relégués au second plan.

Pour acquérir cette expérience, il a fallu repenser l'accès, l'utilisation et la facturation comme un système unique et mettre en place une infrastructure qui considère l'exactitude comme une caractéristique essentielle du produit. Cette base peut s'étendre à d'autres produits au fil du temps ; Codex et Sora ne sont qu'un début.