Cet été j'ai écrit une série d'articles qui racontaient mes aventures à monter une plateforme d'édition en ligne. Il y a un an, je m'étais fixé le but de mettre en place toute l'infrastructure technique et administrative pour expérimenter dans la vente de bd en ligne.

Alors que la 2ème année arrive, il est temps de faire un bilan sur ce qui a été et ce qui va être.

Ce qui est

Des béta test ont commencé à une url confidentielle pour l'instant ( vous pouvez la demander en écrivant à arnold@cepcam.fr). J'ai réussi à mettre en place un backend pour vendre et télécharger des pdf sans limite de taille et avec un coût raisonnable.

Les premiers test de charges ( automatisés ) ont effectué 5 achats et download par seconde pendant 1 heure ( 18 000 ventes donc, réparties selon une loi de Poisson pour bien simuler un usage réel ) et tout le monde a bien reçu son lien de download, les factures ont été bien émises et les download bien downloadé.

Evidemment, les permiers utilisateurs et utilisatrices réelles n'ont rencontré aucun problème technique vu qu'on est loin des 5 achats par secondes.

A coté de ça, tous les documents comptables sont bien générés, la TVA déclarée et payée correctement et les droits d'auteurs enregistrés. Bref, j'ai un vrai backend de maison d'édition, ce que va probablement devenir la société CEPCAM d'ici la fin du mois.

Le point important, et chouette, c'est que je parle de backend. J'y ai évidemment greffé un front ( site web) applicatif pour les premiers essais mais l'important est que je dispose de tout ce qui est nécessaire pour diffuser et vendre de la bd en ligne sous toute ses formes. On va donc pouvoir faire des expériences.

Le contenu

J'ai aussi commencé à parler largement du projet autour de moi aux autrices et auteurs que je connais, ou que je ne connais pas d'ailleurs. Un certain nombre d'entre elles et d'entre eux, soit par amitié soit par réel enthousiasme ( beaucoup ne croient pas à la réussite du projet mais beaucoup plus se sont montré‧es très enthousiastes donc pour l'instant on continue ) ont accepté de fournir du contenu ( QUE JE LEUR PAYE ) pour qu'on fasse des expériences. Il faut qu'ils trouvent le temps de faire ça dans leurs emplois du temps bien occupés mais à priori, même si je divise les promesses par 2, on a de quoi publier jusque mi-Mars.

So far so good.

Ce qui s'est passé

Petit retour d'expérience d'entrepreneur pour faire grimper ma notoriété sur LinkedIn : Comment s'est déroulée cette année ?

Tout d'abord, ca a été beaucoup plus long que prévu. En partie parce que j'ai travaillé sur d'autres projets important pour faire rentrer de l'argent pour acheter les droits d'auteurs mais surtout parce que :

1. La facture electronique. J'ai lancé une boutique en ligne pile poil l'année du passage à la facture électronique. J'ai codé 8 versions differentes du système de facturation le temps de comprendre ce qu'il fallait faire. Et évidemment, impossible de vendre quoi que ce soit tant que c'était pas prêt.
2. Mauvais partenaire. Pour démarrer j'ai pris un cabinet comptable "sur internet", pas cher et qui propose monts et merveilles. Le commercial m'avait évidemment promis qu'ils étaient spécialisés en droits d'auteur, ecommerce, etc. En pratique ils étaient aussi perdus que moi, incapables de répondre à la plupart de mes questions et ont résilié leur contrat avec moi pour je ne sais quel raison précise. Vraiment une expérience très négative et qui m'a fait perdre beaucoup de temps. J'ai maintenant un vrai cabinet comptable de gens experimentés et réellement spécialisés, plus cher sur le papier mais nettement moins cher en pratique au vu de leurs compétence. Comme dit ma dentiste "Il y a autant de comptables que de métiers, le mien il est spécialisé dans le dentaire." ( merci dentiste, j'aurais pas deviné).
3. Over Optimisation. Comme tout développeureuse de base j'ai commencé par résoudre des problèmes qui n'existaient pas encore. Ma première version gérait 5 moyens de paiement différents, signait les pdf pour protéger leur diffusion, déployait des pods kubernetes en cas de pic de charges, utilisait un système de CDN pour les downloads… Bref, de la tech pour la tech mais qui m'a pris 3 mois là ou 1 seul aurait suffit. Le systeme actuel est beaucoup plus simple à maintenir. Il pétera sans doute si je fais 50 000 ventes par jour mais je pense que a ce moment là j'aurais les moyens de résoudre les problèmes.

Interlude

Voilà où l'on en est. Les bases pour expérimenter sont posées. La partie difficile commence.

Ce qui va se passer

Je dispose d'un socle sur lequel on va pouvoir essayé différents modèles , appelons ça différentes offres produits, de manière itérative et rapide. Les modèles envisagés sont :

1. les ventes relais : on vend une seule bd a la fois avec une jauge de ventes à remplir qui débloque la prochaine bd. L'avantage majeur est que c'est simple techniquement et administrativement. Ce sera la première expérience à sortir, courant Septembre ( actuellement en beta test, écrivez moi un email pour participer )
2. Les blogs bd individuels. Le code que j'ai développé permet de mettre en place en moins de 1 heure une structure de blog bd avec une boutique intégrée. Ca peut interesser certain‧es auteurices dans une démarche individuelle ( qui peuvent m'ecrire )
3. La boutique éphémère évenementielle. 50 auteurs et autrices soigneusement choisies, une période limitée à un mois. C'est le modèle qui suscite le plus d'enthousiasme chez les auteurices et c'est le prochain sur lequel je vais bosser, dès Octobre, afin d'être prêt en Mars.
4. Le studio de BD. C'est mon projet long terme qui me fait réver le plus : publier un ( un seul ) feuilleton bd avec showrunner, cliffhanger, pool de scénariste etc… Mais c'est le plus couteux. Pour éviter de faire courir les risques sur les auteurices, il faut réunir au moins 50 000€ pour financer une série. Autant dire que c'est pas pour tout de suite.

Ce qui va être compliqué

Ok faisons donc une petite matrice des forces et faiblesses, ainsi que des risques et opportunites, pour aborder le problème majeur de mon projet.

• Force : enthousiasme certain des lecteurices et auteurices pour le projet en général. Il y a une envie existante de mettre en relation auteurices et lecteurices hors des plateformes et j'ai rencontré, hors du cercle de mes proches qui trouvent évidemment tous mon idée géniale, un enthousiasme manifeste. Attentes qui peuvent se coupler à mon expérience en matière de produit et projet pour espérer sortir un quelque chose qui réponde à un besoin existant.
• Faiblesses : je n'ai absolument aucune expérience en communication et marketing. Vous pouvez faire tous les produits du monde que vous voulez, si personne n'en entend parler, ça ne se vendra pas. Ca va être le problème principal à résoudre pour cette fin d'année 2026. Mais genre vraiment.
• Opportunités : il y a dégout général des réseaux sociaux et plateformes. Ca peut déboucher vers un retour à des sites de plus petites tailles et une volonté de payer des lecteurices, pour sorti des pièges du modèle gratuit ou…
• …absolument pas ! ( risque ). Tout le monde a pris l'habitude de ne rien payer sur internet et malgrès ce que promettent les plus enthousiastes, il n'y a peut être pas de modèle viable hors la pub et la gratuité. Ce serait triste mais au moins on serait fixé. Je rappelle que tous les projets précédents similaires au mien ( vendre de la bd en ligne ) ont échoués.

Clairement, la communication va être le plus gros problème. Au vu des chiffres de conversions du milieu, il faut réussir à atteindre au moins 100 000 personnes et pour l'instant je ne dispose d'aucun réseau qui permette ça. Je ne sais pas comment je vais résoudre ça mais au moins, je sais que je ne sais rien et c'est toujours un bon départ.

J'ai au moins 1 an devant moi pour expérimenter. Et au pire, si j'échoue, j'aurais appris pleins de chose en chemin ( et vous aussi j'espère parce que je compte bien tenir ce blog à jour)

A bientôt pour le premier lancement !

LES RESEAUX SOCIAUX N'EXISTENT PLUS.

WEB 2.0, 3.0 et n+1

Il y a eu bref moment où l'on mettait des numéros de version au web.

D'abord il y a eu juste le web puis le web 2.0 pour désigner, justement, les réseaux sociaux; vînt ensuite le web 3.0 qui a tellement dégouté tout le monde avec ses singes virtuels à 100 millions de dollars que l'on a arrété de numéroter. Et nous assistons probablement à la naissance d'un nouveau web avec l'arrivée de l'Intelligence Artificielle, un web où toutes les interfaces classiques s'effacent pour être remplacées par une seule et unique, pardon, Une Seule et Unique Interface, un chatbot capable de répondre à toutes les questions du monde.

Autant dire que nous sommes gentiment en train de préparer les catastrophes à venir mais ce n'est pas le propos du billet d'aujourd'hui.

Parlons plutôt de la phase dans laquelle nous somme actuellement, que l'on pourrait qualifier de Endless Feed, ou de Foutu Fil sans Fin si on veut tenter une petite allitération.

Reconnaissons qu'il y a eu une phase où les réseaux sociaux ont vraiment existé. Avant eux, le web était un ensemble de pages web, cataloguées et indexées grâce à des liens qui menaient de l'une à l'autre.

Puis sont apparus les blogs et surtout l'abonnement RSS. En plus d'avoir un format organisé dynamiquement et chronologiquement, les blogs ont popularisé 2 élèments importants du web pour la suite :

• le fil RSS et la notion d'abonnement
• les commentaires

Je vais insister sur ces 2 points. Avant le RSS, il n'était pas trivial de s'abonner à du contenu. Si vous découvriez un site web à propos d'un sujet qui vous interessait, il fallait revenir régulièrement vérifier s'il y avait des nouveautés. C'était un peu fastidieux et on avait tendance à oublier et abandonner les sites.

capture d'écran d'un logiciel de lecture de RSS

Avec le RSS, on pouvait s'abonner à un site, ou un blog, ou n'importe quoi qui publiait du contenu en respectant la norme rss : des photos par thèmes, une bd, de la poésie,… Et tout nos abonnements étaient centralisés dans un seul endroit, qui serait une app maintenant, qui permettait de voir le contenu que l'on suivait classé chronologiquement, filtré, etc.

Récapitulons donc ce qu'on pouvait faire à ce moment là du web ( en tant que consommateurice) :

1. s'abonner au contenu produit par quelqu'un pour être tenu‧e au courant des nouveautés
2. lui signaler qu'on aimait bien son contenu ou lancer des discussions sur des sujets hautement clivant avec des inconnu‧es sur le web en pourrissant la section commentaires
3. partager le contenu. Juste en envoyant un email avec le lien vers le site, ou en le rajoutant sur sa propre page web dans la section "liens" ou "blogroll".

Et en tant que créateur ou créatrice de contenu :

1. Publier votre contenu

Ok vous dîtes si ca vous rappelle un truc.

Facebook

Pour beaucoup d'entre nous, français, françaises, le 1er réseau social a sans doute été facebook. Certain‧es ont eu un myspace, peut etre même un compte friendster mais il est très probable que la majorité des gens aient commencé avec un compte Facebook.

Par rapport à un site web, l'immense avantage de Facebook, puis plus tard de Twitter et Instagram, et d'autres, a été qu'il n'y avait plus besoin de compétences techniques du tout. Vous vous inscriviez à Facebook et dans la foulée vous pouviez :

1. Mettre un petit mot ou une petite photo sur votre journée, ce qui vous avais enchanté, embété, étonnée,…
2. Vous abonner aux mises à jour de quelqu'un : votre cousin, votre collègue ou même Barack Obama
3. Signaler à quelqu'un qu'on aimait bien son contenu avec un Like ( bouton apparu environ 10 ans après la création du site)
4. Repartager AU SEIN DU RESEAU un contenu qui vous avait plu

Et une nouveauté qui n'existait pas vraiment avec le web sous formes de sites :

5. Vous voir proposer du nouveau contenu auxquelles vous abonner.

On conserve les fonctionnalités de l'ancien web ( s'abonner, réagir, partager) auxquelles on rajoute :

1. Simplicité
2. Decouverte

On pourrait dire que la découverte existait déjà avec le web précédent au travers des pages de "Liens". Mais je pense que la différence d'ampleur conduit à une différence de nature. Proposer une decouverte de contenu automatisé est totalement différent d'une découverte de contenu éditorialisée à la main.

Par la suite, d'autres réseaux sociaux apparurent, tous fermés et non intéropérables d'ailleurs, mais les principes et fonctionnalités restaient identiques :

• publier
• s'abonner
• réagir
• partager
• decouvrir

Et tout ça avec des compétences techniques nécessaires quasi nulles.

Afflux

Ne crachons pas dans la soupe : la facilité de créer un compte twitter ou facebook pour partager son contenu et discuter de sujets que l'on aime avec des gens aux goûts proches l'emportait facilement sur la perte de contrôle du contenu qu'on publiait. Celui ci était librement exploitable par les plateformes mais on s'en fichait un peu, vu qu'il n'avait à priori pas trop de valeur. On se créait des petits réseaux de communauté par affinité, de temps en temps on avait la chance de pouvoir discuter avec une personnalité qu'on appréciait dans le domaine et c'était bien.

Au milieu de tout ça, de temps en temps, on voyait du contenu ou des comptes que l'on ne connaissait pas mais qui était proches de nos goûts, on faisait des découvertes et c'était bien.

Et puis à un moment, la découverte à primée sur le suivi.

Il me faut du contenu. Plus de contenu.

Les gens qui vivent grâce au web vous le diront. La priorité c'est la régularité et la répétition incessante de votre existence en tant que créateurice dans le thread de vos abonné‧es. Et seulement une partie le verra de toute façon. Et seulement une partie de cette partie s'intéressera réellement à vous ou ce que vous faites. En conséquence de cette nécessité, le rythme des sollicitations ne fait que s'accélérer.

Constatons ce qu'est le web maintenant ( en majorité ) :

• une consommation en fil (c'est à dire avec un scroll de haut en bas, majoritairement sur smartphone)
• une disparition de l'agentivité pour laisser place à une consommation de ce que l'algorithme de découverte propose.

On ne va plus sur Instagram ou Tik tok, encore moi sur twitter, pour voir si son artiste préférée a fait un nouveau dessin, on y va comme on allume la télé, pour avoir un contenu à regarder pour se détendre (notez que j'ai absolument rien contre ça. Consommer du contenu divertissant passivement pour se changer les idées n'est ni nouveau, ni déshonorable). Chaque réalisation de chaque personne doit être fait pour être assimilé en quelques secondes, ou alors ça n'a pas sa place sur les réseaux sociaux

Présenté ainsi, est ce que Instagram ( pour le contenu créatif ), Twitter ( pour les "débats" politiques ) ou Tiktok ( pour la comédie ), sont encore des réseaux sociaux, où des communautés se tissent pour échanger sur un sujet, ou est ce que ce sont des chaînes de télévision, qui diffusent du contenu en continu pour y insérer de la pub ?

Evidemment, posée ainsi, la question est réthorique. Bien sûr que mon avis, qui est une énorme banalité parce que tout le monde le sait ou au moins le pressent, est que le web actuel consiste uniquement en une demi douzaine de plateformes qui diffusent du contenu destiné à être consommé. Exactement comme la télévision qu'on allume le soir pour se changer les idées, si on a plus de 50 ans.

Ce n'est plus les createurices individuelles qui comptent dans l'eco système actuelle mais la somme du million de micro créateurice, micro influenceureuse, qui à eux tous et elles toutes génèrent des heures de contenu non payés mais pourtant monétisés.

Cela plus rien à voir avec un réseau social.

Sur Instagram on dirait que j'ai bien hook. Vous avez vu ce titre passer dans votre fil et vous vous êtes dit "ok ça c'est un article que j'aimerais bien lire".

He bien allons y alors.

(il y a un TL;DR à la fin de la page pour celles et ceux qui ont la flemme)

Entreprendre

Je ne suis pas économiste, je ne vais pas prétendre être capable de savoir ce qui est "le mieux" comme système pour la société. Je constate par contre que depuis des années, une seule facette de l'entreprise est mise en avant : faire fructifier du capital. Beaucoup si possible.

Les entreprises qui se contentent de permettre à leurs associé‧es et salarié‧es de vivre correctement en vendant leur travail attireront sans doute beaucoup moins les regards.

Quel pourrait être le but d'une entreprise pourtant ? Et pour se concentrer sur un sujet beaucoup plus spécifique, quel pourrait être le but d'une structure d'édition à l'ére d'Internet ?

Un éditeur est une structure qui produit, promeut et distribue des oeuvres de l'esprit imprimées (ou leur équivalent numérique et audio). (des livres quoi, mais depuis que je dois payer la TVA je suis pointilleux sur la définition). Pour cela il faut un certain nombre de personnes, qui doivent manger et se loger , ainsi que quelques outils qui ont un coût. Si la structure en question permet ça, on peut considérer que l'entreprise a réussit.

Que les gens qui la dirigent ou ont fourni l'investissement initial s'enrichissent est totalement accessoire.

Production & Distribution

Avec Internet, les coûts de production et distribution se sont drastiquement effondrés. Plus besoin d'imprimer un livre physique (1€ à 2€ par livre) ni de l'envoyer en camion en travers le pays. Faire un site web pour distribuer un livre aupres de 100 000 personne, c'est moins de 10€ par mois de matériel, auxquels vous aurez rajouté environ 500€ par mois, ou 6000€ par an, pour payer un‧e dev qui s'occupera mettre en place et maintenir tout ça.

Mais on est du coup passé beaucoup trop vite sur le coût principal d'un livre : les personnes qui le font.

J'ai déja détaillé dans un précédent article le prix que je pense il faudrait payer une autrice ou un auteur de bd pour son travail.

L'un dans l'autre, toujours en prenant des chiffres à grosse maille pour alimenter la réflexion, j'avais estimé que il fallait à minima qu'un auteur recoive 3000€ par mois pour son travail.

On peut ramener ça à des unités standards de bd pour avoir un ordre de grandeur

Note : Dans un premier temps je considére uniquement le dessin, dans un style propre à internet, plutôt efficace et rapide. Cela ne s'appliquerait sans doute pas pour un travail plus abouti destiné à des impressions papier grand Format et il faut aussi rajouter le travail d'écriture / story board qui précède ces tâches

Essayons d'évaluer le coût de l'écriture en amont. Les gens à qui j'ai demandé un scénario de bd autour de moi évaluait le travail à environ 6000€. 1/6 du cout de la réalisation de la bd donc ( Ce qui veut dire aussi que dans mon hypothèse, un auteur de bd passerait environ 2 mois à reflechir sur un scenario qu'il mettrait ensuite 10 mois à réaliser. Grosso modo.)

Ramené à notre table dans laquelle on va rajouter 1/6 partout, ça donne :

Evidemment, ça fait mal de ramener un acte créatif à une question de coût aussi triviale et bassement terre à terre. De plus, ces chiffres peuvent grandement varier d'une autrice à l'autre.

Mais à force de porter l'art aux nues en lui prétant des vertues supérieures à celle du simple divertissement, on a occulté un point important : quand vous lisez un épisode de bd sur internet, il faudra que l'auteurice qui l'a réalisé touche AU MOINS 875€ pour continuer.

L'outil de production

Il faut rajouter à ceci les coûts des outils et fonctions supports, qui sont encore nécessaires même dans le cadre d'internet ( realisation du site web, communication et animation des réseaux sociaux ). Fonctions supports qui n'ont pas vocation à s'enrichir et outils qui n'ont pas pour but de produire de l'argent.

Pourquoi les fonctions supports ? Parce que même si une autrice très punk et très douée pourrait s'occuper elle même de son site web et de sa comm sur les réseau sociaux, ce n'est pas du travail de dessin et ça a un coût; environ 2 vingtieme du reste ( 2 jour par mois, ~1h par jour, 2 salarié‧e à temps plein par mois pour 20 personnes), plus des dépenses d'outils informatiques.

Dans un précédent article, toujours le même, j'estimai les dépenses à environ 10 000€ par mois pour distribuer le travail d'une vingtaines de personnes, soit 500€ par personne, et donc, si on reprend nos 3000€ par mois, un nouveau sizième à rajouter.

Je vais de nouveau répéter les avertissements, nécessaires, il s'agit d'évaluations très rudimentaires dont le but principal est dire aux lecteurs et lectrices : quand vous avez lu un épisode de bd sur internet, il faut que 1000€ ait été payé au minimum au total pour en assurer la pérennité

Si vous êtes 12000 à lire une bd il faut que chacun paye 1€ un €uro chaque trimestre pour que l'aventure continue.

Je le remet en gras et en majuscules.

POUR QU'UN‧E ARTISTE LU‧E PAR 12000 PERSONNES SUR INTERNET PUBLIE UNE BD REGULIEREMENT IL SUFFIRAIT QUE CHAQUE LECTEUR, CHAQUE LECTRICE PAYE 1€ PAR TRIMESTRE

Soit je me suis trompé dans mes calculs, soit le système actuel, où l'on a renoncé à payer pour à la place être noyé sous la pub et la contenu médiocre, est ridicule.

Certes mais depuis les début de la presse ça à toujours fonctionné comme ça.

Hélas, il est vrai que depuis le début, le but des média n'est pas de vendre ce qu'ils produisent mais bien le temps d'attention des gens qui les consomment.

La presse survit principalement grâce aux subventions et aux annonceurs, la télévision est soit payée par le service publique soit par la publicité.

Ou du moins c'est ce que les gens cyniques aiment a me dire. Et j'aime pas trop les cyniques parce que c'est juste une bonne manière de dire qu'on va faire aucun effort pour corriger une mauvaise situation.

Mutualisation

Cependant, il y a un probleme que l'on ne peut pas nier : si certains auteurs ou certaines autrices pourraient prétendre trouver 12000 personnes prêtes à payer 4€ par an pour les aider à continuer, et même plus, cela ne va largement pas être le cas pour la majorité des artistes.

C'est là où l'éditeur trouve une partie de son interêt : la mutualisation du risque.

Top 3

Le raisonnement ci dessus nous a amené à dire, bien naïvement, que "pour un‧e artiste qui a 12000 lecteurices, il suffirait que chacun donne 1€ par trimestre pour qu'il puisse publier une web serie sur Internet". Et le raisonnement serait le même pour 20 artistes (taille de la structure pour laquelle on mutualise les MOYENS DE PRODUCTIONS).

Mais on sait très bien que tous les projets ne fonctionnent pas pareil et qu'en pratique, le nombre de lecteurices pour chaque auteurice, si on les classe par ordre de nombre de lecteurs, ressemblera à ça :

• la personne avec le plus de lecteurices en a 12000
• la 2ème en a 10000
• la 3eme en a 8500 [...]
• la 20ème à 500 lecteurices

Pour illustrer mon idée, j'ai fait l'hypothèse que chaque rang a 15% de lecteurices de moins que le précédent ( et j'ai arrondi les chiffres). Ca donne des chiffres comme ça environ (note : j'ai pris ces valeurs pour que la 20ème personne ait environ 500 lecteurices et la 1ère 12000 ):

Et dans ce cas, la somme des lecteurices ( qu'ils se recoupent ou pas entre auteurices, ca ne change rien à notre raisonnement pour l'instant ) est d'environ 77 000 et la moyenne par auteur de 3900.

C'est donc en dessous de ce qu'il faudrait pour faire vivre nos 20 (+2 ) personnes.

Si vous avez encore quelques notions de math, vous aurez reconnu une suite géométrique ( de raison q=0,85) et déduit que la moyenne de lecteurice par autrice dans mon cas, sous forme de formule excel, est

m = max(auteurs)*(1-POW(0,85;20+1))/(1-0,85)

D'où l'ont peut déduire si on a envie que pour que chaque auteur ait en moyenne 12 000 lecteurices motivées il faut que le premier en ait environ 3,1 fois plus que la moyenne, soit 37000 a peu pres. Puis 31600 pour la deuxième, 27000 pour la 3ème etc. Et 1700 pour le dernier, soit environ 22 fois moins.

Dans les hypotheses que j'ai posé, le projet qui convainc le moins de personne en convainc 22 fois mois que le projet qui en convainc le plus et 5 auteurices représentent 50% du revenu.

( note en passant : mes ordres de grandeurs ne sont pas du tout loin de ce qu'on pourrait observer. Sur une vingtaine de projets, ce qui ont le plus de ventes en feront environ 12 000 et ceux qui en font le moins environ 500, soit un ratio de 24)

Même si j'adorerais que ce ne soit pas un sujet, on ne peut malheureusement pas écarter ce problème : dans une structure qui se voudrait collaborative, comment distribuer de manière juste les revenus entre les gens quand une personne en génère 20 fois plus que les autres ?

Manger et vivre

Repartons de nos principes et chiffre précedents. 1/6eme des revenus de chaque auteur sert à la structure commune ( serveurs, salarié‧es supports, …).

Chaque auteur récupère donc 5/6 ( 83% ) de ce qu'il génère en revenu ( désolé pour les gros mots mais encore une fois, on ne vit pas de reconnaissance );

On est parti du principe que chaque lecteurice est pret‧e à payer 1€ par trimestre, 4€ par an (ou que 1/12ème des gens payent 4€ par mois, peu importe pour l'instant).

On a dit que pour que chacun ait en moyenne 12000 lecteurs (par an), le premier doit en avoir 37000 ( par an. 3000 par mois). Multiplié par notre 1€ par trimestre ca fait environ 148000€ par an pour le premier, ou encore 9900€ par mois une fois l'ursaff payé. C'est beaucoup.

Quand au projet avec le moins de succées, il recupère 6800€ par an. Pas du tout de quoi vivre

Evidemment, chacun et chacune pourrait donner tout le surplus au dela des 3000€ nécessaires, mais même si ca parait équitable, ca ne sera probablement pas juste.

Une solution, celle que j'envisage, est de prélever une contribution sur tout ce qui est au dessus des 3000€ minimum estimée comme nécessaire pour vivre décemment de son travail puis de redistribuer entre tout le monde. Prenons un taux de 40% par exemple :

Le 1er projet a généré environ 12500€ par mois, le deuxième environ 10500. LE vingtieme n'a "généré" que 600€

On retire les 3000€ de base de vie pour le premier et le deuxième, ainsi que tous les projets qui génèrent plus de 3000€. J'ai fait le calcul ca fait un total de 36000€ de surplus tous les mois ( principalement portés par les 5 premiers projets). On applique les 40% de redistribution pour arriver à environ 15000€ redistribué entre 20 auteurices, soit 750€.

Le 1er projet a généré 12400€. En pratique il recupère :

3000 + (12400-3000) * (1- 0,4) + 750 = 3000 + 5640 + 750 = 9390€

quand au projet le plus risqué, alors qu'il n'aurait du récupérer que 565€, il récupère environ 1300€ après répartition. Pas la panacée mais un moyen d'absorber quelques risques et échecs.

Je vous met le tableau précis, avec un seuil de base de 3000€ et un redistribution de 40%, avec une colonne qui montre le taux effectif.

Lire : "pour le projet ayant le plus de lecteurices, 12400€ générés deviennent 9370€ après redistribution"

Justice et équité

Evidemment, c'est injuste. Alors qu'il rencontre un succées incroyable, le projet le plus lu (en imaginant une répartition équitable des lecteurices prêtes à payer entre auteurice) reverse 25% de ses sous à tous les autres projets qui ont eu moins de succés que lui, sans doute PARCE QU'ILS TRAVAILLENT PAS ASSEZ ET SONT NULS. Mais :

1. Ca laisse encore 6370€ au dessus des 3000€ nécessaires pour vivre mieux que la moitié de la population française. 3 fois le salaire médian.
2. Il est risqué de se contenter de projets qui ne rencontrent que des francs succées. Si personne n'ose prendre de risques de peur de ne pas manger cette année, ce qui conduit à la mort, on finit avec des projets formatés.
3. Comme être en bonne santé, avoir du succées à un moment de sa vie n'est que temporaire pour la pluspart d'entre nous. Mettre en place un système qui lisse ça est bien pour tout le monde.
4. C'est quand meme meilleur ambiance quand votre entourage ne risque pas de mourir de faim chaque mois.

Faites moi confiance pour le 4.

Un mot sur les chiffres, qui fera office de tl;dr en conclusion

Cette page est pleine de chiffres, qui semblent sorties de nulle part en plus. J'aurais pu faire une analyse plus rigoureuse avec des formules analytiques précises mais ca aurait été très pénible à lire.

Ce que j'aimerais retenir ce sont les 2 points suivants :

• Les sommes qu'il faudrait voir les lecteurs et lectrices payer par mois pour faire vivre leurs artistes sont basses. On parle de 20000 personnes qui accepterait de payer 4€ par mois pour faire vivre un collectif de 20 auteurices. Ou 5000 pour 5 auteurices. Oui, 1000 personnes par auteurice quoi. Et oui, je sais, jamais aucun de ces projets n'a fonctionné pourtant. Je ne sais pas pourquoi.
• Comme certains projets rencontrent plus de succes que d'autres, il faut envisager une redistribution au dela d'un certain seuil pour préserver la prise de risque. Le pourcentage de cette redistribution est assez élevé, de l'ordre de 40% mais il se fait uniquement sur les sommes qui dépassent le "minimum par mois."

Mes chiffres sont tous discutables. Ce qui m'importait c'était de soulever les questions pour ce genre de projet. Les réponses viendront en expérimentant

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)

Mais viable pour qui au fait ?

Le partage de la valeur ajoutée

Le but d'un éditeur ou d'une plateforme de publication en ligne est très rarement de garantir la survie de celles et ceux qui sont édité‧es. Si vous êtes une maison d'édition, vos auteurs et autrices sont une source de coût et en bon gestionnaire, le but est de maintenir les coûts le plus bas possible.

Le but d'un artiste est à priori de gagner suffisamment sa vie pour vivre au quotidien ( manger, dormir, se soigner). En second peuvent venir un besoin de reconnaissance puis de notoriété mais disons que il faut à minimum vivre décemment avant de se préoccuper de passer au journal de 20h00. Si elles et ils le pouvaient, sans doute que les artistes se passeraient bien d'éditeur. Mais l'éditeur remplit une fonction bien utile pour les artistes : produire et distribuer leur travail. Ce qui a aussi un coût.

Au lieu de partir du schéma actuel :

"Je suis une maison d'édition ( ou une plateforme ) il faut que je produise des BD au coût le plus bas possible pour être rentable"

partons de :

"Je suis un‧e auteurice de bd, il faut que je vende suffisamment de livre pour m'acheter à manger".

Et remontons la chaîne.

La 1ère question est "de combien devrait disposer toute personne pour vivre correctement en France ?". Pas "combien mérite-t-on de gagner ?" mais "Si je consacre mon temps à travailler, combien me faut il pour manger et dormir correctement ?".

Ce n'est pas une question facile. On pourrait faire un budget de base loyer + nourriture + energie + etc. Il faudrait aussi prendre en compte les disparités selon le lieu de vie, ainsi que pleins d'autres facteurs. Pour entamer la réflexion, j'ai chois de prendre comme référence le salaire médian dans la fonction publique en 2025, que j'arrondirais à 2500€ net parce que c'est un joli chiffre.

( Rappelons que le salaire médian d'un pays est le salaire tel que la moitié des habitants qui travaillent gagne moins et l'autre moitié gagne plus ) Pourquoi le salaire médian ? Parce que je me dis que si vous disposez d'un revenu supérieur à celui de la moitié des gens de votre pays alors les conditions de vie pour vous dans ce pays doivent être suffisamment correctes (C'est évidemment sujet à discussion).

Si un artiste travaille sur une bd et que vous vendez cette bd, on va donc partir du principe qu'il faut qu'il dispose d'au moins 2500€ net à la fin du mois. Si vous publiez un feuilleton hebdomadaire, chaque épisode devrait donc rapporter 2500 / 4 = 635€ à l'artiste.

Si c'est une bd qui a pris 1 an à réaliser, ça devrait rapporter 12x2500 = 30 000€.

Notez bien que j'ai pas dit 'combien devrait gagner un artiste qui vend 500 bd et un autre qui en vend 50 000 ?'. Je pars du principe que à partir du moment où on travaille, on doit vivre décemment, ce qui est malheureusement loin d'être le cas pour les artistes actuellement.

Combien ça coûte de produire une bd ?

J'ai déjà écrit un article sur combien ça coûte de vendre en ligne. Demandons nous maintenant combien ça coûte pour que la bd arrive en ligne.

Cotisations sociales

On a fixé les besoins pour la production d'une bd mensuelle ( désolé de le dire comme ça ). Il faut que l'autrice, ou l'auteur, à l'origine de la bd récupère 2500€ net (net avant impôt pour celles et ceux qui veulent aller dans le détail ).

Avant cela il va falloir que l'éditeur ou la plateforme qui l'édite payent sa protection sociale. Si on considère que les auteurices sont payé‧es en droits d'auteurs, et même si il y a pleins d'autres manières, d'après le simulateur de l'ursaff cela veut dire que l'éditeur / la plateforme doit débourser environ 3000€ par mois / 750€ par semaine / 36000€ par an.

Pour l'instant, un épisode hebdomadaire de bd ça coûte 750€ par semaine.

Distribution et production

Rappelons qu'on parle ici de BD numérique qui est distribuée par Internet ( site web, réseaux sociaux, email, etc…). Beaucoup d'auteurs d'autrices s'occupent eux même de faire leur blog, leurs newsletter, leur Patreon,… Mais cela ne devrait pas être le cas. C'est du travail d'éditeur pour une raison importante sur laquelle je reviendrais plus tard.

Pour distribuer et vendre de la bd sur Internet, si on veut s'affranchir des réseaux sociaux, j'estime qu'il y a 4 sources de coûts (c'est ne pas qu'une estimation, c'est ce qui ressort des recherches que j'ai fait cette année)

1. Le serveur internet, le fournisseur d'email, les outils logiciel divers comme le ?#*?$$#!! de logiciel de facture compatible facture électronique. 200€ par mois
2. Le comptable, le service juridique, l'assurance, la banque,… Toute activité professionelle impose un certain nombre de démarches et obligations. Et croyez moi, ça chiffre vite. 500€ par mois.
3. Une personne pour la technique ( une développeuse ou un développeur quoi_). Comme c'est moi qui m'y colle, on va heureusement pouvoir ne pas se préoccuper des lois du marché et considérer qu'il ou elle devrait être payé‧e le même salaire net que celles et ceux pour qui iel travaille, soit 2500€ net. Par contre, les cotisation salariales sont beaucoup plus élevées. Des salarié‧es ça coûte donc 4300€ par mois par salarié‧e.
4. Bien qu'on puisse croire que les auteurices pourraient s'en occuper à l'ère d'internet, ce n'est pas leur métier et certain‧es n'aiment pas ça du tout : la communication. Il faut quelqu'un pour gérer les alertes et notifications sur tous les réseaux sociaux, voir même publier les bd sur le site, car après tout c'est pas le boulot d'un auteur de faire des billets de blog. Toujours selon la même idée, c'est 4300€ de plus ( 1 personne dédiée à ça).

Bref, total pour faire marcher un mini éditeur numérique en ligne qui vend des bd :

Pour l'auteurice : 3000€
Outils et infrastructure : 200€
Services et administratif : 500€
Autres salarié‧es‧: 8600€ ( ouch !)
TOTAL: 12300€

Mais on parle d'une structure d'édition, qui peut donc en théorie éditer plusieurs personne d'un coup sans que les coûts fixes ne changent. C'EST TOUT L’INTÉRÊT D'UNE MAISON D’ÉDITION.

D'expérience, la structure que je présente ci dessus serait en mesure de gérer 20 auteurices par mois ( ça fait à peu près un jour de dev et un jour de comm par artistes, ca parait tout à fait raisonnable). On va prendre un serveur plus gros (500€) pour gérer l'afflux, le comptable va demander un peu plus ( 1000€ ) et on va donc multiplier les sous des auteurs par 20 pour ce cas :

Pour les auteurices : 20*3000 = 60 000€
Outils et infrastructures: 500€
Services: 1000€
Autres salarié‧es‧: 8500€ ( j'ai arrondi pour faire un chiffre rond )
TOTAL FRAIS FIXES : 10000€
TOTAL DES DÉPENSES POUR 20 AUTEURICES : 70 000€

J'estime donc que pour faire fonctionner une structure qui permettrait la vente des bd de 20 auteurices, il faudrait générer 70 000€ de revenus par mois. C'est beaucoup.

Combien ça ferait en terme de ventes ?

Le prix d'une BD

Il y a énormément d'hypothèse à faire sur le type de "produits" à vendre et le prix que les gens seraient prêt à payer. Je vais simplifier à outrance poru les besoins de la réflexion. On va dire que chaque auteurice vend tous les mois un PDF à 4€ Hors Taxe ( 4€80 prix de vente, un prix généralement accepté).

Note: j'ai eu le comptable au téléphone pendant la rédaction de billet et il s'avère que un pdf de BD c'est aussi 5,5% de TVA. On peut donc vendre nos BD 4€10 et toujours toucher un tout petit peu plus que 4€

Cela pourrait être un autre modèle : un abonnement mensuel, une ou 2 grosses ventes par an… J'ai aussi réfléchi à ça et ça fera même l'objet d'un billet dédié.

Pour l'instant, on va se contenter de dire que les auteurices vendent leur bd sous forme de pdf une fois par mois, pour 4€ une fois la TVA payée.

De ces 4€, il faut retirer la commission du fournisseur de carte bleue. Je vais prendre 2,5% car c'est ce que j'ai réussi à construire actuellement.

4 - (4x2,5%) = 3€90

Une vente rapporte environ 3€90 à la structure. On a plus qu'à mettre ça dans nos chiffre précédents pour voir combien de ventes il faut faire

Pour un seul auteurice

12300 / 3,9 ~= 3 200 ventes

Pour 20 auteurices

70 000 / 3,9 ~= 18 000 ventes par mois
18 000 / 20 = 900 ventes par mois par auteurice

Pour qu'une seule autrice ou un seul auteur puisse avoir une structure qui l'accompagne, il faut avoir environ 3200 ventes par mois à 4€ (C'est beaucoup mais cela ne semble pas impossible). Avec un système d'abonnement, ce serait les même chiffres : environ 3000 abonnées par mois pour faire vivre un‧e auteurice et la structure, environ 20 000 abonnées pour en faire vivre 20 Attendez, je vais remettre les chiffres dans un gros encadré parce que c'est sans doute ce qui intéresse les gens.

Pour faire vivre une structure capable de distribuer les bd de 20 auteurices, il faut 20 000 abonné‧es ou 20 000 ventes par mois

La vente annuelle

Puisqu'on dispose de tous les chiffres, voyons rapidement un autre modèle qui consisterait plutôt en des ventes annuelles, soit au travers d'un événement comme le shortbox comics fair, soit toujours au travers d'une boutique mais en imaginant que ce sont les bd finies qui sont vendues et qu'il faille 1 an pour faire une bd ( hypothèse très hasardeuse ).

Ce n'est pas compliqué il suffit de tout multiplier par 12 donc

Pour qu'une structure de bd numérique soit rentable pour faire vivre 20 auteurices il faudrait qu'elle fasse 18000x12 = 216 000 ventes par an. Ou 10800 ventes par auteur par an.

Est ce que 10800 ventes, disons 10 000, par livre par auteur est raisonnable ? Non. C'est loin des chiffres de ventes constatés habituellement.

(Rule of Thumb : la majorité des auteurs et auteurices font 500 ventes par livre. 3000 est considéré comme un succés. Les auteurs, autrices que perçus comme des gros vendeurs font 20 000 ventes par ouvrage Le modèle du "un livre par an par auteur" parait donc difficilement viable._)

1000. C'est le nombres de ventes par mois par auteurices qu'il faut faire.

Bizarrement, même si ce sont les mêmes chiffres au final, il parait plus accessible de faire 900 ventes par mois par auteurice que 10 800 ventes par ouvrage annuel.

Tous ces calculs font plusieurs approximations. mais ils valent cependant pour 2 choses :

• l'exercice mentale
• les ordres de grandeurs, qui sont a peu près correctes.

Ainsi, pour mettre une dernière couche de simplification, on va retenir que pour qu'une structure de distribution numérique de plusieurs auteurices soit viable, chaque auteurice doit faire en moyenne 1000 ventes à 4€ par mois

Voyons ce que ça donne 10 auteurices ?

10 auteurices = 10 000 ventes
10 000 ventes = 39 000€ après la commission bancaire
37 500€ après les frais de fonctionnement ( infrastructure, comptables, banque, assurances, légiste,…)
29 000€ après avoir payé la développeuse et le chargé de communication
2900€ brut par auteurice
2435€ net par auteurice après paiement de l'ursaff (*2170€ net si vous décidez de surcotiser* )

20 auteurices ?

(sortons la formule)

84% *(((20 * 1000 * 4) - (500 + 1000 + 8500)) / 20) = 2940€ net

(oui, c'est plus car on mutualise les coûts)

Je vous met meme le tableau, sous l'hypothèse de 1000 ventes par mois par auteurice donc (ou 1000 abonnements par mois, ou 250 ventes par semaines)

(notez que pour 50 personnes on est passé à 3 salarié‧es, 4 salarié‧es pour 100 personnes)

Justice

Ok super les communistes tout le monde gagne pareil. Mais qu'est ce que je dis à mon autrice qui fait 5000 ventes par mois ? Et celle qui a pris des risques avec son projet et n'a fait que 5 ventes ce mois ci ?

On aimerait que les ventes par "rang d'auteur" soient uniformes :

lire : l'auteurice qui est numéro 1 au classement des ventes à fait 1000 ventes. Celle ou celui qui est numéro 2 à fait 1000 ventes. Le numéro 3 aussi etc…

Mais en pratique le nombre de ventes par auteurices va sans doute ressembler à ça :

Lire : la plus grosse vendeuse à fait 6700 ventes. Le 2ème plus gros vendeur 4500 ventes…Le 20ème plus gros vendeur à fait 3 ventes.

En matière de ventes, ou de succées par des individus, on retrouve toujours la même distribution. (une loi exponentielle), avec juste une pente qui descend plus ou moins vite ( ici j'ai pris une valeur de paramètre lambda = 0.4).

La personne qui vend le plus vend, par exemple, 6000 livres. La suivante en vend 4000, la 3ème 3000, etc…jusqu'à arriver à des chiffres de ventes largement inférieurs à ce qui serait nécessaire pour vivre.

J'ai volontairement construit un tableau de ventes, fictifs de manière à ce que la moyenne fasse environ 1000 ventes ( et donc la somme de nos 20 auteurs 20 000 ventes soit de quoi faire vivre notre petite structure)

Cela donne à peu près les chiffres suivants :

Total des ventes : 21210
Ventes moyennes par auteurice : 1060 ventes par moi

Ces ordres de grandeurs, d'après ce que j'ai pu en observer et discuter avec des auteurices, sont tout à fait plausibles sur internet ( pas pour des ventes classiques en librairie, dont les ordres de grandeurs sont plutôt ce que j'évoquais plus haut ).

Les plus gros succées font environ 5000 à 6000 ventes, la majorité font entre 100 et 500 ventes et certains projets ne font qu'une petite dizaines de ventes.

Mais c'est l'avantage d'une structure d'édition ou d'une structure de coopération ! Les projets qui ne rencontrent pas un succés commercial font quand même vivre leurs auteurices grâce à celles et ceux qui ont eu plus de chance, permettant ainsi aux artistes de se sentir à l'aise pour explorer et prendre des risques.

Cependant, on ne peut pas se contenter de forcer l'égalité pour tout le monde. On peut le regretter mais dire à la personne qui fait 6000 ventes qu'elle va toucher autant que celles qui en fait 3 est un bon moyen de voir votre structure exploser ou vos meilleurs vendeureuses partir vers des cieux plus clément pour eux et leur famille.

Voyons comment évaluer une juste redistribution et éventuellement corriger les inégalités.

Hé ho ca va bien les gauchos là si Astérix il en vend 60 millions c'est normal qu'il soit millionnaire.

Non.

1. On peut tous et toutes réussir un jour et échouer ensuite. Vivre au sein d'une organisation qui garantit que les succées d'un jour permet les échecs d'un autre est rassurant
2. En matière créative, scientifique et artistique, je ne pense pas que le succées commercial soient un marqueur pertinent pour mesurer ce qu'on apporte à la société. J'ai lu des BD indépendantes originales et pleines d'idées, j'aimerais qu'elles puissent continuer à exister même si il s'en vend 50 par an.
3. Quoi qu'il en soit, aucun projet de société commun ne justifie des différences de revenus énormes. Qu'un succées commercial vous permette de partir en vacance en famille dans un chouette camping, c'est cool. Par contre, que vous y allez en jet privé pendant que votre entourage se nourrit de pâtes, bof.

Bref, tachons de mesurer un peu objectivement ces inégalités.

Enter the Gini.

Ne réinventons pas la roue chaude, il existe un indicateur pour mesurer les inégalités dans une distribution de revenu, qui s'appelle coefficient de Gini.

C'est compliqué à comprendre mais c'est un bon indicateur rapide d'inégalité. Retenons que il vaut entre 0 et 1, que 0 est la société parfaitement égalitaire ou tout le monde gagne pareil et 1 une société avec une seule personne qui gagnerait tout l'argent.

Dans notre cas il vaut 0,75. Pas ouf.

Rappelons le revenu par auteur dans notre situation

Pour 20 auteurs, on fait 78 000€ de CA ( une fois les comissions bancaire enlevées). De ces 78 000€ il faut soustraire environ 10 000€ de frais de fonctionnement puis les cotisations sociales, qu'on va arrondir à 16%

Dans le système que je présente, au final, un auteur recoit environ 85% de ce qu'il a vendu (super grosse estimation mais le chiffre de 15% fonctionne pas mal d'une manière générale). Si on prend nos chiffre cela fait :

Pour le plus gros vendeur

6700 ventes * 4€ * 85% = 22780€

Pour la 8ème, qui a vendu 400 exemplaires

400 ventes * 4€ * 85% = 680€

et 10€ pour l'artiste qui aura vendu 3 exemplaires ce mois ci.

Clairement, avoir au sein de la même société quelqu'un qui touche 22 780€ par mois et un autre 10€ c'est pas génial. Il va falloir trouver un moyen de corriger ça.

Conclusions temporaires.

Jusque présent, j'ai argumenté qu'il était possible d'envisager une structure d'édition numérique capable de distribuer le travail d'une vingtaine d'autrice et auteurs et de leur procurer un revenu décent si ils et elles font chacun 1000 ventes à 4€ par mois.

Les choses étant ce qu'elles sont, on sait cependant que en pratique 3 projets, ou 3 autrices ou auteurs, vont représenter plus de la moitié des ventes. Si l'on veut conserver la prise de risque et l'égalité au sein de la structure, il faut donc un mécanisme redistributif.

C'est un sujet compliqué, qui mérite une réflexion plus poussée et un prochain article à part entière.

J'avoue être très frustré de l'échec de la bd en ligne ( appelez ça comme vous voulez, blog bd, turbomedia, webcomics ou webtoon ) . Alors que c'était une formidable opportunité de distribuer de la bd sans passer par la fabrication et la distribution d'un objet livre coûteux, les éditeurs semblent avoir très mal investit le domaine et seul 2 modèles ,frustrant, ont émergés :

• la prépublication gratuite sur internet en vue d'une vente de livres physiques, travail entièrement assumé par les auteurs et autrices et que les éditeurs se sont appropriés sans que la question de la réévaluation des bénéfices dédiés aux auteurices, qui assument maintenant, le travail de communication et marketing, n'ait été posée correctement.
• les grosses plateformes, comme webtoon par exemple, où chaque oeuvre, parfois cédée gratuitement en échange de la visibilité, vient alimenter une énorme masse de contenus vendue comme un argument de vente, sans que les œuvres ne bénéficient de mise en avant individualisée ( sauf dans certains cas comme ono par exemple qui semble apparemment rémunérer correctement ses artistes et les mettre en valeur ).

J'aimerais donc qu'un autre modèle émerge.

Cela soulève énormément de question et je sais que de nombreux autres avant moi ont échoué mais quoi qu'il se passe, je suis au moins certain que à l'issue de cette expérience j'aurais appris pleins de choses dans un domaine qui m'intéresse.

Je compte dorénavant partager toutes ces questions, qu'elles soient techniques, éthiques ou administratives, et les réponses que j'ai pu y trouver sur ce blog, question par question, à commencer par la 1ère qui s'est posée : combien ça coûte de vendre en ligne ?

Build or Buy

Il y a une expression qui revient souvent dans le monde du développement, sous forme de termes anglais, c'est "Build or buy" ( littéralement "Construire ou Acheter" ).

Cette question, elle arrive quand vous avez besoin d'un service, ou d'une fonctionnalité, que vous êtes capable de coder vous même mais qu'une autre société existante propose déjà pour un certain prix. Les développeurs et développeuses ont une vilaine tendance à vouloir tout coder soi même, pour le plaisir d'apprendre. Mais avec l'expérience, on apprend le coût réel d'une fonctionnalité codée soi même :

1. le coût initial : si vous passez 5 jours à coder quelque chose, ça vous coûte environ 1800€ ( sur la base des prix du marché des dev et à raison de 218 jours travaillés par an )
2. La maintenance. Tout le monde oublie ça mais du code que vous avez écrit c'est du code dont il va falloir s'occuper quand ça pète. Alors que si vous utilisez les services d'une société externe, c'est son problème et ça n'engendre à priori pas de surcoûts ( et de stress).

Pour mon projet, je sais qu'il me faut a minima :

1. une vitrine pour montrer les "produits" à vendre ( un site web quoi )
2. un moyen d'encaisser des paiements
3. une infrastructure pour héberger et télécharger des fichiers (ça a un coût non négligeable )

Je me sais capable, en tant que développeur, de coder tout ça moi même mais je sais AUSSI qu'il existe déjà de nombreuses plateformes et outils qui permettent cela, pour des coûts…eeerrr…disons… dur à déchiffrer.

La Jungle des coûts

Reprenons de manière très simplifié la fonctionnalité principale ( sur le ton d'un user story comme on dit dans le monde du dev ) :

Je veux que les gens puissent acheter le pdf de ma bd en ligne pour environ 5€

Les prix d'un service qui permettrait de faire ça se décompose grosso-modo entre les 3 points exposés plus haut : site web boutique, paiement et hébergement des fichiers.

Pour disposer de ces services, il est possible de combiner plusieurs plateformes existantes ou d'en prendre une seule qui fait ( presque ) tout. Commençons par le plus simple : une plateforme qui fait tout.

Zero dev

Je paye, je met mon contenu en ligne j'ai une boutique qui permet d'acheter mes pdf. Dans ce domaine on trouvera par exemple square space, gumroad, big Cartel, itch.io ( et oui ! ) ou Ko-fi.

Décomposons les coûts pour mieux comprendre ( petite précision cependant. Etant donné la complexité des offres, je ne prétend pas que les chiffres soient exacts. Il y a plein de coûts cachés et aucune offre n'est identique. L'exercice vaut plutôt pour réflexion )

Gumroad

Gumroad à l'air le plus trivial en apparence : sur chaque vente que vous faites, la plateforme prélève 50c environ + 10%.

MAIS

En cherchant bien on touve cette page, gumroad fees, qui précise qu'il faut rajouter les frais de carte bleue de environ 30c + 3% par transaction.

Voyons ce que ca fait sur une bd à 5€ ( on va pas s'encombrer avec la TVA, je n'ai pas trouvé s'ils prélevaient leur commission sur les prix HT ou TTC)

Commission sur une vente à 5€

= 0.5€ + 5*10% + 0.30€ + 5*3% =1,45€

J'ai oublié de le préciser plus haut, c'est l'occasion de le faire,mais disons au doigt mouillé que pour que mon idée soit viable ( pour moi et les artistes ), il faut qu'on fasse au moins 4000 ventes par mois ( à 5€ = 20 000€ par mois, ça permet de faire de la bd et payer le site. Même si c'est discutable ).

4000 ventes par mois sur chacune de laquelle est prélevé 1,45€ => 5800€ par mois. Ou environ 70 000€ par an. De quoi se faire soi même une belle boutique et payer quelqu'un pour la maintenance.

Alors évidemment, si vous êtes un/e auteurice qui fait quelques ventes par mois, disons 100 ventes, il va sans dire que ce que ca vous coûte ( 1740€ par an ) est sans comparaison à ce que vous couterez un/e dev si vous vouliez votre propre boutique. Mais dans mon cas, où le but est d'avoir une plateforme qui génère suffisamment de ventes, la solution gumroad n'est pas envisageable.

Passons à squarespace

Square Space

Je dois dire que Square space est assez génial. Pour les gens non technique ca permet de faire tout un tas de chose, du simple site web à la boutique de vente en ligne, de produits physiques ou numériques. L'inconvénient c'est que leur offre est un peu complexe.

Pour commencer, leur commission n'est pas la même pour la vente de produits physiques et numériques ( ce qui est normal car vendre un produit numérique signifie héberger le fichier pour téléchargement, ce qui a un coût, alors que pour un produit physique c'est le vendeur ou la vendeuse qui gère ces coûts ).

Ainsi, avec l'abonnement minimum à 12€ par mois, la commission est de 2% sur les produits physiques et 7% sur les produits numériques à laquelle il faut encore rajouter le coût de la carte bleue de 2%+25c )

Si vous passez à l'abonnement à 828€ par an, ces coûts chutent à :

• 0% de frais de commission pour eux !
• 25c + 1,5% de frais de CB

Je n'ai à priori trouver aucun autre coût caché.

Reprenons notre hypothese de 4000 ventes par mois / 48000 ventes par an à 5€ :

commission(5€) = 5*1.5% + 0.25 = 0,325€
cout(48000 ventes) =828 +  48000*0,325 ~= 15828€
jours de dev(15828€)  = 15828/360 ~= 44 jours de dev

L'option square space semble particulièrement attractive. On peut rapidement avoir une boutique fonctionelle, qui soit à peu près personalisable et pour l'équivalent de 40 jours de dev par an. Je vais vous avouer que c'est une option que je garde précieusement en tête, surtout en sachant que c'est ce qui est utilisé pour le shortbox comics fair, une festival de vente de bande dessinée numérique qui a rencontré un certain succés

NOTE : si vous êtes une autrice ou un auteur de bd qui souhaite faire l'équivalent d'un shortbox comics fair mais français, n'hésitez pas à me contacter, je sais comment faire :D

Itch.io

Itch.io est une plateforme pour vendre des fichiers numériques principalement connue pour le jeu vidéo un peu expérimental ( on y trouve des perles d'ailleurs ).

Leur modèle, bien que clairement expliqué, est un peu complexe à gérer car ils laissent chaque createurice décider du montant de leur commission, qui peut être de 0%.

Le taux par défaut est de 10%, que l'on va prendre comme base, auxquels s'ajoutent de toute façon l'habituel taux de transaction (~ 30c + 3%).

commission(5€) = 5*10% + 5*3% + 0,30 = 0,95€
cout(48000 ventes) = 48000*0,95 = 45600€
jours de dev(45600€) = 45600 / 360 ~= 127 jours de dev

Et si on fait l'hypothese qu'on ne va rien donner à la plateforme comme des gros schlags sortis de HEC :

commission(5€) = 5*3% + 0,30 = 0,45€
cout(48000 ventes) = 48000*0,45 = 21600
jours de dev(21600) = 21600 / 360 ~= 60 jours de dev

Big Cartel

Alors…l'offre Big Cartel à l'air trop belle pour être vraie. Pour un abonnement à 12€ par mois, vous pouvez vendre des produits numériques (des fichiers donc, comme un pdf par exemple ) sans qu'ils ne prennent de commission.

Evidemment, les habituels frais de transaction, qu'on va continuer à évaluer à 3% + 30c, sont toujours là et il y a une limite de 50 produits par boutiques, qui peut être pousser à 500 avec l'offre à 24€ par mois ( 288€ par an ).

Bref, on se retrouve avec les même tarifs que Itch.io en mode "0% de commission", soit l'équivalents de 60 jours de développement pour 1 années de ventes aux chiffres évoqués ( 4000 ventes à 5€ par mois ) auxquels s'ajoutent 288€ d'abonnement par an, négligeables quand on fait beaucoup de ventes (mais pas du tout négligeables quand on fait pas de ventes)

Ko-fi

Ko-fi, en plus de permettre les tips et les tips mensuels, permet de vendre ses produits digitaux. On retourve toujours les même frais de transaction ( décidemment ) auxquels on rajoute, si j'ai bien compris, 5% de comission pour Ko-fi à chaque vente :

commission(5€) = 5*5% + 5*3% + 0,30 = 0,7€
cout(48000 ventes) = 48000*0,45 = 33600€
jours de dev(33600€) = 33600 / 360 ~= 90 jours de dev

Ok, et donc ?

En résumé, pour cette première gamme de solution de boutiques en ligne (des plateformes complètes qui ne nécessitent pas de coder), je vais retenir 2 choses :

• même si c'est un peu personnalisable dans les styles et les fonctionnalités, on reste sur des modèles et des fonctionnalités qui peuvent ne pas être extensibles.
• en cherchant bien, on peut descendre à des frais très réduit mais dans tous les cas subsistent les frais de transactions de 30 centimes + 3%

Pour un/e artiste qui voudrait une solution rapide pour vendre en ligne, couplée à un site web et une communication efficace sur les réseaux sociaux, toutes ces plateformes semblent raisonnables dans leurs prix (à part Gumroad. Je comprend pas qu'ils existent eux, j'ai dû rater un truc)

A noter que pour Big cartel, qui n'a aucune commission, l'abonnement peut paraître cher si vous faites très peu de ventes.

Comparons 2 profils pour voir les coûts pour quelques unes des solutions évoquées.

Profil 1 Une autrice de Bd qui vend environ 50 pdf par mois à 6€

Square space essentiel

abonnement mensuel : 18€
cout abonnement à l'année : 216€

coût proportionelle par vente: 7% ( 5% square space + 2% carte bancaire)
coût absolu par vente: 25c ( Commission carte bancaire)
coût par vente à 6€ : 67c
total des commissions pour 50 ventes par mois, 600 ventes par an : 402€

Total abonnement + commissions : 618€
coût effectif par vente ( 600 ventes ): 1,03€
Commission effective: 1,03 / 6 = 17%

Ho ho ho !

Square space Advanced

abonnement mensuel : 69€
cout abonnement à l'année : 828€

coût proportionelle par vente: 1.5% ( carte bancaire uniquement )
coût absolu par vente: 25c ( Commission carte bancaire)
coût par vente à 6€ : 34c
total des commissions pour 50 ventes par mois, 600 ventes par an : 204€

Total abonnement + commissions : 1032€
coût effectif par vente ( 600 ventes ): 1,72€
Commission effective: 1,72 / 6 = 29%

Et oui. Si vous faites peu de ventes, vous pouvez avoir jusque 30% qui partent dans la plateforme.

Big Cartel

abonnement mensuel : 12€
cout abonnement à l'année : 144€

coût proportionelle par vente: 3% ( carte bancaire uniquement )
coût absolu par vente: 30c ( Commission carte bancaire)
coût par vente à 6€ : 48c
total des commissions pour 50 ventes par mois, 600 ventes par an : 288€

Total abonnement + commissions : 432€
coût effectif par vente ( 600 ventes ): 0,72€
Commission effective: 0,72 / 6 = 12%

(pour info : ca veut dire que pour 3600€ de ventes sur l'années vous récupérez 3168€ )

Big Cartel reste définitivement très intéressant pour les "petits" vendeurs.

Profil 2 : un petit éditeur ou un groupement d'auteurs ou un collectif, ou n'importe quoi qui arrive à faire 2000 ventes par mois à 6€ ouais je sais j'ai changé les chiffres en cours de route

Square space Advanced

abonnement mensuel : 69€
cout abonnement à l'année : 828€

coût proportionelle par vente: 1.5% ( carte bancaire uniquement )
coût absolu par vente: 25c ( Commission carte bancaire)
coût par vente à 6€ : 34c
total des commissions pour 2000 ventes par mois, 24000 ventes par an : 8160€

Total abonnement + commissions : 8988€ ( 25 jours de dev)
coût effectif par vente ( 24000 ventes ): 0,37€
Commission effective: 0,37 / 6 = 6%

Profil 3 : VOTRE PROJET A GROSSI VOUS VOUS ETES STRUCTURES ET VOUS VENDEZ 10000 FICHIERS PAR MOIS A 4€

Square space Advanced

abonnement mensuel : 69€
cout abonnement à l'année : 828€

coût proportionelle par vente: 1.5% ( carte bancaire uniquement )
coût absolu par vente: 25c ( Commission carte bancaire)
coût par vente à 4€ : 31c
total des commissions pour 10000 ventes par mois, 120 000 ventes par an : 37200€

Total abonnement + commissions : 38028 ( 105 jours de dev)
coût effectif par vente ( 120000 ventes ): 0,32€
Commission effective: 0,32 / 4 = 8%

Et ouais. Le taux a augmenté. C'était le piège. J'ai changé le prix des produits sans vous le dire. En baissant le prix des ventes, les "25 centimes de commissions par ventes" font plus mal.

Ca me saoul tous les petits chiffres et les calculs là on peut pas passer à autre chose ?

Les 1ères solutions évoquées ci dessus faisaient partie de la catégorie "je veux pas coder". Faciles a prendre en main, elles permettent de rapidement lancer sa boutique, en échange d'un coût qui peut être elevé et de possibilités d'évolutions et de personnalisations qui peuvent être limitées.

Voyons l'étape suivante, qui parait séduisante : on prend une solution technique existante, possiblement open source, mais on se la gère soit même sur son serveur. Comme ça on peut avoir son propre nom de domaine et le design de notre rêve au lieu des templates tout pourri de Squarespace.

J'en ai noté 2 :

• Wordress et son plugin woocommerce
• Snipcart

Relativement opposées dans leurs approches.

Purée mais c'est quoi le .htaccess ?

Ici, on va enlever un coût, la commission de la boutique en ligne, puisqu'on va tout gérer soi même, mais on va en rajouter un autre : le coût de développement initial.

Il faut faire cependant attention à un point : l'abonnement mensuel, de Square Space par exemple, va être remplacé par les coûts d'hébergement que vous allez devoir payer pour faire tourner votre site web.

Comme base de travail on va imaginer que le coût initial de dev ( que vous allez payer en faisant appel à un/e graphiste et un/e dev pour coder votre boutque) est d'environ 2000€. ( à titre personnel, j'arrive à monter une boutique Woocommerce complète avec un design basique en 2 jours. Donc pour le dev on peut descendre jusque 700€, arrondissons à 1000€ ).

On va aussi imaginer que votre boutique dure 3 ans avant d'envisager de passer à autre chose, abandonner ou voir plus grand.

Vos coûts de dev ( upfront )se monte donc à 667€ par an.

Woocommerce

Wordpress reste la solution pour les sites web personnels ou de petites entreprises la plus répandue, et de loin. Le système est éprouvé et la communauté et l'éco système sont riches. Il nécessite de se plonger un peu dans la technique mais avec un peu d'effort et de motivation, n'importe qui peut déployer son site.

Au dessus de wordpress, il existe un plugin, appel woocommerce, qui est totalement gratuit et open source et permet d'avoir très vite et très facilement une boutique en ligne, y compris pour les fichiers numériques. Cela nécessite encore et toujours de brancher un compte Stripe ou paypal, ou un des nombreux autre fournisseurs de paiement compatible, qui va prélever ses 30c + environ 3%, mais tout est extrêmement facile à configurer.

Faison donc une revue des coûts avec 2 hypothèses :

100 ventes par mois à 4€

1. coûts de dev initiaux ( parce que vous avez engage un/e dev et un/e graphiste que vous avez payé ) : disons 700€ par an
2. coût d'hébergements : pour ce niveau de fréquentation, on va être sur des hébergements autour de 10€ par mois, 120€ par an
3. coût par ventes : 4 * 3% + 0,30 = 0€42
4. Commission bancaire sur 1 an ( 1200 ventes ) : 504€

Soit un coût total de environ 1320€ (700+120+504) pour un Chiffre d'affaire de 4800€. Un taux effectif d'environ 23% par vente. Clairement pas ouf mais au moins vous avez un nom de domaine et un design aux petits oignons.

5000 ventes par mois à 4€

1. coûts de dev initiaux ( parce que vous avez engage un/e dev et un/e graphiste que vous avez payé ) : disons 700€ par an
2. coût d'hébergements : il va falloir passer sur un plus gros serveur. J'estime que pour être serein vous pouvez investir 100€ par mois ( 1200€ par an )
3. coût par ventes : 4 * 3% + 0,30 = 0€42
4. Commission bancaire sur 1 an ( 60000 ventes ) : 25200€ (!!!)

Soit un coût total de environ 27100 (700+1200+25200) pour un chiffre d'affaire de 240 000€. Soit environ 10,5% par ventes.

Evidemment, dans ce cas, le cout de développement initial devient négligeable et c'est la commission des transactions qui pèse. Mais on va y revenir.

Snipcart

Je vais pas vous cacher que j'ai été hyper emballé par snipcart. C'est énormément plus simple à mettre en place que Wordpress et son cortège de failles de sécurité. Vous pouvez faire juste une page web de base en html , hébergée avec l'offre gratuite ovh et y copier coller le code fournit par snipcart et vous avez une boutique qui fonctionne. Comme la partie compliquée et gourmande en ressource est hébergée chez snipcart, vous vous épargnez les frais d'hébergement élevés.

Le seul inconvénient que j'y ai trouvé c'est que la taille des fichiers est par défaut limitée à 20Mo mais on peut discuter avec eux pour l'augmenter. Et bien sûr, il y a toujours les frais de carte bancaire, en plus des 2% de commission que prend snipcart.

Revoyons nos 2 profils

100 ventes par mois à 4€

1. coûts de dev initiaux : franchement. je dirais 300€ en tout, soit 100€ par an
2. coût d'hébergement : ca passe sur du ovh gratuit 100Mo offert avec le nom de domaine
3. coût par ventes : 4*(2+3)% + 0,30 = 0€50
4. Commission bancaire sur 1 an ( 1200 ventes ) : 600€

En se forcant un peu, ca va vous couter 700€ pour réaliser 4800€ de chiffre d'affaire. Ca reste 14,5% de commission effective par vente mais ça peut être un bon compromis entre boutique personnalisée et solution rapide sans gros investissement initial.

5000 ventes par mois à 4€

1. coûts de dev initiaux : disons qu'on monte à 200€ par an parce que ca se complique un peu
2. coût d'hébergement : ca passe encore sur du ovh gratuit 100Mo à mon avis.
3. coût par ventes : 4*(2+3)% + 0,30 = 0€50
4. Commissions bancaires sur 1 an ( 60000 ventes ) : 30 000€

C'est toujours la partie fixe qui grève les coûts. Le coût de dev n'a quasiment plus aucun impact mais les 30c par ventes, sur des ventes d'un petit montant, font mal. Et je ne vais même pas évoquer le cas où vous vendez vos bd 2€.

Est ce qu'on peut pas renverser le systeme bancaire et payer en crypto monnaie du coup ?

Alors non, on va pas faire ça. Par contre on va basculer sur la 3ème possibilité : je fais tout moi même à partir de rien.

Build

Jusqu'à présent, on a seulement évoqué stripe et Paycart comme fournisseurs de paiement. On aura pu rajouter Mollie, qui a le mérite d'être anglais plutôt qu'américain mais on reste dans la même gamme de prix.

Vous aurez remarqué que ce qui grève le coût dans notre cas, où les ventes se font sur des petits montants, c'est le montant fixe de la commission : en général 30 centimes par vente.

Ce n'est pas pour rien que Stripe est si connu : leur produit fonctionne bien, la doc est très bien faite et tous les dev connaissent leur API par coeur. En contrepartie, ils se servent bien.

Mais il existe aussi des solutions techniques sans frais fixes comme par exemple sumup dont la commission par transaction est de 2,5% (en gros. J'omet les questions de cartes internationales, taux de change etc) ou les solutions de paiements en ligne…de votre banque.

Bonjour c'est votre conseiller bancaire. Vous connaissez nos solutions e-commerce ?

Pour je ne sais quelles raisons, les banques communiquent peu, ou mal, sur leurs solutions de paiement en ligne dont les frais peuvents descendre jusque 1% ( j'ai même entendu parler d'une banque qui proposait des frais de 0,5% mais je n'ai jamais pu le vérifier).

L'inconvénient c'est que ce sont des solutions techniques très complexes et qui nécessitent en plus de gérer sa TVA, ses factures, … Mais la disparition du taux fixe change tout.

Sans se concentrer sur chaque solution individuellement, qui vont toutes être du même niveau de complexité, voyons l'impact de la disparition des commissions fixes, avec des commissions à 2,5% et à 1%.

100 ventes par mois à 4€

1. coûts de dev initiaux : on va en reparler plus tard.
2. coût d'hébergement : 10€ par mois
3. coût par ventes : 2.5% * 4 = 0€10 ou 1% * 4 = 0€04
4. Commission bancaire sur 1 an ( 1200 ventes ) : 120€ ou 48€.

He ouais. Le fonctionnement de votre boutique, une fois le développement initial terminé ne va vous coûter que 240€ par an, voir 170€ dans le meilleur de cas. Pour 4800€ de chiffre d'affaires.

Et c'est encore mieux quand on grossit

5000 ventes par mois à 4€

1. coûts de dev initiaux : j'ai dit qu'on allait en reparler.
2. coût d'hébergement : désolé mais il va falloir taper dans le 100€ par mois minimum là, peut être même 150€.
3. coût par ventes : 0€10 ou 0€04
4. Commissions bancaires sur 1 an ( 60000 ventes ) : 6000€ ou 2400€

Disons que votre infrastructure vous coute 1800€ par an, auxquels vous rajoutez 6000€ de comissions bancaire soit un total de 7800€ par an. A comparer aux 30 000€ si on se fait une shop woocommerce avec stripe. soit 22 2000€ économisé.

Soit environ 60 jours de dev.

3 mois de travail.

Pour coder une boutique en ligne qui permet de faire 5000 ventes par mois.

Je pense que vous avez compris l'idée ( l'idée c'est : c'est largement faisable et ça vaut le coup)

Hé béh. C'était compliqué. En plus y a pleins d'erreurs de calculs et d'approximations.

Oui.

J'ai un peu tout mélangé, omis certains coûts, me suis trompé dans certains calculs, … Mais le but était plutôt de partager la 1ère réflexion que j'ai du avoir il y a un an, dont les conclusions ne seraient évidemment pas les mêmes si vous êtes une artiste sans compétences de code qui souhaite juste vendre une cinquantaine de fanzine par mois.

Comme cela était il y a un an, je peux même vous fournir un retour d'expérience, parce que j'ai bien enregistré tout ce que j'ai fait : ma boutique est terminée, j'y ai passé l'équivalent de 30 jours de dev et les premiers tests de charge semblent montrer que je peux faire 100000 ventes par mois avec un serveur à 60€ par mois ( avec quelques techniques pour gérer les pics de ventes s'il y en a).

Il me reste plus qu'à trouver des bd à vendre.

Petit épilogue commercial

En lisant cet article, vous vous êtes peut être dit "dis donc il s'est sacrément penché sur le sujet, il doit s'y connaitre un max en boutique en ligne et en plus il est capable d'adapter ses propositions à mes capacités et contraintes franchement faudrait trop que je lui demande un devis pour ma boutique"

C'est clair que vous avez l'oeil pour ce genre de chose. Contactez moi donc pour que je fasse votre boutique, ou alors venez me causer sur bluesky.

On a un discord pour poser des questions aussi si vous voulez.

DEUXIEME EPILOGUE

du coup on va l'appeler "péroraison" plutôt

Un point important que je vais marteler pendant les prochains mois : si plusieurs personnes ont un besoin similaire, elles dépensent moins d'argent en mettant leurs besoins en commun ( appelons ça une coopérative. Comme les trucs qui vendent le rosé le long de la national l'été )(enfin, qui faisait ça avant que toutes les nationales ne soient coupées à cause des feux de forêt ).

Pour une personne seule, évidemment qu'investir 5000€ dans une développeuse et prendre un serveur ou un abonnement à 20€ par mois pour faire 50 ventes ça vaut pas le coup mais à partir de 20 personnes qui font chacune 50 ventes, ça fait 1000 ventes par mois, ce qui peut largement justifier un investissement.

• des gens produisent du contenu ( des journalistes, des artistes...)
• des société hébergent ce contenu ( site web ad hoc comme lemonde.fr ou plateforme comme Artstation, twitter,...)
• d'autres les recensent et organisent ( Google mais aussi facebook ou twitter avec leurs algos ! )
• et enfin, une dernière catégorie de plateforme, souvent la même que celle qui hébergent, permet de consommer le contenu Si vous publiez une video sur Youtube, vous êtes la créatrice du contenu, youtube l'héberge, Bing ou Google le recensent, Bluesky peut l'afficher. ( il y a quelques nuances à tout ça mais simplifions …). Internet est un réseau de tubes dans lequel on injecte des contenus.

Mais ces dernières années, ce contenu a été accaparé par les plateformes, le modèle était "tu upload ton contenu sur notre plateforme, il nous appartient, on en contrôle l'accès et éventuellement on te reverse une partie des bénéfices qu'on fait avec" Et évidemment, tout ca fonctionnait parce qu'en réalité, ce qui était vendu c'était les consommateur/ices de contenu.

L'argent sur internet ne provient pas de personnes qui achètent ce que produisent d'autres personnes mais de plateformes qui vendent à des annonceurs l'attention qu'elles ont réussi à capter chez des individus. Attention captée par l'exposition gratuite du contenu d'autres personnes.

Pourtant il n'y a aucune raison valable pour ca.

le prix du web

Si je suis, disons, une autrice de bd, mettre mes bd en ligne, lisible par 2 millions de personnes sans que le serveur n'explose me couterait actuellement 12€ par mois de bande passante et 15€ par an de nom de domaine. 159€ par an soit sans doute autant que les dépenses en peintures et pinceaux d'une artiste tradi. Et mettre un bouton paypal ne coute rien. Et les gens qui aiment lire la bd pourraient soutenir l'artiste en donnant 1€ par mois. Et si ils étaient 3000, ca permettrait à l'artiste de vivre à peu près correctement tout en cotisant pour sa retraite et l'assurance maladie

Mais ça ne s'est pas passé comme ça pour, à mon avis, 3 raisons

1. Quoi que moi j'en crois en tant que développeur, le palier technique à l'entrée est en fait grand. Faire un site web vs ouvrir un compte vite fait sur Instagram ? Zero sujet jusqu'à présent
2. La vitrine. C'est chouette de faire son site web chacun dans son coin mais les lecteurs et lectrices ne sont pas des petits chercheur/euses d'or qui parcourent tout le web à la recherche de la pépite. Non, ce qu'on aime c'est un gros hub centrale qui nous balance une joli vitrine déjà présélectionnée et où on a juste à choisir.
3. Le micropaiement n'existe pas. Coté lecteur, sortir sa CB, voir ouvrir un compte paypal / kofi / Patreon / whatever quand j'ai lu une bd rigolote de 4 cases, c'est bof. Coté artiste, sur 1€ je vais me faire éclater 25c par le fournisseur de paiement , qui en plus peut décider de son coté de ne plus accepter le paiement pour mes produits parce que il y a un perso LGBT ou un téton féminin visible

On aurait pu penser que le web aurait permis l'émergence de circuits courts mais au final, des années après, c'est le modèle classique qui domine : les économies d'echelles favorisent les gros acteurs ( il est plus facile de mettre 10 000€ dans un site web pour Naver que pour une autrice de webtoon) et plutôt que de se disperser, la consommation se réduit à quelques plateformes dans lesquelles il est impossible de ne pas être si on veut exister. Quand au paiement, ce n'est pas le modèle dominant sur Internet, habitués au contenu gratuit permis à la fois par l'exploitation des créatrices et créateurs de contenus et la vente du temps d'attention des consommateurs et consommatrices des contenus.

Evidemment, rien de nouveau ici, le phénomène s'était déjà produit avec la presse et la télé. Faire un journal ce n'est pas rentable mais vendre les lecteurs d'un journal à des annonceurs, ca aide. Il y a une sorte de fatalité avec les médias, dont on dirait que personne n'est prêt à accepter le prix que ca coute de produire un média de qualité. Que ce soit de l'information de qualité ou un feuilleton bd.

Les journaux d'informations ont commencé à sortir de cette phase et leurs lecteurices aussi. Mediapart, Les Jours, … Je ne connais pas le détail de leurs revenus mais force est de constater qu'ils existent encore et produisent du contenu de qualité sans avoir recours à la pub ou la vente de temps d'Attention de leurs lecteurices. Je ne sais pas si un modèles similaire est possible dans la bd, de nombreuses tentatives ont déjà échoués, mais j'espère que oui.

Je ne connnais même pas la musique qu'ecoutent mes enfants.

Je suis tellement en accord avec l'article de Pauline Harmange que j'ai l'impression de ne pouvoir que paraphraser.

J'écoute énormemént de musique, j'aime beaucoup ça. Depuis des années, sans doute à cause du travail en Open Space, je passe une grande partie de ma journée avec un casque sur la tête et une appli, Spotify avant, Apple Music maintenant, pour le remplir de contenu. Mais depuis environ 1 mois, j'ai remplacé Apple Music par un transistor Sony à 15€ acheté chez Darty et branché sur FIP.

Comme l'autrice citée plus haut, j'ai été de plus en plus déçu au fil des années de mon wrapped annuel, cette pratique consistant à produire un récapitulatif de ce qu'on a écouté ( ou vu, ou lu ) l'année passée.

En plus de me rendre compte que c'est finalement toujours les 20 mêmes chansons en boucle, elles ont pour la plupart en commun d'être juste des tubes de l'époque où j'avais 20 ans. Evidemment, çe me plait. La preuve, je les écoute en boucle. Mais récemment, à l'occasion d'un voyage en voiture avec 3 ados au cours duquel on a été contraint de partager le haut parleur principal de la voiture, j'ai découvert Théodora, et j'ai adoré.

Je me suis rendu compte que :

1. je ne connais quasiment aucune ou aucun artiste récent/e
2. Quand j'en découvre un/e, il arrive que j'aime beaucoup.

Pourtant il me semblait que les recommandations de l'algorithmes de Apple Music étaient super. Quasiment à chaque fois que il me proposait un morceau, j'aimais ça. D'ailleurs c'est pareil sur Instagram, quand je m'y met, je peux passer 1 à 2 heures à scroller et cliquer sur ses propositions !

Est ce que j'ai découvert de nouvelles illustratrices, ou illustrateurs, dont je suivrais dorénavant le travail ?

Non.

Est ce que j'ai appris des trucs sur la peinture de figurines, un de mes hobby qui m'avait fait venir sur Insta ?

Non plus.

Discover

Je suis développeur et il y a bientôt 1 an, je suis repassé Freelance avec l'idée que si les artistes n'ont plus de visibilité sur le web c'est parce qu'ils n'ont pas leur propre site web. C'est en partie vrai ou en tout cas une condition sine qua non pour exister. Mais être indépendant dans son petit coin du web ne résoud pas tout. Même avec un contenu qui plait suffisamment pour convaincre les gens de vous suivre voir de payer pour votre travail, il reste 2 barrières à franchir :

1. Que les gens découvrent votre travail
2. Qu'ils soient mis au courant quand vous publiez du nouveau contenu.

Pendant longtemps, la découverte se faisait par mots clé. Si vous vouliez lire une bd d'aventures, vous tapiez "bd d'aventures" sur google et vous obteniez une liste de site web de bd d'aventures, classée selon le nombre de sites web qui citaient cette page comme référence en matière de bd d'aventures. Notez que déjà là, la découvrabilité d'un site dépendait d'un algorithme et de recommandations externes mais au moins les mots clés étaient pris en compte et surtout, pendant longtemps, les recommandations étaient sur ce que vous aviez demandé ( "bd d'aventure").

Puis il y a eu les réseaux sociaux et les recommandations personnalisées. On a pu rajouter un retour interactif aux contenus ("j'aime","Partager", …) permettant de dresser une relation entre contenu et consommateur/ices. Plutôt que d'avoir une liste de bd d'aventures, vous aviez la liste des bd d'aventures auxquelles des gens similaires à vous avaient réagi.

Evidemment, on ne peut pas complètement se passer de traitement algorithmique.

L'indexation de contenu, puisque c'est de ça qu'il s'agit, est un problème complexe à l'échelle d'internet. Si des gens recherchent de la bd d'aventure, vous ne pouvez pas vous contenter de retourner tous les sites qui ont mis "bd d'aventure" dans leur titre, au risque que quelqu'un fasse une page blanche dont le titre serait "bd d'aventure" et soit propulsé aussi haut qu'une autre bd d'aventure plus légitime. Mais par contre il est temps de se demander si "les gens qui ont réagi à ce type de contenu ont aussi réagi à ce type de contenu" reste pertinent pour découvrir du contenu de qualité.

Si vous avez aimé… alors vous aimerez…

On voit poindre la différence entre 2 types d'objectifs, pour lequels on peut parfois employer les même algorithmes.

proposer du contenu recherché à propos d'un sujet ("bd d'aventure") proposer du contenu qui va me faire réagir. Pour le premier cas, il s'agit d'indexation pure. Etant donné un sujet, quelles pages web ( on parle plutôt de "document" ) sont légitimes à parler de ce sujet. La difficulté de la tache est donc de définir la légitimité d'un document à propos d'un sujet au moment de ma recherche. Parfois, rien que le fait d'en parler de manière plus spécifique que d'autres termes suffit à positionner un document comme traitant du sujet mais plus souvent, on se base sur les recommandations des autres, reconnaissant ainsi tacitement qu'un contenu légitime est un contenu très souvent cité.

Notez en passant que "montre moi les bd produites par cet artiste que j'aime bien " est une forme d'indexation. Ici point d'algos, on a la forme d'indexation de contenu la plus simple possible : l'identité du producteur ou de la productrice de contenu est utilisé pour indexer le contenu et on récupère tous les contenus indexés par cette identité, classés par date. Mais même cette indexation très simple est dévoyée et dans instagram, vous abonner au contenu d'un/e artiste que vous aimez ne garantit même pas que vous le voyez dans votre feed.

Pour le 2ème cas, tout le problème est dans la relation entre "apprécier" et "decouvrir", en plus de la prémice un peu vite acceptée que partager du contenu voir même aimer du contenu signifie qu'on en veut plus.

J'aime le travail de Maïlis Colombié, j'aimerais en voir plus. Je me suis abonné à son compte instagram ainsi qu' à celui d'autres artistes. Est ce que instagram m'a proposé des blog bd similaires ? non.

Est ce que google me permet de trouver des bd ou des blogs bd dans ce style ? non plus.

Il n'existe plus aucun moyen de trouver facilement du contenu sur un sujet, ou similaire à un sujet. Par contre, je peux passer 2 heures a scroller sur instagram.

Portal

Ce que je voudrais semble-t-il, c'est une sorte de page web en laquelle j'aurais confiance et qui me proposerait des recommandations sur un sujet donné. Il se trouve que cela existe pour certains sujets ou, le cas contraire, que c'est assez facile à faire.

Il y a 3 sortes d'actrices et d'acteurs sur Internet : les créateurices de contenu, les consommatrices et consommateurs et… les référents. Les créateurices commencent à prendre conscience des problemes des plateformes mais en reste dépendant/es. Les consommatrices aussi. Mais pour résoudre le problème il va falloir qu'on se remette à recommander, ce qui va plus loin que de juste liker ou partager de manière molle un contenu,

Si vous faites de la photo, du dessin, du tricot, vous pouvez vous faire un website ou un blog pour partagez vos créations mais même si vous ne créez pas, vous pouvez parler de ce que vous aimez et faire une page web en dehors des plateformes, avec des liens vers d'autres sites web qui vous plaisent, qui feront de même, etc...

J'ai besoin d'un site web qui recensent tous les blog bd d'aventures chouettes. Mettez vous y s'il vous plait, je vous explique comment faire.

Dans ce jeu de rôle, comme dans la plupart des jeux de rôle (pas tous), une des composantes principales du système de jeu est le lancer de dés. Il faut donc que le notre soit irréprochable.

Définir par les tests.

Avant de parler statistiques et math, parlons un peu méthode.

Quand vous vous apprétez à coder un nouveau système, la première étape n'est souvent pas de déterminer comment vous allez faire, quel langage, quel algorithme,... Mais plutôt comment on va déterminer que le projet est clôt et réussi.

Je m'explique.

Le vrai métier d'un·e dévelopeureuse c'est de modéliser : transcrire en un code formel des besoins exprimés de manière naturelle ( par opposition à formelle ). Attention, je ne dis pas que c'est le travail du chercheur ou de la chercheuse en informatique, qui travaillent sur l'informatique en tant qu'outil technique. Mais pour les gens qui gagnent leur vie avec le développement informatique, la plus grande valeur ajoutée une fois la syntaxe du langage maitrisée, c'est de savoir définir ce qu'on attend du code.

Les méthodes diffèrent mais comme je l'avais dis une fois sur les réseaux de manière à moitié sérieuse, j'ai tendance à apprécier la méthode qu'on appelle le BDD (Behavior-Driven development). Si on vous demande "Ha tiens j'aimerais une app qui me prédit la Température de demain", j'aurais tendance à écrire ceci :

function tomorrowTemp():number {
  return 14.5 ; //Température moyenne en France
}

_ (il y a une très bonne note de XKCD là dessus mais je crois qu'elle n'est que dans l'édition papier de ses "How to")_

Et là vous allez me dire

Mais c'est complétement débile et complétement faux ?!

Très bien, vous avez raison, pourquoi c'est faux ?

((évidemment que ca se passe pas littéralement comme ça))

C'est pas la même température à Toulouse et à Lyon ?! Il fait pas la même température partout

Ok donc déjà vous voulez une température par ville

et puis ca peut pas etre la même température toute l'année.

…par date donc

Et puis c'est faux ? Il a pas fait 14 tous les jours ces dernières années

Ok donc pour valider la fonction on va la vérifier sur les archives de températures

Et faut pas que ca se trompe dans les prédictions plus de 95% du temps

(donc sans doute que ce qu'il veut c'est une cross entropy sur la cross validation )

Etc.

Le dialogue est extrêmement caricatural mais je pense qu'il illustre bien le fond de l'idée qui est de commencer par définir formellement ce qu'on attend d'un programme, qu'on doit considérer comme une boite noire, au lieu de se concentrer sur comment il va le faire. Et si vous trouvez ça vraiment débile, pensez à tous les programmes en cours d'intelligence artificielle ( nous somme en Novembre 2025 au moment où ce billet est écrit) qui ont juste spécifié "on va foutre de l'IA " au lieu de "on va améliorer le taux de détection", "on va réduire le temps d'attente", "on va augmenter la détection de taux de defection".

Pour être très concret, et juste pour montrer à quoi ca peut ressembler, cela veut dire que quelque part dans votre projet vous allez avoir un fichier qui ressemble à ça

import { describe, it, expect } from "vitest";
import DiceCup from "@models/DiceCup";
import constants from "@stdio/constant";

describe("Dice diceDescriptor string Parser", () => {
  it("should create One four sided face if you use 1D4", () => {
    const myCup = new DiceCup("1D4");

    expect(myCup.modifier).toBeUndefined();
    expect(myCup.dice.length).toBe(1);
    expect((myCup.dice[0].dieValue = 4));
  });

  it("should create not create 1Dsix+douze", () => {
    const myCup = new DiceCup("1Dsix+douze");

    expect(myCup.modifier).toBeUndefined();
    expect(myCup.dice.length).toBe(0);
  });

  it("should create not create 1Dboule", () => {
    const myCup = new DiceCup("1Dboule");

    expect(myCup.modifier).toBeUndefined();
    expect(myCup.dice.length).toBe(0);
  });

})
describe("Fair throw and expected value", () => {
  it("should respect chiSquared criteria for 1D6", () => {
    const startTime: number = performance.now();
    const faces = 6;
    const maxChisquared = constants.chiSquared005Table[faces];

    let myCup = new DiceCup("1D" + faces);
    const nRoll = 60000;
    const valueCount = new Array(faces).fill(0);

    for (let i = 0; i < nRoll; i++) {
      const r = myCup.roll();
      valueCount[r - 1]++;
    }

    /** Ok now go chi squared */
    const valuesExpected = new Array(faces).fill(nRoll / faces);

    let chiSquared = 0;
    for (let i = 0; i < faces; i++) {
      const a = (valueCount[i] - valuesExpected[i]) ** 2;
      chiSquared += a / (nRoll / faces);
    }
    const endTime: number = performance.now();
    const elapsedTime = endTime - startTime;
    expect(elapsedTime).toBeLessThan(200);
    expect(chiSquared).toBeLessThan(maxChisquared);
  });
})

Le fichier ci-dessus utilise une syntaxe courante à base de mots clés comme "it","should","expect", qui sont des vrais mots clé informatique dans ce cadre, interprétés très formellement par l'ordinateur.

Mais revenons en au sujet de l'article et regardons plus en détail ce test "it should respect chiSquared criteria for 1D6"

Quantifier l'aléatoire Comme je suis très sérieux, je veux écrire un test pour vérifier que mes dés virtuels sont corrects pour jouer à Donjons & Dragons. Seuleument, la difficulté intrinsèque à tester un lancer de dés est qu'il n'y aucune certitudes sur ce qu'on peut attendre du résultat.

Dois-je lancer les dés 6 fois et vérifier que j'ai bien chaque chiffre ? 60 fois et vérifier que chaque chiffre apparait 10 fois ? Non, ca serait pas systématique. Alors lancer 100 fois 60 fois 1D6 et vérifier que dans 50% des cas j'ai bien 10 fois chaque chiffre ?

En matière d'aléatoire, les statistiques ne nous donnent qu'une certitude : plus j'effectue un même tirage (lancer un dé, une pièce, tirer une boule d'un sac,…) et plus le résultat va se rapprocher de la distribution théorique espérée.

Distribution Le cœur des tests statistiques ce sont les distributions. Une distribution ce n'est ni plus ni moins qu'une valeur avec une autre valeur en face qui dit dans quelle proportion je devrais la trouver si j'effectue mon operation un million de fois, 100 milllions de fois, 100 000 milliards de fois…

Cela peut prendre 2 formes :

Un tableau qui recense toutes les valeurs et met en face la proportion attendue

Ou une fonction qui vous dit très précisemment pour chaque nombre (de son domaine) la proportion de valeur autour de ce nombre (c'est en réalité plus compliqué que ça mais ce n'est pas le sujet aujourd'hui)

Dans le cas qui nous intéresse on a juste besoin du tableau de nombre, qui est la "distribution d'un dé à 6 faces non biaisé". Il va donc falloir trouver un test qui vérifie que la distribution qu'on obtient avec un nombre suffisamment grand de lancer est proche de la distribution espérée.

χ²

Heureusement,ce test là est un test bien connu et maitrisé en statistique, c'est même l'un des premiers que vous apprenez, et s'appelle le test du chi-squared. La page wikipedia vous en dira plus mais elle un peu rude, même si elle donne précisemment le dé à 6 faces qui nous interesse comme exemple d'application.

Sans rentrer dans les détails de la démonstration, qui peut être difficile, voyons au moins le raisonnement et comment l'utiliser en tant que dev. La première utilité à noter c'est que le test du chi-squared vous donne pour n'importe quelle distribution un nombre et un seul. C'est particulièrement pratique pour nos tests puisqu'on va pouvoir lancer nos dés virtuels des milliers fois et réduire tous ces lancers à un seul nombre, puis décider quelle valeur notre test attend pour ce nombre.

Je met le raisonnement derrière ce nombre pour celles et ceux que ca intéressent

1. On connait la loi qui régit le nombre de 1 ( et de 2, et de 3, et de 4...) que vous allez obtenir en lancant 1 million de fois un dé à 6 faces : c'est la même que celle de pile ou face. En effet, à chaque tirage vous avez 1 chance sur 6 d'obtenir un 1 et 5 chances sur 6 de NE PAS obtenir un 1. Pareil pour les autres valeurs.
2. Si considère donc chaque tirage comme "obtenir un 1 ou ne pas obtenir un 1" , on a une formule qui nous dit combien on aura de 1 à la fin, de 2, de 3 etc…
3. Evidemment on sait tous que en moyenne on aura 1/6 de chaque mais la loi ci dessus est beaucoup plus puissante, elle nous donne la probabilité qu'on ait a peu pres 10 000 fois le nombre 5 si on fait 60 000 lancer mais aussi la probabilité qu'on l'ait à peu pres 6000 fois, à peu pres 2000 fois, etc. Car souvenez-vous que meme si évènement se produit en moyenne 10000 fois sur 60000, ça ne veut pas du tout dire que il se produira 10000 fois à chaque fois que vous faites 60000 lancers. Le point important ici est que le compte de chaque valeur suit une distribution Normale (parfois appelée Gaussienne)
4. Il se trouve qu'une autre loi, qui sert de titre à ce paragraphe, vous donne la valeur espéré des comptes, en gros, de plusieurs variables suivant une loi gaussienne, soit exactement notre cas ! Bref, comme on a eu des cours de statistiques, on connait une loi qui nous dit quelle valeur espérer si je fais la somme des carrés (les carrés permettent de faciliter certaines operations mathématiques comme la dérivation, vous tracassez pas) de la difference entre ce que j'observe et ce que j'espere.

Dont acte

const nRoll = 60000; // On lance le dé un nombre suffisamment grand de fois
const valueCount = new Array(faces).fill(0); // Au début , chaque nombre est obtenu zero fois

for (let i = 0; i < nRoll; i++) { // On va faire 60 000 jets virtuelles
  const r = myCup.roll(); // On note le résultat
  valueCount[r - 1]++; // On rajouter "+1" dans la case correspondante ( '0ème' case pour le résultat 1 et '5ème' case poru le résultat 6)
}

/** Ok now go chi squared */
const valuesExpected = new Array(faces).fill(nRoll / faces); // Notre distribution idéale POUR UN DE NON BIAISE serait de 1/6 de 60 000 pour chaque valeur de dé

let chiSquared = 0;
for (let i = 0; i < faces; i++) {    // Pour chaque valeur possible de dé
  const a = (valueCount[i] - valuesExpected[i]) ** 2; // on mesure la difference entre le nombre de fois où on l'a vue et le nombre de fois qu'on aurait espéré la voir, et on met au carré
  chiSquared += a / (nRoll / faces); // on divise par la le nombre de fois espéré (pour normaliser la somme) puis on additionne au total
}
const endTime: number = performance.now(); // Tant qu'on y est on mesure aussi le temps d'exécution
const elapsedTime = endTime - startTime;
expect(elapsedTime).toBeLessThan(200);
expect(chiSquared).toBeLessThan(maxChisquared);   // et enfin on vérifie que notre chisquared reste inférieur à une certaine valeur standard des statistiques.

Donjons et Dragons, en typescript

Ainsi que je le disais sur le réseau social Bluesky, je me suis mis en tête à l'occasion de la mise à jour des règles de Donjons et Dragons en version 5.5 de voir si je pouvais coder une partie de celles-ci, sans la partie graphique, en Typescript.

Donjons & Dragons est un jeu de rôle, c'est à dire un ensemble de règles, plus ou moins complexes, permettant de simuler un univers fictif ainsi que la description de l'univers en question : ses pays, ses différentes formes de vies, son économie,... Ce n'est sans doute pas mon jeu de rôle préféré mais il a l'avantage de laisser peu de places à l'interprétation dans ses règles, assez bien formalisées et relativement cohérentes.

Quand à typescript, il s'agit d'un langage de programmation à l'histoire un peu particulière puisqu'il n'existe que pour combler les défauts d'un autre langage déjà existant mais perclus de défauts, le javascript. Imaginez ça comme un ajout de mots clés au langage, que vous avez le droit ou pas d'utiliser mais qui, quand vous le faites, rend tout plus formel.

Pour des raisons que nous allons expliquer plus loin.

Mais c'est quoi le travail de développeur et développeuse au juste ?

Sans doute que pour les gens dont ne c'est pas le métier, la principale activité d'une personne qui développe, qu'on appelera désormais "developpeureuse" par souci d'inclusion, c'est d'écrire des lignes de code, ce qui est en en grande partie vraie.

Quand on débute, la maitrise du langage informatique, voir de plusieurs, représente la plus grosse difficulté et l'activité sur laquelle on passe le plus de temps, à l'instar de la dessinatrice débutante qui doit se concentrer pleinement pour dessiner une guerrière à cheval chargeant une automobile vue de 3/4. Mais avec la pratique apparait le vrai métier de développeureuse : la modélisation.

Plus on avance et plus le métier consiste à recevoir une suite d'instructions en langage naturel, imprécises et ouvertes à l'interprétation, émises par des responsables produits, dirigeant·es de startup ou chef·fes de projet, pour les convertir en règles beaucoup plus strictes, formelles et surtout déterministes, qui prendront la forme de ligne de code qu'on tapera nous même ou confiera à une personne encore au stade de l'apprentissage de la technique de codage.

La capacité d'abstraction est une compétence commune à beaucoup de profession scientifiques ou créatives. Elle consiste, à mon avis, à saisir ce qui est la quintessence d'une chose, ce à quoi on peut la réduire au minimum sans trahir sa nature. Et pour le coup, je me permettrais de citer une célébrité connue parce que je trouve que ça colle parfaitement :

La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer.

Probablement Antoine de Saint-Exupéry

Des vertus du formalisme

C'est sans doute le propre des sciences, et peut être en partie de l'Art, de chercher, pour toute choses et tout phénomène, comment le réduire à sa forme la plus élémentaire tout en expliquant et reproduisant un maximum des observations qui en ont été ou en seront faites. C'est aussi ce que certains et certaines d'entre nous font en informatique et que j'appelais plus haut "modéliser", décrire de la manière la plus succinte, mais qui reste fonctionelle pour le but recherché, les choses.

Ainsi par exemple, "un site web où l'utilisateur peut lire mes bd" deviendra "des listes d'images ordonnées, listes elles mêmes numérotées par date" puis

interface BdPage {
  images: string[];     // une image c'est juste une url donnant son emplacement.
  date: Date;
}

interface blog {
    pages: BdPages[];
}

et voilà ! vous avez tout ce qui faut pour faire un blog BD !

Types.

Revenons brièvement sur cette histoire de Typescript. Le web moderne repose pour beaucoup sur un langage, le dénommé javascript, qui a d'après la légende était conçu à la va vite. Ainsi, entre autre reproche qu'on lui fait, celui ci ne possède pas réellement de système de typage de ses variables, problème corrigé par un autre langage qui vient s'y greffer, le Typescript.

Une partie du métier de dévelopeureuse est justement de choisir comment décrire chaque élement qui va composer notre application. Et décrire, c'est typer. Voyons ça avec mon exemple de Donjons & Dragons et demandons nous ce qu'est un jet de dés au juste :

import constants from "@stdio/constant";

import constants from "@stdio/constant";

interface Die {
  dieValue: number;
}

interface DiceCupTemplate {
  dice: Die[];
  modifier?: number;
  roll(): number;
}

/**
 *  DiceCup is a cup with some dices, only the polyhedral ones,
 *  and maybe a modifier ( a number that add at the end )
 *  It's created from a classic DND string like "1D8 + 4".
 *
 */
class DiceCup implements DiceCupTemplate {
  dice: Die[] = [];
  modifier?: number;

  /**
   * constructor is a little bit complex because we parse string
   * First we split on the '+'
   * then, each element may be a number or a dice
   * It's a dice if splitting it on the D gives 2 elements
   */
  constructor(diceDescriptor: string) {
    //1D6, 1D6+9 etc
    const itemList: string[] = diceDescriptor.replace(/\s/g, "").split("+");

    for (let item of itemList) {
      const maybeADie: string[] = item.toLowerCase().split("d");

      if (maybeADie.length === 1) {
        const c = parseInt(maybeADie[0]);

        if (!isNaN(c)) {
          this.modifier = c;
        }
      }

      if (maybeADie.length === 2) {
        const dieCount: number = parseInt(maybeADie[0]);
        const dieValue: number = parseInt(maybeADie[1]);

        if (!isNaN(dieCount) && !isNaN(dieValue)) {
          if (constants.polyhedralDieValues.includes(dieValue)) {
            for (let i = 0; i < dieCount; i++) {
              this.dice.push({ dieValue } as Die);
            }
          }
        }
      }
    }
  }

  static getRandomIntInclusive(min: number, max: number) {
    const randomBuffer = new Uint32Array(1);

    window.crypto.getRandomValues(randomBuffer);

    let randomNumber = randomBuffer[0] / (0xffffffff + 1);

    min = Math.ceil(min);
    max = Math.floor(max);
    return Math.floor(randomNumber * (max - min + 1)) + min;
  }
  roll(): number {
    let total = 0;
    for (let die of this.dice) {
      total += DiceCup.getRandomIntInclusive(1, die.dieValue);
    }

    if (this.modifier) {
      total += this.modifier;
    }

    return total;
  }
}

export default DiceCup;

Dans le jeu Donjons & Dragons, un jet de dé consiste à lancer un ou plusieurs dés polyédriques ( restreints aux polyèdres réguliers plus le dé à 100 faces qu'on peut simuler avec un dé à 10 faces) et à y ajouter un modificateur pour obtenir un nombre entier.

Un "jet de dé" c'est donc :

• Une liste de 0, 1 ou plus dés,

• 0 ou 1 nombre entier ( le modificateur),

• Une méthode "lancer" (roll en anglais ) qui retourne en entier dépendant des dés lancer et un dé c'est :

• un nombre entier appartenant à l'ensemble 4,6,10,12,20

De plus, le jeu propose une formalisation de la description d'un lancer de dé sous la forme "2D6","1D20", "2D6+1D4+10". On rajoute donc la règle

Une description d'un lancer de dé est une suite de 0, 1 ou plus élèments séparés par le caractères "+". Chaque éléments est soit sous la forme d'un entier, soit sous la forme de 2 entiers séparés par la lettre "D"

Et boum. Vous voilà à inventer une grammaire et écrire un analyseur syntaxique pour déchiffre ( "parse") cette grammaire. Bien qu'en apparence trivial, ce travail est déjà une énorme suite de choix et de simplifications. Après tout, j'aurais très bien pu décrire un lancer de dés comme un ensemble de polyhèdres non élastiques munis d'une vitesse initiale et d'un moment cinétique et soumis aux lois de la gravité mais pour ce jeu là en particulier, voir un dé comme un nombre entier muni d'une méthode "lancer" est suffisant (je connais au moins un jeu pour lequel ce serait nécessaire par contre)

Vous aurez évidemment remarqué que pour l'instant on ne s'est pas préoccupé de décrire COMMENT obtenir notre nombre entier à partir de la description de l'objet "lancer de dés" (Vous pouvez cependant lire le code en détail pour voir comment). Nous nous sommes juste demander "de quoi a ton besoin pour notre simulation" et "qu'est ce qui décrit ce dont on a besoin". Le boulot ensuite sera d'écrire ça sous forme de langage informatique et c'est là qu'on retrouvera la compétence qu'on prête aux dévelopeureuses : écrire du code

// Un dé c'est
interface Die {
  dieValue: number; // Juste un nombre ( Typescript ne fait pas de différence entre nombres flottants, entiers etc)
}
// Un jet de dé c'est :
interface DiceCupTemplate {
  dice: Die[]; // Une liste de dé
  modifier?: number; //  un nombre entier
  roll(): number; // et une méthode roll() qui retourne un entier, sans doute à partir de la liste de dé et du modificateur
}
// Pour créer un jet de dé, on fournit une chaine de caractères
  constructor(diceDescriptor: string)
  [...]