larlet-fr-david-cache/cache/9334f31dc2330cad7b7fba411819f661/index.md

title: Noir sur blanc
url: https://nrkn.fr/blog/2017/01/28/noir-sur-blanc/
hash_url: 9334f31dc2330cad7b7fba411819f661

<p>Il est plus que temps d’écrire le dernier chapitre de cette trilogie improvisée en guise de réponse à la réflexion lancée par Antoine : “<a href="https://www.quaternum.net/2017/01/06/interroger-nos-pratiques-de-publication-en-ligne/">Interroger nos pratiques de publication en ligne</a>“. <br/></p><p>Après avoir exposé <a href="https://nrkn.fr/blog/2017/01/17/interroger-nos-pratiques-de-publication-en-ligne/">ce que représentait pour moi la démarche de publier dans un environnement auto-hébergé et auto-géré</a>, je me suis risqué à <a href="https://nrkn.fr/blog/2017/01/18/l-insoutenable-legerete-de-l-etre/">me demander ce qui pouvait bien pousser une grande majorité à préférer des plateformes comme Medium ou Facebook</a>, par exemple. J’ai émis autant de réserves dans cette démarche que j’en ai extrait de suppositions, compte tenu de mon absence de compétences dans le domaine des sciences humaines et sociales. J’insiste d’autant sur ce terme de “<i>suppositions</i>” puisque certaines de ces dernières me servent en partie de postulats pour la suite de cet article.</p><p>Je m’offre encore le temps d’une dernière précision avant d’entrer dans le vif du sujet. Histoire de rajouter un morceau de contexte dans ce qui va suivre. Pour ceux qui ne le sauraient pas, puisqu’au fond je n’ai pas trop laissé de traces, j’ai fait partie de l’équipe “<i>canal historique</i>” du projet <a href="https://fr.dotclear.org/">Dotclear</a>. J’étais présent lors de l’accouchement de la première version stable (1.2) par <a href="https://neokraft.net/">Olivier</a>. J’étais encore dans la bande pendant la longue et douloureuse gestation de Dotclear 2 et les premiers pas de ce nouveau bébé. J’ai également trouvé le moyen de verser dans le lobbying pro-<a href="https://fr.dotclear.org/association">association</a> alors que j’avais déjà un pied et demi en dehors du projet.</p><p>Maintenant que toutes les réserves et précisions d’usage ont été émises, nous pouvons passer à la suite…</p><h3><span class="caps">TL</span>;<span class="caps">DR</span></h3><blockquote><p>C’est génial !<br/>Faut tout refaire.</p><p><a href="https://neokraft.net/">Olivier Meunier</a><br/></p></blockquote><h3>Et si nous devions revoir nos copies ?</h3><p>Je compte parler de notre façon de concevoir les outils de publication en ligne, en tant que développeurs / contributeurs. Mais aussi de la manière de les promouvoir, de les diffuser et de les rendre séduisants auprès du plus grand nombre , en tant que projets ouverts et libres. Cela risque d’impliquer de gros mots et beaucoup de choses sales pour les plus libristes et plus évangélisateurs du lot. Du moins, c’est ce que je crois. Mais sans débat, nous n’avancerons pas.</p><p>D’abord, nous parlons - en tout cas, je parle - souvent d’outils. Ce terme, “outil”, n’est pas sans connotations. Il y a un petit côté bricoleur. Un côté artisan et/ou passionné. Et en parlant d’outils, nous nous adressons directement à des “utilisateurs”. En face de nous, on nous toise avec des “services” et l’on s’adresse alors à des “usagers”, plus qu’à des utilisateurs. Quand il s’agit de mesurer, on parle plus volontiers de “comptes actifs” ou d‘“abonnés”, là où nous utilisons encore et toujours, presque systématiquement… “utilisateurs”. Et si cette fixation sur l‘“outil” était tellement profonde chez nous qu’elle nous aurait fait louper un glissement essentiel. À rabâcher “outil”, n’en oublions-nous pas de penser “produit” (et/ou “service”) ?</p><p>Prenons donc l’un de nos “outils” et son projet associé et considérons désormais cela comme un produit et des services liés et voyons ce que nous pouvons en retirer. Ce sont des dents qui commencent à grincer, que j’entends ? Je n’espère pas, il est encore tôt…</p><h3>Penser différemment le produit</h3><p>Voilà, j’enfonce le clou avec une masse !</p><p>Prenons comme cobaye notre blogware ou <span class="caps">CMS</span> favori. Je fais l’impasse, pour l’instant, sur la phase d’installation. Mais nous y reviendrons. Disons que l’engin est installé et fonctionnel et que nous souhaitions maintenant nous immerger enfin dans ce monde merveilleux. Bien souvent, la première impression est un “<i>humpf!</i>“…</p><h4><span class="dquo">“</span>Cachez cette administration que je ne saurais voir !”</h4><p>La grande majorité des moteurs de blog et autres <span class="caps">CMS</span> présente ce même “travers” : vous tombez par défaut sur une interface d’administration et/ou un tableau de bord. La liste des derniers articles publiés, des dernières réactions reçues, etc. Ce n’est plutôt pas mal me direz-vous. Surtout si vous êtes actuellement blogueur. Oui, vous avez été conditionné ou vous vous êtes conformé à un certain moule…</p><p>Si les versions successives sont devenues un peu plus “<i>user friendly</i>” avec le temps, elles demeurent l’incarnation d’une certaine pensée “geek et technique” de leurs créateurs. Mais ne jetons pas la pierre à qui que ce soit : cette bonne vielle page de tableau de bord reste très pratique. Je ne la remets d’ailleurs pas en question. C’est sa prédominance que je trouve gênante.</p><p>Avec un peu de recul, avec l’expérience de certains réseaux sociaux ou autres services de publication, j’estime désormais que nous lui avons vraisemblablement accordé une place trop importante. Pour quelle raison principe nous connectons-nous à ce back-office ? Pour administrer, surveiller ou… Publier ? On pourra toujours me rétorquer “pour modérer les commentaires”, mais ça restera un petit morceau de mauvaise foi.</p><h4>Rendre sa priorité à l’acte de publier</h4><p>D’ailleurs, très tôt dans le cycle de vie de Dotclear, Olivier avait introduit une zone “<i>QuickPost</i>” au sein de ce fameux tableau de bord. L’idée a depuis été abandonnée - me semble-t-il - car elle n’avait pas les faveurs du plus grand nombre. Sans doute parce que son intégration était un peu prématurée, ou maladroite, ou contre nature compte tenu de ce qui l’accompagnait alors</p><p>Mais maintenant - bien plus qu’alors, je l’avoue -, je pense qu’il s’agissait d’une très bonne idée.</p><p>Ainsi, en lieu et place d’une entrée “Nouveau billet” dans un menu ou sous forme de bouton dans le tableau de bord, pourquoi ne pas réintroduirions-nous pas une telle zone de saisie ? Réfléchissons à comment la rendre flexible mais surtout simple et efficace. Comment faire en sorte de lever un frein et favoriser le passage à l’acte ? Comment inciter notre utilisateur/usager à créer et diffuser son contenu en lui facilitant la tâche ? Tout cela dans le but évident que cette tâche soit réalisée sur son système, sur son serveur, dans sa demeure.</p><p>J’ai glissé, en catimini, la notion de flexibilité dans l’une des phrases précédentes. Ce n’était pas innocent. C’était même un complot pour tordre le cou à ce bon vieux “<i>Billet</i>” ou “<i>Article</i>“. Oui, oui, si je continue à m’en prendre à toutes ces parties qui caractérisent tant nos systèmes actuels, ça risque de finir en génocide, non ?</p><p>Pour l’instant, je vous laisse avec l’idée d’une réponse de normand.<br/></p><h4>Du contenu. Pas des billets ou des articles. Du contenu, bon sang !</h4><p>Le weblog a toujours été vu comme la transposition sur le Web du principe de journal ou de carnet papier, comme certains d’entre nous pouvaient en tenir (et en tiennent toujours, à mon avis). Dans mes carnets, je ne laisse pas que de longues litanies sur mes émois ou de longues (et pseudo) réflexions métaphysiques. Il y a également de simples notes. Des listes de tâches. Des post-it en guise de pièces rapportées qui peuvent contenir des choses exotiques (si, si, j’ai des post-it avec des adresses <span class="caps">IP</span> et des numéros de ports, par exemple). Des schémas ou autres dessins. Etc.</p><p>Si tout cela n’a pas forcément sa place sur un blog, en partie publique qui plus est, cet inventaire est tout de même transposable dans ce contexte. Nous avons besoin de publier des “trucs” dans des tailles et des formats hétéroclites. Dès lors, pourquoi vouloir tout faire rentrer dans la notion de “billet”. Évidemment, le “post” anglo-saxon est sans doute moins marqué “article”. Dans la même veine, il y a déjà des systèmes qui proposent des types de “posts” différents ou qui permettent de construire des déclinaisons. Mais ce que j’en ai vu jusqu’à maintenant, tant chez Dotclear que chez <a href="https://wordpress.org/">WordPress</a>, ne me parait pas suffisamment intuitif pour tout un chacun.</p><p>Oh ? Mais…</p><p>… Entre le “<i>QuickPost</i>” et les multiples types de contenus traités sur un mode d’égal à égal, ne serait-ce pas <a href="https://www.tumblr.com">Tumblr</a> que je décrirais tranquillement là ?<br/></p><h4>Un modèle nommé Tumblr ?</h4><p>Mais pourquoi pas ?</p><p>S’il y a bien une plateforme que je serais apte à qualifier de “<i>micro-blogging</i>“, c’est indiscutablement Tumblr. Aussi ludique que Twitter à l’utilisation mais bien plus riche et plus souple au niveau du contenu publiable. J’utilise sciemment le qualificatif “ludique”, puisque le but de ma réflexion, je vous le rappelle, est de déterminer comment attirer et de “<i>capt(iv)er</i>” le plus grand nombre possible d’usagers. Présenté comme cela, ça pourrait néanmoins être réduit au fait de proposer un moteur de blog auto-hébergé orienté grand public. S’arrêter là serait, à mon avis, dommage et n’aurait pas fait avancer le schmilblick d’un poil.</p><p>Surtout sans parler de la notion d’abonnés et d’abonnements que nous retrouvons sur ces deux services (mais également sur ton bon réseau social digne de ce nom). Car, si j’essaie d’être logique avec moi-même - chose pas toujours très évidente, je vous le concède -, il faudrait penser notre solution non plus pour un(e) auteur(e) à tendance ours(s) solitaire mais également pour un animal social à tendance colibri. Pour ceux qui n’auraient pas suivi, je fais allusion <a href="https://nrkn.fr/blog/2017/01/18/l-insoutenable-legerete-de-l-etre/">au fameux besoin d’appartenance que je soupçonne et que j’ai rapidement abordé dans le “volume” précédent</a>.<br/></p><p>Notre outil/produit ne pourra fort logiquement pas adresser cet aspect-là à lui tout seul. Mais nous pourrions déjà lui adjoindre un pan en lui faisant embarquer l’agrégation de flux <span class="caps">RSS</span>/Atom, dans un premier temps. Au passage, nous pourrions envisager de nous débarrasser d’un autre service tiers tel qu’un Feedly, par exemple, pour ceux qui comme moi y ont recours. Un tel système embarqué permettrait d’envisager 2 changements majeurs : l’introduction d’une fonction “reblog”, très proche de ce que propose Tumblr ou sous une forme un peu plus édulcorée et surtout plus saine pour remonter à l’origine du contenu, ainsi qu’une notion de… <i>&lt; roulements de tambour &gt;</i>… timeline !</p><p>Oui, oui ! Une timeline en guise de cœur battant du back-office. <br/></p><h4>Non, je ne suis pas en plein trip sous <span class="caps">LSD</span>…</h4><p>Faisons juste preuve d’un petit peu d’imagination. Au-delà du “<i>reblog</i>“/”<i>repost</i>“, nous pourrions également implémenter une méthode pour commenter depuis chez soi, sans avoir à faire un véritable post soi-même. En gros, une sorte de webmention qui ne dirait pas son nom et qui serait également l’équivalent d’une réponse sur Twitter. Poussons le bouchon jusqu’à intégrer ce cher “<i>Like</i>“. Vous voyez le tableau ou je dois vous faire un dessin ?</p><p>Non, je ne parle pas d’héberger l’équivalent d’un réseau social chez vous, sur votre machine personnelle ou sur un bout de serveur dédié. Cela reviendrait à faire un nouveau silo, à la pérennité plus fragile et à l’intérêt moindre. Cette approche-là existe déjà ou a déjà été tentée. Si cela peut avoir un peu de sens au sein d’une entreprise, par exemple, je n’en vois aucun en dehors de ce contexte. Ce dont je parle, c’est de transformer (ou adapter) votre demeure en nœud d’un réseau social entièrement décentralisé.</p><p>Introduisons maintenant les <a href="https://www.w3.org/TR/activitystreams-core/">Activity Streams</a>. Publier devient une activité. Commenter depuis chez vous, devient une activité, etc. Notre cher produit/outil ne se contenterait plus de créer un fil <span class="caps">RSS</span>/Atom, il pourrait également publier un fil de votre activité. Et au même titre que nous parlions un peu plus haut d’agréger des fils de contenus, nous pourrions intégrer ces fils d’activités en provenance des systèmes compatibles utilisés par vos pairs. Un bon vieux principe d’abonnements/d’abonnés.</p><p>Comme nous ne changerons pas les habitudes de tous du jour au lendemain, ni ne devons nous couper du monde des silos, il faudrait également que nos solutions puissent aisément émettre des notifications vers les différents réseaux sociaux. De nombreuses solutions existent déjà pour répondre à ce besoin, telles que Buffer, <span class="caps">IFTTT</span> ou Zapier. Mieux : nous avons même des alternatives libres qui apparaissent. N’est-ce pas, <a href="https://trigger-happy.eu/">Trigger Happy</a> ? N’est-ce pas, <a href="https://brid.gy/">Bridgy</a> ?</p><p>Techniquement, les charges d’agrégations et de notifications devraient pouvoir trouver des réponses acceptables, à court terme, en travaillant sur la base de <a href="https://pubsubhubbub.github.io/PubSubHubbub/pubsubhubbub-core-0.4.html">PubSubHubbub</a>. Idéalement, l’outil/produit devrait pouvoir fonctionner autant en client qu’en serveur PuSH.  Mais un mode dégradé pourrait être possible, en déléguant une partie de cette mécanique.</p><p>Et la boucle est presque bouclée.<br/></p><h4>Pour un choix ajouté, 10 choix masqués</h4><p>Voilà une offre alléchante, n’est-ce pas ?</p><p>De fait, le choix est typiquement la médaille et son revers des offres actuelles (je parle toujours de nos outils “libres”). Pour une grosse poignée d’utilisateurs, les choix sont synonymes de liberté et de contrôle. Au moment de l’installation et du paramétrage, l’outil va présenter une multitude d’options. Au moment de la personnalisation, l’outil va présenter une multitude d’options. Au moment de publier, l’outil va présenter une multitude d’options. Bien entendu, il y a un peu d’aide et quelques recommandations pour faire les bons, pour ne retenir parmi toutes ces options que les bonnes, c’est-à-dire celles qui nous intéressent. Je fais partie de cette grosse poignée, je l’avoue.</p><p>Mais, parfois, je me laisserais bien aller à un peu plus de facilité. Et je comprends alors l’épouvante que peut subir une plus grosse poignée d’utilisateurs potentiels. Trop de choix, ça fait peur. Ça demande de réfléchir et de comprendre avant même de pouvoir faire quoi que ce soit. Avant même d’être certain que le choix déjà fait pour choisir l’outil est bien le bon. Et si nous simplifions tout cela ? Et si je faisais hurler quelques uns d’entre vous en proposant non pas d’enlever des options mais d’en choisir les valeurs par défaut, passant ainsi de l’opt-in systématique à l’opt-out ?</p><p>Notre utilisateur devenu usager se verrait peu à peu confier les pleines responsabilités. Quand il se sentirait prêt. Quand il serait impliqué et intéressé. Il découvrirait qu’il pourrait choisir un tout autre thème pour son chez lui et pas seulement un bandeau et une palette. Il découvrirait qu’il pourrait restreindre les commentaires et les rétroliens sur chaque billet s’il le souhaitait. Qu’il pourrait protéger l’accès à une section entière ou à une page, s’il le souhaitait. Qu’il pourrait décider de mettre une description complémentaire / alternative, s’il le souhaitait. Qu’il pourrait décider d’apprendre, de devenir utilisateur/artisan/passionné, s’il le souhaitait. Ou d’occulter tout cela à tout jamais, s’il le souhaitait.</p><p>Et pour en revenir au point central de l’interface back-office, il y aurait un nouveau choix à prévoir et à laisser bien visible selon moi : le mode d’utilisation. Choisir entre un mode “live”, qui serait cet affichage en <i>timeline</i> façon Twitter avec du post rapide façon Tumblr, et un mode “zen”, qui serait une interface d’écriture proche de ce qu’offre <a href="https://medium.com/">Medium</a>.<br/></p><h4>C’est bon, là ? Ou il y en a encore ?</h4><p>Il y en aurait encore beaucoup, à mon avis. D’ailleurs, j’espère qu’il y en aura encore beaucoup suite à la lecture de ce billet et aux réactions que cela pourrait susciter. <br/></p><p>Notez, pour l’exemple, que j’ai volontairement évité de discuter d’éventuelles applications mobiles natives. Pourtant, plus j’y réfléchis, plus que je crois que ce passage serait obligé. Ce ne serait pas des applications complètes qui viendraient singer ce que nous pouvons obtenir au sein d’un navigateur. Ce serait plutôt des compléments permettant de s’intégrer profondément et parfaitement dans les usages du système mobile hôte.</p><p>Mais, au delà de l’outil/produit, il y a le projet, comme nous l’appelons souvent.<br/></p><h3>Réorienter le projet et redéfinir ses services</h3><p>Actuellement, derrière chaque outil, il y a une équipe, une communauté, un écosystème complet - ou presque -. C’est tout cela que je case sous l’étiquette “projet et services associés” afin de me simplifier la vie pour la suite de mon exposé.</p><p>Nous retrouvons majoritairement des bénévoles et cela ne va pas sans poser de problèmes. Problèmes de disponibilité, risques de lassitude - quand cela ne frôle pas le burn-out -, absences de moyens, etc. Pourtant, je vais trouver le culot de leur charger encore un peu plus la mule. Drôle de remerciement, n’est-ce pas ?</p><p>Car, oui, au-delà du code de l’outil, de la documentation et du support, d’autres tâches attendent ces braves troupes si nous voulons envisager une reconquête du Web. Et nous y trompons pas : si cela n’apparait qu’en filigrane, c’est pourtant bien ce dont il s’agit. Avec un tel objectif, quelques tâches techniques supplémentaires seront nécessaires. Côté développement - évidemment - mais également sur des aspects d’exploitation et d’opérations.</p><p>Mais les défis à relever ne seront pas exclusivement techniques ou documentaires. En cela, les projets actuels auraient tout intérêt à séduire et recruter d’autres types de profils.<br/></p><h4><span class="dquo">“</span>Notre produit est bon. Mais attendez de voir nos services…”<br/></h4><p>Nous pourrions convenir que les services qu’offre un projet tiennent dans cette liste : la production et la distribution du produit, la documentation et le support (essentiellement sur la base d’un forum et d’une <span class="caps">FAQ</span>). Et si cela n’était en fait que le package produit ? Tiens, d’ailleurs, je pousse la provocation jusqu’à l’affirmer ouvertement. Mais alors quels seraient les services ?</p><p>Sur l’infrastructure du projet, nous pourrions avoir un principe d’annuaire. Cet annuaire serait alimenté automatiquement à chaque création d’un nouveau site avec l’outil. Au moment de l’installation de l’outil, ou de la création d’un nouveau site avec ce dernier (pour les outils multi-sites), une entrée serait créée dans l’annuaire (pour peu que l’<span class="caps">URL</span> du nouveau site soit publique, bien entendu). Et régulièrement, les thématiques associées à ce site seraient évaluées et mises à jour en fonction des publications.</p><p>La bonne vieille blogroll telle que nous la connaissions pourrait se transformer de fait en une liste d’abonnements. Ces abonnements pourraient alors être vérifiés auprès de l’annuaire du projet (en premier lieu, mais pas que) et deviendraient alors actifs. Cela déclencherait ainsi l’agrégation des contenus et, éventuellement, des activités en provenance de chacun de ses abonnements. Chaque source recevrait également une notification d’un nouvel abonné (et l’<span class="caps">URL</span> du site correspondant, au minimum).</p><p>De cet annuaire, le projet pourrait également en décliner un portail de contenus : simplement un gros “<i>Planet</i>” présentant les extraits agrégés, renvoyant directement vers la source de chacun mais également indexant le contenu de chacune (en total respect du fichier <i>robots.txt</i>, cela va de soi) et pouvant ainsi servir de moteur de recherche.</p><p>L’image se fait-elle plus nette ?<br/></p><h4>L’union fait la force (et l’oignon, la soupe)</h4><p>J’ai soupé des querelles de clochers qui polluent régulièrement les projets libres. Qu’il s’agisse des débats houleux et stériles sur le mode “telle techno est meilleure que telle autre” ou encore “<span class="caps">XXX</span> sucks! <span class="caps">YYY</span> rocks!”. Sérieusement ? Nous ne serions pas de sérieuses bandes de cons ? Le mode interrogatif n’est là que pour la rhétorique. Désolé pour le spoiler.</p><p>La charge de travail nécessaire pour assurer la mise en œuvre et le bon fonctionnement des quelques services donnés en exemple dans le paragraphe précédent justifierait qu’elle soit partagée. Que les travaux soient mutualisés et qu’une véritable collaboration sur ces aspects s’installe entre des projets “concurrents”. Trois d’entre eux reposent sur <span class="caps">PHP</span> ? Parfait ! Il y a 3 groupes de développeurs en mesure de travailler sur une implémentation de référence commune dans ce langage. Rien n’empêche ensuite chacun de ces groupes de travailler sur une surcouche de spécialisation propre à son produit, si son projet le juge souhaitable. Mais pitié… Arrêtons de réinventer la roue à chaque fois, de chaque côté.</p><p>Et évitons également le communautarisme. Je parlais d’annuaire et d’abonnés/d’abonnements. Connectons-les entre eux ! Qu’est-ce qui a fini par vous échapper dans le sens premier d’”<i>Internet</i>” ? Faut-il vraiment que je vous dessine une toile d’araignée pour que vous vous rappeliez ce qu’il y a derrière le terme “<i>Web</i>” ? Nous crions à la liberté et à l’ouverture. Franchement, notre propre application de l’ouverture n’est pas uniquement discutable. Elle en devient parfois risible. Nos discours sont beaux. Passons aux actes et à la pleine mise en application. Prouvons en montrant l’exemple. Et ce sera également l’occasion de vérifier si nous ne nous trompons pas.<br/></p><h4><span class="dquo">“</span>T’es gentil, Bibi. Mais… Il faut du monde et des moyens pour tes idioties !”</h4><p>Effectivement. Je n’ai dit ni le contraire ni que ce serait facile.</p><p>D’après moi, il faudrait commencer par les nouvelles recrues. Et là aussi, beaucoup des équipes actuelles pourraient être amenées à faire preuve d’une plus grande ouverture. De nouveaux profils, de nouvelles compétences : des gestionnaires, des négociateurs, des vendeurs et des acheteurs, des juristes et des avocats. Comble du comble : même des “<i>marketeux</i>“ !</p><p><i>&lt; Hérésie ! Hérésie ! &gt;</i></p><p>Et pourtant… Ce serait peut-être le premier type de profils à recruter. Justement pour nous aider à attirer les autres. Les dernières neiges de l’utopie du Web sont en train de fondre très rapidement. L’horloge tourne vite et nous devons admettre que l’évangélisation seule prend trop de temps. Pire, elle ne suffira jamais. Il faut lui adjoindre des techniques d’influence et de séduction. Notre discours, notre démarche doivent être affutés, alignés sur les standards actuels de notre société. Il n’est pas question d’en changer le fond mais les formes.</p><p>Nos projets ont besoin de gagner en visibilité et en notoriété pour pouvoir grimper en “puissance”. Ne serait-ce que pour ces questions de moyens nécessaires pour assurer de bons niveaux de services. Il y aura besoin de connectivité, de serveurs, de stockage. Dans des proportions que les seuls dons ou cotisations aux associations ne pourront sans doute suffire à couvrir. Il faudra donc aller négocier du sponsoring, du partenariat. Faire comprendre aux hébergeurs indépendants qu’ils ont tout à gagner en fournissant gracieusement quelques VMs et gigaoctets à des projets qui sont les derniers remparts face à des silos qui ne leur confieront jamais la gestion de leurs infrastructures. En tout cas jamais dans des conditions financières saines. <br/></p><h4>Travailler à l’instauration d’un cercle vertueux<br/></h4><p>Les Google, Microsoft, Facebook, Amazon et autres (ne nous limitons pas aux seuls GAFAs, Ok ?) remettent en question un bon nombre de libertés mais menacent également tout un écosystème : petits éditeurs, hébergeurs indépendants et même certains vendeurs de noms de domaines. Autant d’alliés qu’il nous faudrait gagner. Il faudra donc parfois également savoir parler d’argent. Comprendre qu’il en faut, c’est comme ça et nous n’y changerons rien d’un coup de baguette magique. Comprendre que rentabilité ne signifie pas forcément profit. Qu’un peu de profit pour alimenter les investissements, ce n’est pas sale. Arrêter de se raconter des craques et de se contenter de se bercer d’illusions. Ainsi, il faudra jouer le jeu commercial et savoir renvoyer la balle.</p><p>Un hébergeur aura tout à gagner à s’associer avec un projet si ce dernier lui permet également de gagner de nouveaux clients. Tout cela peut se faire intelligemment. Des équipes mixtes peuvent se concentrer sur le bon déploiement et les bonnes performances de l’outil chez l’hébergeur. Le projet peut émettre des recommandations auprès des utilisateurs en quête d’une solution d’hébergement. Il n’y a aucun mal à cela tant que cela se fait dans la transparence et dans l’intérêt premier des utilisateurs mais également des autres parties prenantes. Je vous invite à relire le paragraphe juste au dessus si vous ressentez déjà l’envie de maugréer.</p><p>Et de tels alliés pourraient également aider à porter d’autres projets un peu fous. Pourquoi ne pas imaginer un soutien à l’<a href="https://www.eff.org/"><span class="caps">EFF</span></a> en vue d’une démarche auprès de l’<span class="caps">ICANN</span> et de l’<span class="caps">IANA</span> destinée à la création d’une extension générique ? L’<span class="caps">EFF</span> pourrait alors gérer ce nouveau registre afin de fournir des noms de domaines aux <i>Netizens</i> enfin retrouvés, à la façon qui se répand actuellement pour les certificats avec <a href="https://letsencrypt.org/">LetsEncrypt</a>.</p><p>Ne pas se bercer d’illusions n’implique pas non plus d’arrêter de rêver…<br/></p><h3>Concevons les réponses ensemble</h3><p>Je m’imaginais être en mesure de faire un texte plus bref, plus condensé. Malheureusement, je manque de pratique et je ne souhaitais pas laisser trainer cela plus longtemps. J’aurais encore beaucoup à dire. Beaucoup à écrire, à corriger, à préciser. Beaucoup trop pour une personne seule. Avec beaucoup trop de risques d’une approche condamnée à être biaisée, pour cette dernière raison. Et puis cette grosse montagne pourrait bien n’accoucher que d’une minuscule souris (sans fil ?).<br/></p><p>Ne vous y trompez pas. Ce texte n’est pas un manifeste. Je n’ai fait que mettre noir sur blanc une grosse poignée d’idées et de réflexions qui me traversent la tête ou m’occupent l’esprit depuis plusieurs années, de manière récurrente. Tout cela a ressurgi avec l’incitation d’Antoine à réfléchir et débattre du propos de la publication en ligne. Je me suis donc précipiter par l’entrebâillement de porte ainsi présenté.</p><p>Pour les plus “techos” d’entre vous, vous aurez noté que je ne parle pas de Blockchain, d’<span class="caps">IPFS</span>, etc. C’est volontaire. Il y a sans doute de vrais gros et beaux potentiels derrière tout cela. Je garde d’ailleurs un œil rivé sur tout ce qui peut porter une étiquette “<i>Decentralized Web</i>“. Mais tout ceci est encore trop loin de la maturité et nous manquons cruellement de retours d’expériences. Ce qui n’est pas le cas de ces bons <span class="caps">HTTP</span>, <span class="caps">JSON</span>, <span class="caps">XML</span> et consorts, protocoles et formats avec lesquels les vieux routards du Web sont familiers.</p><p>Tout ce qui figure dans ce texte est critiquable et devrait être critiqué. La seule condition étant de le faire dans une démarche constructive. D’ailleurs, je vous invite tous à envisager <a href="http://www.christian-faure.net/2013/06/05/lapproche-pre-mortem-dun-projet/">une approche pre-mortem</a>. Pour chaque frein identifié, essayez de livrer des pistes pour tenter de le lever. Et pour lever toute ambiguïté, en cas de besoin si ça peut servir, <a href="https://creativecommons.org/licenses/by/4.0/">ce texte est sous licence Creative Commons 4.0 - Attribution (<span class="caps">CC</span>-<span class="caps">BY</span>)</a>.</p><p>Sinon…<br/>On en rediscute ensemble quand vous voulez !<br/></p>