Résumé

  • draft-ietf-regext-balance-02 permet au client EPP authentifié de consulter le solde disponible, la trésorerie, la ligne de crédit et, s’ils sont configurés, les seuils d’exécution et d’alerte.
  • Cette réponse montre un état exploitable par l’automatisation, mais pas les écritures, l’heure du calcul, la provenance des taux de change, la version de la politique ni les engagements réservés qui le justifient.
  • Dès que cet état pèse sur l’acceptation d’une commande facturable, opérateur de registre et bureau d’enregistrement devraient conserver un reçu financier lié à la décision, sans transformer EPP en protocole comptable.

Le scénario est banal : un bureau d’enregistrement consulte son compte avant une vague de renouvellements. Le serveur annonce un montant positif. Une première commande passe, la suivante échoue. L’équipe technique possède les identifiants EPP ; la finance possède un grand livre ; le service clientèle possède peut-être une capture d’écran. Ces trois traces ne suffisent pas toujours à établir quel calcul a gouverné le refus.

Le projet du groupe REGEXT apporte une réponse utile à une partie du problème. Sa révision 02, publiée le 14 août 2026, définit une extension qui permet au client actuellement connecté de demander son état financier. Il s’agit encore d’un Internet-Draft destiné à la voie de normalisation, pas d’un RFC ni d’une preuve de déploiement par un registre donné.

La proposition réduit une fragmentation réelle. Aujourd’hui, connaître la capacité d’achat peut exiger un portail propriétaire, une alerte par courriel ou une convention spécifique à chaque opérateur. Un objet EPP commun rend la donnée accessible au même endroit que l’activité de provisionnement. Mais le fait de standardiser l’affichage ne standardise pas l’explication.

« Disponible » désigne une capacité, pas un relevé

Le projet définit balanceAvailable comme la somme de creditLine et cashBalance. La trésorerie correspond aux fonds détenus pour le client ; la ligne de crédit, au crédit accordé par l’opérateur. Une facturation est négative, un remboursement ou un dépôt est positif, un retrait est négatif.

Cette terminologie évite de confondre capacité de dépense et encours dû. Elle précise aussi ce qu’un automate peut comparer au prix d’une commande. Pourtant, le schéma ne livre aucune liste d’opérations. Il ne dit pas quel dépôt, remboursement, ajustement ou achat a produit la valeur. Il n’indique ni date d’arrêté du solde, ni période close, ni traitement d’une contestation, ni réservation encore non comptabilisée.

Le solde est donc une projection calculée par le serveur. Il peut être sincère et conforme tout en restant invérifiable à partir de la seule réponse. Tant qu’il informe, cette limite est gérable. Lorsqu’il commande l’accès à une création, un renouvellement ou un transfert facturé, il devient une pièce du pouvoir opérationnel.

Le seuil d’exécution déplace la frontière réelle

Le champ facultatif executionLimit indique le plancher sous lequel une opération facturable peut être refusée. Sa valeur par défaut est 0,00, mais le projet autorise un seuil positif ou négatif.

Un seuil positif protège une marge. Le texte cite les transactions déclenchées par le serveur, notamment les renouvellements automatiques : un opérateur peut conserver des fonds au-dessus de zéro afin de couvrir une obligation qui surviendra sans nouvelle commande du client. Le mot « disponible » ne signifie alors pas « entièrement dépensable maintenant ».

Un seuil négatif ouvre au contraire une capacité supplémentaire. Le client peut continuer à soumettre des opérations facturables après le passage sous zéro. La décision dépend ainsi de trois variables : le solde disponible, le seuil applicable et le coût de l’opération envisagée.

Le protocole montre le seuil courant, mais pas la règle qui l’a produit. Il ne donne ni l’auteur de l’autorisation, ni la date du changement, ni l’estimation des renouvellements à protéger, ni l’exception temporaire accordée pendant un incident. Il ne réserve pas non plus le montant entre la consultation et la commande. Un autre processus peut consommer les fonds, un taux peut évoluer, ou une règle non financière peut provoquer le refus.

Une lecture du solde n’est donc ni une promesse de traitement ni un jeton d’autorisation. C’est une information dont la durée de validité dépend d’éléments extérieurs au message.

L’alerte de file d’attente ne clôt pas les comptes

Le notificationThreshold, lui aussi facultatif, peut produire un message de solde faible au moment où le montant franchit un seuil. Son attribut basedOn doit reposer sur la même notion que le seuil d’exécution. Ce détail empêche une alerte fondée sur la seule trésorerie de côtoyer silencieusement une interdiction fondée sur le solde disponible.

L’alerte emprunte la file de messages du protocole de base. La date d’insertion, l’identifiant du message et les identifiants de transaction client et serveur donnent une chronologie technique. Le client accuse réception selon le mécanisme EPP habituel. Le projet prévoit un message lors du franchissement, plutôt qu’une répétition à chaque consultation.

Cette sobriété évite le bruit, mais elle ne constitue pas un rapprochement comptable. Accuser réception signifie que le logiciel a retiré ou reconnu le message, pas que le responsable financier l’a compris, que les fonds ont été ajoutés ou que le client accepte le calcul. Entre l’alerte et un refus, le seuil ou le solde peut encore changer.

La preuve utile doit relier l’avertissement à son contexte, pas seulement démontrer qu’un paquet a traversé une file.

Plusieurs devises, une provenance absente

Pour un compte alimenté dans plusieurs monnaies, le projet peut détailler chaque composante : devise de trésorerie, montant, taux et valeur convertie dans la monnaie de référence. La somme des valeurs converties doit correspondre à cashBalance. La cotation est directe : une unité de la devise composante, multipliée par le taux, donne le montant de référence.

Le client peut ainsi vérifier l’addition et comprendre la composition du total. Les codes ISO 4217 stabilisent les unités. Cependant, le message ne nomme pas la source du taux, son instant d’observation, la version de la règle d’arrondi ni le mode de secours utilisé si le flux de marché est indisponible. Il ne porte même pas un horodatage explicite « solde arrêté à ».

Cette absence est discrète lorsque le compte est largement approvisionné. Près du seuil d’exécution, quelques unités de conversion peuvent décider du passage d’un lot. L’infrastructure hérite alors d’une dépendance monétaire que le protocole rend calculable sans la rendre contestable.

Il ne serait pas raisonnable de demander à EPP de devenir une place de change. Il est raisonnable d’exiger que l’opérateur conserve, dans son système de preuve, la source et l’heure du taux qui a exercé un effet opérationnel.

La confidentialité fragmente l’enquête

Le projet qualifie ces informations de confidentielles et limite leur consultation au client connecté. Ce principe protège la position financière d’un bureau d’enregistrement contre ses concurrents. Il est indispensable.

Il produit néanmoins une difficulté d’organisation. Le prestataire qui exploite la connexion EPP peut détenir la trace de session sans posséder les fonds. Le service financier peut voir les écritures sans connaître la séquence exacte des commandes. Le registre peut expliquer sa politique interne sans partager le grand livre complet. Chacun détient une vérité partielle.

La bonne réponse n’est pas une publicité accrue. C’est une preuve étroite, accessible aux parties autorisées, qui révèle moins qu’un grand livre mais explique davantage qu’un écran de solde.

Un reçu lié à la décision

Je propose qu’un reçu d’état financier soit produit lorsqu’une règle de solde avertit, permet ou refuse matériellement une commande EPP facturable. Cette proposition relève de la gouvernance éditoriale ; elle ne figure pas parmi les obligations du projet IETF.

Le reçu devrait lier l’identité du client authentifié, le contexte de session, les clTRID et svTRID de la consultation, l’heure de lecture, la devise de référence, le solde disponible, la trésorerie, la ligne de crédit, le seuil d’exécution et le seuil d’alerte. Pour chaque composante monétaire, il conserverait montant, taux, source, heure d’observation et règle d’arrondi.

Il ferait également référence à l’état comptable sous-jacent : instantané ou relevé immuable, débits et crédits en attente matériellement pertinents, réserves de renouvellement automatique, version de politique et exception applicable. Un hachage ou un identifiant contrôlé peut assurer l’intégrité sans recopier les écritures sensibles dans EPP.

Enfin, il rattacherait cet état à la commande : type d’objet, référence tarifaire, heure de demande, heure de décision, résultat, code EPP et identifiants de transaction. Si la cause est étrangère au financement, le reçu le préciserait. Si le solde a changé, il garderait les états avant et après au lieu de remplacer le premier.

On pourrait alors tester une affirmation comme « fonds insuffisants ». Le désaccord serait localisé : concurrence entre sessions, conversion, réserve, retard comptable, politique ou simple autre motif de refus.

Garder EPP minimal sans rendre la décision opaque

L’extension reste volontairement limitée à la consultation. Elle ne définit pas de comportement spécifique pour check, create, delete, renew, transfer ou update. Ce choix permet à des modèles commerciaux différents de partager le même vocabulaire financier.

Ajouter des factures complètes et une logique de réservation universelle alourdirait le protocole et exposerait trop d’informations. Le problème n’est donc pas l’absence d’un grand livre dans le XML. Le problème apparaît si l’institution traite la valeur normalisée comme une vérité définitive tout en jetant les éléments qui l’ont rendue vraie.

La révision 02 a d’ailleurs affiné ce point en remplaçant « balance » par « balance available », en ajoutant basedOn et en faisant évoluer l’espace de noms vers 0.3. Le mot « disponible » signale une capacité sous conditions. La gouvernance doit désormais conserver les conditions qui ont réellement décidé.

Sources