Pezzo : gestion de prompts et observabilité LLM dans une pile auto-hébergée

Un registre de prompts qui vit hors du code

Le problème visé est classique : un prompt écrit en dur dans une fonction ne se modifie pas sans redéploiement, ne se compare pas à sa version précédente et ne se partage pas avec les personnes qui écrivent les instructions plutôt que le code. Pezzo place ces prompts dans un service central, avec un historique de versions et une livraison dite instantanée. Le README annonce aussi une réduction de coûts et de latence pouvant atteindre 90 pour cent. Ce chiffre vient de la page du projet et n'est accompagné d'aucun protocole de mesure dans le dépôt : à traiter comme une affirmation marketing, pas comme un résultat reproductible.

Le public visé est précis. D'un côté, les développeurs qui intègrent des appels à des modèles comme GPT-3 ou GPT-4 et qui veulent sortir la configuration des prompts du cycle de build. De l'autre, les équipes produit qui doivent modifier une instruction sans attendre une livraison. Le dépôt mentionne des clients Node.js, Python et LangChain, ce qui couvre les deux écosystèmes les plus courants pour ce type d'application. Une personne seule qui prototype un appel unique n'a rien à faire de cette machinerie.

Quatre briques open source et un schéma Prisma

Le README est explicite : Pezzo repose uniquement sur PostgreSQL, ClickHouse, Redis et Supertokens. La répartition des rôles n'est pas détaillée dans le matériel fourni, mais la présence simultanée d'une base relationnelle et d'une base colonnaire indique deux usages distincts. PostgreSQL porte vraisemblablement les données de configuration et de versionnement, tandis que ClickHouse absorbe les événements d'observabilité, qui sont volumineux et en ajout seul. Redis sert probablement de cache, ce qui recoupe la fonctionnalité de caching listée pour les trois clients. Supertokens gère l'authentification.

Le serveur est une application NestJS, puisque la commande de démarrage est npx nx serve server et que le dépôt est organisé en monorepo Nx avec un dossier apps/server. L'API exposée est GraphQL : le README recommande l'extension VSCode de support GraphQL et une commande de génération de types en continu. Le schéma est décrit par un fichier Prisma à l'emplacement apps/server/prisma/schema.prisma, ce qui signifie que toute évolution de structure passe par des migrations versionnées. La console, elle, tourne séparément sur le port 4200.

Cette architecture a une conséquence pratique : Pezzo n'est pas une bibliothèque que l'on ajoute à un projet existant. C'est un service avec sa propre base de données. Vous héritez de son exploitation.

Démarrage en développement, étape par étape

Le README donne une séquence précise. Les prérequis annoncés sont Node.js 18 ou plus récent et Docker. L'installation des dépendances se fait par npm install. Pezzo lit un fichier .env, et un fichier .env.docker distinct est nécessaire lorsque l'on passe par Docker ; le modèle de référence est .env.example.

Les dépendances d'infrastructure se lancent avec docker-compose -f docker-compose.infra.yaml up. C'est le point le plus lourd de la mise en route, puisqu'il démarre les quatre services cités plus haut. Ensuite, les migrations Prisma se déploient avec npx dotenv-cli -e apps/server/.env -- npx prisma migrate deploy --schema apps/server/prisma/schema.prisma. Le serveur démarre par npx nx serve server et l'on vérifie sa disponibilité sur http://localhost:3000/api/healthz.

Deux commandes concernent le confort de développement. npm run graphql:codegen:watch doit tourner dans un second terminal pour régénérer les types à chaque modification du schéma. La console se lance enfin avec npx nx serve console, accessible sur http://localhost:4200. Le README renvoie aussi vers une page dédiée pour exécuter la pile complète avec Docker Compose, sans en donner le contenu. C'est cette page qu'il faut lire avant de déployer, car la séquence ci-dessus décrit un environnement de développement, pas une mise en production.

Le versionnement des prompts n'est pas un détail

La fonctionnalité la plus intéressante du projet est aussi celle dont le dépôt dit le moins. Un registre de prompts versionné suppose de répondre à des questions que le README n'aborde pas : que se passe-t-il lorsqu'une version est supprimée alors que des requêtes en production la référencent, comment revenir en arrière sans redéployer, et comment un client met-il en cache une version dont il ne connaît pas encore l'existence. Le tableau des clients indique que le caching est disponible en Node.js, Python et LangChain, mais aucune règle d'invalidation n'est décrite dans le matériel fourni.

C'est une lacune réelle pour un usage en production. Une livraison instantanée signifie qu'un changement de prompt peut modifier le comportement d'une application sans passer par une revue de code ni par une étape de déploiement. Selon la façon dont votre organisation travaille, c'est soit l'argument principal, soit un risque de gouvernance. Le dépôt ne fournit aucun mécanisme d'approbation visible, aucune piste d'audit décrite, aucun contrôle d'accès documenté au-delà de la présence de Supertokens pour l'authentification.

Autrement dit, Pezzo déplace le problème plutôt qu'il ne le résout entièrement. Le prompt sort du code, mais il entre dans un système dont les règles de gestion restent à définir par l'équipe qui l'exploite.

Observabilité : ce que le dépôt ne permet pas de trancher

Pezzo se présente comme une plateforme d'observabilité, et la présence de ClickHouse dans la pile confirme qu'il y a bien une ingestion d'événements à volume. Le tableau des clients confirme que la fonctionnalité existe en Node.js, Python et LangChain. Au-delà de cela, le matériel disponible est mince.

Aucune information n'est fournie dans le README sur le format des traces capturées, sur la manière dont un appel de modèle est rattaché à une trace parente, ni sur ce qu'il advient des données lorsque la base ClickHouse grossit. Aucune politique de rétention n'est mentionnée. Pour une plateforme dont l'observabilité est l'un des deux piliers, c'est une zone d'ombre que la documentation externe devra combler. Le lecteur qui a besoin de savoir s'il peut corréler une trace Pezzo avec ses traces OpenTelemetry existantes devra chercher ailleurs que dans ce dépôt.

Le point à retenir n'est pas que la fonctionnalité est absente. Le tableau la liste pour les trois clients. Le point est que son coût d'exploitation, en volume de stockage et en maintenance de ClickHouse, n'est documenté nulle part dans le matériel fourni.

Face à un simple fichier de prompts versionné dans Git

L'alternative la plus directe n'est pas un concurrent commercial, c'est un dossier prompts/ dans votre dépôt, avec un fichier par prompt et un historique Git. La différence d'approche est nette. Git vous donne la revue, l'approbation, la traçabilité et le retour arrière, gratuitement et sans service supplémentaire. En échange, toute modification exige un commit et un déploiement, et les personnes non développeuses ne peuvent pas intervenir.

Pezzo inverse ce compromis. Il supprime la barrière du déploiement et l'accès pour les non-développeurs, mais il faut maintenir quatre services, un schéma Prisma, un serveur NestJS et une console. Une équipe de deux personnes qui modifie un prompt par mois n'y gagnera rien. Une équipe qui itère plusieurs fois par jour, avec des personnes produit dans la boucle, y trouvera un gain réel, à condition d'accepter la charge d'exploitation.

Il existe aussi des services hébergés qui couvrent le même terrain. Le projet propose d'ailleurs une offre cloud, citée dans le README. Le choix entre les deux se résume à une question de contrôle des données : avec l'auto-hébergement, les prompts et les traces restent sur votre infrastructure, mais vous en devenez responsable.

Licence, maintenance et coût réel

Le code source est publié sous Apache-2.0, ce qui autorise l'usage commercial, la modification et la redistribution, à condition de conserver les mentions de licence et d'avis. Cette licence contient une clause de brevets. Elle n'impose aucune obligation de publier vos modifications. Je ne donne pas de conseil juridique : pour un usage en entreprise, faites relire le fichier LICENSE et la politique de la marque par qui de droit.

Le coût de maintenance est le point le plus concret. Le dépôt n'a pas été archivé, mais la dernière publication listée est la v0.9.2 du 15 mai 2024, précédée de v0.9.1 la veille et de v0.9.0 le 28 avril 2024. Trois versions en moins d'un mois, puis rien dans la liste fournie. Le numéro de version reste en 0.x, ce qui signale une API non stabilisée. Une équipe qui adopte Pezzo aujourd'hui doit prévoir de suivre les migrations Prisma et les évolutions de schéma GraphQL à ses frais.

L'auto-hébergement déplace aussi la charge vers vos équipes : sauvegardes PostgreSQL, dimensionnement ClickHouse, persistance Redis, mise à jour de Supertokens. Rien de tout cela n'est décrit dans le README. C'est le prix à intégrer dans la décision, avant même de regarder les fonctionnalités.

Conclusion éditoriale

Pezzo convient aux équipes qui veulent garder leurs prompts et leurs traces LLM sur leur propre infrastructure, et qui acceptent de maintenir PostgreSQL, ClickHouse, Redis et Supertokens. Il ne convient pas à celles qui cherchent un service managé ou un support commercial garanti. Avant de vous engager, vérifiez la cadence réelle des publications depuis v0.9.2 (mai 2024), l'état de l'intégration LangChain et le contenu de .env.example, qui détermine la configuration des quatre dépendances.

Sources officielles

1. License: Apache-2.0
2. pezzolabs/pezzo on GitHub
3. Project website
4. README
5. Releases