Vous avez déjà perdu le sommeil sur une facture IA qui a explosé du jour au lendemain, sans comprendre pourquoi ?
C’est le sale secret du dev IA : ces modèles engloutissent les jetons comme des bolides crament l’essence, mais sans tableau de bord, vous pilotez en aveugle. Entrez en scène le Three Table Pattern — requêtes, réponses, échanges. Une structure d’apparence anodine qui capture ce que vous envoyez, ce qui revient, et les lie étroitement, faisant jaillir les coûts naturellement. Je l’ai vu dissiper le brouillard dans les apps de chat, les tâches en arrière-plan, partout où l’IA pose ses pattes sur du code.
Et le miracle : ce n’est pas du bloatware d’entreprise. Juste trois tables, un échange d’ID, et hop, chaque aller-retour devient traçable. Pas de fouille dans les logs. Pas de devinettes en UI.
Pourquoi traquer les allers-retours IA ressemble à de la sorcellerie… jusqu’à aujourd’hui ?
L’IA, c’est un basculement de plateforme plus gros que l’iPhone — des modèles comme endpoints, des prompts comme API. Mais les coûts ? C’est la taxe sur la magie. Jetons d’entrée, de sortie, paliers de tarification des fournisseurs : ça s’accumule vite.
TL;DR : Quand vous intégrez de l’IA dans une app, persistez la requête, persistez la réponse, et liez-les via un échange. Cette structure rend chaque aller-retour traçable — et les coûts en jetons émergent naturellement.
C’est l’étincelle originelle, tout droit des tranchées. Boum. Autorité.
Ma variante ? Ça rappelle la naissance de l’observabilité web — rappelez-vous quand les logs de requêtes HTTP étaient une nouveauté ? Aujourd’hui, c’est la base, grâce à des outils comme New Relic. Avance rapide (non), cette chorégraphie en trois tables est l’équivalent pour l’IA : primitive aujourd’hui, omniprésente demain. Pari osé : d’ici 2026, elle s’intègrera aux frameworks comme LangChain, taillant dans le gaspillage en repérant les fuites de prompts dès le départ.
Paragraphe court. Direct.
Décomposons. Table des requêtes : entrée utilisateur, ID utilisateur, contexte (disons, ID d’une transcription YouTube), statut en attente. Minimaliste. Réponses : sortie du modèle, JSON structuré peut-être, nombre de jetons parfois inclus. Échanges : la colle — request_id, response_id, input_tokens, output_tokens, model_used, statut. Une ligne par tour de chat. Interrogez pour les factures.
Le flux ? Insérez requête (en attente). Insérez échange (lié à la requête, en attente). Appelez le modèle. Insérez réponse. Mettez à jour l’échange : jetons, modèle, terminé. Échec ? Marquez-le. Toujours prêt pour l’audit.
Comment l’implémenter dans Supabase sans y laisser votre santé mentale ?
Supabase excelle là-dedans — Postgres en sous-sol, edge functions pour les appels. Prenez une UI de chat qui interroge des transcriptions YouTube.
Le code tombe pile : insertKnowledgeTranscriptChatRequest. Récupère user_id, transcript_id, content, met en attente. Retourne l’ID.
Puis insertKnowledgeTranscriptChatExchange : lie à request_id, user_id, en attente.
Le modèle s’active — disons GPT-4o-mini. La réponse arrive : mise à jour de l’échange avec response_id, jetons, modèle, complété.
Le client récupère responseId, tokens, modelUsed. Slice Redux normalisé — pas de service à coût supplémentaire. La session lit les coûts directement.
De la magie en action. Et ça scale — même forme pour les jobs d’idéation de blogs. Sujet, contexte ICP dans la requête. Idées structurées, jetons en réponse. L’échange lie tout. Dump Redux par ID. Cohérent.
Mais attention, hype corporate ? Que nenni, ce n’est pas Vercel qui vend des vecteurs. C’est du pragmatisme brut, dev-first. Pas de lock-in fournisseur. Postgres partout.
Fragment : Net.
Plus profond : les comptes de jetons sur échange font chanter les agrégats. « Dépense mensuelle de l’utilisateur X ? » SELECT SUM(input_tokens * price_per_million) FROM exchanges JOIN users… Fait. Les dashboards fleurissent.
Ou debug : « Pourquoi ce prompt a foiré ? » Ti
