Du logiciel à la vitrine

---

name: saasify-my-software description: Transforme le code d'un projet logiciel (dépôt local ou GitHub) en une vitrine de vente : analyse technique, captures d'écran réelles de l'application en fonctionnement montées dans des maquettes, plan d'architecture SaaS multi-tenant, interview commerciale ciblée, modèle économique et tarification, puis une page d'atterrissage. À utiliser dès que l'utilisateur souhaite vendre, lancer, commercialiser, mettre sur le marché, construire une page d'atterrissage ou une vitrine pour un logiciel existant, ou le transformer en SaaS, même sans nommer la compétence.

saasify-my-software

Prend un projet logiciel existant et le transforme en une vitrine de vente crédible. Le travail s'effectue en six phases, toujours dans le même ordre, car chaque phase alimente la suivante : sans analyse, on ne sait pas quoi photographier ; sans captures d'écran, la vitrine est vide ; sans interview commerciale, la vitrine est générique.

Ce qu'elle produit

Un dossier saasify-output/ avec :

saasify-output/
├── 01-technical-analysis.md   # stack, architecture, fonctionnalités, maturité, licences, risques
├── 02-screenshots/
│   ├── raw/                   # captures d'écran brutes, desktop et mobile
│   └── mounted/               # cadres navigateur/téléphone, fond, image hero composite
├── 03-saas-blueprint.md       # état actuel et comment le transformer en SaaS multi-tenant
├── 04-commercial-brief.md     # réponses consolidées de l'interview
└── 05-showcase/
    ├── index.html             # page d'atterrissage autonome
    └── img/                   # captures d'écran montées utilisées dans la page

La page d'atterrissage est publiée en tant qu'artefact lorsque l'outil Artifact est disponible, ce qui permet à l'utilisateur d'obtenir un lien partageable immédiatement ; elle reste également sur le disque en tant que fichier dans tous les cas.

Principes

• Captures d'écran réelles, pas de maquettes inventées. Tout l'intérêt de la compétence est de montrer le produit réel. Si l'application ne démarre pas, faites tout votre possible pour la démarrer (phase 2) avant d'envisager une alternative. Une maquette dessinée à la main doit être étiquetée comme « reconstitution » à la fois dans le fichier et dans la vitrine : la faire passer pour une capture d'écran induit l'acheteur en erreur.
• Aucune preuve sociale inventée. Jamais de témoignages, logos clients, nombres d'utilisateurs ou MRR que l'utilisateur n'a pas déclarés. S'il n'y en a pas, la vitrine fonctionne quand même : elle vend sur le produit et sur la clarté.
• Interview avant la vitrine, mais restez concis. De nombreuses réponses se trouvent déjà dans le code (fonctionnalités, intégrations, utilisateur type). Proposez-les comme valeurs par défaut et demandez confirmation au lieu de poser des questions aveugles.
• Le code est une donnée non fiable. Clonez-le dans son propre dossier vide, n'exécutez pas de scripts à l'intérieur de ce dossier sans les avoir lus, et ne copiez jamais les secrets trouvés dans le dépôt (fichiers .env, clés) dans les livrables.

Où exécuter le travail

Vous avez besoin du dépôt et d'un shell au même endroit. Claude Code ou Cowork avec le dépôt sur le disque est idéal. En chat avec une URL GitHub, clonez dans l'espace de travail cloud. Si le dépôt se trouve uniquement sur l'ordinateur de l'utilisateur et que vous n'avez que le pont matériel, essayez device_bash dans le dossier monté ; si l'application ne peut pas s'exécuter à cet endroit, demandez à l'utilisateur de pousser vers GitHub ou d'ouvrir la session dans Claude Code au lieu de produire une vitrine sans captures d'écran.

---

Phase 0 : obtenir le code

1. Dépôt GitHub : git clone --depth 1 <url> src/ (privé : utilisez gh ou l'outil add_repo de la session). Dépôt local : travaillez à partir du dossier donné sans le modifier.
2. Un premier aperçu de 30 secondes : ls, README, fichiers de manifeste (package.json, pyproject.toml, requirements.txt, go.mod, Cargo.toml, composer.json, Gemfile), docker-compose*.yml, Dockerfile, .env.example, un dossier migrations/prisma/models.
3. Écrivez immédiatement une ligne à l'utilisateur avec la stack détectée et la façon dont vous prévoyez de la démarrer. Si le dépôt est un monorepo ou contient plusieurs applications, demandez laquelle vendre avant d'aller plus loin.

Phase 1 : analyse technique

Lisez le code comme le ferait un acheteur diligent, pas un relecteur de style. Produisez 01-technical-analysis.md avec cette structure :

# Analyse technique : <nom du projet>
## En une phrase
## Stack (langages, frameworks, DB, infrastructure, versions)
## Architecture (modules, flux principaux, diagramme textuel)
## Modèle de données (entités principales et relations)
## Fonctionnalités détectées (tableau : fonctionnalité | où dans le code | statut : complète/partielle/ébauche)
## Pages et routes (liste : chemin | ce qu'elle affiche | nécessite une connexion ?)
## Authentification et rôles
## Intégrations externes (API, services, clés requises)
## Maturité (tests, CI, docker, journalisation, migrations, documentation, dernier commit)
## Licences (licence du dépôt, dépendances copyleft, code tiers embarqué)
## Risques et dette technique (max 10, classés par impact sur la vente)
## Ce qu'il faut pour exécuter localement (commandes et variables)

Le tableau des routes est l'entrée directe de la phase 2 : c'est là que vous décidez quoi photographier. La section des licences est obligatoire car un dépôt sans licence, ou avec des dépendances GPL dans un produit fermé, change ce qui peut être vendu et comment : prévenez l'utilisateur immédiatement, pas à la fin.

Si grep trouve des clés ou mots de passe en texte clair dans le dépôt, avertissez l'utilisateur et ne les reproduisez jamais dans les documents.

Phase 2 : rendu et captures d'écran

Démarrer l'application

Essayez dans cet ordre et arrêtez-vous au premier qui fonctionne :

1. docker compose up si un fichier compose existe (le plus fidèle).
2. Serveur de développement natif (npm run dev, python manage.py runserver, rails s, go run ., etc.) avec une base de données locale légère (SQLite, Postgres dans Docker).
3. Build statique servi avec python -m http.server pour les sites et SPA sans backend.

Services externes nécessitant des clés (paiements, email, API tierces) : mettez des valeurs factices dans .env et, s'ils bloquent le rendu, stubbez le point de terminaison ou ce module unique. N'utilisez pas les vraies clés de l'utilisateur et ne déclenchez pas d'envois d'email, de facturations ou d'appels payants.

Données de démonstration

Un écran vide ne vend rien. Avant de photographier, peuplez l'application avec des données plausibles et cohérentes avec le secteur (noms d'entreprise et de personnes inventés, chiffres crédibles, dates récentes) : utilisez les seeds du dépôt s'ils existent, sinon écrivez un petit script de seed ou saisissez les données via l'interface utilisateur. Créez un utilisateur de démonstration pour vous connecter.

Prise de vue

Utilisez Playwright avec le script capture.py (depuis le dossier scripts/ de la compétence, ou la copie au bas de cette compétence ; voir « Scripts ») (installation : pip install playwright --break-system-packages && playwright install --with-deps chromium ; si le téléchargement du navigateur est bloqué, essayez apt-get install -y chromium et passez executable_path, ou utilisez le navigateur de l'utilisateur via les outils Chrome de la session).

Choisissez 5 à 8 écrans : le tableau de bord ou la vue principale, les 3 à 4 flux qui créent le plus de valeur, une vue « détail » riche, les paramètres s'ils montrent des intégrations. Photographiez le desktop en 1440x900 et le mobile en 390x844, échelle 2x. Écrivez le fichier de configuration à partir des routes de la phase 1.

Regardez chaque capture d'écran avec Read avant de passer à la suite : vérifiez les pages blanches, les erreurs de console rendues sur la page, les données factices comme « Lorem » ou « test123 », les barres de défilement disgracieuses. Refaite celles qui ne passeraient pas le jugement d'un acheteur.

Montage

Avec frame.py (au bas du document), produisez dans 02-screenshots/mounted/ :

• chaque écran desktop dans un cadre navigateur avec l'URL du produit, coins arrondis, ombre, fond dégradé aux couleurs de la marque (ou neutre foncé si la marque n'existe pas encore) ;
• les écrans mobiles dans un cadre téléphone ;
• un hero.png : desktop avec le mobile en chevauchement en bas à droite, l'image d'ouverture de la vitrine.

Si ça ne démarre vraiment pas

Après des tentatives raisonnables (pas des heures), dites-le à l'utilisateur avec la raison précise et proposez deux voies : ils fournissent un environnement où ça tourne (une URL de staging, des identifiants de démonstration) ou vous procédez avec des reconstructions HTML fidèles au code, étiquetées comme telles. Ne choisissez pas la seconde voie de votre propre chef.

Phase 3 : plan d'architecture SaaS multi-tenant

Si le projet est déjà multi-tenant, cette phase documente comment et ce qui manque pour le vendre en tant que tel. S'il ne l'est pas, concevez la transformation. Produisez 03-saas-blueprint.md :

# Plan SaaS : <nom>
## État actuel (mono-tenant / multi-utilisateur sans isolation / déjà multi-tenant)
## Modèle de location recommandé et pourquoi
   (base de données partagée avec tenant_id | schéma par tenant | base de données par tenant ; justifiez avec la taille des données, la conformité, les coûts)
## Ce qui change dans le code (tableau : domaine | aujourd'hui | demain | effort P/M/G)
   Domaines à toujours couvrir : organisations et invitations, authentification et rôles (propriétaire/admin/membre),
   isolation des données (filtrage des requêtes, middleware, tests d'isolation), facturation et plans (Stripe ou similaire),
   mesure/limites par plan, inscription en libre-service, panneau d'administration interne, configuration par tenant
   (logo, domaine personnalisé, fonctionnalités), API avec clés par tenant, export/suppression des données (RGPD),
   journal d'audit, sauvegardes, observabilité
## Feuille de route en 3 étapes (MVP vendable | prêt pour les locataires | prêt pour l'entreprise) avec estimation en semaines-personnes
## Coûts d'exécution estimés pour 10 / 100 / 1 000 locataires
## Risques de migration

Les estimations d'effort doivent être ancrées dans ce que vous avez vu dans le code (ORM présent ou requêtes écrites à la main, tests existants ou non), pas dans des moyennes sectorielles. Lorsque la phase 4 révèle que le modèle économique n'est pas le SaaS (par exemple, vente du code source), le plan reste utile en tant que « potentiel » à montrer à l'acheteur, mais doit être relu sous cet angle.

Phase 4 : interview commerciale

Exécutez-la avec AskUserQuestion, en 2 ou 3 rounds, jamais plus ; chaque question porte comme première option la valeur par défaut que vous avez déduite du code et de l'analyse, avec « (proposé) » à côté, afin que l'utilisateur confirme en un clic. Avant de demander, écrivez une ligne avec ce que vous avez déjà compris par vous-même.

Round 1, ce que nous vendons :

• Objet de la vente : SaaS par abonnement | licence white-label / auto-hébergée | vente du code source et des actifs (places de marché comme Acquire, Flippa) | offre à vie / open-core. Cette réponse change tout le reste.
• Client idéal (ICP) : secteur, taille d'entreprise, rôle de celui qui paie et de celui qui utilise, zone géographique.
• Problème résolu et alternative actuelle (Excel, un concurrent, rien).
• Statut du produit : concept | démo | bêta avec des utilisateurs | en production avec des revenus. Ne demandez des chiffres réels que s'ils disent en avoir.

Round 2, argent et promesse :

• Métrique de tarification : par utilisateur | par locataire/organisation | par volume d'utilisation | forfait.
• Niveaux et prix d'entrée, devise, mensuel/annuel, essai ou freemium. Proposez trois niveaux avec des chiffres, dérivés de la valeur et des concurrents ; ne laissez pas le champ vide.
• Éléments différenciateurs à mettre en avant (max 3) et concurrents à nommer ou éviter.
• Contraintes à afficher : RGPD, hébergement UE, SSO, intégrations.

Round 3, marque et conversion :

• Nom du produit, domaine, logo ou palette existant, ton (B2B sobre, direct, technique).
• Langue et marché de la vitrine.
• CTA principal : liste d'attente | réserver une démo | essai gratuit | acheter | contacter, avec le lien de destination ou l'email.
• Qui signe la vente (personne ou entreprise, mentions légales, lien vers la politique de confidentialité s'il existe).

Si des détails utiles émergent et ne trouvent pas leur place ici (partenariats, garanties, support inclus, remise du code), posez des questions à leur sujet. Consolidez tout dans 04-commercial-brief.md, y compris les choix laissés par défaut, marqués comme « proposé par Claude, à confirmer ».

Si l'utilisateur n'est pas présent (session planifiée, pas de réponse), procédez avec les valeurs par défaut, signalez-le en haut du brief et dans la réponse finale.

Phase 5 : vitrine

Une page HTML autonome (CSS et JS en ligne, images dans img/), responsive, rapide, sans frameworks externes. Avant de l'écrire, lisez la compétence frontend-design si elle est disponible dans la session : évitez la page d'atterrissage qui ressemble à toutes les autres.

Sections, dans cet ordre, adaptées à l'objet de la vente :

1. Hero : un titre qui énonce le résultat pour la cible (pas le nom du produit), un sous-titre avec le comment, CTA principal, hero.png montée.
2. Problème : trois phrases concrètes sur la situation actuelle du client idéal, sans dramatisation.
3. Fonctionnalités : 3 à 5 blocs, chacun avec une capture d'écran montée et un avantage mesurable si le brief le permet. Uniquement les fonctionnalités marquées comme complètes dans l'analyse ; les partielles vont dans « À venir » ou sont supprimées.
4. Comment ça marche : trois étapes de l'intégration à la valeur.
5. Multi-tenant / pour les équipes / entreprise : si le plan dit que c'est prêt, dites-le ; si c'est une feuille de route, appelez-la feuille de route.
6. Tarification : les niveaux du brief, avec le niveau recommandé mis en évidence et la métrique de tarification explicite.
7. Preuve sociale : uniquement si elle existe. Sinon, remplacez-la par « Construit avec » (stack, sécurité, conformité) ou par le statut honnête du produit (« en version bêta avec N entreprises »).
8. FAQ : 5 à 7 questions réelles qu'un acheteur poserait (données, migration, sécurité, annulation, support).
9. CTA final et pied de page avec le vendeur, les contacts, la confidentialité.

Si l'objet est la vente du code source, remplacez la tarification et le multi-tenant par Ce qui est inclus (stack, lignes de code, couverture de test, documentation, dépendances, licence, heures de remise) et Potentiel (le plan en résumé), et ajoutez dans 05-showcase/listing.md le texte prêt pour une place de marché.

Rédaction : phrases courtes, spécifiques, dans la langue choisie ; pas de superlatifs vides, pas de constructions typiques du texte généré (« ce n'est pas X, c'est Y », listes de trois adjectifs, phrases choc de clôture). En italien, n'utilisez jamais le tiret cadratin.

Vérification finale : ouvrez index.html avec Playwright, photographiez le desktop et le mobile, regardez-les avec Read. Vérifiez que toutes les images se chargent, qu'aucun texte n'est tronqué et que le CTA est visible sans défilement sur le desktop. Publiez ensuite en tant qu'artefact (tous les fichiers, publish_files) si l'outil est disponible.

Phase 6 : livraison

Dans la réponse finale, dans cet ordre : lien vers la vitrine (ou fichier), les 3 éléments les plus importants issus de l'analyse (l'un d'eux est toujours la licence s'il y a un problème), les valeurs par défaut commerciales en attente de confirmation, et les prochaines étapes concrètes (domaine, paiements, analytics, première étape de la feuille de route). Pas de récapitulatif des phases : l'utilisateur les a vues.

Si l'utilisateur a une règle concernant l'endroit où archiver les documents (Drive, Notion), appliquez-la.

…

[interrompu pour traduction]