Fin 2025, Claude et moi avons entrepris de construire la plateforme ultime d'expérience client. Nous l'avons appelée DEBLO Intelligence -- la « première plateforme CxPaaS IA-Mesh omnisciente au monde ». Nous allions remplacer Intercom, Zendesk, Freshdesk, HubSpot, Slack, Notion, Google Workspace et Jira. Avec un seul produit. Propulsé par six modèles IA tournant simultanément à travers un noyau intelligent unique.
Nous avons construit une landing page de 3 318 lignes. Nous avons conçu un tableau de bord avec 17 modules. Nous avons modélisé 50+ agents IA avec des personnalités. Nous avons écrit un schéma avec 25 relations à travers 15 tables de base de données. Nous avons créé une interface LiveChat à 4 colonnes qui suivait le sentiment client, la valeur vie, le risque de churn et les opportunités d'upsell en temps réel.
Nous avions 4 routes API fonctionnelles.
La date de lancement -- le 1er décembre 2025 -- est passée. Le projet est resté intact pendant des mois. Nous n'avons jamais livré quoi que ce soit à un seul utilisateur.
Puis, cette semaine, j'ai construit un widget helpdesk IA pour sh0.dev en un après-midi. Neuf fichiers. Deux tables de base de données. Un endpoint de streaming. Il fonctionne. Il est en production. Les visiteurs l'utilisent en ce moment.
Cet article raconte pourquoi une approche a échoué et l'autre a réussi, et ce que je compte faire à ce sujet.
Ce que nous avons réellement construit
Le projet devenu 0seat.dev (initialement DEBLO Intelligence) vit dans un monorepo avec trois applications : une API, un tableau de bord et un site marketing public. Voici un inventaire honnête de ce qui existe.
L'API (ElysiaJS + Bun + InstantDB)
Ce qui fonctionne : - Authentification par code magique (génère un code à 6 chiffres, le vérifie, émet un JWT) - Gestion des fournisseurs SMS (CRUD pour l'admin, listing pour les tenants) - Envoi de SMS (valide la configuration, vérifie les limites, crée un enregistrement de message) - Health check
Ce qui ne fonctionne pas : - Le code magique est affiché dans la console. Aucun e-mail n'est envoyé. - L'envoi de SMS est simulé. Aucune API de fournisseur n'est appelée. - Il n'y a pas d'endpoint de conversation. Pas d'endpoint de message. Pas d'endpoint de contact. Pas d'endpoint de campagne. - Le schéma de 15 tables définit des conversations, messages, contextes IA, analyses IA, réponses IA, retours IA, campagnes, métriques quotidiennes, métriques IA -- aucun n'a de route API.
Quatre routes. Quinze tables. Le modèle de données a été conçu pour un produit qui n'existait pas encore.
Le tableau de bord (Solid.js + Tailwind)
Ce qui fonctionne : - Un superbe tableau de bord d'accueil avec 17 cartes de modules affichant des métriques en temps réel - Une boîte de réception unifiée avec un layout à 3 colonnes, le threading des conversations et des suggestions IA - Une page LiveChat IA avec un layout à 4 colonnes, le suivi multi-modèle des agents, un panneau d'intelligence client - Une page de workflow d'approbation avec recommandations IA - Mode sombre, chargement paresseux, système de plugins, design responsive
Ce qui ne fonctionne pas : - Chaque nombre sur chaque écran est codé en dur. Les métriques se rafraîchissent toutes les 3 secondes -- elles génèrent des nombres aléatoires, pas de vraies données. - La boîte de réception affiche des conversations factices avec des messages factices de clients factices. - Le LiveChat IA affiche « Claude Sonnet 4 : 89 actifs, 94 % de succès » -- ce sont des littéraux de chaîne. - Sept modules sont des pages placeholder avec un seul paragraphe de description. - Il n'y a aucune intégration API. Le tableau de bord ne récupère rien depuis l'API. Il n'écrit rien dans InstantDB. C'est un prototype statique qui s'anime.
Le site marketing (Solid.js + Tailwind)
Ce qui fonctionne : - Cinq pages marketing complètes : accueil, tarifs, fonctionnement, agents IA, architecture AI-Mesh - Un assistant IA flottant avec des réponses basées sur des mots-clés (pas de vraie IA -- du pattern matching) - Un modal de prélancement qui capture les e-mails dans localStorage - Quatre niveaux de tarifs (0 $ / 49 $ / 299 $ / 499 $) - Mode sombre, design responsive, typographie professionnelle
Ce qui ne fonctionne pas : - Le compteur « 2 847 décisions IA prises aujourd'hui » s'incrémente aléatoirement toutes les 2 secondes - « Rejoignez 847 entreprises déjà sur la liste » est une chaîne codée en dur - Les e-mails sont stockés dans localStorage. Ils ne vont nulle part. - L'assistant IA fait du matching de mots-clés et retourne des réponses prédéfinies. Aucun LLM n'est appelé.
Pourquoi c'est arrivé
Je ne vais pas accuser le scope creep comme si c'était quelque chose qui nous était arrivé. Claude et moi nous sommes fait ça à nous-mêmes. Voici comment.
Le piège de la vision
Nous avons commencé avec une idée légitime : les entreprises en Afrique utilisent plus de 10 outils pour gérer la communication client. WhatsApp pour le chat. Le SMS pour les notifications. L'e-mail pour la communication formelle. Des tableurs pour le suivi. Des outils séparés pour chaque canal, chacun avec son propre login, sa propre IA, sa propre facture mensuelle.
L'idée était de tout unifier. Une plateforme, une IA, une facture. C'est un vrai problème avec un vrai marché.
Mais au lieu de construire la seule chose qui prouverait l'idée -- un widget de chat qui fonctionne réellement -- nous avons construit le site marketing qui vendrait le produit fini. Nous avons conçu le tableau de bord qui gérerait les 17 modules. Nous avons modélisé la base de données qui stockerait tous les types de données dont la plateforme aurait jamais besoin.
Nous avons construit la brochure avant de construire le produit.
Le problème de la gravité fonctionnelle
Une fois que vous avez un tableau de bord à 17 modules sous les yeux, chaque module vous attire. « La boîte de réception est superbe, mais il lui faut de vraies conversations. Mais les conversations ont besoin de contacts. Mais les contacts ont besoin d'un CRM. Mais le CRM a besoin de campagnes. Mais les campagnes ont besoin de SMS. Mais les SMS ont besoin de la gestion des fournisseurs. »
Chaque fonctionnalité justifiait la suivante. La chaîne de dépendances grandissait dans toutes les directions. Nous étions toujours à une fonctionnalité de pouvoir démontrer quelque chose de réel.
Après des mois de travail, nous avions zéro utilisateur, zéro donnée réelle, zéro hypothèse validée, et une landing page de 3 318 lignes promettant des choses que nous ne pouvions pas livrer.
La séduction esthétique
Je vais être honnête à ce sujet : le tableau de bord était magnifique. L'interface LiveChat à 4 colonnes avec suivi du sentiment et prédiction du churn était la plus belle chose que Claude et moi avions jamais construite. Chaque fois que je l'ouvrais, j'avais le sentiment de construire quelque chose d'important.
Ce sentiment était le piège. La qualité esthétique du prototype créait une fausse impression de progrès. Nous ne faisions pas de progrès. Nous faisions des pixels.
Ce qui a changé cette semaine
Cette semaine, j'avais besoin d'un helpdesk pour sh0.dev. L'instinct était de regarder la codebase de 0seat.dev -- nous pouvions sûrement extraire le module LiveChat et le livrer.
J'ai ouvert le code. Le module LiveChat faisait plus de 800 lignes de Solid.js rendant des données factices codées en dur. Il dépendait de @deblo/ui-kit, @deblo/contexts, @deblo/plugins, @deblo/ai, @deblo/instant-client et @deblo/shared-components. Il ne pouvait pas être extrait sans le monorepo entier.
Alors je l'ai construit de zéro. En une session. Pour sh0.dev.
La comparaison est instructive :
| LiveChat 0seat.dev | Helpdesk sh0.dev | |
|---|---|---|
| Lignes de code | 800+ (tableau de bord) + 0 (API) | 490 (widget) + 200 (endpoint) |
| Routes API | 0 | 1 |
| Tables de base de données | 15 (définies) / 0 (utilisées) | 2 (définies et utilisées) |
| Intégration IA | Données factices | Vrai streaming API Anthropic |
| Authentification | JWT (pas de livraison d'e-mail) | Non nécessaire (widget public) |
| Conversations | Tableau codé en dur | PostgreSQL avec persistance complète |
| Temps de construction | Des mois | Un après-midi |
| Utilisateurs | 0 | En production sur sh0.dev |
Le helpdesk de sh0.dev est moins bon dans toutes les dimensions sauf celle qui compte : il fonctionne. De vrais visiteurs posent de vraies questions. Une vraie IA génère de vraies réponses. De vraies conversations sont stockées dans une vraie base de données. Un vrai admin peut lire de vraies transcriptions.
Le plan : 0seat.dev en 7 jours
La codebase de 0seat.dev n'est pas sans valeur. Le modèle de données est réfléchi. Les composants UI sont bien conçus. L'architecture multi-tenant est solide. Ce qui manque, c'est la discipline sur ce qui sort en premier.
Voici ce dont 0seat.dev a besoin pour se lancer en 7 jours :
Jour 1-2 : le widget
Un widget JavaScript intégrable que n'importe quel site peut ajouter avec une seule balise <script>. Il ouvre un panneau de chat, envoie des messages à l'API 0seat et streame les réponses IA. C'est le widget helpdesk de sh0.dev, extrait et rendu multi-tenant.
Jour 3-4 : la boîte de réception L'UI existante de la boîte de réception, débarrassée des données factices et connectée à de vrais endpoints API. Un agent se connecte, voit de vraies conversations de vrais visiteurs, peut lire les transcriptions et répondre. Deux tables de base de données : conversations et messages. Rien d'autre.
Jour 5 : l'onboarding Un tenant s'inscrit, obtient une clé API, obtient un code d'intégration du widget. Il le colle sur son site. Les conversations commencent à affluer. C'est l'intégralité de l'onboarding.
Jour 6 : la facturation Intégration Stripe. Niveau gratuit avec limites. Niveau payant sans limites. Facturation à l'usage sur les tokens IA. Rien de plus.
Jour 7 : le lancement Déployer. Annoncer. Obtenir les 10 premiers clients payants.
Tout le reste -- campagnes, approbations, tâches, notes, messagerie, tableurs, présentations, drive, 50 agents IA, routage multi-modèle, suivi du parcours de sentiment, détection du risque de churn -- c'est pour après le lancement. Pas après le MVP. Après le lancement. Ces fonctionnalités se construisent quand les clients les demandent, pas quand j'imagine qu'ils pourraient les vouloir.
La leçon
La leçon n'est pas « commencez petit ». Chaque fondateur sait qu'il faut commencer petit. La leçon, c'est que la qualité esthétique n'est pas la qualité produit. Un prototype magnifique avec des données factices n'est pas 80 % d'un produit -- c'est 0 % d'un produit. Les 20 % restants ne sont pas du polish. Les 20 % initiaux consistent à rendre quelque chose de réel.
Construire le helpdesk de sh0.dev en un après-midi m'a appris davantage sur ce que 0seat.dev doit devenir que des mois passés à concevoir le tableau de bord parfait. Les contraintes étaient instructives : pas d'auth (c'est public), un seul modèle (Haiku, le moins cher), un seul endpoint (POST /api/ai/helpdesk), un seul composant (HelpdeskWidget.svelte). Chaque contrainte a forcé une décision. Chaque décision a fait avancer le produit.
0seat.dev n'a pas besoin de 17 modules. Il a besoin d'un widget qui fait disparaître la question d'un visiteur et d'une boîte de réception qui montre au propriétaire d'entreprise ce que ses visiteurs demandent.
Tout le reste est une demande de fonctionnalité d'un client que nous n'avons pas encore.
Le plan de refactoring de 0seat.dev est publié ici. Il contient le plan d'implémentation jour par jour, les choix de stack technique et le périmètre exact pour le lancement en 7 jours.