Aller au contenu principal

Journal de bord · Phase 0 · 1/7

Pourquoi Aubia commence par une liste d'attente

Une page, un champ email, une promesse : la Phase 0 d'aubia.dev valide la demande réelle par une waitlist en double opt-in avant d'élargir le produit.

Publié le 13 juillet 20264 min de lecture
  • waitlist
  • product
  • architecture

La première incarnation publique d'Aubia tient en une page : un champ email et une promesse. Pas de pricing, pas de téléchargement, pas de création de compte. Cette Phase 0 a un seul travail : mesurer si l'orchestrateur d'agents IA que je développe répond à un besoin réel, avant d'y investir des mois supplémentaires.

J'aurais pu coder le desktop dans mon coin pendant six mois, puis annoncer. J'ai choisi l'inverse. La landing valide d'abord une intuition : d'autres développeurs ressentent-ils la même frustration que moi, celle de faire tourner plusieurs agents IA en alternance sans jamais les faire dialoguer ? Une liste d'attente répond à cette question tôt, et constitue au passage une base de contacts consentante et qualifiée pour le lancement de la beta 0.1. La note du développeur raconte d'où vient cette frustration.

Cette prudence répond à un risque documenté : le segment des orchestrateurs d'agents IA est encore immature, et l'adoption n'y prouve pas la monétisation. Un des orchestrateurs les plus populaires du segment a annoncé son arrêt en 2026 malgré une vraie traction. La liste d'attente sert à valider un intérêt qui tienne avant d'élargir le produit, plutôt que d'empiler des fonctionnalités que personne n'a demandé de payer.

Une page, une seule conversion

Le repo de la vitrine a démarré fin avril 2026, et cette discipline se lit dans le routage dès les premiers commits. Toutes les pages publiques vivent sous un préfixe de langue, et le seul verbe d'écriture exposé est la soumission du formulaire waitlist, qui part vers aubia.cloud.

Route::prefix('{locale}')
    ->where(['locale' => 'fr|en|es|de|it|pt'])
    ->group(function (): void {
        Route::inertia('/', 'welcome')->name('home');

        // Proxy waitlist vers aubia.cloud (BF-WB-001). Throttle nommé défini
        // dans bootstrap/app.php.
        Route::post('/waitlist', [WaitlistController::class, 'store'])
            ->name('waitlist.store')
            ->middleware('throttle:waitlist');
    });

Pas de tableau de bord, pas d'espace membre, pas d'API publique. La landing expose une home localisée, deux pages légales, les pages de confirmation, et ce point de soumission unique. Le préfixe de langue sert six locales, chacune avec sa propre URL indexable. Moins de surface, c'est moins de bugs et un message qui ne se dilue pas.

J'ai écarté l'idée de garder les boutons Télécharger et Créer un compte grisés d'un « Bientôt disponible ». Un CTA inactif posé à côté du bouton d'inscription actif crée une hésitation cognitive qui coûte des conversions : le visiteur se demande lequel choisir au lieu d'agir. Tant qu'aubia.cloud n'ouvre pas les comptes et que les binaires ne sont pas signés, ces boutons mèneraient vers du vide.

aubia.dev, aubia.cloud, aubia.app : une frontière par domaine

Le choix du domaine encode une frontière nette entre les briques d'Aubia. La vitrine et les emails vivent sur aubia.dev. L'application et son API vivent sur aubia.cloud, avec l'endpoint api.aubia.cloud qui reçoit les inscriptions. Le desktop occupera aubia.app.

Cette séparation garantit que le site public, exposé à tout l'internet, ne partage aucune infrastructure sensible avec l'app. La landing reste une coquille légère et sans état, pendant que la logique métier et les données restent confinées côté cloud. Quand vous soumettez votre email sur aubia.dev, la requête traverse la frontière vers api.aubia.cloud, et rien de personnel ne se dépose au passage sur la vitrine. Je détaille ce proxy plus loin dans la série.

Des mesures sans cookies ni bannière

Piloter une campagne de préinscription exige de savoir ce qui fonctionne, sans trahir la confiance des visiteurs. J'utilise Fathom Analytics, sans cookies et sans traçage individuel. Quelques événements custom suffisent à lire le parcours : l'entrée du formulaire dans le viewport, la soumission réussie, une erreur éventuelle, l'arrivée sur la page de confirmation. Aucun profil, aucune revente de données, aucune bannière de consentement à imposer.

La landing affiche aussi un compteur de personnes déjà confirmées, récupéré côté serveur depuis aubia.cloud. Un chiffre réel, jamais une projection : il ne compte que les inscriptions confirmées par double opt-in, jamais les emails en attente de validation. Cette exigence de sobriété guide aussi la vision du produit : un outil qui ajoute de la valeur sans confisquer votre attention.

La première pierre

Une vitrine minimale, un seul objectif, une frontière stricte avec le cloud : voilà la première pierre. Les articles suivants entrent dans la technique : la stack qui sert cette page aux moteurs de recherche, puis l'architecture d'une landing volontairement dépourvue de base de données.

Pour être prévenu à l'ouverture de la beta 0.1, rejoignez la liste d'attente.

Ce chantier se raconte ici, article après article. Embarquez dans l'aventure : vos retours dessineront la suite.

Rejoindre la liste d'attente