Si il reste des zones d’ombre dans votre compréhension du fonctionnement du bitcoin et de sa blockchain, ou si vous vous demandez ce qu’est une blockchain, ou ce qu’est une crypto monnaie, je vais essayer ici d’éclaircir tout cela, sans vous perdre dans des concepts pouvant rapidement devenir très complexes (je préviens les puristes qu’il peut y avoir des raccourcis ou des approximations volontaires afin de faciliter la compréhension).

Pour comprendre ce qu’est une blockchain ou une crypto monnaie, il faut d’abord commencer par un petit résumé de l’histoire de la cryptographie.

Introduction: la cryptographie

Depuis très longtemps, des personnes ont tenté de communiquer des messages sans que personne, hormis le destinataire du message, ne puisse comprendre son contenu. L’exemple le plus simple est le code César : il consiste à remplacer chaque lettre d’un message par une autre, les A deviennent des B, les B des C, etc…

À leur création, ces méthodes de codage ont semblé indéchiffrables, mais des personnes plus ingénieuses que les autres ont trouvé des moyens de retrouver le message d’origine à partir du message codé, sans avoir le détail de la méthode utilisée pour coder ces messages. Pour le code César par exemple, ce fût l’analyse fréquentielle.

Ainsi, à chaque fois qu’une nouvelle méthode de codage était élaboré, plus ou moins longtemps plus tard (des siècles au début), une personne trouvait une méthode pour déchiffrer sans posséder les informations utilisées lors du chiffrement.

À la fin du XIXe siècle, le cryptologue Auguste Kerckhoffs, publie les Principes de Kerckhoffs, dans lesquels il définit les caractéristiques d’un bon codage, au sens d’un codage assez bon pour un usage militaire, premier utilisateur des méthodes de codage.

Dans ces principes, qui sont devenus une référence depuis, il énonce que la méthode de codage doit faire intervenir un secret partagé entre l’émetteur et le destinataire, qui puisse être défini comme un message, et non comme une méthode. Ainsi, il est préférable que la méthode de chiffrement puisse être connue de l’ennemi, et que pour chiffrer un message, il faille faire intervenir un message secret partagé, nommé clé, uniquement connu de l’émetteur et du destinataire, car ainsi, si cette clé tombe aux mains de l’ennemi, il suffira d’en utiliser une nouvelle pour pouvoir retransmettre de manière sûr, sans avoir à modifier la méthode de chiffrement utilisée (qui peut nécessiter un matériel complexe et coûteux).

Pour le code César, cette clé pourrait être la valeur du décalage à appliquer dans l’alphabet, ou la table d’équivalence : lettre en clair – lettre codée.

Jusqu’en 1977, toutes les méthodes de chiffrement utilisaient la même clé pour chiffrer et déchiffrer, mais cette année, Ronald Rivest, Adi Shamir et Leonard Adleman ont publié une nouvelle méthode de chiffrement nommée à partir de leur initials : RSA.

Avec le chiffrement précédent à clé unique, dit chiffrement symétrique, il faut, pour envoyer un message secret à un destinataire, lui avoir fait parvenir au préalable une clé, d’une manière telle que personne d’autre que lui ne l’ai vu. Et cette transmission de clé est le talon d’Achille du chiffrement symétrique.

La méthode RSA a introduit une révolution dans le domaine du chiffrement et de la cryptographie. Pour la première fois, une méthode de chiffrement nécessitait d’utiliser des clés différentes pour chiffrer et déchiffrer. « Quel intérêt? » pensez-vous peut être, et bien il est double :

Avec ce nouveau chiffrement, dit asymétrique, le destinataire peut transmettre une clé de chiffrement sans se soucier de la cacher à l’ennemi, car il ne pourra rien en faire. L’expéditeur utilise cette clé pour chiffrer son message secret. Il le transmet ensuite, chiffré, sans se soucier de le cacher à l’ennemi, car celui-ci ne pourra le déchiffrer avec la clé de chiffrement qu’il a pu voir. Le destinataire reçoit le message chiffré, et le déchiffre avec une clé de déchiffrement qu’il a conservé pour lui, sans jamais la montrer à personne. Ainsi, il n’est plus besoin d’assurer la sécurité de transmission d’une clé unique, car la clé de déchiffrement n’a jamais circulé. Elle est restée dans les mains du destinataire du message. Pour un échange bidirectionnel, le principe sera le même, mais avec une paire de clé (chiffrement+déchiffrement) par sens de circulation du message.

Le second avantage du chiffrement asymétrique est la possibilité de faire quelque chose qui n’existe pas avec le chiffrement symétrique : l’authentification.

Si l’on reprend l’exemple que l’on vient de décrire, mais que l’on garde secrète la clé de chiffrement au lieu de celle de déchiffrement, n’importe qui pourra déchiffrer le message, mais une seule personne pourra le chiffrer. L’intérêt n’est plus dans ce cas la transmission d’un message devant rester secret, mais la preuve de l’origine du message. Seul la personne possédant la clé de chiffrement jamais divulguée aura pu chiffrer le message que n’importe qui peut déchiffrer. Le message n’est donc plus « chiffré » mais « authentifié » (on utilise ces termes pour différencier les deux cas d’utilisation, même si dans le cas de l’authentification il y a aussi chiffrement, sauf que comme n’importe qui peut déchiffrer, on n’utilisera pas ce terme).

Jusqu’ici, il a été question de clé de chiffrement et de clé de déchiffrement, mais elle ont été nommés comme cela pour une meilleure compréhension. Dans les faits, ces clés ne sont pas nommées ainsi, car chacune d’elle peut être utilisée pour chiffrer ou déchiffrer. Si une clé est utilisée pour une opération, alors seule l’autre clé pourra effectuer l’opération inverse. Cependant, ces clés sont différentiables par la manière dont elles sont générés : l’une des clé est calculée à partir de l’autre, alors que l’opération inverse n’est pas possible. Pour cette raison, la clé permettant de générer l’autre est appelée clé privée, et l’autre: clé publique. Si la clé privée est connue d’autres personnes que son propriétaire, tout le système perd son intérêt, pour le chiffrement, comme pour l’authentification.

Vous vous demandez peut être comment il est possible de calculer la clé publique à partir de la clé privée sans que l’opération inverse soit possible, car après tout, pour l’addition existe la soustraction, et pour la multiplication existe la division ? Si c’est le cas, lisez la section ci-après : « Les opérations à sens unique », et sinon, sautez cette section.

On vient de le voir, le chiffrement asymétrique a beaucoup changé les choses, en supprimant le problème de transmission des clés. En revanche, dans les cas du chiffrement comme de l’authentification, que se passera t-il si la clé que je pense être celle du mon interlocuteur a été remplacée par un ennemi? Alors c’est l’ennemi qui décodera mes messages et se fera passer pour mon interlocuteur.

Ainsi, le chiffrement asymétrique a supprimé le problème de transmission d’une clé unique, mais le remplace par celui de l’authentification des clés publiques : comment s’assurer qu’une clé publique appartient bien à la personne à laquelle on pense ?

Heureusement, le chiffrement asymétrique contient justement une possibilité d’authentification que le chiffrement symétrique ne fournit pas (du moins pas de manière indépendante du chiffrement).

Ainsi, pour s’assurer qu’une clé publique provient vraiment de la personne à qui elle prétend appartenir, il n’y aura que deux solutions : avoir obtenu cette clé en personne, ou l’obtenir d’une personne de confiance: le tiers de confiance, qui se sera elle aussi authentifiée. L’obtenir en personne est une meilleure solution, mais impossible dans le cadre d’échanges sur internet. Le tiers de confiance sera donc l’unique solution possible en pratique. Mais alors, comment obtenir la clé publique du tiers de confiance? Le problème semble se répéter. Il se répète effectivement jusqu’au premier programme que l’on utilisera pour communiquer, le navigateur internet par exemple (Google Chrome, Microsoft Edge, Safari, Firefox…), ou le magasin d’application (Google Store, Apple App Store) utilisé pour télécharger les applications accédant à internet (navigateur internet, application de banque en ligne…). Celui-ci devra posséder la clé publique d’un tiers de confiance et non d’un pirate informatique pour que l’ensemble soit sûr. Ces clés publiques sont nommées « certificats » au sein de ces programmes (ce sont de ces clés publiques dont il est question lorsque votre navigateur vous parle de « Certificat »).

Les opérations à sens unique

Si on pense aux mathématiques telles qu’on les a pratiqué avant le baccalauréat, on ne voit pas nécessairement comment une fonction peut être à sens unique. Si je fais A*B=C, je peux partir de C pour revenir à A en divisant C par B. Dans le cas du chiffrement asymétrique RSA, l’impossibilité d’inverser l’opération mathématique vient de l’utilisation de l’opération « modulo ».

Le modulo est le reste d’une division, par exemple : si on veut arriver à 15 en avec des 7, on pourra faire tenir 2 fois 7 (soit 14), mais pas 3 fois 7 (soit 21>15), et de 14 à 15 il restera 1, c’est le modulo 7 de 15 : 15 modulo 7= 1.

Si on connaît la solution (1) et le modulo (7), et qu’on doit retrouver 15, il y aura plusieurs solutions, mais avec une multiplication et une addition, on pourra retrouver que 8 modulo 7 = 1 (7*1+1=8) et 15 modulo 7 = 1 (7*2+1=15).

Si maintenant on augmente la difficulté en disant que 15 est le produit de deux nombres, et que l’un de ces nombres est inconnu : 3 * ? modulo 7 = 1

La seule solution pour trouver la valeur de ? est de tout essayer: 3*1 modulo 7 = 3, 3*2 modulo 7 = 6, 3*4 modulo 7 = 5…

Maintenant, si au lieu de 3 et 5 dont le produit fait 15, on utilise deux nombres de 150 chiffres, dont le produit fait 300 chiffres de long, il faudra des années pour essayer un nombre de possibilités plus grand qu’il y a d’atomes dans l’univers. Il existe des méthodes plus efficaces que d’essayer tous les nombres possibles pour trouver la valeur inconnue « ?“, mais aucune n’est assez efficace pour permettre de le faire dans un temps raisonnable (moins de plusieurs dizaines d’années pour un ordinateur extrêmement puissant).

Ainsi, « casser » un chiffrement asymétrique n’est pas impossible, mais prends trop de temps pour rendre cette opération réalisable. C’est pour cette raison que les « certificats » dont on a déjà parlé ont une date d’expiration, car si ils existent depuis assez longtemps, un pirate qui aura commencé à essayer de les « casser » dès leur création, aura pu y parvenir si le certificat est assez ancien.

Si vous vous demandez comment il est possible de chiffrer et déchiffrer avec des clés différentes, je vous invite à lire l’exemple de RSA sur la page wikipédia, RSA étant le plus simple de tous les chiffrements asymétriques existants, c’est donc le meilleur exemple pour comprendre comment ce type de chiffrement marche. Comme il est très bien décrit sur wikipédia, je ne reprends pas l’explication ici.

On vient de voir ici une opération à sens unique, utiliseée pour le chiffrement de messages, mais il existe d’autres opérations à sens unique mis en œuvre dans les crypto monnaies (et bien d’autres domaines), ce sont les fonctions de hachage.

Les fonctions de hachage

On vient de parler des fonctions à sens unique pour illustrer la difficulté de passer de la clé publique à la clé privée d’un système de chiffrement asymétrique tel que RSA. Il existe cependant beaucoup d’autres exemples de fonctions a sens unique, dont un autre type très utilisé en sécurité informatique, et dans les crypto monnaies comme le bitcoin : les fonctions de hachage.

Une fonction de hachage permet de calculer un nombre, nommé hash, donnant une image d’un fichier d’entrée (ex: un fichier vidéo), de tel sorte que si le fichier d’entrée est à peine modifié, le nombre calculé sera très différent.

Prenons un exemple simpliste : un fichier d’entrée constitué d’un nombre à deux chiffres, 67, et une fonction de hachage faisant l’addition de tous ces chiffres, et de ceux du résultat jusqu’à obtenir un seul chiffre : 67 donne 6+7=13, puis 1+3=4. Cette fonction de hachage passe de 2 chiffres à un seul, de 67 à 4, et si l’entrée est 68 au lieu de 67, la sortie sera 6+8=14 et 1+4=5 au lieu de 4. Bien sûr, beaucoup de données d’entrée donneront le même nombre en sortie, mais la fonction de hachage est faite de telle sorte que la probabilité de trouver ces deux données d’entrée donnant le même nombre de sortie est incroyablement faible pour les vraies fonction de hachage, qui prennent en entrée des milliers d’octets et produisent une valeur de hash de quelques octets seulement.

En plus de fournir un nombre représentant une donnée d’entrée et permettant d’y détecter de très petits changements, les fonctions de hachage ont également la propriété d’être impossible à inverser. Contrairement aux clés de RSA, cette impossibilité ne vient pas de l’opération modulo, mais du mélange (hachage) des chiffres en entrée. Je ne vais pas détailler plus ici les fonctions de hachage utilisés pour le bitcoin, car cela serait trop complexe, je vais juste citer SHA256, mis au point par l’agence de sécurité intérieure des Etats Unis (NSA). Ce hachage génère un hash de longueur fixe (256 bits, d’où son nom), y compris sur une donnée d’entrée vide (car la fonction fait intervenir des constantes dans son calcul). Pour donner un exemple simpliste mais plus représentatif de ce que fait SHA256, notamment avec une entrée nulle, imaginez qu’on modifie l’exemple de hachage précédent de la manière suivante : on prend le fichier d’entrée fait d’un nombre à deux chiffres, on le multiplie par 7, on y ajoute 67, on additionne tous ses chiffres comme dans l’exemple précédent, puis on recommence toutes ces opérations avec le résultat sur un chiffre que l’on a obtenu, et on refait cela 16 fois. À l’issue de tout cela, on obtient bien un nombre à un chiffre à partir du nombre à deux chiffres du début, mais il semble très difficile de remonter à ce nombre à partir du résultat obtenu (sans calculer le hachage des nombres de 1 à 100 de manière exhaustive, ce qui est impossible avec SHA256 car la taille du nombre en entrée est inconnu, et/ou peut avoir des milliards de chiffres de longueur).

Avec SHA256, n’importe quelle donnée d’entrée produit un hash de longueur fixe, et il est impossible de calculer comment modifier la donnée d’entrée afin que le hash produit reste identique.

En plus de cette propriété, SHA256 et les fonctions de hachage du même type en ont une autre utilisée dans beaucoup de domaines liés à la sécurité : les hash de valeurs consécutives d’une entrée (hachage de 1, 2, 3…) forment une suite aléatoire, et il est impossible de calculer la valeur suivante qui sera produite par cette suite sans connaître la valeur d’entrée qui est hachée. Cette propriété est particulièrement intéressante parce qu’elle permet de générer une multitude de clés privées pour un chiffrement asymétrique à partir d’une seule valeur initiale. On en reparlera lors de la description du Bitcoin, car c’est comme cela qu’il est possible de reconstituer un portefeuille avec un grand nombre de comptes Bitcoin en partant d’une seule clé secrète.

Une blockchain : la crypto monnaie Bitcoin

Le Bitcoin n’est ni la première blockchain, ni la première crypto monnaie (DigiCash l’a précédé notamment, mais n’a duré que 9 ans), mais c’est la première fois qu’une blockchain et une crypto monnaie connait un tel essor sur la durée (le Bitcoin a eu 10 ans en 2019).

Une blockchain est un système de stockage d’information, et le Bitcoin est une monnaie utilisant ce système de stockage pour mémoriser les débits, crédits, soldes et propriétaires d’un grand nombre de comptes.

Bien qu’étant une crypto monnaie, le Bitcoin répond à la même caractéristique que toutes les autres monnaies (que j’ai décrite dans un précédent billet) : il n’a de valeur que parce que ses utilisateurs lui accordent leur confiance.

En soi, l’argent n’a d’intérêt que parce qu’on peut l’échanger contre ce dont on a réellement besoin : nourriture, habitation, soin, habillement, divertissement, culture, loisirs… On attribuera de la valeur à une monnaie si on a confiance dans le fait qu’on pourra l’échanger contre des choses qui satisferont ces besoins fondamentaux. Ceci est valable pour l’euro, le dollar ou le bitcoin, même si dans le cas du bitcoin on l’échangera généralement d’abord contre des euro ou des dollars, avant de faire un échange contre des biens ou des services.

Si le bitcoin a pris de la valeur, c’est donc parce que des gens ont décidé d’accepter de l’échanger contre des monnaies publiques comme le dollar ou l’euro. Certaines des raisons qui ont mené ces gens à accepter ces échanges, relèvent du fonctionnement du bitcoin, que je vais décrire ici.

Une monnaie publique comme le dollar est centralisée : une seule banque en émet, et lorsqu’elle le fait, elle note dans ses comptes la somme qui a été émise et l’échéancier du remboursement de cette somme avec les intérêts. Comme pour payer ces intérêts il faudra nécessairement émettre de nouveau de l’argent, la somme en circulation ne pourra qu’augmenter, générant ainsi une inflation qui a pour but de dissuader les gens de garder de l’argent trop longtemps, car le but premier de l’argent est de permettre des échanges de bien et de services, nécessaire à l’activité humaine, il faut donc pour cela qu’il circule. Si la valeur d’une monnaie publique augmente parce qu’il n’y en a pas assez, la banque qui l’émet peut diminuer son taux d’intérêt afin de faciliter son émission, ou faire l’inverse si cette monnaie perd trop de valeur. Ainsi, un organisme émetteur d’une monnaie publique a des moyens d’agir sur sa valeur, même si cette action est toujours limitée par la confiance que les gens accordent à cette monnaie : si plus personne n’accepte cette monnaie en échange de biens ou de services, peu importe alors son taux d’intérêt, elle n’aura plus aucune valeur.

Le bitcoin est une devise spéculative car aucun organisme ne facilite son émission ou sa conversion afin d’en assurer la stabilité. D’autres crypto monnaies, les stable coins, veulent assurer une certaine stabilité en fournissant une possibilité de les convertir dans une autre monnaie à un taux de change fixe, ce qui retire l’intérêt de spéculer avec elles, car un organisme centrale permet d’en acheter et d’en revendre à taux fixe dans une devise à laquelle elle est adossée. Cependant, la stabilité de ces monnaies se limite à la devise avec laquelle l’échange est proposé, ainsi qu’à la capacité réelle à faire cet échange, car cela signifie pour l’émetteur du stable coin d’avoir une réserve de l’autre devise en quantité suffisante pour échanger tous les stable coins émis. Si cet organisme ne peut assurer cet échange, le stable coin s’effondre, comme l’a fait Terra en 2022, lequel ne possédait pas réellement autant de dollars que de coin Terra en circulation

La caractéristique du bitcoin qui la différencie des monnaies publiques comme le dollar est que aucune banque ne l’émet. Le bitcoin est émis par ceux qui enregistrent des transactions entre les comptes contenant des bitcoin. Mais qui enregistre ces transactions ? N’importe qui, capable de se connecter à internet, et d’exécuter le programme informatique permettant d’enregistrer des transactions : Bitcoin Core. Ce programme est libre d’accès pour tout le monde.

Dans ce cas, on peut se demander où sont enregistrées ces transactions ? Dans une blockchain, sorte de livre comptable, accessible à n’importe quelle personne avec un accès internet.

Un livre comptable accessible à n’importe qui? Chacun peut y écrire n’importe quoi alors, comme s’arroger des millions de bitcoin ? Non, car l’écriture de ce livre, cette blockchain, doit être fait selon un programme précis, et si une personne n’utilise pas ce programme, alors ce qu’il écrira dans ce livre sera ignorés des autres personnes l’utilisant, et n’aura donc aucun effet concret.

C’est un peu comme lors d’un jeu à plusieurs personnes : tout le monde se met d’accord sur les règles du jeu, et si un joueur les enfreint, il est expulsé par les autres, qui continent à jouer sans lui. Il aura beau dire qu’il a gagné, cela n’aura aucune valeur si tout les autres joueurs sont d’accord pour dire que ce n’est pas le cas.

Ce principe est nommé « consensus » dans le cadre des blockchaines, mais il arrive cependant que tous les utilisateurs d’une blockchain ne parviennent pas à se mettre d’accord sur une modification, et que deux blockchaines se mettent donc à vivre en parallèle. Ceci s’est produit en 2016 sur la blockchain de la monnaie Ethereum par exemple : une attaque des 51% (on en parlera plus loin) a eu lieu et une nouvelle chaîne ETH à été créé pour annuler les effets de cette attaque, mais comme l’ancienne blockchain (sans cette annulation) a continué à être utilisée par une partie de ses utilisateurs, cette ancienne chaîne, nommée alors ETC, existe toujours.

Formulé ainsi, cela semble fonctionner, mais en pratique, comment, sans organe de régulation central (aucun joueur n’a plus de droit qu’un autre), s’assurer de la cohérence des écritures dans le livre de compte, si deux personnes veulent, en même temps, y ajouter des éléments contradictoires?

Ce problème explique que le bitcoin n’ai pas été créé plus tôt, car sa résolution n’est pas triviale, on l’appelle le problème de la double dépense.

La double dépense intervient lorsque deux personnes veulent écrire des dépenses d’un montant différent sur le même compte en même temps. Pour résoudre ce problème avec un livre de compte accessible à tous, sans que personne n’ai d’accès privilégié, ou de rôle d’arbitre, le Bitcoin utilise deux concepts : la chaîne de blocs, et la preuve de travail.

La chaîne de blocs

Afin que beaucoup d’intervenants sans différences de rôle ni de privilèges (on parle de paires) puissent écrire ensemble le contenu d’un livre de compte, celui-ci prend la forme d’une chaîne de blocs. Le premier bloc a été créé par le créateur de la monnaie (son pseudonyme est Satoshi Nakamoto pour le bitcoin, sans que l’on sache si c’est une ou plusieurs personnes), et contient les premiers bitcoins avec le compte sur lequel ils ont été déposés. Les blocs suivants contiennent des transactions de compte à compte, ainsi que les bitcoins nouvellement créés (nous verrons plus loin comment ils le sont). Chaque intervenant peut ajouter à cette chaîne un bloc contenant une liste de transactions, et transmettre au réseau d’intervenants ce nouveau bloc afin qu’il soit pris en compte par tous (un nouvel arrivant doit au moins connaître un intervenant déjà présent dans le réseau pour y prendre part). L’ensemble peut être comparé à des élèves en classe se passant des papiers de main en main afin d’écrire une histoire commune, chacun y ajoutant une phrase. Chaque élève écrira pour lui l’intégralité de l’histoire, à laquelle il ajoutera le contenu des papiers dans l’ordre dans lequel il les recevra. Chacun tiendra donc à jour toute l’histoire sur un cahier qu’il ne fera pas circuler. Mais alors, comment s’assurer de la cohérence de l’ensemble si plusieurs élèves se mettent à faire circuler en même temps des papiers depuis plusieurs coins de la salle de classe ?

En pratique, les papiers sont numérotés de telle sorte qu’ils mentionnent où ils doivent être insérés dans l’histoire, par exemple : la 25e phrase est « il poussa la porte et entra » et fait suite à « arrivé devant l’entrée ». Si un élève reçois deux 25e phase en même temps, il ne conservera que la première arrivée, et rejettera l’autre. Pendant un moment, il y aura divergence des histoires parmi les élèves en fonction de qui aura reçu quel papier en premier, mais cette divergence sera rapidement corrigée lors de l’arrivée des papiers suivants. En effet, chaque élève considérera comme l’histoire correcte celle qui sera la plus longue. Si un élève reçois une suite ne correspondant pas à la dernière phrase qu’il a reçu, il verra qu’une autre version que la sienne est prolongée, il demandera alors à son voisin de lui transmettre la phrase qu’il a rejeté précédemment, pour s’aligner sur l’histoire la plus longue. La blockchain bitcoin fonctionnent comme cela : c’est toujours la chaîne la plus longue qui est conservé, la confusion de dure que tant que de nouveaux blocs sont produits et propagés en même temps à travers le réseau de tous les intervenants. Pour le bitcoin, la durée pendant laquelle cette confusion peut persister est défini empiriquement par l’expérience des intervenants, et il est de coutume de dire qu’il faut attendre que 6 blocs aient été ajoutés à celui contenant une transaction, pour être sûr que cette dernière ne sera plus rejeté suite à la levée d’une confusion telle que celle décrite ici.

Ainsi, pour limiter le risque de cette simultanéité, et également ralentir la vitesse de production de nouveaux blocs, un second concept est utilisé par le bitcoin : la preuve de travail.

La preuve de travail

Le concept de preuve de travail joue plusieurs rôles dans la blockchain du bitcoin. Je les détaillerai après avoir décris en quoi cela consiste.

Pour ajouter un bloc à la blockchain du bitcoin, il ne suffit pas de le transmettre aux autres intervenants, il faut fournir une preuve que des calculs ont été faits pendant environ 10 minutes. Ainsi, un nouveau bloc n’est créé que toutes les dix minutes, et comme on a vu qu’il est d’usage d’attendre la création de six blocs pour en déduire qu’une transaction est définitive, cela revient à 60 minutes.

Le problème que résoud la preuve de travail est de garantir qu’il ne soit pas possible d’ajouter un nouveau bloc en beaucoup moins de temps que dix minutes. Pour cela, on utilise une fonction de hachage. On a vu qu’une telle fonction produit à partir d’une importante quantité de données d’entrée, un nombre beaucoup plus petit, et de taille fixe, sans qu’il soit possible de calculer quelle donnée d’entrée produira un nombre de sortie précis sans essayer toutes les données d’entrée de possibles. La preuve de travail consiste donc à demander à celui qui produit le bloc, de trouver combien ajouter au contenu de ce bloc, pour produire une valeur de hachage avec une propriété déterminée à l’avance. Si on reprend l’exemple de la fonction de hachage qui à partir d’un nombre de deux chiffres produit un nombre d’un chiffre, une preuve de travail serait de trouver combien ajouter au nombre d’entrée, pour obtenir 4 comme valeur de hachage. Comme il y a 100 nombres possibles en entrée, pour 10 valeurs de hachage en sortie, trouver une entrée proposant un hash égal à 4 nécessitera à priori de tester 10 valeurs (100 entrée pour 10 sortie, chaque sortie est produite par 10 entrées car 10*10=100 et que la fonction de hachage a la propriété d’associer aléatoirement les entrées aux sorties).

De cette manière, si un bloc est publiée sans préciser la valeur à lui ajouter pour produire le hash demandé, ou si l’ajout de cette valeur ne produit pas le hash requis, le bloc sera ignorés par les autres intervenants.

La preuve de travail joue les rôles suivants : limiter la vitesse de production de blocs et protéger la blockchain contre une inondation de blocs de la part d’un intervenant, car il lui faudrait pour cela une capacité de calcul très supérieur à tous les autres intervenants.

Mais une telle inondation n’est elle pas tout de même possible ? Après tout, des intervenants peuvent se regrouper pour coordonner une attaque, et la puissance de calcul des ordinateurs augmente continuellement au cours du temps ?

Le regroupement d’intervenants est effectivement la plus grosse menace contre laquelle la blockchain du bitcoin n’a pas de parade, on l’appelle l’attaque des 51%. Si un groupe d’intervenants coordonnés possède plus de 50% de la puissance de calcul de la totalité des intervenants sur la blockchain du bitcoin, alors ce type d’attaque est possible. Si on reprend l’exemple du jeu : si plus de la moitié des joueurs décident de modifier le score, les autres n’auront pas le moyen de s’opposer, sinon de lancer une autre partie, donc une autre blockchain et par conséquent une crypto monnaie différente.

Concernant la puissance de calcul croissante des machines, la solution a été prévue dès la création du bitcoin. Tous les 2016 blocs, tous les intervenants mesurent la fréquence de production des 2016 derniers blocs, et corrigent selon la même formule la difficulté de la preuve de travail à fournir. Avec notre exemple de nombre sur deux chiffres donnant un hash sur un chiffre, une augmentation de la difficulté de preuve de travail pourrait être : trouver un hash inférieur à 5, puis trouver un hash pair, puis trouver un hash égal à 4. Comme le bitcoin utilise  SHA256 comme fonction de hachage pour la preuve de travail, la latitude d’augmentation de la difficulté est énorme. Lors de la création du bitcoin, son créateur calculait la preuve de travail sur un ordinateur portable (calculer cette preuve s’appelle « miner » en référence à l’extraction de l’or d’une mine), l’indice de difficulté était de 1. Le 2 avril 2021, cette difficulté était de 23 milliards de milliards, ce qui signifie qu’il faudrait autant d’ordinateurs portable pour miner ce bloc d’avril 2021 en 10 minutes, ou qu’il faudrait 430 millions de milliards d’années à ce même ordinateur portable pour miner ce bloc d’avril 2021. Un telle différence s’explique par le fait que depuis 2009, des puces électroniques spécifiques (nommées ASIC) ont été créés pour calculer le plus de hash SHA256 possible par seconde. Pour se faire une idée, un PC portable peut en calculer environ 10 millions par seconde, et les plus gros ASIC peuvent en calculer 14 millions de millions par seconde. Si en plus de cela, on fait travailler des centaines voire des milliers de ces puces en même temps, on comprend la différence de puissance constatée entre 2009 et 2022.

Avec un chiffre aussi vertigineux, la preuve de travail pose un problème de fuite en avant : il faut être plus rapide que les autres pour miner des blocs, mais cet avantage est régulièrement annulé par l’ajustement automatique de la difficulté du minage. Pour corriger ce problème, d’autres crypto monnaies ont défini la preuve d’enjeu, mais je ne la détaillerai pas ici.

Face à cela, on peut se demander ce qui pousse des intervenants à miner ? Et bien le gain prévu par le bitcoin : miner un bloc rapport automatiquement des bitcoin au mineur, 50 par bloc pour les tous premiers blocs minés, et 6,25 en 2022 (cette récompense va décroissante et atteindra un jour zero). Le mineur se voit également rémunéré pour chaque transaction contenue dans le bloc, d’un montant laissé libre et déterminé entre le mineur et celui ayant demandé d’ajouter la transaction dans la blockchain.

Après avoir décrit la chaîne de bloc, et la preuve de travail qui assure son intégrité, je vais présenter ce que l’on peut voir dans la blockchain du bitcoin, car elle est publique, n’importe qui peut y avoir accès, et un bon nombre de site web proposent de visualiser son contenu.

Le contenu de la blockchain du bitcoin

Comme la blockchain du bitcoin est publique, des sites web proposent de voir son contenu. Voici une page permettant de voir le contenu d’un bloc:

https://www.blockchain.com/btc/block/720638

La page de ce bloc détaille les informations qui lui sont propres, juste avant de lister les transactions qu’il contient :

Bloc bitcoin 720638

Les « Confirmations » sont le nombre de blocs ajoutés après celui-ci, et venant donc confirmer sa présence dans la chaîne de blocs.

Le « Hash » est le résultat de la preuve de travail fournie par le mineur. On remarquera qu’elle commence par une longue suite de « 0 », cela est dûe à la difficulté élevée lié à la preuve de travail de ce bloc (visible tout en bas de l’image). Plus la difficulté est élevée, plus un grand nombre de chiffres de la preuve de travail (du Hash) seront imposés. Si on regarde un des tout premiers bloc, on voit que le Hash a beaucoup moins de « 0 » à son début.

On peut également voir dans l’en-tête de ce bloc (non entièrement visible dans l’image ci-dessus) le nombre de transactions contenues dans ce bloc, ici 3062.

Enfin, on voit que ce bloc a été miné par « AntPool » (groupe de fourmis), qui était le second plus grand regroupement de mineurs lorsque ce bloc a été validé, représentant 14% de la capacité mondiale de minage du bitcoin. Se regrouper permet aux mineurs d’augmenter leurs chances de valider un bloc en premier, ils se partageant le travail de recherche du hash validant le bloc.

Intéressons nous maintenant à une transaction en particulier :

https://www.blockchain.com/btc/tx/01e7c525a5759cde1d04d2e9a363424053ace3ff1d2dde9cd1b368493254bd0d

La première partie résume le contenu de la transaction :

Contenu d’une transaction bitcoin

À gauche de la flèche verte centrale on voit d’où l’argent a été retiré (la liste est longue et ne tient pas entièrement), et à droite de cette flèche apparaissent deux lignes : la dépense (nommé « spent » en rouge) et la monnaie (nommé « unspent » en vert).

Les suites de chiffres et des lettres en bleu sont les adresses des comptes débités ou crédités.

On voit que le compte avec l’adresse commençant par « 34xp » est débité deux fois. Cela s’explique par le fait que les transactions ne débitent pas des comptes, mais des sorties d’autres transactions. On peut faire le parallèle avec les pièces et les billets de notre porte monnaie. Je gagne d’abord 20 euros, j’obtiens alors un billet de 20 euros qui va sur mon compte. Ensuite je gagne 10 euros et reçois donc un billet de 10 euros qui va également sur mon compte. Suite à cela, je veux payer 25 euro à un ami, je vais donc devoir utiliser mon billet de 20 euros, et mon billet de 10 euros, pour avoir assez. C’est pour cela que le compte d’adresse commençant par « 34xp » apparaît deux fois dans les entrées débitées lors de cette transaction. Les deux billets seront consommés dans la transaction, mon ami se verra attribués un billet de 20 euros ainsi qu’un billet de 5 (le « spent »), et je recevrai un billet de 5 euros en monnaie de la transaction (le « unspent ») qui arrivera sur un compte m’appartenant (la création de compte est illimité et gratuite avec le bitcoin, on en reparlera plus loin). Avec le bitcoin c’est pareil, les sorties d’autres transactions sont les billets que l’on peut dépenser, et les adresses indiquées sont celles des comptes sur lesquels ils se trouvent. La principale différence avec cette analogie est que les valeurs possibles pour les « billets » sont illimitées, on peut créer un billet de 25 euro en dépensant un billet de 10 et un billet de 20. Comme avec les billets, le bitcoin impose la consommation de la totalité des sorties de transaction mises en entrée d’une transaction, d’où la présence de la sortie de transaction nommée « unspent » (monnaie), qui permettra de récupérer le « trop plein » non utilisé.

Le solde d’un compte bitcoin n’est écrit nulle part dans la chaîne de blocs, il est calculé en faisant la somme de toutes les sorties de transactions non consommés par d’autres transactions.

Si on additionne les montants en entrée et qu’on compare avec les montants des deux sorties, on constate que tout ce qui entre est inférieure à tout ce qui sort. Cette différence correspond aux frais de transaction que le mineur du bloc percevra, nommé « Fee » dans l’image précédente.

On a déjà présenté le chiffrement asymétrique avec clé privée et clé publique, ainsi que les fonctions de hachage, mais quel lien avec le bitcoin ? Nous allons voir cela dans la partie suivante, traitant des adresses bitcoin.

Les adresses bitcoin

Les comptes Bitcoin sont identifiés par leur adresse. L’adresse d’un compte bitcoin n’est rien d’autre que la résultat du hachage de la clé publique de ce compte. On a vu au sujet du chiffrement asymétrique qu’il rendait possible une authentification, c’est à dire qu’il permet de prouver qu’une information vient de son propriétaire, parce que celui-ci possède la clé privée correspondant à la clé publique connue comme étant la sienne.

Dans une transaction de bitcoin, l’authentification n’est pas nécessaire pour recevoir de l’argent sur une adresse, mais elle l’est pour retirer de l’argent de cette adresse (plus exactement, pour consommer une sortie de transaction associée à cette adresse). Ainsi, pour retirer de l’argent d’un compte bitcoin, il faudra faire apparaître en clair la clé publique correspondante à l’adresse bitcoin à débiter.

Clé privée, clé publique ou adresse, ces éléments sont tous des nombres entiers très grands, mais il existe plusieurs manières de les représenter, afin de limiter leur longueur, ou de détecter des erreurs de recopie manuelle (on ajoute pour cela un hash à la suite du nombre, afin de pouvoir ensuite vérifier si ce hash correspond au reste).

Voici un exemple de clé privée, générée pour exemple et inexistante dans la blockchain du bitcoin (sinon, en la publiant ici, n’importe qui pourrait récupérer tous les bitcoins qui s’y trouvent), représentée sous trois formats différents:

  • Clé privée en nombre entier (longueur 78 chiffres) : 102061992561968853568950977252470692809088189136225027685948897740255026254358
  • Clé privée en nombre hexadécimal (longueur 66 caractères) : E1A50A699F686E58C1F6BD127ABA915B4D39246A443ADDA0A2DDFB29DCD89216
  • Clé privée au format d’import de portefeuille, WIF : Wallet Import Format (longueur 54 caractères) : L4nLN6MwwXSR46aa72G4RAHYBLQMw5BCmSpf72HNmHoiSt7ThnqV

Selon la représentation choisi, la clé privée est plus ou moins longue, mais le format WIF est le plus compact, si bien qu’une clé privée ne sera jamais représenté en moins de 54 caractères.

Voici maintenant les différentes représentations de la clé publique correspondante à la clé privée que l’on vient de présenter :

  • Clé publique en nombre entier (longueur de 78 chiffres) : 285765539192629817323937589327463562807921794138960550967853643494446978197436
  • Clé publique en nombre hexadécimal (longueur 68 caractères) : 0277C9903C47317E53DCBA9AC17788A0AB2BC3D87D2ADDD9234AEFF01B5BA667BC

A partir de cette clé publique, l’adresse est calculé en faisant passer cette clé dans une fonction de hachage :

  • Adresse en nombre entier (longueur de 58 chiffres) : 2572585619506013735068534208072914071089840138606773255319
  • Adresse au format d’import de portefeuille, WIF : Wallet Import Format (longueur 36 caractères) : 1AZkrJvzgz1qN7gvDR4kD3J3272Ph2V6wx

C’est ce dernier élément que vous pourrez rechercher dans un explorateur de blockchain. Si vous le faites avec cette adresse, l’explorateur vous dira qu’elle existe même si elle n’est pas dans la blockchain, car le format est valide, mais si vous regardez le solde, vous verrez qu’il est à 0.

Si vous vous demandez si le bitcoin utilise RSA pour le chiffrement asymétrique, et SHA256 dont on a parlé précédemment pour le hachage, les réponses sont : non pour RSA, et oui pour SHA256. Les clés des comptes Bitcoin sont créés selon un algorithme de la même famille que RSA mais permettant d’utiliser des nombres moins grands pour le même niveau de sécurité, nommé ECDSA. SHA256 est utilisée lors de plusieurs opérations de hachage par le bitcoin, mais d’autres fonctions sont également utilisées, comme RIPEMD-160.

Si les détails de la génération des clés privée, publique et de l’adresse bitcoin vous intéresse, voici un code conçu de manière la plus minimaliste possible permettant de générer une clé publique et l’adresse bitcoin correspondant à une clé privée. Ce code est donné pour des raisons pédagogiques, ne l’utilisez pas pour générer une adresse bitcoin faite pour recevoir de l’argent.

Maintenant que l’on a vu à quoi ressemble les clés et l’adresse d’un compte bitcoin, nous allons voir comment se déroule une transaction.

Réalisation d’une transaction

Pour recevoir des bitcoins sur un compte, seule l’adresse de ce compte est nécessaire, aucune autre information n’est requise pour inclure dans la blockchain une transaction dans laquelle ce compte sera crédité. En revanche, l’adresse de ce compte doit être exacte, car si elle contient une erreur, aucune vérification ne la détectera, et l’argent sera viré sur une adresse dont personne n’a la clé privée, ce qui signifie que cet argent sera à jamais perdu.

Ça c’est le principe, en pratique, les adresses sont utilisées dans un format nommé Wallet Import Format (WIF) qui contient une somme de contrôle, c’est-à-dire que l’adresse WIF ne contient pas que l’adresse bitcoin, mais également une suite de lettres et de chiffres qui lui est accolée et qui a été calculée à partir de l’adresse. Ainsi, si l’adresse ou cette suite ont fait l’objet d’une erreur de saisie, les deux ne seront plus cohérents et cela pourra être détecté. Le format WIF se base sur le codage base58, un format fait pour la saisie manuelle de grand nombres, utilisant, en plus de la somme de contrôle déjà évoquée, un ensemble de 58 caractères contenant des chiffres, lettres majuscules et minuscules sans utiliser celles se ressemblant trop, comme le i majuscule « I » et le L minuscule « l ».

Dans le cas d’une dépense depuis un compte bitcoin, l’adresse seule ne suffira pas, car il sera nécessaire d’avoir la preuve que le propriétaire du compte, celui possédant la clé privée, est d’accord avec le contenu de la transaction. Ce que le Bitcoin met en place pour obtenir cet accord est relativement simple :

Le contenu de la transaction est transmise au propriétaire du compte débité, celui-ci la relit, et si il est d’accord avec, il va calculer un hash de celle-ci, puis chiffrer ce hash avec sa clé privée. Il transmet alors le hash chiffré ainsi que sa clé publique au mineur. Ce dernier vérifie en calculant lui-même le hash de la transaction, que ce dernier correspond au hash donné par le propriétaire du compte, une fois celui-ci déchiffré par la clé publique qu’il a reçu avec. Si les deux correspondent, cela prouve que le propriétaire du compte correspondant à la clé publique est d’accord avec la transaction. Comme l’adresse du compte est un hash de la clé publique, le mineur vérifie également que la clé publique qui valide la transaction correspond à l’adresse du compte débité.

Avec ce fonctionnement, le propriétaire d’un compte peut valider une transaction de débit d’un de ses comptes sans jamais partager la clé privée de ce compte. Ceci permet de sécuriser la clé privée en la sanctuarisant dans un matériel spécifique: un portefeuille matériel (hardware wallet). La communication avec ce portefeuille se limite donc à lui envoyer le contenu d’une transaction, et à récupérer son hash chiffré ainsi que la clé publique. Ces matériels sont également conçus pour maximiser la sécurité contre d’éventuels virus informatique, de manière plus poussée qu’un smartphone par exemple. On appelle ces portefeuilles « froid » si ils ne sont pas connectées en permanence au réseau internet, et « chaud » si ils le sont.

On a mentionné précédemment qu’il ne fallait pas réutiliser une adresse de compte suite à un retrait d’argent sur celle-ci. La raison à cela est que le retrait est le seul moment où la clé publique est exposée dans la blockchain, visible par tous. Un pirate peut donc commencer à rechercher la clé privée ECDSA à partir de cet instant là, et même si cela est très difficile et très long, si jamais il y parvient il pourra vider le compte à l’adresse réutilisée. Ainsi, et c’est ce que font les portefeuilles matériel, il faut toujours vider intégralement un compte bitcoin dès qu’on utilise le solde d’une des transactions qui lui sont associés (ce qui signifie que si l’on consomme une des sorties de transactions associée à une adresse bitcoin, il faut également consommer toutes les autres sorties de transaction associées à cette adresse, et ce dans la même transaction, pour virer les bitcoin sur une nouvelle adresse qu’on aura créé).

Certain utilisateurs sont adeptes du portefeuille papier (garder ses clés publiques et privées sur un papier), mais cela pose tout de même un problème de sécurité, car le calcul pour générer une paire de clés publique/privée est trop complexe pour le faire manuellement sans risque important de se tromper (il nécessite des centaines de multiplications de nombres de plus de cent chiffres). Un ordinateur sera nécessaire pour ce calcul, mais il faudra être certain que celui-ci n’est pas infectée par un logiciel malveillant qui récupérerai silencieusement la clé privée pour la transmettre à des pirates informatique. Cela n’est pas une mince affaire, tant les possibilités et les méthodes d’infection d’ordinateur sont variées et en perpétuelle évolution. C’est pour cette raison qu’il est plus sûr de confier cette génération de clés à une machine prévue pour cela, comme un portefeuille matériel (hardware wallet), ou alors il faudra générer cette clé sur un ordinateur sans connexion à Internet, puis formater totalement cette machine après avoir noté sur un papier les clés générées, afin de de pas risquer de transmission de ces clés à des pirates informatiques lors d’un accès ultérieure de cet ordinateur à internet.

On comprend avec ce que je viens d’expliquer, qu’on va rapidement se retrouver à devoir utiliser un grand nombre d’adresses bitcoin si on achète et qu’on vend régulièrement des bitcoins. Heureusement, les portefeuilles matériel font appel à un mécanisme permettant de récupérer autant d’adresses que l’on veut à partir d’un seul message secret. Pour cela, ils utilisent BIP-32. C’est un mécanisme basé sur une fonction de hachage qui permet de produire autant de clés privées de comptes bitcoin que l’on veut à partir d’une seule graine (seed). On a vu qu’avec une fonction de hachage, on ne pouvait remonter à la valeur hachée depuis celle produite. On utilise donc une fonction de hachage, appliquée plusieurs fois sur la concaténation d’un nombre d’origine et d’un index, pour produire autant de clés privées que de valeurs de cet index Ce nombre d’origine, nommé graine, seed en anglais, doit être aussi grand que la clé privée à générer, car sinon on réduit la sécurité du fait du nombre plus petit de combinaisons possibles. Ces graines plus petites existent, mais elles sont moins sûres.

Afin de ne pas demander de mémoriser un nombre de 77 chiffres comme graine de récupération de toutes les clé privées d’un portefeuille matériel, ce nombre sera codé avec une suite de 24 mots (12 mots pour les graines moins grandes que les clés privées générées). Chacun de ces mots étant pris dans une liste standard de 2048 mots définie dans le standard BIP-39, descendant du standard BIP-32 déjà évoqué.

Détails du contenu d’une transaction

Si on regarde ce que contient la première source de bitcoin consommée dans la transaction dont on a déjà parlé précédemment, on voit ceci:

Première entrée consommée par la transaction

Bien qu’il y ait un lien nommé Output, ceci est bien la première source de bitcoin consommée par cette transaction (source de 2000 bitcoin). Comme on l’a vu, une transaction ne consomme pas en entrée un compte bitcoin, mais la sortie d’une transaction précédente, et ici c’est cette sortie qui est consommée (visible en cliquant sur le lien Output) :

Sortie consommée dans la première entrée de la transaction

On retrouve dans cette sortie le montant de 2000 bitcoin consommé dans l’entrée de transaction qui nous intéresse (car une sortie de transaction doit toujours être consommée intégralement). A cette sortie de transaction est associée un « Pkscript ».

Le « Pkscript », pour « Public Key Script » est une condition devant être satisfaite pour pouvoir consommer cette sortie de transaction. Il existe plusieurs façons d’écrire cette condition mais ici, le Pkscript contient trois lignes : deux instructions et une valeur numérique. Ce script défini que pour consommer cette sortie, il faut fournir une valeur qui, une fois passée par une fonction de hachage « hash160 », doit être égal à la valeur numérique contenue dans ce Pkscript. En réalité, une telle valeur correspond à la clé publique du compte bitcoin dont l’adresse est associée à cette sortie de transaction. Ainsi, cela revient à dire que pour consommer cette sortie, il faut disposer de la clé publique du compte. La clé publique seulement, pas la clé privée ? Si, et on va voir pourquoi avec l’entrée de la transaction qui nous intéresse.

Dans la première entrée de la transaction présentée ci-dessus, on retrouve le Pkscript issu de la sortie de transaction qui est consommée, et un Sigscript (Signature script) qui contient la valeur qui satisfait la condition décrite dans le Pkscript. Il y a également un Witness.

Le Witness (témoin) est issu d’une modification apportée au bitcoin en 2017. Avant cela, les informations contenues dans le Witness étaient dans le Sigscript, mais le principe est le même. Le Witness (ou le Sigscript dans d’autres types de transaction) contient deux lignes : un hash du contenu de la transaction qui a été chiffré avec la clé privée compte bitcoin débité, et la clé publique de ce compte. On a déjà parlé de ces deux éléments précédemment : ils permettent au propriétaire du compte débité de prouver qu’il est bien le propriétaire de de compte, tout en garantissant qu’il a relu le contenu de la transaction, et qu’il est d’accord avec celui-ci.

Voici l’entrée d’une transaction qui n’utilise pas de Witness:

Entrée de transaction sans Witness

On voit dans cette transaction que le Pkscript est plus long. Il spécifie qu’il faut:

  • OP_DUP : dupliquer le dernier élément de la pile, lequel est le second élément du Sigscript, car le contenu du Sigscript est mis dans la pile avant l’exécution du Sigscript. La présence d’un pile provient de l’utilisation d’une manière d’écrire les opérations mathématiques sans parenthèse appelée notation polonaise inverse.
  • OP_HASH160 : faire un hachage du dernier élément de la pile, autrement dit du second élément du Sigscript
  • Charger dans la pile la valeur 348ceb2e0315a310e6692c938967d8207f7dc9fd
  • OP_EQUALVERIFY : vérifier l’égalité entre les deux dernières valeurs de la pile, autrement dit la valeur ci-dessus commençant par 348ce et le résultat du hachage du second élément du Sigscript. La valeur dans le Pkscript était un hash de la clé publique, et la valeur du Sigscript est la clé publique, on vérifie donc que la personne qui fourni le Sigscript possède la clé publique du compte bitcoin.
  • OP_CHECKSIG : vérifier le contenu du Sigscript, autrement dit le hash de la transaction avec la valeur du hash du Sigscript (le premier élément du Sigscript) une fois celui-ci déchiffré avec la clé publique (second élément du Sigscript). On vérifie ainsi que la personne qui fourni le Sigscript possède la clé privée du compte bitcoin, et a lu et approuvé le contenu de la transaction (sans quoi il n’aurait pas hachée et chiffré ce contenu avec la clé privée de son compte).

Si vous voulez de détails sur une partie des calculs effectués pour vérifier le contenu de cette transaction, ainsi que d’une autre sans champ Witness, voici un code en python qui effectue la vérification de la condition du Pkscript ainsi que le calcul de l’adresse du compte à partir de la clé publique contenu dans le Witness ou le Sigscript.

Les autres blockchaines

Jusqu’ici, il a surtout été question de la blockchain du Bitcoin, mais il en existe beaucoup d’autres, et le principe de blockchain est utilisable dans bien d’autres domaines que la monnaie, il est ainsi intéressant de comprendre les caractéristiques qui font que la blockchain peut avoir de multiples applications.

Comme on l’a vu, une blockchain est une sorte de registre qui n’appartient à personne, et n’existe que parce qu’elle a des utilisateurs (les « mineurs »). Elle est régie par un code informatique, sorte de règle du jeu à laquelle les utilisateurs adhérent (au risque de voir leur activité ignorée par les autres utilisateurs, c’est le « consensus »). Le contenu de ce registre est mis à jour selon des « smart contracts », ou « contrats intelligents », qui sont des listes d’instructions (ou conditions à satisfaire, comme dans un contrat papier) pour que les engagements mentionnés soient tenus par les parties mentionnées dans celui-ci.

Formulé ainsi, cela peut sembler obscure, mais on peut prendre un exemple pour clarifier: imaginez un smart contract dans une blockchain utilisée par une compagnie aérienne. Ce contrat stipule que si un billet d’avion est acheté, alors si le vol correspondant est en retard, 5% du prix du billet sera remboursé à l’acheteur du billet. Ce type de contrat existe déjà hors d’une blockchain, mais cette dernière apporte les caractéristiques suivantes :

  • Les informations sur l’achat du billet, le contrat lié à cet achat, et les retards des vols sont publiques et consultables par n’importe qui.
  • L’exécution du contrat pourra être faite par n’importe quel utilisateur de la blockchain : la compagnie aérienne, le voyageur ou, et surtout : n’importe qui d’autre. Ainsi, à partir du moment ou la compagnie aérienne et le voyageur auront signé le smart contract, son exécution ne dépendra plus d’eux, mais du contenu du contrat, et du producteur des données qu’il consomme, ici les horaires des arrivées des vols (dont le producteur pourra être l’aéroport d’arrivée).
  • La sécurité de l’ensemble ne repose plus sur le système informatique de la compagnie aérienne, qui déclenche le remboursement dans un système classique sans blockchain, mais sur la spécification de cette blockchain (ex: l’utilisation de la preuve de travail est vulnérable à attaque des 51%)

Voilà, j’espère que cet article a répondu au moins en partie à vos attentes, et je vous invite à le commenter si vous avez des remarques ou des suggestions.

If you’ve heard about this cleverly designed puzzle, and wonder how to solve it, how many solutions there is for each day, or if you can solve a day without returning some of its pieces, you’re at the right place.

If you haven’t heard yet about this puzzle, you can try the playable online version I made, which also tells you if a solution exists with the pieces already placed. The goal is to put all the pieces in the puzzle frame, only leaving visible 3 cells : one for the month, one for the day in the month, and one for the day of the week.

I’ve got the puzzle above for my birthday, and I immediately like it, even if I hardly ever find a solution for the present day.

There are several different versions of this puzzle, but mine has blue pieces with one smooth side:

And one frosted side:

As the frosted side looks better to me, I consider it as the original one, the one without pieces upside down.

Frosted side solutions

After trying to find a solution for almost an hour, I wondered how many solutions there were for each day, and more important : does it have solutions without turning some pieces upside down?

To figure out these questions, I’ve created a python code able to look for all existing solutions for any date.

This code is also generic enough to be easily adapted to any « Tetris like » puzzle, only by providing another array for the « board » and other lists of vectors for the « pieces ».

With this code, I tried to look for every solutions for each of the 366*7 possible days. Unfortunately, I quickly learnt that, even with a 12 cores computer, using this code for such task would have required 8,5 days of computation. Therefore, I recoded the same algorithm in C++, and optimized it to run as fast as possible. With this new algorithm, what would have required 8,5 days with the python version, ended in less than an hour!

From this, I created this page:

Daily Calendar Puzzle Solver

It is a webpage linked to a database containing all 4,864,096 existing solutions of this puzzle, and able to display any of them. I will improve the design to make this page prettier when I will have some time.

Therefore, I have the answer to my question : Do I need to return any piece to find a solution to every possible day?

The answer is : Yes.

Not so surprising, because when I looked at the list of dates without solution, a pretty obvious thing appears: Wednesday the 27th never has a solution.

When you try to solve this day, you quickly understand why it’s impossible, which could have been done without such amount of computation.

Aside Wednesday the 27th, other not obvious dates don’t have solution without returning pieces, here they are:

  • Monday 1st March
  • Monday 6th March
  • Monday 5th October
  • Wednesday 6th April
  • Thursday 6th October
  • Saturday 5th October
  • Sunday 6th April
  • And all Wednesday 27th of course

With this list, you may ask: What is the minimum number of pieces I have to turn upside down to have a solution to every possible date?

I also checked the answer to this question, and this answer is : 2

Pretty interestingly, if you obviously need to turn the « Q » piece upside down to solve every Wednesday 27th, this single piece turn is enough for every date except : Sunday 6th April.

To solve this last date, you’ll need to turn another piece, the « Small S » for example (the S of 4 squares).

Allowing these 2 pieces alone to be turned upside down, you are then 100% sure that a solution exists for every possible date.

To ease the solving of this puzzle, I wondered if there is a piece, when placed on the top left square, which always lead to a solution?

The answer is, also : no

If you put the straight I piece of 4 squares on the top left square if the puzzle (Jan or Feb depending on the date), this would be part of the solution for 86,3% of the dates.

For the remaining 13,7% of all dates, you can put the U shaped piece on the top left square, but this would be part of the solution for only 7,5% of all dates, meaning that 6,2% of all dates can only be solved with another piece than I or U on the top left square.

You’d reiterate this until no more unsolved date remain, and only the T piece wouldn’t have been put on the top left square. The sequence of the pieces put on the top left square would be this one :

All the analysis described above is related to find solutions by using only the frosted side of the pieces, but what about only using the smooth side?

Smooth side solutions

I also performed the same analysis with the smooth side, and get similar results.

There are as many dates without solution as when using only the smooth side:

  • All Monday 27th (instead Wednesday)
  • Monday 25th November
  • Monday 1st March
  • Thursday 28th April
  • Friday 6th November
  • Saturday 1st March
  • Saturday 6th April
  • Sunday 5th October

As with the frosted side up, the absence of solution for Monday 27th is quite obvious, but unlike with the frosted side, if we allow the Q piece to be returned, all dates get at least one solution.

By comparing the lists of dates without solution with all pieces on frosted side, and all on smooth side, you’ll see that Monday 1st March is the only date without solution with all pieces on the same side. To solve this day, you shall have at least one piece the opposite side compared to the others.

Similarly, the list of pieces on the top left square of solutions start with the same piece, for 81,6% of solutions, and the two next ones are the same but in opposite order : Q and U instead U and Q for frosted side. As for the frosted side, all pieces except one are required at on the top left square to cover all solutions, but the useless one for smooth side is the Big S instead the T piece of frosted side (Big S is the second from the right on the picture above).

Both sides solutions

On some versions of this puzzle, the pieces don’t have distincts side, so you cannot talk about « upside down » or « frosted » side. Thus, I wondered about the solutions without using specific side for the pieces, and allowing any of them be used on both of their side up or down.

Allowing any piece to be turned upside down, my optimized C++ algorithm took 15 hours of computation on a 12 cores computer to find all existing solutions for every possible dates.

This has shown that there are from:

  • 97 solutions for Monday 6th April, to
  • 10374 solutions for Tuesday 7th June

For comparison, if all pieces are used on the same side, there are from :

  • 0 to 152 solutions for Tuesday 7th January with smooth side
  • 0 to 197 solutions for Tuesday 29th November with frosted side.

If we sort all possible dates by their number of solutions, and create groups by ranges of number of solutions we get:

  • From 97 to 999 solutions: 595 dates
  • From 1000 to 1999 solutions: 1050 dates
  • From 2000 to 2999 solutions : 558 dates
  • From 3000 to 3999 solutions : 242 dates
  • From 4000 to 4999 solutions : 102 dates
  • From 5000 to 5999 solutions : 28 dates
  • From 6000 to 6999 solutions : 13 dates
  • From 7000 to 7999 solutions : 12 dates
  • From 8000 to 8999 solutions : 2 dates : Tu 29th Jan (8675), Tu 1st July (8067)
  • From 9000 to 9999 solutions : 1 date : Tu 7th Jan with 9266 solutions
  • From 10000 to 10374 solutions : 1 date : Tu 7 June with 10374 solutions

As we can expect, allowing any piece to be returned drastically reduce the number of pieces required on the top left square to be sure that a solution exists. Only two pieces are required to cover all dates (when 9 were required if all pieces are on the same side) :

  • L of 4 squares for all dates except 28 dates
  • Q piece for the remaining 28 dates : all 1st of march, 2nd and 8th of July and 2nd of September

Knowing all existing solutions, I am able to check if there is always an existing solution with specific pieces positions. Here are the hypothesis I’ve checked so far:

  • When using both sides of the pieces, there is always an existing solution when the U piece is placed around Friday and Tuesday for Fridays and Tuesdays.

Side note about the analysis described here : it has been performed on all 7*12*31=2604 physically possible dates, including 6*7 not existing ones as February 30th or November 31th.

Time span if this puzzle

Aside the existing solutions, you may wonder how long we need to wait to go through all possible dates. The answer can be found this way:

The question is linked to the number of years required to see each date be all days of the week, including the 29th of February.

Perhaps you noticed that each year, a given date shift by one weekday each year. This is because 365 days is 52 times 7 days plus 1. When a 29th of February is in-between, the shift is by 2 weekdays. As there is a 29th of February each 4 years, the weekday shift from year to year follow the sequence : +1, +1, +1, +2, +1…

If we take a date matching a Monday, this date will then becomes the following years : Tuesday, Wednesday, Friday (after a 29th of February), Saturday, Sunday, Monday, Wednesday (after another 29th of February), Thursday.

Therefore, as a weekday is skipped by a 29th of February, more than 7 years are needed to make dates cover all weekdays. Depending on the starting year, it can take from 9 to 11 years:

  • Monday, Tuesday, Wednesday, Thursday (29th), Saturday, Sunday, Monday, Tuesday (29th), Thursday, Friday : 10 years
  • Monday, Tuesday, Wednesday (29th), Friday, Saturday, Sunday, Monday (29th), Wednesday, Thursday : 9 years
  • Monday, Tuesday (29th), Thursday, Friday, Saturday, Sunday (29th), Tuesday, Wednesday, Thursday, Friday : 10 years
  • Monday (29th), Wednesday, Thursday, Friday, Saturday (29th), Monday, Tuesday, Wednesday, Thursday (29th), Saturday, Sunday: : 11 years

When we add the 29tb of February, to know how many years are required to get all weekdays for this 29th, we first need to know the weekday shift from a 29th of February to the next one. 365 days after a 29th of February, this is the 28th. So we need to apply the same computation 4 times: Monday 29th of February, Tuesday 28th, Wednesday 28th, Thursday 28th, Saturday 29th.

So from a Monday 29th, we get Saturday for the next one: plus 5. As 5 and 7 are both prime numbers, the 7 days of the week will be a 29th of February, before it will restart. Therefore, 7 times will be necessary to have the 7 weekdays for the 29th, so 7 times 4 years = 28 years.

Chains of solutions

As I computed all existing solutions, I wonder if it exists solutions (using both sides of pieces) such as, when moving few pieces (two, three or four among the ten), we can get a solution for the next day.

I created a python script to look for these chains of solutions, allowing 2, 3 or 4 pieces to be moved (I consider that moving 5 pieces is not interesting because it represents half of the pieces of the puzzle). I wonder which is the longest chain for each number of pieces allowed to be moved.

I found the following answers:

  • Allowing 2 pieces to move, the longest chains of solutions have 4 dates, and 3 chains like this exist, with, as starting dates : Sun 17th Feb, Sun 17th Oct and Sun 17th Nov.
  • Allowing 3 pieces to move, the longest chains of solutions have 5 dates, and 10 chains like this exist, with, as starting dates : Tue 17th Jun, Thu 24th Jul, Sun 17th Apr, Sun 17th Jul for 2 chains, Sun 17th Sept for 2 chains, and Sun 17th Dec for 3 chains.
  • Allowing 4 pieces to move, the longest chains of solutions have 7 dates, and 3 chains like this exist, with all, as starting date, the Sat 17th Nov.

Here is one of the 2 solutions for Sunday 17th of July starting a chain of 5 consecutive dates solutions :

Solution starting a chain of 5 solutions

The pieces to move in order to get the solution for Monday 18th July are the ones current on Mon, 18 and 21. For Tuesday 19th July, the pieces on Wed, 19 and 20 need to be moved. Pieces on Thur and 20 need to be moved to create Wed 20 July. Indeed, pieces on Thur, 21 and 13 need to be moved to solve Thur 21st of July from 20th July solution.

Below is another solution starting a chain of 4 consecutive dates solutions:

Solution starting a chain of 4 solutions (not 2022 but 2019)

From the solution above, it is possible to get the solutions of 18th, 19th and 20th of February by only moving 2 pieces to get the next dates solution (these pieces are each time the ones on squares 19 and 20 in the picture above).

Other similar puzzles

If you’re interested, other similar puzzles exists (you can try them online with the previous link, and there is also links to pages providing solutions to them).

Si vous arrivez sur cette page, c’est probablement que vous vous demandez comment fonctionne les « histoires à écouter » que l’on trouve chez les marchands de journaux, également appelées « audiocontes magiques ».

Je me suis posé la même question face à la boîte à histoire suivante, même si il en existe plusieurs autres types, Disney notamment :

Après une analyse et quelques tests, voici ce que j’ai compris:

Tout d’abord, de part mes connaissances techniques, j’ai supposé que le personnage qui permet de déclencher l’histoire contient une puce RFID. Pour vérifier cette hypothèse, j’ai téléchargé une application NFC pour smartphone et scanné la base de la figurine. Cette application m’a permis de valider cette hypothèse, et d’apprendre que la puce située dans la base de la figurine contient 1ko de données. En lisant le contenu de ce kilo octet de données, il apparaît que pratiquement toutes ces données sont des zéros, à l’exception d’une petite partie. En comparant les données des puces de deux figurines, je m’aperçois qu’elles ne diffère que pour deux parties :

– l’identifiant de la puce

– un octet qui est égal à 21 pour une puce, et à 22 pour l’autre.

Ensuite, la boîte est vendue avec une carte micro SD qu’il faut insérer dedans pour qu’elle fonctionne. En lisant cette carte sur un système Windows, je m’aperçois que son contenu est compatible avec ce dernier, et que la carte contient un dossier avec 30 fichiers d’extension « smp » à l’intérieur. Ces fichiers font entre 10 et 30 Mo, ce qui laisse penser qu’ils contiennent les données audio des histoires racontées par la boîte, d’autant plus qu’un internaute a déjà analysé ces fichiers pour tenter de les decoder, mais sans arriver à éviter que les données non audio ne polluent le son décodé (le son qu’il a obtenu était bien l’histoire, mais avec beaucoup de craquements).

Les noms des fichiers sont des numéros : T1121, T1122… Les différences dans leurs noms correspondent exactement aux différences vues dans les données des puces des deux figurines.

En copiant le premier de ces fichiers à l’intérieur d’un répertoire du même nom sur une autre carte micro SD, je découvre que la boîte à histoire lit l’histoire du premier des personnages, mais pas les autres histoires. En renommant le second fichier avec le nom du premier, j’espère faire en sorte que la première figurine déclenche sa lecture. Malheureusement, cela ne fonctionne pas. J’en déduis que le contenu du fichier est vérifié par rapport à son nom, afin d’empêcher la lecture d’un fichier par la puce d’une autre figurine, ce qui permettrait d’écouter les 30 histoires en ne disposant que d’une seule figurine. Ainsi, une cryptanalyse serait nécessaire pour comprendre comment extraire les données audio de ces fichiers. Cependant, comment cette boîte à histoire doit avoir un coût réduit, il y a fort à parier que le codage doit être rudimentaire, afin de ne pas nécessiter de composant performant et cher.

Ce qui est ci-dessus est valable pour les boîtes à histoire des éditions Hachette, mais j’ai aussi fait l’analyse pour les boîtes à histoire Disney des éditions Altaya. Ces dernières sont assez différentes car la puce des personnages n’est pas lisible depuis un smartphone, si bien qu’elle doit utiliser une technologie basée sur une fréquence autre que 13,56MHz (il existe aussi des puces en 125-134,2kHz, 860-960MHz et 2,4GHz). Enfin, leur carte micro SD fait 1Go mais ne contient pas de fichier visible depuis un système Windows, si bien que les 80 histoires de la collection doivent s’y trouver mais sous un format de fichier différent des éditions Hachette (les cartes micro SD peuvent contenir n’importe quel système de fichiers, même un spécifique utilisé nulle part ailleurs). Ces boîtes à histoire sont donc plus robustes à une utilisation sans acheter tous les personnages.

En conclusion : toutes les histoires de ces boîtes sont contenues dans la carte mémoire vendue avec la boîte, mais sous un format codé. Une puce lisible sans contact, et se trouvant dans la base des personnages que l’on pose sur la boîte pour déclencher la lecture des histoires, contient un numéro identifiant le fichier contenant l’histoire correspondante au personnage.

Voilà, j’espère que cet article aura répondu aux questions que vous vous posiez sur la technologie derrière ces « boîtes magiques ».

Pour ce nouveau post, rien de très exceptionnel, simplement deux solutions (parmi d’autres) d’un casse tête fabriqué (au moins) par l’enseigne HEMA BV.

Ce casse tête est un puzzle fait de pièces basées sur de petits carrés (façon pixels ou Tetris) et qu’il faut parvenir à toutes faire entrer dans un carré de 8×8. Il est reconnaissable car il possède une pièce en forme de croix rouge, une en forme de T violet, une en forme de C bleu et deux en forme de L et une en forme de h minuscule jaune.

J’ai développé une version web de ce puzzle, afin que ceux qui ne l’ont pas puissent jouer avec (attention! toutes les solutions sont dans la suite de cet article, continuer à lire vous gacherai le plaisir de sa résolution).

Voici deux solutions à ce casse tête (l’une était celle avec laquelle le jeu était vendu, et l’autre vient de l’internet)

et voici l’autre solution :

De part sa fabrication, ces deux solutions peuvent évidemment en occasionner d’autres par rotation et transposition en miroir (4 par rotation avec chacune leur équivalent en miroir soit 8 au total).

J’aurais pu en rester là, mais suite au développement d’un code permettant de résoudre un « Daily Calendar Puzzle » (un autre puzzle basé sur des pièces type Tetris) j’ai réussi à déterminer et analyser toutes les solutions possibles pour ce puzzle.

Si l’on ne compte pas les 4 rotations et la transformation en miroir des solutions de bases dans le nombre total de solutions, il existe 89 solutions de base à ce puzzle. Il a fallu 33 heures de calcul et 688 millions de tentatives de positionnement des pièces pour arriver à ce chiffre.

En étudiant ces 89 solutions, j’ai identifié des variations parmi celles-ci. La première solution présentée dans cet article contient une telle variations : le C bleu, imbriqués dans le double carré vert, forme un figure symétrique, que l’on peut retourner comme dans un miroir sans modifier sa forme extérieur. Un tel retournement permet d’obtenir une autre solution légèrement différente de la précédente.

Ainsi, si l’on réduit les 89 solutions aux seules pouvant donner de telles variations, on obtient 25 solutions totalement distinctes, que voici :

La première de ces 25 solutions est celle qui a le plus de variantes : 16.

8 de ces variantes sont dues aux deux moitiés de carré que l’on peut voir dans cette solution :

Ainsi, il est possible d’inverser la partie inférieure de cette solution, comme dans un miroir, afin d’obtenir une variante de celle-ci :

La moitié inférieure a été retournée comme dans un miroir, mais on peut également la retourner de 180° et combiner ces 2 modifications. On peut en faire autant avec la moitié supérieure:

  • 2 possibilités en miroir
  • multiplié par 2 possibilités par rotation
  • multiplié par 2 possibilités selon la moitié supérieure où inférieure

Cela donne 8 possibilités de variations.

Ces 8 possibilités se voient doublées par l’inversion des pièces rose et bleu en haut à droite de la manière suivante :

On obtient alors 16 variantes de cette première solution.

La seconde solution des 25 comprend 4 variantes :

  • 2 en inversant les pièces violette et saumon:
  • 2 autres solutions avec une inversion verticale de la partie droite :

La troisième des 25 solution comprend 8 variantes :

  • 2 en inversant les pièces lavande et saumon en bas à droite
  • 2 fois plus en inversant les pièces violette et zigzag vert de la droite
  • 2 fois plus en inversant les pièces verte et bleue en bas à droite

La quatrième des 25 solutions comprend également 8 variantes :

  • 4 variantes sont créées en retournant et en inversant en miroir les pièces violette et bleu en haut à droite, car elles forment un rectangle à elles deux
  • 2 fois plus de variantes sont créées en inversant en miroir la moitié inférieure du puzzle, en utilisant le double carré vert du centre comme pivot

La cinquième des 25 solutions comprend également 8 variantes :

  • 2 variantes en inversant en miroir les pièces verte et bleue en bas à gauche
  • 2 fois plus en inversant en miroir les pièces rose et bleue en haut à gauche
  • Z fois plus en inversant en miroir le zigzag et la pièce violette situés en haut à droite

La sixième des 25 solutions comprend 8 variantes :

  • 2 par retournement en miroir des pièces rose et bleu situées en bas à gauche
  • 2 fois plus par retournement en miroir des pièces bleue et du double carré vert situées en bas à droite
  • 2 fois plus par inversion des pièces zigzag et double carré vert situées sur la droite

La septième des 25 solutions comprend 4 variantes :

Ces variantes sont créées par retournement et inversion en miroir des pièces saumon et bleue qui forment ensemble un rectangle en haut à gauche

La huitième des 25 solutions est une variante de la précédente, qui comprend elle même 4 variantes :

2 variantes par inversion des pièces zigzag et double carré :

Et 2 autres variantes par inversion en miroir des pièces rose et bleue situées en bas à gauche.

La neuvième des 25 solutions comprend 4 variantes :

  • 2 par inversion en miroir des pièces rose et bleue situées en bas à gauche
  • 2 par inversion en miroir des pièces bleue et verte situées en bas à droite

La dixième des 25 solutions comprend deux variantes, en inversant en miroir les pièces rose et bleue situées en bas à gauche :

La onzième des 25 solutions comprend également 2 variantes, en inversant en miroir la pièce bleue et le double carré situés en bas à gauche :

La douzième des 25 solutions comprend également 2 variantes, en inversant en miroir les trois pièces orange, rose et lavande situées en haut à gauche :

La treizième des 25 solutions comprend également 2 variantes, en inversant en miroir la pièce bleue et le double carré situés en bas à gauche :

La quatorzième des 25 solutions comprend 2 variantes, en inversant en miroir les pièces orange, saumon et violet situés en haut à gauche :

La quinzième des 25 solutions comprend 2 variantes, en inversant en miroir le double carré et la pièce bleue situées en bas à droite :

La seizième des 25 solutions comprend 2 variantes, en inversant en miroir les pièces orange, saumon et violet situés en haut à gauche :

La dix-septième des 25 solutions comprend 2 variantes, en inversant en miroir le double carré et la pièce bleue situées à droite :

La dix-huitième des 25 solutions comprend 2 variantes, en inversant en miroir le double carré vert et la pièce bleue situées en haut à droite :

Les solutions restantes n’ont pas de variantes (mis à part évidemment l’inversion en miroir de l’ensemble):

If you have bought the LEGO Ideas set 21321 : the International Space Station, you may have wonder what represent each of the oddly shaped elements you built, regarding the real international space station.

Unfortunately, the building manual doesn’t provide usefull data about this. Due to this, I have written this blog post.

Before going into the details of all ISS elements, I will talk about one frustrating thing related to it : the orbiter of the space shuttle cannot be docked where it should be, because both sides are stud.
Fortunately, there is a simple trick to fix this, simply save the round part of this step:

Don’t use is at this step, and keep it to be used as connector between the space shuttle orbiter and its docking bay, because, this part fits perfectly to connect them.

And this part also works for two others spacecrafts included in this set:

Back to the topic of this article : The correspondance of the LEGO ISS to the real one.
The LEGO International Space Station corresponds almost entirely to this configuration:

Thus, by following the building instructions manual, we can map the built elements with the real ones as following.

First are the mini-build from bag 1. If the orbiter of the Space shuttle seems obvious, here are the corresponding spacecrafts for the three other builds : Crew Dragon, Cargo Dragon and Progress.

Now we can map the differents Space station elements, first is the truss, which is a uninhabited structural elements, with Solar Alpha Rotary Joint (grey parts) at both extremities, allowing the rest of the truss, supporting solar panels, to turn in order to let them always face the sun. Its scale is the same than the small included astronauts, so its should be 66% of its size to match the scale of the entire station (it is actually a little bit too big):

Second is the Node 2 Harmony module, which is, as all the other modules of the model, a little bit to small compared to the whole station size. They should be 22% bigger in diamter to match the scale of the whole station :

Third is the US Lab Destiny, connected to previously built Node 2 :

Fourth is the Japanese Experiment Module, connected to Node 2 :

Fifth is the Colombus module, also connected to Node 2:

Sixth is the Node 1 (center rectangular connecting part) with Quest Joint Airock (small cylinder) and Z1 truss (above Node 1), which is the connecting point between the inhabited modules and the station Truss elements:

Seventh are the Space To Ground Antennas:

Eighth is the Node 3 (center part) with Permanent Multi-purpose Module (cynlider), Bigelow Expandable Module (white ball), Airlock (black cone) and Copula (grey cone with black windows). The copula is the earth obervations point, which we can frequently see on images taken from inside the ISS, because the view is stunning:

Ninth is the Cygnus spacecraft docked to Node 3. The one docked to the station in 2020 doesn’t look like this (this is the only difference between LEGO ISS and the real one, if we don’t take into account which spacecrafts are connected to the differents airlocks). It has solar panels because it is a spacecraft which is designed to be autonomous, like the Progress ones we will also see later. It is a resupply cargo spacecraft. A LEGO fan have created a 2020 version of this spacecraft corresponding to the one actually docked to the station, because the one with rectangular solar panels is from 2013 :

Tenth is the Mini-Research Module (grey cylinder) with Progress spacecraft docked on it. On the real ISS picture below, the Mini-Research Module is in the top left corner, and we can see the Pirs module with a Progress spacecraft docked on it in the top middle. This module is not represented on the LEGO model, only the Progress spacecraft is:

Eleventh is the Functional Cargo Block. It has its own solar panels without begin a cargo spacecraft. The reason to this is that is it one of the very first modules of the station, and it has been put into orbit before the big solar panels of the truss were there. That’s why it needed its own solar panels, because when it became a module of the space station, there were no available solar panels to power it:

Twelfth is the Service Module with another Progress spacecraft docked on it. As for the Functional Cargo Block, the Service module also have its own solar panels, because it is the very first element of the space station put into orbit. In december 1998, the International Space Station was only composed of this module all alone :

Thirteenth are the radiators, used to dissipate in space the excess of heat received from the sun light, which can prevent the system from working in their temperature range:

Fourteenth seems to be the S-Band antenna, according to the integrated truss assembly diagram:

Fifteenth seems to be the Wireless Video System Antenna, according to the integrated truss assembly diagram:

Sixteenth are several Express Logistics Carrier, which is a support for station spare replacement parts and scientific experiments modules:

Seventeenth is one of the three External Stowage Platform (the two others are so small that they are not present on the LEGO ISS):

Eighteenth is the Alpha Magnetic Spetrometer:

Nineteenth is the Mobile Servicing System, also called Canadarm (because the first version has been built by canadian firm for the space shuttle), which is a remote command arm used to manipulate spacecraft (for docking and undocking), ISS modules and help astronauts during extravehicular activities (EVA):

Twentieth and lasts are other radiators, these ones are here to dissipate the heat of the electric transformers used to power the station with the electricity produced by the big solar panels. A LEGO fan have created an improved version of these radiators, as « wavy » as the real ones.

I spare you the description of the solar panels, so hugh and visible, the unique elements of the bag number 6.

Even if this ISS LEGO build is pretty detailed and accurante, there is some little differences I want to detail in this post.

First difference with real International Space Station is the scale of the different elements. The scale of the LEGO ISS, considering its lengh in its longer dimension is 1/224, but its elements are not all at this scale:

  • The orbiter of the space shuttle is at scale 1/389, so it should be 73% bigger to match the ISS scale. Fortunately, Adam Wilde, a LEGO fan, has created a design of the space shuttle orbiter with the same scale as the ISS (« io » file is from the LEGO digital designer software Stud.io).
    With this « at scale » orbiter docked on it, the ISS looks like this:
  • The astronauts are at scale 1/150, so they should be 66% of their size to fit the ISS scale
  • Cargo Dragon and Progress are well scaled regrading their overall span, but a little bit small without their solar panels
  • Crew Dragon is pretty well scaled
  • The modules of the ISS, regarding its entire span, should be 22% bigger in diameter
  • The truss of the ISS is at the same scale as the astronauts, 1/150, so it should also be 66% of its size to fit the overall ISS scale
  • The Dextre tool of the Mobile Servicing System is not provided in this set, so a LEGO fan has created it.
  • Several spacecrafts which have, or may have, visited the International Space Station during its 20 years lifetime are not present in this LEGO set, so a LEGO fan has designed them (and also improved the design of the included spacecrafts)

Another thing to know about the ISS is that is has changed during time, as we can see in this video. Even if it is finished, today, there are cargos which dock and undock to it, changing a little bit its aspect. Thus, this LEGO version doesn’t correspond exactly to what the ISS has looked like at any point point of time, but it is so close than small modifications can be performed to make it fit with the first diagram presented in this article, roughly: putting round solar panels to the Cygnus module, moving Progress spacescrafts to different docking places and adding currently visiting Dragon spacecrafts.

If you are interested in the space program which took mankind to the moon, you probably eared the odd names of the moon rocket stages. The Saturn V rocket have three stages, and their names are : S-IC, S-II and S-IVB.

We can easily guess that the « S » stands for « stage », so the second stage is named quite logically, « S-II » for « stage 2 » with the use of roman numbers. But the two other stages names are quite strange.

The reason of this strange naming is historical.

During one early period of Saturn planning (about 1958-1959), even before the choice of « Saturn » name, and also before the famous « We choose to go to the moon » speech of president J.F.Kennedy, a « C » serie of rockets has been planned based on Silverstein Committee recommandation for next generation intercontinental ballistic missile. Among them, the C-4 rocket was a four stages rocket, so its last stage was named S-IV.

I couldn’t find any written confirmation of this, but I guess that when NASA decided to go to the moon by using C serie rockets, it was necessary that all of them share the same last stage, in order to be able to test and validate the moon spacecraft above the earth, by using a small rocket, before sending it to the moon. If both small and big moon manned program rockets where sharing the same last stage, all will go the same between a separation test above the earth, launched with a small rocket, and the actual separation on the way to the moon, launched with the big rocket.

Among the C serie rockets, two were selected for the moon manned missions « Apollo » program : C-1 and C-5.
C-1 was renamed Saturn I, and first launched unmanned in 1961.
Its fist stage was named S-I, and the second, from the early C-4 last stage, S-IV.

Unfortunately, it was not powerful enough to bring Apollo spacecraft to the earth orbit, even without the lunar module. Therefore, an enhanced version was developed, the Saturn IB, and the two stages of this new version was named S-IB and S-IVB, because they both have been improved. Saturn IB was first launched in 1966.

From this, we can guess what followed. Saturn V has been developed from early C-5 and first launched in 1967. As the first stage of Saturn V was entirely different from the S-IB of Saturn IB, it has been named S-IC, and the two other stages kept their names : S-II for its new second stage, and S-IVB for the third stage which was the same as the second stage of Saturn IB.

Si vous avec vu toute la première saison de la série d’Apple TV+ « For All Mankind », vous vous êtes sans doute demandé ce qui est plausible dans l’histoire racontée, ce qui s’est vraiment passé, et ce qui relève de l’uchronie. Si vous n’avez pas vu toute la première saison, passez votre chemin car cet article contient beaucoup de spoilers. Si vous avez vu toute cette première saison et que les réponses à ces questions vous intéresse, vous pouvez continuer à lire.

La série débute le 26 juin 1969, historiquement entre les mission Apollo 10, dernière répétition de l’alunissage qui a approché le sol lunaire de 15 km le 22 mai, et Apollo 11, alunissage historique de Neil Armstrong et Buzz Aldrin le 20 juillet 1969. Alors que les servies de renseignement américains n’ont constaté que deux lancements, tous deux réussis, de la fusée lunaire russe, la N1, la planète entière voit en direct à la télévision le premier pas sur la lune du cosmonaute Alexeï Leonov. Les américains sont sous le choc, ils n’ont rien vu venir, et deux astronautes sont particulièrement affectés : Ed Baldwin et Gordo Stevens, ceux-là même qui étaient à 15 km de la surface lunaire une peu plus d’un mois plus tôt.

Beaucoup de choses correspondent à la réalité historique dans ce premier épisode : la fusée russe est celle qui a réellement existé, même si elle n’avait été lancée qu’une seule fois à la date du 26 juin, et que ce lancement avait en réalité été un échec (qui a d’ailleurs décidé les américains à ne pas faire alunir Apollo 10). Alexeï Leonov était effectivement le cosmonaute pressenti pour marcher sur la lune, seul, car la fusée russe étant moins puissante que celle des américains, leur missions lunaire n’envoyait qu’un seul cosmonaute, et non trois astronautes. La date de la mission Apollo 10 et son déroulement sont authentiques, même si la production s’est amusée avec le nom des astronautes. En effet, même si les deux astronautes qui ont réellement approché la lune sont Stafford et Cernan, leurs doublures étaient Gordo Cooper et Ed Mitchell, et Ed Mitchell a volé sur Apollo 14, et dans la série Ed Baldwin est reparti sur Apollo 15. Le bar où les astronautes américains aimaient sortir était effectivement l’Outpost, qui a fermé en 2009. La série met au premier plan le dilemme moral d’Ed Baldwin sur sa décision de ne pas avoir poursuivi la descente, en ne faisant qu’une petite mention du caractère trop lourd de ce LM pour permettre un alunissage sans casse, mais c’est surtout ce second point qui rendait l’alunissage d’Apollo 10 impossible, en plus du roulis anormal qu’ils ont constaté lors de leur descente, et qui a déclenché le moment de la remontée.
A la fin de l’épisode, Apollo 11 fait un alunissage qui ne laisse pas le module lunaire indemne. En réalité, le module lunaire est un engin tellement fragile qu’il n’aurait jamais pu se retrouver dans l’état dans lequel on le voit. Soit il aurait été sur ses quatre pieds intacts, soit un alunissage à plus grande vitesse l’aurait fait se retourner et l’étage supérieur aurait été écrasé sous le poids de l’étage inférieur.

Beaucoup de personnages de la série on réellement existé : Neil Armstrong et Buzz Aldrin bien sûr, mais aussi John Glenn, Michael Collins, Pete Conrad, Deke Slayton qui était réellement responsable de la sélection et de l’entrainement des astronautes, suite à une interdiction de voler pour raison médicale reçu juste après son recrutement comme astronaute pour le programme Mercury, mais qui a été levée, comme dans la série, en 1972, Gene Kranz, même si il est resté directeur de vol jusqu’à la dernière mission lunaire, et vie encore au moment de l’écriture de cet article, Wernher Von Braun, qui a effectivement travaillé pour l’allemagne Nazi pendant la seconde guerre mondiale, Thomas O. Paine, administrateur de la NASA.
D’autres personnages, surtout féminins, ont été un peu modifiés afin d’avoir accès dans la série à des fonctions que seuls les hommes occupaient à l’époque. Margo Madison, protégée de Von Braun dans la série, semble faire référence à Frances Northcutt, seule femme présente dans la salle de contrôle mission de Huston, même si elle n’avait pas de relation particulière avec Von Braun. En revanche, aucune femme n’a accédé au poste de directeur des vols durant les missions lunaire. Molly Cobb est probablement la seule femme pilote dans cette série à avoir réellement existé, tout comme le programme Mercury 13. Ce programme, réalisé juste après les tests d’aptitude physique des sept premiers astronautes américains, pour le programme Mercury, a été mené à l’initiative du médecin qui a réalisé les tests médicaux des astronautes, afin de savoir si il existait aux Etats-Unis un groupe de femmes pilotes aux aptitudes physiques au moins égales à celles de ces astronautes. Treize femmes ont passé ces tests avec autant voir parfois plus de succès que leur homologues masculins. Malheureusement, l’aventure s’est arrêtée juste après, car les astronautes déjà recrutés n’étaient pas prêt à partager leurs places avec des femmes. Dans la série, Molly Cobb et Ellen Waverly sont des anciennes de Mercury 13, mais cette dernière ne semble correspondre à aucune des membres de ce programme.

Dans l’épisode 3, on peut voir un exercice de survie auquel participent le aspirantes astronautes. Ces exercices faisaient réellement partie de la formation des astronautes, car entre les situations d’urgence lors du lancement, et des problèmes lors de la rentrée atmosphérique, il était tout à fait possible que les astronautes se retrouvent dans une région hostile du globe qu’aucune équipe de récupération ne pouvait atteindre rapidement. Il aurait été alors dommage de perdre des astronautes uniquement par qu’ils ont atterri sur une zone de la planète qui n’était pas prévue. L’étrange machine volante à quatre pattes sur laquelle une astronaute se tue à la fin de l’épisode 3 était la machine sur laquelle les astronautes d’Apollo s’entraînaient à l’alunissage. Le LLTV (Lunar Landing Training Vehicle) était fait pour se comporter sur terre comme le module lunaire sur la lune. Neil Armstrong a d’ailleurs failli se tuer avec à cause d’une panne de son moteur, il doit sa vie au siège éjectable dont il était équipé.

Dans la série, le recrutement de femmes comme astronautes est déclenché par l’envoi par les russe d’une cosmonaute sur la lune. Dans la réalité, les russes ont effectivement envoyé une femme (Valentina Terechkova) dans l’espace juste après les deux premiers hommes (Gagarine et Titov), mais c’était seulement pour s’arroger une première supplémentaire. Si il a fallu attendre 1983 et la mission de Sally Ride à bord de la navette spatiale pour qu’une américaine aille dans l’espace, en 2020, seules trois cosmonautes russes ayant été dans l’espace étaient des femmes, alors que 51 astronautes américaines ont volé.

Dans l’épisode 5, ce que l’on voit des systèmes d’Apollo est relativement fidèle, comme par exemple les couchettes dans le module lunaire, qui se résumaient à des hamac pour des raisons de gain de place et de poids. En revanche, il est peu probable que la NASA ait effectivement approuvé une telle improvisation lors d’une sortie extra-véhiculaire. Descendre dans un cratère est extrêmement risqué, car un simple accro sur la combinaison pouvait entraîner une dépressurisation mortelle, et la transformation de la roue du rover lunaire en treuil aurait nécessité des outils dont ils ne disposaient pas là-haut, car la structure du pneu était riveté à la gente. De la même façon, on voit que Houston a un image retransmise en direct depuis la combinaison des astronautes. Ceci est une déformation due à notre époque, ou la capture et la diffusion d’une image vidéo ne demande qu’un matériel de petite taille consommant peu d’énergie. Ce n’était pas le cas à l’époque, et un tel équipement sur les combinaisons auraient été bien trop encombrant et consommateur en énergie. En réalité, hors de retransmission en direct pour le télévision nationale, les échanges entre les astronautes et le contrôle mission n’étaient que vocaux. Il est ainsi peu probable que dans les années 70, une base lunaire ait pu être équipée d’un système de communication vidéo pour les échanges entre les astronautes et le NASA.
On voit, à la fin de cet épisode, deux ans après la mission Apollo 15, soit en 1973, se poser sur la lune une base pilotée à distance. Ce moment est probablement le premier où l’uchronie fait un grand pas vers la fiction. Si l’opinion publique américaine avaient continué à accepter des missions lunaires, la NASA avaient des projets de séjours de plus en plus long sur la lune, mais toujours basés sur le module lunaire que l’on connaît, ou des version légèrement modifiées pour être plus hautes et de plus grande capacité. A la fin de cet épisode, on voit arriver sur la lune une base nécessairement apportée par la fusée Saturn V, puisqu’il n’est fait mention d’aucune autre fusée dans la série, mais avec une forme et une taille qui la rend incompatible avec cette fusée.

Un aspect réaliste que cette série respecte concerne les communications. Au début de l’épisode 6, lors de l’explosion de la fusée Saturn V, aucun son n’est disponible, car le centre de contrôle de Houston n’avait pas besoin d’un flux audio de la fusée, l’image suffisait. C’est pour cette raison que la catastrophe se déroule dans le plus grand silence. La réaction de la directrice de vol dans cette scène est d’ailleurs la même que lors de la catastrophe de la mission STS-107 de la navette spatiale, lorsque celle-ci a brûlé lors de sa rentrée dans l’atmosphère en 2003. Le même réalisme est valable lorsque Baldwin tombe nez à nez avec un cosmonaute russe lors d’une sortie sur la lune. Le vide spatial de portant pas le son, et russes et américains travaillant avec leur propres fréquences radio, il leur est effectivement impossible de communiquer autrement que par le langage corporel. On retrouve le même silence réaliste dans l’épisode 9 lors de l’accident alors que plusieurs astronautes sont en sortie extra-véhiculaire et que la trappe de la capsule est ouverte.

Dans cette série, le réalisme de la base lunaire de Jamestown peut être apprécier en regard de Skylab, le laboratoire spatial que la NASA a lancé après les missions Apollo, et de Saliout, l’équivalent russe. On voit dans la série que les astronautes sur la lune sont équipés d’un magnétoscope, et commencent à avoir des problèmes psychologiques entre 86 et 156 jours de séjour. Si on fait le parallèle avec les stations Skylab et Saliout, la présence d’un magnétoscope pour les divertir est très étrange, car même lors du séjour de 84 jours de Skylab 4 et celui de 175 jours sur Saliout 6, aucun divertissement de ce type n’a été nécessaire. C’était plutôt l’inverse, car le planning sur la première mission Skylab était tellement serré que les astronautes n’avaient plus assez de temps pour se reposer, si bien qu’il a dû être adapté. On est loin d’un besoin de divertissement pour tuer un trop plein de temps.

Une bizarrerie du scénario apparaît lors du premier retour d’astronautes depuis la base lunaire. Ils partent à trois depuis la lune dans ce qui semble être une version du module lunaire plus grande et sans séparation entre les étages. Puis, une fois en orbite lunaire, il passent dans un CSM (capsule et module de service) identique à celui des vrais missions Apollo. On peut alors se poser deux questions : d’où vient ce CSM? Il pourrait avoir été laissé lors du trajet aller, mais si ils ne repartent qu’à deux au lieu de trois dedans, l’astronaute restant sur la lune n’aura plus de moyen de retour. Il faut supposer qu’il a été apporté de manière automatique, car à l’épisode 10, le CSM qu’il utilisent pour venir est totalement à cours de carburant, et Baldwin en a tout de même pour repartir, sans pour autant qu’on ai vu un ravitaillement à partir du carburant produit sur la lune (grâce à l’eau qu’ils y ont trouvé). Une autre aspect étrange est le module lunaire utilisé pour faire la navette avec l’orbite lunaire. Il est plus gros que celui utilisé pour les missions précédentes, lequel correspondait au modèle authentique. Cette différence s’explique par le fait que ce module lunaire doit décoller de la lune, puis y revenir. Cela signifie qu’il doit faire décoller la masse de tout le carburant nécessaire à l’ascension, plus celui nécessaire à la descente. C’est l’inverse de l’autre module lunaire. En plus de cela, son caractère réutilisable empêche de laisser une partie à mis chemin (en orbite dans ce cas), si bien que cela ajoute à la masse à soulever, et donc à la taille globale nécessaire.

Les derniers éléments concernant le réalisme de la première saison de cette série porteront sur les deux épisodes finaux, et le trajet mouvementé vers la lune. La panne du troisième étage de la fusée Saturn V est crédible, si l’on imagine un sabotage. Le dépannage en orbite est également possible, même si le délai dans la série est très court (quelques jours alors que la procédure de dépannage de Skylab a pris deux semaines pour être mis sur pied). Ce qui est dit sur le troisième étage de la fusée est également authentique : il y a bien un anneau rempli d’instruments à cet emplacement de la fusée, avec un accès depuis l’extérieur, même si il n’est pas certain que la taille de cette accès (mois d’un mètre de large) aurait permis le passage d’un astronaute dans une combinaison telle qu’on la voit. En revanche, le déroulement du dépannage, et l’incident qui survient, sont de la pure fiction de cinéma. D’abord, sur les 6 astronautes en orbite, seulement deux restent dans les vaisseaux, et quatre effectuent des sorties extra-véhiculaires. C’est totalement inutile, deux astronautes d’Apollo 25 auraient été suffisant à l’extérieur, aucun membre d’Apollo 24 (la mission dépannée), n’avait besoin de sortir du leur capsule. Ensuite, lorsque la mise à feu du troisième étage ce produit, il faut savoir que celui-ci procure une fois et demi l’accélération de la pesanteur terrestre, et que le CSM d’Apollo 25 pèse 30 tonnes. Cela signifie que le lien qui a été tiré entre les deux vaisseaux spatiaux, et qui n’est là que pour permettre aux astronautes de le parcourir, va supporter l’équivalent de 45 tonnes de traction. C’est comme si un bateau se retrouvait pendu par ses amarres. Il n’y a aucune chance que ceux-ci soient assez solides pour résister à la traction. La seule question que l’on peut se poser est la suivante : est-ce que le lien entre les vaisseaux est assez solide pour tenir le temps de ramener le CSM percuter le troisième étage de Saturn V, dans ce cas il le transpercerait comme une feuille de papier et cela créerait une explosion de l’hydrogène et de l’oxygène liquide qu’il contient. Ou alors, romprait-t-il avant que le CSM ne touche la fusée, auquel cas tout le monde s’en sortirai indemne, mis à par le ou les astronautes encore attachés à la fusée. Pour eux, il serait totalement impossible de se détacher, car avec 1,5G d’accélération, leur propre poids ajouté à celui de leur combinaison les rendrait comme suspendus sur terre avec 250 kg accrochés au corps. Ensuite, le choix fait par Slayton et Waverly de pousuivre la mission alors que le troisième étage de Saturn V s’est allumé au mauvais moment est carrément absurde. Il est dit que leur trajectoire va les amener à 1000 miles de la lune, c’est déjà une chance considérable compte tenu de la taille de l’orbite lunaire (la zone en question ne représente que 0,2% de tous les endroits où la fusée aurait pu envoyer Apollo 24). Le principe est le même que lorsqu’on fait tourner une fronde au dessus de sa tête, si on veut atteindre sa cible, il faut la lâcher au bon moment. Avec un mauvais timing, la pierre peut partir à l’opposé de la direction souhaité. Au lieu d’arriver à 60 miles de la lune pour entrer dans son orbite, Apollo 24 arrive à 1000 miles. Dans la réalité, atteindre la lune n’aurait pas été un problème de vitesse minimum à avoir, car Saturn V aurait très certainement donnée assez de vitesse, mais de corrige la trajectoire donnée par la fusée pour ne pas passer trop loin de la lune et finir en orbite autour du soleil (ce qui a d’ailleurs été le cas des troisième étages d’Apollo 8, 10, 11 et 12). Si on suppose que tel a été le cas, et que Waverly a consommé tout le carburant du CSM pour passer suffisamment près de la lune, il est probable que le rendez-vous avec Baldwin auraient été impossible, car le module lunaire, même dans sa version modifiée, n’aurait sûrement pas eu assez de carburant pour effectuer la trajectoire nécessaire (mise en orbite lunaire, puis accélération à la même vitesse que celle du CSM venant de la terre, puis rendez-vous, puis décélération jusqu’à se poser sur la lune).

Si vous avez vu ce film de Morten Tyldum avec Benedict Cumberbatch et Keira Knightley, vous vous êtes peut-être posé la question de ce qui était historiquement juste, et de ce qui relevait de la fiction. Après m’être documenté, je pense pouvoir vous donner ici une réponse à cette question.

Contrairement à d’autre films sur la vie d’Alan Turing, comme Codebreaker, Le Modèle Tuing, ou Comment les maths ont vaincu Hitler, Imitation Game a été critiqué pour ses erreurs historiques et la caricature qu’il fait du personnage d’Alan Turing.

Pour tenter de lister des façon exhaustive les erreurs historiques d’Imitation Game, je les ai classées par catégories.

Erreurs sur les personnalités des personnages

Alan Turing est présenté comme assez peu social, à cause d’une forme d’autisme ou du syndrome d’Asperger, qui sera en réalité diagnostiqué par certains chercheurs bien après la seconde guerre mondiale. En réalité, ses collègues de l’époque le décrivent comme quelqu’un qui avait de l’humour, des amis et entretenait de bonnes relations avec eux. Dans le film, lorsque Cairncross le menace de dévoiler son homosexualité pour que Turing ne dénonce pas son activité d’espion au service de l’URSS, ce dernier décide de ne rien révéler. En réalité, l’activité d’espion de Cairncross n’a été découverte que bien plus tard, et les services de renseignement britanniques étaient tellement cloisonnés que Turing et Cairncross ne se sont sans doute jamais parlé. Enfin, cette scène suppose que Turing aurait renoncer à dénoncer un espion pour protéger le secret de son homosexualité, ce que les historiens pensent peu probable, compte tenu de la personnalité de Turing. D’ailleurs, les activités des employés de Bletchley Park étaient tellement secrètes que Turing ne les auraient jamais révélées à un inspecteur de police enquêtant sur son homosexualité. Dans le film, l’amour qu’il a pour Chritopher est réciproque, et il nie être son ami lorsqu’il apprend sa mort. En réalité, si Christopher savait être aimé de Turing il ne partageai pas ses sentiments, et Turning a ouvertement été effondré à la mort de celui-ci.

Le commandant Denniston est présenter dans le film comme un personnage obtus qui empêche Turing de progresser dans son travail. En réalité, les dirigeants de Bletchley Park, dont Denniston, avaient bien compris la valeur de Turing et de ses travaux, et oeuvraient pour lui permettre d’obtenir ce dont il avait besoin. Si Alan Turing a effectivement écrit une lettre à Churchill afin d’obtenir plus de ressources, il ne l’a pas fait seul, mais avec d’autres collègues de Bletchley Park comme Hugh Alexander.

Le film montre une complicité entre Turing et Menzies, chef du service de renseignement britannique, mais aucun document de l’époque ne laisse supposer une telle relation.

Si je personnages de Joan Clarke était effectivement la seule femme cryptanalyste de Bletchley Park, et qu’elle s’est fiancée avec Turing à la demande de ses parents à cause des conventions sociales, le reste de la relation avec Alan Turing est très probablement fictive (surpasse Turing au test de recrutement qu’elle passe le même jour que lui, Turing qui l’a fait engager comme secrétaire, travail ensemble chez la logeuse de Turing, visite lorsque Turing purge sa peine). En effet, on sait qu’ils ont été amis de 1940 jusqu’à après la fin de la guerre, mais Clarke ayant toujours été très secrète sur sa vie, il est probable que les scénaristes d’Imitation Game aient imaginés ce dont il avaient besoin pour leur récit. Enfin, Joan Clarck a été repérée dans un cours de géométrie de Cambridge par Gordon Welchman, un mathématicien de Bletchley Park dont le film ne fait aucune mention, et qui l’a recruté pour travailler sur le procédé de cryptanalyse d’Alan Turing.

Erreurs historiques

Toute la partie sur Turing et l’activité d’espion de John Cairncross est fictive, car si Cairncross a bien existé, et qu’il était effectivement un espion russe, ceci n’a été découvert que bien plus tard, et le cloisonnement des service de renseignement britanniques fait qu’il n’a probablement jamais rencontré Alan Turing.

Dans le film, la machine électromécanique s’appelle Christopher, mais en réalité elle se nommait Victory.

L’arrestation d’Alan Turing par des policiers est décrite comme ayant eu lieu en 1951, alors qu’elle a eu lieu en 1952, et que Turing n’a jamais révélé aux policiers ses activités à Bletchley Park.

Le film montre Alan Turing incapable de travailler sous l’effet du traitement hormonal, alors qu’il a produit à cette époque un travail novateur sur la mophogénèse.

Le film parle d’un suicide Turing après un an de traitement hormonal, alors que sa mort, dont la qualification de suicide fait débat, a eu lieu quatorze mois après la fin de sa période de castration chimique.

Dans le film, à la fin de la guerre, Menzies ordonne à l’équipe de détruire tout leur travail et de faire comme si rien ne s’était passé. En réalité, comme un bombardement de Bletchley Park pouvait occasionner la destruction de tout le travail de cryptanalyse, trois autres sites hébergeaient des machines électromécaniques conçues par les équipes de Bletchley Park. En 1945, plus de 200 de ces machines étaient exploitée au Royaume-Unis, et même si une partie a été détruite après le fin de la guerre, une majorité a continué à être exploité pour de la cryptanalyse.

Dans le film, Hugh Alexander lui propose une modification de sa machine afin de l’améliorer, or cette modification est en réalité une idée du mathématicien Gordon Welchman, dont le film ne fait aucune mention.

Dans le film, lorsqu’ils parviennent enfin à déchiffrer des message de l’Enigma, ils décident de ne pas le révéler afin de ne pas prendre le risque de dévoiler aux allemands l’avantage dont il bénéficient. Si la logique de cette décision est authentique, celle-ci ne s’est pas prise à Bletchley Park, mais à beaucoup plus haut niveau. Churchill était au courant de tous les progrès des cryptanalystes, et c’est à son niveau qu’il était décidé comment utiliser quelle information.

Erreurs concernant la cryptanalyse

La gageure d’un film traitant de mathématiques est de ne pas trop simplifier le problème dont il est question, sans pour autant perdre le spectateur.
Dans Imitation Game, les scénariste on fait le choix de mettre en scène un « génie de cinéma », aux idées juste assez malignes pour que le spectateur les comprennent tout en se disant qu’elles sont effectivement malignes.

La réalité de la cryptanalyse est tout autre.

L’idée de rechercher des mots que l’on pense contenu dans un message codé pour simplifier son déchiffrage date des débuts de la cryptanalyse, au neuvième siècle, et n’est absolument pas l’idée de génie qui a permis à Turing d’avancer dans son travail. En réalité, si il a eu ce que l’on peut considérer comme un éclair de génie, c’était un soir où il travaillait seul à la Hut 8, et il lui a fallu des mois, et non quelques minutes, pour le mettre en oeuvre et obtenir un résultat probant.

Imitation Game donne l’impression qu’Alan Turing a inventé la machine électromécanique qui permet de casser les codes de l’Enigma, mais cette machine a en réalité été inventé par le mathématicien polonais Marian Rejewski qui a travaillé sur l’Enigma allemande à partir de 1929, même si sa machine ne pouvait déchiffrer qu’une version commerciale et non militaire de l’Enigma.

Une autre erreur faite par Imitation Game au sujet de l’Enigma est qu’il n’en existait pas un seul type, mais plusieurs, commerciaux et militaires. Les premières version ont été complexifiées au cours du temps pour rendre leur décodage plus difficile, même si les allemands n’étaient pas au courant des progrès de cryptanalyse des britanniques. Entre les différentes armées de l’Axe se servant de l’Enigma, des négligence dans son utilisation fournissait parfois des indices permettant le décodage des messages. Contrairement à ce que l’on peut voir dans le film, à aucun moment de la guerre, les britannique n’ont connu la position de tous les sous-marins allemands. Même si, en 1945, la quasi totalité des messages allemands pouvaient être déchiffrés par les anglais, ceux destinés aux U-Boot ont toujours bénéficié de plusieurs niveaux de chiffrement qui les rendaient souvent inutilisables même déchiffrés. Par exemple, voici un message de U-Boot une fois tout le chiffrage de l’Enigma correctement retiré : « CKSA KBXO MBGV QQYY OJ ». Ce n’est pas de l’allemand, mais une suite de mots associés à des informations par l’intermédiaire d’un manuel qu’il faut connaître pour en comprendre le sens. Même en ayant ce manuel en sa possession, on obtient le message suivant : « Convoi en vue, carré BE4131, route au Sud, signé U-276 », et cette fois-ci c’est la position BE4131 qui pose problème, car elle est également codée, parfois même par une transposition communiquée à l’orale juste avant l’appareillage du sous-marin. Ainsi, malgré le travail formidable de des équipes de Bletchley Park, la lutte contre les sous-marins allemands a été gagnée grâce aux reconnaissances aéronavales, aux radars, aux écho-sondeurs ASDIC, à la localisation par radiogoniométrie, mais aussi grâce au nombre des navires engagés et à l’endurance des marins. Enfin, en fonction des modifications faites par les allemands, les progrès dans le déchiffrage ne duraient pas toujours. Par exemple, entre février et décembre 1942, les anglais sont redevenu incapables de déchiffrer les messages des Enigma M4 utilisées par les U-Boot. Il aura fallu attendre que le U559 soit capturé pour la la nature exact de la modification ainsi qu’un manuel de code permette aux cryptanalystes de décoder de nouveau les messages échangés par cette machine.

Si comme moi vous avez toujours utilisé des ordinateurs fonctionnant sous Windows, et que vous devez du jour au lendemain être productif sur un projet qui ne travail qu’en ligne de commande sous Linux, ce guide est fait pour vous.
Contrairement à ce que l’on pourrait penser, il existe de multiples façon d’être confronté à une interface Linux en ligne de commande, car beaucoup de systèmes (Smartphone Android, server d’hébergement de site web…) utilisent Linux comme base, et nécessite de passer par la console pour effectuer certaines opérations.

La console Linux est très différente de l’utilisation de Windows car ce dernier a été conçu pour n’être utilisé que via des programmes avec une interface graphique, alors que Linux, si il peut disposer d’une interface graphique aussi pratique (voir même plus) que Windows, est fait pour être 100% utilisable en mode console, en ne faisant que taper des commandes, ce qui n’est pas le cas de Windows. Je donnerai de temps en temps l’équivalent Windows des commandes dont je parlerai, et vous verrez qu’elles sont bien plus limitées.

Pour commencer, il faut ouvrir une console et se connecter sur la machine Linux sur laquelle on souhaite travailler (si ce n’est pas la machine locale, dans le cas d’un hébergement de site web par exemple). Je ne vais pas détailler cette étape car elle dépend trop de l’environnement de travail, sachez juste que sous Linux, impossible d’utiliser une machine sans s’authentifier avec un login et un mot de passe. De cette identification découlent des droits, qui sont différents en fonction des utilisateurs. Un seul utilisateur existe cependant toujours, même si la connexion sous sont nom est souvent désactivée pour des raisons de sécurité : root. Cet utilisateur est à la racine de tous les autres, ce qui signifie qu’il possède tous les droits sur la machine.

Une fois connecté sur la machine (avec PuTTY par exemple si vous accédez à un serveur web depuis Windows), vous avez l’invite de commande dont l’aspect est entièrement paramétrable (on peut y afficher la date, l’heure, le nom de l’utilisateur, de la machine…). Pour ce guide, on utilisera un simple caractère dollar:

$

L’invite de commande est affichée par un programme, un interpréteur de commande, qui peut être différent selon les systèmes (ce qui peut expliquer que ce que je décris ici ne s’appliquera pas toujours exactement à votre cas). Le plus courant est l’interpréteur de commande bash. La seule chose que va faire cet interpréteur est d’appeler les commandes (programmes) dont vous écrirez les noms, en leur donnant en entrée ce que vous décrirez dans la ligne de commande que vous taperez. Il affichera ensuite ce que la commande (programme) retournera sur ce que l’on appelle la « sortie standard ». L’une des grandes forces de Linux est que tous les programmes conçus pour lui le sont selon la même philosophie : ils prennent en entrée un flux (données mises les unes derrière les autres comme une longue liste), et retournent un flux. Un programme Windows peut prendre en entrée des clics sur des boutons, des fichiers, des sélections parmi des éléments graphiques… Cette diversité pose des problèmes de compatibilité qui rendent la réutilisation des programmes Windows très difficile. Par conception, les programmes Linux doivent avoir tout ce dont il ont besoin sur leur flux d’entrée, et ne rien demander de plus à l’utilisateur (pas d’affichage de question demandant une réponse). Si des données leur manquent, il affichent une erreur sur la « sortie d’erreur » puis s’arrêtent.
Ainsi, le premier mot tapé après l’invite de commande sera considéré comme celui d’un programme à exécuter. L’interpréteur vas rechercher ce programme, puis l’exécuter en lui donnant sur son flux d’entrée ce qui aura été écrit après sur la ligne de commande.

Comme Windows, Linux possède un système de fichier, à cette différence près que ce n’est pas le caractère « \ » qui sépare les noms des dossiers, mais le caractère « / ». De plus, il n’y a pas de lettre de lecteur sous Linux, les disques autres que celui où se trouve le système sont « montés » dans un chemin configurable. Si on insère une clé USB dans une machine Linux, il faudra peut-être « monter » cette clé sur un chemin manuellement, et dans tous les cas retrouver le chemin où cette clé a été montée, potentiellement de manière automatique. Si tel est votre besoin, je vous laisse rechercher en anglais sur internet avec le mot clé « mount », car ce guide serait bien trop long si tous les aspects tels que celui-ci devaient être traités. Par défaut, lorsqu’on se connecte à une machine Linux, on se trouve dans le répertoire « home » de l’utilisateur avec lequel on s’est connecté. Comme l’invite de commande est configurable, elle n’affiche pas comme sous Windows le chemin du répertoire courant, on utilisera donc la commande suivante (le caractère « $ » n’est pas à taper puisque c’est l’invite de commande dont on a parlé plus haut):

$ pwd

Comme sous Windows, on peut visualiser le contenu du répertoire courant avec la commande « ls » (sous Windows c’est la commande « dir »). On utilisera la même commande que sous Windows pour changer de répertoire courant : « cd » suivit du chemin sur répertoire dans lequel on souhaite aller (attention cependant à utiliser le caractère « / » en lieu et place du « \ » sous Windows). Comme sur Windows, les chemins relatifs commencent par « .. ». Comme il n’y a pas de lettre de lecteur, les chemins absolus commenceront par « / »:

$ pwd
/home/toto
$ cd ../titi
$ pwd
/home/titi
$ cd /data
$ pwd
/data

Comme toutes les commandes Linux doivent se contenter de ce qu’on leur donne sur leur flux d’entrée, beaucoup acceptent des paramètres. Pour connaître les paramètres que l’on peut donner à une commande, utiliser la commande « man » suivit du nom de la commande qui nous intéresse:

$ man pwd

Cette commande va recherche sur le système un fichier de manuel pour la commande dont on lui a donné le nom, puis elle affiche ce fichier dans toute la console, ce qui donne ceci:

PWD(1L) Manuel de l'utilisateur Linux PWD(1L)

NOM
pwd - Afficher le nom du répertoire de travail en cours.

SYNOPSIS
pwd
pwd {--help,--version}

DESCRIPTION
Cette page de manuel documente la version GNU de pwd
([NDT] pwd = Print Working Directory).

Lorsqu’on a pas l’habitude, on peut se retrouve coincé, car il n’est pas écrit comment revenir à l’invite de commande. Pour quitter le manuel et revenir à l’invite de commande, taper sur la touche « q » du clavier. Lorsqu’on est dans un manuel, la navigation se fait en partie commande l’éditeur de texte indispensable à connaître sous Linux : « vi » (prononcer ces deux lettres à l’anglaise).
Pour se déplacer dans un manuel ou un fichier ouvert par vi, utiliser les flèches ainsi que les touches Page Up et Page Down pour aller plus vite. Taper la combinaison Maj+g pour aller à la fin, et deux fois la touche « g » rapidement pour aller au tout début. Pour rechercher un mot, taper sur la touche « / » immédiatement suivi du mot à rechercher. La recherche se fait en même temps que la frappe, et une fois le mot à rechercher tapé en entier, taper sur la touche « n » pour aller à l’occurrence suivante du mot recherché, et Maj+n pour aller à la précédente. Il est également possible de recherche un mot dans les manuels de toutes les commandes disponibles sur la machine, à l’aide de la commande suivante:

man -k MotaRechercher

Maintenant que nous avons parlé de l’éditeur de texte vi, nous allons donner quelques éléments très utiles, même si cet éditeur a énormément de fonctionnalités. Contrairement à Windows, où l’on peut ouvrir un fichier texte et faire des sélections à la souris puis des copier/coller, vi ne permet pas cela, ou alors seulement dans le même fichier. On devra donc ruser pour obtenir le même résultat (copier d’abord le fichier, puis modifier la copie, et éventuellement y ajouter des lignes à la fin en provenance d’un autre fichier).
La première chose à savoir sur vi c’est qu’une fois ouvert, il répond aux touches du clavier comme étant des commandes (comme on vient de la voir pour la recherche). Si on veut modifier le fichier, il faudra d’abord exécuter la commande « insert » en tapant au clavier sur les deux caractères « : » et « i », le premier annonçant que le second est une commande. On sera alors en mode insertion, et on pourra en sortir avec la touche « Esc ». Si vous vous être trompé, et que vous voulez annuler la dernière modification, utiliser la commande « u » (en tapant « :u » depuis le mode commande, donc faire « Esc » si vous étiez en train de taper du texte dans le fichier).

Voici un résumé des commandes vi citées ci-dessus ainsi que quelques autres très utiles:

  • Ouvrir le fichier /home/toto/myfile.txt avec vi (il sera créé si il n’existe pas): « vi /home/toto/myfile.txt »
  • Modifier (insérer) du texte : « :i »
  • Quitter le mode édition : Esc
  • Rechercher la chaîne de caractères « toto » : « /toto »
  • Rechercher la prochaine occurrence de la chaîne de caractères : « n »
  • Rechercher la précédente occurrence de la chaîne de caractères : « N »
  • Aller au début du fichier : « G »
  • Aller à la fin du fichier : « gg »
  • Aller à la ligne 232 : « :232 »
  • Couper 4 lignes à partir de la ligne actuelle : « 4dd »
  • Copier 5 lignes à partir de la ligne actuelle : « 5yy »
  • Coller les lignes copiées ou coupées juste après la ligne actuelle: « p »
  • Afficher les numéros de lignes: « :set number »
  • Masquer les numéros de lignes: « :set nonumber »
  • Annuler la précédente action: « :u »
  • Quitter en enregistrant (ne pas oublier Esc si mode édition): « : x » ou « :wq »
  • Quitter sans enregistrer (ne pas oublier Esc si mode édition): « :q! »
  • Enregistrer sans quitter (ne pas oublier Esc si mode édition): « :w »

Comme on l’a déjà évoqué, l’interpréteur de commande bash va considérer chaque premier mot qu’on lui donne comme une commande (un programme), qu’il doit trouver et exécuter. Nous allons voir comment il fait cela, car si une commande ne marche pas, la cause peut venir de là.

L’interpréteur de commande est exécuté avec ce qu’on appelle un environnement, c’est un ensemble d’éléments dont il hérite de celui qui l’a démarré. Parmi ces éléments, deux sont souvent à vérifier afin de comprendre pourquoi ce que l’on tente de faire ne fonctionne pas : les variables et les alias.

Les variables sont, comme leur nom l’indique, des couples nom/valeur. L’une d’entre elle est utilisée pour rechercher les commandes appelée dans l’interpréteur, c’est la variable PATH. Cette variable contient une liste de chemins répertoires séparés par « : », c’est dans ces répertoire que l’interpréteur va rechercher les programmes dont le nom doit correspondre aux commandes qu’on lui donne. Pour afficher le contenu d’une variable, utiliser la commande « echo »:

$ echo $PATH

Pour faire la différence entre une simple chaîne de caractère et le nom d’une variable, Linux utilise le caractère « $ ». Ce qui suivra ce caractère sera considéré comme le nom d’une variable, et ce jusqu’au prochain caractère espace. Même si dans cet exemple le nom de la variable est entièrement en majuscule, ce n’est pas une obligation, mais une convention très souvent respectée.

Pour modifier le contenu d’une variable, ou en créer une nouvelle, utiliser le symbole « = »:

$ MY_PATH=/home/toto
$ echo $MY_PATH
/home/toto
$ MY_PATH=$MY_PATH:/home/titi
$ echo $MY_PATH
/home/toto:/home/titi

Dans l’exemple ci-dessus, on a concatener à la variable MY_PATH un chemin supplémentaire. Ceci est utile pour la variable PATH, si on souhaite ajouter un dossier où l’interpréteur doit rechercher des commandes. Attention cependant, les variables créées n’existent que dans l’environnement courant, si on se connecte à nouveau sur la même machine, elles ne seront plus là, car rien ne les aura créé. Pour les rendre persistantes, il faut les créer dans un fichier qui sera « sourcé » à chaque démarrage de l’interpréteur. Pour l’interpréteur bash, ce fichier s’appelle « .bashrc » (le point au début indique que c’est un fichier caché) et se trouve dans le home de l’utilisateur (on peut le créer si il n’existe pas déjà).

En plus des variables, l’environnement contient également des alias. La différence entre une variable et un alias est que l’alias n’a pas de caractère « $ » précédant sont utilisation. Il consiste en un remplacement d’une chaîne de caractère par une autre, effectué sur les commandes tapées dans l’interpréteur. Les alias servent à créer des commandes simplifiées, ou à forcer certaines options.

Par exemple, voici comment créer un alias « ll » pour la commande « ls -l », ainsi qu’un alias « rm -i » pour forcer l’option « -i » à chaque utilisation de la commande « rm »:

$ alias ll='ls -l'
$ alias rm='rm -i'

Il arrive sur certains système que la commande « rm » (supression de fichier ou répertoire) ait un alias pour forcer l’option « -i » (demande de confirmation). Une telle option peut être très gênante si on veut supprimer un répertoire ainsi que tout son contenu, c’est pour cela que l’on pourra demander à l’interpréteur de ne pas résoudre cet alias grâce au caractère d’échappement « \ »:

$ \rm /home/toto/*

On pourra aussi vérifier si l’alias « rm » existe, et le supprimer (c’est une action permanente, contrairement à l’utilisation de l’échappement):

$ alias rm
alias rm='rm -i'
$ unalias rm

Comme pour les variables, les alias devront être créé au bon endroit si on veut qu’ils soient persistants (ex: fichier « .bashrc »).

En plus de résoudre les alias, les variables et de rechercher les programmes correspondants aux commandes, l’interpréteur bash a une autre fonctionnalité très pratique, que la console Windows a fini par copier : la complétion.
Comme le commandes sont interprétée, le nombre de commandes qui ont un sens n’est pas illimité, ainsi, l’interpréteur fourni la possibilité de compléter automatiquement la commande en cours avec ce qu’il considère possible (qu’il est capable d’interpréter). Cette complétion s’obtient en tapant sur la touche Tabulation du clavier, lorsqu’on est en train d’entrer une commande. Si on le fait alors que aucune commande n’as été entrée, le nombre de possibilités sera très grand, et l’interpréteur demandera une confirmation avant d’afficher les centaines de possibilités. Si on le fait lorsqu’on a commencé à taper un chemin, par exemple « /home/toto/ », il affichera successivement, à chaque frappe de la touche Tabulation, un élément contenu dans le dossier dont on a entrée le chemin. Cette fonctionnalité fait gagner beaucoup de temps, surtout lors de la saisie des chemins de fichiers.

Dans le même ordre d’idée, l’interpréteur garde en mémoire la liste des commandes qu’on lui a fait exécuté, et cette liste peut être parcourue grâce aux flèches Haut et Bas lorsqu’on est dans la console. On peut également faire une recherche dans cette liste de commande, à l’aide des touches Ctrl+r, puis en tapant la partie de commande de l’on recherche, un nouveau Ctrl+r donnera à chaque fois l’occurrence suivante correspondante dans l’historique des commandes. Ces raccourcis permettent de gagner beaucoup de temps en évitant de retaper des commande déjà utilisé, ou de partir de celles-ci pour en saisir de légèrement différentes (lorsqu’on corrige une erreur par exemple).

On a vu que l’interpréteur recherchait les programmes correspondant aux commandes dans dossiers listés dans la variable PATH. Il existe cependant un moyen de lui demander ou se trouve le programme correspondant à une commande, avec la commande « which »:

$ which ls
/bin/ls

Une chose qui peut être assez déconcertante lorsqu’on débute sur Linux, est que certains caractères ont une signification pour l’interpréteur, et leur utilisation peut mener à un comportement auquel on ne s’attend pas, si on ignore quels caractères ont quelle signification. Un bon exemple de cela est le caractère espace. Il est utilisé comme séparateur, si bien que si jamais il apparaît dans un nom de fichier (habitude fréquente sous Windows, mais à proscrire même si cela est possible sous Linux), il faudra mettre ce nom entre guillemets et échapper l’espace pour qu’il soit correctement interprété:

vi "Mon\ fichier\ avec\ des\ espaces.txt"

De la même façon, la quasi totalité des commandes Linux travaillent en utilisant l’espace et le retour chariot comme séparateurs. C’est pour cette raison que par défaut, la commande « echo » ne peut afficher plus d’une ligne. Si on veut lui demander d’afficher plusieurs lignes (séparées par le caractère retour chariot « \n »), il faudra utiliser l’option « -e »:

$ echo "1\n2\n3"
1\n2\n3
$ echo -e "1\n2\n3"
1
2
3
$

On notera au passage que, contrairement à Windows, le retour à la ligne sous Linux n’est spécifié que par un seul caractère d’un octet « \n », alors que Windows en utilise deux : « \r\n ». Ainsi, un fichier créé sous Linux créera une erreur sous Windows, et un fichier Windows affichera des caractères supplémentaires pouvant créer des erreurs avec certains programmes sous Linux.

Il sera possible de remplacer tous les retour à la ligne Windows « \r\n » par des Linux « \n » dans le fichier windowsFile.txt avec la commande suivante:

$ sed -i 's/\r\n/\n/g' windowsFile.txt

Les caractères ayant des significations spéciales dépendent des commandes utilisées, mais il est tout de même intéressant de s’intéresser aux expressions régulières pour se familiarisé avec un concept très utile pour les opérations de recherche et de remplacement automatique de chaînes de caractères.

Prenons l’exemple de la recherche. Elle se fait sous Linux grâce à deux commandes principales : « grep » et « find ».
« grep » est pour rechercher dans le contenu des fichiers, et « find » pour rechercher sans analyser le contenu.

Voici quelques exemples:

  • Rechercher un fichier ou dossier nommé « toto.txt » à partir de l’emplcement /home/toto : find /home/toto -name toto.txt
  • Rechercher un dossier nommé « titi » à partir de l’emplcement /home/toto : find /home/toto -name titi -type d
  • Rechercher tous les fichiers ou dossiers modifiés dans les 180 dernière minutes à partir du répertoire courant : find -cmin -180
  • Rechercher tous les fichiers ou dossiers modifiés dans les 3 derniers jours à partir du répertoire courant : find -ctime -3
  • Rechercher à partir du répertoire courant tous les fichiers ou dossiers ayant l’une des extensions suivantes *.cpp, *.h : find -regex « .*\.\(cpp\|h\) »
  • Rechercher un fichier contenant le texte « toto » dans tous les fichier nommés « *.txt » à l’intérieur du répertoire /home/toto et de ses sous-répertoires (r), n’afficher que le nom des fichiers contenant le texte recherché (l) et ne pas être sensible aux majuscules et minuscules (i) : grep -rli toto /home/toto –include *.txt

La chaîne de caractères recherchée (ici : « toto ») pourra contenir une expression régulière, afin de permettre plus de finesse dans la recherche. On notera également que les expressions régulière donnant un sens à un grand nombre de caractère spéciaux, il sera nécessaire de les échapper si on souhaite rechercher ces caractères. On notera enfin avec l’exemple ci-dessus que, par défaut, les commandes Linux font le strict minimum, et qu’il faudra leur demander explicitement des choses que Windows fait par défaut (mais cela donne ainsi plus de contrôle, car on peut choisir ou non de leur demander de faire plus). Ainsi, dans l’exemple présenté de la commande « grep », on a préciser de rechercher les majuscules et les minuscules des termes spécifiés (avec l’option -i), et de regarder également dans les sous-répertoires de l’emplacement de base de la recherche (avec l’option -r).

Comme certaines commandes peuvent prendre du temps à s’exécuter, ou faire un travail qu’on ne souhaite finalement pas, il est possible d’arrêter l’exécution de la commande en cours en utilisant la combinaison de touches Ctrl+c.
Une autre combinaison de touches intéressante à connaître, afin de comprendre pourquoi plus rien de change dans l’affichage est Ctrl+s. Cette combinaison est très utile sous Windows pour sauvegarder le document ouvert, mais si on la fait dans une console Linux, elle aura pour effet de figer l’affichage, et on ne verra plus ainsi la progression de la commande en cours d’exécution. Pour libérer cet affichage, il faudra faire la combinaison de touches Ctrl+q.

Maintenant qu’on a fait le tour des éléments essentiels à connaître, voici une liste de commandes souvent utiles:

  • Créer un répertoire /home/toto/mydir (en supposant que /home/toto existe déjà) : mkdir /home/toto/mydir
  • Supprimer un fichier : rm fileToDelete.txt
  • Supprimer le répertoire /home/toto et tout son contenu sans demander de confirmation (f), à utiliser avec précaution car il n’y a pas de retour en arrière possible, ni corbeille comme sous Windows, ni opération Annuler : rm -rf /home/toto
  • Copier le fichier /home/toto/myFile.txt dans /home/titi : cp /home/toto/myFile.txt /home/titi
  • Copier le répertoire /home/toto et tout son contenu dans /home/titi (on aura alors un répertoire /home/titi/toto) : cp -r /home/toto /home/titi/
  • Déplacer le répertoire /home/toto/src dans /home/titi (on aura alors un répertoire /home/titi/src) : mv /home/toto/src /home/titi/

D’autre commandes peuvent également être utiles pour des besoins spécifiques, ou même des structures de contrôle (le langage de l’interpréteur en un langage de script, avec des boucle, des conditions…), mais comme tout cela serait très long à expliquer, et que beaucoup de documentation existe sur internet, je vais me limiter ici à vous donner une exemple de commande évoluée mettant en oeuvre plusieurs de ces éléments:

$ for i in $(grep -rl "2020-[0-9][0-9]-[0-9][0-9]" /home/toto/src);do sed -i 's/2020\(-[0-9][0-9]-[0-9][0-9]\)/2019\1/g' $i;done

La commande ci-dessus contient une boucle avec une variable i. Les valeurs de cette variable sont générées à partir d’une sous commande encapsulée dans $().
La sous commande va rechercher les noms (l) des fichiers dans le dossier et sous-dossier (r) de /home/toto/src contenant la séquence de caractères suivante : « 2020- » suivi de deux chiffre de 0 à 9, puis du caractère « -« , puis de deux chiffres de 0 à 9. Avec les valeurs prises par i (ce sont donc les noms des fichiers qui contiennent la séquence « 2020- » deux chiffre, tiret, deux chiffres), on a effectuer un remplacement (sed) de caractère à l’intérieur de ces fichiers (-i pour ne pas créer de nouveau fichier). On va remplacer la séquence « 2020- » deux chiffre, tiret, deux chiffres par « 2019- » puis le reste de la séquence d’origine (deux chiffres, tiret, deux chiffres).

Lorsqu’on vient de Windows, il est également intéressant de savoir

On va terminer ce billet en donnant des explications sur quelques caractères spéciaux de l’interpréteur dont il peut être utile de connaitre le sens:

  • Envoyer la sortie standard de la commande pwd dans le fichier toto.txt (il sera créé si il n’existe pas: pwd > toto.txt
  • Ajouter la sortie standard de la commande pwd à la fin du fichier toto.txt (il sera créé si il n’existe pas: pwd >> toto.txt
  • Exécuter la commande « gedit » et se débarrasser de la sortie standard et la sortie d’erreur (utile lorsqu’on lance une interface graphique et que l’on ne veut rien avoir qui s’affiche dans la console) : gedit &> /dev/null
  • Rechercher la chaîne « toto » sur la sortie de la commande « ls -R » (afficher le contenu d’un dossier et de tous ses sous dossiers) : ls -R | grep toto

Les exemples ci-dessous n’ont pas d’intérêt en eux-même, ils ne sont là que pour montrer l’utilisation des symboles « > », « >> », « &> » et « | » (Alt Gr + 6), lesquels peuvent être intéressants à connaître au cas où on les retrouve dans un script bash. En effet, comme le langage de l’interpréteur est un langage de script, il est possible de faire un fichier qui contiendra des commandes et sera exécuté par Linux comme un programme. Pour cela, le fichier, souvent d’extension *.sh, doit commencer par:

#!/bin/bash

Cette ligne indique à l’interpréteur que ce qui suit dans le ficher sont des lignes qui seront comprises par le programme /bin/bash. Pour rendre un tel fichier de script exécutable, il faudra modifier ses permissions avec la commande « chmod »:

$ chmod u+x myscript.sh

La commande ci-dessus demande à ajouter (+) l’autorisation d’exécution (x) pour la possesseur du fichier (u) myscript.sh. En effet, sous Linux, tous les fichiers et les répertoires ont un possesseur, et des autorisation pour lui, le groupe d’utilisateur dont il faut partie, et les autres (tous les utilisateurs hors du groupe dont il fait partie).

Pour connaitre les groupe dont on fait partie, utiliser la commande « id ».

Une dernière chose dont il est intéressant de connaître l’existence sous Linux sont les liens symboliques. On peut les comparer aux raccourcis sous Windows, même si ils sont quelque peu différents. Ce sont des fichier pointant sur un autre emplacement, et que l’on peut parcourir comme un dossier. Leur intérêt est surtout de fournir un compatibilité ascendante, car on peut ainsi créer un lien portant le nom d’une ancienne version de logiciel, et le faire pointer vers la nouvelle. On aura alors uniquement installé la nouvelle version, mais les programmes recherchant à l’emplacement de l’ancienne seront redirigés sans s’en rendre compte. Voici les principales commandes liées aux liens symboliques:

  • Créer un lien symbolique titi pointant vers /home/toto (-s pour créer et -f pour écraser un lien déjà existant) : ln -sf /home/toto titi
  • Supprimer le lien symbolique titi (il sera plus simple de supprimer/recréer plutôt que de modifier, et un rm sur un lien symbolique supprimera la cible du lien, et non le lien lui même) : unlink titi

Résumé de toutes les commandes citées dans cet article:

  • Afficher le répertoire courant : pwd
  • Afficher le contenu du répertoire courant : ls
  • Afficher le contenu du répertoire courant avec les fichiers cachées (a) et les détails (l) par ordre de date de modification (t): ls -lta
  • Changer le répertoire courant pour aller dans /home/toto : cd /home/toto
  • Ouvrir le fichier toto.txt avec l’éditeur vi : vi toto.txt
  • Afficher le manuel de la commande pwd : man pwd
  • Rehercher « toto » dans les manuels de toutes les commandes : man -k toto
  • Afficher la valeur de la variable PATH : echo $PATH
  • Créer ou mettre à jour la variable MY_PATH avec le contenu /home/titi : MY_PATH=/home/titi
  • Crée un alias ‘ll’ pour la commande ‘ls -l’ : alias ll=’ls -l’
  • Vérifier si l’alias ‘ll’ existe : alias ll
  • Supprimer l’alias ‘ll’ : unalias ll
  • Empêcher la résolution d’un éventuel alias de la commande ‘rm’ : \rm
  • Proposer la suite de la commande en cours de saisie : touche Tabulation
  • Se déplacer dans l’historique des commandes exécutées par l’interpréteur : Fléche haut, Flèche bas
  • Effectuer une recherche dans l’historique des commandes exécutées pas l’interpréteur : Ctrl+r puis saisie de la chaîne à rechercher, et Ctrl+r pour l’occurrence suivante
  • Connaitre l’emplacement du programme associé à la commande ls : which ls
  • Afficher une chaîne de caractères sur plusieurs lignes : echo -e « Ligne1\nLigne2\nLigne3 »
  • Remplacer tous les retours à la ligne Windows par des Linux dans le fichier windowsFile.txt : sed -i ‘s/\r\n/\n/g’ windowsFile.txt
  • Rechercher un fichier ou dossier nommé « toto.txt » à partir de l’emplacement /home/toto : find /home/toto -name toto.txt
  • Rechercher un dossier nommé « titi » à partir de l’emplacement /home/toto : find /home/toto -name titi -type d
  • Rechercher tous les fichiers ou dossiers modifiés dans les 180 dernière minutes à partir du répertoire courant : find -cmin -180
  • Rechercher tous les fichiers ou dossiers modifiés dans les 3 derniers jours à partir du répertoire courant : find -ctime -3
  • Rechercher à partir du répertoire courant tous les fichiers ou dossiers ayant l’une des extensions suivantes *.cpp, *.h : find -regex « .*\.\(cpp\|h\) »
  • Rechercher un fichier contenant le texte « toto » dans tous les fichier nommés « *.txt » à l’intérieur du répertoire /home/toto et de ses sous-répertoires (r), n’afficher que le nom des fichiers contenant le texte recherché (l) et ne pas être sensible aux majuscules et minuscules (i) : grep -rli toto /home/toto –include *.txt
  • Créer un répertoire /home/toto/mydir (en supposant que /home/toto existe déjà) : mkdir /home/toto/mydir
  • Supprimer un fichier : rm fileToDelete.txt
  • Supprimer le répertoire /home/toto et tout son contenu sans demander de confirmation (f), à utiliser avec précaution car il n’y a pas de retour en arrière possible, ni corbeille comme sous Windows, ni opération Annuler : rm -rf /home/toto
  • Copier le fichier /home/toto/myFile.txt dans /home/titi : cp /home/toto/myFile.txt /home/titi
  • Copier le répertoire /home/toto et tout son contenu dans /home/titi (on aura alors un répertoire /home/titi/toto) : cp -r /home/toto /home/titi/
  • Déplacer le répertoire /home/toto/src dans /home/titi (on aura alors un répertoire /home/titi/src) : mv /home/toto/src /home/titi/
  • Envoyer la sortie standard de la commande pwd dans le fichier toto.txt (il sera créé si il n’existe pas: pwd > toto.txt
  • Ajouter la sortie standard de la commande pwd à la fin du fichier toto.txt (il sera créé si il n’existe pas: pwd >> toto.txt
  • Exécuter la commande « gedit » et se débarrasser de la sortie standard et la sortie d’erreur (utile lorsqu’on lance une interface graphique et que l’on ne veut rien avoir qui s’affiche dans la console) : gedit &> /dev/null
  • Rechercher la chaîne « toto » sur la sortie de la commande « ls -R » (afficher le contenu d’un dossier et de tous ses sous dossiers) : ls -R | grep toto
  • Ajouter un droit d’exécution du fichier myscript.sh à son propriétaire : chmod u+x myscript.sh
  • Afficher les groupes d’utilisateur dont on fait partie : id
  • Afficher le nom de l’utilisateur sous lequel nous sommes connecté : whoami
  • Créer un lien symbolique titi pointant vers /home/toto (-s pour créer et -f pour écraser un lien déjà existant) : ln -sf /home/toto titi
  • Supprimer le lien symbolique titi (il sera plus simple de supprimer/recréer plutôt que de modifier, et un rm sur un lien symbolique supprimera la cible du lien, et non le lien lui même) : unlink titi
  • Quitter l’interpréteur (la console), ou se déconnecter de la machine : exit
  • Stopper l’exécution de la commande ne cours d’exécution dans l’interpréteur : Ctrl+c
  • Figer l’affichage de la console/Libérer l’affichage de la console : Ctrl+s/Ctrl+q

Après avoir vu le film inspiré de faits réels et produit par Amazon Prime : « The Aeronauts », je me suis posé la question de ce qui était historique, et de ce qui relevait de la fiction. Je vous livre ici les réponses que j’ai trouvées (attention, spoilers).

« The Aeronauts » se passe au milieu du XIXème siècle en Angleterre, et raconte l’histoire de James Glaisher, un astronome et un météorologue convaincu que les voyages en ballon permettront d’en apprendre plus sur la composition de l’atmosphère, et de faire ainsi progresser la discipline météorologique alors naissante. Pour l’aider, il faut appel à Amelia Wren, une pilote de ballon dont le mari, pilote également, est décédé.

Nous pouvons commencer par ce qui est authentique, dans la mesure ou cela représente la partie la plus courte de cet article. James Glaisher a effectivement existé à cette époque, il était astronome et météorologue, et il a effectivement battu un record d’altitude en ballon à hydrogène, pour étudier l’atmosphère dans le but de faire progresser la météorologie. Lors de cet exploit, il a perdu connaissance et doit sa vie au pilote avec qui il était. Voilà tous les éléments authentiques utilisés dans le film.

Concernant les éléments fictifs, le premier est le personnage d’Amelia Wren, qui n’a jamais existé, puisque le pilote de James Glaisher était un homme, Henry Coxwell, et que les femmes du XIXème siècle ne pouvaient pas occuper de telles fonction. Elles étaient cantonnés aux métiers liés aux enfants (institutrices, gouvernantes, nourrices…), et n’avaient pas plus de droits qu’eux. Elles passaient de l’autorité de leur père a celui de leur mari, n’avaient pas le droit de posséder un compte en banque, de voter (jusqu’en 1918 en Angleterre), et les femmes de lettres étaient obligées de se faire passer pour des hommes si elles voulaient être publiées.
Ensuite, si les ballons étaient tels qu’on peut le voir dans le film, le record d’altitude réalisé par Glaisher et Coxwell n’a pas été précédé de la traversée d’un nuage d’orage, et a culminé à 8838m, et non 11000m. Il faudra attendre 1901 pour que les docteurs Berson et Suring atteignent une telle altitude en ballon, mais en respirant de l’oxygène en bouteille à partir de 6000m, car l’exploit de Glaisher a montré la limite d’altitude supportable par un être humain sans oxygène ou système de pressurisation.
Contrairement à ce que l’on peut voir, il n’y a pas d’altitude uniquement peuplée d’insectes, car ceux-ci ne sont pas capables de voler aussi haut que les oiseaux, lesquels comptent des espèces peuvant atteindre 10 000m.
Si le vol de Glaisher et Coxwell a été épique, c’est dans une bien moindre mesure que celui du film. Glaisher a perdu connaissance, et Coxwell, qui lui aussi perdait ses moyens, a tiré la corde de la trappe du sommet du ballon avec ses dents, juste avant de perdre également connaissance. Leur record a été enregistré automatiquement par le baromètre que possédait leur ballon.
Concernant les températures, les 5°F (-15°C) dont il est question après avoir battu le record, à plus de 8000m, se présentent en réalité à seulement 3000m, car c’est un -37°C (-35°F) que l’on trouvera en réalité à cette altitude. À 11000m, on arrivera même à -55°C.
Un autre aspect qui a été exagéré pour rendre l’expérience des personnages plus spectaculaire est l’aspect du ciel et de la terre en altitude. On voit une nette courbure terrestre sur certains plan, au bas de l’image, or, même avec un objectif grand angle, une telle courbure ne serait pas visible à moins de plusieurs dizaines de kilomètres d’altitude. De la même façon, les étoiles sont visibles en plein jour alors qu’ils volent aux alentours de 8000m. En réalité, une telle observation n’est possible que deux fois plus haut, à l’altitude de croisière de l’avion Concorde, entre 16000 et 18000m.

En conclusion, ce film utilise effectivement des éléments authentiques, mais pour la grande majorité, ils se basent sur des aspects purement fictifs, afin d’augmenter le caractère dramatique des scènes.