diff --git a/readme_french.md b/readme_french.md
new file mode 100644
index 00000000000..444474c27a4
--- /dev/null
+++ b/readme_french.md
@@ -0,0 +1,269 @@
+Guide du Coffre-fort de Code GitHub
+Introduction
+
+Cet archive, le Coffre-fort de Code GitHub, a été établi par le Programme d’Archivage GitHub, dont la mission est de préserver les logiciels open source pour les générations futures. Que vous lisiez ceci dans un an ou dans mille ans, nous espérons que son contenu, et peut-être même le concept même de l’open source, vous seront utiles.
+
+Il s’agit principalement d’une archive de logiciels. Un logiciel est une série de commandes utilisées pour contrôler les actions d’un ordinateur. Un ordinateur est un appareil capable d’effectuer automatiquement des fonctions mathématiques bien plus rapidement que l’esprit humain, lui conférant des pouvoirs qui nous dépassent largement. Nos ordinateurs servent à explorer les secrets de l’univers, à connecter toute l’humanité dans un réseau omniprésent d’informations, à manipuler des signaux suffisamment rapidement pour transmettre des sons et projeter des images animées détaillées sur des écrans électriques, et à contrôler des machines puissantes dépassant de loin la capacité et la précision du travail humain.
+
+Un ordinateur sans logiciel ne peut rien faire de tout cela. Un ordinateur est une chose extraordinaire et merveilleuse, mais sans logiciel, toute sa puissance est inutile. Le but de cette archive est de vous transmettre ce que nous savons sur les logiciels.
+
+Les logiciels sont écrits sous forme de séquences complexes mais lisibles par l’humain, appelées langages de programmation, car une unité complète de logiciel est souvent appelée un programme. Ces programmes sont ensuite convertis dans le langage binaire des uns et des zéros utilisé par les ordinateurs. Ce processus est appelé compilation.
+
+Comme il est très difficile de reconstituer un logiciel compilé dans sa forme originale, aussi appelée code source, il est possible pour des personnes de garder cette forme secrète et d’en revendiquer la propriété. Le logiciel open source n’est pas un type de logiciel différent, mais une éthique différente. L’éthique open source rejette le secret et la propriété. Les logiciels open source sont mis à disposition de tous, gratuitement, afin qu’ils puissent à leur tour améliorer ces programmes ou les utiliser pour en créer de nouveaux et de meilleurs.
+
+Un projet open source est le travail collectif d’une communauté auto-organisée qui peut compter des milliers de membres. L’accumulation de tous les projets open source archivés ici est le fruit d’une communauté de plusieurs millions de personnes. Bien que certains individus puissent avoir des droits particuliers dans un projet donné, comme la capacité d’approuver ou de rejeter des modifications proposées à la dernière version officielle de son code source, personne ne le possède jamais. Chacun a le droit de prendre et d’utiliser une copie complète de n’importe quel projet open source à tout moment, sans coût ni pénalité. C’est ce qu’on appelle forker un projet.
+
+Lorsque de nombreuses personnes travaillent sur le code source en même temps, il est difficile de suivre et d’intégrer tous leurs changements. Un projet open source appelé « Git » est dédié à la résolution de ce problème. Il intègre un historique complet de toutes les modifications apportées à un projet dans une entité appelée dépôt Git. Cette archive est essentiellement une archive de tels dépôts.
+
+Cette archive a été créée par une entreprise nommée « GitHub », qui fournit un service permettant aux gens du monde entier de stocker les programmes qu’ils ont écrits, de suivre les modifications de ces programmes et de collaborer avec d’autres pour les améliorer et les étendre. GitHub offre ses services gratuitement aux développeurs de logiciels open source publics. Elle compte des dizaines de millions d’utilisateurs.
+
+Ce qui suit est une description de ce que nous pensons que vous devrez savoir et posséder pour tirer le meilleur parti de cette archive logicielle. Si vous ne comprenez pas tout, ne vous découragez pas ! Nous avons également inclus un guide pour accomplir ces exigences. Si, pour une raison quelconque, vous ne pouvez pas les accomplir vous-mêmes, alors vos descendants le pourront.
+Ce dont vous avez besoin pour utiliser l’archive
+
+En principe, tout ce dont vous avez besoin pour accéder au contenu de cette archive est une source de lumière et une sorte de loupe. Cependant, la plupart (mais pas la totalité) de ses données ont été très densément stockées sur des bobines de film sous une forme encodée et compressée. Lire, décoder et décompresser ces données nécessitera un calcul considérable. En théorie, cela pourrait être fait sans ordinateurs, mais ce serait très fastidieux et difficile.
+
+Nous supposons que vous n’avez pas besoin de nos définitions de logiciel, d’ordinateur et d’autres termes. Nous imaginons que vous avez vos propres ordinateurs, probablement bien plus avancés que les nôtres, et peut-être fondamentalement différents dans leur architecture. Une fois que vous aurez compris la vue d’ensemble et le guide ci-dessous, vous pourrez facilement accéder à toutes les données.
+
+Cependant, il est possible que vous ayez des ordinateurs inférieurs aux nôtres, voire pas d’ordinateurs du tout. Dans ce cas, nous avons préparé une bobine de données non compressée, non encodée et lisible par l’humain, que nous appelons l’Arbre Technologique (Tech Tree). L’Arbre Technologique contient des informations sur nos technologies fondamentales, nos ordinateurs et nos logiciels, dans l’espoir qu’avec le temps, vous puissiez utiliser ces connaissances pour recréer des ordinateurs capables d’utiliser les logiciels open source de cette archive.
+Ce qu’il y a à l’intérieur
+
+L’archive est si grande — environ 21 000 milliards d’octets (expliqué ci-dessous) — parce qu’elle est extrêmement inclusive et démocratique. Des millions de personnes rendent les logiciels qu’elles écrivent accessibles à tous. Cette archive inclut un instantané — c’est-à-dire une copie unique, à un moment donné — de tous les logiciels publics que les utilisateurs de GitHub développent activement. Cela signifie qu’elle comprend des millions de dépôts distincts. Nous espérons que cette approche large et démocratique intéressera les historiens du futur.
+
+Les dépôts inclus dans cette archive ont été déterminés uniquement par leur date de dernier commit, c’est-à-dire la dernière fois qu’ils ont été mis à jour, et leur nombre d’étoiles. (Les utilisateurs de GitHub peuvent tous « étoiler » des dépôts publics pour indiquer qu’ils les trouvent intéressants ou importants.) L’instantané a été lancé le 02/02/2020, c’est-à-dire le deuxième jour du mois de février de l’année 2020 du calendrier grégorien, tel que nous comptons le temps. Les dépôts inclus sont : tous les dépôts ayant eu un commit dans les 80 jours précédents ; tous les dépôts ayant au moins une étoile et un commit dans les 365 jours précédents ; et tous les dépôts ayant au moins 250 étoiles, quelle que soit leur date de dernière mise à jour.
+
+Bien sûr, tous ces dépôts n’ont pas la même importance en termes d’influence et de dépendances. L’Arbre Technologique inclut un index et une brève description des dépôts les plus significatifs de l’archive, et indique sur quelle bobine chacun peut être trouvé, afin qu’ils puissent être consultés sans avoir à parcourir tous ces millions de dépôts pour déterminer lesquels sont les plus utiles en pratique.
+Aperçu de l’archive
+
+L’archive se compose de 188 bobines de film : une « bobine guide » d’informations et de conseils lisibles par l’humain, que nous appelons l’Arbre Technologique, et 187 bobines de logiciels archivés. Chaque bobine comprend 65 000 images individuelles. Les images au début de chaque bobine, et celles de la bobine guide, incluent du texte et des images lisibles par l’humain. Toutes les autres images de film consistent en des données numériques stockées sous forme visuelle appelée codes QR.
+
+Les données numériques signifient des données stockées en format binaire, c’est-à-dire en 0 et 1, car les ordinateurs eux-mêmes sont binaires — contrôlés par des signaux électriques qui sont soit « allumés » soit « éteints », correspondant à 1 ou 0 — et donc les données binaires sont beaucoup plus faciles à comprendre pour les ordinateurs que tout autre format.
+
+Les métadonnées lisibles par l’humain stockées au début de chaque bobine incluent des informations sur le film lui-même, un guide de l’encodage QR utilisé, un programme pour le décoder, et un index. L’index liste le titre, le numéro de la première image et la somme de contrôle de chaque fichier stocké sur cette bobine.
+
+Un fichier est une entité de données cohérente unique. Une somme de contrôle est une valeur unique issue d’un calcul, appelé fonction de hachage, effectué sur l’ensemble du contenu d’un fichier pour s’assurer que son contenu n’a pas été endommagé ou corrompu ; la fonction de hachage utilisée dans l’archive est appelée « SHA-1 ».
+
+Chaque code QR consiste en un champ de minuscules carrés blancs ou noirs qui occupent presque toute l’image du film. Nous utilisons les codes QR car ils sont beaucoup plus compacts et robustes que le texte lisible par l’humain. Un code QR se décode en données binaires, c’est-à-dire une série de uns et de zéros.
+
+Ce décodage n’est que la première étape pour transformer ces données binaires en informations significatives. Ce sont des données compressées, c’est-à-dire qu’elles ont été compactées pour gagner de la place, un peu comme on écrirait « 128xA » au lieu d’écrire la lettre A 128 fois. Après décodage, elles doivent être décompressées.
+
+Le résultat après décompression est appelé un fichier archive : un fichier unique contenant tout le contenu du dépôt d’un projet logiciel. La plupart des dépôts incluent de nombreux fichiers, donc ce fichier archive est comme un livre contenant de nombreux chapitres séparés, ou une boîte contenant de nombreuses autres boîtes. Il est généralement avantageux, mais pas absolument nécessaire, de décompresser le fichier archive en ses fichiers composants avant de les consulter.
+
+Enfin, chaque fichier composant est son propre ensemble de données binaires, c’est-à-dire des uns et des zéros. On peut donner un sens à ces données si l’on connaît leur format. Par exemple, dans le format appelé « UTF-8 », le plus courant dans l’archive, les uns et les zéros sont divisés en groupes de huit, appelés octets ; l’octet 01000001 représente la lettre A ; les trois octets 01101001 01101110 01110100 représentent le mot int ; et les deux octets 11000011 10000011 représentent la lettre à (A avec un accent tilde).
+
+Ce processus d’archivage des données — fichiers binaires regroupés dans des fichiers archive, d’abord compressés puis encodés en QR — est évidemment complexe comparé à l’écriture de texte lisible par l’humain. Le processus de désarchivage que vous devrez suivre — QR vers binaire compressé ; compressé vers décompressé ; fichier archive vers plusieurs fichiers ; fichiers texte vers texte lisible par l’humain — est tout aussi complexe. Mais cette complexité nous permet de stocker beaucoup plus de données qu’il ne serait autrement possible, de manière relativement facile à lire par ordinateur.
+
+Si cette complexité vous semble difficile et coûteuse, nous nous en excusons, mais nous pensons que, dans ce cas, ce guide et l’Arbre Technologique lisible par l’humain allégeront cette complexité, et seront peut-être plus utiles que le contenu de l’archive, du moins jusqu’à ce que vos ordinateurs soient suffisamment avancés pour que la complexité des données de l’archive soit facile à gérer.
+Fichiers, répertoires, dépôts et formats de données
+
+Il peut être instructif d’expliquer comment l’archive est divisée logiquement. En particulier, une discussion sur les fichiers, les répertoires et les formats de données peut être utile.
+
+Un fichier est un ensemble de données regroupées en une entité cohérente portant un nom unique : imaginez les données comme du sable, et un fichier comme un sac qui ne peut contenir que du sable. Un répertoire est un ensemble de fichiers : imaginez-le comme un sac qui ne peut contenir que d’autres sacs. Selon cette métaphore, chaque dépôt consiste en un répertoire externe, appelé répertoire racine, qui contient un certain nombre de fichiers et/ou de répertoires. Chaque répertoire peut à son tour contenir à la fois des fichiers et des répertoires.
+
+Cette structure est préférée car des fichiers organisés en groupes sont beaucoup plus faciles à manipuler qu’une collection unique de fichiers. L’identifiant d’un fichier particulier dans le répertoire externe consiste en les noms de tous ses répertoires englobants, en commençant par la racine, suivis de son propre nom, avec un caractère / entre chaque nom. Par exemple, un fichier nommé README.md dans la racine serait identifié comme /README.md et un fichier identifié comme /public/www/index.html serait le fichier index.html dans le répertoire ‘www’ à l’intérieur du répertoire ‘public’ à l’intérieur de la racine.
+
+Chaque dépôt a à son tour deux noms, séparés par un séparateur, qui dans l’archive est un caractère _ ou souligné. (Historiquement, c’était un / ou slash, mais cela sert aussi à indiquer un répertoire, donc nous utilisons _ pour plus de clarté.) Le premier nom est le compte GitHub qui possède ce dépôt ; le second est le nom du dépôt individuel. La combinaison des identifiants de dépôt et de fichier peut être utilisée pour identifier de manière unique un fichier individuel dans l’archive. Par exemple, le fichier ‘package.json’ dans le répertoire ‘web’ du dépôt ‘ykarma’ du compte GitHub ‘rezendi’ pourrait être identifié de manière unique comme /web/package.json dans rezendi_ykarma dans l’archive.
+
+Différents types de fichiers ont des objectifs différents. L’archive GitHub se compose principalement de fichiers texte, c’est-à-dire de fichiers dont les données sont destinées à représenter une langue écrite. La plupart des logiciels sont écrits dans des fichiers texte contenant du texte hautement structuré appelé code source. Un programme spécial appelé compilateur convertit ce code source lisible par l’humain en instructions lisibles par l’ordinateur, appelées code compilé ou code machine.
+
+Les fichiers qui ne sont pas des fichiers texte, comme ceux qui représentent des images ou contiennent du code compilé, sont souvent appelés fichiers binaires. Ce terme est malheureusement trompeur, car les fichiers texte sont eux aussi finalement des 1 et des 0. Nous appellerons fichiers non texte ceux qui ne sont pas des fichiers texte.
+
+Il existe de nombreuses façons de représenter une langue écrite à l’aide de 1 et de 0. Pour des raisons historiques, la plupart du code source était à l’origine écrit dans ce qu’on appelle l’alphabet latin. L’alphabet latin a 26 caractères de base utilisés pour représenter des mots prononçables, chacun ayant deux formes, majuscule et minuscule. Il a aussi 10 chiffres pour représenter les nombres. L’alphabet latin, ainsi que divers autres symboles associés utilisés pour indiquer la structure et d’autres concepts, est encodé en 1 et 0 dans un format appelé ‘ASCII’, qui peut représenter 128 caractères différents et, pour des raisons historiques, a dominé la plupart des logiciels pendant de nombreuses années.
+
+Cependant, l’alphabet latin n’est qu’une infime partie des nombreuses façons dont les humains s’expriment par écrit. Pour prendre en charge d’autres écritures, tout en permettant à tous les logiciels écrits en ASCII de continuer à fonctionner sans modification (concept appelé rétrocompatibilité), un autre format de données appelé ‘UTF-8’ a été introduit.
+
+ASCII reste le format le plus courant pour le code source. Chaque bobine de cette archive comprend un guide des caractères ASCII. ASCII est un sous-ensemble d’UTF-8, c’est-à-dire que tous les encodages ASCII sont aussi des encodages UTF-8. La bobine guide contient en plus une spécification de tous les caractères UTF-8. Presque tous les fichiers texte de cette archive devraient être encodés en UTF-8.
+
+Les fichiers non texte incluent les fichiers destinés à représenter des images et des documents formatés. Une convention largement utilisée veut que les noms de fichiers se terminent par un point suivi d’un suffixe indiquant le type de fichier. Par exemple, un nom de fichier se terminant par .jpg est probablement un fichier image JPEG ; un nom se terminant par .PNG est probablement un fichier Portable Network Graphic ; et un nom se terminant par .pdf un fichier Portable Document Format.
+
+Il n’existe pas de suffixe unique indiquant les fichiers texte. Pour le code source, le suffixe indique plutôt dans quel langage de programmation ou de balisage le code est écrit. Les langages de programmation et de balisage seront décrits plus en détail ci-dessous.
+Comment extraire le contenu de l’archive
+
+Voici un aperçu de la façon de décompresser un dépôt archivé en ses différents fichiers constitutifs. Ce processus consiste à :
+
+    Identifier la bobine et les images spécifiques sur lesquelles les données du dépôt sont archivées.
+
+    Décoder à partir des codes QR, les champs de pixels noirs, blancs et gris sur ces images, en un fichier binaire, une séquence d’au moins des milliers, souvent des millions, de 1 et de 0.
+
+    Décompresser le fichier binaire en un fichier archive non compressé plus long.
+
+    Décompresser le fichier archive en ses sous-fichiers séparés. Notez cependant que les données d’archive sont généralement compréhensibles, bien que désordonnées, même si cette étape est omise.
+
+    Enfin, convertir chacun de ces sous-fichiers — eux-mêmes des séquences de 1 et de 0, de longueur variable — en caractères écrits, s’il s’agit de fichiers texte.
+
+Identifier la bobine et les images spécifiques sur lesquelles les données du dépôt sont archivées
+
+Chaque bobine de film commence par un leader de film vierge, puis le Cadre de Référence Zéro, qui consiste en un rectangle noir solide dans un coin d’une image par ailleurs vide. L’image lisible suivante est le Cadre de Contrôle, avec des informations sur la bobine. Ensuite vient la Table des Matières, qui inclut une liste de Fichiers de Données Utilisateur.
+
+Chaque dépôt sur cette bobine est l’un de ces Fichiers de Données Utilisateur. La liste inclut un identifiant unique, un identifiant de fichier et un nom pour chacun de ces fichiers. Par exemple, le dépôt CPython du compte Python pourrait avoir l’identifiant de fichier 12345, et le nom python_cpython.tar.
+
+Après la liste des Fichiers de Données Utilisateur vient une liste d’Emplacements de Données Numériques. Cette liste inclut l’identifiant de fichier, une image de début, un octet de début, une image de fin et un octet de fin. Ainsi, dans l’exemple hypothétique de CPython, l’élément de cette liste avec l’ID 12345 pourrait avoir une image de début 054321, un octet de début 03210321, une image de fin 054545 et un octet de fin 12321232.
+
+Cela signifie, pour obtenir les données de CPython : allez à l’image 54321 de cette bobine de film. Décodez toutes les images de l’image de début, 54321, à l’image de fin, 54545, en valeurs binaires, selon les moyens décrits ci-dessous. Cela vous donnera 225 morceaux de données numérotés de 54321 à 54545, qui commenceront par un ensemble de morceaux vides sans données. Ignorez les 3210320 premiers octets du premier morceau non vide. Ajoutez tous les « morceaux du milieu », dans l’ordre. Enfin, ajoutez les 12321232 premiers octets du dernier morceau de données, 54545. Vous avez maintenant assemblé le dépôt CPython complet, sous forme d’un fichier archive compressé unique.
+Décoder à partir des codes QR en un fichier binaire
+
+Les détails sur la façon de décoder les images de film en données binaires se trouvent dans les Informations de Représentation lisibles par l’humain, qui se trouvent après la Table des Matières au début de chaque bobine de film de l’archive. Ces informations se trouvent sur chaque bobine afin que, même si une bobine est séparée de l’archive, il soit toujours possible d’en déchiffrer le contenu. Ces Informations de Représentation incluent, dans l’ordre :
+
+    Un Guide du Programme d’Archivage GitHub (ce document)
+
+    Index descriptif GitHub, une liste et une brève description de tous les dépôts sur cette bobine
+
+    Description des Informations de Représentation
+
+    Préservation numérique et comment récupérer les données, un aperçu des détails de récupération des données
+
+    Description du support de stockage
+
+    Technologie de récupération des données
+
+    Structure générique de la bobine de préservation (format de la bobine)
+
+    Description du format d’image 4K générique
+
+    Description de la bibliothèque Unboxing (pour les codes QR)
+
+    Code source de la bibliothèque Unboxing
+
+    Spécification du format de données ASCII
+
+    Spécification du langage de programmation C
+
+    Code source du fichier archive TAR
+
+    Code source PDF
+
+    Spécification du format de fichier XZ (pour la compression/décompression, voir ci-dessous)
+
+Le sixième de ces éléments, le document sur la Technologie de Récupération des Données, décrit les exigences et processus pour utiliser un scanner afin de capturer les données sur une image de film encodée numériquement et de les transformer en une forme exploitable par ordinateur. Le huitième, la description du format d’image 4K générique, fournit les informations techniques, y compris le code source, nécessaires pour qu’un ordinateur transforme une telle image scannée en données binaires.
+
+Il est théoriquement possible, en principe, de convertir un dépôt à partir de données encodées en QR vers des données binaires sans utiliser d’ordinateur. Cependant, ce serait extrêmement difficile et nécessiterait probablement un effort considérable d’une communauté bien organisée sur plusieurs semaines, voire mois ou années. Puisque le contenu des dépôts est destiné à être exécuté sur un ordinateur, leur utilisation en l’absence d’ordinateur serait au mieux minimale.
+
+Si les héritiers de cette archive n’ont pas d’ordinateurs, ils devraient conserver l’archive entière et en sécurité jusqu’à ce qu’ils en aient. Un des objectifs de l’Arbre Technologique lisible par l’humain est d’accélérer le développement des technologies et des ordinateurs en cas de cette éventualité. (Son autre objectif est de codifier notre technologie et son développement pour les historiens du futur.)
+Décompresser le fichier archive en ses sous-fichiers séparés
+
+Le fichier binaire de chaque dépôt est dans un format appelé TAR, pour Tape Archive. Un fichier TAR est essentiellement composé en regroupant plusieurs fichiers en reliant la fin de l’un au début du suivant, comme si on collait des feuilles de papier ensemble pour en faire un seul rouleau. Un fichier TAR peut inclure n’importe quel nombre de fichiers, de toute taille, répartis en n’importe quel nombre de répertoires et sous-répertoires.
+
+Chaque sous-fichier dans un fichier TAR est précédé d’un en-tête de 512 octets, qui agit comme le ruban dans la métaphore du rouleau. Cet en-tête contient des informations sur le fichier, comme son nom et sa taille. La fin de l’archive est indiquée par au moins deux blocs consécutifs de 512 octets.
+
+Parce que les fichiers TAR sont essentiellement des collections de fichiers avec des enregistrements texte entre eux, si un fichier TAR ne contient que des fichiers texte, il peut être traité comme un fichier texte lui-même. S’il contient un mélange, il peut être traité comme un fichier texte contenant un mélange de texte structuré et significatif (les fichiers texte constitutifs) et de charabia incompréhensible (les fichiers non texte constitutifs).
+
+Il est possible d’imbriquer des fichiers TAR dans d’autres fichiers TAR, un conteneur à l’intérieur d’un autre, et c’est ainsi que la plupart de nos données archivées sont stockées. Pour un dépôt donné, le fichier TAR externe contiendra au moins :
+
+    un fichier de métadonnées non compressé appelé META, qui inclut le nom du dépôt, le nom du compte, la description, le langage, le nombre d’étoiles et de forks
+
+    un fichier compressé (voir ci-dessous) nommé COMMITS, qui inclut le journal des modifications apportées au dépôt au fil du temps
+
+    un fichier nommé repo.tar.xz, un fichier TAR compressé contenant le contenu réel du dépôt
+
+D’autres métadonnées, telles que les wikis, gh-pages, issues et pull requests, peuvent également être incluses sous forme de fichiers compressés séparés.
+
+Les détails spécifiques des fichiers TAR, et les logiciels pour les encoder et les décoder, se trouvent dans les Informations de Représentation sur chaque bobine de l’archive.
+Décompresser les fichiers compressés en fichiers lisibles
+
+Pour inclure autant de dépôts et de données que possible, la plupart des données ont été compressées. La compression consiste à utiliser une petite quantité de données pour représenter une plus grande quantité, en exploitant les motifs et répétitions dans cette dernière. Par exemple, au lieu d’écrire le caractère a neuf fois de suite, on pourrait simplement écrire le texte compressé 9a, si l’on est sûr que le lecteur comprendra que 9a signifie le texte décompressé aaaaaaaaa.
+
+Les algorithmes de compression efficaces sont bien plus complexes que cela, mais le principe est le même. Cette archive utilise un programme de compression appelé « XZ », qui utilise à son tour un algorithme appelé « LZMA ». Le deuxième fichier de données sur chaque bobine contient le code source et la documentation de XZ dans un fichier TAR non compressé unique (le premier fichier de données contient la Déclaration universelle des droits de l’homme dans toutes les langues écrites disponibles).
+
+LZMA combine ce qu’on appelle un algorithme « LZ77 » et le « range encoding ». LZ77 remplace les données répétées par des références à des apparitions précédentes de ces données. Pour simplifier, si une phrase de 80 octets apparaît deux fois, à 400 octets d’intervalle, la deuxième fois, l’algorithme compacte les données en disant « répéter 80 octets à partir de 400 octets plus tôt ». Le range encoding convertit essentiellement un message entier en un seul très long nombre, qui peut à son tour être encodé.
+
+Les étapes spécifiques de l’algorithme à utiliser pour décompresser les données sont décrites par le code source XZ contenu dans le deuxième fichier de données de chaque bobine. Bien qu’il soit théoriquement possible de décompresser à la main, ce serait là encore un processus extraordinairement long et laborieux. En pratique, un ordinateur fonctionnel sera nécessaire.
+Convertir chaque fichier individuel en caractères écrits
+
+L’humanité a utilisé de nombreux caractères écrits au fil des millénaires. L’encodage utilisé pour représenter ces caractères en 1 et 0 dans cette archive est appelé « UTF-8 ». Un seul caractère UTF-8, c’est-à-dire un symbole écrit, peut occuper de 1 à 4 octets de données binaires.
+
+Pour des raisons historiques, parce qu’ils étaient les plus utilisés à l’époque et dans la région où le développement logiciel a commencé, un groupe de caractères (et de concepts) appelé « ASCII » est encodé de la manière la plus efficace, à 1 octet par caractère. Tout ce qui n’est pas ASCII est encodé sur 2 octets ou plus par caractère. La plupart des fichiers texte de cette archive sont en ASCII, mais un nombre important ne le sont pas. Beaucoup d’autres seront principalement en ASCII avec des caractères non ASCII occasionnels.
+
+Les spécifications détaillées d’ASCII se trouvent dans les Informations de Représentation sur chaque bobine de l’archive. Les spécifications détaillées d’UTF-8 se trouvent dans la bobine guide. Le premier fichier de données sur chaque bobine de l’archive contient le texte de la Déclaration universelle des droits de l’homme dans toutes les langues écrites disponibles. Cela servira à la fois d’outil de traduction et d’exemple d’ASCII et d’UTF-8.
+Types de fichiers
+
+Il existe de nombreux types de fichiers texte, créés pour différentes raisons. Le type principal ici, la raison d’être de cette archive, est le code source. Le code source est un texte très dense et extrêmement structuré, dans lequel des symboles comme « { » et « ; » ont une grande importance.
+
+L’essentiel à propos du code source est qu’il est écrit pour être lu par des compilateurs. Puisque les compilateurs sont des logiciels, on peut aussi dire que le code source est écrit pour être lu par des ordinateurs. Un bon code est aussi écrit pour que d’autres humains, s’ils sont compétents et formés dans le domaine du logiciel, puissent le comprendre ; mais il n’est correct que si un compilateur peut le comprendre.
+
+Ce compilateur, à son tour, via des séquences complexes décrites dans l’Arbre Technologique, convertira le code source en séquences de uns et de zéros qui feront que l’ordinateur exécutera les fonctions et activités décrites par le code. Pour prendre un exemple très simple, la ligne de code
+
+text
+for (int i=0; i<5; i++) { }
+
+sera convertie par le compilateur en une série d’instructions binaires envoyées à l’ordinateur, qui feront qu’une petite partie de l’ordinateur, appelée registre, fixera sa valeur à 0, puis l’incrémentera à 1, 2, 3, puis 4. (Ce n’est pas un exemple de code utile ; c’est juste une illustration du processus à plusieurs niveaux de transformation du code source en logiciel fonctionnel.)
+
+D’autres types de fichiers texte, comme JSON, XML et HTML, servent à stocker des données (plutôt que des commandes) pour les ordinateurs. Ils sont généralement aussi lisibles par l’humain, bien que leurs formats structurés les rendent plus difficiles à lire que du texte moins structuré comme ce fichier.
+
+La plupart des autres types de fichiers texte sont destinés à être lus un jour par des humains. Certains sont simples, principalement non structurés, comme ce fichier que vous lisez actuellement. Un type que vous rencontrerez souvent dans l’archive est le Markdown, signalé par l’extension .md, qui est une sorte de forme intermédiaire destinée à être lisible par l’humain dans sa forme brute et, en même temps, structurée pour que les ordinateurs puissent la formater en présentations plus attrayantes et utiles. La plupart des dépôts de cette archive ont un fichier README.md en Markdown, généralement destiné à présenter le dépôt, à expliquer pourquoi il existe et comment l’utiliser.
+
+Un bref aperçu des formes les plus courantes de fichiers non texte peut aussi être utile. Le code compilé est non texte. Les fichiers JPG et PNG encodent des images en format numérique, et MP3 et WAV encodent de l’audio. Les fichiers PDF encodent des documents avec une mise en page précise et parfaite. Et les fichiers ZIP et TAR, comme mentionné plus haut, sont des fichiers conteneurs qui peuvent inclure un ou plusieurs autres fichiers.
+Langues humaines et langages de programmation
+Langues humaines
+
+Il existe des milliers de langues écrites utilisées aujourd’hui par l’humanité, et encore plus de langues parlées. La plupart ne sont utilisées que par des populations relativement petites, mais il y a au moins vingt langues utilisées comme première ou deuxième langue par au moins 60 millions de personnes.
+
+Les langues les plus utilisées dans le monde sont l’anglais et le chinois. Pour des raisons historiques, pendant de nombreuses années, la plupart du développement logiciel a eu lieu dans des pays anglophones, si bien que, pendant un temps, l’anglais est devenu la langue par défaut des logiciels. La plupart des langages de programmation utilisent des mots anglais dans leur syntaxe. C’est la langue dans laquelle ce guide de l’archive a d’abord été rédigé.
+
+Il n’est pas garanti que les héritiers de cette archive connaissent l’anglais, bien que cela semble une langue particulièrement susceptible de durer indéfiniment. Pour aider à d’autres langues, nous incluons les plus de 500 traductions disponibles de la Déclaration universelle des droits de l’homme sous forme de fichier UTF-8 non compressé au début de chaque bobine, et aussi dans l’Arbre Technologique. Cette déclaration est une liste des droits et libertés de chaque être humain de notre époque, qui ne doivent jamais être retirés.
+Langages de programmation
+
+Les langages de programmation sont ceux utilisés par les humains pour communiquer des instructions aux ordinateurs. Ce sont les langues dans lesquelles les logiciels sont exprimés. D’autres humains (formés) doivent aussi pouvoir lire les logiciels écrits dans ces langages, mais c’est un objectif secondaire.
+
+Un langage de programmation est un ensemble d’éléments prédéfinis, dont la plupart sont des mots, qui peuvent être arrangés de manière structurée pour ordonner à un ordinateur d’effectuer l’action spécifiée de la manière spécifiée. Un ensemble de telles instructions est appelé un programme, ou code source. Le code source est essentiellement un logiciel sous forme écrite figée.
+
+Les programmes sont généralement divisés en étapes distinctes, appelées instructions, qui sont à leur tour regroupées en ensembles appelés fonctions. Un programme entier peut être contenu dans un seul fichier, ou réparti sur des milliers.
+
+Il existe des centaines de langages de programmation différents, répartis sur de nombreuses formes, approches et philosophies. Certains sont compilés en fichiers binaires séparés, qui sont ensuite exécutés ; d’autres, appelés langages « interprétés », sont effectivement compilés et exécutés en une seule fois, sans étape intermédiaire. La plupart des langages modernes incluent des bibliothèques de fonctions pré-écrites, et ces bibliothèques peuvent être très volumineuses et élaborées. Parmi les langages de programmation les plus populaires aujourd’hui, on trouve :
+
+    C, l’un des plus anciens, rapides, universels et puissants, simple à certains égards mais assez limité à d’autres, et pas toujours intuitif, facile à lire ou à apprendre.
+
+    C++, une évolution plus complexe, abstraite et puissante de C.
+
+    C#, une évolution supplémentaire compilée non pas en code machine binaire mais en un « runtime » interprété.
+
+    Java, similaire à (mais antérieur à) C#, est peut-être le langage le plus utilisé aujourd’hui.
+
+    JavaScript, très différent de Java malgré la similarité du nom, aussi appelé « ECMAScript », est un langage initialement utilisé uniquement dans un navigateur web, c’est-à-dire un programme qui récupère, interprète et affiche des données d’un serveur distant ; aujourd’hui, il est aussi largement utilisé sur ces serveurs.
+
+    TypeScript, une forme de JavaScript avec des règles plus strictes pour que les erreurs, aussi appelées bugs, soient moins susceptibles de se retrouver dans les programmes.
+
+    Python, un langage élégant populaire chez les scientifiques, à la fois puissant et un bon premier langage.
+
+    Ruby, un langage intuitif dont les instructions ressemblent souvent à de l’anglais écrit.
+
+    Go, un langage simple et puissant qui excelle particulièrement dans les programmes parallélisés, c’est-à-dire écrits pour que plusieurs fonctions s’exécutent indépendamment en même temps.
+
+    Swift, un nouveau langage utilisé pour écrire pour les téléphones et autres appareils utilisés par un milliard de personnes.
+
+    Rust, conçu pour remplacer C, rendant les bugs dangereux beaucoup moins probables.
+
+    PHP, un langage simple utilisé pour les serveurs Internet.
+
+    Lisp, un très vieux langage avec une approche fondamentalement différente, axée sur les fonctions.
+
+    SQL, un langage très différent utilisé pour extraire des données de bases de données structurées et très efficaces.
+
+    Assembleur (ou assembly), une famille de langages très cryptiques, limités, mais rapides et puissants, dans lesquels il existe une relation directe entre les constructions du langage et le code machine de l’ordinateur en question ; il peut être considéré comme du code à moitié compilé.
+
+Développement, dépendances et open source
+Développement
+
+Le processus qui consiste à prendre un simple fichier de code source et à le convertir en impulsions électriques dans un ordinateur est extrêmement complexe. Nous gérons cette complexité à l’aide de couches d’abstraction. Une abstraction appelée jeu d’instructions permet au code machine produit par un compilateur d’être utilisé sur de nombreux types d’ordinateurs. Un auteur de code source n’a généralement pas besoin de savoir ou de se soucier du type d’ordinateur, ou même du jeu d’instructions, qui sera utilisé pour exécuter ce code ; cela est géré par le compilateur.
+
+Le logiciel moderne est, à son tour, bien plus complexe qu’un seul auteur travaillant sur un seul programme pour un seul ordinateur. Il consiste en de nombreux auteurs travaillant sur de nombreux fichiers au sein d’un même projet, simultanément, souvent en utilisant plusieurs langages de programmation. De plus, chaque projet dépend d’autres projets séparés et autonomes comme outils et/ou composants, tandis que ces projets sont eux-mêmes activement développés, et dépendent à leur tour d’autres projets. Faire fonctionner ensemble tous ces éléments de manière élégante et efficace est le défi du développement logiciel moderne.
+
+Lorsque plusieurs auteurs de code source, aussi appelés développeurs, travaillent sur un même projet, chacun a son propre ordinateur et une copie complète du projet sur son ordinateur. S’ils font chacun des modifications, ils ont alors des versions différentes du même projet. Le processus de réconciliation de plusieurs versions d’un projet s’appelle le contrôle de version. Il est géré par un logiciel de contrôle de version ; dans cette archive, par un logiciel appelé Git, duquel GitHub tire son nom. Chaque dépôt de cette archive est un dépôt Git.
+
+Git peut fusionner automatiquement différentes versions d’un logiciel en une forme cohérente avec une intervention humaine minimale. Git conserve également un historique complet qui permet de revenir à une version précédente si nécessaire. Cependant, pour économiser de l’espace, les dépôts de cette archive n’incluent généralement pas les historiques Git.
+
+Lorsque plusieurs développeurs prennent un projet sur plusieurs chemins différents simultanément, cela s’appelle créer des branches, et ces chemins sont appelés branches. La branche principale d’un projet est appelée tronc, ou branche master. Git offre une fonctionnalité permettant aux développeurs de résumer les différences entre deux branches et de proposer de fusionner la leur dans celle de l’autre. C’est ce qu’on appelle une pull request. Le développement logiciel moderne consiste en grande partie à créer une branche, à écrire ou modifier le logiciel sur votre branche, puis, une fois terminé, à soumettre une pull request pour que votre travail soit réintégré dans la branche principale.
+Dépendances
+
+Pratiquement tous les langages de programmation permettent de s’appuyer sur le travail des autres. Sans réutilisation du travail d’autrui, chaque projet serait énormément plus difficile, bien plus lent, et très peu de projets verraient jamais une utilisation réelle dans le monde.
+
+Si le projet A doit inclure le projet B pour fonctionner, alors A dépend de B, et B est une dépendance de A. A peut avoir de nombreuses dépendances, chacune pouvant avoir ses propres dépendances, et ainsi de suite. De plus, chaque dépendance concerne une version particulière, ou une plage de versions, d’un projet donné. L’énumération complète de toutes les couches de dépendances d’un projet s’appelle son arbre de dépendances.
+
+En général, les dépendances sont énumérées dans les fichiers de code source, généralement en haut, et chaque fois que le compilateur ou l’interpréteur trouve une dépendance, il la recherche dans un ensemble de répertoires prédéfinis. Parce que l’arbre de dépendances d’un projet peut être très complexe, il est parfois énuméré en entier dans un seul fichier du projet appelé liste de paquets. Par exemple, les projets Ruby peuvent avoir un Gemfile à cet effet, et les projets JavaScript peuvent avoir un fichier package.json. Cela permet à un outil appelé gestionnaire de paquets de récupérer toutes les dépendances d’un projet en une seule fois, à partir d’un ou plusieurs serveurs Internet.
+
+Dans le cas de cette archive, il est probable que les dépendances de tout projet donné existent ailleurs dans l’archive. Pour trouver une dépendance dans l’archive, il faut d’abord découvrir le nom de la dépendance dans le code source ou la liste de paquets, dont les détails varient selon le langage et le framework, puis utiliser l’index principal dans la bobine guide, ou, à défaut, les index au début de chaque bobine, pour déterminer sur quelle bobine et quelles images se trouve le dépôt en question.
+Open source
+
+Comme l’exécution d’un programme sur un ordinateur ne nécessite que le code machine compilé, il est possible de distribuer cela tout en gardant le code source secret. C’est ce qu’on appelle le modèle propriétaire. Aux tout débuts de l’informatique, le code source était généralement distribué avec le code machine, mais par la suite, à mesure que le logiciel est devenu une industrie lucrative, le modèle propriétaire est devenu plus courant.
+
+On a depuis appris que rendre le code source public, pour que quiconque puisse le copier, le brancher et l’améliorer, est une approche bien plus efficace du développement logiciel. Plus il y a de personnes pouvant lire le code source d’un projet, plus il y a de personnes pour identifier des besoins ou de nouvelles fonctionnalités utiles, plus il y a de personnes qui comprennent suffisamment le projet pour y contribuer, plus il y a de personnes susceptibles de repérer des bugs et de proposer des corrections, et plus il y a de personnes pour tester et vérifier que le nouveau code fonctionne.
+
+En général, le modèle propriétaire conduit à des communautés plus petites, isolées, fragmentées, qui peinent à trouver et adopter de nouvelles idées. L’open source conduit à de grandes communautés interconnectées, chacune aidant les projets des autres à grandir, à prospérer et à réussir, en utilisant le travail des autres comme dépendances et/ou en réutilisant leur code, et en apprenant les uns des autres. Le logiciel open source est une boîte à outils pour l’usage collectif de toute l’humanité, et plus nous avons d’outils, et meilleurs ils sont, plus vite et mieux nous pouvons progresser en tant qu’espèce.