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)
  [...]

Distribution de PDF

Je ne suis pas suffisamment compétent ni informé pour savoir si c'est viable "commercialement" mais en l'espace de quelques jours, sans doute en partie parce que j'y prétais une oreille attentive, des artistes, autrices et auteurs de bd particulièrement, ont évoqués autour de moi l'idée de mettre leur contenu sous forme numérique en téléchargement, gratuitement ou en échange d'un prix libre. Je me suis demandé quelle forme ca pouvait prendre techniquement. Vous pouvez m'écouter en train d'y réflechir ( et commencer à coder ) sur la vidéo suivante, issue de ma chaîne twitch

Fonctionnalités, problèmes

Quand je commence un projet qui à vocation à être réellement utilisé ( et donc pas juste à tourner sur un pc en local avec 10 utilisateurices maximum ) j'aime bien commencer par lister clairement :

• à quoi ça sert, pour chaque intervenant,
• de quel problème faut il se prémumnir Ainsi ici :
• Les artistes veulent déposer leur pdf sur un service et permettre à leurs lecteurices de payer une petite somme
• les lecteurices veulent télécharger ( et lire ) le pdf pour lequel ils ont payé Mais :
• A priori, l'artiste veut éviter que le lien de téléchargement, acheté une seule fois, ne soit partagé
• L'artiste, et son développeur, ne veulent surtout pas garder de numeros de carte bleues ou données personnelles dans leurs bases de données à part le stricte nécessaire
• Il faut que le lecteur, ou la lectrice, recoivent l'url de download par email plutôt que d'être redirigé directement après achat vers une page de download dont il, elle pourrait oublier ou perdre le lien

Architecture

Cela me conduit une architecture qui ressemblerait à quelque chose comme ça, avec 3 élèments notables et importants :

• les urls de donwload sont signées, assurant ainsi qu'elles ont bien été autorisées ET qu'elles sont uniques à l'email de la personne qui a payé.
• Dès son départ, l'état de la transaction est suivi en BDD et évolue selon la sequence CREEE -> DEMANDEE -> ECHOUEE ou TERMINEE. Le status "DEMANDEE" permet entre autre de suivre les downlaods qui auraient démarrés mais n'aurait jamais pu aboutir pour quelque raison que ce soit.
• Très important : le paiement n'est rééllement capturé ( c'est à dire effectif ) que si le download s'est bien terminé. Cela fait porter le risque sur l'artiste de voir des paiements effecctué mais jamais "consommés" mais cela évite les demandes remboursements massives suite à un problème techniques, demandes de remboursements qui ont un coût pour le vendeur

Et c'est sur ces bases que l'on attaque le codage , dont vous pouvez voir une partie dans la vidéo ci dessus.