Valha s'installe dans les sessions IA que votre équipe utilise déjà et transforme le travail qui mérite d'être gardé en une page sur laquelle on agit, le contexte dont un agent a besoin pour continuer, et un Blueprint pour le cas suivant.
Claude
CodexChatGPTVotre meilleur travail finit dans un chat.
Vous le résolvez dans l'assistant que vous utilisez déjà, et la réponse reste dans une session que personne d'autre ne peut ouvrir.
CLAUDE86 MESSAGES · 12 QUERIES · AUTO SCROLLING ↓Audit the account-creation funnel for the last 30 days. Compare Google SSO, email + password, verification, and recovery. Keep user details private.
Mapped the account-creation paths and source systems
I’ll rebuild the funnel from raw events instead of trusting the aggregate signup rate. That lets us see whether the loss happens before authentication, during verification, or after the account exists.
Plan:
Start from Metabase card #1842, then verify every step against prod_analytics.events_* in BigQuery.
Joined the business funnel to raw warehouse events
First pass: 124,800 signup page views split into two primary paths. Google receives 72,410 starts. Email + password receives 52,390 starts.
The 41-point gap is real enough to investigate, but not clean enough to explain yet.
Resolve anonymous IDs after OAuth redirects. Remove internal users, automated tests, bots, duplicated callbacks, and clock drift.
Rebuilt identity and removed invalid sessions
I joined pre-auth device IDs to server-side account creation and deduplicated retries inside a 30-minute window. That excludes 3,842 sessionsfrom the comparison.
Google remains stable at 84% completion. Email + password lands at 43%, so the difference is not an identity artifact.
Break the password path into form submit, verification delivery, verification click, and final account creation.
Reconstructed the password branch event by event
From 52,390 starts, 39,180 people submit valid credentials. The email provider reports 38,460 verification emails delivered.
The dominant loss sits between delivery and a successful verification return.
Confirm that against the email delivery logs. Quantify users who received the message but never verified.
Matched delivery logs to verification returns
15,520 users received the verification email but never completed verification. That is a 40% loss after confirmed deliveryand the largest controllable leak in the signup funnel.
Delivery failures matter, but they are not the main constraint. The return path, link context, and reminder behavior deserve the next intervention.
Password resets use the same email infrastructure. Check them, but do not mix recovery into signup conversion.
Separated password recovery from account creation
Recovery shows 11,430 requests, 11,120 delivered messages, and 6,280 completed resets. It confirms that returning from email is difficult, but it remains a separate funnel with a different user intent.
Stress-test the leak by device, region, and verification delay. Did reminder copy materially fix it?
Stress-tested the leak across enterprise cohorts
Completion improved from 55.8% to 61.7% after reminder copy changed. The same delivery-to-verification drop remains the largest loss across desktop, mobile, North America, and Europe.
The evidence supports prioritizing verification. It does not yet prove which UI or email change will recover the loss, so the next move should be instrumented.
Give me the decision, the caveat, and everything the next engineer needs to reproduce this analysis.
Condensed the investigation into a reproducible decision
Key finding: Password verification is the signup funnel’s largest controllable leak.
Decision: fix the verification return path before redesigning Google SSO. Keep recovery separate, preserve the query jobs, and revalidate the result after the intervention.
La réponse reste dans un chat privé.
Aucune page ne garde la réponse, les preuves ni la manière dont on s'y est pris.
La personne suivante reconstruit le contexte depuis zéro.
Ces huit pages sont réelles, pas des captures. Un rapport de données, une proposition client, un rapport annuel, un post-mortem d'incident, un point pour le board, un plan de voyage, un bilan de campagne, un choix de local. Ouvrez-en une et vérifiez les preuves qui la soutiennent.
Chacune est une page Valha, rendue par le produit. Les entreprises, les personnes et les chiffres qu'elles contiennent sont inventés ; les lieux et les photographies sont réels.
Exemple 1 sur 8.
EXEMPLE01 / 08
Vous terminez le travail dans l'assistant que vous utilisez déjà.
Chaque section peut porter sa propre provenance : la question posée, ce qui a été compté, ce qui a été exclu, et d'où viennent les données.
Une page peut garder la partie reproductible : la séquence, les vérifications, les réserves, sans les données d'entrée privées.
Ce que votre équipe ouvre. Une page composée avec la conclusion en haut, sous une forme exploitable par quelqu'un d'extérieur au travail.
Assez de contexte publié pour qu'une personne ou un assistant reprenne le travail plus tard : requêtes, définitions, sources, réserves.
L'approche seule, détachée du cas qui l'a produite, pour que la fois suivante ne démarre pas de rien.
Quand un travail mérite d'être refait, gardez-le comme Blueprint : la séquence, les requêtes, les vérifications. Votre assistant cherche dans la bibliothèque et en charge un avant de commencer.
Un Blueprint appartient à l'espace de travail qui l'a créé. Rien n'en sort, et le cas qui l'a produit reste derrière.
Chaque révision est conservée, donc un Blueprint qui change reste lisible tel qu'il tournait le trimestre dernier.
Un Blueprint enregistre quand il a été chargé et quand quelqu'un signale qu'il a marché, donc la bibliothèque reflète la pratique plutôt que les intentions.
valha est un serveur MCP hébergé. Pointez vers lui l'outil dans lequel vous travaillez déjà, connectez-vous une fois, et toutes les sessions suivantes peuvent publier et retrouver.
Disponible sur toutes les offres. Free est limité à un connecteur personnalisé, et sur Team ou Enterprise c'est un propriétaire qui l'ajoute pour l'organisation.
Dans les réglages, sous Personnaliser, choisissez Connecteurs. Le bouton Ajouter est en haut à droite.
Deux champs : le nom affiché dans votre liste de connecteurs, et l'URL du serveur MCP distant. Les paramètres avancés restent vides.
Autorisez une fois dans votre navigateur. valha répond dès le message suivant.
https://valha.link/mcpAvec l'accès à l'espace de travail, un assistant cherche dans les pages publiées et récupère leurs preuves. Valha ne reçoit que les demandes, arguments et contenus que vous autorisez les outils à lire ou modifier.
Prochaine étape : faire remonter le Blueprint pertinent, la décision contradictoire ou l'effort dupliqué pendant que le travail se fait, dès que c'est possible sans deviner. Ce n'est pas dans le produit aujourd'hui.
Valha donne aux équipes un nouveau type de document d'entreprise. Chaque page conserve un travail IA utile pour qu'il puisse être lu, vérifié et réutilisé. Ensemble, ces pages rendent la contribution de l'IA tangible à l'échelle de l'organisation.
Les pages publiées montrent les décisions, les analyses, les rapports et les Blueprints que les personnes ont choisi de préserver, pas les sessions privées qui restent derrière.
Les pages et les Blueprints validés montrent quel travail utile peut servir au prochain projet au lieu de disparaître avec le chat.
Les manques dans le travail partagé et réutilisable peuvent ouvrir une discussion sur les freins et l'accompagnement, sans noter les personnes.
Valha ne surveille pas les conversations privées et ne classe pas les employés. Toute vue à l'échelle de l'organisation resterait privée et n'utiliserait que le travail que les personnes choisissent de publier.
Team est la première offre payante. Enterprise se fait sur devis.
Pour une personne qui publie son propre travail
Par personne
Pour les équipes dont le travail doit circuler
Par utilisateur et par mois, facturation annuelle. 19 € en mensuel.
Pour les organisations avec des exigences de sécurité et d'accès
Sur devis
Une page existe parce que son auteur l'a validée. Le travail privé n'est jamais promu par défaut.
Les assistants atteignent Valha par un endpoint MCP distant protégé par OAuth, limité aux espaces de travail que vous autorisez.
Quand une page exécute du code, elle l'exécute dans un bac à sable isolé du réseau. Elle peut lire les données publiées dans cette section et rien d'autre.
Tout ce que fait Valha découle d'une seule promesse, et chaque fonctionnalité est construite pour qu'elle continue de tenir.
Ce qui existe aujourd'hui, ce qui n'existe pas, et où se situe la frontière.
Non. Valha ne reçoit que les demandes, arguments et contenus que vous autorisez les outils à lire ou modifier. L'assistant garde le reste de votre conversation privée, et rien n'est publié sans votre instruction.
Connecter un assistant compatible, créer et mettre à jour des pages, publier des liens, travailler dans les espaces auxquels vous avez accès, et chercher ou récupérer des pages publiées via les outils MCP distants de Valha.
Non. Valha fait une seule chose : transformer un travail IA terminé en une page que vous pouvez envoyer. Tout le reste de ce que votre équipe écrit reste où il est déjà.
Une méthode dont vous avez décidé qu'elle valait la peine d'être gardée : les étapes, les requêtes, les vérifications et les réserves, sans le cas qui l'a produite. Votre assistant peut chercher dans la bibliothèque et en charger un avant d'attaquer une tâche similaire.
Non. C'est l'auteur qui décide ce qui mérite d'être gardé. Une page peut conserver les étapes reproductibles, les requêtes, les vérifications et les réserves, mais le travail privé ne devient pas automatiquement du savoir d'entreprise.
Avec l'accès à l'espace de travail, oui : il cherche dans les pages publiées et récupère les preuves qui les soutiennent via les outils MCP distants de Valha. Il n'atteint ni une session privée, ni un brouillon non publié, ni un espace qu'on ne lui a pas donné.
Aujourd'hui Claude, Codex, ChatGPT et Gemini. Valha se connecte via MCP distant protégé par OAuth plutôt que par un import propre à un fournisseur, donc tout assistant qui gère les connecteurs MCP distants peut publier.
Une minute pour le compte. Ensuite vous ajoutez un connecteur MCP distant, https://valha.link/mcp, et vous vous connectez à travers lui. L'endroit où coller cette URL change selon l'assistant. Après ça vous publiez depuis le chat où vous étiez déjà.
Alors cet assistant ne peut pas encore publier vers Valha, et il n'y a pas de contournement, autant le dire. La politique des connecteurs dépend en général de qui administre votre abonnement IA. Lire et partager des pages publiées ne demande aucun connecteur.
Uniquement dans un bac à sable isolé du réseau. Elle voit les données publiées dans cette section pour pouvoir les afficher, mais elle ne peut ni les envoyer ailleurs ni atteindre autre chose. La plupart des pages n'en ont jamais besoin.
Quelque chose que vous devriez sinon réexpliquer en réunion, ou retaper pour un collègue. Un rapport, un post-mortem, une décision, une analyse.
Le prix affiché est le prix de lancement : 15 € par utilisateur et par mois en facturation annuelle, ou 19 € en mensuel. Team se déploie d'abord avec des pilotes menés par le fondateur, donc ce qui est en avance de phase c'est l'accompagnement, pas le tarif.
Vous venez avec un workflow assisté par IA que votre équipe fait déjà tourner. En 30 minutes on montre comment son résultat utile devient une page maîtrisée, puis on passe en revue les accès, la provenance et ce que Valha sait faire aujourd'hui. C'est une évaluation produit, pas un engagement.
Elle s'ouvre avec le brief déjà écrit : lire Valha comme le ferait un CTO, dire où ça crée de la valeur, et nommer les risques à vérifier en premier.
Connectez un assistant et publiez la prochaine chose que vous terminez. Un message, et votre équipe a la page.
Gratuit, sans carte
