L’Impact Mapping s’invite au French SUG !

Décidément, cette nouvelle année du French SUG voit émerger une nouvelle dynamique : celle de permettre aux membres de la communauté d’être acteur des évènements ! D’accord, pour l’évènement de février on peut argumenter que je suis un ancien membre du bureau… Mais ce n’est pas le cas de celui-ci . Il a été imaginé par Géraldine Legris, épaulée par Dragos Dreptate.

image

A l’image de la soirée « en finir avec… », cette rencontre prend la forme d’un open-space. Le principe est simple et commence à être bien connu, ne revenons pas dessus. Le thème est encadré, certes. On dispose de 2 créneaux horaires et 3 salles qui seront finalement 4 ! Une restitution en fin de première session, pour la seconde, ce sera autour des pizzas !

La place de marché est rapidement alimentée et il ne reste plus qu’à faire son choix. Pas mal de monde ne connait pas en fait l’Impact Mapping ! Pour toi, cher lecteur, sache que j’avais fait une note de lecture sur le livre éponyme et que Gojko Adzik était venu en parler dans les locaux de Zenika !

Session 1 : un « why mesurable »

Ce point précis est souvent vu comme une difficulté, et s’en est bien une. Mais c’est aussi une aide, car ne pas avoir de mesure signifie souvent que l’on encore dans le moyen et non dans le « pourquoi » ! Un certains nombre d’idés et pratiques remontent rapidement :

  • Le « why » est notre pôle nord, la direction à prendre sans nécessairement devoir l’atteindre.
  • L’impact est notre boussole, qui nous indique si nous sommes dans la bonne direction.
    • Les OKR : Objective Key Results.
    • Les NPS : Net Promoter Scores.

Bien sûr, rapidement la conversation dévie sur des sujets connexes : User Story mapping et le problème de la convergence sur le why… Il est temps de passer à la restitution !

Restitution !

C’est Géraldine qui se charge de la restitution pour le groupe. Inutile de revenir là-dessus.

L’impact mapping de la soirée

Beau challenge que s’était donné l’une des équipes : construire un impact mapping sur la soirée elle-même ! Une sorte de paradoxe auto-référençant… Laurent se charge de la restitution.

La construction de la map a donné lieu à 2 difficultés :

  • D’abord converger sur un même objectif quantifiable. Au final celui qui est choisi me semble sujet à caution. Mais l’exercice est difficile.
  • Choisir dans quel sens construire la map ! Descendant ou montant 

Finalement, l’équipe aura utilisé les deux directions alternativement. C’est en fait ce qu’on fait dans la vraie vie !

Qu’est-ce que l’Impact Mapping

C’était le track « débutant », mais qui manquait un peu de praticiens expérimentés pour aider ! Le group a donc exploré diverses questions liées à l’impact mapping :

  • L’impact Mapping permet de redonner du sens à ce que l’on fait !
  • Comment se positionne l’Impact Mapping par rapport au Story Mapping ?
  • La construction d’un impact mapping conduit à des cycles successifs de divergence / convergence à l’image de ce que l’on fait en Design Thinking. Cette alternance évite l’effet fractal des mind-maps et induit une sorte de « respiration ».
  • Qu’il y a-t-il au delà de l’Impact Mapping ? Les cartes heuristiques ?

Second créneau

Impact Mapping et Lean Startup

L’Impact Mapping et le Lean Canvas sont deux outils qui me semblent pertinents pour donner du sens à ce que l’on construit, de manière agile. Mais sont-ils concurrents ou complémentaires ? Peuvent-ils s’utiliser en association ? Si oui, comment ? Voilà des questions sur lesquelles je reste pour l’instant complètement sans réponse.

C’est pour réfléchir ensemble à cette question que j’avais choisi ce groupe. Hélas pour moi, la session prend la tournure d’un long exposé.

Non seulement la teneur ne m’intéresse pas, mais je viens aux open-space pour échanger : réfléchir, écouter, enrichir les autres de mes idées et m’enrichir de même. Je ne trouve pas cela ici, je fais marcher la « loi des deux pieds » !

Retours d’expérience

Je m’arrête dans la salle où se discutent des retours d’expérience. Plusieurs sujets d’intérêt sont évoqués :

  • Comment sait-on qu’un Impact Mapping est réussi : lorsque les participants ont envie de continuer !
  • L’impact Mapping crée un effet positif important au niveau des conversations et de l’alignement.
  • Il est important de construire une branche complète (avec les 4 niveaux) assez tôt. Ce premier accomplissement soulage les participants.
  • Il faut rester « macro » sur les impacts. Cet outil n’est pas là pour créer des stories détaillées.
  • C’est un outil utile quand on ne sait pas par où commencer !
  • On peut l’utiliser dans les projets qui ont déjà commencé pour consolider ce qui existe, ou pour s’en servir comme outil de communication.
  • Ce n’est pas un outil « fire and forget » : on l’initialise avec de premiers chemins, puis on revient dessus plus tard, à la lumière de ce que l’on a appris.

Fin de soirée

Sans aller jusqu’à dire que la 3ème mi-temps est ma préférée, c’est au moins un moment dont j’essaie de profiter. Discussions avec Frédéric sur les spécifications et l’agilité, retrouvailles avec Sébastien après 8 ans… Il se fait hélas tard…

Note de lecture : Managing Software Requirements, par Dean Leffingwell & Don Widrig

Note : 7 ; Les exigences selon RUP, avec beaucoup d’éléments sur les pratiques, mais aussi un manque de matière sur la mise en œuvre.

Ce livre traite de la gestion des exigences vue par Rational Unified Process. Les auteurs ont d’ailleurs travaillé sur l’outil Requisit Pro. La lecture en est plaisante, le découpage en nombreux chapitres assez découplés bien que complémentaires y aide beaucoup. Comptez 385 pages pour ce volume qui comprend en sus près de 90 pages d’annexes ! Les 35 chapitres que les auteurs ont concoctés sont divisés, non en parties mais en 8 « skills », une petite subtilité, mais assez intelligente !

En une trentaine de pages comptant quand même 3 chapitres, la première partie fort opportunément appelée « introduction » est vite passée ! Si on s’intéresse aux grands classiques du « pourquoi » des exigences, c’est à dire le coût des exigences erronées, on arrive vite à la définition de ce qu’est une exigence au chapitre 2. C’est ici aussi que l’on introduit la pyramide problème / besoin / solution que j’aime tant ! L’auteur n’oublie pas que le développement logiciel, même dans l’ingénierie des exigences, est une affaire d’hommes et de femmes, il consacre le chapitre 3 à l’équipe et aux compétences. Bref, une première partie tout à fait sympathique.

Ce sont 3 chapitres (sur environ 40 pages) qui sont également consacrés à la seconde partie « Analyser le problème » qui est le premier « team skill » du livre. Nous voilà rentrés dans la matière. L’auteur nous propose 5 étapes pour définir le problème. Les choses sont rarement aussi simples que l’on puisse suivre une telle séquence de manière immuable, mais nombre d’analystes devraient s’inspirer de ce que l’on trouve ici : identification des acteurs, définition du périmètre du système et de ses contraintes et surtout, surtout : l’analyse causale ! La matière proposée concernant l’analyse métier est bien moins convaincante, mais on peut bien excuser de petites faiblesses… Le dernier chapitre de cette partie met surtout en musique ce que nous avons vu avec l’étude de cas du livre : HOLIS. Fort intelligemment, il ne se contente pas de reprendre la matière du chapitre 4, on y ajoute quelques petits éléments comme l’elevator statement.

La 3ème partie, comprendre les besoins utilisateurs, c’est vraiment du sérieux : pas moins de 9 chapitres ici ! De petits chapitres toutefois, car ils totalisent moins de 80 pages. Identifier les besoins utilisateur, ce n’est pas si simple et le chapitre 7 est consacré à ce challenge, même si c’est seulement sur quelques pages. Quelle est la différence entre « feature » et « requirement » ? La plupart du temps, on s’arrête à une bonne zone de flou. Dean Leffingwell nous propose une articulation claire entre besoin / feature et requirement. Savoir questionner est un art essentiel dans l’ingénierie des exigences. Si le sujet n’est pas aussi puissamment investigué que dans « exploring requirements » de Weinberg et Gauge, au moins est-il évoqué de manière non anecdotique. Les workshops sont un complément naturel à cette activité et là encore une matière intéressante et exploitable nous est proposée. Le chapitre qui suit sur le storyboarding est là pour servir d’introduction à celui sur les Use Cases qui va suivre. Il est vrai qu’aujourd’hui, en ingénierie agile, on s’appuiera d’avantage sur le Story Mapping. Oui, bien sûr les cas d’utilisation sont évoqués, c’est forcé ! En fait, ils le sont plusieurs fois dans l’ouvrage, ici on s’arrêtera à la vision d’ensemble. On ne peut évoquer les cas d’utilisation sans parler de rôles, l’occasion pour l’auteur pour évoquer brièvement les cartes CRC, une brièveté certainement frustrante mais il est certainement possible de se reporter sur l’ouvrage de Bellin et Simone si le cœur vous en dit… On termine cette partie très riche par l’évocation des prototypes, à titre d’introduction.

La « team skill 3 », c’est définir le système, on a 3 chapitres pour cela. Comptez 3 chapitres et un peu moins de 30 pages. Oui, un moment, on parle documents et organisation de ceux-ci. Ce n’est pas le plus passionnant, mais au moins le sujet est-il abordé avec une certaine intelligence. Un chapitre est même consacré au document de Vision (avec un template, s’il vous plait), si cher à Philippe Kruchten. Retour à l’aspect humain pour clore le chapitre, avec le Product Champion. Ce qu’on y évoques recoupe pas mal ce qu’aujourd’hui on appelle un Product Owner.

Gérer le périmètre, c’est le sujet de « team skill 4 », qui couvre 4 chapitres sur un peu plus de 40 pages. On commence par le « pourquoi » de cette problématique de périmètre : en quoi est-ce important et dimensionnant. Pour aborder cette question du périmètre, Leffingwell s’adosse aux dimensions suivantes : des priorités qui se ventilent sur des releases, une gestion des risques et de l’effort, le tout illustré avec HOLIS. On trouve là les prémices de SAFe… L’engagement des utilisateurs dans cette gestion de périmètre est évoqué, mais guère convaincante. Personnellement j’ai bien aimé le chapitre 22, non pas parce qu’il évoque RUP (dans lequel l’approche de l’auteur s’inscrit), mais parce qu’il évoque aussi comment la gestion du périmètre a évolué entre le modèle en cascade, le modèle en spirale de Boehm et finalement le modèle itératif.

La partie consacrée au raffinement des spécifications est l’autre grosse partie du livre : 6 chapitres sur un peu plus de 80 pages. On commence par évoquer en profondeur la nature des exigences : comment on différencie le domaine du problème de celui de la solution, ou encore les différents types d’exigence. Le chapitre 23 est particulièrement affuté sur le sujet. S’en suit une introduction sur la spécification des cas d’utilisation. Bel exercice, même s’il ne saurait concurrencer les livres dédiés au sujet (je pense particulièrement à celui de Géri Schneider. Quand on parle de requirements à l’ancienne, on parle souvent de SRS et du fameux IEEE 830-1998. Le sujet n’est pas esquivé. Ambiguïtés et précision font parties des pratiques que doit développer tout analyste. Le sujet n’est qu’effleuré, même s’il l’est plutôt bien. Mais « exploring requirements » ou Tom Gilbs avec Planguage vont au moins un cran plus loin. La question des critères et de la mesure de qualité des spécifications est la mesure de la rigueur de l’analyste. Leffingwell aborde honorablement le sujet, même si je préfère la prose des Robertson dans « Mastering Requirements » à cet égard. On referme cette partie avec une revue des formalisations plus ou moins funkies des exigences : pseudo-code, diagrammes d’état-transition, etc.

La dernière partie « building the right system » reste imposante avec 6 chapitre et plus de 70 pages. Le chapitre consacré à la transition des exigences à la réalisation n’est pas mon préféré et apporte je pense assez peu. La traçabilité est un grand classique. S’il a cessé d’être un centre d’intérêt pour moi, le sujet existe, dommage qu’il soit abordé sous l’angle des outils, tout comme le sera le volet sur le change management. Par contre le test et la validation sont des points d’importance. Ils ne sont peut-être pas traités avec l’importance qu’ils devraient mais ils sont là. J’aurais par contre du mal à cautionner l’approche d’effort de validation par le ROI…

Le point fort de cet ouvrage est l’importance du tour d’horizon qu’il nous imprime sur l’activité d’ingénierie des exigences. C’est probablement l’ouvrage le plus complet à cet égard, et il faut bien avouer que l’on ne s’ennuie jamais. Nombre sinon tous les sujets peuvent nous amener sur des textes plus complets, et c’est très bien.

Au delà de ceci, on regrettera toutefois que le livre se cantonne souvent à la présentation des techniques de capture d’exigences, et que les véritables “guidelines” soient par trop absents, de même qu’un véritable processus de gestion d’exigences capable de cimenter l’ensemble des techniques présentées. Ceci fait que je préfère l’ouvrage de Suzanne et James Robertson, et que je considère celui-ci à la fois comme un complément et un texte embrassant plus large sur les différents volets de l’ingénierie des exigences.
Ce texte a connu deux éditions depuis celle-ci, dont la dernière markettée en agile.

image

Référence complète : Managing Software Requirements, a unified approach – Dean Leffingwell & Don Widrig – Addison Wesley / O.T. series 1999 – ISBN: 0-201-61593-2

Managing Software Requirements: A Unified Approach


https://www.goodreads.com/book/add_to_books_widget_frame/0201615932?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Champfrogs Checklist, un Management Workout par Jurgen Appelo

Pour Jurgen Appelo, le business ne doit plus seulement être adaptatif, il doit être transformatif ! Et pour rendre cela possible, nous devons, en tant que personnes, être des transformateurs. Etre un transformateur dans notre monde super-connecté signifie être soi-même connecté et surtout pouvoir influencer les autres dans la direction qui nous convient.

Où l’on parle de motivation intrinsèque…

Oui, être agent du changement, c’est bien mais en réalité les personnes que nous voulons changer répondent d’avantage à leur part d’irrationnel (leurs envies, leurs peurs) qu’à leur part de rationnel. C’est là qu’interviennent les « moving motivators », la détection des motivations intrinsèques qui servirnt de levier au changement, que Jurgen Appelo a popularisé dans son jeu. L’auteur a lui-même repris Daniel Pink qui les évoquent dans Drive :

  • L’acceptation (par les autres, par les collègues)
  • La nourriture. Ce sont les besoins essentiels, cux qui constituent le niveau de base de la pyramide de Maslow.
  • La famille
  • La liberté, l’indépendance.
  • Le sens. C’est la nécessité de savoir que l’on oeuvre dans un but, pour une finalité.
  • Le sens de l’honneur et de l’intégrité.
  • La compétence et la maîtrise.
  • Le sens de l’ordre et donc de la stabilité. Un besoin qui tire plutôt dans une direction différente des entreprises connecté et du changement.
  • Le pouvoir et l’influence, si chers à nos hommes politiques.
  • La connexion sociale et le besoin de tisser des liens.
  • L’amour. Disons que c’est l’étape suivante !
  • Le sens de la propriété, l’appartenance.
  • Le status social.
  • La sécurité et la tranquilité (retour à la pyramide de Maslow)

On l’on évoque (enfin) le Champfrog

De cette longue série, Jurgen Appelo extrait les éléments qu’il juge pertinent dans le contexte d’une organisation. C’est le fameux acronyme CHAMPFROG.

  • Curiosité : Se demander comment et quoi apprendre, mais aussi donner de la perspective sur les idées des autres.
  • Honneur : Quel est notre engagement de confiance et de responsabilité envers les autres ? Comment construire une confiance réciproque ?
  • Accepation (ou approbation) : De quelle manière notre comportement, nos signes extérieurs sont inclusifs envers les autres ? Utiliser le principe d’association lors de réussite pour construire une acceptation collective.
  • Maîtrise : Comment gagner en compétence et en tant qu’organisation rendre cette acquisition de compétence possible ? Mais aussi : comment valoriser la compétence des autres ?
  • Pouvoir : Montrer son autorité sur un sujet sans faire preuve d’arrogance, c’est l’autorité situationnelle. L’étape suivante est de parvenir à abandonner cette autorité aux autres.
  • Freedom (liberté) : Littéralement, c’est abandonner les contraintes implicites et explicites que l’organisation fait peser sur ses membres pour qu’ils puisse juste faire ce qui est nécessaire…
  • Relations sociales : Etre connecté, c’est d’abord s’ouvrir aux autres. C’est le prémice pour avoir un impact sur les personnes qui nous entourent.
  • Ordre : Il répond à un besoin de simplicité, de limpidité même dans la façon dont une organisation fonctionne.
  • Goal (But) : Pour Jurgen Appelo, la recherche d’un but a à voir avec l’optimisme et l’alignement des besoins de l’entreprise et de ses employés.
  • Statut social : C’est la crédibilité que nous avons et celle que nous accordons aux autres. Sur quels critères est-elle basée ?

Et après ?

Après, il y a le « moving motivator », une activité pour reflechir et expliciter nos motivations… Et bien sûr le présent « workout » !

Agile Playground #19 : austèrement Kanban !

Je ne sais si ce début d’année est synonyme de démarrage en douceur, mais j’ai tendance à trouver nos premiers meetups doucement fréquentés…
Deux jeux au programme de cette 19ème édition et un ice-breaker !

image

Pendant que la glace fond…

L’ice-breaker, c’est en passe de devenir une tradition à l’Agile Playground ! Aujourd’hui, c’est au pied levé que Franck Beulé nous propose une petit activité pour mieux mémoriser le nom des autres participants. C’est là que je m’aperçois que je connais effectivement trois-quart de l’assemblée. Dois-je m’en inquiéter ou m’en réjouir ? Cela reste à déterminer…

image

Arrive le moment du choix : 2 jeux nous sont proposés :

  • Un « business value game » d’un côté.
  • Un « FeatureBan » de l’autre.

Le choix est plus cornélien qu’il n’y parait. En effet, si je connais le Business Value Game, j’ai du mal à apprécier celui-ci. Mais c’est peut-être que mon animation n’est pas au point. Aussi aimerais-je un de ces jours voir comment d’autres l’animent.

Mais ce ne sera pas pour aujourd’hui. Christophe Keromen nous propose un Featureban, qu’il nous présente comme une version austère des jeux Kanban. La tentation est trop grande pour moi !

image

Expérimenter Kanban avec Featureban

Le jeu que nous propose Christophe est une adaptation de celui de Mike Burrows. On peut trouver toutes informations nécessaires et les liens utiles sur le blog de Christophe.

Le principe est simple, simplifié à l’extrême même: Un Kanban avec 4 états et des pièces à passer à « terminé ». Tout est anonymisé : les étapes et les pièces (de simples pièces de Lego). Des tirages au sort déterminent si la pièce peut avancer (ou se débloquer selon le cas) ou se bloquer. Nous jouerons plusieurs expérimentations et comparerons celles-ci sur la base du nombre de pièces terminées et de l’en-cours. Nous formons deux tables, la première, animée par Christophe génèrera de nouvelles séries de tirages à chaque tour, tandis que la seconde (celle où je vais jouer) réutilisera la même série de tirages à chaque expérimentation. C’est Olivier qui animera cette table.

image

Premier tour

Sur ce premier tour, chacun joue pour soi (nous avons de pièces de couleur différente pour nous différencier), il n’y a pas de limite de WIP.

image

Le résultat obtenu n’est pas à la hauteur de nos espérances :

  • Nous sommes frustrés de ne pouvoir agir sur les autres pièces lorsque des opportunités s’offrent à nous.
  • La « double peine » nous obligeant à faire deux tirages « face » consécutifs biaisent un peu le jeu à mon avis.

Bref, pas beaucoup de pièces finies et un gros en-cours à la fin de ce round !

image

Second tour

Lors de ce tour, nous voulons observer l’impact d’une limite de WIP (limite de 3 dans les 2 étapes d’en-cours). Toutefois, les joueurs continuent à ne traiter que leurs pièces !

image

Résultat pas très convainquant sur ce round : le nombre de pièces terminées reste le même ! Par contre notre en-cours baisse sensiblement. Nous apprenons quelque chose au passage : grâce à la limite de WIP, quand on atteint les limites d’en-cours, un mauvais tirage peut avoir un effet neutre au lieu d’avoir un effet négatif !

Mais nous restons frustrés de ne pouvoir fluidifier le système en jouant n’importe quelle pièce !

image

Troisième tour !

Nous décidons (comme la fois précédente) de ne changer qu’un seul paramètre pour mieux observer l’influence de celui-ci ! Ici, nous ouvrons à tous les joueurs la possibilité de jouer n’importe quelle pièce. Enfin ! Par contre, nous gardons les limites de WIP du tour précédent.

Cette fois le nombre de pièces terminées augmente très sensiblement. Et non seulement nous jouons les pièces des autres, mais nous collaborons beaucoup plus afin de nous aligner sur une stratégie commune ! Bref c’est bien plus fun. Nous avons hacké le jeu qui devait être austère !

image

Notre capacité est plus grande, une fois que nous avons élargi notre capacité d’action. Mais cette foi, c’est notre limite qui nous parait trop basse !

Quatrième tour…

Pour ce dernier round, nous avons augmenté notre limite de WIP de manière très importante (nous l’avons doublé sur les 2 steps). Notre jeu gagne en fluidité, car nous sommes déjà très bien alignés sur la stratégie. Nous augmentons un peu notre réalisé, mais pas autant que nous l’avions imaginé. En effet la neutralisation des mauvais tirages joue moins lorsque nous augmentons notre limite de WIP !

image

Nous arrêtons là, en envisageant toutefois une expérimentation supplémentaire dans laquelle nous abaisserions la limite sur le step 2, afin de saturer plus facilement le premier step (si, si) et d’avantage neutraliser les mauvais tirages. Vous n’avez probablement rien compris à ma dernière phrase ? Vous n’aviez qu’à être avec nous !

Debrief

La première table a effectué de nouveaux tirages à chaque round. Cela a beaucoup handicapé leur capacité à tirer des enseignements de chaque changement. Ainsi nous pensons que conserver les mêmes tirages est un facteur important de ce jeu.

Par contre, ils ont rapidement hacké la règles des mauvais tirages, une liberté que nous ne nous sommes pas accordé. Il aurait été intéressant de tester cela. Peut-être faut-il clarifier la latitude des changements possibles ?

image

En bref, sur le jeu nous avons pensé que :

  • Il n’est pas adapté à ceux qui découvrent complètement Kanban. Il est trop abstrait pour cela. Kanbanzine ou Getkanban feront mieux l’affaire.
  • Les petites expérimentations très courtes qu’il permet sont excellentes pour découvrir et comprendre l’influence de chaque paramètre.
  • Ces mêmes itérations courtes donnent du fun, car une complicité s’établit entre les joueurs !

End of #19

Au playground, une soirée ça se termine par un buffet. On siffle une bière, malgré l’absence récurrente de décapsuleur et on partage nos expériences !

image

J’ai oublié d’évoquer le l’Agile Playcamp à venir. Un agile Playground sur une journée avec la participation exceptionnelle de Luke Hohman. C’est Greg Hutchings qui a rendu cet évènement possible. Cet évènement sera précédé la veille par une formation certifiante aux innovation games, toujours par Luke Hohman !

Le bitcoin sous toutes ses faces !

En cette fin Janvier, le meetup Product Tank nous proposait un programme tout à fait prometteur : 3 invités venus pour nous présenter le bitcoin sous 3 perspectives différentes ! Sébastien Levaillant a fait un travail remarquable pour organiser cela. Travail mal récompensé par une participation plutôt faible : seulement 25 personnes présentes sur les 75 inscrits !

image

Bien sûr, le sujet est moins cliquant que lorsque l’on invite le Product Manager d’un commerce en ligne très en vue. Toutefois le sujet est au moins aussi intéressant, plus même dans ce cas précis, car on se situe là en pleine innovation économique !

Il est temps de s’élancer avec notre premier orateur.

Le Bitcoin, par Stanislas Marion

C’est à Stanislas que revenait l’exercice de nous présenter le Bitcoin ! D’abord qu’est-ce que c’est ? Et à quoi celà sert-il ?

A la découverte du bitcoin

Le Bitcoin, oui c’est une monnaie virtuelle, mais surtout un protocole peer to peer ne nécessitant pas de tiers de confiance, donc pas de banque (d’ailleurs pas toujours dignes de confiance). En cela Stanislas nous présente le bitcoin comme l’avancée la plus importante sur la gestion des comptes depuis la comptabilité à double entrée apparue à la fin du 15ème siècle ! A la différence des autres monnaies virtuelles jusqu’ici, le bitcoin adresse de manière fiable le problème du double spending. Il faut d’ailleurs préciser, pour briller dans les salons qu’il existe 2 bitcoins :

  • Le Bitcoin (B majuscule) : c’est le protocole.
  • Le bitcoin (b minuscule) : c’est la monnaie.

En parlant de protocole, celui-ci s’appuie sur un élément majeur : la Blockchain, la base de données contenant l’historique de toutes les transactions bitcoin. Cette base de données n’est pas centralisée : elle est dupliquée sur tous les noeuds du réseau bitcoin. La validation des transactions se base sur le consensus entre tous les noeuds du réseau bitcoin, en lieu et place du processus basé sur la « confiance ».

image

Minons le bitcoin

Les bitcoins, ça se génère, ou comme l’on dit dans le jargon : ça se mine ! Tout le monde peut miner des bitcoins, en fait cela génère même une forme de compétition entre mineurs. Celle-ci n’est pas anodine car le minage demande beaucoup de puissance de calcul, il s’agit en fait de la résolution d’un problème mathématique dont la difficulté augmente progressivement, environ tous les 15 jours. Finalement « tout le monde » n’est pas le mot juste, le minage demande beaucoup de ressources matérielles (pour « gagner »), de l’énergie aussi car le but est que le minage soit effectivement coûteux, ce qui n’est guère écologique.

Le minage ne sert pas seulement à fabriquer de nouveaux bitcoins, il sert à valider les transactions en les attachant à la Blockchain. Cette Blockchain ne représente pas seulement l’état du marché, mais l’historique complet des transaction. Même si bitcoin permet un certain anonymat, l’argent lui est complètement tracé !

Bref, le bitcoin, c’est :

  • Open-source : on peut tester le code du bitcoin !
  • Décentralisé : pas d’autorité faisant foi. La validation est basée sur un consensus et une connaissance partagée.
  • Une complète transparence des mouvements d’argent : tout le monde peut savoir d’où vient quel montant.
  • Fondé sur des mathématiques solides. Les incentives économiques paraissent saines, du moins jusqu’à présent.
  • Une simplification des risques.

Mythes et état de l’art

Un certain nombre de croyances gravitent aujourd’hui autour du bitcoin. Voyons cela.

  • Les transactions sont gratuites. Ce n’est pas la cas, par contre le coût est encore inconnu car nous sommes actuellement en phase de «  bootstrapping ». La validation des transactions est récompensée par des bitcoins « fabriqués » pour l’instant. Dans 20 ans, quand le bootstrapping sera terminé, il faudra effectivement payer la validation des transactions.
  • Le mining dépense de l’énergie inutilement. En fait la « dépense d’énergie » est la façon de sécuriser le bitcoin. C’est un facteur qui ne peut être fraudé !
  • Les transactions sont anonymes. En fait, on devrait dire qu’elle dépend de notre capacité à nous anonymiser ! Un facteur de moins en moins évident aujourd’hui et qui demande une forte technicité.
  • Le bitcoin c’est sûr car c’est crypté. Non, on peut se faire vider son compte bitcoin ! Un bitcoin c’est une clé privée sous forme de chaine de caractères. Elle figure localement chez vous. On peut s’en faire voler le support physique !
  • Le bitcoin est techniquement supérieur à tout le reste ! En fait son succès est lié au fait que son principe a un sens économique.
image

Tout n’est pas complètement aboutit quand on parle de bitcoins.

La technologie qui l’entoure est encore immature. Son « utilisabilité » est réservée aux personnes avec de solides connaissances techniques. Mais cela change beaucoup depuis un an. Des solutions facilitant la gestion de la sécurité apparaissent. Nous allons en voir une en 3ème partie.

En bref

Très bonne première partie, même si elle est un peu menée tabours battants, pour prendre connaissance des essentiels du bitcoin.

The Bitcoin blockchain, a new way to secure social interactions par Oleg Andreev

Le bitcoin c’est avant tout une nouvelle façon de penser notre présence sur l’Internet.

  • En 2000, la question était : Quelle est notre stratégie Internet ?
  • En 2005, c’était : Quelle est notre stratégie des réseaux sociaux ?
  • En 2015, c’est maintenant : Quelle est notre stratégie bitcoin ?

Une « ligne » bitcoin, c’est essentiellement 4 éléments:

  • Une origine, qui peut être une personne (via sa clé publique) ou un programme.
  • Une signature de la transaction.
  • Une destination, elle-même pouvant être une personne ou un programme.
  • Et bien évidemment : un montant !

Les transactions sont chainées entre elles : le destinataire de la première étant nécessairement l’origine de la suivante. Ainsi la Blockchain n’est pas une construction miraculeuse, elle adresse simplement bien certains problèmes tout en n’étant pas adapté à d’autres. Oleg l’illustre avec le cas d’un achat de places de cinéma :

  • Cet achat est « local », il n’a aucun sens a être connu à l’échelle planétaire.
  • Ce type d’achat est fréquent, on parle de dizaines de milliers de places par minutes à l’échelle du globe.
  • Il n’y a pas de revente. Donc suivre cette transaction dans le temps a peu d’intérêt.
  • La gestion de ce type de vente est centralisé.

A l’inverse de, par exemple, une action boursière, l’achat et la vente de ce type de produit n’ont pas de sens dans l’univers bitcoin.

image

Quand bitcoin redéfinit…

Oui, il redéfinit certaines choses, à commencer par la possession.

Aujourd’hui la possession est définie par l’accès physique, donc également notre capacité à protéger celle-ci, ce qui nous amène vers des considérations de hiérarchies, de lois, etc… Bref comme le dit si bien Oleg : « big guys win ». Toujours.

Avec la Blockchain, la possession est définie différemment, elle est définie par la connaissance : une simple base de données synchronisée partout. 

Le bitcoin redéfinit également la responsabilité : alors détenue par une autorité centrale, elle revient vers l’utilisateur.

Enfin, la Blockchain redéfinit la notion de contrat. Elle n’est plus assurée par un système légal mais par la sécurité intrinsèque du système.

La décentralisation que permet la Blockchain nous projette dans un monde où là où des autorités contrôlant nos échanges seront remplacés par des systèmes décentralisés.

En bref

Oleg nous a un peu surpris, finalement en se détachant du bitcoin lui-même pour se focaliser sur la Blockchain et évoquer toutes les nouvelles perspectives qu’offre cette plateforme, au-delà de la monnaie.

Ledger Wallet par Eric Larchevêque.

C’est bien en parlant de produit que nous allons terminer cette rencontre : Eric, qui est également le créateur de la maison du bitcoin, est venu nous parler de Ledger, une solution simple pour traiter de manière sérieuse les problèmes de sécurité que pose le bitcoin !

image

Pour Eric, le bitcoin c’est aussi et surtout une réinvention de l’identité. On peut désormais avoir une infinité d’identités numériques… à condition de savoir préserver son « secret ». Et cette sécurité est un sujet très complexe.

Ledger se présente comme une solution de sécurité dans un contexte Blockchain. Concrètement, il s’agit d’une smart card (la carte à puce n’a-t-elle pas été inventée en France ?), qui n’est pas une simple carte mémoire, mais un ordinateur complet avec son propre système d’exploitation et particulièrement résistant aux attaques. Cela me rappelle un peu le module de sécurité des concentrateurs Linky …

Cette smartcard n’expose jamais le secret, elle valide elle-même les transactions. En fait, même sa signature RF est indétectable. Nous avons parlé d’une infinité d’identités numériques : Ledger est capable de les générer sur la base d’un générateur d’identités digitales s’appuyant sur un code sur 256 bits, lui-même issu d’un code formé de 24 mots (ceux-là il ne faut pas les perdre).

image

En bref

C’est vrai, cette dernière présentation était particulièrement attrayante. Sans doute parce qu’on nous y montre un produit réel ! Au fait, combien coute-t-il ? pas très cher, en fait : 34 euros !

Il n’y a pas de magie dans ce prix. L’objectif est bien la démocratisation du bitcoin, et cela nécessite au moins deux facteurs :

  • Une simplification de l’usage. C’est l’objectif avoué de Ledger.
  • Un coût d’acquisation des produits et applications de support marginal. D’où le prix !

Alors oui, il va falloir en vendre beaucoup ! Mais Ledger vise aussi le marché de renouvellement avec les technologies émergentes : NFC et même TEE !

Note de lecture : Architecting Enterprise Solutions, par Paul Dyson & Andy Longshaw

Note: 7 ; Un excellent “pattern language” d’approche très Alexandrienne. Dommage que l’aspect solution me laisse un peu sur ma faim.

Le titre de l’ouvrage est assez évocateur à cet égard: Il s’agit là de décrire le style architectural des systèmes d’information Internet à l’aide d’un pattern language, à la Christopher Alexander. Digne représentant de la « software design patterns series », cet ouvrage expose sur 290 pages découpées en 12 chapitres formant 3 parties des architectures de déploiement dédiées aux applications Internet. Bien sûr, vous allez me dire que le texte va accuser son âge, surtout dans le domaine où les plus grands progrès ont été faits au cours des 10 dernières années ! Si ce point est indéniable, il n’est pas aussi marqué que l’on pourrait le craindre car il se focalise bien plus sur les principes d’architecture que sur les solutions techniques !

Je passe sur le premier chapitre qui ne nous apprend rien pour aborder la première partie « Architecture, Patterns and Internet Technology » qui comprend 4 chapitres sur 60 pages. Le premier d’entre-eux (donc le second chapitre) « system architecture » mérite que l’on ne passe pas trop vite dessus. Ses 15 pages sont consacrées aux propriétés non-fonctionnelles des architectures. Intéressant. Le point sur les technologies de l’Internet que nous propose le chapitre 3 sur 17 pages est un peu superficiel, mais pas aussi démodé que l’on pourrait le croire. Mais il apporte peu. Le chapitre 4 est en quelque sorte la table des matières patterns du livre. C’est un incontournable pour ce genre d’ouvrage. Pour clore cette première partie, les auteurs présentent l’étude de cas fictive sur laquelle ils ont choisi de s’appuyer. On y fait le tour des propriétés non-fonctionnelles que l’on avait énumérées au chapitre 2. C’est bien fait.

Avec 167 pages, la seconde partie est le gros de la troupe du bouquin, et de loin ! Il faut dire que cette partie qui ne compte pourtant que 4 chapitres s’intitule « The Patterns ». Et l’on commence fort logiquement au chapitre 6 par un chapitre « fundamental patterns » de 18 pages. Il présente deux patterns, le très classique « application server architecture » encore largement majoritaire aujourd’hui et un moins convainquant « péripheral specialist elements » dont la symétrie est questionnable du fait de la BDD unique… Le chapitre 7 nous offre un gros morceau avec les « system performance patterns » qui couvrent 45 pages. Les patterns architecturaux de ce chapitre sont particulièrement intéressants et bien décrits dans leur essence (load balancing, redondance, failover, appliance, replication, resource pooling, cache, offlining), il ne manque guère que le sharding des bases NoSQL ! Les diverses variantes de ces stratégies sont abordées ainsi que des considérations d’équilibrage de charge CPU, etc… Bref un chapitre riche qui justifierai le livre à lui tout seul !

Place aux « system control patterns » au chapitre 8, qui nous occupe sur 60 pages. Ce chapitre nous expose nombre de patterns de monitoring et de contrôle d’application en production. Ces patterns ne sont pas, disons « mortels », mais ils ont le mérite d’être là ainsi que les discussions qui vont avec. Plus intéressant, ce chapitre couvre aussi un volet sécurité avec les DMZ, l’encryptions et le secure channel (SSH). Le chapitre 9 qui clos cette seconde partie est probablement le plus décevant. Couvrant le « system evolution patterns », les patterns présentés restent de haut niveau. Petite exception pour le « swappable stagging environment » qui reste la perle de ce chapitre.

La dernière partie de l’ouvrage est consacré aux applications de ce que nous avons vu. 60 pages sont dédiées à cette partie qui regroupe 3 chapitre. Le chapitre 10 revisite ainsi notre étude de cas. C’est l’occasion de mixer plusieurs patterns pour endosser la performance, le monitoring et le déploiement. C’est un peu rapide mais donne une image à grande échelle de l’usage combiné des patterns. Le chapitre 11, « applying the patterns » couvre une vingtaine de pages. Son objectif est de donner une logique à l’application des patterns de la seconde partie, ce que je ne trouve pas convainquant. L’ouvrage se conclut par un mini chapitre « moving on » dont le but est de donner une perspective d’avenir. Bien sûr, c’est aussi celui qui accuse le plus son âge !

N’en doutez pas, l’objectif du livre est parfaitement réussi. Car nous avons vraiment là un bel exemple de pattern langage, dont chaque pattern est l’essence d’un point particulier de l’architecture, l’ensemble formant un tout cohérent. Cet ouvrage est convainquant sur la description efficace et agréable d’une architecture avec un pattern language. Une parfaite réussite à cet égard.

Ce qui modère un peu ma note, c’est que le volet technique, plus « design » soit un peu frustrant, car le propos reste assez haut niveau, même si le style est agréable et efficace. Quoi qu’il en soit, si vous décidez d’acquérir la connaissance de ce qu’est une architecture Internet, voilà le livre que vous cherchez. Toutefois, si vous êtes un pur techos, vous risquez d’être déçus. Moi je ne l’ai pas été !

image

Référence complète : Architecting Enterprise Solutions: Patterns for high-capability Internet-based systems – Paul Dyson & Andy Longshaw – John Wiley & sons / Software Design Patterns series 2004 – ISBN: 0-470-85612-2

Architecting Enterprise Solutions: Patterns for High-Capability Internet-Based Systems


https://www.goodreads.com/book/add_to_books_widget_frame/0470856122?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on