Passer au contenu principal

Sept jours pour expédier

Comment nous avons transformé une plateforme d'entreprise en un produit grand public en une semaine.

De l'entreprise au consommateur en une semaine.

7

Jours pour expédier

97

Modèles LLM disponibles

9

Langues prises en charge

3

Fournisseurs de facturation

15 février 2026. Un samedi. Nous avions une plateforme d’entreprise que nos clients B2B utilisaient depuis des mois. Des agents IA en sandbox, 97 modèles LLM, gestion des espaces de travail, toute la pile. Ce qui nous manquait, c’était un produit qu’une seule personne pouvait s’inscrire et commencer à utiliser en moins d’une minute.

Nous avions observé les chiffres d’OpenClaw pendant un certain temps. 157 000 étoiles sur GitHub. Des milliers d’utilisateurs actifs quotidiens. Une communauté qui continue de croître peu importe le nombre d’avis de sécurité publiés. La demande est réelle et ne ralentit pas. Les gens veulent des agents IA autonomes. Ils veulent installer un outil, le pointer vers un problème, et s’en aller.

Mais nous continuions à voir le même schéma dans nos appels de vente d’entreprise. Les prospects disaient : “Nous avons essayé OpenClaw en interne. C’était génial jusqu’à ce qu’un agent exécute rm -rf sur un volume partagé.” Ou : “Nous adorions la flexibilité mais nous n’avons pas pu passer l’examen de sécurité.” L’appétit était là. La confiance ne l’était pas.

C’est là que tout a cliqué. Nous avions déjà la version sécurisée. Notre plateforme d’entreprise exécute chaque agent dans un environnement E2B isolé. Pas d’accès système brut, pas de clés API en clair, pas de piège où l’agent peut faire ce qu’il veut. Le compromis est un peu moins de flexibilité — vous ne pouvez pas installer des paquets système arbitraires ou monter votre répertoire personnel. Mais vous ne pouvez pas non plus effacer accidentellement votre système de fichiers ou divulguer des identifiants à une compétence malveillante.

La question n’était pas de savoir s’il fallait créer un produit pour les consommateurs. C’était de savoir si nous pouvions simplifier la complexité d’entreprise assez rapidement pour en expédier un. Nous nous sommes donné sept jours.

Ce qui a été supprimé

Les deux premiers jours ont été consacrés à la soustraction, pas à l’ajout.

Les groupes ont été les premiers. Dans la version entreprise, chaque utilisateur appartient à une organisation, chaque organisation a des rôles, chaque rôle a des permissions. Pour un produit de consommation, vous êtes juste vous. Un compte, un espace de travail, vos affaires. Nous avons construit le système de variantes pour supprimer cette couche entière au moment de la construction — le code existe toujours pour les clients d’entreprise, il ne se compile simplement pas dans le bundle consommateur.

Les intégrations système internes ont suivi. Webhooks Jira, importations de pages Confluence, flux SSO personnalisés — tous réservés à l’entreprise. La version consommateur se connecte aux outils que les individus utilisent réellement : Gmail, Slack, Notion, GitHub.

Le tableau de bord admin est resté réservé à l’entreprise. Aucun consommateur n’a besoin d’un panneau d’analyse d’utilisation avec des décompositions d’équipe. Ils ont besoin d’une barre latérale qui montre leur solde de crédit et d’un bouton pour en acheter plus.

Nous aurions pu forker le dépôt. Chaque instinct dit de le forker, d’avancer vite, de nettoyer plus tard. Nous ne l’avons pas fait. Au lieu de cela, nous avons construit une séparation des chemins de code dans la base de code existante. LikeClaw, Dashboard, FulDive — trois produits, un dépôt, différentes configurations d’environnement. Chaque patch de sécurité, chaque correction de performance, chaque nouveau modèle touche toutes les variantes simultanément. Le coût est un peu plus de complexité dans la construction. Le bénéfice est de ne jamais avoir à porter en arrière une seule ligne.

Facturation consommateur de zéro

Les clients d’entreprise paient par facture. Net 30, bons de commande, tout le rituel. Les consommateurs paient avec leur pouce sur un écran de téléphone.

Nous avions déjà intégré Stripe et Google Play grâce à un travail antérieur. Mais Apple n’allait pas attendre. Si vous voulez que les utilisateurs iOS achètent des crédits, vous avez besoin de vérification de reçu de l’App Store, d’une interface utilisateur de pack de crédits qui a du sens à côté de la version Play Store, et d’un auto-rafraîchissement pour que la barre latérale se mette à jour au moment où une réponse LLM arrive.

Marina a construit l’intégration de facturation de l’Apple Store en trois jours. Point de vérification. Tuiles de pack de crédits. Configurations d’utilisateur de test pour la révision de l’App Store. Trois fournisseurs de facturation, un système de crédit unifié. Le genre de plomberie qui est invisible quand ça fonctionne et catastrophique quand ça ne fonctionne pas.

Inscription en un clic

Les clients d’entreprise reçoivent un appel de vente, un contrat, un compte provisionné. Les consommateurs obtiennent un bouton Google.

Google OAuth a été intégré le 18 février. Le flux : le frontend redirige vers le backend, le backend gère la poignée de main Google, le rappel redirige vers le frontend avec un cookie de session. Un décorateur @Public sur le point de rappel afin que le middleware d’authentification ne rejette pas une redirection OAuth non authentifiée. Mise en cache des jetons avec des réanimateurs de date pour que les identifiants expirés ne passent pas.

Deux jours de travail. Le résultat : un clic pour s’inscrire. Pas de mots de passe, pas de vérification par e-mail, pas de “vérifiez votre boîte de réception.” Le flux SSO d’entreprise a douze champs de configuration. Le flux consommateur a un bouton.

Le problème de l’onboarding

C’est là que le passage de l’entreprise au consommateur devient difficile.

Les utilisateurs d’entreprise sont onboardés par des humains. Un ingénieur de solutions les guide à travers la configuration de l’espace de travail, connecte leurs intégrations, configure leur premier agent. Cela prend un après-midi. Personne ne se plaint car le contrat est déjà signé.

Les utilisateurs consommateurs ont soixante secondes avant de partir. Peut-être moins.

L’ancien onboarding était une superposition modale. Elle apparaissait, vous demandait ce que vous vouliez faire, puis disparaissait. Bien pour quelqu’un qui avait déjà eu une réunion sur le produit. Useless pour quelqu’un qui vient de cliquer sur un lien.

Nous l’avons arraché. Nous avons construit un itinéraire dédié /onboarding avec un assistant multi-écrans. L’écran principal montre des cartes de scénario : automatisation Gmail, recherche approfondie, analyse de code. Chaque carte a une puce d’engagement — “Pas de configuration,” “OAuth requis,” “Jeton API” — pour que vous sachiez à quoi vous vous engagez avant de vous engager. L’écran de sélection des compétences montre des compétences sélectionnées avec des comptes de téléchargement, des évaluations par étoiles et des informations sur l’auteur. Preuve sociale intégrée dans les premières soixante secondes.

Le truc qui a tout lié : auto-soumission. Lorsque vous terminez le flux d’onboarding, votre scénario sélectionné s’injecte directement dans le chat comme un prompt. Pas de copier-coller, pas de moment “et maintenant quoi”. Vous terminez l’onboarding et l’agent est déjà opérationnel.

Neuf langues, un jour

21 février. Marina a ajouté l’allemand, l’espagnol, le français, le coréen, le portugais et le portugais brésilien au frontend. Six langues en une seule journée. Cela semble impossible jusqu’à ce que vous réalisiez que notre infrastructure i18n avait déjà été testée en conditions réelles avec l’anglais, le russe, le chinois simplifié et le chinois traditionnel. Les modèles étaient en place. Le pipeline de traduction était prouvé. Ajouter six de plus était mécanique, pas créatif.

Les clients d’entreprise parlent principalement anglais. Les consommateurs parlent ce qu’ils parlent. La parité de la plateforme n’est pas optionnelle lorsque vous lancez globalement dès le premier jour.

Le contrôle de sécurité

La veille du lancement n’est pas le moment de découvrir une faille de sécurité. C’est le moment de vérifier que vous n’en avez pas.

Nous avons effectué un audit complet de la frontière de la sandbox. La règle critique : les vraies clés API n’entrent jamais dans la sandbox E2B. Ni la clé OpenRouter, ni aucun identifiant de fournisseur. La sandbox obtient un JWT à durée de vie courte qui passe par notre proxy LLM. Si la sandbox est compromise, l’attaquant obtient un jeton qui expire avant qu’il puisse en faire quoi que ce soit.

Cela importait plus pour le lancement consommateur qu’il ne l’a jamais fait pour l’entreprise. Les clients d’entreprise fonctionnent sur une infrastructure privée derrière des pare-feux. Les utilisateurs consommateurs fonctionnent sur une infrastructure partagée sur Internet public. La surface d’attaque est plus large. La sécurité doit être plus stricte.

Ce qui a été expédié

97 modèles LLM disponibles via OpenRouter. Neuf langues. Trois fournisseurs de facturation. Inscription OAuth. Un nouvel assistant d’onboarding. Frontend Cloudflare Pages. Backend StackSmith. Renforcement de la sécurité de la sandbox. Et 15 scénarios d’évaluation de prompt s’assurant que l’IA ne régresse pas pendant que nous reconstruisons tout autour d’elle.

Sept jours. Deux développeurs. Un produit qui est passé de “plateforme d’entreprise pour clients B2B” à “SaaS consommateur que n’importe qui peut s’inscrire en trente secondes.”

La version entreprise n’a perdu aucune fonctionnalité. Elle a gagné toutes les améliorations que nous avons faites pour les consommateurs — onboarding plus rapide, meilleure découverte des compétences, sécurité de la sandbox plus stricte. Le système de variantes signifie que les deux produits se poussent mutuellement en avant. Ce que nous construisons pour les individus rend la version entreprise meilleure. Ce que nos clients d’entreprise demandent rend la version consommateur plus robuste.

OpenClaw a montré au monde que les gens veulent des agents IA. Nous ne sommes pas en désaccord avec cela. Nous offrons la même capacité avec un contrat différent : votre agent fonctionne dans une sandbox, vos clés restent cryptées, votre système de fichiers reste intact. Un peu moins de flexibilité. Beaucoup plus de sommeil tranquille la nuit.

Le passage de l’entreprise au consommateur n’est pas un pivot. C’est un deuxième front. Même armée, mêmes armes, champ de bataille plus large.

LikeClaw est en ligne. Le tableau de bord entreprise continue d’être expédié. Lundi, nous commençons à construire pour les deux.

La semaine, jour par jour

  1. 1

    15-16 févr. : Couper et déployer

    Groupes dépouillés, panneaux d'administration et intégrations de systèmes internes. Mise en place de Cloudflare Pages pour le frontend et StackSmith pour le backend. Création du système de variantes afin que les entreprises et les consommateurs expédient à partir d'un seul dépôt.

  2. 2

    17-18 févr. : Facturation des consommateurs et OAuth

    Intégration de facturation de l'App Store. Google OAuth pour une inscription en un clic. Les clients entreprises utilisent des factures. Les consommateurs ont besoin d'achats dans l'App Store et de connexions sociales. Deux mondes différents.

  3. 3

    19-20 fév : Intégration de zéro

    Les utilisateurs d'entreprise reçoivent un appel de vente et un guide d'installation. Les consommateurs ont soixante secondes. On a supprimé l'ancien overlay. On a construit un assistant multi-écrans avec des cartes de scénario, des jetons d'engagement et une sélection de compétences.

  4. 4

    21 févr. : Localisation et sécurité

    Six nouvelles langues en une journée. Allemand, espagnol, français, coréen, portugais, portugais brésilien. Ensuite : audit de sécurité du sandbox. Les vraies clés API ne touchent jamais le sandbox. Seulement des JWT à courte durée de vie.

  5. 5

    22 févr. : Peaufiner et expédier

    Affinements de l'UX d'intégration. Tri intelligent des compétences. Badges de preuve sociale. Flux de travail de développement découplé en trois couches indépendantes. Déployez.

Questions sur le sprint de lancement

Pourquoi passer au consommateur alors que l'entreprise fonctionnait déjà ?

Parce qu'OpenClaw a prouvé que la demande est énorme et ne disparaîtra pas. Des milliers de personnes veulent des agents IA autonomes mais ne peuvent pas surmonter les problèmes de sécurité. Nous avions déjà la version sécurisée — elle n'était tout simplement pas accessible aux particuliers. Les entreprises paient les factures, mais un produit grand public construit la marque et crée les champions qui l'intègrent dans leurs entreprises plus tard.

Qu'est-ce que vous avez réellement retiré de la version entreprise ?

Groupes, contrôle d'accès basé sur les rôles, intégrations avec des systèmes internes comme Jira et Confluence, configuration SSO et tableau de bord admin. Tout ce qui a du sens pour une équipe de cinquante mais qui peut submerger un utilisateur solo essayant le produit pour la première fois.

Comment expédiez-vous aussi vite avec deux développeurs ?

Petite équipe, zéro réunions, une base de code partagée. Marina s'occupait de la stabilisation du backend, de la facturation et de la localisation. Alex gérait le frontend, l'onboarding et le cadre d'évaluation. Nous avons examiné les PR de l'un et de l'autre chaque jour. C'est tout.

La version entreprise reçoit-elle toujours des mises à jour ?

Chacun d'eux. Le système de variantes signifie une seule base de code, plusieurs produits. Chaque correctif de sécurité, amélioration de performance et nouveau modèle arrive dans les deux versions en même temps. Les clients entreprises ne perdent rien. Ils gagnent tout ce que nous construisons pour les consommateurs aussi.