Console de requête TokenLab : déboguez vos appels d'API d'IA depuis un tableau de bord unique

Un appel d'API IA qui échoue ne se signale que rarement de manière explicite. Vous recevez un code d'état, peut-être une chaîne d'erreur, et un canal de support où quelqu'un vous demande : « Quel était l'ID de la requête ? ». Si vous ne l'avez pas sous la main, l'investigation s'enlise avant même d'avoir commencé.

La console de requêtes TokenLab (Request Console) existe pour combler cette lacune. Elle centralise les détails au niveau de la requête — modèle, clé, état du cache, état de facturation, timing et aperçu de la charge utile (payload) expurgée — dans une vue unique. Vous pouvez ainsi passer de « cet appel a échoué » à « voici pourquoi » sans avoir à assembler des journaux provenant de trois endroits différents.

Cet article détaille ce que la console affiche, les points à vérifier en priorité en cas de problème, et comment elle s'articule avec les exports d'utilisation pour les équipes ayant également besoin de rapports sur les coûts.

Points clés à retenir

• La console de requêtes est une interface de débogage au niveau de la requête au sein du tableau de bord API de TokenLab, et non un rapport de facturation.
• Chaque requête possède un ID que vous pouvez rechercher directement, et vous pouvez créer un lien profond (deep-link) vers une requête spécifique grâce au paramètre requestId dans l'URL.
• La console affiche le routage, l'état de facturation, l'état du cache, le contexte du modèle/clé et des aperçus de charge utile expurgés pour les requêtes récentes.
• L'accès est limité à votre organisation et régi par les permissions du tableau de bord — les membres de l'équipe voient ce que leur rôle autorise.
• Pour le débogage d'un incident isolé, utilisez la console. Pour une revue groupée des coûts sur des plages temporelles, utilisez plutôt les exports d'utilisation.

Qu'est-ce que la console de requêtes ?

Vous y accédez via https://tokenlab.sh/en/dashboard/api?tab=requestConsole, dans la section API du tableau de bord TokenLab. Elle repose sur un principe simple : lorsqu'une requête échoue, la résolution la plus rapide consiste à avoir tout son contexte sous les yeux, plutôt que de deviner à partir d'un simple message d'erreur.

La description du tableau de bord présente la console comme un inspecteur pour les requêtes récentes, couvrant le routage, la facturation, le corps de la requête/réponse et le contexte du fournisseur de modèle. En pratique, cela se divise en plusieurs sections fonctionnelles.

Vue en liste. Un tableau filtrable des requêtes récentes. C'est ici que vous commencez lorsque vous n'avez pas encore d'ID de requête spécifique — vous recherchez l'appel ayant échoué ou présentant une anomalie.

Panneau d'inspection. Une fois une requête sélectionnée, l'inspecteur s'ouvre avec tous les détails : quel modèle a traité l'appel, quelle clé API a été utilisée, si le cache a été sollicité et quel a été le statut final.

Contexte d'erreur. Si la requête a échoué, la console affiche les informations d'erreur liées à cet appel spécifique, vous évitant ainsi de croiser des journaux d'erreurs séparés.

État du routage et de la facturation. Indique comment la requête a été routée et si elle a été facturée, est en attente, a été remboursée ou a échoué — les quatre états les plus importants lorsqu'un client demande : « Ai-je été facturé pour cette erreur ? ».

Aperçu de la charge utile (Payload). Les corps de requête et de réponse sont affichés sous forme d'aperçus expurgés lorsque cela est possible, vous donnant la forme et la structure sans exposer de données sensibles brutes.

Contexte du fournisseur et du modèle. Quel fournisseur et quel modèle spécifique ont traité l'appel — utile lorsque vous exécutez plusieurs modèles derrière une seule intégration et que vous devez confirmer que le bon a été invoqué.

Rien de tout cela ne nécessite de construire votre propre pipeline de journalisation par-dessus l'API. Tout est déjà exposé par organisation, filtré par les permissions du tableau de bord, afin que les membres de l'équipe disposant des accès appropriés voient les mêmes données de requête que vous.

Que vérifier en priorité ?

Lorsqu'un appel d'API échoue, il existe un ordre logique pour vérifier les choses. Sauter directement à « le modèle est-il hors ligne ? » avant de confirmer que la requête a bien atteint le bon point de terminaison est une perte de temps.

Le triage en cinq champs

Vérification	Ce que cela vous indique
ID de requête	Confirme que vous examinez l'appel exact en question, et non un appel similaire
Statut	Facturé, en attente, remboursé ou échoué — indique s'il s'agit d'une question de coût ou d'un problème technique
Modèle	Quel modèle a réellement traité la requête (utile si vous routez vers plusieurs modèles)
État du cache	Si une correspondance (hit) ou un échec (miss) du cache a modifié le coût ou la latence
Source de la clé	Quelle clé API a été utilisée, utile lorsque plusieurs clés ou environnements partagent une intégration

Commencez par l'ID de la requête. Si vous l'avez obtenu à partir d'un journal côté client, d'un ticket de support ou d'un rapport d'erreur, utilisez le modèle de lien profond :

https://tokenlab.sh/en/dashboard/api?tab=requestConsole&requestId=<request_id>

Cela ouvre l'inspecteur directement sur la requête en question, en ignorant la vue en liste. C'est le chemin le plus rapide lorsqu'on vous donne un ID en vous demandant « que s'est-il passé ici ? ».

Si vous n'avez pas encore d'ID de requête, les filtres de la console vous permettent de restreindre la recherche par modèle, plage horaire, état du cache, source de la clé et statut. Un modèle courant : filtrer par statut « failed » (échoué) sur la dernière heure, puis parcourir la liste pour trouver l'appel spécifique sur lequel un utilisateur s'interroge.

Lire correctement le champ de statut

Les quatre états — facturé, en attente, remboursé, échoué — répondent à des questions différentes :

• Facturé (Billed) signifie que l'appel a été complété et a consommé des crédits. Si un utilisateur signale une erreur mais que la requête apparaît comme facturée, cela mérite d'être signalé séparément, car cela suggère que l'échec s'est produit côté client après une réponse réussie.
• En attente (Pending) signifie que la requête est toujours en cours ou en attente de règlement. Ne considérez pas cela comme un échec prématurément.
• Remboursé (Refunded) signifie que TokenLab a annulé la facturation, généralement lié à une défaillance du fournisseur ou du routage.
• Échoué (Failed) signifie que l'appel n'a pas pu être complété avec succès et n'a pas été facturé.

Savoir lequel de ces états s'applique avant d'escalader le problème vous évite des allers-retours inutiles avec le support.

Confirmer le modèle et l'état du cache

Si vous exécutez des requêtes vers des modèles comme Claude Sonnet 5, DeepSeek V4 Pro ou Gemini 3.5 Flash via une intégration partagée, il est utile de confirmer que la console affiche bien le modèle attendu. Un client mal configuré, une variable d'environnement obsolète ou une règle de routage peuvent envoyer du trafic vers le mauvais modèle sans erreur évidente côté client.

L'état du cache compte pour deux raisons : le coût et la latence. Un échec de cache (miss) là où vous attendiez une correspondance (hit) signifie généralement que le préfixe du prompt a changé, même subtilement — un horodatage, un champ réordonné, un espace supplémentaire. Le filtre d'état du cache de la console vous permet de comparer côte à côte les requêtes avec hit et celles avec miss.

Comment cela fonctionne avec les exports d'utilisation

La console de requêtes et les exports d'utilisation résolvent des problèmes différents, et il est important de bien définir la limite pour ne pas utiliser le mauvais outil.

La console est conçue pour l'investigation d'une requête unique : un appel, une erreur, une question de facturation, résolus dans le panneau d'inspection. C'est ce que vous ouvrez lorsqu'une requête spécifique échoue et que vous devez savoir pourquoi, immédiatement.

Les exports d'utilisation sont conçus pour une revue globale : dépenses sur une plage temporelle, ventilations par modèle ou par clé, et le type de rapport que vous remettriez à un responsable financier ou utiliseriez pour une réconciliation mensuelle. Si vous essayez de répondre à « combien avons-nous dépensé pour DeepSeek V4 Pro la semaine dernière ? », c'est une question d'export, pas de console. Consultez le guide des exports d'utilisation du tableau de bord TokenLab pour ce flux de travail.

En résumé : la console pour les incidents, les exports pour les totaux. Certaines équipes utilisent les deux en séquence — un export révèle une anomalie dans les dépenses globales, et la console est l'endroit où vous creusez les requêtes spécifiques qui l'ont causée.

Une routine de débogage pratique

Le débogage ad hoc se transforme en conjectures sous la pression. Une routine répétable empêche les incidents de durer plus longtemps que nécessaire.

Checklist : lorsqu'une requête échoue

1. Obtenez l'ID de la requête. Depuis vos journaux clients, la réponse d'erreur ou un rapport d'utilisateur. Si vous ne journalisez pas les ID de requête de votre côté aujourd'hui, commencez maintenant — c'est la clé de recherche la plus rapide dont vous disposez.
2. Ouvrez la console avec le lien profond. Utilisez le paramètre de requête requestId pour accéder directement à l'inspecteur.
3. Vérifiez d'abord le champ de statut. Facturé, en attente, remboursé ou échoué — cela cadre le reste de l'investigation.
4. Confirmez le modèle qui a réellement servi la requête. Comparez-le avec ce que vous pensiez envoyer.
5. Vérifiez l'état du cache. Un échec de cache là où vous attendiez un hit peut expliquer une latence ou un coût inattendu.
6. Vérifiez la source de la clé. Confirmez que la bonne clé API et le bon environnement étaient utilisés, surtout dans les configurations staging-vs-production.
7. Lisez le contexte de l'erreur et les informations de routage. C'est généralement là que la cause racine devient visible.
8. Examinez l'aperçu de la charge utile expurgée. Confirmez que la forme de la requête correspond à ce que votre client a envoyé — des paramètres mal formés apparaissent souvent ici avant d'apparaître ailleurs.
9. Croisez avec la référence API si nécessaire. La référence de l'API de complétion de chat de TokenLab documente les formes de requête et de réponse attendues, utile pour confirmer si une charge utile était mal formée côté client.
10. S'il s'agit d'un modèle récurrent, passez aux exports d'utilisation. Une seule requête échouée est un problème de console. Dix requêtes échouées en une heure constituent un modèle qui mérite d'être exporté et examiné globalement.

Suivre cet ordre — ID, statut, modèle, cache, clé, erreur, charge utile — vous évite de passer à côté du champ qui explique réellement l'échec.

Étapes suivantes

Si vous déboguez actuellement les échecs d'API IA en cherchant dans vos propres journaux côté client et en croisant avec un tableau de bord de facturation séparé, la console de requêtes supprime une étape de cette boucle. Commencez par trouver une requête échouée récente et ouvrez-la directement.

• Ouvrez la console et localisez une requête par ID : https://tokenlab.sh/en/dashboard/api?tab=requestConsole
• Créez une clé API TokenLab sur tokenlab.sh/en/dashboard/api pour commencer à effectuer des requêtes depuis votre propre console ou vos scripts.
• Vérifiez la forme de requête/réponse des complétions de chat si vous suspectez une charge utile mal formée : https://docs.tokenlab.sh/api-reference/chat/create-completion
• Pour une revue des dépenses globales, utilisez les exports d'utilisation plutôt que la console : https://tokenlab.sh/en/blog/tokenlab-dashboard-usage-exports
• Si vous comparez des modèles pour leur coût ou leurs capacités avant de changer, le répertoire des modèles contient les prix actuels et les détails sur les fenêtres de contexte : https://tokenlab.sh/en/models

FAQ

Qu'est-ce que la console de requêtes TokenLab ? C'est une vue de débogage au niveau de la requête à l'intérieur du tableau de bord API de TokenLab. Elle affiche le routage, l'état de facturation, l'état du cache, le contexte du modèle et de la clé, ainsi que des aperçus de charge utile expurgés pour les requêtes récentes, limités à votre organisation.

Puis-je inspecter une requête par son ID ? Oui. Utilisez le format de lien profond /dashboard/api?tab=requestConsole&requestId=<request_id> pour ouvrir l'inspecteur directement sur une requête spécifique, ou effectuez une recherche par ID de requête depuis la vue en liste.

La console remplace-t-elle les exports d'utilisation ? Non. La console est destinée à l'investigation de requêtes individuelles — un échec, une question de facturation. Les exports d'utilisation servent à la revue des dépenses globales sur une plage temporelle. Utilisez les deux ensemble lorsqu'un export révèle un modèle que vous devez approfondir.

Que dois-je vérifier en premier lorsqu'une requête d'API IA échoue ? Commencez par l'ID de la requête pour confirmer que vous regardez le bon appel, puis vérifiez le champ de statut (facturé, en attente, remboursé, échoué), le modèle qui a réellement traité l'appel, et l'état du cache. À partir de là, le contexte de l'erreur et l'aperçu de la charge utile rendent généralement la cause racine visible.

Sources et fraîcheur

• Console de requêtes TokenLab — https://tokenlab.sh/en/dashboard/api?tab=requestConsole — observé le 09/07/2026
• Référence de l'API de complétion de chat TokenLab — https://docs.tokenlab.sh/api-reference/chat/create-completion — observé le 09/07/2026
• Exports d'utilisation du tableau de bord TokenLab — https://tokenlab.sh/en/blog/tokenlab-dashboard-usage-exports — observé le 09/07/2026
• Répertoire public des modèles TokenLab — https://tokenlab.sh/en/models — observé le 09/07/2026

Les exemples de modèles référencés (Claude Sonnet 5, DeepSeek V4 Pro, Gemini 3.5 Flash) reflètent la source unique de vérité (SSOT) des modèles au 07/07/2026. Pour les prix et la disponibilité actuels exacts, vérifiez auprès du lien du répertoire des modèles ci-dessus avant de prendre des décisions de routage.