Les coulisses, épisode 06 : Partage, sortir de l'atelier

On peut passer des années à construire quelque chose que personne ne sait trouver.

C'est presque ce qui nous est arrivé.

Nous avions appris à développer des applications, à les héberger, à les faire communiquer et à suivre leurs revenus. Skalpai les testait et les déployait. Spore leur permettait d'envoyer des messages. Lungor organisait leurs paiements. Synthiz conservait ce que nous apprenions. L'Alter nous assistait au quotidien.

Les applications existaient. Elles fonctionnaient ensemble. Je les utilisais quotidiennement, tout comme plusieurs personnes de mon entourage.

Pourtant, presque personne ne les connaissait.

Nous savions construire.

Il fallait maintenant apprendre à sortir de l'atelier.

Pourquoi ne pas avoir commercialisé plus tôt ?

Les applications de la Fabrique ne sont pas des prototypes indépendants les uns des autres.

Elles s'utilisent entre elles. Elles partagent une infrastructure, des moyens de communication, un système de paiement et des outils de suivi. Une transformation apportée à l'une peut modifier le fonctionnement des autres.

Pendant leur construction, certains choix techniques ont été profondément revus. Des interfaces ont été remplacées. Des services ont été rapprochés. Des fondations entières ont évolué pour répondre aux difficultés rencontrées.

Ne pas avoir encore de clientèle nous donnait une liberté précieuse : nous pouvions effectuer ces changements rapidement, sans imposer chaque migration à des personnes qui dépendaient déjà du système.

Avec des clients, nous aurions dû préserver davantage de compatibilité, prévenir, accompagner et parfois conserver des choix que nous savions déjà devoir remplacer.

Cette période nous a permis d'éprouver les applications dans notre propre usage et d'améliorer considérablement leur qualité.

Mais elle avait aussi une limite.

Utiliser soi-même un produit permet d'en éprouver le fonctionnement. Cela ne prouve pas qu'un marché existe.

Notre usage quotidien ne validait ni le positionnement des applications, ni leur prix, ni leur capacité à trouver des utilisateurs.

Attendre davantage n'aurait plus seulement amélioré les produits. Cela aurait aussi retardé les apprentissages que seuls des utilisateurs extérieurs peuvent apporter.

Nous connaissions notre métier, pas encore celui-ci

Notre expertise était principalement technique.

Nous savions transformer un problème en application. Nous savions construire une infrastructure, automatiser des tests et déployer une nouvelle version.

Mais savoir fabriquer quelque chose ne donne pas automatiquement la capacité de le faire connaître.

Comment expliquer une application sans réciter ses fonctionnalités ? Comment trouver les personnes auxquelles elle peut réellement servir ? Comment comprendre leurs besoins sans leur faire confirmer notre propre idée ? Comment choisir un prix ? Où publier ? Avec quel message ?

La commercialisation exigeait d'acquérir de nouvelles compétences : positionnement, écoute, acquisition, tarification et communication.

Cinq lectures nous ont servi de premiers repères :

• —Do Things That Don't Scale, de Paul Graham, pour aller chercher les premiers utilisateurs un par un ;
• —The Mom Test, de Rob Fitzpatrick, pour comprendre des besoins réels sans orienter les réponses ;
• —Traction, de Gabriel Weinberg et Justin Mares, pour tester méthodiquement les canaux d'acquisition ;
• —Obviously Awesome, d'April Dunford, pour apprendre à situer un produit face aux solutions existantes ;
• —Pricing Low-Touch SaaS, de Patrick McKenzie, pour réfléchir aux offres et aux prix d'un logiciel accessible en libre-service.

Voir nos lectures sur la commercialisation →

Une nouvelle étape commençait.

Il ne suffisait plus de construire les applications. Il fallait apprendre à les présenter, à les publier et à créer des occasions de les rencontrer.

Une idée, quatre plateformes

La difficulté est apparue très concrètement.

Pour parler d'une application, il faut commencer par écrire. Ensuite, il faut adapter le texte à l'endroit où il sera publié.

Un texte destiné à LinkedIn ne prend pas nécessairement la même forme sur Bluesky. X impose ses propres contraintes. Dev.to accueille des contenus plus longs et plus techniques.

La même idée devient alors plusieurs publications.

Il faut ouvrir chaque plateforme, reprendre le texte, l'adapter, vérifier sa longueur, choisir une date et revenir au bon moment pour le publier.

Puis recommencer quelques jours plus tard.

Nous avions construit des applications pour éviter cette dispersion dans la connaissance, les e-mails, les paiements et le déploiement.

Elle revenait maintenant dans notre communication.

Une idée était écrite une fois, mais son partage exigeait encore quatre travaux différents.

C'est de cette répétition qu'est né Partage.

Un brouillon, plusieurs publications

Partage est un outil de publication sociale.

Il prend un seul brouillon, le réécrit au format de chaque plateforme — LinkedIn, Bluesky, X et Dev.to — puis publie chaque version à la date choisie, sans que vous ayez besoin d'être devant votre écran.

Le principe tient en quatre étapes :

1. —vous écrivez l'idée que vous souhaitez transmettre ;
2. —Partage l'adapte au format et au ton de chaque plateforme ;
3. —vous choisissez les réseaux et les dates de publication ;
4. —Partage publie les différentes versions au moment prévu.

Il ne s'agit donc pas de copier exactement le même texte partout.

Une publication peut conserver davantage de contexte sur LinkedIn, devenir plus directe sur Bluesky, respecter les contraintes de X ou prendre la forme d'un contenu plus développé sur Dev.to.

L'idée reste la même.

Sa forme s'adapte à l'endroit où elle sera lue.

Faciliter l'écriture, pas inventer une conviction

Partage facilite également la génération des publications.

Un brouillon n'a pas besoin d'être un texte terminé. Il peut partir d'une idée, de quelques phrases ou d'un message encore imparfait. Partage aide à le transformer en plusieurs versions prêtes à être publiées.

Mais il ne doit pas inventer ce que vous pensez à votre place.

Il ne connaît ni votre expérience ni les raisons profondes pour lesquelles vous avez construit quelque chose. Il ne peut pas fabriquer une expertise qui n'existe pas.

Son rôle est de réduire la distance entre une idée et sa publication.

Partage ne remplace pas ce que vous avez à dire. Il vous aide à réellement le dire.

Cette distinction est importante.

Nous ne voulions pas construire une machine destinée à remplir les réseaux de textes génériques. Nous voulions retirer les tâches répétitives qui finissent par empêcher une personne de partager ce qu'elle connaît véritablement.

Publier sans organiser sa journée autour d'un réseau

La programmation est l'autre partie du problème.

Préparer une publication ne signifie pas nécessairement vouloir l'envoyer immédiatement. Certaines doivent accompagner la sortie d'un article. D'autres correspondent à une annonce, à une étape du projet ou à un moment particulier de la semaine.

Sans outil, le calendrier de communication devient rapidement une suite de rappels :

ouvrir LinkedIn à 9 h
publier sur Bluesky à 11 h
revenir sur X
mettre la version longue sur Dev.to

Partage dissocie la préparation de la publication.

Le texte peut être écrit lorsque l'idée est claire. Les versions peuvent être préparées ensemble. Les dates sont choisies ensuite. Une fois le calendrier défini, Partage publie sans demander que quelqu'un interrompe son travail au moment prévu.

Ce n'est pas spectaculaire.

C'est précisément pour cela que c'est utile.

La publication devient une tâche préparée à l'avance plutôt qu'une interruption répétée.

Partage ne trouve pas des utilisateurs à notre place

Partage facilite la communication. Il ne résout pas à lui seul la commercialisation.

Publier davantage ne garantit ni l'attention ni l'intérêt. Un mauvais positionnement reste mauvais lorsqu'il est diffusé sur quatre plateformes. Un message qui ne répond à aucun besoin ne devient pas utile parce qu'il a été programmé.

Partage ne remplace pas les conversations avec les premiers utilisateurs. Il ne choisit pas notre marché. Il ne fixe pas nos prix et ne décide pas de ce que nous devons construire.

Il retire une friction particulière : transformer régulièrement une idée en plusieurs publications adaptées et les envoyer au bon moment.

Cette friction paraît petite.

Répétée chaque semaine, elle suffit pourtant à faire disparaître beaucoup de bonnes intentions éditoriales.

Le premier utilisateur de Partage, c'est la Fabrique

Partage est d'abord devenu l'outil avec lequel nous faisons connaître les autres applications.

Les articles peuvent être annoncés sur plusieurs plateformes. Une étape de développement peut devenir une publication. Une difficulté technique peut être racontée. Une nouvelle application peut progressivement rencontrer ses premiers utilisateurs.

Chaque publication réalisée avec Partage sert donc deux fois.

Elle présente une application de la Fabrique, tout en éprouvant Partage dans son usage réel.

Nous pouvons constater les adaptations qui fonctionnent, celles qui déforment le message, les formats qui manquent et les étapes qui restent trop longues.

Comme les autres applications, Partage commence par être utilisé avant d'être promis.

Sortir de l'atelier

Les premiers épisodes de cette histoire racontaient principalement la construction.

Il fallait acquérir les moyens de conserver la connaissance, d'envoyer des messages, de gérer les paiements, de développer, de tester et de déployer.

Avec Partage, la question change.

Nous ne cherchons plus seulement à savoir comment produire une application. Nous cherchons à savoir comment lui permettre de rencontrer celles et ceux auxquels elle pourrait servir.

Nous n'avons pas commercialisé plus tôt parce que l'ensemble changeait encore profondément et que nous voulions d'abord pouvoir compter sur lui.

Nous commençons maintenant parce qu'aucune amélioration interne ne remplacera la rencontre avec de véritables utilisateurs.

Jusqu'ici, nous apprenions à construire. Avec Partage, nous commençons à apprendre à être vus.

Publier permettra de faire connaître les applications.

Il faudra ensuite pouvoir poursuivre directement la conversation avec celles et ceux qui répondront.

Ce sera l'histoire de Messag.