Librairies dans les nuages

J’essayais l’autre jour de convaincre une connaissance, grosse lectrice, d’arrêter d’acheter ses livres sur Amazon et d’enrichir l’abject libertarien Jeff Bezos. N’étant moi-même pas adepte du commerce en ligne, j’ai lancé un appel à la vox populi des oiseaux bleus pour savoir où acheter des livres en ligne. Je compile ici les différentes réponses, en en profitant pour remercier toutes celles et ceux qui m’ont répondu.

Je précise que je cherchais une alternative réaliste, c’est à dire à prestations équivalentes à celles d’Amazon, gros catalogue et délais de livraison raisonnables. Les solutions demandant un effort sont à écarter, car malheureusement beaucoup de gens choisissent Amazon pour sa simplicité, et refuseront les alternatives plus propres mais moins simples. Quand à la réponse la plus évidente, passer chez un libraire physique, elle est malheureusement à réserver aux gens habitant au centre de grandes villes. Dans ma banlieue, la seule librairie indépendante ferme à 19h, je ne peux y passer que le samedi. Pour peu qu’il faille commander l’ouvrage, ça oblige à attendre une semaine de plus. Inenvisageable pour les gamins impatients que nous sommes devenus.

Merci donc :

J’espère n’avoir oublié aucune réponse. La plupart des sites précédents offrent les frais de port à partir d’un certain montant de commande, et certains proposent comme Amazon des livres d’occasion. Ne pas contribuer à renforcer le mortifère monopole d’Amazon semble donc possible.

Pour un navigateur public

Je suis retombé récemment sur cette passionnante introduction sur la naissance des standards qui régissent le Web, rédigée par Karl. Il y rappelle entre autres comment XHTML 2, le successeur de HTML 4, est mort. Quelques forgeurs de navigateurs, Apple, Mozilla et Opera, ne voulaient pas entendre parler de la voie XML choisie par le W3C, et ont décidé d’implémenter un simple dérivé de HTML 4, HTML 5. Sans implémentation, XHTML 2 est restée une spécification de papier, morte-née (et je le regrette amèrement, car elle aurait permis au Web de bénéficier du vaste et vivant écosystème d’outils autour de XML). Ce sont donc les éditeurs de navigateurs, et non la communauté investie dans les groupes de travail du W3C, qui ont décidé de la voie que devait prendre le Web.

Les exemples similaires sont nombreux. En 2007, JavaScript s’apprêtait à connaitre une très importante évolution (ES4) qui aurait démultiplié ses capacités. Microsoft a refusé d’implémenter cette version de la spécification (elle aurait permis au Web de devenir une plateforme applicative attractive et concurrente de la poule aux œufs d’or Office). Comme IE était alors le navigateur majoritaire, ce véto a été fatal à ES4, et les développeurs JavaScript ont dû attendre de nombreuses années avant de disposer d’un langage mature pour créer de meilleures applications. Plus anecdotique, Mozilla a refusé récemment d’implémenter la spécification JSON LD, proposée par un groupe de travail du W3C. Ce refus risque d’enterrer cette fonctionnalité, comme a également été enterrée la possibilité de disposer dans le navigateur d’une base de données comprenant SQL, Mozilla ayant préféré IndexedDB à WebSQL. Enterrées également, par Google cette fois, l’API microdata ou les régions CSS. Et tant d’autres fonctionnalités, /ad nauseam/.

En tant que créateur et utilisateur du Web, toutes ces décisions me frustrent, car elles stérilisent de nombreuses routes, m’empêchent de coder bien des rêves, ou du moins me contraignent à d’épuisantes acrobaties. Et je m’interroge de plus en plus sur ce pouvoir démesuré des fabricants de navigateur de décider sans appel des technologies qui façonnent le Web. En ce domaine au moins, « Code is law », ce sont les éditeurs de navigateurs qui écrivent les lois du Web. Mon seul pouvoir, en tant que pronétaire, est de favoriser l’un des éditeurs. En effet, leur pouvoir dépend essentiellement de leur part de marché. Sur le mobile, Mozilla est inexistant car la présence de Firefox est encore dérisoire, ce sont donc Apple et Google qui ont un droit de vie et de mort sur l’évolution des spécifications nécessaires pour créer des applications mobiles. On se souvient de comment Apple a utilisé ce pouvoir pour porter un coup fatal à Flash.

La situation n’est certes guère différente de la démocratie parlementaire. Ici on élit des membres du parti Blanc Bonnet ou du parti Bonnet Blanc, mais les uns comme les autres façonnent une fois élu et main dans la main des lois conformes à leurs seuls intérêts, sans se soucier de leurs mandants. Là, je donne du pouvoir à Mozilla en utilisant Firefox, mais Mozilla, comme ses semblables, se soucie comme d’une guigne de mon avis.

L’initiative Webizen du W3C pourrait être intéressante. Pour l’instant la plupart des législateurs du W3C sont des entreprises qui n’y défendent que leur intérêt à court terme, remplir de blé les poches de leurs actionnaires (il y a également quelques organismes publics, laboratoires ou université, j’ignore quel est leur impact). Webizen voudrait permettre à tous les citoyens du Web de faire davantage entendre leur voix. C’est un pas dans la bonne direction, mais je pense que cela restera symbolique tant que les éditeurs de navigateurs auront le dernier mot, en choisissant d’implémenter ou non les lois votées. Webizen peut permettre aux citoyens de mettre un pied au siège du pouvoir législatif. Mais tant qu’ils n’auront aucun contrôle sur l’exécutif, et notamment les forgerons de navigateur, leur pouvoir de décision restera tout théorique.

Pour prendre le contrôle du Web, pour en faire un espace démocratique, c’est donc sur les éditeurs de navigateurs que les citoyens doivent peser. Idéalement, je suis partisan d’une socialisation des fondeurs de brouteurs, c’est à dire leur prise de contrôle par les internautes. Mais je reconnais que les conditions n’en sont peut-être pas encore réunies, et qu’il faudra sans doute dans un premier temps se contenter d’alternatives moins radicales.

La solution la plus évidente serait un projet de R&D international, mené par des laboratoires publics sous l’égide de l’ONU, de l’Unesco, de l’AIT ou d’une quelconque structure internationale représentant les citoyens (je ne suis pas partisan de la « démocratie représentative », et ne considère aucunement l’ONU ou l’Unesco représentatives des citoyens, c’est juste pour illustrer l’idée). Après tout, le Web offre d’énormes perspectives, tant sociales qu’économiques, et je trouve complètement délirant que la R&D dans ce domaine soit abandonnée au secteur privé, alors que c’est un sujet qui concerne au plus haut point l’ensemble des citoyens. La mutualisation des moyens devrait rendre la question du financement d’un tel projet anecdotique. Et si les participants s’y investissaient vraiment, et s’en donnaient les moyens, le navigateur développé pourrait rapidement obtenir les parts de marché nécessaires pour avoir voix au chapitre à la table de spécification. Il « suffirait » qu’il devienne le navigateur par défaut dans tous les service publics mondiaux, les écoles, etc. L’embryon d’un tel projet existe, c’est le navigateur Amaya, dont le développement a malheureusement été arrêté il y a plusieurs années.

Sur le papier, cette option ne me semble pas du tout utopique, il suffirait d’un peu de volonté politique pour changer la donne, et offrir aux citoyens un navigateur public, base d’un futur service public de l’Internet. Mais je n’y crois pas. Parce qu’aucun des acteurs en place n’y a intérêt. Le Web porte en lui la possibilité de profondes mutations. Ni les politiques au pouvoir, ni les multinationales n’ont intérêt à favoriser l’éclosion d’alternatives qui remettraient en cause leur pouvoir. Souvenons-nous de Microsoft, qui avec son IE6 et ses réticences aux évolutions de JavaScript, a essayé de freiner le Web pour ne pas qu’il vienne concurrencer sa rente. Les gouvernements en place et le pouvoir économique qui les mandate n’a pas plus intérêt que Microsoft à favoriser la fertilisation des réseaux. Quant aux acteurs du Web, je crains qu’ils ne soient bien trop imprégnés de l’anti-étatisme libertarien de la Silicon Valley pour accepter qu’un projet public mette les pieds dans leur jardin. Même si ça n’est pas, pour une fois, pour tenter de « réguler », mais au contraire, pour encourager l’innovation, en veillant juste qu’elle soit guidée démocratiquement.

Une autre solution est peut-être alors à chercher du côté de la multitude. Que nous, utilisateurs du Web, nous associons pour financer un navigateur dont le développement serait démocratique. Financièrement, l’idée n’est pas totalement délirante. En 2013, le budget de la fondation Wikimedia était de 48M$, majoritairement financé par des dons, d’individus ou d’organisations. C’est à peine moins que celui de Mozilla en 2005 (52M$). Il « suffirait » de quelques millions d’utilisateurs du navigateur s’engageant à donner 1$ par mois pour assurer viabilité financière et indépendance à un tel projet. C’est énorme au vu des chiffres récemment révélés sur par exemple le budget d’OpenSSL, mais pour un logiciel aussi visible qu’un navigateur, ça ne me semble pas une solution de financement complètement irréaliste. Les principaux écueils du projet seraient plus à mon sens au niveau de la prise de décision (comment éviter la dérive vers un système aristocratique qualifié de « méritocratique ») et surtout comment obtenir un nombre suffisant d’utilisateurs pour peser dans les processus de décision des comités de standardisation. Quand je vois l’érosion continue du nombre d’utilisateurs de Firefox, je doute qu’un navigateur avec un positionnement proche réussisse à capter beaucoup d’internautes.

Je n’ai pas de solution miracle. Mais suis persuadé que si nous voulons récupérer un peu de souveraineté sur nos vies numériques, nous devons essayer d’inventer un navigateur public, créé par les internautes, pour les internautes.

Enrichir la barre d’URL

À l’occasion du débat actuel sur la probable disparition prochaine de la barre d’URL des navigateur, je suis tombé sur un Plaidoyer pour l’URL qui propose entre autres d’améliorer les possibilités d’édition de la barre d’url, via une interface de navigation. L’idée n’est pas neuve, et avait d’ailleurs déjà été évoquée par Mozilla lors d’une tempête de cerveaux sur la refonte de la barre d’url. Je la trouve bonne, et m’étonne qu’aucune extension ne semble l’avoir implémentée. Peut-être parce que bidouiller la barre d’adresse est ardu, je ne sais. En fouillant un peu, j’ai découvert The Standard-Sitemap Protocol (SSP). Ce projet propose de standardiser la façon pour un site d’exposer son plan. Le standard de fait actuel étant le format / protocole Sitemap introduit par Google en 2005. Ici encore, les bénéfices de standardiser cette fonction me semblent nombreux, et je suis étonné que l’initiative SSP n’ait pas eu plus d’écho. Si des gens s’ennuient, il y a là matière à faire un travail des plus utiles.

Je ne me fais cependant guère d’illusion, c’est là un combat d’arrière-garde pour nostalgiques. En tant qu’amoureux du Web-de-quand-j’avais-20-kilos-de-moins, je suis évidemment très attaché aux URL. Mais je me doute que très bientôt, elles seront définitivement considérées comme un détail d’implémentation et disparaitront définitivement des interfaces, au nom de la simplification. L’affichage de l’url cible d’un lien au survol est elle-même en sursis depuis des années, présageant la destinée de la barre d’URL. La tendance de fond actuelle est au nivellement par le bas, à penser toute interaction uniquement en fonction de terminaux tactiles monotâches où l’espace est compté. La plupart des utilisateurs y trouveront sans doute leur compte, seuls les vieux cons aigris et pré-post-modernes dans mon genre grommelleront en regrettant que leurs merveilleux outils aient été remplacés par de simples écrans de télévision.

Austrapocalypse

Ce vingt-neuf avril deux mil quatorze est un jour sombre pour les amoureux du Web, qui voit Mozilla, un de nos meilleurs alliés, faire deux dramatiques erreurs. Aujourd’hui, comme toutes les six semaines, sort un nouvel avatar de Firefox. Mais Mozilla a voulu faire de cette version vingt-neuf un évènement spécial. Depuis des années, lentement, les utilisateurs se détournent de Firefox. Mozilla veut regagner le terrain perdu, et montrer que Firefox a changé. Ce qui est vrai. S’il a connu, en termes de performances ou de fonctionnalités, un coup de mou qui a rendu Chrome plus utilisable, cette époque est à présent révolue. Firefox est de retour en haut du podium, il n’a plus rien à envier, sur quelque terrain que ce soit, à ses concurrents, et je m’en réjouis.

Si ce renouveau est évident pour les fans, il reste à en convaincre le grand public. Et pour cela, Mozilla a décidé de symboliquement rajeunir également l’interface de son navigateur. Le nom de code de ce projet est Australis, d’où le titre de ce billet. Elle l’a malheureusement fait d’une manière que je trouve catastrophique, en privilégiant deux axes, google-isation et neuneu-isation. Neuneu-isation, parce que cette version masque de nombreuses options, n’offre plus qu’un menu avec neuf pauvres et énormes icônes, comme si les utilisateurs étaient trop bêtes pour faire autre chose que cliquer sur de gros boutons. Google-isation, parce que de la forme des onglets au nouveau menu, simple icône incompréhensible soudain déplacée à l’extrême-droite, il est difficile de ne pas trouver un air de famille entre le « nouveau » Firefox et l’ancien Chrome. Et je trouve que cette similitude brouille complètement le message de Mozilla. Comment expliquer qu’à la différence de Google, nous nous préoccupons réellement du respect de leur vie privée, quand visuellement plus grand-chose ne nous distingue de Google ?

Plus qu’une volonté de singer Google, Australis marque peut-être une étape vers une unification de l’interface entre les versions de Firefox présentes sur les ordinateurs de bureau et sur les terminaux mobiles équipés d’Android ou Firefox OS. L’intention est louable. Malheureusement, j’ai l’impression qu’elle se concrétise pour l’instant par un nivellement par le bas. Au lieu de prendre l’interface épurée de Firefox OS et de l’enrichir pour les terminaux plus utilisables que les gadgets tactiles, Mozilla n’offre plus aux utilisateurs d’antiques ordinateurs à clavier qu’un clicodrome simplifié à l’extrême, d’où ont disparu pratiquement toutes les options.

Cette nouvelle interface est donc selon moi, en elle-même, une erreur. Mais comme si cela ne suffisait pas, Mozilla perd aussi dans cette opération une partie de son bien le plus précieux : la communication pour vendre cette refonte graphique atténue à mon avis la crédibilité de Mozilla et la confiance que les utilisateurs lui accordent.

Qu’il y ait eu ou non intention de copier Google importe peu au final. Le résultat est que beaucoup d’utilisateurs percevront une similitude. « Tiens, ils ont copié Chrome » est la première réaction qu’ont eue beaucoup de gens auxquels j’ai montré Australis. Peu importe que cela soit vrai, c’est ce que les utilisateurs perçoivent. Mais, sur ce point, la communication de Mozilla est catégorique. Il faut nier l’évidence, prétendre jusqu’à l’absurde que la nouvelle interface de Firefox ne ressemble pas à celle de Chrome. Et tous les Mozilliens sont priés de reprendre ces éléments de langage fournis par les services marketing, priés de se ridiculiser et de perdre toute crédibilité en niant toute similarité.

Le message passera probablement auprès de nombreux utilisateurs qui n’en ont après tout rien à faire. Mais quid des passionnés, des communautés libristes amies, de tous ceux qui ne seront pas dupes. Quelle valeur aura encore demain la parole de Mozilla, ses discours en faveur du Web Libre, son engagement à placer l’utilisateur au centre du monde, ses affirmations d’être différent, quels sens auront encore nos mots lorsqu’il sera évident qu’une partie au moins de nos discours n’est que mensonges dictés par des marketeux, ne valant pas mieux que les histoires racontées par Google, Apple, Facebook.

Sous le capot de Firefox, et dans d’autres domaines, Mozilla continue de faire un travail précieux pour faire progresser la plate-forme Web et pour multiplier ses promesses. Mais je ne peux qu’être profondément triste et déçu de voir l’énergie dépensée pour réaliser puis promouvoir un projet par lequel elle se tire une balle dans le pied. Triste de voir le projet perdre peu à peu sa crédibilité auprès des utilisateurs avancés qui ont toujours été ses fervents promoteurs.

Enfin, de l’énergie, il va également nous en falloir si comme moi vous avez installé Firefox chez de nombreuses personnes. Préparez-vous à quelques difficiles journées de support pour les aider à reprendre leurs marques. Heureusement, le vieux Firefox, extensible et bidouillable, n’est pas encore tout à fait mort, et plusieurs extensions existent qui permettent d’annuler la plupart des régressions d’Australis, et de conserver à Firefox son aspect actuel. Je vous conseille par exemple de jeter un œil à Classic Theme Restorer, et de l’installer chez tous ceux qui ne veulent pas d’une interface « à la Chrome ». Malheureusement, l’extension propose de nombreux réglages, et n’est de ce fait pas à la portée de tous les internautes. Une version simplifiée, avec juste un gros bouton « arrêter les conneries », aurait été bienvenue. On trouve en ligne de nombreux articles expliquant comment réparer les dommages causés par Australis, par exemple celui-ci, mon principal regret est de n’avoir pas eu le temps d’en rédiger un en français.

Ne reste plus qu’à espérer que l’Austrapocalypse ne laissera pas trop de traces indélébiles, et n’altèrera pas durablement la confiance des internautes en Mozilla. Ça serait dommage car la route est encore fort longue, et nous n’avons malheureusement pour l’instant guère de meilleur allié que le petit panda roux.

(Merci à Goofy pour les corrections ☺)

HTML ou encore ?

Il y a peu, Jérémie Patonnier s’interrogeait sur la pertinence d’HTML. Ce a quoi je répondis « ah si les navigateurs interprétaient nativement Markdown pour les documents et XUL pour les applis ;) ». C’était une boutade en écho à un excellent texte de Bruno Bord, notant que pour composer des textes sur le Web, Markdown était largement suffisant, et regrettant que les navigateurs ne soient pas capables d’afficher nativement des fichiers Markdown.

Mais, à la réflexion, ma boutade était peut-être sérieuse. Contexte. Le Web est aujourd’hui un média de masse très accessible, qui permet, moyennant un apprentissage relativement simple, à chacun d’accéder à des connaissances, de s’exprimer et d’échanger. Une deuxième tête est en train de lui pousser, porteuse de nouvelles promesses : il devient une plateforme encore une fois relativement universelle et simple d’accès permettant de manipuler des données, de faire, de créer. Bien sûr, aucun des usages du Web ne sont innés, ni l’expression, ni la communication, ni la création. Pour qu’un maximum de gens puissent tirer partis de ce potentiel, il faut les éduquer au Web, enseigner les techniques et les usages d’expression et de création en ligne. C’est l’objet, entre autres, du programme Webmaker de Mozilla. Dans un premier temps, Webmaker a développé des outils pour enseigner les techniques de base du Web, HTML, CSS, JavaScript. Le programme s’est depuis étendu à des domaines plus génériques, avec la création d’un référentiel de compétences. Je vous invite à lire sur le sujet l’excellente série d’articles du génial Goofy.

Je suis très content de la direction prise avec ce référentiel de compétences, et m’interroge sur l’utilité d’enseigner HTML proprement dit au plus grand nombre, et notamment aux enfants. HTML a été fondamental pour ma génération, celle des pionniers du Web, parce que lorsque nous avons découvert la toile, il n’y avait pratiquement rien, et que c’est en apprenant HTML que les collègues ont créé le Web que nous connaissons aujourd’hui. HTML est encore fondamental pour mes pairs, les développeurs Web, parce que c’est lui qui nous permet de donner vie à tous nos rêves numériques. Mais je crois qu’aujourd’hui, connaître HTML n’est absolument plus nécessaire pour tirer profit de la toile. Depuis dix ou quinze ans déjà, maîtriser HTML n’est plus obligatoire. Une des plus belles réussites du Web est à mon avis Wikipedia. Combien de contributeurs Wikipedia connaissent HTML ? Une autre réussite est la galaxie des carnets, tous ces journaux où la liberté d’expression et le débat se démocratisent enfin réellement. Hormis les dinosaures, combien d’auteurs de carnets connaissent HTML ? Pour Wikipedia comme pour les carnets, la seule connaissance technique nécessaire est celle d’un langage permettant de structurer son expression et de créer des liens. Les différents langages de balisage léger, comme Markdown ou les syntaxes Wiki, sont largement suffisants pour cela, nul besoin d’apprendre les détails de la sémantique HTML pour s’exprimer et débattre en ligne.

Quid de l’autonomie ? Certes, en ne connaissant plus HTML, on devient dépendant de plateformes de publication, d’outils tiers. Mais dans ce cas, HTML n’est que la petite couche de vernis au sommet d’un vaste édifice. Si l’on veut que les gens soient capables de s’exprimer de manière complètement autonome en ligne, il ne faut pas enseigner qu’HTML, mais aussi un langage serveur, l’architecture d’un serveur Web, l’administration d’un serveur. Comment écrire de tels serveurs. C. Ou l’Assembleur. Et peut-être aller encore plus loin du côté du matériel. HTML était le langage indispensable à connaitre il y a quelques années pour faire du Web, comme l’Assembleur était l’alphabet de l’informatique il y a 50 ans. Mais aujourd’hui, nous avons des outils qui nous dispensent de connaître l’Assembleur, et d’autres qui nous permettent de manipuler des abstractions plus aisées qu’HTML.

Pour ce qui est de l’expression en ligne, apprendre à mettre en forme ses idées via quelques annotations basiques, celles fournies par Markdown par exemple, me semble donc largement suffisant. Encore faudrait-il que comme le souhaite Bruno Bord, Markdown et ses frères soient des citoyens de première classe sur le Web. Que n’importe qui puisse publier directement un texte avec quelques indications de formatage, que les navigateurs sauraient interpréter.

Or, ce rêve est en train de devenir réalité grâce à la principale évolution de HTML depuis sa naissance, les composants Web. Cette technologie permet d’assembler les petites briques legos d’HTML pour en faire des objets de plus haut niveau, plus simples à utiliser. Hier, pour créer un blog, il fallait mettre dans une marmite toute une soupe de DIV, assaisonner généreusement de CSS, utiliser un langage pour convertir la mise en forme appliquée par l’utilisateur en mise en forme compréhensible par le navigateur. Aujourd’hui, afficher un billet dans un navigateur ne nécessite plus que d’utiliser une seule balise :

<x-post src="http://toto.org/mon-fichier.markdown"></x-post>

Tout comme la balise IMG sait récupérer une image enregistrée en gif, jpeg ou png et l’afficher, la balise x-post sait récupérer un fichier formaté en Markdown, Textile ou reStructuredText et l’afficher.

Et si on veut tout un blog, dont la structure serait définie dans un fichier formaté en [YAML](http://fr.wikipedia.org/wiki/Yaml) par exemple, une balise suffit encore une fois :

<x-blog src="http://toto.org/mon-fichier.yml"></x-blog>

Bien sûr, x-blog affiche juste une liste d’articles, pour mettre le tout en forme de façon un peu plus jolie, il sera sans doute nécessaire de l’entourer d’un x-layout auquel on indiquera un nom de thème. Mais c’est tout.

Demain, pour créer un blog, on n’aura plus besoin de mettre les mains dans le HTML. Juste d’importer un composant (créé en HTML) et de l’utiliser. Ce qui, grâce à la grande tolérance des navigateurs aux erreurs de syntaxe, permet d’écrire un moteur de blog en seulement deux lignes :

<script src="blog-component.js"></script>
<x-blog src="config.yml"></x-blog>

Les composants Web ne fonctionnent pas encore dans tous les navigateurs, mais des bibliothèques permettent de les émuler. En jouant avec X-Tags, une bibliothèque développée par Mozilla, il ne m’a fallu que quelques minutes pour créer les balises x-blog et x-post décrites ci-dessus (soyez indulgents, c’est ma première expérience avec cette technologie). Donc estimer qu’HTML est en passe d’être supplanté par des composants Web d’un plus haut niveau d’abstraction n’est pas de la science-fiction, c’est ce qui, j’en fais le pari, va arriver très bientôt.

Et pour en revenir à ma boutade initiale : désormais, pour créer sur le Web, les seules connaissances techniques nécessaires sont un langage de structuration du texte, et savoir assembler des composants de haut niveau. Attention, je ne parle que des compétences techniques, car la communication et la créativité en ligne sur le réseau demandent bien d’autre chose que de la technicité. Je partage sur le sujet l’opinion du Président Benjamin : l’apprentissage du Web n’est pas du ressort des professeurs de science, mais plutôt de français ou de philosophie.

Petite note triste : je ne peux m’empêcher d’être triste en me disant que nous avons perdu dix ans. Markdown a été créé en 2004. Les composants Web sont les enfants de XBL créé par Mozilla il y a plus de dix ans. Nous avions donc depuis longtemps les moyens techniques de dépasser HTML pour simplifier l’accès à la création Web grâce à un langage de formatage basique et des composants de haut niveau. Mais il a fallu des années de maturation avant que la chrysalide ne commence enfin à éclore.

Bien évidemment, je ne parlais ici que des moyens à mettre en œuvre pour permettre aux humains de devenir autonomes et créatifs en ligne. Cette autonomie suppose quelques pré-requis que nous oublions généralement, comme l’accès à l’eau, des pizzas, de l’électricité, du Wifi, et deux ou trois autres gadgets nécessaires à la survie.

Fork me on GitHub