Dans cet article, je vais revenir sur les étapes, les difficultés et les solutions que j’ai mises en place pour créer le service Confdays, projet en solo-preneur sur lequel je travaille depuis plusieurs années sur mes heures de temps libre.

Le projet Confdays est un service SaaS, c’est à dire hébergé dans le cloud et disponible via la souscription d’un abonnement. Ce service s’adresse aux organisateurs de conférence. L’objectif est de proposer une solution rapide pour mettre en ligne un site web de conférence, gérer l’appel à contribution et suivre l’évaluation des propositions de “talk”.

En 2008, après plusieurs années de salariat, je décide de devenir webdesigner indépendant. Afin d’éviter l’isolement et rencontrer la communauté web, je propose ma candidature à l’équipe d’organisation de la conférence Paris Web. Ma candidature est refusée, l’équipe pour 2008 étant déjà constituée, en revanche on m’encourage de candidater pour proposer un sujet sur le webdesign. Le sujet est accepté, c’est ma première expérience de conférencier. L’année suivante en 2009, j’intègre l’équipe d’organisation affecté au pôle “Orateurs”.

En 2010, un peu lasse de la relation client et de la difficulté de trouver des missions de webdesign correctement rémunérées, je me spécialise sur le CMS WordPress qui est en plein essor.

Dans l’écosystème WordPress, plusieurs freelances se lancent dans l’entrepreneuriat avec succès. L’idée de me lancer à mon tour me trotte dans la tête. Quelques temps plus tard, à la sortie d’un barcamp WordPress, deux amis freelances et moi décidons de créer une boutique de thèmes WordPress: peaxl.com

Deux ans plus tard, je quitte l’équipe Peaxl pour lancer ma propre boutique “Kattagami” et commence le développement d’un thème WordPress pour les organisateurs de conférence. L’offre pour ce type de thème est pauvre et je vois de plus en plus de conférences qui éclosent sur le web. Je me dis donc qu’il y a peut être un marché de niche à creuser. L’idée me plaît d’autant plus que j’ai l’expérience de l’organisation de conférence et que je connais assez bien le besoin.

Lors de mes expériences dans les équipes d’organisation, j’observe souvent le process suivant :

Les candidats postulent via un formulaire en ligne, les sujets sont recopiés dans un fichier Excel partagé dans lequel tous les membres de l’équipe d’organisation commentent et évaluent les sujets. Une fois les sujets sélectionnés, les lauréat.e.s et leur sujet sont de nouveau saisis dans l’espace d’administration du site web de la conférence. Les orateur.e.s dont le profil est incomplet doivent être relancé.e.s. par mail.

Ce workflow me semble perfectible si on réuni toutes ces actions dans une application web afin d’éviter les saisies manuelles d’un soft à l’autre. L’idée d’un site web de conférence couplé à un tableau de bord pour gérer l’appel à contribution fait son chemin.

A partir de ce moment là, va commencer une longue série de tricotage/détricotage de code, de changement d’outils, d’apprentissage de technologies, de changement d’idées et de business model. Je tombe dans le piège du codeur solitaire qui code son produit fini sans se soucier des aspects marketing. Je n’ai jamais entendu parler du Lean Startup et de MVP. Les aspects techniques absorbent toute mon attention.

Plus j’avance dans le développement du thème, plus je prend conscience que le développement d’un thème générique de conférence qui soit facile à personnaliser demande une charge de travail importante pour un développeur/designer solo. De plus les boutiques de thèmes WordPress et les places de marchés comme Theme Forest se multiplient. L’offre et le niveau technique des thèmes augmente de façon vertigineuse en quelques années. Je commence à douter de la pertinence, pour un solo-preneur, de se lancer dans une boutique de thèmes WordPress. La maintenance du code et le support demandent également beaucoup de temps. Comment gérer cette masse de travail quand la boutique proposera plusieurs thèmes ?

A cette époque, Noel Tock développeur WordPress, lance un service SaaS intitulé “Happytable” qui propose un site clés en main pour les propriétaires de restaurants. Le concept m’interpelle et me semble comporter plusieurs avantages :

On se focalise que sur un seul produit.

Le système par abonnement assure des revenus récurrents.

L’environnement technique est maîtrisé ce qui élimine les problématiques de compatibilité avec des hébergeurs exotiques ou low cost.

Je décide donc de changer de business model en me tourne vers le model SaaS. Je n’ai alors aucune idée de la façon de construire un service SaaS.

Après quelques recherches, je découvre que “Happytable” utilise le mode multisite de WordPress pour proposer ses sites clients. Je connais l’existence du mode multisite de WordPress mais ne l’ai jamais vraiment utilisé. Je dois donc me former à l’outil, saisir les subtilités de son API et adapter mon thème de conférence à ce nouvel environnement.

Nous sommes en 2013, j’ai déménagé en Haute-Savoie et je ne fais presque plus de prestations clients afin de pouvoir avancer sur mon projet. Je vis donc sur mes économies depuis plusieurs mois en essayant de dépenser le moins possible. C’est une période difficile car ma conjointe travaille et un décalage se créer entre ses moyens financiers et les miens. Puis vient le moment où mes économies ne suffisent plus, je suis obligé de chercher un travail.

Mes nouvelles compétences vont me permettre de postuler sur un poste de développeur WordPress Multisite. Je négocie un temps partiel à 80% pour continuer le développement de “Kattagami” que je rebaptise “Confdays” après ma décision de passer au modèle SaaS.

Pour construire une interface simple, j’ai besoin de personnaliser l’espace d’administration de WordPress en supprimant l’inutile et en ajoutant des champs personnalisés complexes comme des champs qui se répètent.

Se pose alors la question d’utiliser un plugin ou coder soi même son framework ? Le plugin ACF répond en partie à mon besoin mais je ne recherche pas une interface graphique mais plutôt une API pour créer directement les metaboxes et les champs personnalisés dans le code. Je choisis donc la seconde option car à cette époque je considère que moins je dépend de ressources externes, moins je m’expose à des problèmes d’abandon de maintenance du code.

Bien que le risque d’abandon d’un outil soit réel, je finis par changer de point de vue ! Je passe beaucoup trop de temps à développer mon propre framework de champs personnalisés et à côté je vois d’autres frameworks apparaîtrent et proposer bien plus de fonctionnalités. Je dois regarder les choses en face, un solo-preneur ne peut prendre en charge tous les aspects d’un projet.

Je fais donc marche arrière et décide de travailler avec le plugin Piklist qui permet de créer des metaboxes et des champs personnalisés évolués à partir de son API. Je présente ce plugin à la conférence WPtech de Nantes. Piklist est prometteur mais son développement à des hauts et des bas. Je me retrouve en fin de développement avec des bugs bloquants qui restent non résolus pendant plusieurs mois. Comme je suis un médiocre développeur JavaScript et que je manque de temps, je ne peux aider à la résolution de ces bugs. J’essaye alors entre temps un autre framework mais me retrouve coincé par un support peu réactif. Le temps passe, j’ai l’impression de ne pas avancer, d’autant plus qu’il me reste beaucoup de travail :

- Développer le site e-commerce et mettre en place son mode de paiement.

- Développer un espace client.

- Automatiser la création d’un nouveau site après validation du paiement.

- Trouver une solution de backup.

- Mettre en place un système de démonstration.

- Mettre en place un système pour gérer le support.

Je commence à me décourager et mon rythme de travail baisse.

Je commence à réfléchir aux aspects serveur et administration système. Certaines craintes liées au mode multisite commencent à me tracasser.

En mode Multisite, WordPress fonctionne avec une seule installation et des tables supplémentaires qui s’ajoutent dans la base de données à chaque nouveau sous-site. Le succès de WordPress éveille l’intérêt des pirates informatiques et l’idée qu’une attaque impacte le fonctionnement des sites de tous mes client.e.s me fait frémir.

Quid de la performance et de la maintenance d’un serveur web quand la base de données commencera à grossir ? J’essaye d’interroger des entrepreneurs qui utilisent cette solution mais leur réponse reste imprécise. Il est évident que je vais devoir passer par un préstataire pour assurer la montée en charge et la sécurité.

J’ai aussi des difficultés à trouver une solution de sauvegarde/restauration granulaire pour chacun des sites clients. Il existe des solutions payantes mais j’essaye de réduire au maximum les coûts étant solo-preneur sans fonds de réserves pour lancer l’activité.

Enfin, l’implémentation du mapping d’URL pour proposer des URL personnalisées et la mise en place d’un certificat SSL me paraît plus compliquée sur une installation multisite. Let’s Encrypt ne gère pas encore les sous-domaines et je dois passer par un wilcard payant.

J’ai besoin d’avancer et de me rassurer, j’abandonne donc la solution multisite de WordPress et décide que chaque client.e sera hébergé.e sur son propre serveur virtuel.

Les performances seront assurées, la sécurité accrue car les clients seront isolés sur leur propre serveur, la sauvegarde/restauration plus aisées à mettre en place et la gestion des URL et du certificat SSL plus simple.

En revanche de nouveaux défis se présentent à moi:

- Comment déployer les serveurs et les sites clients dynamiquement lors de la validation du paiement ?

- Comment automatiser le paramétrage des DNS et du certificat SSL ?

- Comment mettre à jour l’application sur tous les serveurs ?

Comme je suis bloqué par des bugs non résolus sur le framework Piklist, je commence à développer le site e-commerce et l’espace client. Je choisis la solution de paiement Stripe via le plugin EDD (Easy Digital Download) et quelques Add-on. La nouvelle loi de 2015 sur la vente des produits numériques nous oblige à facturer la TVA du pays du client en Be to C. Je passe donc par le service Taxamo et un plugin WordPress qui fait le lien entre EDD et Taxamo.

L’implémentation de l’espace client est un gros morceau mais j’arrive à développer un environnement où les clients peuvent renouveler leur abonnement, accéder à leur facture, demander un nom de domaine personnalisé …

Je travaille aussi sur le déploiement dynamique des serveurs. J’étudie un temps la solution Docker mais à l’époque, la technologie est émergente et la maîtrise de cette technologie me demande trop de temps.

Je teste aussi des solutions comme Ansible, Server Pilot, Forge. Ces outils sont intéressant mais je n’arrive pas à automatiser le déploiement à partir de mon site e-commerce. Il me manque une API Rest (pour info, Server Pilot possède maintenant une API Rest).

Côté fournisseur de VPS, je teste Linode, Digital Ocean puis Vultr. Vultr a ma préférence car l’espace d’administration est simple et ergonomique. Vultr propose une API pour la création des instances serveur et la gestion des DNS. De plus, un script shell peut être exécuté lorsque le serveur est en place.

J’apprends donc à utiliser une API Rest et à développer un script Shell de déploiement. C’est à nouveau un gros investissement en apprentissage, tests et réalisation.

Le temps passe et je suis toujours bloqué avec les bugs des frameworks de champs personnalisés. Le développement de Piklist semble au point mort depuis des mois.

Au détour d’un article et de différents tweets, ma curiosité est piquée par un CMS PHP dont j’entends le plus grand bien. Il n’utilise pas de base de données mais des fichiers pour stocker les données. Il s’agit de Kirby CMS.

Gros avantage de Kirby, sa flexibilité. L’espace d’administration est entièrement customisable et se construit de zéro contrairement à WordPress où l’on doit ajouter du code pour retirer des choses ce qui me paraît contre productif. Autre avantage, Kirby possède dans son “core” des champs personnalisables répétables ! gère le multilingue et possède une documentation et un support efficace.

Étant dans une impasse avec Piklist, je prend une décision insensée: je redéveloppe tout avec Kirby.

J’aurais pu revoir mes prétentions à la baisse et abandonner certaines fonctionnalités. Rester sous WordPress et lancer quelque chose de moins ambitieux, mais la façon dont Kirby est construit va me simplifier ne nombreuses tâches.

Le développement avec Kirby se révèle une bonne surprise. Non seulement je réussis à développer toutes les fonctionnalités sur lesquelles je bloquais, mais en plus mon temps de développement s’avère beaucoup plus court et la quantité de code générée moindre.

N’ayant plus de base de données à gérer (Kirby stocke les données dans des fichiers), le déploiement et la solution de sauvegarde s’en trouve largement simplifiée.

Partie sur ma lancée et étant très satisfait de cette première expérience avec Kirby CMS, je redéveloppe aussi le site e-commerce et change de prestataire pour la solution de paiement.

Je choisis une solution plus chère en terme de commission (5,9 % + 0,95 c.) mais totalement clés en main. Ce service s’appelle FastSpring.

Il prend en charge :

- L’espace client qui gère l’accès aux factures, le changement ou l’arrêt de l’abonnement.

- Le calcul de la TVA selon le pays du prospect, son encaissement et le reversement aux administrations concernées.

Je n’ai donc rien à redévelopper de ce côté là. Il me fournit un javascript pour afficher une pop-up de paiement et me reverse mensuellement la somme qu’ils encaissent via la souscription des abonnements, commission déduite.

Nous sommes début 2018, l’idée initiale d’un site web pour organisateur de conférence a émergé en 2013. Le projet est presque finit mais il m’aura pris plusieurs années sur mon temps libre. Aux vues des techniques prônées aujourd’hui par le Lean Startup et le MVP, ce parcours illustre l’exemple de tous ce qu’il ne faut pas faire: coder un produit fini sans valider auprès de prospects la solution que vous proposez. Si vous êtes codeur.euse, avant de vous lancer dans un projet entrepreneurial et d’écrire les premières lignes de code, intéressez-vous rapidement aux aspects commerciaux et marketing.

Les leçons que je tire de cette expérience sont les suivantes :

- Monter un projet entrepreneurial seul et vouloir tout réaliser est une stratégie risquée à moins d’être très doué.e. Il faut savoir déléguer en utilisant des outils ou des services externes. La difficulté est de trouver des outils/services aboutit qui répondront à vos besoins et vous feront gagner un maximum de temps. Il faut aussi accepter l’idée que certains de ces outils/services peuvent disparaître ou rencontrer des difficultés dans leur cycle de développement. Il faudra alors trouver une alternative.

- Lorsqu’on est développeur et que l’on veut se lancer dans l’entrepreneuriat, il faut rapidement se sensibiliser à des aspects qui sortent de notre zone de confort comme le marketing, le SEO, la communication, la création d’une communauté etc. Cela permet de changer de point de vue et de prendre conscience que le code n’est qu’une partie de l’iceberg.

- Lancer un produit fait peur car on se met en danger. On expose son travail publiquement et on prend le risque d’échouer. Pour pallier cette anxiété, on est tenté de vouloir sortir un produit le plus aboutit possible afin d’éviter les critiques. C’est aussi une façon inconsciente de reculer la date de mise en ligne du projet.

- Si vous décidez de vous lancer en solo-preneur, partez sur une idée et une solution simple. Choisissez les outils de développement qui vous simplifient la vie, ce ne sont pas toujours les derniers farmework à la mode.

- Méfier-vous de l’isolement, c’est très facile pour un codeur solo-preneur de passer des heures derrière son écran. Fréquentez les meetups, les conférences, les communautés et tout évènement qui peut vous faire rencontrer du monde.

- Se lancer dans un projet web monnetisable c’est passer son temps à chercher des solutions, ne vous décourragez pas, on finit toujours par trouver et cela est très gratifiant.

Les aspects positifs de ce parcours sont les suivant :

- C’est un bon test pour mettre à l’épreuve sa persévérance.

- Je suis monté en compétences tout au long de ce projet et ces compétences me servent dans l’activité professionnelle qui me rémunère actuellement.

- J’ai découvert (sur le tard) qu’il existait des techniques pour tester ses idées de service/produit en minimisant les risques de dépenser trop de temps/d’argent. Je pense bien sure à la technique du MVP (Minimum Viable Product). J’ai encore quelques réserves sur cette technique mais elle semble avoir fait ses preuves.

- Je me suis ouvert à d’autres disciplines qui sortent de mes centres d’interêt habituel.

Si comme moi vous êtes dans l’élaboration d’un projet web que vous souhaitez monétiser ou que vous avez déjà lancé votre service/produit, n’hésitez pas à me contacter, vos témoignages m’intéressent.