Résumé

  • La version 1.6.0 de pai-auth-ws-client expose séparément la résolution d’un usage d’IA et l’appel de chat, avec le fournisseur et le modèle dans les deux objets de réponse.
  • Aucun identifiant de résolution ou de version de configuration ne traverse le contrat Java public ; l’application peut comparer des attributs, mais pas rattacher sa réponse à l’état précis qu’elle avait inspecté.

La nouvelle interface mérite d’abord d’être défendue. Selon le README de la version 1.6.0, l’accès au gateway exige un jeton Bearer PAI doté du rôle portal-ai-gateway et une adresse appelante inscrite dans AI_LLM_WS_IP_WHITELIST. Le client emploie la validation TLS et le contrôle du nom d’hôte ordinaires, encode use comme un seul segment d’URL, limite la connexion à cinq secondes et l’attente de réponse à 90 secondes. Un dépassement devient une erreur explicite gateway_timeout avec le statut 504. Ce n’est pas un simple tuyau anonyme vers un modèle.

La réponse du chat contient aussi use, le fournisseur, l’identifiant du modèle et la latence. Ces éléments constituent déjà une provenance utile. Une bibliothèque cliente légère n’a d’ailleurs pas vocation à recopier les journaux du serveur, à révéler les secrets d’authentification ni à imposer un dossier réglementaire à chaque message. Le dépôt public ne permet ni de savoir si cette version est déployée, ni d’inventorier les traces privées du gateway ou des applications. L’absence d’un champ Java ne prouve donc pas l’absence d’un dispositif ailleurs.

La réserve porte uniquement sur ce que la bibliothèque rend vérifiable par elle-même. Elle propose désormais deux gestes distincts. resolve(token, use) demande l’affectation associée à un cas d’usage. chat(token, use, messages) transmet ensuite le même nom d’usage et les messages. Le README précise que l’application choisit use et que le client le fait suivre au gateway.

L’objet AiResolveData décrit un état assez détaillé : usage, fournisseur, identifiant et libellé du modèle, activation, délai et nom de la référence d’identification, en plus du succès, du statut HTTP et de l’erreur. L’objet AiChatData conserve le texte, l’usage, le fournisseur, le modèle et la latence. Il est donc possible de constater que le résultat affirme avoir utilisé tel fournisseur et tel modèle.

En revanche, aucun objet ne nomme la résolution elle-même. On ne trouve ni resolutionId, ni identifiant ou version de configuration, ni identifiant de requête, de trace ou de corrélation commun. Dans PortalAiClient, le corps du chat renvoie use et la liste des messages. Il ne transporte ni l’objet obtenu lors de la résolution, ni un jeton opaque issu de celle-ci.

La répétition du fournisseur et du modèle peut sembler suffisante. Elle ne l’est pas tout à fait, sans être pour autant trompeuse. L’objet de résolution montre qu’une configuration comporte également un état d’activation, un délai et un nom de référence d’identification. Deux versions peuvent garder le même couple fournisseur-modèle tout en modifiant un autre paramètre. Une affectation peut également changer entre la consultation et l’exécution. Les sources ne disent pas que cela s’est produit. Elles montrent seulement que, si cela arrive, deux chaînes identiques ne permettent pas de reconnaître la version exécutée.

Prenons une application qui résout un usage à 14 h 00 et note le fournisseur A, le modèle B et un délai de 60 secondes. À 14 h 01, le chat répond avec A et B. Cette concordance est rassurante. Elle n’établit pas si la révision de configuration contrôlée à 14 h 00 était encore active au moment de produire la réponse. Une nouvelle révision peut conserver A et B tout en changeant une autre règle. L’application dispose alors de deux portraits compatibles, pas d’un même acte signé.

Il ne s’agit pas d’alléguer une condition de course ou une faille. Le serveur peut très bien effectuer une nouvelle résolution et l’exécution de manière atomique dans le chat, tout en enregistrant une trace parfaite. L’application appelante peut ajouter ses propres identifiants. Une documentation non publique peut offrir des garanties supplémentaires. La discipline consiste à ne nier aucune de ces possibilités, mais aussi à ne pas les substituer au contrat observable par un intégrateur.

Le calendrier du dépôt rend l’examen légitime. GitHub date la publication de 1.6.0 du 12 septembre 2026. La note de version indique 59 tests Maven réussis sous Java 17 et une vérification structurelle validée. La comparaison avec 1.5.1 place la nouvelle étiquette huit commits plus loin : un commit ajoute le client d’IA, le suivant durcit ses appels. La fonction vient donc d’obtenir une forme publique stable.

Les tests de PortalAiClient révèlent utilement les invariants retenus. Ils contrôlent l’envoi du Bearer, la lecture du catalogue, l’encodage d’un usage contenant des caractères réservés, la sérialisation des rôles, le refus d’un usage vide, la conversion d’un timeout en 504 et la délégation par PortalWSClient. Il n’existe pas de test faisant passer l’identité de résolution au chat, puisque l’API n’offre pas encore cette identité.

Le correctif le plus petit serait un reçu opaque, pas la divulgation du fonctionnement interne. resolve pourrait retourner un resolutionId ou une version de configuration. Dans un mode strict, le chat l’accepterait et refuserait explicitement une résolution expirée ou remplacée. Dans un mode indicatif, le gateway resterait libre de basculer pour préserver le service, mais retournerait l’identité effectivement exécutée. Les deux modes sont défendables ; l’ambiguïté entre eux ne l’est pas.

Le reçu privé associerait cette identité à l’usage, à la version de politique, au fournisseur, au modèle, à l’heure de résolution et à l’identifiant de la requête appelante. Après le chat, il ajouterait l’identité appliquée, le statut, la latence, le recours à une nouvelle tentative ou à un cache, ainsi que les empreintes du prompt ou du dossier de preuves et de la réponse. Les empreintes rendent l’égalité contrôlable sans rendre public le contenu sensible. Les valeurs de secret n’y ont pas leur place.

Un tel reçu n’attesterait ni la vérité ni l’équité de la sortie. Il répondrait à une question antérieure : quel état de contrôle a produit cet objet ? Le catalogue exprime une intention de routage ; la réponse est un événement d’exécution. La continuité entre les deux doit pouvoir être démontrée, ou sa rupture doit être déclarée.

Cette précision protégerait également LACNIC. Faute d’identité commune, toute réponse surprenante peut être imputée à un changement silencieux du gateway, même lorsqu’aucun changement n’a eu lieu. Un reçu permettrait de confirmer une seule trace ou de localiser la divergence. Il réduit le champ des accusations au lieu d’étendre la responsabilité du registre.

Enfin, ce sujet ne reprend pas l’article précédent sur le décalage entre la mention Java 8 du README et le bytecode Java 17 des versions récentes. Cette question concernait la compatibilité d’exécution. Celle-ci commence après le démarrage réussi du client et examine la preuve laissée par ses nouveaux appels. Faire tourner la bibliothèque et identifier la décision du gateway sont deux problèmes différents.

Sources