Comment créer un logiciel durable ?

By Hugo LassiègeDec 19, 20257 min read

En discutant avec plusieurs personnes de Writizzy j'ai pu comprendre que l'un des sujets de préoccupation quand on choisit une plateforme pour blogger, mais aussi pour mettre des photos, des vidéos etc... c'est la pérennité. Est-ce que la plateforme ne va pas fermer dans 1 an ou 2 ? Et qu'est-ce qui se passe si jamais c'est le cas ? Est-ce que je perds mes données ? Et si elle évolue, mais dans le mauvais sens (oui je pense à toi Twitter) ?

Citations :

Je n'ai pas vraiment l'intention d'utiliser une plate-forme, une des raisons d'avoir écrit mon moteur c'est la stabilité

Avant d'utiliser Substack j'utilisais la solution de Twitter qui faisait a peu près la même chose. Et ils ont fermé du jour au lendemain, j'ai pas pu récupérer mes infos.

Bref, c'est une préoccupation normale : est-ce que l'effort que je vais mettre à tenir un blog ne va pas être réduit à néant demain ?

Je dois trouver une réponse à cette question. Comment préserver l'effort des personnes qui pourraient utiliser Writizzy ?
Et pour ça j'ai quelques éléments de réponse. Mais ce n'est pas uniquement cantonné à Writizzy, que vous utilisiez une plateforme ou que vous en construisiez une, voici le framework que j'ai utilisé pour penser à cette question.

Prévoir la réversibilité

Un des premiers sujets, selon moi, c'est de rester toujours maitre de ce qu'on produit. Il faut fournir une manière simple d'exporter ces informations.

La fonction d'import/export doit être facile à trouver, et le format doit être exploitable.

Sur Writizzy j'ai choisi un format Json qui ressemble à celui de Ghost. Et tous les posts sont inclus dedans au format markdown. La liste des abonnés à la newsletter est également incluse.

Il n'y a aucun locking sur les données et il serait facile pour un utilisateur de faire une migration vers une autre plateforme si besoin.

Le second facteur de réversibilité, c'est de créer la possibilité (optionnelle) à chacun d'utiliser son propre nom de domaine, par exemple j'utilise eventuallymaking.io. Si demain writizzy s'arrête, je pourrais toujours garder ce nom de domaine et recréer mon blog à partir de mes données. Le contenu n'est pas noyé dans un site (comme Medium par exemple) et donc je garde tout contrôle sur la façon dont je peux le récupérer, et le diffuser.

Avec le sujet de la réversibilité je pourrais aussi parler de l'interopérabilité. Comment faire en sorte que le contenu ne soit pas exclusif à Writizzy, comment l'interopérer ailleurs. Il y a déjà des solutions comme le flux RSS, les newsletters. Mais, je regarderais aussi du côté d'ActivityPub, AtProto et tout ce qui pourra permettre une meilleure décentralisation du contenu si des solutions intéressantes sont faisables.

Prévenir la merdification

Ok, ce titre est un peu étrange :)

La plupart des produits grand public ont tendance à mal vieillir, devenir trop complexe, trop cher. C'est souvent le résultat d'une double pression, celle des actionnaires d'une part qui cherche à maximiser les profits, et celle des équipes internes de l'entreprise qui ont besoin de constamment faire évoluer le produit pour justifier de leur présence.

Cory Doctorow a popularisé cette expression, mais essentiellement en parlant de la première cause, la pression des investisseurs. J'ai tendance à penser que la seconde est tout autant problématique.

Writizzy est construit différemment. Et je pense que la plupart des nouvelles boites qui se créent dans cette ère post IA et en bootstrap vont partager cette même discipline. Je ferai en sorte de construire juste ce qui est nécessaire et ensuite de faire évoluer le produit uniquement quand il le faut. Je ne vais recourir à aucun investisseur externe et je ne prévois pas de revendre ce projet.
Et je ne prévois pas d'embaucher des centaines de personnes.

Je pense qu'il est possible et même plutôt sain de construire "lentement mais surement" pour ce type de projet.

Etre viable économiquement

Durer implique que le produit ne soit pas un gouffre financier. La première réponse est donné par le chapitre précédent, je n'ai pas d'investisseurs, je ne vais pas embaucher pour cramer un budget que je n'ai pas et je sais ce que c'est de que de créer un produit pour l'avoir fait plusieurs fois. Je sais développer à l'économie.

Sur Hakanai.io (un autre produit que je créé), je ne fais pas des milliers d'euros, mais le produit rapporte plus qu'il ne coute. Writizzy n'est vieux que d'un mois et demi, et c'est déjà le cas également. Parce que c'est simple aujourd'hui de créer des produits avec peu de moyens.

Evidemment, je pourrais ne pas en vivre, mais je ne compte pas dessus pour l'instant, et Thomas (qui crée ce produit avec moi) non plus. Je ferais en sorte que ça puisse arriver, ne serait-ce que pour démontrer que j'en suis capable, mais j'ai la possibilité d'attendre longtemps.

Une technologie durable

Bon, ça c'est la partie la moins réalisable dans le sens ou aucune technologie n'est vraiment durable. Tous les languages, tous les frameworks nécessitent d'être mis à jour régulièrement, notamment pour les failles de sécurité, la compatibilité avec les OS sous-jacent etc...

Pour autant, il y a quelques bonnes pratiques à avoir et notamment éviter les lockins techniques, ne pas reposer majoritairement sur une plateforme dont on ne pourrait pas se passer (éviter un gros vendeur cloud par exemple, ou datadog etc...) Il faut toujours prévoir des alternatives, des plans de secours si un outil utilisé devenait trop cher, ou mourrait.

Writizzy tourne sur une stack standard (kotlin, nuxt) avec un outil PAAS qui serait facile à échanger (Coolify avec Traefik), sur un serveur VPS tout ce qu'il y a de plus simple chez Hetzner.

On pourrait me demander, mais pourquoi ne pas en faire un produit open source ? C'est évidemment, en apparence, une garantie ultime de pérennité.
Je dis bien, en apparence, parce que l'histoire nous a montré que des projets open source pouvaient être accaparé par leurs créateurs (Cf Wordpress et ces différents dramas).
La question n'est pas forcément open source ou pas open source, mais quelles sont les intentions de ces créateurs ?
Il existe beaucoup d'exemples d'openwashing — des projets qui utilisent l'étiquette "open source" comme canal d'acquisition ou argument marketing, sans que ce soit une conviction profonde.

Dans tous les cas, l'opensource vient aussi avec des contraintes. Aujourd'hui Writizzy c'est 3 applications distinctes, ce qui n'est pas forcément dans les standards de ce qu'on aime déployer pour de l'open source. C'est aussi un produit qui est pensé comme une plateforme et pas un produit qu'on utiliserait de facon personnelle uniquement. Enfin, il y a un sujet d'exploitation commerciale, je ne souhaite pas avoir d'autres personnes qui profiteraient de mon travail gratuitement pour revendre ce que j'ai créé.

Je pourrais revenir sur ce sujet dans le futur en fonction de comment le produit évolue. Mais pour l'instant, cette option est écartée.

Si jamais par contre Thomas et moi décidions d'arrêter ou si nous avions un accident, ce serait une des conditions qui déclencherait un passage en open source et je vais prévoir des solutions pour que ca se fasse tout seul le cas échéant.

Etre mon premier utilisateur (dogfooding)

Enfin dernier point, je bloggue depuis 20 ans. Je suis actuellement l'utilisateur le plus prolifique sur Writizzy avec plus de 80 articles déjà présents (mais je triche, j'ai migré mes anciens articles ^^). Je construis cet outil parce que je l'utilise. Je pense que c'est beaucoup plus facile de construire un produit qu'on comprend parce qu'on est soit même utilisateur. Et ça aussi, c'est un facteur de longévité.


Share this:

Written by Hugo Lassiège

Software engineer, ex-freelance, ex-cofounder, ex-CTO. I love building things, sharing knowledge and helping others.

Copyright © 2026
 Eventuallycoding
  •
Powered by Bloggrify