Langfuse v4 : le cloud bascule le 16 novembre, ce qu'il faut vérifier avant

Langfuse enregistre ce que fait une application IA : chaque appel au modèle, son coût, sa durée, sa réponse. On s'en sert pour comprendre une erreur, suivre la facture et évaluer la qualité. Le dépôt est sous licence MIT, à l'exception des dossiers ee. Sa version 4, annoncée le 17 août 2026, impose une échéance aux utilisateurs du service en ligne.

Ce que change la v4

Jusqu'ici, traces et observations étaient stockées dans des tables séparées, qu'il fallait rapprocher à chaque lecture. La v4 les réunit dans une seule table d'observations, où chaque observation terminée est écrite une fois et n'est plus modifiée.

L'éditeur annonce des tableaux qui se chargent en millisecondes au lieu de secondes sur de gros volumes, et des tableaux de bord au moins dix fois plus rapides sur de longues périodes dans les grands projets. Ces chiffres viennent de Langfuse, sans protocole de mesure publié sur la page.

Sur Langfuse Cloud : échéance au 16 novembre 2026

Jusqu'à cette date, la v3 et la v4 cohabitent. Ensuite, le service ne fonctionne plus qu'en v4 : anciennes API, anciennes fonctions et ancienne ingestion sont retirées.

À faire avant :

• ouvrir l'assistant de migration dans la barre latérale, accessible aux propriétaires de l'organisation ; il liste, projet par projet, les actions détectées sur les kits de développement, les évaluateurs, les API et les intégrations ;
• mettre à jour les kits : Python 4.7.0 ou plus récent, JS/TS 5.4.0 ou plus récent ;
• vérifier tout script maison qui lit les données par l'API.

D'après Langfuse, la plupart des projets n'ont rien à faire, et les projets récents sont déjà en v4. La page n'énumère pas les fonctions retirées côté cloud : l'assistant fait foi.

En auto-hébergement : pas de date, mais un vrai chantier

Aucune bascule n'est imposée, et la v3 reçoit des correctifs de sécurité jusqu'à fin janvier 2027. L'architecture reste la même, sans nouveau service. Le guide de migration fixe toutefois des prérequis :

• ClickHouse 25.12 au minimum, PostgreSQL 15 (16 recommandé), Redis 7.0 (7.2 recommandé) ;
• des droits supplémentaires pour l'utilisateur ClickHouse, sans quoi les migrations échouent ;
• environ trois fois le volume actuel des données ClickHouse en espace disque si vous lancez la reprise automatique de l'historique ;
• toutes les migrations de fond de la v3 terminées avant de commencer.

Ce dernier point est le plus risqué : selon le guide, si l'une d'elles n'est pas terminée, les lignes jamais copiées sont supprimées définitivement.

Par défaut, le serveur v4 n'écrit que dans les nouvelles tables. Les données envoyées par des kits trop anciens (Python v2 et antérieurs, JS/TS v3 et antérieurs) sont alors refusées, et une série d'anciennes routes de lecture renvoient une erreur 404. Deux modes transitoires permettent d'étaler la migration ; l'un d'eux écrit en double, ce qui double à peu près la charge d'écriture et le stockage. La reprise de l'historique prend, selon le volume, de quelques minutes à plusieurs jours.

Les limites

• Revenir en arrière ne se résume pas à relancer l'ancienne image : il faut ramener le schéma ClickHouse à une version antérieure avec un outil fourni, ou restaurer une sauvegarde.
• Les métadonnées de trace ne sont pas recopiées lors de la reprise de l'historique.
• Les évaluateurs par modèle définis au niveau de la trace cessent de fonctionner dans le mode par défaut.

Notre lecture

Sur le cloud, la vérification prend quelques minutes : ouvrez l'assistant de migration, relevez les versions des kits dans vos applications, et traitez les actions listées avant le 16 novembre. Après cette date, une application restée sur un ancien kit risque de ne plus rien remonter.

En auto-hébergement, prenez le temps que l'éditeur vous laisse : mettez d'abord ClickHouse à niveau, ce qui peut se faire en restant en v3, sauvegardez, puis répétez la migration sur une copie.