Les projets entrepreuneuriaux c'est comme l'Art contemporain : il y a toujours quelqu'un pour dire "nan mais moi aussi si je veux je le fais" ou "j'avais eu la même idée qu'eux y a 10 ans, je pourrais être millionnaire" pour au final ne jamais rien faire. Sauf que faire les choses c'est dure et les idées n'ont de valeur que si elles se réalisent.

Voyons ça très concrétement avec mon propre projet.

Le diable et ses détails

J'ai appris, en matière de marketing, que la clarté de l'offre était positivement corrélée avec la réussite ( et logiquement, l'absence de clarté était un bon moyen de ne rien produire).

C'est quelque chose de bien connu dans le monde du développement informatique. Le meilleur moyen d'échouer un projet c'est d'avoir des demandes vagues et ambigües. Pour pallier à ça, vous trouverez souvent dans les équipes de projets informatiques des gens chargés de :

• diviser le projet en tâches élémentaires factuelles et evidentes ("Rajouter un champ 'dernière connexion' sur la table 'utilisatrice'" et non "Améliorer le systeme de téléchargement des produits")
• faire préciser l'attendu par les commanditaires ("Quand je me connecte je veux voir une alerte en orange si j'ai pas regardé le tableau de bord depuis 15 jours")

Mais même un objectif exprimé simplement ne signifie pas que la tâche derrière va l'être. Dans mon cas, mon objectif il y a un an était plutôt clair :

Je veux pouvoir

• vendre un pdf en ligne sur une page web
• sans inscription
• avec une jauge des ventes visibles pour les lecteurices

C'est clair, c'est simple. J'avais même un design fonctionnel :

Techniquement, vu comme ça, cela ne parait pas excessivement compliqué :

• une table dans la base de donnée avec la liste des livres en ventes, leurs prix etc.
• Une autre table avec les ventes effectuées, pour le compteur

et en terme de séquences :

1. on affiche la page d'accueil
2. ainsi que une petite progress bar avec le nombre de ventes en cours
3. si l'utilisatrice clique sur acheter elle est envoyée sur une page ou elle rentre ses coordonnées bancaires (dans un formulaire sécurisé. Il y a un moyen précis de faire ça que je n'aborderais pas ici)
4. si la transaction est acceptée, la banque alerte mon serveur qui génère un lien signé et l'envoi par email à l'adresse indiquée.

En matière de design, la fonction précède la forme et d'une manière générale j'aime bien me contenter de mettre sur mes applis que ce qui sert une fonction précise.

Mais ce qu'on ne voit pas ici c'est l'envers du décor.

Comptabilité

Commencons par le premier point, que j'avais très mal anticipé à cause d'un malheureux concours de circonstance.

Dès que vous vendez quelque chose, cela signifie que vous avez une activité commerciale. Celà implique 2 points majeurs :

• vous devez appliquez la TVA à vos produits
• vous devez pouvoir justifier de vos ventes avec une facture

C'est écrit ici :

Lorsqu'une entreprise vend un bien à un particulier, l'émission d'une facture (ou d'une note) est obligatoire ... pour les ventes à distance

S'ensuit la définition de ce qu'est une vente à distance. Qui vous apprend aussi que toute vente à distance doit s'accompagner de plusieurs informations au client qui doivent évidemment être claires et explicitement acceptées (vous savez, les conditions générales de ventes ou d'utilisation que personne ne lit jamais)

Et s'ensuit aussi les "mentions obligatoires sur une facture : nom complet du client et adresse de facturation"

A peine commencé, à périmètre fonctionnel identique, il faut déjà rajouter à l'application :

1. un ecran avec les CGV. CGV que je dois faire rédiger par un‧e professionel‧le (450€),
2. les infos perso au formulaire d'achat, plus une case "j'ai lu les cgv" plus une case "j'ai compris que je renonçais à mon droit de rétractation" (car c'est un produit numérique à télécharger, on a donc le droit de vous le proposer en tant que vendeur)
3. un générateur de facture en PDF

Le 1. est trivial.

Le 2., vous dites vous, est trivial aussi, mais non. Il s'agit de rajouter un formulaire avec plusieur champs et les messages d'erreurs qui vont avec, ce qui soulève dont des questions de mise en page. Rien d'impossible mais pas trivial non plus

Le 3.

Le 3.

Générer une facture en pdf. Vous n'avez aucune idée de la difficulté de générer une facture en pdf, avec tous ses champs à mettre en page, l'alignement, le respect de la charte graphique,…

Et surtout, cerise sur le bébé, en 2026 c'est l'année DU PASSAGE A LA FACTURE ELECTRONIQUE.

Dorénavant, tout facture doit être émise au format éléctronique. Qu'est ce que ca veut dire concrétement ? Aucune idée.

Est ce que ca me concerne ? pffffrt. Aucune idée. même mon comptable ne sait pas.

Un an après, je peux vous faire le retour d'expérience. Dans un précedent article j'évoquais la question du Build or Buy. He bien ici ca aurait été un Build. Après avoir essayé d'implémenter tout ça moi même, j'ai décidé de payer 19€ par mois pour ne pas perdre 20 jours à faire ce que d'autres font déjà mieux que moi

GDPR

Cette question de facturation à une conséquence assez déplorable et que je voulais éviter à tout prix : mon appli web se retrouve maintenant à manipuler des données personnelles (Nom, Prénom, Adresse, email) et tombe donc sous le coup de la RGPD

En Europe, et c'est heureux, tout entreprise qui manipule des données personnelles est soumise à certaines contraintes et obligations. Je trouve ca très bien mais ce que je trouve encore mieux c'est de NE PAS manipuler et enregistrer de données personelles.

Dans mon cas, j'avais initialement un système assez malin où l'email, seule donnée personelle que je manipule, était chiffré de manière légère, maintenue en mémoire vive uniquement (jamais sauvé en base ) et servait à signer le lien de téléchargement comme preuve de d'achat. C'était super malin.

Mais les règles du commerce impose de conserver les données personelles, 10 ans même.

Bilan ? Une dizaine de jours supplémentaires pour renforcer la sureté du serveur, mettre un systeme de clés tournantes (rotation) en place, chiffrer les sauvegardes, distribuer mes clés…

Rien qui ne sorte du champ de compétence d'un développeur mais un point à prendre en compte : dès que vous manipulez des données confidentielles ou importantes, cela signifie que votre infrastructure doit gérer la sécurité et les sauvegardes. Et si votre appli a des utilisateurices, cela veut dire données confidentielles à protéger.

La tva

Un point rapide sur la TVA.

Les produits en France doivent être vendus en incluant la TVA. Vous vous dites qu'il suffit de multiplier tous les prix par 1,2 ( +20%) ?

Non. Car la TVA dépend du produit. Voyons quelques règles :

• TVA d'une bd numérique ? 5,5%. Facile
• TVA d'un don (tip) ? 0% sauf si le don est assortie d'une contre partie. Dans ce cas c'est le montant de la tva de la conterpartie qui s'applique
• TVA d'un fichier PSD à colorier : 20%. Ce n'est pas un livre.
• TVA d'un abonnement à un site web: 20%. Sauf si ca permet uniquement de lire des bd dans ce cas c'est 5.5%
• TVA d'un fichier zip qui contient une bd en pdf et des fonds d'ecrans HD tirés de la BD ? 5.5% pour le pdf et 20% pour les fichiers. Il vous faut donc définir le prix et le type de chaque fichier dans votre zip de manière indépendante.
• TVA à appliquer si c'est un belge qui achète votre BD ? TVA des produits belges (car c'est la TVA du pays de l'acheteur qui s'applique en Europe) sauf si le pays a aussi un taux réduit sur le livre, qui est alors celui à appliquer.

Pour générer le prix correcte et l'information nécessaire aux services fiscaux il faut donc vérifier le pays de l'acheteur, rajouter des options "TVA réduite / tva complete" a vos produits et maintenir à jour une table des TVA de chaque pays.

Encore un truc en plus qui n'est pas directement lié à la fonctionnalité première.

Mauvaise foi

Précisons que la règle de la TVA de l'acheteur ne s'applique qu'une fois le seuil de 10 000€ par an en Europe mais hors de France franchi.

Il y a un dicton dans le monde du dev qui dit "premature optimisation is the root of all evil" (une optimisation précoce est la source de tous les maux) et je suis relativement réaliste sur le fait que je ne risque pas de faire 10 000€ de ventes en belgique cette année. Si ça arrive, je prendrais le temps de faire les corrections qui s'impose. Pour l'instant je vais me contenter de noter le code du pays de chaque acheteur et acheteuse, ce qui devrait permettre de régulariser quand le cas se présentera.

Email

Vous vous souvenez du produit ? Quand l'acheteureuse à payer, on lui envoit un email avec un lien de téléchargement.

Si vous deviez mettre une évaluation entre 1 et 10 sur la difficulté d'envoyer un email en 2026, combien mettriez vous ?

Multipliez votre évaluation par 40.

Qui plus est, dans mon cas, on doit envisager d'envoyer 5000 emails par mois si tout se passe bien (5000 c'est à peu pres le seuil de rentabilité de mon projet). Envoyer 5000 emails sans précaution c'est s'assurer que votre domaine est déclaré comme compte de SPAM par tous les serveurs d'email du monde.

J'ai essayé. J'ai cru que j'étais plus malin que les autres.

L'email en matière de dev informatique c'est comme le manuscrit de Voynich pour les linguistes et crypto analystes : tout le monde arrive super confiant en se disant que les autres étaient des c*ns et repart en pleurant sa maman.

Bilan : 5 jours de perdus et un abonnement à 30€ par mois pour envoyer des emails sans risque. Plus bien sûr une clé API en plus à gérer de manière sécurisée.

Die and Retry

A ce moment là, si vous avez un peu d'expérience, une question doit vous venir à l'esprit : que se passe t il si l'email avec le lien, ou n'importe quelle processus important pour le produit , échoue ?

On réessaie comme des bourrins jusqu'à ce que ca passe (non) ?

On laisse tomber (non) ?

Hop ! Et voilà comment vous vous retrouvez à mettre en place tout un système de gestion de tâches (jobs) avec gestion des erreurs, essais limités, monitoring…

La derniere fois que j'ai regardé, la gestion des emails non envoyés c'était 800 lignes de code, dans un projet qui en fait à peine 5000 (car la grosse difficulté, c'est de ne pas rater un email TOUT en évitant d'en envoyer en double ou pire. Je rigole pas, c'est vraiment compliqué)

Pertes et Plaintes

Le point précédent, la gestion des problèmes et exceptions, est assez fondamental. Dans tout projet, il faut se demander quoi faire en cas d'échec, encore plus quand on vend un produit à des gens, qui ont payé pour avec de l'argent donc, argent qu'ils et elles auraient pu utiliser pour manger donc vous avez intêret à avoir une bonne réponse.

Pour tous dev, il y a un délicat équilibre dans tous projet :

• réfléchir tres fort pour penser à tous les cas tordus et blinder votre code de validations et vérifications. Et envisager de faire des sprint qui durent 4 mois
• mettre des messages dans votre code qui à défaut d'éviter les problèmes vous donne assez d'infos pour les détecter et comprendre quand ils arrivent.

(note : si vous travaillez dans l'armée ou l'avionique typiquement, il existe un 3ème moyen plus intelligent : s'imposer certaines contraintes et langages de programmation qui permettent la vérification formelle du code, vu que vous pouvez pas vous permettre d'attendre un bug de votre avion pour découvrir les problèmes au fil de l'eau)

Imaginez qu'un utilisateurice vous envoie un email qui dit que son nom n'est pas correct sur la facture. Il va falloir comprendre pourquoi.

Pour ça, vous allez regarder tous les messages que vous avez pensé à mettre dans votre code. Mais comme il y 40 000 messages de debug par jour, il vous faut un outil.

Puis, comme certains problèmes sont tres importants, comme par exemple ne pas recevoir son email avec le lien de téléchargement, il va vous falloir mettre en place des outils de detection et alerte de problemes.

Encore du code à écrire, encore une infrastructure à organiser et maintenir.

En conclusion

Je n'ai abordé qu'une petite partie des problèmes rencontrés cette année. Je n'ai pas parlé de la gestion des pics de charges ou des droits d'accées, ainsi que de la vitesse d'affichage du site, l’accessibilité, la distribution des fichiers,…

Les personnes qui me lisent et travaillent dans le développement auront certainement reconnus la plupart des problèmes.

Le point principal était que quand il s'agit de faire un vrai produit destiné à être réellement utilisé, rien n'est jamais simple. Si vous devez évaluer le temps qu'il vous faudra pour sortir un projet, pensez toujours à multiplier votre évaluation par 3 ou 4. Car c'est ce qui va arriver : vous allez y passer 4 fois plus de temps que prévu, et en plus vous allez probablement devoir tout changer en cours de route parce que vous aurez pas prévu un truc.

deliver early fail fast

( ca veut dire : dépéchez vous de faire des trucs pas finis pour découvrir pourquoi c'était nul plutot que de passer 4 mois à réfléchir sans rien faire)