Et l’hypermédia sauva le web

Le World Wide Web est le système documentaire d’Internet. À l’instar de l’email qui permet d’envoyer des messages à d’autres utilisateurs, le Web permet de consulter des documents de différentes natures reliés les uns aux autres comme dans une espèce de gigantesque toile d’araignée.

Cette notion de documents de différentes natures reliés les uns aux autres, c’est ce qu’on appelle l’hypermédia. Il s’agit du principe autour duquel le Web est construit, et pourtant cette notion tombe dans l’oubli.

Prenons en exemple un projet hypermédia que l’on connaît tous : Wikipédia.

Chaque article de Wikipédia est une ressource hypertexte reliée à d’autres articles Wikipédia (hyperliens internes), et reliée à des sources documentaires sur le Web (hyperliens externes profonds).

De plus, un article Wikipédia peut être relié à d’autres ressources de la Wikimédia Foundation, tels que des médias hébergées sur Wikimedia Commons, ou des fiches de la base de connaissances Wikidata.

Schéma simplifié des liens sortant de l’article « Hypermédia »

Mais aujourd’hui, nous ne faisons plus les choses comme ça.

On ne développe plus des sites web reliés les uns aux autres, mais des applications qui fonctionnent en silos, et qui tentent de vous retenir à l’intérieur par des avertissements balourds.

Attention, il ne faudrait pas que vous accordiez votre attention à quelqu’un d’autre que nous.

Et dans le même temps, quelques hurluberlus ont passé les années 2010 à évangéliser certaines pratiques de développement, sans prendre le temps de les comprendre, ni même de s’apercevoir que non : il n’y a pas de baguettes magiques.

Quoi, tu fais encore du SQL ? Du MVC ? Des monolithes ? Des requêtes AJAX ? Tu es bloqué dans les années 2000 ou quoi ?

Maintenant, il faut faire du Scrum ! Utiliser des frameworks front-ends ! Faire des micro-services ! Utiliser des bases de données noSQL ! Faire du REST !

Je n’aime pas Scrum et j’aime de moins en moins les frameworks frontend, par contre j’aime assez REST… mais est-ce que quelqu’un parmi eux sait au moins ce que c’est ?

C’est quand le serveur expose des actions CRUD et répond en JSON !

« Ah ! Non ! C’est un peu court, jeune homme ! »

Pourtant il y a des choses à dire, parce que comprendre REST c’est comprendre le Web.

Alors, qu’est-ce que REST, réellement ?

REST signifie Representational State Transfer.

REST, ce n’est pas un format de sortie, c’est un style d’architecture — celle pensée pour le Web — qui doit respecter les six contraintes suivantes, définies par Roy Fielding dans sa thèse Architectural Styles and the Design of Network-based Software Architectures :

  1. Les responsabilités sont découplées entre le client et le serveur (celle là est simple, en principe tout le monde la respecte)
  2. La communication entre le client et le serveur s’effectue sans état, c’est-à-dire que le client a la responsabilité de fournir toutes les informations nécessaires pour que le serveur puisse répondre (ici aussi, généralement peu de problèmes)
  3. Le serveur doit fournir les informations nécessaires pour que le client puisse déterminer quelles information mettre en cache sans risquer de stocker des données obsolètes. (si votre application frontend décide d’elle-même ce qu’elle met en cache ou non, vous sortez ici)
  4. Le client ne doit pas être capable de savoir s’il est connecté au serveur final ou à un serveur intermédiaire (si vous avez une URL d’API différente pour chaque région, vous n’êtes pas REST)
  5. Le serveur a la possibilité d’ajouter des fonctionnalités au client en lui injectant des scripts (attendez, on peut faire ça avec du JSON ?)
  6. Le plus important : le serveur doit présenter une interface uniforme. (et ça, on le trouve très rarement)

Pour avoir une interface uniforme, le serveur doit :

  • Fournir au client des représentations de ressources qu’il peut manipuler à l’aide d’actions métiers (et non pas un bête CRUD)
  • Permettre des requêtes auto-descriptives utilisant les verbes HTTP et des URIs sémantiques pour identifier des ressources spécifiques (cependant REST ne dit pas comment une ressource doit être identifiée)
  • Fournir des réponses auto-descriptives qui permettent de naviguer vers d’autres ressources et d’autres actions à l’aide d’hyperliens
Niveau 0 : Représentation de la donnée (XML/JSON) / Niveau 1 : Organisation en ressources / Niveau 2 : Utilisation des verbes HTTP / Niveau 3 : Contrôles hypermédia (Liens)

Quand on applique REST, l’hypermédia devient le moteur d’état de l’application, c’est-à-dire que le rôle du serveur n’est pas juste de nous renvoyer une représentation de la donnée, mais également de nous indiquer comment on peut interagir avec et à quoi elle est liée.

L’hypermédia comme moteur d’état de l’application

REST n’impose pas de format de réponse : tout est permis. Mais avouons-le : c’est quand même assez étrange de représenter des hyperliens en JSON…

Alors peut-être qu’il est temps de se souvenir du hypertext dans le terme Hypertext Transfer Protocol.

REST n’impose pas de format de réponse, mais il est pensé pour le Web, et le Web est fait d’hypertexte.

Tu n’y penses pas ?! C’est vraiment très important d’avoir une API qui répond en JSON et une application JavaScript qui fait des requêtes au serveur pour construire l’interface à partir du JSON !

Vraiment ? Et qu’est-ce qu’on y gagne, en fait ?

En tant que développeurs Web, nous travaillons sur la partie la plus relativement simple et facile du spectre du génie logiciel. Et pourtant on a passé les dernières années à se compliquer la vie avec des concepts sortis de nul part, alors que nous n’avions qu’à suivre les recommandations des fondateurs dudit Web.

C’est à croire que le développeur Web s’invente des problèmes car il n’en a pas assez.

Il va sans dire que les développeurs de kernels n’ont pas les mêmes débats.

Ils n’ont pas forcément les débats les plus civilisés par contre

Comment mettre en place une architecture REST aujourd’hui ?

Pour appliquer REST, vous avez principalement besoin d’une seule chose : un serveur web qui répond du HTML par défaut.

Et en faisant cela, vous simplifiez déjà grandement l’architecture logicielle de votre solution. Il n’y a qu’un seul point d’entrée : le serveur.

Vous n’avez pas besoin d’avoir une application React/Svelte/Vue en plus. Le navigateur internet suffit pour utiliser l’API.

Et si vraiment vous tenez à avoir une application JavaScript, elle n’a pas besoin d’intégrer de la logique métier en plus. Seulement d’afficher ce que le serveur lui dit d’afficher.

Quels outils ?

L’avantage du vrai REST, c’est que vous n’avez pas besoin de toucher à JavaScript si vous ne le voulez pas.

Vous pouvez utiliser n’importe quel langage et n’importe quelle technologie, à condition que vous puissiez faire un serveur web avec.

Côté frontend, je vous suggère d’intégrer les librairies HTMX et AlpineJS, qui permettent respectivement d’ajouter du contenu dynamique et de la gestion d’états sans avoir à écrire une seule ligne de JavaScript.

« vous devriez utiliser de l’hypermédia, les gars »

Toutefois, si vous aimez TypeScript, je vous conseille Astro : un framework permettant de créer des sites statiques et de faire du rendu côté serveur. Contrairement à une application React qui est exécutée sur le navigateur, Astro renvoie du HTML prêt à l’emploi au navigateur.

De plus, Astro permet aussi d’intégrer des composants de frameworks frontend, tels que React, Vue, et Svelte, si pour une raison ou pour une autre cela s’avérait nécessaire pour votre projet.

« Mais j’ai besoin que des clients tiers puissent utiliser mon API ! »

Ce n’est pas un problème.

Deux choix s’offrent à vous :

  1. Si le client tiers est capable d’interpréter du HTML, il peut directement afficher la réponse du serveur
  2. Sinon, renvoyez une représentation de la donnée dans un format plus adapté

Dans un système REST, la réponse par défaut devrait être de l’hypertexte, mais rien n’empêche d’ajouter d’autres formats comme le JSON, XML, CSV.

C’est ce que fait l’API MediaWiki qui permet d’interroger Wikipédia : dans l’URL vous pouvez spécifier un paramètre `format=json` qui changera le format de la réponse.

Vous pouvez également accomplir quelque chose de similaire avec un `.json` en fin d’URL, ce qui à titre personnel me paraît un peu plus joli.

Ma règle générale serait de créer d’abord la version HTML de la page, puis éventuellement une version JSON qui sera toujours basée sur la version hypertexte.

Par exemple, si la version HTML de votre page présente un hyperlien, la version JSON pourrait contenir la paire clé-valeur suivante :

{
  "link": {
    "label": "Mon lien",
    "method": "GET",
    "href": "/foo.json"
  }
}

Malheureusement, il n’existe pas de standard clairement établi pour représenter l’hypermédia en JSON, mais l’important ici est de faire en sorte de fournir un document le plus auto-descriptif possible.

Le client doit être capable d’interpréter la réponse du serveur sans connaissance préalable – autre que la façon dont l’hypermédia est représenté – et sans intégrer de la logique métier.

Exemple d’une ressource représentée sous différents formats

Soit la réponse hypertexte de la ressource `/users/john-doe` :

/users/john-doe

On pourrait imaginer une version JSON de cette même ressource à une adresse `/users/john-doe.json` comme suit :

/users/john-doe.json

Certes la réponse est un peu plus verbeuse que dans une API JSON plus « classique », mais le client qui recevra cette réponse saura que la ressource utilisateur « John Doe » est liée à la ressource société « Acme » qui peut être consultée à l’adresse `/companies/acme`.

Et si le client accédant à la page de John Doe n’est pas autorisé à consulter la page d’Acme, on pourra toujours remplacer l’objet `Link` par un objet `Text` pour le lui faire comprendre.

Exemple n° 2 : représenter des actions pouvant être effectuées sur une ressource

Soit la réponse hypertexte du serveur pour la ressource société « Acme » :

/companies/acme

Contrairement à l’exemple précédent, ici nous avons des textes, un lien vers une autre ressource, mais également des actions qui peuvent être effectuées sur Acme : Modifier, Gérer les employés, et Supprimer la société.

Nous pourrions essayer de représenter cette réponse en JSON de la manière suivante :

/companies/acme.json

En résumé

Les grands principes de REST

  • La logique métier se trouve exclusivement sur le serveur.
  • Le serveur doit donner des réponses auto-descriptives que le client peut interpréter sans connaissance préalable.
  • Les différentes ressources et actions proposées par le serveur sont reliées entre-elles — et reliées au reste du Web — au sein d’une toile de liens et de redirections. (L’hypermédia est le moteur d’état de l’application)

Les avantages de REST

  • Une architecture simplifiée : votre frontend et votre backend sont gérés au même endroit. Un seul point d’entrée, une seule application à maintenir.
  • Pas de désynchronisations frontend–backend : si le serveur a la main-mise sur la logique métier, le frontend ne peut plus faire des suppositions erronées sur les entrées-sorties du serveur
  • Une vraie séparation des responsabilités : certaines actions comme le client-side-routing ne sont plus gérés en JavaScript, mais par le navigateur qui est là pour ça.
  • Un versionnage simplifié : une API REST n’est pas versionnée à proprement parler, elle évolue. Le serveur renvoie une représentation hypermédia de la donnée et non la donnée en tant que tel, cela signifie que cette représentation peut évoluer pour intégrer de nouvelles composantes, et que les formats de données en interne peuvent changer sans impacter la représentation.
  • Une architecture plus sécurisée : en prenant le temps de travailler les représentations de vos ressources pour n’inclure que le strict nécessaire, vous réduisez le risque d’exposer de la logique interne qui pourrait être exploitée par des acteurs malveillants.
  • Des meilleures performances par rapport à une application JavaScript qui serait exécutée par le navigateur.
  • Une API auto-documentée : les réponses étant compréhensibles sans connaissance préalable, un tiers peut utiliser votre API sans avoir à en comprendre tous les tenants et aboutissants, même si une documentation minimale restera nécessaire pour expliquer les modalités d’accès.
  • Un Web plus cohérent : vous développez un maillon dans un système documentaire international basé sur une philosophie spécifique, et vous respectez cette philosophie. C’est cette philosophie qui nous permettra à l’avenir de bâtir des communs numériques où chaque acteur pourra mettre son expertise à la disposition des autres au sein d’un grand système documentaire commun.

That’s all Folks!

Si cet article vous a donné envie d’appliquer REST correctement, je ne peux que vous conseiller de commencer à expérimenter et à approfondir vos connaissances du sujet (les liens en bas sont un bon point de départ).

Ne foncez pas tête baissée non plus. Malgré tout ce qui a été dit ici, une API RPC peut être pertinente. Cela dépend de votre projet. Il s’agit avant tout de rester pragmatique.

Souvenez-vous d’une chose : il n’existe pas de baguette magique.

« M’ouais, mais je suis toujours pas convaincu »

Cela demande un certain temps de se désintoxiquer des fameuses « bonnes pratiques » que l’industrie a érigé en baguettes magiques ces dix dernières années.

Cela m’a pris aussi quelques mois, mais à force de chercher et d’expérimenter, j’ai fini par comprendre.

Peut-être que cet article n’aura pas achevé de vous convaincre, mais au minimum il aura permis de planter une graine dans votre esprit.

Peut-être que dorénavant vous allez vous mettre à grincer des dents quand quelqu’un dira que votre serveur web qui retourne du JSON est une « API REST ».

Peut-être qu’un jour vous aurez un problème avec votre serveur et votre application React, et vous vous direz que tout ceci pourrait être plus simple.

Peut-être même que vous vous direz que ça ne peut pas être comme ça que le Web a été imaginé à la base.

HTML suffit

Pour aller plus loin

Hypermédia (article) : https://fr.wikipedia.org/wiki/Hyperm%C3%A9dia

Hyperlien (article) : https://fr.wikipedia.org/wiki/Hyperlien

Representational state transfer (article) : https://fr.wikipedia.org/wiki/Representational_state_transfer

HATEOAS (essai) : https://htmx.org/essays/hateoas/

How Did REST Come To Mean The Opposite of REST? (essai) : https://htmx.org/essays/how-did-rest-come-to-mean-the-opposite-of-rest/

A Response To « Have Single-Page Apps Ruined the Web? » (essai) : https://htmx.org/essays/a-response-to-rich-harris/

Hypermedia Systems (livre) : https://hypermedia.systems/

Ne vendons pas la peau de l’IA avant de l’avoir inventée

Le 26 mars 2023, Léo Duff publiait une vidéo intitulée « Et si l’intelligence artificielle…nous avait inventés ?« .

C’est une vidéo qui s’inscrit de manière très pertinente dans le contexte actuel, la nouvelle tendance tech étant centrée sur les IA grand public et leur évolution aussi rapide qu’impressionnante.

Sa vision atypique de la tech couplée à la qualité de ses analyses donne un mélange qui sonne souvent juste.

Il mène au cours de celle-ci une réflexion très intéressante sur notre rapport à l’IA et à notre propre intelligence.

Il me semblait donc pertinent de revenir sur certains points, pour y apporter une contradiction, ou approfondir.

AlphaGo, créative ?

« Lorsqu’elle place le coup 37, elle sait que les chances qu’un humain tente ce coup sont de 1 sur 10 000. Mais elle le fait quand même. Elle a agi au-delà de ce qu’on lui a enseigné. Au point où c’est elle qui nous a donné une leçon. »

Et si l’intelligence artificielle…nous avait inventés ?, Léo Duff

La vidéo prend pour point de départ la victoire de l’intelligence artificielle AlphaGo sur l’ex-champion du monde de Go, Lee Sedol.

Durant la 2e manche l’opposant à Sedol, AlphaGo a joué un coup improbable qui finira plusieurs tours plus tard par retourner le match en sa faveur.

Lee Sedol expliquera plus tard que c’est à ce moment là qu’il a compris que l’intelligence artificielle était capable de faire preuve de créativité, et Léo vient appuyer ces propos dans sa vidéo en expliquant qu’AlphaGo avait joué ce coup en dépit de la faible probabilité qu’un humain ne le joue.

Le problème, c’est que ça ne marche pas tout à fait comme ça.

L’apprentissage d’AlphaGo s’est fait en deux temps, chacun employant une méthode différente :

  1. Apprentissage supervisé : AlphaGo a analysé des dizaines de milliers de parties, toutes jouées par des humains, afin de déterminer quels coups avaient le plus de chance de mener à la victoire dans une situation donnée.
  2. Apprentissage par renforcement : on a fait jouer AlphaGo contre des instances d’elle-même avant de lui faire analyser ces parties, afin de lui permettre d’affiner son modèle en fonction des situations de jeu.

AlphaGo n’a pas été entraîné pour trouver les coups les plus joués par les humains, mais pour trouver les coups ayant le plus de chances d’amener à la victoire.

Au jeu de Go, un coup à l’épaule (ou Katatsuki) consiste à juxtaposer diagonalement une de ses pierres à une de celles de l’adversaire.

C’est une stratégie considérée comme risquée, car bien qu’elle permette de préparer le terrain pour une future offensive, elle ouvre néanmoins des failles dans la défense du joueur.

AlphaGo n’a pas véritablement fait preuve de créativité : après avoir analysé des dizaines de milliers de parties, elle est simplement arrivée à la conclusion que les joueurs humains qui sortaient victorieux de la situation dans laquelle elle se trouvait étaient ceux favorisant la prise de risque du katatsuki.

Peut-être que le coup avait bel et bien 0,01 % de chances d’être joué par un humain, mais il s’agissait bien du coup qui avait statistiquement le plus de chances de la mener à la victoire.

Si AlphaGo pensait cela, c’était parce qu’elle avait « vu » des humains l’utiliser, et gagner.

Toute chose remise dans son contexte, le « coup 37 » était bel et bien surprenant.

Non pas car il était créatif et innovant, mais parce qu’il a brisé une idée pré-conçue que les joueurs de Go tenaient pour vraie.

Celle que le katatsuki était trop risqué pour pouvoir être utilisé dans cette situation, en particulier lors d’une compétition.

Je crois fermement que l’intelligence artificielle n’est pas capable de faire preuve de créativité, ou du moins pas encore.

Cependant, en analysant des données dont nous faisons nous-même abstraction, elle est capable de mettre en lumière des vérités que nous avons occulté.

C’est la raison pour laquelle on a constaté une amélioration de la prise de décisions chez les joueurs de Go depuis l’arrivée d’AlphaGo.

AlphaGo n’est pas allée au-delà de ce qu’on lui a appris. Elle n’a fait que nous rappeler avec quoi nous l’avons nourrie.

L’intelligence humaine

« Ce n’est pas seulement des calculs, c’est de l’inspiration, de la créativité, de l’intelligence pure. Cela nous pose un énorme problème d’identité. »

Et si l’intelligence artificielle…nous avait inventés ?, Léo Duff

Qu’est-ce qui fait que nous sommes humains ?

De nombreux philosophes se posent la question depuis maintenant des milliers d’années, mais à une heure où nous nous sentons de plus en plus remplaçables par nos propres machines, elle semble revêtir une importance nouvelle.

Comme le souligne justement Léo Duff dans sa vidéo : l’humanité se définit elle-même par son intelligence, mais sans définition universelle de l’intelligence, elle se définit par un concept qu’elle n’est pas sûre de comprendre.

Là où il manque cruellement de nuance, c’est qu’il oublie de distinguer l’intelligence de l’intelligence humaine.

Si AlphaGo peut être considéré comme intelligente du fait de sa capacité à résoudre des problèmes, on ne peut pas pour autant considérer qu’elle possède une intelligence humaine.

De tous les traits qu’il évoque pour parler de notre intelligence, presque aucun n’est réellement propre à l’être humain.

  • Des animaux tels que les primates sont capables d’apprendre à se servir d’outils.
  • Des modèles mathématiques sont capables de résoudre des problèmes.
  • Presque tous les animaux possèdent un moyen de communiquer avec les autres individus de leur espèce, et c’est également le cas de certains végétaux.

Ce qui nous distingue de l’animal, ce n’est pas le concept de l’intelligence. C’est autre chose.

La question de la créativité

« La créativité, c’est l’intelligence qui s’amuse. »

Albert Einstein

En prenant la définition la plus simple possible de la créativité, peut-être qu’il est possible d’affirmer de manière très discutable que l’intelligence artificielle est déjà capable d’en faire preuve.

En revanche, essayer d’étoffer la définition ne fera que nous éloigner de cette thèse.

L’intelligence artificielle n’est pas encore capable de créer, car elle est incapable de comprendre les concepts qu’on lui transmet.

Elle n’a, pour ainsi dire, pas de culture.

Quand AlphaGo joue au jeu de Go, elle ne comprend pas ce qu’est le Go. Elle ne comprend même pas ce qu’est un jeu.

Tout ce qu’elle sait, c’est que pour une donnée d’entrée, elle est récompensée si elle retourne une donnée de sortie satisfaisante.

Et en le tournant en ces termes, on est déjà en train de personnifier une ligne de code dans un programme.

AlphaGo n’a pas de motivation intrinsèque à jouer au jeu. Elle ne peut ni le trouver intellectuellement stimulant, ni particulièrement agréable.

Sa recherche de récompenses est codée en dur dans son programme. On ne peut donc même pas parler de motivation extrinsèque.

Elle n’a pas de motivation, elle est simplement obligée de se comporter ainsi.

En d’autres termes, elle n’a pas de volonté propre.

Lorsque nous sommes mis dans des états de privations avancés, il devient extrêmement difficile, pour ne pas dire impossible, de résister aux pulsions de faim et de soif.

« La seule barrière entre nous et l’anarchie, ce sont nos neuf derniers repas. »

Alfred Henry Lewis

En revanche, je suis tout à fait capable de m’empêcher d’aller scroller sur TikTok pendant 3 heures, bien que cette activité soit récompensée par mon cerveau via la sécrétion de dopamine.

Je suis configuré pour assurer ma propre survie, mais tout ce qui n’y est pas directement lié dépend, au moins en partie, de ma propre volonté.

Il n’y a pas d’IA créative

L’une des définitions possibles de la créativité que donne Wikipédia est la suivante :

L’acte créatif peut être considéré comme le fruit d’une volonté de puiser quelques informations provenant de la mémoire (logique ou irrationnelle) et de les réorganiser d’une manière nouvelle, poussée par l’imagination, l’instinct, l’inspiration, les émotions fortes…

Créativité, Wikipédia

Sans culture, sans volonté, et sans aucune capacité à ressentir des émotions, l’intelligence artificielle est en réalité incapable d’être créative.

À mon sens, la créativité en elle-même est une capacité propre à l’intelligence humaine.

Cela ne signifie pas qu’on ne rendra jamais l’intelligence artificielle créative, seulement que le faire nécessiterait de lui permettre de vivre une expérience profondément humaine.

Quid des IA génératives ?

Image générée par Dall-e représentant une main luminescente approchant une lumière rouge

Ainsi, ChatGPT, MidJourney, StableDiffusion ne seraient pas créatives ?

Ma réponse, c’est que non, elles ne le sont pas.

Auriez-vous oublié que ces intelligences artificielles n’attendent spécifiquement que vos instructions pour se mettre en marche ?

Elles ne font rien d’elles-mêmes, elles attendent vos idées.

Si le succès dépend de l’exécution, la créativité, quant à elle, réside dans l’idée.

L’intelligence artificielle a remplacé le pinceau, mais elle n’a aucunement remplacé l’artiste.

« ChatGPT et les technologies similaires sont des applications de complétion de texte. Rien de plus, rien de moins. Leurs réponses étonnantes sont la démonstration de la prévisibilité des humains, à condition qu’elles aient assez de données sur notre façon de communiquer. »

AI isn’t close to becoming sentient — the real danger lies in how easily we’re prone to anthropomorphize it, The Conversation U.S.

MidJourney a beau être capable de générer des rendus incroyablement détaillés, sans une prompt réfléchie à laquelle on aurait insufflé une culture et des émotions, l’image ne transmettra absolument rien.

Ceux qui se sentent menacés par MidJourney sont ceux qui se définissent par leur technique plutôt que par leur imagination.

Pendant ce temps, les personnes à la technique faible mais à l’imagination débordante n’ont jamais été aussi prolifiques que depuis que ces IA leurs sont devenues accessibles.

L’IA générative est un outil, pas un cerveau.

Entre science et philosophie

« La définition de l’intelligence, comment elle se produit, comment elle se mesure, tout cela varie selon les cultures, les sciences, les philosophies et les croyances. »

Et si l’intelligence artificielle…nous avait inventés ?, Léo Duff

Pour parler de l’intelligence, Léo Duff se réfère à deux courants de pensée : le physicalisme, et le dualisme.

Pour faire simple :

  • Le physicalisme part du principe que tout ce qui existe est physique ou matériel. Chaque chose dans l’univers serait ainsi modélisable par la physique, y compris la vie et l’intelligence.
  • Le dualisme oppose le matériel et le spirituel, deux entités opposées qui constitueraient une seule unité : notre univers. Nos émotions et nos pensées existeraient ainsi sur un plan de l’existence qui nous serait alors inaccessible.

Ce qui est intéressant ici, c’est que le physicalisme nous dit que notre intelligence n’est que le fruit d’une machine biologique extrêmement complexe.

Nous pouvons donc essayer de la comprendre et de la répliquer.

En revanche, le dualisme nous explique que notre intelligence appartient à un domaine qui nous est hors de portée, et par conséquent nous ne pourrons jamais la comprendre

Ainsi, selon qu’une philosophie ou l’autre se révèle vraie, la finalité de la course à l’IA connaîtra une fin bien différente.

Dans un cas, on arrivera un jour ou l’autre à insuffler l’intelligence humaine à une de nos créations.

Dans l’autre, seul un être divin serait capable de réaliser cet exploit.

Ce qui nous différencie des machines

« Pour faire simple, nous ne sommes rien de plus que des amas de produits chimiques et d’impulsions électriques. »

Et si l’intelligence artificielle…nous avait inventés ?, Léo Duff

Si le physicalisme finit par l’emporter, qu’est-ce que cela impliquerait pour nous ?

Si notre cerveau peut être répliqué pour créer des machines, alors nous sommes nous-même des machines.

C’est en réponse à cette problématique-là que Léo Duff introduit dans sa vidéo le sujet de la conscience.

Contrairement aux machines, nous sommes conscients.

Conscients du monde qui nous entoure, mais surtout conscients de nous-même.

Sauf que, se référant à des travaux de recherche récents, Léo explique que cette conscience de soi pourrait être une illusion.

Et là, j’ai du mal à voir où il veut en venir.

La conscience est-elle une illusion ?

« Le cerveau est une incroyable machine qui orchestre notre perception du monde pour créer un spectacle captivant. Mais si c’est lui qui l’orchestre, ce « moi » n’est qu’une illusion. »

Et si l’intelligence artificielle…nous avait inventés ?, Léo Duff

Que veut-il dire par « illusion » ?

En quoi le fait que notre cerveau organise notre perception du monde ferait de notre conscience une illusion ?

Tout cela est pourtant bien réel : nous voyons, entendons, pensons et ressentons.

Les images que nous voyons et les sons que nous entendons ne sont certes que des interprétations que notre cerveau construit à partir des informations qu’il reçoit, mais cela ne change rien.

Si notre cerveau traite pour nous la plupart des informations qu’il reçoit sans pour autant nous les faire parvenir, cela ne veut pas dire que tout est faux pour autant.

C’est justement cette séparation entre les automatismes de notre cerveau et nos pensées qui rend la conscience bien réelle.

C’est là tout le sens métaphysique de la locution « Cogito ergo sum » / « Je pense, donc je suis » : la seule certitude du sujet pensant, c’est celle de sa propre existence.

Descartes était pour le coup dualiste, mais cette locution conserve son sens même dans un contexte physicaliste.

Ayant besoin d’exister pour douter, nous ne pouvons pas raisonnablement douter de notre propre existence, et par extension de l’existence de notre conscience.

J’imagine qu’il cherche à dire que la conscience n’est pas une entité distincte, seulement un produit de notre cerveau.

Cependant, je trouve ce choix de mot étrange, au vu des implications que l’on peut mettre derrière.

D’où vient la conscience ?

Image générée par Dall-e représentant un crâne émettant de la lumière depuis l'intérieur

Dans sa vidéo, Léo semble relier l’intelligence humaine à l’expérience consciente.

Comme évoqué plus tôt, je suis d’accord avec cette proposition.

Je suis persuadé que pour donner une intelligence humaine à une machine, il faut lui permettre de vivre une expérience profondément humaine.

En revanche, cela pose des questions aussi bien sur le plan biologique que philosophique.

Comment fait-on apparaître la conscience ?

Actuellement, la communauté scientifique étudie plusieurs possibilités.

J’ai décidé d’en évoquer ici deux pour lesquelles les implications sur le domaine de l’intelligence artificielle sont assez intéressantes.

La théorie de l’information intégrée

Selon cette première théorie, la conscience serait définie par la capacité d’un système à intégrer de l’information.

Tout système traitant de l’information aurait un certain degré de conscience.

Ainsi, plus un système serait capable d’intégrer et de traiter efficacement l’information, plus il serait conscient.

Ce ne résout pas forcément le problème du « pourquoi », mais cela expliquerait au moins le « comment ».

La différence entre les expériences conscientes humaines et animales serait donc simplement due à la meilleure capacité du cerveau humain à traiter l’information.

En extrapolant un peu, on peut supposer qu’une intelligence artificielle consciente, ça ne serait rien de plus qu’une IA possédant une grande capacité à traiter des informations variées.

Ainsi, une potentielle Intelligence Artificielle Générale serait, par nature, consciente.

Conscience et mécanique quantique

Notez qu’on ne parlera pas ici du mysticisme quantique, mais bel et bien de théories évoquées par des physiciens.

En revanche, celles-ci n’ont jamais été prouvées, elles ne constituent donc pas une connaissance.

Elles sont d’ailleurs vivement critiquées par une partie de la communauté scientifique, les phénomènes quantiques étant censés relever du domaine sub-atomique, et non de structures aussi grosses que le cerveau.

Nous sommes donc plus dans de la philosophie que dans la physique, mais ce sont à mon sens des hypothèses intéressantes à considérer dans le cadre de notre raisonnement.

Selon l’hypothèse de l’esprit quantique, le fonctionnement du cerveau impliquerait des phénomènes de superpositions d’états et d’intrications qui expliqueraient l’apparition de la conscience.

Pour faire simple, la conscience serait ainsi générée par la matière, suivant une certaine configuration.

Cette propriété de la matière étant intrinsèquement liée à la mécanique quantique, cela expliquerait pourquoi nous sommes incapables de la simuler avec notre informatique actuelle.

Si cette théorie devait se vérifier, cela aurait une implication assez importante quant à notre capacité à reproduire notre propre intelligence.

Cela nécessiterait alors de faire usage des capacités propres aux ordinateurs quantiques.

Ce qui est intéressant avec cette théorie, c’est qu’elle permet de libérer la conscience du déterminisme de la physique classique.

Elle expliquerait également la persistance de la conscience malgré des phénomènes biologiques tels que le renouvellement des cellules du corps, car bien que restant physicaliste dans l’idée, on peut tout de même la rapprocher d’une certaine forme de dualisme.

Synthèse

D’après ces hypothèses, il serait tout à fait possible de recréer notre conscience.

Ce qui changerait, ça serait la difficulté de la manœuvre.

Dans un cas, le simple fait de construire un système capable de traiter des informations variées de manière très efficace suffirait à faire apparaître la conscience.

Dans l’autre, il nous faudrait pouvoir définir le rôle de phénomènes complexes qu’on ne maîtrise pas encore dans l’apparition de la conscience, et faire un plein usage des capacités uniques des ordinateurs quantiques.

La singularité et l’ère post-AGI

« La singularité technologique (ou simplement la Singularité) est l’hypothèse selon laquelle l’invention de l’intelligence artificielle déclencherait un emballement de la croissance technologique qui induirait des changements imprévisibles dans la société humaine. »

Singularité technologique, Wikipédia

L’innovation technologique est exponentielle.

Plus on crée de technologies, plus on a de technologies permettant d’en créer des nouvelles.

Ainsi, tout va toujours de plus en plus vite.

La singularité technologique, c’est en fin de compte l’apparition d’une Intelligence Artificielle Générale (AGI) capable de reproduire l’intelligence humaine, et par conséquent pouvant faire preuve de créativité.

En d’autres termes : une technologie pouvant créer d’autres technologies.

Et effectivement, cela risque de nous poser un énorme problème d’identité.

C’est là-dessus que je rejoins complètement Léo : « On verra peut-être plus de changements dans les 50 prochaines années que dans les 5 000 dernières. Le plus grand défi de l’intelligence artificielle, ce n’est pas de parvenir à définir ce qu’elle est, mais d’enfin comprendre qui nous sommes. Nous devons répondre aux questions existentielles sur notre propre intelligence, notre éthique, la raison de notre existence, pour préparer le futur potentiel dans lequel nous devrons transmettre ces règles à une nouvelle intelligence avant qu’elle nous dépasse. »

Conclusion

Là où Léo Duff fait, à mon, sens une erreur de raisonnement, c’est qu’il considère que l’intelligence artificielle fait d’ores et déjà preuve de créativité.

Au contraire, je pense que la créativité est encore une capacité propre à l’intelligence humaine.

Ainsi, le seul moyen d’obtenir une IA créative serait de lui conférer une intelligence humaine, et cela impliquerait de lui faire vivre, de manière intentionnelle ou non, une expérience consciente.

J’ai choisi de ne pas évoquer les implications morales et éthiques d’un tel acte.

Pour être honnête, je n’ai pas encore de réponse à apporter, et c’est à mon sens un sujet qui mérite d’être traité en profondeur.

Évitons de personnifier les machines

Il me semble contre-productif de considérer que l’IA peut être créative, en partie car cela contribue à la personnifier.

Il n’y a, à ce jour, aucune bonne raison de croire qu’il existe une IA consciente quelque part.

Tout ce que nous faisons pour l’instant, c’est nous projeter sur des boîtes qui font des statistiques et des probabilités.

Nous y voyons des signes d’humanité car elles sont devenues très performantes sur des tâches que nous étions jusqu’alors les seuls à pouvoir accomplir.

Seulement, ce ne sont que des boîtes qui font des statistiques et des probabilités.

En tant qu’humains, nous sommes psychologiquement prédisposés à anthropomorphiser notre environnement, mais cela ne doit pas nous empêcher de voir les choses pour ce qu’elles sont.

Un monde où une majorité de personnes seraient sincèrement persuadées que ChatGPT pourrait envahir le monde, ce serait aussi un monde où on établirait un degré d’innovation inacceptable.

Cela mettrait bien sûr en danger notre niveau de connaissances, mais il me semble aussi que cela pourrait mettre en péril notre futur en tant qu’espèce.

Une humanité qui mettrait un coup de frein à sa capacité d’innovation, ça serait également une humanité qui stagnerait et qui se rendrait incapable de surmonter ses plus gros obstacles.

Pour aller plus loin

Et si l’intelligence artificielle…nous avait inventés ? : https://www.youtube.com/watch?v=VeeBT5Bhyno

AlphaGo, dissection d’une évolution : https://datalchemy.net/blog/alphago

AlphaGo vs Lee Sedol: Post Match Commentaries : https://www.alexirpan.com/2016/03/17/alphago-lsd.html

Créativité : https://fr.wikipedia.org/wiki/Cr%C3%A9ativit%C3%A9

AI isn’t close to becoming sentient – the real danger lies in how easily we’re prone to anthropomorphize it : https://medium.com/@ConversationUS/ai-isnt-close-to-becoming-sentient-the-real-danger-lies-in-how-easily-we-re-prone-to-b767c96552a2

Conscience (biologie) : https://fr.wikipedia.org/wiki/Conscience_(biologie)

Pourquoi avons-nous développé une conscience ? : https://www.youtube.com/watch?v=VeoHfFTaaBw

Le Discours de la Méthode : Pourquoi Descartes Gifle les Zététiciens ? La page 99 de Gontran H #21 : https://www.youtube.com/watch?v=TDDB0YpF3FI

Qualité logicielle et architecture

Pour lire d’autres articles sur le développement logiciel, cliquez ici.

Quand on parle de logiciel, l’architecture est ce qui définit l’organisation, les dépendances, et l’interopérabilité entre les différents éléments composant un système.

Une bonne architecture logicielle permet de garder la solution stable et d’éviter la production de dette technique.

L’impact de l’architecture sur la qualité

La qualité d’un logiciel et son architecture sont deux choses fortement corrélées.

L’architecture étant la fondation sur laquelle on va développer le produit, les choix de conception préliminaires ne peuvent que fortement impacter sa qualité finale.

Le principe d’entropie logicielle

Quand un système est modifié, sa désorganisation, ou entropie, augmente systématiquement.

Ivar Jacobson

Selon le principe d’entropie logicielle, la dette technique d’un système ne fait qu’augmenter dans le temps, au fur et à mesure qu’il se complexifie.

Sans aucune contre-mesure, cette dette technique implique une augmentation des coûts de production et de maintenance liée à 3 facteurs :

  • Perte de productivité des développeurs, à cause d’un code source de mauvaise qualité
  • Perte de temps, à cause de corrections de bugs intempestives et nécessaires
  • Perte de maintenabilité, le logiciel ne peut plus être modifié sans entraîner des effets de bord

Érosion de l’architecture logicielle

Commentaire de code disant "vous pourriez penser que cette fonction est obsolète, et ne semble rien faire du tout. et vous auriez raison. mais quand on retire cette fonction, pour une raison ou une autre le programme entier plante et on n'arrive pas à comprendre pourquoi, donc elle restera ici."
« vous pourriez penser que cette fonction est obsolète, et ne semble rien faire du tout. et vous auriez raison. mais quand on retire cette fonction, pour une raison ou une autre le programme entier plante et on n’arrive pas à comprendre pourquoi, donc elle restera ici. »

Dans le cas où l’équipe de développement ne prendrait pas en compte l’entropie logicielle, l’architecture du système s’érode jusqu’à pourrir (software rot).

Cette souillure du système a pour conséquence de rendre ce dernier impossible à maintenir à cause des effets de bord et de leurs coûts.

Le problème de l’érosion, c’est qu’elle se propage dans le code source de manière exponentielle.

Il s’agit de l’hypothèse de la vitre brisée : de la même manière qu’une simple vitre brisée peut encourager des délinquants à vandaliser tout un quartier, la simple présence de code de mauvaise qualité incitera le développeur à écrire à son tour du code de mauvaise qualité.

Au contraire, si le développeur rencontre du code source de bonne qualité, alors il aura tendance à essayer de le laisser dans un état au moins aussi bon que celui dans lequel il l’a trouvé.

Ainsi, procéder à du refactoring lorsque l’on trouve du code inutilement complexe, répétitif, ou mal découpé permet de réduire la dette technique tout au long du développement et donc de réduire considérablement le risque d’érosion.

Seulement, mettre en place ces bonnes pratiques ne suffit pas réduire de manière durable le taux de défaillance du logiciel.

Sans une bonne architecture, le système aura de plus en plus de mal à accueillir le changement sans introduire des effets indésirables.

La norme ISO 25010

Visuel représentant les critères de la qualité logicielle selon la norme ISO 25010 : -Capacité fonctionnelle -Fiabilité -Efficacité -Convivialité -Sécurité -Compatibilité -Maintenabilité -Portabilité

Ayant pour objectif de standardiser les spécifications et l’évaluation de la qualité logicielle, la norme ISO 25010 définit 8 critères de qualité des produits logiciels :

  • La capacité fonctionnelle
  • La fiabilité
  • L’efficacité
  • La convivialité
  • La sécurité
  • La compatibilité
  • La maintenabilité
  • La portabilité

Voyons à quoi ils correspondent dans le détail :

Capacité fonctionnelle

Le produit doit répondre aux besoins des utilisateurs de manière :

  • Complète : le produit possède toutes les fonctions dont il a besoin.
  • Correcte : le produit délivre des résultats corrects avec le degré de précision approprié.
  • Appropriée : les différentes fonctions accomplissent les tâches comme attendu.

Fiabilité

Le produit doit être :

  • Mature : correspond aux attentes des utilisateurs en matière de fiabilité.
  • Disponible : le produit est en service et accessible.
  • Résilient : le système est capable d’opérer malgré la présence de fautes techniques
  • Récupérable : le système est capable de récupérer ses données après une interruption de service.

Efficacité

Le produit doit être économe en :

  • Temps
  • Ressources
  • Capacité

Convivialité

Le produit doit être facile à utiliser. On évalue cette facilité d’utilisation grâce aux critères suivants :

  • Pertinence reconnaissable : il est facile de savoir si le produit peut répondre à un certain besoin ou non.
  • Apprentissage : il est facile d’apprendre à utiliser le produit.
  • Opérabilité : le produit est facile à utiliser.
  • Protection contre les erreurs : le système est capable de protéger les utilisateurs de leurs propres erreurs.
  • Esthétique : l’interface utilisateur est plaisante.
  • Accessibilité : le produit peut être utilisé par le plus grand nombre.

Sécurité

Le système doit pouvoir empêcher des personnes non-autorisées ou mal-intentionnées d’accéder aux données.

La sécurité d’un système peut être évaluée selon ces 5 principes :

  • Confidentialité : le système est capable d’assurer que les données ne sont accessibles qu’aux personnes autorisées.
  • Intégrité : le système est capable d’empêcher l’altération des programmes et des données par des personnes non-autorisées.
  • Non-répudiation : les actions et les événements sont enregistrées par le système.
  • Responsabilité : les actions d’un utilisateur non-autorisé peuvent remonter jusqu’à lui.
  • Authenticité : l’identité des ressources peut être prouvé

Compatibilité

La compatibilité d’un produit est définie par deux principes :

  • Co-existence : le produit est capable d’opérer de façon efficace dans un environnement partagé avec d’autres produits.
  • Interopérabilité : le système est capable d’échanger des informations avec des systèmes ou des produits tiers.

Maintenabilité

Pour être facilement maintenable, le système doit être :

  • Modulaire : il est possible de modifier ou de remplacer un composant du système sans trop impacter les autres composants.
  • Réutilisable : les composants du système peuvent être utilisés pour d’autres systèmes.
  • Analysable : il est possible d’évaluer les impacts d’un changement dans le système de manière préliminaire et fiable et d’identifier facilement les causes des déficiences.
  • Modifiable : le système peut être modifié sans dégrader la qualité.
  • Testable : le système possède des procédures de tests pertinentes.

Portabilité

Pour pouvoir être « portable », et donc être transféré aisément d’un environnement à un autre, un logiciel doit être :

  • Adaptable : le système est capable de s’adapter à l’évolution de son environnement.
  • Installable : le système peut facilement être installé et désinstallé.
  • Remplaçable : le produit peut remplacer un produit similaire de manière efficace et pertinente.

L’architecture monolithique

Visuel représentant l'architecture monolithique. Le client communique avec le monolithe. Ce dernier contient 4 composants principaux : -Une couche de présentation -La logique métier -La couche d'accès aux données -Une base de données

L’un des critères de qualité d’un logiciel est sa portabilité.

Pendant longtemps, le meilleur moyen de rendre un système portable était d’inclure absolument tous ses composants dans un unique exécutable, un monolithe.

Ne nécessitant aucune dépendance, le monolithe était ainsi prêt à l’emploi, et n’avait plus qu’à être lancé sur un serveur correctement configuré.

Un monolithe se compose généralement des couches suivantes :

  • Base de données
  • Accès aux données : le lien entre la base de données et le reste de l’application
  • Logique métier : la logique programmatique liée aux fonctionnalités de l’application
  • Présentation : la couche gérant les interactions entre l’utilisateur et le système

La problématique du scaling

La scalabilité, c’est la capacité d’un système à grandir ou à rapetisser en fonction de l’évolution de la demande.

On distingue 2 types de scaling :

  • Le scaling vertical, qui consiste à augmenter physiquement les capacités du serveur pour qu’il puisse accepter une charge plus importante
  • Le scaling horizontal, qui consiste à lancer d’autres instances du système sur d’autres serveurs afin de répartir la charge entre-eux

Contrairement à ce que certains pensent, il est tout à fait possible de scaler un monolithe, que ce soit verticalement ou horizontalement.

En revanche, les monolithes scalent mal.

Si le scaling vertical est en principe le plus simple à mettre en œuvre, il ne faut pas oublier qu’il y a toujours une limite physique à la puissance d’un ordinateur.

En d’autres termes, il y aura une charge limite au-delà de laquelle on ne pourra plus scaler.

Rien n’empêche non plus de scaler un monolithe de manière horizontale, mais ce qu’on gagne en fiabilité, on le perd en efficacité.

Le principe même du monolithe consiste à inclure l’entièreté du système dans un seul exécutable.

Seulement, la charge de travail n’est jamais répartie uniformément à travers un système.

Si je veux scaler ma base de données, je suis donc obligé de lancer toute une instance de mon monolithe, incluant des couches qui n’ont pas besoin d’être scalées, comme la couche de présentation par exemple.

Les infrastructures en micro-services

Visuel représentant une architecture en micro-services. Le système est découpé en plusieurs micro-services qui communiquent les uns avec les autres

Avec l’apparition d’outils de virtualisation et d’orchestration tels que Docker et Kubernetes, il est devenu bien plus facile de rendre ses applications portables et scalables, donc fiables.

En conséquence, les infrastructures en micro-services ont fini par envahir l’industrie, balayant au passage l’architecture monolithique.

Ce type d’infrastructure consiste à diviser le système en plusieurs applications modulaires faiblement dépendantes les unes des autres.

Cette approche permet non-seulement d’améliorer la fiabilité du logiciel, mais elle améliore également sa maintenabilité, puisqu’elle rend les effets de bords limités par nature.

Clean Architecture

Visuel représentant la Clean Architecture. Elle se compose de 4 couches techniques : -Les frameworks et les drivers -Les adaptateurs -La logique métier -Les entités métiers Les données traversent plusieurs fois la couche Adaptateurs pour aller d'un driver à un autre, mais les dépendances ne se font que de l'extérieur vers l'intérieur.

La Clean Architecture est une architecture adaptée aux micro-services dont l’objectif principal est de réduire les relations de dépendances avec les services extérieurs, et de limiter le couplage, c’est-à-dire les relations de dépendance entre les composants eux-mêmes.

Selon la Clean Architecture, la logique métier doit être :

  1. Testable
  2. Indépendante des frameworks
  3. Indépendante des interfaces utilisateur
  4. Indépendante des bases de données
  5. Indépendante des services externes

Pour faire simple, il faut pouvoir remplacer tous les éléments qui ne concernent pas directement votre Domaine (entités + logique métier) simplement.

Cela inclut vos applications frontend, vos systèmes de gestion de bases de données, les modules que vous utilisez, et les fournisseurs tiers sur lesquels vous vous appuyez.

Organisation de la Clean Architecture

La Clean Architecture organise ses différentes couches telle une cible où les couches les plus remplaçables enveloppent les couches les plus essentielles.

Ces couches sont, en partant de l’intérieur :

  1. Entités métier : la modélisation programmatique des choses que vous allez manipuler.
  2. Logique métier : l’ensemble du code permettant de réaliser les cas d’utilisation.
  3. Adaptateurs : l’ensemble des passerelles entre votre logique métier et l’extérieur, que ce soit des services tiers, comme des utilisateurs.
    Concrètement : des applications web, des applications mobiles, des APIs et des processus automatisés, des bibliothèques d’adaptateurs, des bibliothèques de Data Access Objects
  4. Frameworks & drivers : l’ensemble de ce qui existe en-dehors du système.
    Concrètement : des bases de données, des APIs tierces

Les dépendances ne pouvant aller que de l’extérieur vers l’intérieur, un adaptateur dépendra de la logique métier, mais la logique métier ne pourra en aucun cas dépendre d‘un adaptateur.

À noter cependant que la Clean Architecture ne parle que de dépendances d’implémentation.

Le fait que les bases de données se situent techniquement dans la couche extérieur ne rend pas pour autant la couche d’infrastructure dépendante de cette dernière, du moment qu’une couche d’abstraction existe bien entre les deux.

De plus, un composant dans la Clean Architecture ne se traduit pas forcément en micro-service.

Ici, un micro-service sera une interface dépendant de bibliothèques communes à d’autres micro-services, telles que les entités et les adaptateurs.

Les tests dans la Clean Architecture

Le code étant séparé en couches distinctes et relativement peu dépendantes les unes des autres, il devient plus facile de le tester correctement.

Ainsi, les tests peuvent être effectués par couche, en mockant les éventuelles dépendances.

Vertical Slice Architecture

Représentation visuelle de la Vertical Slice Architecture. Le système est découpé en tranches verticales, des sortes de mini-monolithes contenant chacun leurs propres couche de présentation, logique métier, et couche d'accès aux données ; et représentant chacun une fonctionnalité du système.

Tout comme la Clean Architecture, la Vertical Slice Architecture est une architecture adaptée aux micro-services qui vise à réduire les relations de dépendance entre le système et l’extérieur, et au sein du système lui-même.

La différence réside dans leurs approches respectives.

La Vertical Slice Architecture s’appuie sur deux dogmes :

  1. Les choses qui changent ensemble vont ensemble.
  2. Il faut maximiser la cohésion (les choses liées vont ensemble) et minimiser le couplage (les relations de co-dépendance entre les composants).

… et trois principes :

  1. Le système doit être centré autour des fonctionnalités.
  2. Il ne doit pas y avoir de barrières entre les couches du système.
  3. Le changement ne doit s’opérer que sur un seul endroit à la fois.

Là où la Clean Architecture découpe le système en couches techniques, la Vertical Slice Architecture le découpe en fonctionnalités.

Chaque tranche vertical du système possède sa propre couche de présentation et sa logique métier, toutes deux établies sur un domaine, et une base de données pouvant être commune à d’autres tranches verticales.

Pour simplifier, on pourrait dire qu’une tranche verticale est une sorte de mini-monolithe s’occupant exclusivement d’une fonctionnalité.

Au lieu de scaler les différentes couches techniques, on fera scaler les fonctionnalités elles-mêmes.

L’avantage de la Vertical Slice sur la Clean Architecture, c’est qu’elle produit en fin de compte moins de couplage, tout en réduisant le niveau d’abstractions à créer pour maintenir une architecture qualitative.

Cela ne veut pas nécessairement dire qu’elle est meilleure, mais elle offre une approche différente.

Monolithe, Clean, ou Vertical Slice ?

Réponse courte : ça dépend !

Chidi de The Good Place disant : "J'ai pris une décision. Je vais commencer... à pleurer."

Même si on utilise de moins en moins l’architecture monolithique de nos jours, elle reste tout de même la plus simple et la moins coûteuse à mettre en place pour les petits projets.

Dans le cas où vous devriez vous diriger vers des micro-services, le choix entre la Clean Architecture et la Vertical Slice dépend presque entièrement de la façon dont vous préférez approcher le développement.

Certes la Vertical Slice Architecture vous fera gagner du temps en vous épargnant quelques couches d’abstractions, mais peut-être qu’un découpage en couches techniques semblera plus cohérent pour vous.

De plus, moins d’abstraction signifie aussi plus de dépendances, ce qui pourrait nuire à la maintenabilité de votre système.

Concevoir c’est choisir, et il y a rarement d’option fonctionnant dans toutes les situations.

Le mieux reste encore de visualiser votre système dans son entièreté, et de choisir ce qui semble être le plus adapté à sa situation.

Pour aller plus loin

Architecture logicielle : https://fr.wikipedia.org/wiki/Architecture_logicielle

Erosion de l’architecture logicielle : https://fr.wikipedia.org/wiki/%C3%89rosion_de_l%27architecture_logicielle

L’entropie logicielle, pourquoi la dette technique ne fait qu’augmenter ? https://lilobase.wordpress.com/2014/05/27/lentropie-logicielle-pourquoi-la-dette-technique-ne-fait-quaugmenter/

What is ISO 25010 : https://www.perforce.com/blog/qac/what-is-iso-25010

monolithic architecture : https://www.techtarget.com/whatis/definition/monolithic-architecture

Qu’est-ce que la Clean Architecture ? https://www.adimeo.com/blog/forum-php-2019-clean-architecture

Clean Architecture Guide : https://proandroiddev.com/clean-architecture-data-flow-dependency-rule-615ffdd79e29

Restructuring to a Vertical Slice Architecture : https://codeopinion.com/restructuring-to-a-vertical-slice-architecture/

How to Implement Vertical Slice Architecture : https://garywoodfine.com/implementing-vertical-slice-architecture/

Mort au cycle en V, mais surtout mort à Scrum

Pour lire d’autres articles sur le développement, cliquez ici.

Depuis plus de 20 ans, Agile est le paradigme le plus utilisé dans le développement logiciel.

Plus spécifiquement, c’est Scrum qui est aujourd’hui appliqué dans la plupart des projets faisant appel aux méthodes agile.

Avant les années 2000, c’était le cycle en V qui était utilisé dans la vaste majorité des cas.

Nous allons voir par quoi ces 2 méthodes ont été influencées, en quoi elles consistent, et pourquoi elles sont en réalité toutes les deux terriblement inefficaces.

Le développement en tant que chaîne de production

Le parti-pris du cycle en V et de Scrum est d’envisager le développement logiciel comme une chaîne de production.

C’est-à-dire que ces méthodes partent du principe qu’il faut pouvoir l’organiser avec des processus très spécifiques au sein d’un cadre strict dans le but d’améliorer l’efficacité des équipes en charge.

Pour comprendre comment on en est arrivé là avec les méthodologies de développement logiciel, il faut comprendre de quoi elles s’inspirent.

Le taylorisme

Représentation visuelle du Taylorisme. C'est une pyramide représentant les 3 niveaux hiérarchiques de l'organisation Tayloriste du travail. La base représente l'exécution, menée par les ouvriers. L'étage intermédiaire représente la vérification, assurée par les contremaîtres. Le sommet représente la conception, assurée par les ingénieurs. La dimension horizontale consiste en la répartition des tâches entre personnes d'un même étage. La dimension verticale consiste en la répartition des types de tâches en fonction de l'étage de la pyramide.

Le taylorisme est une des méthodes d’organisation du travail les plus connues.

Inventée par Frederick Winslow Taylor à la fin du XIXe siècle, elle préconise d’organiser le travail sur 2 dimensions :

  • La dimension verticale : on sépare les phases de conception, de vérification, et d’exécution. Les ingénieurs pensent le produit, les ouvriers le fabriquent, et les contremaîtres supervisent le travail des ouvriers.
  • La dimension horizontale : on découpe l’exécution en tâches simples confiées aux ouvriers.

Lean

Inspiré de la gestion du système de production de Toyota, le Lean est une méthode de gestion de la production visant à éliminer le gaspillage des ressources, l’irrégularité, et la surcharge de travail.

De manière plus résumée, Lean cherche à améliorer la valeur pour le client en améliorant les performances de production.

Pour comprendre Lean, il faut connaître les 2 modes de pilotage d’une chaîne de production :

  • Le flux poussé : on produit pour stocker (on s’apprête à vendre)
  • Le flux tiré : on produit pour livrer (on a déjà vendu)

Lean applique une gestion dite de « juste à temps » (JIT), en flux tiré, afin de toujours produire exactement ce qui est demandé par le client de manière instantanée.

De plus, en faisant en sorte de détecter les défauts dans la chaîne de production au plus tôt, Lean permet de réduire des coûts de non-qualité qui seraient détectés plus tard.

Lean se base également sur le principe de l’amélioration continue, consistant à résoudre les problèmes directement sur le terrain avec les acteurs concernés.

Cycle de Shewhart : Plan-Do-Check-Act

Représentation visuelle du cycle de Shewhart. C'est un cercle vertueux consistant en 4 étapes : la planification, la réalisation, la vérification, et l'ajustement.

Le cycle de Shewhart est une méthode de gestion de la qualité utilisée par Lean, prenant la forme d’un cercle vertueux et permettant d’améliorer la qualité d’un produit de manière continue.

Il se déroule en 4 étapes :
1) Planifier ce que l’on veut réaliser en identifiant un problème et les solutions possibles à sa cause racine
2) Réalisation
3) Contrôler l’efficacité et la qualité de la solution mise en place
4) Ajuster et déployer

Le modèle en cascade

Représentation visuelle du modèle en cascade. On y retrouve 6 étapes successives : exigences, analyse, conception, mise en œuvre, validation, et mise en service.

Le modèle en cascade n’est pas inspiré du Taylorisme de manière officielle, mais il serait difficile de ne pas y voir une certaine forme de mimétisme.

Il s’agit d’une des organisations de projet les plus utilisées en développement logiciel.

Ici, on s’intéresse au projet dans sa globalité en séparant le développement en 6 phases successives :

  1. Exigences, l’expression d’un besoin
  2. Analyse, l’étude du besoin exprimé
  3. Conception, préparation à la mise en oeuvre
  4. Mise en œuvre, la réalisation du produit
  5. Validation, vérification de la conformité du produit aux exigences
  6. Mise en service

L’avantage du modèle en cascade est qu’il permet de tenir une documentation conséquente constituée des livrables créés lors de chaque phase.

Dans le cadre d’un projet de développement logiciel, on se retrouverait avec les livrables suivants :

  1. Exigences : Expression de besoins
  2. Analyse : Cahier des charges
  3. Conception : Architecture et modèles
  4. Mise en œuvre : Produit
  5. Validation : Tests

Cycle en V

Représentation visuelle du cycle en V. On y retrouve 10 étapes : exigences, analyse, conception générale, conception détaillée, réalisation, tests unitaires, tests d'intégration, validation, et recette

Le cycle en V est une spécification du modèle en cascade pour les projets d’ingénierie et de développement logiciel.

Il reprend le fonctionnement en phases successives du modèle en cascade, en ajoutant 4 étapes supplémentaires et étant plus spécifique sur les tâches à accomplir.

Pour cela, il regroupe les phases de la gestion du projet en 4 niveaux, avec pour chaque catégorie une phase de conception et une phase de vérification, lui donnant ainsi une forme de V lorsqu’il est schématisé :

  1. Métier
  2. Fonctions du produit
  3. Système et architecture
  4. Composants du système

On retrouve donc les étapes suivantes :

  1. Exigences : expression d’un besoin
  2. Analyse : création d’un cahier des charges à partir des exigences
  3. Conception générale : conception du système et de son architecture
  4. Conception détaillée : conception de chaque composant du système
  5. Mise en œuvre : développement des composants
  6. Tests unitaires : vérification de la conformité de chaque composant
  7. Tests d’intégration : vérification des interactions entre les composants conformément aux exigences de la conception générale
  8. Tests systèmes : vérification de la conformité du système aux exigences
  9. Validation : tests d’acceptation
  10. Recette : le client valide le produit avant sa mise en service

Les entités du cycle en V

  • La maîtrise d’ouvrage (MOA) : l’organisme décideur pour qui le projet est réalisé
  • La maîtrise d’œuvre (MOE) : l’organisme réalisant le projet
    • L’équipe architecturale : équipe en charge du système et de l’architecture
    • L’équipe de développement : équipe en charge des composants
  • Le comité de pilotage : assure le suivi du projet et sert d’intermédiaire entre la MOA et la MOE

Le problème du cycle en V

Le cycle en V possède un énorme défaut.

C’est d’ailleurs ce défaut qui lui a été fatal quand la méthode Agile est arrivée.

Ce défaut, c’est l’effet tunnel.

« Un jour, j’irai vivre en Théorie, car en Théorie tout se passe bien.« 

Pierre Desproges

L’effet tunnel, c’est un manque de visibilité sur l’avancement du projet.

En se faisant succéder une phase de conception, une phase de réalisation, et une phase de validation, le cycle en V semble partir du principe que l’on n’aura jamais besoin de retoucher aux exigences ou de repartir en arrière.

Pourtant, ce n’est pas rare que les spécifications d’un projet évoluent dans le temps, car elles étaient incomplètes ou parce que l’objectif a changé.

« Vous ne pouvez pas demander aux clients ce qu’ils veulent et ensuite essayer de le leur donner. Au moment où vous l’aurez construit, ils voudront autre chose. »

Steve Jobs

De plus, que se passe-t-il si l’on s’aperçoit qu’une partie de la conception est finalement impossible à réaliser ?

On revient en arrière ? Sous quelles conditions ? Les responsables de la phase en question sont-ils encore disponibles ?

Une méthode qui ne prend pas en compte ce genre d’imprévus n’a pas beaucoup d’utilité.

Vous pouvez bien nommer autant de responsables, et produire autant de livrables que vous voulez, si le train déraille au moindre caillou sur la voie, vous aurez peu de chance d’arriver à destination.

Les critiques du modèle en cascade

Comme vu précédemment pour le cycle en V, le principe des phases successives est une énorme source de problèmes.

Mener toute une gestion de projet sur la base d’exigences susceptibles d’évoluer rend presque obligatoire le fait d’effectuer des retours en arrière intempestifs entre les différentes phases.

Le but du jeu est de descendre la cascade, alors pourquoi passerait-on notre temps à la remonter ?

Quel peut bien être l’intérêt de tout planifier si ça ne sert à rien ?

Agile

Aux antipodes du modèle en cascade et de sa rigidité, les méthodes agiles proposent de s’appuyer sur des équipes pluridisciplinaires auto-organisées au sein d’un cadre favorisant l’amélioration continue.

Agile s’inspire du Lean pour apporter les principes de flux tiré, d’amélioration continue, et de planification adaptative au domaine du développement logiciel.

Agile est apparu de manière officielle lorsque 17 développeurs ont publié le Manifeste pour le développement agile de logiciels en 2001.

En 4 valeurs, Agile se place en opposition complète au modèle en cascade et son cycle en V :

  1. Les individus sont plus importants que les processus et les outils.
  2. Un logiciel opérationnel est plus important qu’une documentation exhaustive.
  3. Collaborer avec les clients est plus important que la négociation contractuelle.
  4. L’adaptation au changement est plus importante que l’exécution d’un plan.

Ce que ces valeurs signifient, c’est que la plus haute priorité est de satisfaire le client avec la livraison rapide d’un produit qui correspond à ses attentes.

Ce faisant, il ne sert à rien d’appliquer strictement des méthodes si elles nuisent à l’avancée du projet, et il faut pouvoir accueillir positivement le changement tout au long du développement.

Le Manifeste Agile nous apporte également un principe important : le principal témoin d’avancement d’un projet de développement est un logiciel opérationnel.

Développement itératif et incrémental

Complètement opposé au modèle en cascade et à sa philosophie de planification excessive, Agile se base sur le principe du développement itératif et incrémental.

  • Itératif : le développement est approché de manière cyclique
  • Incrémental : chaque cycle apporte un nouvel incrément du produit

Le développement itératif et incrémental puise son inspiration directement dans le cycle de Shewhart.

Scrum

Représentation visuelle de Scrum. Scrum forme une boucle jalonnée par 4 étapes : la planification de sprint, le développement (lui-même jalonné par des daily-scrums), la revue de sprint, et la rétrospective de sprint.

Le petit problème avec Agile, c’est que c’est en fin de compte une philosophie à adopter, et non une véritable méthode.

Le manifeste nous indique 4 valeurs à respecter et 12 principes à suivre, mais ne nous dit à aucun moment comment faire.

C’est là qu’entrent en scène 2 méthodes censées appliquer les principes agiles : Scrum et exTreme Programming (XP).

Si les méthodes agiles sont inspirées par la philosophie Lean, Scrum est carrément un moyen de transformer un projet logiciel en chaîne d’assemblage de Toyota.

Scrum est considéré comme un framework, c’est-à-dire un cadre de travail, et non une méthode de gestion de projet en tant que telle.

D’ailleurs, Scrum en tant que tel n’est pas spécifiquement conçu pour le développement informatique.

Plus exactement, ici on va parler du syncrétisme de Scrum et d’eXtreme programming, qui est généralement ce que l’on nomme Scrum au sein des entreprises.

Scrum se base sur 3 piliers :

  1. Transparence : tous les membres de l’équipe Scrum sont tenus au courant des actualités
  2. Inspection : le travail est vérifié au fur et à mesure
  3. Adaptation : l’équipe Scrum s’adapte à l’évolution du contexte du projet

Le développement est divisé en sprints, des blocs de temps plus ou moins longs (d’une semaine à un mois, très généralement 2 semaines).

Lesdits sprints commencent tous par une réunion de planification de sprint, et se finissent par une rétrospective.

La planification de sprint vise à prioriser les tâches du product backlog, qui liste toutes les fonctionnalités et les corrections à implémenter et qui se remplit et se vide au fur et à mesure du projet.

Entre les deux, le développement suit son cours en fonction de ce qui a été défini lors de la planification.

Les entités de Scrum

  • Les parties prenantes : l’ensemble des individus et organisations extérieurs à l’équipe, mais concernés par le projet. (ex : client, utilisateurs, partenaires)
  • Le product owner : le représentant de l’utilisateur final au sein de l’équipe de développement, ou l’utilisateur final lui-même. Il a la charge de prioriser les tâches du backlog pour servir les nouvelles exigences.
  • Le scrum master : le membre de l’équipe de développement chargé de faire appliquer les principes du Scrum. Ce n’est pas un chef de projet, mais un facilitateur.
  • L’équipe scrum : l’équipe pluridisciplinaire chargée de concevoir et de réaliser le produit.

Les « cérémonies » Scrum

  • Daily scrum : réunion quotidienne rapide (max. 15 minutes) au cours de laquelle les membres de l’équipe font le point sur ce qui est en cours et a été fait.
  • Planification de sprint : réunion d’ouverture d’un sprint au cours de laquelle l’équipe définie avec le product owner l’objectif du sprint et les tâches du backlog à y inclure.
  • Revue de sprint : réunion précédent la rétrospective au cours de laquelle l’équipe Scrum présente les ajouts du dernier sprint aux parties prenantes du projet.
  • Rétrospective de sprint : réunion de clôture d’un sprint au cours de laquelle l’équipe fait le bilan sur l’avancement des tâches prévues et cherche des axes d’amélioration.

Le problème avec Scrum

« Maintenant, Agile signifie appliquer la moitié des principes de Scrum et utiliser Jira. »

Andy Hunt

Scrum n’est pas agile.

Il va à l’encontre de la première valeur d’Agile : « Les individus sont plus importants que les processus et les outils ».

Scrum est rempli de processus qui servent à se donner l’illusion d’une planification, mais qui apportent finalement très peu de valeur, voire ralentissent les choses.

On aura beau mettre un joli enrobage autour en remplaçant le terme « réunions » par « cérémonies », le résultat est le même.

Pendant que l’on passe 5 heures par semaine* à discuter du backlog et des tickets, on ne conçoit pas et on ne développe pas.

*il s’agit réellement du temps occupé par toutes les cérémonies quand on suit les recommandations officielles.

Scrum est un moulin à bullshit.

À quoi cela sert-il d’estimer le temps et la difficulté des tâches ?

La prise de décision devrait être simple : si la tâche semble trop lourde ou difficile, il faut la diviser en sous-tâches ou l’abandonner.

Pourquoi donc essayer de quantifier ces paramètres à coups de poker planning ?

La réponse : pour pouvoir faire des sprints de 2 semaines.

Nouvelle question : pourquoi organiser le développement en sprints en premier lieu ?

Bien sûr, il s’agit de pouvoir livrer un incrément du produit régulièrement, mais « régulièrement » ne veut pas dire « absolument toutes les 2 semaines »

L’utilisateur final s’en fiche que son logiciel se mette à jour toutes les 2 semaines, il veut un logiciel qui marche.

Ça n’a pas de sens, au lieu d’axer le développement autour de quelque chose qui a énormément de valeur (un logiciel opérationnel), Scrum l’axe autour de quelque chose qui en a beaucoup moins (des mises à jour régulières)

Roh, c’est pas si mal

Les délais ou la qualité

Qu’obtient-on lorsque l’on essaie de diviser un développement en blocs de temps fixe ?

  1. Un produit mal conçu et à moitié opérationnel (personne ne veut ça)
  2. Des tickets qui sont retardés d’un sprint à un autre (donc aucun intérêt à faire des sprints)

Cela revient à essayer de rentrer un éléphant dans un frigo. Ça ne passera pas sans faire du mal à l’éléphant.*

*pour votre propre bien ainsi que le sien, n’essayez pas de rentrer un éléphant dans un frigo

En voulant créer un cadre de travail alternatif au modèle en cascade, Scrum est devenu la chose même qu’il comptait détruire : une machine à planifier qui ne permet pas de faire ce qui est utile, mais de faire ce que dit la méthode.

De ce point de vue là, Scrum est l’antithèse d’Agile. Tout autant que n’importe quelle variation du cycle en V.

Scrum a complètement délaissé le fondement même d’Agile : le principal témoin d’avancement d’un projet de développement est un logiciel opérationnel.

Pas le nombre de tickets effectués en 2 semaines.

Pas le nombre de livrables.

Un logiciel opérationnel.

Être agile sans Scrum

Devinez quoi ? C’est possible !

Yippee!

Il suffit juste de prendre tout ce qu’a apporté Scrum et de le jeter par la fenêtre, pour revenir aux principes du manifeste.

  1. Arrêtez de faire des sprints. Axez le développement autour de ce qu’il faut livrer, pas autour de blocs de temps.
  2. N’essayez pas de faire des estimations. Une tâche est faisable ou elle ne l’est pas.
  3. Récoltez du feedback de manière régulière.
  4. Gardez votre code simple et clair.
  5. Faites du refactoring. Éliminez la dette technique quand vous la trouvez. N’attendez pas que votre code se transforme en monstre spaghetti géant.
  6. Faites ce qui produit de la valeur.
  7. Ne faites pas ce qui n’en produit pas.

Agile n’est pas un tableau Jira.

Si cela a du sens pour vous d’utiliser Jira, utilisez Jira.

Sinon, utilisez autre chose. L’important, c’est que ça marche.

Maintenant que vous êtes libéré des contraintes de Scrum, vous pouvez vous concentrer sur ce qui apporte le plus de valeur, dans cet ordre-là :

  1. Faire quelque chose qui fonctionne
  2. Le faire proprement
  3. Le faire rapidement

Une 3ème voie

Finissons sur une simple suggestion.

Le modèle en cascade et la méthode Agile comparent tous les deux le développement logiciel à une chaîne de production, à un certain degré.

L’un cherche à planifier la totalité du travail comme on a l’habitude de le faire dans l’industrie, et l’autre s’inspire du Lean.

Seulement, la métaphore est-elle vraiment si pertinente ?

Et si, finalement, le développement n’était pas une chaîne de production, mais un processus créatif ?

Outre le fait qu’un logiciel soit en évolution constante, contrairement à un produit sorti d’une chaîne de production, un logiciel est quelque chose que l’on conçoit et que l’on écrit avant d’être quelque chose que l’on assemble.

Peut-être faut-il simplement cesser de vouloir faire du Taylorisme ou du Lean.

Il n’y a pas qu’une seule façon de piloter un processus créatif.

De plus, le processus créatif de chaque personne et de chaque organisme est différent.

Peut-être que le mieux à faire est encore de s’inspirer de ce qui existe déjà, d’expérimenter, et d’établir sa propre méthode.

Au lieu d’appliquer ce qui est censé marcher, trouvez ce qui marche pour vous et vos collaborateurs.

Ensuite, documentez, et faites évoluer si besoin est.

Refuser de choisir entre le cycle en V et Scrum ne signifie pas que l’entreprise va plonger dans le chaos et l’anarchie pour finir par mettre la clé sous la porte.

Au contraire, cela signifie que l’on se débarrasse d’une quantité astronomique de bullshit pour se concentrer sur la seule chose qui compte pour une entreprise : créer de la valeur.

Pour aller plus loin

Taylorisme : https://fr.wikipedia.org/wiki/Taylorisme

Lean : https://fr.wikipedia.org/wiki/Lean_(production)

Modèle en cascade : https://fr.wikipedia.org/wiki/Mod%C3%A8le_en_cascade

Cycle en V : https://fr.wikipedia.org/wiki/Cycle_en_V

Méthode agile : https://fr.wikipedia.org/wiki/M%C3%A9thode_agile

Le Manifeste Agile : https://manifesteagile.fr/

Scrum : https://fr.wikipedia.org/wiki/Scrum_(d%C3%A9veloppement)

You’re doing agile wrong : https://www.youtube.com/watch?v=9K20e7jlQPA

Less is more agile : https://beny23.github.io/posts/my_take_on_engineering_room_9/

The age of cargo cult Agile must end : https://jchyip.medium.com/the-age-of-cargo-cult-agile-must-end-9408e1d13e1d

Your process should be open source : https://betterprogramming.pub/your-process-should-be-open-source-bb7633e9f3d6

La Qualité Produit

Personne n’aime les produits de mauvaise qualité.

Personne n’a envie d’utiliser un mauvais produit, et personne de sain d’esprit n’a envie d’en créer.

Souvent, ce sont des accidents.

Le degré de qualité d’un produit est défini par les concessions, les choix, et les contraintes qui ont obstrué sa création.

Le problème, c’est qu’il est difficile de faire les bons choix quand on ne sait même pas sur quels critères baser sa décision.

Bien sûr, chaque personne a une vision intuitive des paramètres à observer.

Seulement, chaque personne a également une vision différente.

Au sein de l’entreprise, certaines personnes vont adopter une vision orientée business, et d’autres une vision orientée commerciale.

Il va sans dire que c’est la synthèse de ces différentes visions qui apporte son équilibre à une entreprise, mais qu’en est-il de la vision orientée produit ?

C’est la question que je me posais quand je suis tombé sur un article écrit par Dave Feldman, un product designer ayant pas mal roulé sa bosse chez les géants de la Silicon Valley et dans l’écosystème startup.

L’article concerne en premier lieu les logiciels.

En revanche, il fournit quelques clés de compréhension pouvant s’appliquer à n’importe quel autre type de produit.

À quels critères répond la Qualité Produit ?

La qualité d’un produit est directement corrélée à sa capacité à répondre aux besoins de ses utilisateurs de manière élégante et simple.

Pour mesurer une donnée aussi abstraite, Dave Feldman a conceptualisé le framework COUPE, rassemblant 5 qualités :

  • Complet
  • Opiniâtre
  • Utilisable
  • Propre
  • Efficace
Framework COUPE : Complet, Opiniâtre, Utilisable, Propre, Efficace

Voyons ce que ces critères signifient en détails :

Complet

Ce premier critère mesure la simplicité avec laquelle l’utilisateur interagit avec le produit pour répondre à son problème.

La question à se poser est la suivante : « Pour une fonctionnalité donnée, est-ce que le produit répond à un besoin de manière complète et efficace ? »

En d’autres termes, est-ce que l’utilisateur peut résoudre son problème de manière simple et intuitive, ou bien doit-il se battre avec le produit, voire demander de l’assistance ?

Opiniâtre

Le produit se concentre-t-il sur les utilisateurs cible au détriment des autres ?

Il est impossible de satisfaire tout le monde.

Faire des choix vaut toujours mieux qu’essayer de jongler avec les attentes et les besoins de tout le monde, même si cela implique de décevoir la partie la moins importante de vos utilisateurs

Autrement, votre absence de décision finira par donner un produit incohérent et inutile.

Utilisable / convivial

En quelques mots : votre produit est-il intuitif ?

Avez-vous fait les choix de conception nécessaires pour qu’au premier coup d’œil, l’utilisateur puisse se dire « Ok, je vois comment ça marche » ?

Ces choix de conception concernent directement l’UI/UX de votre produit.

Vos contenus sont-ils agencés d’une manière qui a du sens ?

Les informations les plus importantes sont-elles celles que l’on voit en premier ?

Les icônes et les textes des boutons permettent-ils de comprendre à quoi ils servent spécifiquement ?

L’interface utilisateur est-elle un frein à la compréhension de manière générale ? Est-elle trop lourde ? Les couleurs transmettent-elles les bons messages ? La typographie est-elle facilement lisible ?

Propre

L’apparence de votre produit est-elle soignée ?

Les images ont-elles une qualité satisfaisante ?

Les différents éléments de votre interface font-ils partie d’un tout homogène ?

Soigner l’apparence de votre produit ne le rend pas forcément plus utilisable, mais cela le rend par contre plus agréable à utiliser.

Peut-on travailler de manière efficace avec un produit moche ? Évidemment.

Pour autant, on préférerait un produit avec les mêmes fonctionnalités, mais ayant une meilleure interface.

Efficace

L’efficacité d’un produit concerne à la fois ses performances techniques et les critères vus précédemment.

Le produit est-il rapide et réactif ?

Consomme-t-il beaucoup de ressources ?

Combien de temps met-il à satisfaire l’utilisateur pour un problème donné ? Par combien d’étapes l’utilisateur doit-il passer ? Le délai de réponse est-il satisfaisant ?

Pourquoi la Qualité Produit est-elle importante ?

Au-delà de l’envie de bien faire, il existe plusieurs situations dans lesquelles la qualité de votre produit est essentielle au développement de votre business.

Lorsque vous êtes dans un marché hyper-concurrentiel, la qualité de votre produit est un des seuls moyens de vous différencier face à vos concurrents.

La même logique s’applique particulièrement quand vous avez un business model Business-to-Customer, et, de manière plus générale, quand l’utilisateur final est fortement impliqué dans la décision d’achat.

De même, si vous arrivez sur un marché marqué par la haute qualité de ses produits existants, vous n’avez pas d’autres choix que de proposer ne serait-ce qu’un produit de qualité équivalente.

Mesurer la qualité

Il existe différents moyens de mesurer la qualité d’un produit.

Effectuer une évaluation heuristique

Une évaluation heuristique consiste à faire auditer l’ergonomie d’une Interface Homme-machine par une équipe de designers.

L’évaluation heuristique est un moyen simple et efficace de mesurer et d’obtenir des retours sur la qualité de votre produit.

Les tests de convivialité

La convivialité d’une interface représente la compréhension que l’utilisateur a de cette dernière.

Dans sa version la plus simple, le test de convivialité consiste à mettre un utilisateur devant le produit et à observer comment il interagit avec.

Il s’agit d’un moyen simple de mesurer l’utilisabilité d’un produit.

Les mesures d’utilisation

En complément des tests de convivialité, mesurer l’utilisation des différentes fonctionnalités du produit permet d’avoir une idée plus précise du comportement des utilisateurs.

La satisfaction client

En mettant en place des enquêtes bien conçues et en cherchant à obtenir du feedback, vous pourrez détecter des problèmes qui semblent évidents pour vos utilisateurs, mais que vous avez été incapable de voir.

Les mesures de performance

Mesurer les performances techniques de votre produit vous renseignera sur sa stabilité, et par conséquent son efficacité.

Améliorer sa qualité produit

L’intérêt de comprendre ce qu’est la Qualité Produit et comment la mesurer, c’est de pouvoir l’améliorer.

Soyez axiomatique

« Un axiome est une proposition non démontrée, utilisée comme fondement d’un raisonnement ou d’une théorie mathématique. »

Axiome – Wikipédia

Dans le cadre de l’amélioration de la qualité produit, raisonner de manière axiomatique revient à établir que la Qualité Produit est directement corrélée aux métriques business de l’entreprise.

Autrement dit, c’est partir du principe que la Qualité Produit elle-même est un moteur de la bonne santé de l’entreprise.

C’est simplement la base d’une vision orientée produit : on priorise la qualité du produit parce que l’on pense que cela va directement impacter les revenus.

Priorisez ce qui a du sens

Résoudre les bugs et « rembourser » la dette technique sont essentiels à la stabilité de la solution.

Seulement, la maintenance évolutive et corrective ne devrait pas pour autant prendre le pas sur le développement de fonctionnalités attendues.

Il n’est pas tant question de se concentrer sur les fonctionnalités au détriment du reste que de prioriser ce qui fait sens sur le moment.

Si une fonctionnalité encore incomplète est le principal attrait de votre produit, il vaut mieux concentrer les ressources de l’entreprise sur l’aboutissement de ladite fonctionnalité, plutôt que de s’éparpiller sur des corrections de bugs mineurs.

Faites du good-enough

Pour chaque nouvelle fonctionnalité que vous comptez développer, prévoyez de faire une première version incomplète.

Si les résultats pour cette première version sont prometteurs ou satisfaisants, faites une deuxième version aboutie et mieux intégrée.

Sinon, retirez purement et simplement la fonctionnalité.

Agir ainsi vous permettra de tester vos hypothèses à moindre coût et de garder un produit cohérent qui se concentre sur l’essentiel et ce sur quoi il est bon.

Pensez macro

Il n’y a rien de pire qu’un produit incohérent qui adopte un comportement différent pour chaque fonctionnalité.

Lorsque vous développez une nouvelle fonctionnalité, vous devez toujours tenir compte du reste du produit.

Vous devez vous assurer qu’elle ne détone pas avec le reste.

Cela implique de se restreindre à la façon de fonctionner qui existe déjà, ou de la faire évoluer.

Avoir un outil sur lequel s’appuyer, tel qu’un design system ou une architecture définie, peut dans de nombreux cas aider à garder un fonctionnement cohérent.

Faites des choix

Pour concevoir un produit cohérent, il faut savoir où l’on va.

Ce n’est pas une bonne idée d’essayer de contenter tout le monde.

Un produit ne peut pas être à la fois flexible et de bonne qualité.

Il vous faut être clair sur vos choix d’architecture, plutôt que d’essayer d’optimiser une flexibilité qui ne sera de toute façon jamais satisfaisante.

Utilisez la recherche fondamentale

La recherche fondamentale consiste à trouver un problème profond à résoudre chez l’utilisateur.

Le but est de comprendre ses motivations et ses objectifs et le contexte dans lequel il évolue afin de pouvoir en déduire des points de douleur.

Un rendez-vous bien préparé avec un client peut vous en apprendre beaucoup sur ses besoins et sur votre produit.

Menez des tests de convivialité

Dans sa version la plus simple, le test de convivialité consiste à mettre un utilisateur devant le produit et à observer comment il interagit avec.

Effectuer des tests de convivialité à des moments clé du développement vous permettra d’avoir des retours sur la complétion et la convivialité de votre produit.

Vous n’avez pas forcément besoin d’avoir un produit fini pour commencer à mener des tests de convivialité.

En fonction de ce que vous voulez tester, un prototype ou un mockup peut être suffisant.

Faites des alphas et des betas fermées

Arrivé à la fin du développement, faire valider les nouvelles fonctionnalités au cours d’une alpha ou d’une beta fermée vous permettra de savoir quels aspects ont besoin d’un peu plus d’attention et de soin, et lesquels sont très bien comme ils sont.

C’est fini !

Vous devriez avoir maintenant avoir une meilleure compréhension de ce qu’est la Qualité Produit, et comment l’améliorer !

Lire l’article original : https://dfeldman.medium.com/what-is-product-quality-a-practical-definition-990d3ca6827

Le framework Bullseye

Pour connaître d’autres méthodes, cliquez ici

Le framework Bullseye est un outil permettant de sélectionner le canal de traction le plus adapté pour votre startup.

Il est décrit par Gabriel Weinberg et Justin Mares dans leur livre Traction et permet de sélectionner le bon canal de traction sur les 19 existants.

Afin d’obtenir un Product/Market Fit, il est nécessaire de diffuser le bon message à la bonne audience, et pour cela il faut choisir le bon canal de communication.

Le Bullseye permet justement de trouver ce canal de communication en seulement 3 étapes.

Ces 3 étapes sont représentées par 3 anneaux imbriqués les uns dans les autres.

Représentation graphique du Bullseye

On parcourt le Bullseye de l’extérieur vers l’intérieur, en partant des 19 canaux possibles et en les filtrant jusqu’à n’en garder qu’un seul : votre canal-cœur.

L’anneau extérieur – Le possible

Cette première étape consiste à examiner pour chacun des 19 canaux de traction quel serait le meilleur moyen de les utiliser.

L’objectif ici est de vous pousser à envisager sérieusement chaque possibilité.

En vous forçant à imaginer une solution pour chaque canal, vous vous permettez de vous libérer de vos biais et aprioris.

Les canaux de traction et leurs fonctions

Acquérir des prospects qualifiés

Les blogs spécialisés
La publicité sur le web et les réseaux sociaux
Le Search Engine Marketing
Le Search Engine Optimization
Les salons professionnels

Convertir des prospects en clients

L’email marketing
Le marketing de contenu

Faire connaître sa marque

La publicité (journaux, magazines, TV)
RP non conventionnelles
La publicité hors-ligne (Affichage / Radio / TV)
L’événementiel (Sponsoring / organisation)
La prise de parole en public

Communication de masse

Le marketing par l’ingénierie
Le marketing viral (recrutement des nouveaux clients par les clients existants)
Les programmes d’affiliation
L’exploitation des plateformes (Réseaux sociaux / marketplaces)

Renforcer sa position au sein de son marché

Le développement business (Partenariats)
La vente
La création de communautés

L’anneau central – Le probable

La seconde étape du Bullseye va vous demander de tester les canaux les plus prometteurs.

À partir de toutes les idées formulées dans l’anneau extérieur, il vous faudra sélectionner celles qui vous semblent être les meilleures, et les tester concrètement.

Il va donc vous falloir mener des tests pour chacun des canaux que vous aurez conservé.

De plus, il vous faudra paralléliser ces tests, afin de pouvoir passer à la dernière étape le plus rapidement possible.

Pour chaque canal, il vous faudra établir une procédure de test permettant de répondre aux 3 questions suivantes :

  1. Combien coûte l’acquisition d’un seul client avec ce canal ?
  2. Combien peut-on atteindre de potentiels clients avec ce canal ?
  3. Est-ce que les clients que vous pouvez atteindre via ce canal sont ceux dont vous avez besoin à cet instant ?

Il faut cependant garder en tête que le but est de tester, et non de monter à l’échelle.

Votre préoccupation principale ne doit pas être d’acquérir des nouveaux clients, mais de récolter des données.

Tests de l’anneau central

L’objectif des tests de l’anneau central est de trouver une stratégie de canal prometteuse sur laquelle se concentrer.

Une stratégie de canal est un moyen particulier d’acquérir de la traction à l’aide d’un canal spécifique.

Quand on a des ressources limitées, comme dans une startup, il n’est pas possible d’optimiser plusieurs stratégies en même temps.

Il va donc vous falloir mettre en place plusieurs petits tests facilement mesurables qui vous apporteront des données pertinentes afin de pouvoir sélectionner la meilleure stratégie à mettre en place par la suite.

L’anneau intérieur – Ce qui fonctionne

La dernière étape du Bullseye vous amène à vous concentrer sur le canal qui apporte le plus à votre entreprise : votre canal-cœur.

Si les étapes précédentes ont été effectuées correctement, un des canaux testés devrait produire des résultats plus prometteurs que les autres.

C’est votre canal-coeur.

Votre travail consiste maintenant à concentrer tous vos efforts dessus.

Dans le cas où vous n’auriez pas trouvé votre canal-cœur une fois arrivé au centre du Bullseye, il va vous falloir recommencer depuis l’anneau extérieur, en prenant en compte les données que vous avez récolté.

Optimiser sa stratégie de traction

Une fois arrivé au centre du Bullseye, il ne vous restera qu’une seule chose à faire : optimiser votre stratégie de traction.

Seulement, se concentrer sur un unique canal demande beaucoup de ressources.

Votre canal-cœur représente le canal de traction le plus pertinent et efficace pour votre entreprise aujourd’hui, mais rien ne dit qu’il le restera éternellement.

Ainsi, il faudra constamment vous assurer que votre canal-cœur est toujours pertinent au sein de votre stratégie, malgré les transformations de votre produit et de votre entreprise.

Et si un jour ce n’est plus le cas, il n’y a aucun mal à repasser par le Bullseye.

Acheter Traction: How any startup can achieve explosive customer growth :

https://www.eyrolles.com/Entreprise/Livre/traction-9782856083574/?ae=543

Traction

Dans le domaine des startups, la traction est la preuve quantitative que la demande existe pour votre offre.

Un signe que votre produit intéresse vos clients, rendu évident par les métriques que vous mesurez.

La traction, c’est justement tout le sujet d’un livre sobrement intitulé Traction: How any startup can achieve explosive customer growth, écrit par Gabriel Weinberg, fondateur de DuckDuckGo, et Justin Mares, fondateur de Kettle & Fire.

Traction n’a qu’un seul et unique but : vous apprendre comment générer de la traction.

Il rentre très vite dans les détails, et se veut surtout être le plus exhaustif possible. C’est pourquoi je ne peux que vous recommander de le lire vous-même.

Ce n’est d’ailleurs pas tant un livre à lire d’une traite qu’un livre à laisser traîner sur son bureau et à rouvrir au moment opportun.

Il n’est pas particulièrement plaisant à lire, et même un peu assommant. C’est un guide sur la traction, et c’est probablement l’un des plus exhaustifs que l’on puisse trouver.

Ceci étant dit, voici quelques concepts qu’il est possible de trouver dans Tractions, sans pour autant rentrer dans les détails :

Qu’est-ce que la traction ?

« Une startup est une entreprise conçue pour grandir rapidement.
Il ne suffit pas à une entreprise d’être nouvelle pour en faire une startup.
Il n’est pas non plus nécessaire pour une startup de travailler dans la tech, ou de lever des fonds.
La seule chose essentielle est la croissance.
Tout ce que nous associons aux startups dépend de la croissance. »

Paul Graham, fondateur de Y Combinator

La traction, c’est la croissance. La poursuite de la traction est ce qui définit une startup.

Il est toujours possible d’obtenir plus de traction. Cela revient à améliorer sa courbe de croissance.

Il n’existe pas une manière unique de mesurer la traction. Cela dépendra toujours de votre startup et de ce que vous proposez.

Peut-être que dans votre cas, ça sera l’évolution du nombre de téléchargements de votre application, peut-être qu’il s’agira de l’évolution de votre chiffre d’affaires, ou peut-être que ce sera encore autre chose.

Les canaux de traction

Il existe différents canaux permettant aux startups d’acquérir de la traction.

Ces canaux, on les appelle « canaux de traction ».

Dans la plupart des cas, les fondateurs de startups n’utilisent que les canaux de traction qui leur sont familiers.

C’est une erreur.

La réussite ou l’échec d’une startup dépendra souvent des canaux sous-utilisés et inutilisés.

Les 19 plus importants

En tout, il existe 19 canaux de traction, et chacun vous aidera d’une manière différente :

Acquérir des prospects qualifiés

⚙️ Les blogs spécialisés
🌐 La publicité sur le web et les réseaux sociaux
🔍 Le Search Engine Marketing
⚙️ Le Search Engine Optimization
🧑‍💼 Les salons professionnels

Convertir des prospects en clients

📨 L’email marketing
📝 Le marketing de contenu

Faire connaître sa marque

📺 La publicité (journaux, magazines, TV)
↕️ RP non conventionnelles
📻 La publicité hors-ligne (Affichage / Radio / TV)
⚽️ L’événementiel (Sponsoring / organisation)
💬 La prise de parole en public

Communication de masse

🔧 Le marketing par l’ingénierie
↔️ Le marketing viral (recrutement des nouveaux clients par les clients existants)
🔗 Les programmes d’affiliation
👥 L’exploitation des plateformes (Réseaux sociaux / marketplaces)

Renforcer sa position au sein de son marché

🤝 Le développement business (Partenariats)
💰 La vente
🪢 La création de communautés

Penser traction

« La leçon numéro une que l’on enseigne aux entrepreneurs que nous voulons soutenir, c’est qu’ils se concentrent trop sur leur produit, au détriment du reste.
Beaucoup d’entrepreneurs travaillant sur des produits géniaux n’ont tout simplement pas de bonne stratégie de distribution.
Le pire, c’est quand ils insistent sur le fait qu’ils n’en auraient pas besoin, ou quand ils appellent leur absence de stratégie de distribution une ‘campagne de marketing viral’. »

Marc Andreessen, co-fondateur de Netscape

Toutes les startups qui ont échoué avaient un produit, alors que toutes les startups qui ont réussi ont des clients.

Beaucoup d’entrepreneurs concentrent tous leurs efforts sur la création d’un produit, mais finissent dévorés par la frustration lorsqu’ils se rendent compte que les clients ne viendront pas.

La conclusion semble évidente : la traction est aussi importante que le produit.

Par conséquent, il n’y a pas de meilleure solution que la règle des 50%, consistant à diviser son temps en 2 :

  • 50% sur le produit
  • 50% sur la traction

En vérité, même en ayant un produit pour lequel il y a de la demande, vous n’êtes pas sûr de pouvoir générer de la traction.

Il est très inconfortable de délaisser le développement du produit au profit de celui de la traction, en particulier au début du projet.

Seulement, si vous ne suivez pas la règle des 50% dès le début de la conception produit, vous prenez le risque que l’un de ces pièges se referme sur vous :

  • Il n’y a pas de marché, et donc vous ne trouverez aucun business model viable
  • Le marché est trop petit, et vous n’aurez jamais assez de clients
  • L’acquisition de nouveaux clients dans votre marché coûte trop chère
  • Vous êtes dans un marché hyper-concurrentiel et vous n’arriverez pas à vous démarquer

La traction doit servir un objectif

La traction, c’est la croissance, et la croissance doit servir un objectif.

Elle doit avoir du sens pour le développement de l’entreprise,.

Autrement, elle ne sert à rien.

Cet objectif peut être d’effectuer une levée de fonds, ou encore d’atteindre la rentabilité. Des choses pour lesquelles il est important d’augmenter considérablement son nombre d’utilisateurs ou de clients.

La traction que vous avez besoin de générer n’est pas forcément la même selon votre objectif.

Dans le cas d’une levée de fonds, une croissance de 10% suffit généralement à être bien vu par des potentiels investisseurs.

Stratégie de traction

L’obtention de la traction se fait en 3 phases :

  1. Création d’un produit correspondant à une demande
  2. Obtention du Product/Market Fit, en communiquant le bon message à la bonne audience
  3. Mise à l’échelle (scaling) grâce à un business model viable

De la même manière que la traction doit servir un objectif, la traction ne peut s’obtenir qu’à l’aide d’une stratégie réfléchie.

Une fois que vous aurez défini votre objectif, il vous faudra établir un plan pour générer la traction dont vous avez besoin.

On appelle le Chemin Critique le chemin vous menant à votre objectif en passant par le moins d’étapes possibles.

Ainsi, le rôle d’une stratégie de traction est d’être le plus simple possible et d’aller droit au but.

Une stratégie de traction ne concerne pas uniquement les canaux de traction que vous allez utiliser, elle concerne également la conception de votre produit et la façon dont vous allez gérer les ressources de votre entreprise.

Ajouter une fonctionnalité spécifique à votre produit peut contribuer à améliorer votre traction, mais accomplir toutes les requêtes de vos clients ne vous aidera pas pour autant.

Vous devrez rester critique vis-à-vis des fonctionnalités à implémenter, et vous demander si cela servira votre stratégie d’acquisition ou non.

Une startup fonctionne à partir d’une quantité limité de ressources, aussi bien humaines, que temporelles, que financières.

Le principe du Chemin Critique est justement de vous aider à utiliser ces ressources au mieux sans les gaspiller.

Lorsque vous sortez de votre Chemin Critique, vous prenez le risque d’entrer en compétition avec des organisations bien plus puissantes que la vôtre.

De plus, il faut bien comprendre que le Chemin Critique n’est pas quelque chose de figé dans le temps.

Il vous faudra le réévaluer, au fur et à mesure de l’évolution de votre produit et des tests que vous mènerez sur les différents canaux de traction.

Oublier ses biais

Nous l’avons vu précédemment :

Dans la plupart des cas, les fondateurs de startups n’utilisent que les canaux de traction qui leur sont familiers.

La réussite ou l’échec d’une startup dépendra souvent des canaux sous-utilisés et inutilisés.

Il est tout à fait normal d’avoir des biais vis-à-vis de certains canaux de traction.

Avec 19 canaux existants, il serait étrange d’avoir la même affinité avec chacun d’entre eux.

Pour autant, se laisser passer à côté d’un canal spécifique, c’est également se laisser passer à côté d’un potentiel générateur de croissance.

Il vous appartient donc d’envisager sérieusement les canaux que vous avez tendance à mettre de côté, ou que vous voyez négativement.

That’s all Folks!

Acheter Traction: How any startup can achieve explosive customer growth :

https://www.eyrolles.com/Entreprise/Livre/traction-9782856083574/?ae=543

Concevoir une blockchain en un été

Parfois, on a des idées à la con.

Essayer de coder une blockchain de zéro en est sûrement une.

Seulement, c’est ce que j’ai passé l’été à faire, donc autant tout documenter ici.

Pavé César, ceux qui n’ont pas lu te saluent : voici Muffin Network.

Une blockchain Proof-of-Stake qui n’est pas stupide et dont le développement a débuté en mai 2022.

Pourquoi

Il existe des dizaines de blockchains différentes. Certaines sont spécialisées dans l’infrastructure, d’autres dans le scaling, mais aucune n’est vraiment agréable à utiliser, que ce soit par les utilisateurs comme par les développeurs.

Elles manquent de simplicité et d’intuitivité.

Apporter de la simplicité à une solution technologique nouvelle et complexe n’est pas une chose facile, mais il s’agit de ce vers quoi doit tendre toute innovation.

Dès le départ, le but de Muffin était de proposer une solution simple à utiliser, et sur laquelle il est simple de développer des applications.

Pour cela, il fallait apporter ce qui fera la différence pour les utilisateurs et les développeurs.

L’utilisateur final n’en a rien à faire de comment le moteur fonctionne sous le capot, il veut une voiture qui avance.

Un utilisateur de blockchain doit pouvoir effectuer des transactions facilement, ainsi que gérer son identité virtuelle. Il n’a pas besoin de connaître les détails, il veut que ça marche.

Un développeur veut pouvoir développer et déployer ses applications rapidement et facilement. Lui non plus n’a pas forcément besoin de connaître tous les détails. Il lui faut juste savoir comment va s’exécuter son application et dans quelles limites. Pour le reste, il faut lui faciliter le travail au maximum.

Pour ces raisons, Muffin ne devait pas simplement être une blockchain, mais une solution complète centrée autour d’une blockchain

Tous les choix de conception de Muffin devaient donc découler de ces principes.

Fonctionnement

Système économique

La première étape de la conception consistait à choisir un système financier et économique cohérent, ce que la plupart des blockchains n’ont pas.

Bitcoin est souvent vanté pour sa réserve limitée de jetons, mais c’est en réalité une mauvaise idée.

À ce jour, la distribution de Bitcoins est toujours en cours, près de 13 après le lancement de la blockchain, mais le réseau aura rapidement un problème de liquidité s’il devient un véritable moyen de paiement.

Aussi révolutionnaire la technologie Blockchain soit-elle, elle ne peut pas pour autant se soustraire aux lois de l’inflation, de la déflation, et de la distribution de la liquidité.

En l’état, Bitcoin est parfait en tant qu’or numérique, mais ce n’est pas un système économique tenant compte des réalités.

D’autres blockchains telles qu’Ethereum comportent un système de contrôle de l’inflation et de la déflation, si tant est que l’on puisse appeler ça comme ça.

Le problème, c’est que l’émission de nouveaux jetons se fait toujours par les mineurs/validateurs. Or, les mineurs sont probablement les acteurs les moins indiqués pour distribuer ces jetons, d’autant plus dans un système Proof-of-Stake où ils pourraient être tentés de les staker.

Donc, quelle alternative à tout ça ?

Mon idée initiale était de recopier ce qui marche déjà, c’est-à-dire le système des banques centrales.

Il y avait un petit problème cependant : comment transposer le système de planche à billets des banques centrales dans un système décentralisé où personne en particulier n’a le contrôle ? Comment sanctionner un créancier malhonnête ?

Comment faire pour que les utilisateurs puissent emprunter de l’argent à la blockchain elle-même ? Que faire en cas de défaut de paiement ?

Il est évident que toutes ces questions ont une réponse, mais le morceau était trop gros pour une première approche.

J’ai donc décidé d’explorer des systèmes alternatifs, mais toujours ancrés dans notre réalité économique.

Il était tout à fait possible d’utiliser une planche à billets, le problème était la distribution.

S’il n’était pas possible de distribuer des nouveau jetons en échange d’une créance, il était tout à fait possible de les distribuer à tout le monde, lors d’évenements définis, en même temps sans contrepartie.

Si on ne peut pas financer l’investissement, on peut toujours financer la consommation.

Mieux que la planche à billets : l’hélicoptère monétaire.

Le but était donc devenu d’avoir assez de liquidité pour tous les utilisateurs uniques du réseau.

Voulant déjà implémenter une gestion de l’identité au sein de Muffin, l’idée était toute trouvée.

La masse monétaire serait indexée sur le nombre de « Muffin ID », et à chaque fois qu’un nouvel ID serait créé, un certain nombre de Floats (la cryptomonnaie officielle de Muffin) seraient distribués de manière égale entre tous les possesseurs d’IDs.

Choix technologiques

Muffin n’est pas la blockchain la plus élaborée, ni la plus optimisée.

Bitcoin et Ethereum reposent sur des concepts mathématiques et d’informatique théorique que je ne maîtrise pas.

Je suis donc allé au plus simple, avec les technos que je connais et ce qui a déjà fait ses preuves.

Muffin est écrite en Typescript, est exécutée avec Node JS, et utilise Level comme base de donnée.

Certes, Ethereum est écrite en Go, et Go est bien plus rapide, mais Typescript reste à mon sens le langage le plus lisible et avec lequel il est le plus facile de concevoir en partant de zéro.

Même si les deux blockchains ne partagent pas le même langage, Muffin hérite tout de même de quelques concepts d’Ethereum :

  • Le système clé/adresse est le même. Votre clé privée d’Ethereum vous permettra d’utiliser la même adresse sur Muffin.
  • Une API RPC à peu près fonctionnelle permettant une certaine compatibilité avec les portefeuilles EVM-compatible tels que Metamask
  • Un système de hashage similaire. Une transaction comportant les mêmes données aura le même hash sur Ethereum et sur Muffin.

En revanche, Muffin se distingue sur un certain nombre de points :

  • Une API REST (plus ou moins) CRUD
  • Le gas est remplacé par des frais calculés sur le montant de la transaction. Le gas est conçu pour motiver les validateurs, il n’a pas besoin de dépendre de l’offre et de la demande, juste d’exister.
  • Les contrats sont écrits en Javascript. Le web est écrit en Javascript, et la blockchain, c’est du web.

Les Muffin IDs

Floater homepage

Un Muffin ID, c’est une pièce d’identité stockée sur la blockchain.

L’objectif était de fournir un moyen de s’authentifier sur le web facilement de manière fiable, récupérable, tout en protégeant la vie privée des utilisateurs.

C’est avec ces idées en tête que j’ai conçue les Muffin IDs de cette façon :

  • Tous les champs sont chiffrés avec des clés différentes
  • Les différentes clés sont obtenues à partir d’une clé principale
  • La clé principale permet de modifier certains champs de l’ID et de le transférer d’une adresse vers une autre.
  • Seule la clé principale permet d’utiliser le Muffin ID. Même en cas de piratage de l’adresse qui lui est associée, l’ID n’est pas compromis.

Nights & Weekends

Buildspace Night and Weekends

En juin j’ai postulé pour faire partie de la première session du programme Nights & Weekends de Buildspace.

Ce programme, un combo de Y Combinator et de Stanford d’après son créateur, avait pour but de prendre 500 « builders » et de les accompagner pendant 6 semaines pour qu’ils lancent leur propre projet.

J’ai été accepté, comme beaucoup parce que j’avais déjà lancé des projets par le passé.

Chaque semaine pendant 6 semaines, j’ai donc dû expliquer ce sur quoi j’avais travaillé et faire une démo.

Cela peut sembler inutilement contraignant, mais le fait de devoir rendre des comptes sur mon avancée m’a permis de planifier mon travail et de me forcer à respecter les délais, et donc d’aller beaucoup plus vite.

À la fin des 6 semaines, on nous a demandé d’exposer notre projet au salon virtuel Nights & Weekends Demo Day. Je suis content d’y avoir participé, car je ne pensais honnêtement pas tenir jusqu’à la fin des 6 semaines, et surtout c’était une épreuve que je redoutais particulièrement.

À la fin du programme, nous étions environ 150 participants à recevoir notre certificat sous forme de NFT attestant que nous avions été actif pendant les 6 semaines et que nous avions exposé à Demo Day, c’est-à-dire 30% de la promotion initiale.

Pour ma part, Nights & Weekends était une expérience très enrichissante. Je recommande à quiconque souhaitant lancer un projet d’y participer.

La partie émergée de l’iceberg

Une blockchain n’est pas un outil utilisable par le grand public. Il lui faut une couche d’abstraction.

Pour Muffin, cette couche d’abstraction se divise en 2 parties :

  1. Floater, un portefeuille crypto permettant au grand public d’envoyer des transactions et de créer un Muffin ID
  2. DevsHub, une plateforme hébergeant de la documentation et des outils pour les développeurs.

Floater prend la forme d’une application web, pensée pour le mobile, intuitive visant à faciliter le transfert d’argent entre les utilisateurs de Muffin ainsi que la gestion de leur Muffin ID.

Floater permet de :

  • Effectuer un virement d’un utilisateur vers un autre
  • Générer un QR Code de paiement contenant un destinataire et une somme due
  • Scanner un QR Code de paiement
  • Consulter l’historique des transactions
  • Créer un Muffin ID
  • Récupérer un Muffin ID associé à une autre adresse
  • Scanner des QR Codes d’authentification pour s’identifier avec un Muffin ID

Au niveau des technologies utilisées, je suis allé au plus simple en utilisant Next.js, avec la librairie graphique NextUI, encore en bêta.

Développer sur Muffin

L’un des enjeux de Muffin est de faciliter la vie aux développeurs.

C’est dans cet objectif que j’ai créé 2 modules JS :

  • muffin-utils, facilitant le développement de contrats pour Muffin
  • muffin-sdk, permettant l’implémentation de Muffin au sein de sites, applications et serveurs web

Le but de muffin-utils est de fournir des structures de contrats prêtes à l’emploi, avec le minimum de choses à écrire.

Celui de muffin-sdk est de permettre aux développeurs web d’ajouter Muffin à leurs applications le plus rapidement possible, avec leurs infrastructures existantes.

DevsHub permet également de générer des widgets d’authentification et de paiement sans avoir à écrire de code.

Pay with Muffin

Le widget Pay with Muffin peut être généré grâce à muffin-sdk et également sans code depuis DevsHub.

Il prend une adresse et un montant en paramètres, éventuellement un champ de données, et génère un QR Code pouvant être scanné depuis Floater.

Il s’agit de la manière la plus simple de se faire payer via Muffin.

Sign in with your Muffin ID

Le widget Sign in with your Muffin ID permet de s’authentifier avec un Muffin ID juste en scannant un QR Code.

Il n’est pas encore totalement sécurisé dans le sens où malgré le chiffrage des Muffin ID, il peut être assez facile de faire croire à un service peu regardant que l’on possède la bonne clé.

Marketing

Le marketing de Muffin a débuté durant Night & Weekends, puisque l’un des ateliers proposé était centré autour.

Mon utilisation théorique des différents canaux était la suivante :

  • Twitter pour faire connaître la marque, en expliquant les différents concepts de Muffin et en montrant l’avancée du projet
  • Discord pour fonder une communauté et lui permettre d’interagir (voir l’article sur Tribus)
  • Une landing page pour pouvoir rediriger vers Floater, DevsHub, et le serveur Discord

L’idée était d’attirer les utilisateurs via des distributions gratuites de Floats afin qu’ils puissent créer leur propre Muffin ID.

Ces distributions étaient annoncées sur plusieurs subreddits, mais il y a eu peu de résultats concluant de ce côté-là.

Et ensuite ?

Muffin n’est peut-être pas la solution idéale pour répondre au problème initial.

Avec le temps, elle s’est suffisamment complexifiée pour se rapprocher de ce qui se fait déjà en termes de complexité.

Peut-être que les blockchains ne sont tout simplement pas des services destinés au grand public et devraient être totalement invisibles aux yeux des utilisateurs finaux.

Peut-être aurait-il fallu centré l’expérience sur le développement et laisser les développeurs construire les outils grand-public sur cette base.

Il va donc falloir choisir entre persévérer, faire pivoter le projet, ou le ranger au placard.

Tribus

Pour plus de résumés de lectures, cliquez ici.

Tribus est l’un des livres les plus connus de Seth Godin, un spécialiste du marketing viral qui s’est fait connaître grâce à ses nombreux livres et à sa vision à contre-courant de ce que doit être le marketing.

Bien plus qu’un simple manuel de marketing, ce livre est également un manifeste appelant le lecteur à devenir un meneur.

« Si vous pensez que le leadership, c’est pour les autres, vous vous trompez. »

Pour Seth Godin, il s’agit beaucoup plus de mener un groupe vers un objectif plus grand que de simplement communiquer autour d’un produit.

Les tribus

L’auteur décrit le concept de tribus comme suit :

Une tribu est un groupe de personnes connectées entre elles, connectées à un leader, et connectées à une idée.

Un groupe n’a besoin que de deux choses pour constituer une tribu : un intérêt commun et une façon de communiquer.

Il n’y a pas de tribu sans leader, et pas de leader sans tribu.

La place du marketing

Le marketing est l’art de raconter des histoires sur ce que nous faisons, des histoires qui font vendre et des histoires qui se répandent.

Autrefois, le marketing était surtout une affaire de publicité.

Aujourd’hui, le marketing consiste à créer le contact avec la tribu et à fournir des produits et des services avec des histoires qui se propagent.

Quelques points clé

Les bases

💡 L’innovation intéresse plus que ce qui a déjà fait ses preuves. Ceux qui adoptent les tendances dès la première heure sont également ceux qui influencent autour d’eux.

⚡️ Soyez transgressif. Les gens rêvent de changement et veulent parler de choses extraordinaires.
Vous devez trouver des gens prêts à vous soutenir et qui croient en vous, plus que de simples consommateurs.

↔️ La communication horizontale est aussi importante que la communication verticale. Un mouvement se concrétise lorsque les gens communiquent entre eux et échangent leurs idées.
La communication entre le leader et sa tribu est essentielle, mais rien n’est possible si les membres ne se parlent pas.

✌️ Il suffit de 2 choses pour développer une tribu. Un objectif né d’un désir de changement, et un moyen de communication.

👥 La frontière entre une tribu et une foule est très fine. Une foule est une tribu sans leader, et donc sans communication.

Les bonnes pratiques

🙌 Vous n’avez besoin que de 1000 vrais fans. Un vrai fan est un membre de votre tribu qui s’intéresse vraiment à vous et ce que vous faites et qui fera tout ce qui est en son pouvoir pour vous soutenir.
Les vrais fans sont la fondation des tribus. Il n’en faut pas beaucoup, mais ils soutiennent toute la structure.

🗣 Une tribu qui communique rapidement et avec passion est une tribu qui prospère. Le rôle du leader est de resserrer les liens entre les membres de sa tribu et d’apporter de la coordination.

2️⃣ Il y a 2 types de marketing : le 1er type consiste à atteindre des personnes avec un message pour fonder une tribu.
Le second consiste à resserrer les liens entre les membres de la tribu.

🫥 Essayer de mener tout le monde revient à ne mener personne. Concentrez-vous sur les gens qui ont décidé de vous suivre.
Les autres sont libres de vous ignorer ou d’être en désaccord.

🚀 Plus grand n’est pas toujours la réponse. Certains organismes s’améliorent en grandissant.
D’autres, non. Certaines tribus prospèrent justement car elles sont petites.

🥸 Tenez vos positions. Un bon leader se souvient toujours de ce sur quoi il ne peut pas faire de compromis.

Lancer un mouvement

Pour créer votre propre mouvement, vous pouvez suivre ces 5 étapes :

  1. Publiez un manifeste.
  2. Faites en sorte que ceux qui vous suivent puissent se connecter à vous facilement.
  3. Facilitez l’interconnexion de ceux qui vous suivent.
  4. Comprenez que l’argent n’est pas la raison d’être d’un mouvement.
  5. Partagez votre progression.

… et suivre ces 6 principes :

  1. La transparence est votre seule option
  2. Votre mouvement doit être plus grand que vous.
  3. Les mouvements qui grossissent prospèrent.
  4. Le sens d’un mouvement s’éclaire lorsqu’il est comparé au statu quo et aux mouvements allant dans une direction opposée.
  5. Excluez les indifférents.
  6. Mettre les autres en pièces n’est jamais aussi utile que de construire de façon positive le réseau de gens qui vous suivent.

Acheter Tribus – Nous avons besoin de vous pour nous mener : https://www.eyrolles.com/Entreprise/Livre/tribus-nous-avons-besoin-de-vous-pour-nous-mener-9782354564186/?ae=543

Comment se faire des amis et influencer les gens

Pour retrouver mes autres résumés de livres, cliquez-ici.

Comment se faire des amis (ou How to win friends & infuence people dans sa version originale) de Dale Carnegie regorge de conseils intéressants, en dépit de son titre qui vous fera passer pour un sociopathe si vous faites l’erreur de sortir le livre dans le bus ou le métro.

La promesse de cet ouvrage est d’aider son lecteur à développer des relations humaines de qualité.

De prime abord, il s’agit de livre de développement personnel, mais il devient vite évident que les astuces qui y sont prodiguées peuvent également être utilisées à des fins marketing, ou dans le pire des cas, de manipulation.

En voici quelques-unes :

Des astuces pour des relations de qualité

🤡 Ne critiquez pas les autres. Lorsque vous critiquez les autres, vous ne créez que du ressentiment, mais jamais de changement positif.

✨ Souvenez-vous que les gens souhaitent se sentir importants. Vous vous ferez bien plus d’amis en vous intéressant sincèrement aux autres et en leur faisant des compliments honnêtes qu’avec n’importe quelle autre méthode.
Vous n’intéressez pas les gens, les gens sont intéressés par eux-mêmes.

🥸 Mettez vous à la place des autres pour pouvoir les influencer. Le seul moyen d’influencer une autre personne est de lui parler de ce qu’elle veut et lui montrer comment l’obtenir.

🧠 Souvenez-vous des prénoms. La plupart des gens sont plus intéressés par leur prénom que par tous les autres sons de l’univers.
Mémoriser le prénom de quelqu’un et l’utiliser permet de lui montrer que vous l’appréciez et que vous vous intéressez à lui.

🤫 Fermez-la et écoutez. La plupart des gens désirent un auditeur attentif pour pouvoir se mettre en valeur et se décharger.
Soyez un bon auditeur et encouragez les autres à parler d’eux-mêmes.

🕳 On ne peut pas gagner un débat ou une dispute. Le seul moyen de tirer le meilleur d’un débat est de l’éviter.
Neuf fois sur dix, chaque participant repart de son côté avec les mêmes convictions qu’avant. Les seules choses à faire sont d’accepter le désaccord, d’éviter de se mettre sur la défensive, et de chercher des erreurs à admettre.

🛤 Ne forcez pas les autres à accepter vos idées. À la place, laissez les arriver à votre conclusion par eux-mêmes.

Des astuces pour diriger

🏆 Organisez des compétitions. Le désir d’exceller est la clé infaillible pour engager l’esprit des gens.
Permettez aux gens de prouver leur valeur et de se sentir important si vous souhaitez les stimuler.

🙆‍♂️ Commencez les conversations difficiles par un compliment. Il est plus facile d’entendre des choses désagréables si on a entendu des choses agréables avant.
Si vous devez formuler un reproche, commencez-la par un compliment sincère. Cela agira comme un antidouleur et l’autre personne sera plus compréhensive.

🙅 Il ne faut jamais dire « mais ». Même si vous avez fait un compliment avant de formuler votre reproche, vous pourriez tout faire échouer simplement en les séparant par le mot « mais ».
Le mot « mais » instaure un contraste entre les 2 affirmations, et votre compliment sera alors perçu comme un joli mensonge qui vise à vous ménager.
En remplaçant le mot « mais » par le mot « et », vous pouvez supprimer ce contraste et l’autre personne sera alors en capacité d’accepter le compliment.

Exemple : « C’est bien que tu fasses plus d’efforts, mais tu n’as toujours pas atteint les objectifs. » devient « C’est bien que tu fasses plus d’efforts, et si tu continues dans cette direction, tu seras bientôt capable d’atteindre les objectifs. »


🤦‍♀️ Parlez de vos propres erreurs. Il est moins difficile de faire face à ses erreurs lorsque la personne qui nous critique admet qu’elle en fait également.

🫵 Ne donnez pas d’ordres. Personne n’aime les ordres.
Laissez aux autres l’opportunité de faire les choses d’eux-mêmes et laissez-les apprendre de leurs erreurs.

🙇‍♂️ Laissez l’autre personne sauver les apparences. Même si vous avez raison et que l’autre a tort, n’humiliez jamais l’autre.

🙌 Encouragez les autres pour qu’ils réussissent. Complimenter la moindre petite amélioration permet d’encourager les autres à poursuivre leurs efforts.
Même si la personne commet une erreur, montrez-lui qu’elle est facile à corriger afin qu’elle fasse tout pour exceller.

Acheter Comment se faire des amis de Dale Carnegie : https://www.eyrolles.com/Loisirs/Livre/comment-se-faire-des-amis-9782253009108/?ae=543