J'ai lancé des produits pendant des années. Je sais ce que « lent » signifie.
La première semaine de la construction d'un SaaS est vraiment la pire partie de tout le processus.
Tu changes de rôle dans ta propre tête toute la journée, sans pause.
Fondateur. Chercheur. Chef de produit. Designer. Ingénieur. Testeur QA. Marketeur.
Même cerveau. Sept métiers complètement différents. Aucune dynamique à montrer pour tout ça.
La plupart des fondateurs que je connais passent la première semaine entière à juste réfléchir à comment réfléchir. Ils ouvrent un document vierge, écrivent trois points, ferment l'ordinateur, se font un café, reviennent, suppriment les points et recommencent. La semaine se termine et rien n'existe, à part un sentiment d'anxiété grandissant et une appli de notes pleine d'idées à moitié formées qui ne mènent nulle part.
Le mois dernier, j'en ai eu assez de ce cycle et j'ai essayé quelque chose de complètement différent.
J'ai arrêté d'utiliser un seul modèle d'IA pour tout et j'ai commencé à traiter l'IA comme on traiterait une vraie équipe.
J'ai construit sept agents spécialisés avec Kimi Agent Swarm et j'ai donné à chacun un travail précis, une sortie spécifique à produire et un domaine bien délimité.
Un après-midi. Une idée de SaaS. Sept agents travaillant en parallèle. Un plan d'action MVP complet devant moi avant le dîner.
Voici exactement ce que j'ai fait et pourquoi ça a marché.
L'idée que je leur ai donnée à travailler
Le concept du produit était un SaaS d'audit de site Web IA spécialement conçu pour les entreprises locales.
Le problème est évident une fois qu'on le voit. Cinq millions d'entreprises locales ont des sites Web qui ont l'air d'avoir été construits en 2011 et jamais retouchés depuis. Pas de bouton de réservation. Pas de version mobile. Pas de signaux de confiance. Pas d'appel à l'action clair. Pas de section d'avis. Rien qui convertisse un visiteur en appel téléphonique.
Un plombier peut être vraiment bon en plomberie et perdre quand même des clients tous les jours parce que son site Web a l'air abandonné. La qualité du travail et la qualité de la présence en ligne n'ont rien à voir l'une avec l'autre. Cet écart est l'opportunité.
Le concept du SaaS était simple. Entrer l'URL d'une entreprise locale, l'application lance un audit, génère un score, identifie ce qui ne va pas et pourquoi, et produit un email à froid prêt à être envoyé au propriétaire.
Les utilisateurs cibles étaient les freelances, les designers web et les agences SEO locales. Tous ceux qui vendent des sites Web et des services aux entreprises locales et ont besoin d'un moyen plus rapide de lancer cette conversation.
L'information clé qui a fait fonctionner cette idée était la suivante. L'audit n'est pas le produit. L'audit est l'arme de vente.
Un email à froid générique qui ne dit rien de spécifique est ignoré à chaque fois. Un email qui dit que ton bouton de réservation mobile est cassé, que ta page d'accueil n'a pas de signaux de confiance et que ton concurrent en bas de la rue a trois cents avis de plus et un processus de réservation plus rapide obtient en fait une réponse. La spécificité est ce qui fait que les gens prêtent attention. Le SaaS produit cette spécificité automatiquement en soixante secondes.
Pourquoi la plupart des gens utilisent complètement mal l'IA pour construire
Avant d'entrer dans le workflow, cette partie est importante parce qu'elle explique pourquoi l'approche fonctionne.
La plupart des fondateurs utilisent l'IA comme un chatbot légèrement plus puissant. Ils donnent à un seul modèle une seule énorme invite lui demandant de faire des recherches sur le marché, de concevoir l'interface utilisateur, de construire le backend, d'écrire la page d'accueil et de planifier le lancement, tout en même temps.
Le résultat donne l'impression d'être superficiel parce qu'il l'est.
Un seul modèle qui passe d'un mode de pensée à un autre parmi sept modes complètement différents produit un travail moyen dans chaque mode. Ce n'est pas un problème de qualité du modèle. C'est un problème structurel.
Un chercheur pense différemment d'un designer. Un ingénieur backend pense différemment d'un marketeur. Un testeur QA pense différemment d'un chef de produit. Ce ne sont pas juste des tâches différentes. Ce sont des modes cognitifs vraiment différents qui produisent de meilleurs résultats quand ils ne sont pas en compétition les uns avec les autres dans la même fenêtre de contexte.
L'idée derrière les « agent swarms » (essaims d'agents) est simple. La spécialisation produit de meilleurs résultats que la généralisation. Ce n'est pas du tout une nouvelle idée. C'est exactement pour ça que les entreprises embauchent des équipes plutôt qu'une seule personne qui fait tout.
Kimi Agent Swarm applique cette même logique à l'IA. Au lieu de demander à un seul modèle de te construire un SaaS, tu crées une petite entreprise d'IA autour de la tâche. Chaque agent possède un rôle. Chaque agent produit un artefact. Le fondateur gère le système et révise les sorties au lieu d'effectuer chaque tâche manuellement.
Ce changement semble subtil. En pratique, il change tout dans la façon dont la semaine se déroule.
Les sept agents que j'ai assemblés
Agent 1 était l'Agent de Recherche. Son travail était de valider le marché, d'identifier les vrais clients cibles, de cartographier le paysage concurrentiel et de faire remonter les cas d'utilisation principaux. Rien d'autre.
Agent 2 était l'Agent Chef de Produit. Son travail était de définir le périmètre du MVP avec une honnêteté brutale, de couper toute fonctionnalité non essentielle, de cartographier le parcours utilisateur principal et de fixer le modèle de tarification. Rien d'autre.
Agent 3 était l'Agent UX. Son travail était de concevoir la structure des pages, le flux utilisateur, la disposition du tableau de bord et celle du rapport. Rien d'autre.
Agent 4 était l'Agent Ingénieur Frontend. Son travail était de construire le plan de l'interface utilisateur et de définir la structure complète des composants. Rien d'autre.
Agent 5 était l'Agent Ingénieur Backend. Son travail était de concevoir la logique d'audit, le système de notation, la structure de l'API et le modèle de données. Rien d'autre.
Agent 6 était l'Agent QA. Son travail était d'attaquer le plan complet, de trouver les bugs, de faire remonter les états manquants, d'identifier les cas limites et d'exposer toutes les hypothèses qui allaient poser problème plus tard. Rien d'autre.
Agent 7 était l'Agent de Lancement. Son travail était d'écrire le texte de la page d'accueil, le post de lancement, le modèle d'email à froid et le positionnement du produit. Rien d'autre.
Chaque agent a d'abord travaillé indépendamment. Ensuite, les sorties ont été fusionnées en un seul plan de construction complet.
C'est ce qui le distingue d'une longue conversation avec un seul modèle d'IA. Il n'y a pas de changement de contexte. Il n'y a pas de contradiction implicite entre ce qu'une section dit et ce qu'une autre section suppose. Chaque agent reste dans son domaine et produit une sortie propre à partir de ce domaine.
L'invite principale que j'ai utilisée pour commencer
Voici l'invite exacte que j'ai donnée à Kimi pour ouvrir la session. Utilise-la comme point de départ et adapte-la à ce que tu construis.
« Construis un SaaS d'audit de site Web IA pour les entreprises de services locales. Les utilisateurs cibles sont les freelances, les propriétaires d'agences, les consultants SEO locaux et les designers web qui vendent à des plombiers, des entreprises de chauffage et climatisation, des couvreurs, des électriciens et des dentistes. Workflow principal : l'utilisateur entre l'URL d'une entreprise locale, l'application audite le site Web, génère un score, une liste de problèmes, une liste de contrôle d'amélioration, un rapport client et un email à froid. Divise cela entre sept agents spécialisés. L'Agent de Recherche valide le marché et le client. L'Agent Produit définit le périmètre du MVP, les fonctionnalités et la tarification. L'Agent UX conçoit le flux utilisateur, le tableau de bord et la disposition du rapport. L'Agent Frontend définit la structure et les composants de l'interface utilisateur. L'Agent Backend conçoit la logique de notation, le système d'audit et l'API. L'Agent QA identifie les cas limites, les états manquants et les modes de défaillance. L'Agent de Lancement écrit la page d'accueil, le post de lancement, l'email à froid et le positionnement. Chaque agent travaille d'abord indépendamment. Ensuite, fusionne toutes les sorties en un seul plan MVP final. »
La plupart des gens écriraient une version de ça et attendraient une grande réponse. L'intérêt de l'essaim est que chaque agent produit un véritable artefact depuis son propre angle sans savoir ce que les autres agents font. La recherche ne pense pas aux couleurs des boutons. L'UX n'invente pas le modèle de tarification. La QA attaque plutôt que de défendre. L'agent de lancement ne touche pas au backend. La séparation, c'est le système.
Ce que chaque agent a réellement produit
L'Agent de Recherche a trouvé quatre groupes de clients réels qui comptaient. Les designers web vendant des refontes aux entreprises locales. Les agences SEO vendant des abonnements d'audit mensuels. Les freelances utilisant la prospection à froid pour trouver de nouveaux clients. Les fondateurs solo construisant des services de génération de leads en tant qu'offre packagée.
L'information la plus importante qu'il a fait remonter est celle que j'ai déjà mentionnée, mais ça vaut la peine de le répéter. L'audit n'est pas le produit. L'audit est l'arme de vente. Les gens qui vendent aux entreprises locales ont besoin d'un moyen plus rapide de créer des audits personnalisés et spécifiques qui leur donnent une raison de contacter qui vaille la peine d'être lue. L'agent de recherche a identifié cela comme le positionnement central de tout le produit avant même qu'un seul écran soit conçu.
L'Agent Chef de Produit a réduit le périmètre sans sentiment.
La version un avait besoin d'exactement cinq écrans. Page d'accueil. Page de saisie d'audit. Page de chargement et de progression. Page de résultats d'audit. Page d'export du rapport.
Pas de comptes d'équipe. Pas d'intégration de facturation. Pas de connexions CRM. Pas d'extension de navigateur. Pas de marketplace. Pas d'accès API pour les tiers. Rien de tout ça.
Juste un workflow qui fonctionne proprement. Entrer l'URL, obtenir l'audit, envoyer le rapport, gagner l'affaire.
Les fonctionnalités principales du MVP étaient simples. Saisie de l'URL du site Web. Sélecteur de catégorie d'entreprise. Score d'audit de zéro à cent. Liste de contrôle de conversion. Liste de contrôle de préparation mobile. Liste de contrôle des signaux de confiance. Liste de contrôle des CTA. Résumé du rapport. Générateur d'email à froid. Tarification suggérée des services pour le freelance envoyant le rapport.
C'est suffisant pour la version un. Un MVP SaaS n'a pas besoin d'être complet. Il doit prouver qu'un workflow fonctionne de bout en bout sans casser.
L'Agent UX a conçu le parcours utilisateur en cinq étapes avec une clarté qui aurait pris une journée entière à un designer humain pour produire.
Étape un : coller l'URL et choisir le type d'entreprise. Étape deux : l'application lance l'audit avec une barre de progression visible. Étape trois : voir le score global. Étape quatre : voir exactement ce qui ne va pas et pourquoi, en langage clair. Étape cinq : télécharger le rapport et obtenir l'email à froid prêt à envoyer.
La disposition du rapport produite par l'agent UX était l'élément qui m'a vraiment surpris.
Score du site Web : 62 sur 100. Ce qui vous coûte des clients : pas de bouton de réservation visible, version mobile faible, pas de section d'avis Google, pas de CTA pour les services d'urgence, confiance lente à établir au-dessus de la ligne de flottaison. Victoires rapides : ajouter un bouton d'appel en un clic, déplacer les avis en haut de la page, ajouter une section de zone d'intervention, ajouter des photos avant/après, ajouter un formulaire de réservation. Impact commercial : votre site perd les visiteurs mobiles qui sont prêts à appeler maintenant.
Pas technique. Pas rempli de jargon. Assez clair pour qu'un plombier le lise et le comprenne en trente secondes. C'est ce que le freelance envoie. C'est ce qui fait qu'une réunion est réservée.
L'Agent Backend a construit le système de notation à travers cinq catégories avec des vérifications pondérées spécifiques à l'intérieur de chacune.
La clarté du design valait vingt points. La préparation mobile valait vingt points. La préparation à la conversion valait vingt-cinq points. Les signaux de confiance valaient vingt points. Les bases du SEO local valaient quinze points. Total de cent points, chaque point étant traçable jusqu'à une fonctionnalité observable spécifique sur le site Web.
Cela compte plus qu'il n'y paraît. Un score doit être explicable pour être crédible. Un score IA boîte noire que personne ne peut tracer semble faux et est ignoré. Un score avec des raisons spécifiques et claires attachées à chaque point semble utile et est transmis au propriétaire de l'entreprise avec une note jointe.
L'Agent QA était l'agent le plus précieux de tout l'essaim, et de loin.
Un agent QA fait bien une chose. Il attaque. Et un agent séparé qui attaque le plan n'a aucun attachement émotionnel au travail qui l'a précédé.
L'Agent QA de Kimi a immédiatement fait remonter les problèmes qui auraient causé de réels dégâts plus tard. Que se passe-t-il si l'URL est cassée ou mal tapée ? Et si le site bloque complètement le crawling web ? Et si le site Web n'a presque pas de contenu textuel à analyser ? Et si l'entreprise n'a aucun avis nulle part ? Et si deux catégories d'audit produisent des résultats contradictoires ? Et si l'email à froid généré semble trop agressif et nuit à la relation du freelance avant même qu'elle ne commence ?
Chacune de ces questions a révélé une faille dans le plan qui devait être corrigée avant qu'une seule ligne de code ne soit écrite.
Les correctifs qu'il a recommandés étaient concrets. Des états de repli pour les sites qui bloquent le crawling. Un champ de notes manuelles pour la prise de contrôle humaine lorsque l'audit automatisé ne peut pas vérifier quelque chose. Un score de confiance attaché à chaque constatation pour que le freelance sache ce qui est solide et ce qui nécessite une vérification. Un réglage de tonalité d'email plus doux pour différentes situations. Une étape de révision humaine avant que toute prospection ne soit réellement envoyée.
Ce dernier point est important et je veux être direct à ce sujet. Tu ne veux pas que cinq cents emails à froid médiocres partent automatiquement avec ton nom dessus. Tu veux cinq cents brouillons solides qu'un humain révise et approuve avant qu'ils ne soient envoyés. L'essaim fait le gros du travail. Le fondateur reste l'éditeur.
L'Agent de Lancement a produit le positionnement du produit en une seule ligne qui était vraiment meilleur que tout ce que j'avais écrit moi-même après y avoir réfléchi pendant deux jours.
Transformez les mauvais sites Web d'entreprises locales en opportunités clients.
C'est plus fort que « outil d'audit de site Web IA » de toutes les manières possibles. Personne ne se réveille en voulant un audit. Ils se réveillent en voulant des clients. Le positionnement reflète ce que l'utilisateur veut réellement plutôt que ce que le produit fait techniquement.
Le titre de la page d'accueil et le sous-titre écrits par l'agent étaient tout aussi nets. Transformez les mauvais sites Web d'entreprises locales en opportunités clients. Entrez n'importe quelle URL. Obtenez un audit instantané. Envoyez un rapport personnalisé. Concluez l'affaire. Rien de superflu. Pas de jeu de mots intelligent qui obscurcit la valeur. Juste la promesse énoncée simplement.
Ce que l'après-midi a produit au total
Quand les sept agents eurent terminé et que les sorties furent fusionnées en un seul document, j'avais un marché validé et un profil de client cible réel, un périmètre MVP serré avec cinq écrans et zéro dérive fonctionnelle, un parcours utilisateur complet cartographié étape par étape, un système de notation sur cent points avec des vérifications spécifiques attachées à chaque point, une structure d'interface utilisateur et une liste complète de composants, une disposition de rapport adaptée aux clients testée pour la clarté du langage, une liste de contrôle QA couvrant tous les cas limites que les agents pouvaient identifier, un texte de page d'accueil prêt à l'emploi, un post de lancement pour le jour de la sortie, et un modèle d'email à froid personnalisé pour le propriétaire de l'entreprise locale.
Ce n'est pas une entreprise finie. Personne ne prétend que c'est le cas.
Mais c'est plus que ce que la plupart des fondateurs ont après une semaine entière de réflexion en solo, et ça a pris un après-midi au lieu de sept jours.
Ce que l'essaim ne peut pas faire et où tu comptes encore
Je veux être direct à ce sujet parce que la plupart des articles sur les outils d'IA l'omettent complètement et ce mensonge est ce qui fait que les gens ne font confiance à rien.
Kimi n'a pas construit un SaaS. Il a construit un plan d'action pour un SaaS. La différence est réelle et significative.
Un produit fonctionnel a toujours besoin de code de production écrit et testé. Il a besoin de vrais utilisateurs qui l'essaient et le cassent d'une manière que personne n'avait anticipée. Il a besoin de traitement des paiements, d'hébergement et d'une bonne gestion des erreurs. Il a besoin d'un support client quand les choses tournent mal. Il a besoin d'une distribution qui ne s'arrête pas quand tu arrêtes de pousser. Il a besoin de tests de tarification avec de vraies personnes avec de l'argent réel. Il a besoin d'une QA manuelle avant que quoi que ce soit ne soit livré publiquement.
Certains sites Web bloquent le crawling et ont besoin d'une approche de repli. Certains audits ont besoin d'une vérification humaine avant d'être envoyés à un client. Certains emails ont besoin d'une seconde lecture avant d'être envoyés.
Ce n'est pas « appuie sur un bouton et deviens riche ». Quiconque te dit le contraire est en train de te vendre quelque chose.
La valeur honnête est plus pratique que ça. L'essaim a remplacé les premiers soixante-dix pour cent désordonnés de la réflexion produit qui prenaient auparavant une semaine à regarder des documents vierges et à passer d'un état d'esprit à un autre parmi sept. Le fondateur conserve le goût, le jugement et la livraison réelle. Ce qui change, c'est le point de départ.
Au lieu de commencer avec une page blanche et une spirale d'anxiété, tu commences avec un résultat de recherche, un cahier des charges produit, un système de notation, un flux d'interface utilisateur et un plan de lancement. La charge cognitive diminue immédiatement. Les premières décisions sont prises plus vite parce que la réflexion a déjà été structurée. La semaine se sent complètement différente dès la première heure.
Le workflow exact à sauvegarder et à utiliser
Étape un : écris une idée claire qui inclut le problème, l'utilisateur spécifique et le workflow principal. Un paragraphe. Pas plus.
Étape deux : ouvre Kimi Agent Swarm.
Étape trois : assigne sept agents avec des rôles spécifiques et des sorties spécifiques. Pas d'instructions générales. Des livrables spécifiques de chaque domaine.
Étape quatre : laisse chaque agent produire son artefact complètement indépendamment sans se référer aux autres.
Étape cinq : laisse l'agent QA attaquer le plan fusionné complet sans aucun attachement à aucun des travaux.
Étape six : fusionne toutes les sorties en un seul document de plan d'action MVP.
Étape sept : construis seulement la plus petite version du produit qui prouve que le workflow principal fonctionne réellement de bout en bout.
Étape huit : teste avec cinq vrais utilisateurs avant d'ajouter une seule fonctionnalité supplémentaire. Les vrais utilisateurs cassent les hypothèses qu'aucun agent ne fera jamais remonter parce que les hypothèses ne se brisent que contre la réalité.
L'erreur que la plupart des fondateurs commettent est de demander à l'IA de tout construire. La meilleure approche est de demander aux agents d'éliminer le chaos au début pour que la réflexion soit structurée avant que la construction ne commence.
La recherche devient claire. Le périmètre devient clair. Les écrans deviennent clairs. Les risques deviennent clairs. L'angle de lancement devient clair. Tout ce qui prend habituellement une semaine de changements confus se comprime en un après-midi ciblé.
Le changement qui se produit réellement
Voici ce que je crois sincèrement après avoir exécuté cela et y avoir réfléchi attentivement.
La prochaine génération de fondateurs n'utilisera pas seulement l'IA pour écrire du texte ou résumer des documents. Ils géreront des essaims comme un fondateur gère une équipe. Un agent recherche le marché. Un agent conçoit le produit. Un agent construit le plan backend. Un agent teste les hypothèses. Un agent écrit le lancement.
Le fondateur cesse d'être la personne qui exécute chaque tâche et commence à être la personne qui dirige le système, révise les sorties, applique le goût et le jugement, et décide ce qui est livré.
Ce n'est pas un petit changement. C'est un changement fondamental dans ce à quoi ressemble la première semaine de construction et dans le type de résultat possible avant qu'une seule ligne de code de production ne soit écrite.
Les fondateurs qui comprennent cela en premier vont avoir un avantage injuste sur ceux qui changent encore entre sept rôles dans un seul cerveau fatigué.
Avant : un fondateur changeant entre sept rôles, perdant une semaine avant d'écrire une ligne de code, brûlant de l'énergie cognitive sur la structure plutôt que sur le fond.
Après : sept agents fonctionnant en parallèle, renvoyant un plan d'action MVP complet avant la fin de la journée, avec l'énergie du fondateur préservée pour les décisions qui nécessitent réellement un jugement humain.
Cela prenait auparavant une semaine de travail seul.
Maintenant, ça commence avec une invite et un après-midi.
Suis-moi pour plus de systèmes réels qui changent réellement la façon dont tu construis.
