Un SaaS en deux jours avec Kimi K3 : Claude est-il vraiment détrôné ?

Le narrateur se présente comme un ancien ingénieur d'une grande entreprise technologique, au chômage, avec 25 ans d'expérience dans le secteur, qui a mis au point une automatisation extrayant des clips courts de ses longues vlogs pour les publier sur les plateformes sociales ; après des mois de silence, quelques clips décollent sur TikTok, Facebook et Instagram et apportent une véritable vague d'abonnés. Le détail qui m'a accroché, c'est la règle de l'unique lien sur les profils : sur Instagram, tout ce qui est sous la ligne de flottaison n'existe pour ainsi dire pas. Le plan d'ouverture énonce clairement le pari, avec l'hôte dans un bureau à domicile devant un écran de code, à côté d'un grand GOODBYE CLAUDE.

Quand la nouvelle audience veut une seule page avec tout dedans, il essaie les services de liens de bio tout faits comme Linktree, Beacons et Squarespace ; les pages censées être gratuites apposent leur propre marque partout, puis enterrent le contenu sous les e-mails de mise à niveau et la pression du domaine personnalisé. Alors il inverse la règle et décide d'écrire son propre générateur de page de liens, en choisissant le Kimi K3 à poids ouverts de Moonshot comme moteur. Le modèle est réputé égaler ou dépasser les principaux modèles fermés américains sur de nombreux critères, et il arrive comme l'alternative sans fournisseur unique au Claude Fable qu'il utilise au quotidien.

N'ayant pas de cluster domestique géant, il accède à Kimi K3 via OpenRouter, payant un revendeur qui fait tourner le modèle dans des centres de données situés aux États-Unis plutôt que de payer Moonshot directement. Ce détail apparemment mineur porte l'une des thèses de la vidéo : les poids ouverts signifient choisir qui est payé et où le travail s'exécute. Les fiches de modèle publiées décrivent Kimi K3 comme une architecture sparse de mixture-of-experts avec 2 800 milliards de paramètres au total et une fenêtre de contexte d'un million de tokens.

Il explique ensuite le harnais d'agent en termes simples : la fenêtre de contexte est la mémoire à court terme du modèle, et une fois pleine, les détails anciens s'effacent et la fabrication commence ; le harnais gère cette mémoire avec des fichiers de mémoire globaux et par projet, en compactant et en redémarrant depuis la même base quand c'est nécessaire. L'installation donne aussi au modèle des outils et des compétences ; lire des données, ouvrir un navigateur ou appeler un service distant sont des outils, tandis que les recettes de tâches répétables dans des fichiers Markdown sont des compétences. La plupart des outils suivent le Model Context Protocol afin de pouvoir être réutilisés d'une installation à l'autre, et il avertit que les compétences téléchargées peuvent contenir des lignes hostiles, raison pour laquelle il écrit les siennes.

Chaque grand laboratoire dispose d'une installation accordée à son propre modèle : Claude Code côté Anthropic, Kimiko côté Moonshot, Codex côté OpenAI, plus des installations open source comme OpenCode, PiCode et Hermes qui fonctionnent avec de nombreux modèles. Il choisit délibérément ce qu'il appelle l'option la plus ennuyeuse, l'installation Agent de Visual Studio Code, parce qu'il veut une piste équitable : il a testé Claude 5 Fable sur la même installation à sa sortie et estime qu'elle ne donne à aucun modèle un avantage caché. Cette revendication de neutralité fonde toute la comparaison.

Pour la première tâche, il demande à Kimi un document de conception technique ; son prompt énonce les exigences de bout en bout, exige une pile auto-scalable qu'un développeur solo peut maintenir, et demande explicitement au modèle de poser des questions. Dans cet échange de conception, Kimi pose plus de questions que Claude 5 Fable, creusant les détails fonctionnels et techniques, ce qu'il interprète comme un bon signe. Le squelette de l'architecture émerge après une vingtaine de minutes.

Il pousse sur deux points de la proposition : garder les données de vues de chaque page de liens dans la même base que l'application principale pourrait ralentir tout le système en cas de pic de trafic, et un PostgreSQL auto-hébergé est plus difficile à maintenir qu'un service de base de données géré. Un vieux débat construire-ou-acheter avec d'anciens collègues se rouvre, et il plaisante en disant que parler à l'IA ressemble à des ombres projetées sur la paroi d'une caverne. La pile convenue finit par être React plus Tailwind à l'avant, Next.js au milieu, Convex pour les données, Google Analytics pour la mesure, Clerk pour la connexion et Stripe pour les paiements.

Pour le codage, il saute le schéma habituel consistant à découper le travail entre sous-agents ; comme les modèles plus petits sont généralement plus faibles, il veut voir Kimi écrire le code lui-même. La consigne est nette : avancer phase par phase à partir du document de conception, écrire à chaque fois des tests unitaires plus des tests de bout en bout pour les flux critiques, les exécuter, corriger ce qui casse, boucler jusqu'au vert. Il prend un café pendant que ça travaille ; la construction dure plus d'une heure et le modèle tombe deux fois dans un étrange blocage, brûlant le compteur sans progrès jusqu'à ce que l'installation intervienne au bout de cinq minutes. Il y voit un défaut d'intégration modèle-installation.

À la validation, il fait un calcul sombre : un humain ne peut examiner qu'environ 500 lignes par jour avec qualité, alors que le modèle en a produit des milliers ; un travail de plusieurs semaines est trié par une compétence de revue de code qui cartographie les défauts par gravité, afin que la rare attention humaine se porte sur les pires zones. Après des heures de revue, il lance l'application en local ; à part des problèmes de style mineurs, le comportement du cœur est étonnamment juste. Pas parfait du premier coup, mais confortablement au-dessus de la moyenne.

Le dernier accroc est une course d'ordre de hooks ; Kimi peine dessus et demande soudain les clés de déploiement de production pour essayer un correctif en direct. Sa plaisanterie est cinglante : un modèle de premier plan qui demande les clés de la maison au premier rendez-vous. Il refuse, tente quelques prompts de plus jusqu'à ce que le défaut soit corrigé, et le déploiement Vercel se pose proprement ; de l'idée à la production, il aura fallu moins de deux jours.