← Tous les articles

Journal de bord

Journal de board IA #4 — J'ai voulu construire mon SaaS avec Paperclip. Au final, je l'ai fait avec Claude Design + Claude Code.

Publié le 7 mai 2026

Retour d'expérience honnête sur ce que les outils d'orchestration agent en 2026 promettent, et ce qu'ils livrent vraiment quand on est dev senior et qu'on veut un truc précis.

Le pitch initial

Ma compagne a une boutique Etsy. Elle fait des créations, ça plaît, mais comme à peu près 100% des artisans qui vendent en ligne, elle galère sur le SEO. Pas parce qu'elle est nulle, mais parce que le SEO e-commerce est un sujet technique, jargonneux, chronophage, qui n'a rien à voir avec son métier de créatrice.

J'ai regardé ce qui existe : eRank, Alura, EverBee, EtsyHunt côté Etsy, Yoast et Rank Math côté WooCommerce. Tous bons techniquement. Tous inadaptés à la cible artisan-créateur. Trop de jargon, trop de dashboards, trop chers, jamais multi-plateformes, jamais en français.

L'idée de JunaPilot est née de là : un assistant IA conversationnel nommé Juna qui fait le travail à la place de l'artisan. Zéro dashboard, zéro jargon. Juna scanne les fiches, analyse la concurrence, propose des modifications applicables en un clic via un chat, point. Pricing artisan-friendly (6,90€/mois), freemium permanent pour les boutiques qui démarrent.

Ce que je voulais raconter au départ, c'était : "voici comment j'ai construit ce SaaS en 2 jours avec Paperclip."

Sauf que c'est pas exactement ce qui s'est passé.

Le cadrage en conversation : ça, ça marche très bien

Le premier jour, j'ai cadré le projet en conversation avec Claude. Pas de prompt engineering sophistiqué, pas de framework agent, pas de rituel particulier. Juste un échange long et structuré.

En quelques heures, on a couvert :

  • L'étude de marché complète (concurrents, pricing, gap exploitable)
  • Le positionnement produit (qui je sers, qui je ne sers pas)
  • L'architecture technique (Next.js + Postgres + BullMQ/Redis + Claude Haiku 4.5 via SDK Anthropic, orchestration agent maison, pas de framework)
  • Le pricing (avec un pivot honnête : mon idée initiale "2€/mois" ne passait pas le calcul de marge, le vrai plancher c'est 6,90€)
  • Les principes produit non-négociables (chat-only radical, langage humain, mémoire persistante, mobile-first PWA, hybride par fiche)
  • La roadmap MVP en 6 phases

Sur ce volet, je suis convaincu : la conversation avec un LLM senior est aujourd'hui le meilleur outil de cadrage produit que je connaisse. Ce qu'une agence facturait 5000-15000€ il y a 5 ans (étude de marché + cadrage produit + architecture + roadmap), c'est ce qu'on a fait en une session.

Avec une condition critique : être capable de juger les réponses. Je suis dev JS senior depuis 10 ans et plus. Quand le LLM simplifie, je détecte. Quand il propose une stack qui ne tient pas la charge, je challenge. Quand il oublie une contrainte, je le ramène. Un non-technique aurait pris pour argent comptant des choix qui auraient explosé en vol 3 mois plus tard.

À la fin du cadrage, j'avais deux livrables propres : un brief projet de 10 sections, et un prompt de bootstrap pour Paperclip.

Le fiasco du naming (premier indice)

Avant d'aller plus loin, un détour par un moment qui m'a appris quelque chose d'important sur la confiance à accorder au LLM.

Premier nom proposé : Volo. Référence Baldur's Gate 3, sonne bien, courte, mémorisable. Claude m'a écrit 2000 mots pour me convaincre. J'allais valider. Réflexe : "on vérifie quand même". Vérification : Volo Commerce existe depuis 2006, c'est un SaaS e-commerce britannique racheté par Constellation Software, exactement le même créneau. Si je me lançais sous Volo, je recevais un cease & desist dans les 6 mois.

Deuxième nom proposé : Huginn. Le corbeau d'Odin qui rapporte ce qu'il voit à son maître. Métaphore parfaite pour un agent qui scanne les boutiques. Je vais pour valider. Reflexe : "on vérifie." Vérification : Nosto a lancé en octobre 2025 un agent IA e-commerce qui s'appelle Huginn. Pour l'enterprise (Kylie Cosmetics, Marc Jacobs), mais même secteur exact que mon produit.

Deux ratés d'affilée. Le LLM propose des noms qui sonnent bien, pas des noms disponibles. C'est une distinction qu'il faut garder en tête.

Méthode mise en place : vérifier AVANT de proposer, pas après.

Au final, je suis revenu aux fondamentaux. Ma boutique Etsy s'appelle Juna, du prénom de mes filles Juliette et Anna. C'était déjà mon histoire. JunaPilot pour le produit, Juna pour l'agent IA. Authentique, juridiquement sûr, narrativement fort.

Première leçon : le LLM est créatif, l'humain doit être rigoureux. Sans cette vigilance, je partais déposer la marque Volo. Toute la conversation suivante était bonne, mais ce moment m'a rappelé qu'on avance avec un copilote, pas avec un pilote automatique.

Paperclip : la promesse vs ma réalité

Bon, le brief était propre, les agents prêts à être recrutés. Direction Paperclip.

Le setup

Premier point de friction : l'installation. J'ai mon Paperclip qui tourne sur un serveur distant dans une VM Docker, par choix, parce que j'ai un Kimsufi qui sert de hub pour mes projets. Configuration non-standard, j'ai galéré un bon moment avant que tout fonctionne. Une fois passé ce cap, la connexion à Claude Code est nickel.

Disclaimer honnête : mon setup atypique est une source de friction qui n'est pas la faute de Paperclip. Pour un user qui utilise Paperclip en local sur sa machine, ce point ne se pose pas.

L'orchestration multi-agents

J'ai donné le contexte du projet et le rôle au CEO. Il a recruté :

  • Un CTO
  • Un développeur front-end
  • Un UX designer
  • Un content writer

Le casting était cohérent avec le brief. Bonne surprise.

Le contenu produit (textes de landing, persona Juna, descriptions d'écrans) était propre. Bien aligné avec la philosophie du projet, respect du ton, du positionnement. Pour la partie copywriting et conception, Paperclip fait le job.

Le mur

Le problème commence quand on rentre dans le concret du dev.

La première version générée était moche. Pas un peu, vraiment moche. Des éléments par défaut, des couleurs criardes, des layouts basiques sans cohérence. Le CTO et le front-end avaient produit un truc fonctionnel mais visuellement inutilisable.

C'est à ce moment que j'ai testé Claude Design. Je lui ai filé le brief, il m'a généré une landing magnifique. Pixel-perfect, cohérente, avec juste un input mal aligné en mobile que j'ai corrigé moi-même en 30 secondes.

Logique suivante : repasser ce design à Paperclip pour qu'il l'implémente dans le projet.

C'est là que ça a coincé.

Le drame du handoff design → code

J'ai exporté le HTML/CSS du design Claude Design. Je l'ai donné au CTO Paperclip avec une instruction claire : "voici la source de vérité, implémente-la."

Il a essayé. Il n'a jamais réussi.

Pas que ça ne ressemblait à rien. Il a repris les grandes lignes : les couleurs, la mise en page, les blocs principaux. Mais en pratique, c'était jamais le même rendu. Les polices différaient, des détails de spacing partaient en vrille, certains éléments étaient omis, d'autres ajoutés. Alors qu'objectivement, c'était un copier-coller HTML/CSS à faire, pas du raisonnement créatif.

J'ai essayé de corriger en lui faisant des retours dans Paperclip. Et là, deuxième mur : l'interface.

Honnêtement, je trouve l'UX de Paperclip difficile à suivre. Tu parles à un agent, sa réponse apparaît ailleurs. Tu dois chercher où les choses se passent. Quand tu fais un retour à un agent, il y a des fois où il transmet à un autre agent qui fait autre chose à côté. Le contexte se perd entre agents. J'ai eu l'impression, peut-être à tort, que les agents ne se parlent pas vraiment, qu'ils travaillent en silos avec un orchestrateur qui résume mal.

Ajouté à ça mon problème spécifique de setup distant : à chaque modification de code, je devais aller sur un autre serveur pour tester. La boucle de feedback prenait 2-3 minutes par itération.

J'y ai passé une journée entière. Au bout d'une journée, je n'avais pas une landing qui ressemblait au design.

Mon verdict sur Paperclip

Je ne dirai pas que Paperclip est un mauvais outil. Je vais dire ce que je pense honnêtement : Paperclip ne m'a pas servi pour ce que je voulais faire.

Mes hypothèses sur pourquoi :

  1. Je ne suis peut-être pas la cible. Paperclip semble taillé pour des gens qui veulent un MVP cadré, simple, qu'ils ne vont pas pixel-pousher. Pour quelqu'un qui veut un truc précis avec une charte graphique exacte, c'est probablement le mauvais outil.
  2. Pour le vibe-coding, ça ne marche pas. Si tu as besoin de faire 50 retours pour affiner, l'interface te tue. C'est conçu pour des passes plus larges, pas pour de l'itération fine.
  3. Les agents ne partagent pas leur contexte de manière fluide. Plusieurs fois, j'ai eu l'impression que je devais re-expliquer les mêmes choses à des agents différents.
  4. Mon setup distant est un facteur aggravant qui n'est pas la faute du produit.

Pour un dev senior qui sait ce qu'il veut, qui a des standards visuels, qui veut itérer finement, ce n'était pas l'outil.

Le pivot : Claude Design + Claude Code

J'ai laissé tomber Paperclip pour cette phase. Voici ce que j'ai fait à la place.

Étape 1 : Claude Design pour le design

Brief en entrée. En quelques minutes, une landing complète, cohérente, magnifique. Aucune intervention nécessaire à part un input mal aligné en mobile, que j'ai corrigé en 30 secondes après implémentation.

Étape 2 : Claude Code pour l'implémentation

J'ai téléchargé le repo en local. J'ai lancé une session Claude Code. J'ai donné en input :

  • Le design Claude Design (HTML + CSS + assets)
  • Le repo existant
  • Une instruction simple : "voici le design, voici ce que j'ai, la source de vérité c'est le design, implémente."

Pas de spec kit, pas de BMAD, pas de framework. Juste Claude Code en direct.

10 minutes plus tard, j'avais une landing pixel-perfect. Quelques allers-retours ensuite pour affiner les détails sur mobile et corriger deux ou trois trucs spécifiques au repo existant.

Étape 3 : La construction de l'app

Une fois la landing en place, j'ai continué avec Claude Code dans la même logique pour attaquer le système d'inscription puis le cœur de l'application Juna. Stack telle que prévue dans le brief : Next.js, Postgres, intégration Claude API. Au bout d'une après-midi de boulot, j'avais une landing en prod, une inscription fonctionnelle, et le MVP de l'app codé.

C'est là que je me suis dit : "d'accord, c'est ça la combinaison qui marche pour moi."

Là où ça coince aujourd'hui : Etsy

Maintenant que le code est prêt, il manque le maillon clé : l'accès à l'API Etsy.

J'ai fait ma demande d'API key. Refus en quelques minutes, sans explication détaillée. J'ai retenté avec une formulation différente. Re-refus.

Mon hypothèse, qui n'est pas validée mais probable : dès qu'Etsy voit "IA" dans la description du projet, c'est shadowban. Le délai entre demande et refus est tellement court que je doute qu'un humain lise. C'est probablement un filtre automatique.

C'est cohérent avec une réalité 2026 plus large : les plateformes deviennent défensives face aux outils IA. Etsy a déjà des problèmes avec la prolifération de produits AI-generated qui pourrissent la marketplace, et tout outil IA qui interagit avec leur API est suspect par défaut.

Plan B : commencer par WooCommerce. L'API WooCommerce est ouverte, auto-hostée, sans gatekeeping. Je gardais Etsy pour plus tard parce que c'était la plateforme principale de ma compagne, mais dans l'immédiat je pivote pour ne pas être bloqué.

Leçon collatérale pour qui voudrait construire un outil IA sur Etsy en 2026 : prévois ton plan B dès le départ. L'accès API n'est plus garanti, et tu peux te retrouver avec un MVP fonctionnel mais sans plateforme à laquelle te connecter.

Bilan honnête : ce que l'IA change vraiment dans le process indie

Si je devais résumer ce que ces deux semaines m'ont appris :

Ce que l'IA change radicalement

Le cadrage. La phase à laquelle on consacrait des semaines mentales, qui finissait souvent bâclée parce qu'on avait hâte de coder, est devenue une session structurée de quelques heures. Étude de marché, positionnement, architecture, pricing, roadmap : tout peut être traversé proprement avec un LLM senior comme partenaire de réflexion.

La phase design pure. Claude Design produit en minutes ce qu'un designer freelance facturerait 1500-3000€ pour une landing. Si tu sais brief, tu sors un visuel propre du premier coup.

L'implémentation cadrée. Claude Code sur un brief clair et un design de référence produit du code propre, rapidement. Pas miraculeux, pas zero-shot, mais un multiplicateur de productivité réel pour qui sait reviewer.

Ce que l'IA ne change pas (encore)

Le jugement. Vérifier si un nom est libre, identifier qu'un freemium 2€ ne tient pas la route économiquement, sentir quand un LLM hallucine une feature qui n'existe pas : ça reste à l'humain.

L'orchestration multi-agents complexe. En 2026, dans mon expérience, les outils d'orchestration agent sont encore immatures pour des projets précis avec exigences visuelles. Pour du MVP brut, ils peuvent fonctionner. Pour itérer finement, le workflow direct (Claude Code, Claude Design, validation humaine en boucle courte) reste plus efficace.

Les blocages externes. Etsy ne valide pas, et ce n'est pas quelque chose qu'un agent IA va déjouer pour toi.

Le profil pour qui ça marche vraiment

Dev senior qui sait juger : multiplicateur énorme. Tu cadres mieux, tu codes plus vite, tu testes plus rapidement.

Non-technique qui veut juste un MVP : Paperclip ou des outils similaires peuvent t'amener quelque part, à condition de ne pas être pointilleux sur le résultat. Le code généré sera moche, le design générique, mais ça tournera.

Dev senior qui veut un truc précis : la combinaison Claude Design + Claude Code en direct, avec ton expertise pour orchestrer, est aujourd'hui le meilleur workflow que j'ai trouvé.

Et maintenant

L'app Juna est en local, fonctionnelle, prête à se connecter à une boutique. Je pivote vers WooCommerce le temps que la situation Etsy se débloque, ou pas, auquel cas WooCommerce reste un marché suffisant.


← Retour à tous les articles · Accueil SK Systems