Je suis toujours mauvais à Pacman

Evidement, je ne parle pas de jouer moi-même au pacman, mais plutôt de celui auquel il faut jouer dans le spring challenge 2020. Parce que comme j’ai l’intention de concourir dès demain, en essayant autant que possible de faire du Rust, j’ai essayé de me remettre à niveau en reprenant le problème précédent, et en essayant d’améliorer la solution dont je disposais déja. Et, comme vous pouvez le voir dans cette simulation, ça ne marche pas si bien. Avant d’aller plus loin, on va d’abord voir rapidement ce que fait mon robot.

Donc, à chaque tour

  • D’abord, je découpe le terrain (autrement dit, je construis un pavage du plan) pour disposer pour chaque pac d’un terrain disjoint.
  • Et ensuite, pour chaque pac, je score chaque déplacement en fonction des pillules atteignables au 7 prochains tours.

Il y a un certain nombre de choses qui ne sont pas implémentées, et c’est normal : je ne gère pas les ennemis, ni les changements de couleur, ni même le boost. Bref, c’est pas le niveau argent …

Cela dit, mon robot est bien plus mauvais que simplement parce qu’il n’implémente pas ces fonctionnalités. Ce qui le rend vraiment mauvais, c’est qu’il privilégie l’accessoire à l’essentiel. Parce que dans ce jeu, il y a deux choses essentielles :

  1. Survivre à l’adversaire
  2. Manger les grosses pilules

Et mon code n’essaye de faire aucun des deux … Bon, c’est con. Et, pire que tout, il n’est même pas performant, sans doute parce que le pavage du plan est assez consommateur en temps. Bref, la prochaine fois que je voudrais m’y mettre, je pense que je suis bon pour … supprimer tout le code existant et tout refaire, tout simplement. J’ai donc appris un certain nombre de choses. La plus importante étant que faire du code performant en Rust … c’est pas facile du tout. Lisez donc tranquillement cet article Moves, copies and clones in Rust, et vous comprendrez que l’impact de la sécurité mémoire sur le code écrit est loin d’être négligeable. Et je trouve ce problème assez … stimulant (même si ça me donne parfois l’impression d’avancer avec un boulet au pied).

On fait comment une conception ?

Suite à mon précédent article un poil critique sur la revue de code, j’ai eu droit à une question intéressante de la part de mon collègue Douglas

La première chose à noter dans cette question, c’est l’insistance sur le fait que les développeurs ne connaissent pas forcément le produit sur lequel ils travaillent. Et c’est parfaitement vrai.

Donc, ça veut dire quoi « concevoir un développement » ? Il s’agit tout simplement de jouer, pour un développement particulier, le rôle de l’architecte. Et là, je n’aide personne, puisque le rôle de l’architecte est particulièrement flou dans le monde du logiciel. Néanmoins, pour une fois, je pense que la définition de Grady Booch est appropriée :

Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.

Grady Booch – On design (voir aussi Software Architecture and Related Concerns)

Donc, quand on joue le rôle d’architecte pour un développement, c’est-à-dire qu’on le conçoit, on doit se poser les questions concernant les changements significatifs qu’on va apporter au système. Et pour revenir à la question de Douglas, c’est une excellente façon de découvrir le système et de le comprendre. Autrement dit, je propose d’utiliser ces phases de conception pour prendre le temps de découvrir ce qu’on va modifier.

Mais comment rendre cette connaissance partageable ? D’abord, via un support commun. Et si les issues des bugtrackers marchent bien pour discuter de petites modifications, je trouve que, pour les gros développements, il vaut parfois mieux créer un vrai document de conception qu’on mettra avec la documentation d’architecture – dans la section ADR. Sauf que j’aurais tendance à ne pas formaliser mon ADR aussi simplement que ce que proposent les différents modèles. Non, à titre personnel, j’aurais plutôt tendance à présenter le problème, puis la description de la solution en reprenant justement le plan de l’agile architecture documentation. Parce qu’il permet précisément de segmenter le gros problème en ses différentes facettes.

Typiquement, une grosse fonctionnalité, une qui requiert une documentation spécifique, va avoir des impacts sur différents éléments du logiciel : l’architecture, les donnée,s le déploiement. Et ce modèle de document couvre correctement ces différentes questions, comme je l’ai déjà écrit. Qui plus est, il permet facilement l’amélioration collaborative : un premier rédacteur peut lancer ses idées, et les voir améliorées par un second rédacteur.

Ce qui permet quelque chose que je trouve de plus en plus souhaitable, aussi bien organisationnellement que techniquement : remplacer le synchrone par l’asynchrone via un support permanent, et constamment amélioré.

Pour l’écrire autrement, ce que je propose est assez simple : quand vous lancez un nouveau développement, demandez à un nouvel arrivant d’en faire la conception en suivant le modèle de l’agile architecture documentation, en commençant par un simple commentaire dans le bug tracker puis, si il s’avère que la fonctionnalité est trop importante, dans un document que vous placerez dans vos ADR. Et relisez ce qu’il produit avant de lancer le développement.

Pou bien démarrer Codingame en Rust …

La semaine prochaine, c’est le spring challenge !

Et comme l’année dernière, je vais essayer de le faire en Rust (un poil poussé par des collègues).

Mais contrairement à l’année dernière, j’essaye de préparer ma participation histoire de ne pas me faire avoir. Donc, voici une checklist de quelques détails utiles

  • Créer le projet cargo avec cargo init --lib . (pour créer une bibliothèque plutôt qu’un binaire). Tout le code sera dans le fichier lib.rs parce que je n’ai pas encore trouvé la bonne façon d’utiliser include!(...) pour avoir plusieurs fichiers.
  • Dans le dossier tests, créer un fichier design_tests.rs et un fichier integration_tests.rs
  • Aller chercher dans target/debug/deps les exécutables qui doivent s’appeler design_tests_{un hash pourri}.exe et integration_tests{un autre hash pourri}.rs pour créer les configurations de debug de VSCode
  • Le code doit avoir à peu près la forme suivante
    • Je lis les entrées
    • Je calcule mes sorties
    • IMPORTANT j’appelle la méthode qui génère le code du test d’ntégration
    • Et enfin je retourne ma sorte

Et avec ça, je devrais pouvoir coder assez rapidement, même si ça n’est pas automatique que ce que j’avais en Java.

J’ai été rançonné !

Il y a quelques années, j’avais un NAS D-Link qui avait une fâcheuse tendance à cramer les disques durs que je mettais dedans au bout d’un moment. Ca m’ai aidé à comprendre les problèmes classiques liés au stockage de données. Mais au bout d’un moment, j’en ai eu marre et je l’ai remplacé par un NAS QNAP. QNAP, c’est quand même une marque à laquelle on peut faire confiance. Le matériel est de qualité, et ils fournissent un ensemble de logiciels facilitant l’exploitation du matériel. Dans ces logiciels, il y a même un outil qui s’appelle MyQNAPCloud qui permet d’accéder au contenu du NAS à distance … Mais on y reviendra.

J’étais donc très content de ce matériel, jusqu’à hier soir …

En me connectant à mon NAS, je découvre un curieux fichier !!!READ_ME.txt dans le dossier que jexplore. En allant voir dans un autre dossier, curieusement, je découvre le même fichier. Et là, j’ouvre le fichier qui révèle ce contenu

[~] # cat /share/CACHEDEV1_DATA/lost+found/\!\!\!READ_ME.txt
!!! All your files have been encrypted !!!

All your files were encrypted using a private and unique key generated for the computer. This key is stored in our server and the only way to receive your key and decrypt your files is making a Bitcoin payment.

To purchase your key and decrypt your files, please follow these steps:

1. Dowload the Tor Browser at "https://www.torproject.org/". If you need help, please Google for "access onion page".

2. Visit the following pages with the Tor Browser:

gvka2m4qt5fod2fltkjmdk4gxh5oxemhpgmnmtjptms6fkgfzdd62tad.onion

3. Enter your Client Key:

hpZ1wHUqy37yATr+BV6CyOVLFFpkT602gXTya/Cr4TZTlAv4pqYziNRFhHNNuZ1wJGYarEnQ/63IfrPfEJ3+sHzYJ48vds8VXb+M0mCu+BdTEtDg1mH5tAs75YkpTkCJwOzzVH+A9lvNlvhy3qPa0RqetiGZkNEcmO0BLTmui3QdHLnKpNcEiGDwoO8EpWLl491RfdGOTLQNnA49+pLHo1m7GZZTu4GiWGOXUNJrhb7upSVWPC1kCOWetpM40HVA34UoMNUysAvg4nNuYe9y8TK0sNFaoKeYHJckRzX/OaB/onC6Y9FlqgXJHeAYHCrsAs5LUibvvsddF5dtllJ1qA==

Et là, j’ai immédiatement eu deux réflexes.

  • enculé
  • éteindre le NAS

Après avoir un peu réfléchi, je relance le NAS et découvre avec stupeur et horreur que tous les fichiers ont hérité d’un joli suffixe .7z. Je lance alors une recherche internet, qui m’emmène assez rapidement chez bleepingcomputer. Et cette lecture-là fait bien mal : il semblerait bien que des pirates aient réussi à exploiter les failles de MyQNAPCloud pour venir installer un ransomware chez tous les possesseurs de NAS QNAP qui utilisent ce service. Et comme j’ai éteins le NAS, je ne peux pas utiliser l’astuce mentionnée dans l’article qui est de ne pas redémarrer, pour retrouver la clé de chiffrement dans un log que les pirates laissent sur la machine. Bref, je suis tout seul dans la merde.

La soirée se passe dans une espèce de panique foireuse, en essayant de faire dans ma tête la liste de ce que j’ai perdu, jusqu’à ce que je me connecte à ce NAS avec VLC, en UPnP. En effet, celui-ci me montre que toutes les vidéos disponibles sur ma machine sont toujours accessibles. C’est bizarre … En y regardant de plus près, je constate que les gros fichiers (vidéos, images disques, gros fichiers zip) sont intacts, et que seuls les petits fichiers (mp3, .doc, …) ont été chiffrés.

Au réveil, ce matin, j’ai eu le temps de réfléchir et de sortir l’arme secrète du stockage de données : la règle du 3-2-1. Bon, en vérité, je n’y suis pas. MAIS, je fais régulièrement des backups du contenu de mon NAS sur des disques qui sont stockés à la cave, et qui contiennent une version avec moins de trois mois de retard de ce que contient mon NAS. Donc, en combinant cette sauvegarde à long terme et les fichiers que je peux retrouver sur les ordinateurs de la maison (typiquement, les photos des trois dernières années sont toutes sur l’ordinateur de ma femme), j’arrive à retrouver tous les fichiers de mon NAS. Et ça soulage terriblement de me dire que les sales pirates peuvent s’asseoir sur ces 500 $.

Parce que maintenant, il ne faut plus faire que deux choses

  • Remonter correctement le contenu de mon NAS
  • Améliorer la sécurité de ce stockage.

Et évidement, le second point est le plus difficile, surtout pour un amateur comme moi.

Néanmoins, la première étage est évidement de désactiver complètement MyQNAPCloud, qui a été un vecteur d’attaque aussi évident qu’inutile (en tout, j’ai dû m’en servir … 3 fois). Ensuite, je me suis rendu compte que MyQNAPCloud utilisait UPnP-IGD pour ouvrir tranquillement des ports dans ma freebox. Donc, j’ai également désactivé l’option UPnP-IGD dans la freebox, pour être sûr que le NAS soit aussi séparé du web qu’il est possible de l’être dans un réseau domestique. Et enfin, j’ai ajouté dans mon calendrier un rendez-vous mensuel pour sauvegarder toutes les données de mon NAS. Avec ça, je serai un peu plus à l’aise la prochaine fois qu’un problème arrivera.

Parce que quand même, je suis bien content d’avoir eu ces sauvegardes qui m’ont évité de perdre beaucoup plus.

Mais la revue de code, ça sert à rien ?

Cette semaine, j’ai vu passer plusieurs messages au sujet de la revue de code, qui fait partie des pratiques essentielles de l’artisanat logiciel tel qu’il est promu.

Tout a commencé par un superbe article par Jessica Kerr : Those Pesky Pull Requests Reviews. Elle revient dans cet article sur les revues de code des pull requests, et de leur imapct potentiel sur cette équipe.

Ca m’a fait réagir

Et j’ai été mis au défi de détailler mon propos

Ce que je vais tenter ici.

Pour ceux qui n’ont jamais pratiqué, les pull requests sont le moyen chez GitHub d’intégrer du code d’une branche dans la branche principale. Et la revue de code, c’est une relecture par un développeur du code écrit par un autre développeur de l’équipe. L’objectif théorique de la revue de code est de permettre à un développeur de s’améliorer grâce à la critique constructive de ses collègues. En quelque sorte, ça apporte au développeur un côté auteur, avec les autres développeurs jouant le rôle des éditeurs dans la littérature : permettre à l’artefact produit d’être aussi bon qu’il est possible de l’être, en correspondant au style de l’équipe.

Et quelque part, une partie de la difficulté de la revue de code tient à ce changement de rôle : passer de celui de constructeur d’une solution technique à critique stylistique n’est humainement pas facile, et le contexte des projets aide rarement. Parce que dans un projet, le facteur temps, s’il n’est pas essentiel, est souvent important. Et pousser un collègue a améliorer sa construction stylistique est rarement facile quand on arrive après la bataille (mais j’y reviendrai). Ca explique en partie le peu d’attrait que j’ai pour les revues de code, et que Jessica explique fort bien : réaliser une revue de code, ça implique de se plonger dans le code à relire. De s’y plonger … totalement, en fait. C’est-à-dire comprendre l’objectif fonctionnel et les contraintes techniques qui ont mené à la création de ce code. Et ça n’est que le début ! Parce qu’il faut ensuite comprendre l’intention du développeur, la manière qu’il a eu de coder cette solution. Et le pire, c’est de se placer au bon niveau de jugement : une revue de code qui demande au codeur de tout recommencer pour satisfaire au souhait « stylistique » du relecteur n’est pas une revue, mais une démolition. Et je ne vais pas parler de tout le côté humain : l’auteur du code est forcément impliqué émotionnellement avec ce qu’il a produit. Et même les mots magiques comme « c’est ton code tant qu’il n’est que sur ta machine. Et quand entre dans git/svn/pijul/whatever, il n’est plus ton code, mais celui de l’équipe » ne suffisent pas, parce que les relecteurs auront tendance à poser les questions qui détendent comme « mais pourquoi tu as fait ça ».

A mon avis, tout ces éléments font de la revue de code une solution inadaptée à un vrai problème qui est de maintenir la cohérence d’une base de code.

Et la solution de Jessica, de faire des séances de refactoring en groupe, ne me paraît pas mieux.

Parce que ces deux solutions au problème de cohérence arrivent en fait au mauvais moment. En effet, elles arrivent après que le code a été écrit. Autrement dit, on demande à quelqu’un qui est allé quelque part d’aller ailleurs, bref de refaire du travail. Et ce nouveau travail, qui apparaît magiquement une fois le code écrit, en est d’autant plus frustrant.

alors que faire ?

D’expérience, je pense qu’il faut remplacer la revue de code par la revue de conception.

C’est-à-dire demander d’abord aux développeurs de définir comment ils vont résoudre un problème en écrivant le plan de leur solution technique. Et ensuite de relire et de commenter cette conception. D’expérience, discuter de la solution avant de l’implémenter dans le code permet une discussion plus créative, parce que le codeur n’a pas la fameuse aversion à la perte liée au fait que le code, lors de la revue de code, a été écrit. Par ailleurs, on évite peut-être le plus gros écueil de la revue de code, dont je n’ai même pas parlé jusqu’à présent : la loi de la futilité. Vous savez, ce truc qui fait que l’équipe de développement va passer deux heures à passer d’une modification de 5 lignes, mais 5 minutes à parler d’une modification de 20.000 lignes, tout simplement parce que personne n’aura fait l’effort de relire ce gros paquet de code. Je sais bien que certaines équipes font des efforts désespérants pour éviter les grosses modifications de code, justement pour permettre aux développeurs de relire ces modifications. Donc, en faisant de la revue de conception, on va éviter cet effet. Parce qu’une modification simple ne présente pas d’intérêt en terme de la conception, et que la conception sera donc triviale. En revanche, une modification plus complexe nécessitera une vraie réflexion préalable, qui sera d’autant plus importante que les composants impliqués seront nombreux.

Il y a en revanche une vraie difficulté à faire la revue de conception … C’est évidement que les développeurs doivent réfléchir avant de coder. Franchement, j’ai moi-même eu parfois du mal à me retenir de plonger dans mon IDE. Mais ce temps a toujours été bien investi. Parce qu’il m’a permis d’appréhender l’ensemble des impacts d’une modification avant de l’attaquer. Et que cette appréhension m’a souvent aidé à décomposer correctement la solution, pour faciliter les composants à développer ou faire évoluer.

Autrement dit, et pour conclure, si vous n’aimez pas la revue de code … je suis bien d’accord avec vous. Et je pense sincèrement que vous devriez lui préférer la revue de conception (qui s’applique aussi bien à la correction de bugs qu’au développement de nouvelles fonctionnalités).

Rétrospective

Il y a à peu près un an, le gouvernement français décidait le premier confinement suite à l’épidémie de coronavirus (je précise au cas où quelqu’un l’ignore). Et je me suis dit que les choses se sont suffisamment calmées (disons plutôt que l’anormal est devenu suffisamment normal) pour que je puisse me permettre de faire l’exercice d’une rétrospective de cette année particulière (et en fait particulièrement chiante). Mais d’abord, un poil de mon histoire.

Avant le premier confinement, j’étais directeur technique d’une agence de Zenika, en mission d’architecte transverse dans une équipe d’une vingtaine de personnes. La mission se passait assez bien, en revanche le rôle de directeur technique était plutôt plus compliqué que ce que je croyais, à cause d’un désengagement croissant (mais j’en reparlerai). Et puis, au premier confinement, tout s’est arrêté. La mission a été arrêtée par le client (qui dans le bâtiment où je travaillais à l’époque a arrêté toutes les missions de développement). Et j’ai été mis au chômage partiel pour des raisons compréhensibles. J’ai alors passé le printemps sans aucune activité professionnelle, avant de reprendre tout doucement avec une journée par semaine de direction technique. Pendant cette journée, j’ai tenté de maintenir un lien avec les consultants, tout autant confinés que moi. Quelque part, ça a été une nouveauté pour moi, parce que le fait de contacter chaque consultant pour lui demander comment il vivait le confinement était vraiment un travail social, évidement pas ma compétence la plus développée à priori. Fin août, j’ai également repris une mission dans un contexte très différent d’archéologie logicielle à temps plein, donc sans avoir vraiment la possibilité de continuer mon rôle de directeur technique. Et depuis, les choses avancent en télétravail permanent.

Qu’est-ce qui a bien marché ?

Je suis plutôt surpris d’avoir aussi bien vécu la transition au télétravail : je ne suis absolument pas gêné par le fait de ne pas voir les gens. Je dois remercier pour ça la pratique de l’open-source, qui est déjà une forme de télétravail très avancée.

Je suis également assez content d’avoir pu écrire, pendant le premier confinement, une série d’articles sur l’architecture agile, qui m’a permis de poser un certain nombre d’idées élaborées pendant mes missions. Et dans la même veine, ça m’a donné le temps de lancer agile-architecture-documentation-system, que j’ai utilisé dans ma mission avec beaucoup de plaisir.

D’une manière un peu plus vaste, ça a été aussi l’occasion pour moi de voir certains pans de mon entreprise se réinventer avec beaucoup de talent et d’envie (et parfois, ça fait rêver).

Qu’est-ce qui n’a pas marché ?

D’une façon assez évidente pour ceux qui y travaillent, le lien social qu’on a essayé de maintenir avec les consultants chez Zenika a disparu. J’y vois plusieurs raisons.

La première est assez simple : loin des yeux, loin du coeur. Parce que pour un employé d’une société de service, qui travaille donc quotidiennement dans une autre entreprise, garder un lien avec ses collègues a moins d’intérêt, moins de sens que de maintenir un lien avec les collègues de mission. Chez Zenika, l’astuce traditionnelle pour maintenir le lien consistait à attirer les consultants par tous les moyens …

Par des événements techniques bien sûr

Mais aussi du vrai team-building

Et figurez-vous que c’est après cette super séance de hockey-roller que j’ai commencé à vraiment avoir mal au dos

Et même grâce à l’appel du ventre

Et si vous y réfléchissez un poil, dans ce contexte épidémique où on ne sait pas si on sera confiné demain, plus aucune de ces méthodes n’est applicable. Autrement dit, l’outillage classique d’une entreprise de conseil n’est plus accessible maintenant, et risque fort de ne plus jamais être accessible, puisque l’un des impacts les plus évidents de l’épidémie est le changement de paradigme culturel avec la culture du télétravail.

Bref, aujourd’hui, le lien avec les consultants est malheureusement redevenu un lien d’ordre contractuel : Zenika paye des gens pour accomplir des missions chez ses clients, et ces gens reçoivent un salaire Si on y réfléchit bien, il n’existe plus trop de différence avec des consultants indépendants pour lesquels Zenika serait un intermédiaire offrant un bon catalogue de mission, et l’assurance d’être payé même en-dehors des missions … Et c’est triste.

Pour le dire autrement, si les valeurs de Zenika sont la transparence, le partage, et la convivialité, la disparition de cette dernière a détruit la capacité de l’entreprise à exprimer les deux premières. Alors, comment faire ?

Comment faire mieux ?

Plus exactement, comment m’adapter à ce contexte transformé ?

Pendant cette année, j’ai essayé de maintenir ce fameux lien sans avoir vraiment d’autre objectif que de parler aux gens. Ca c’est révélé assez inutile. Je pense maintenant qu’il vaut mieux aller de l’avant, et voir ce que ça produit. Mais ça veut dire quoi aller de l’avant ? Ca veut dire qu’il serait bien que j’utilise mon temps de directeur technique pour produire du contenu mémorable, et que cette production de contenu incite mes collègues à agir, attirés par l’exemple. Et bien sûr, le fait que cet article soit public est une partie de ce plan de communication. Mais à part cet article, c’est quoi du contenu mémorable ?

Eh bien par exemple une présentation plus poussée de C4, ainsi que des composants additionnels pour faciliter la vie de l’architecte au maximum. Ca peut aussi être une explication d’un usage sympa de la reconnaissance d’image dans un plugin Keepass. Ca peut être enfin l’utilisation de Mindustry comme support de présentation, et d’expériences, sur l’informatique d’entreprise. Et encore d’autres idées très chouettes.

Proust

J’offre ici une idée à celui qui souhaitera l’implémenter … même si j’aimerai bien essayer prochainement.

J’ai parlé récemment de la réification de la stupidité. Et j’ai réfléchi par ailleurs à ce que pourrait être un réseau social limitant ça, et faisant plutôt, pour une foi, une arme de l’intelligence. Je vais donc vous faire ma proposition ici. Une proposition d’abord basée sur une conviction : le texte est un bon moyen de communiquer des idées, bien meilleur que l’audio ou que la vidéo. Par ailleurs, ce qui incite à la stupidité, c’est l’envie de s’inscrire dans l’illusion de vitesse du monde contemporain. Pa conséquent, je me dis qu’une base de réseau social intéressante pourrait se baser sur ces fonctionnalités

  • D’abord, un éditeur de texte simple, utilisant le format markdown (parce qu’un peu de mise en page ne fait pas de mal) en enlevant toutefois le support des images, des vidéos et des autres médias.
  • Ensuite, un délai de publication dépendant du contenu. Je m’explique. Si l’instantanéité favorise la stupidité, pourquoi insister à répondre rapidement ? Pourquoi ne pas plutôt attendre avant d’envoyer un message, ce qui pourrait vous donner le temps d’y réfléchir. Pour favoriser ça, je propose que, dans Proust, un message reste dans la boîte d’envoi (que seul l’auteur peut lire) d’autant plus longtemps que le message est court. Et bien sûr, on ne peut répondre qu’une fois à un message donné.
  • Egalement, aucune curation du flux par un algorithme : si vous choisissez de suivre cent personnes, vous aurez intérêt à avoir du temps, parce que vous devrez lire leurs messages … tous leurs messages

Dans les fonctionnalités annexes, mais sympathiques, je me dis qu’utiliser un vrai stockage distribué pourrait faire sens, mais je n’en suis pas si sûr.

Alors ? Ca vous parle ?

Réification de la stupidité

J’ai déja parlé, je crois, de ce sujet qui me hante de plus en plus.

La réification, c’est le mot savant pour l’objectification, c’est-à-dire la réduction d’une personne à l’une de ces composantes. L’exemple canonique, c’est « une femme« , parce que c’est celui qu’ont bien fait de mettre en avant les féministes : les femmes sont bien plus souvent réduites à leur texte et, partant de là, traitées avec au minimum de la condescendance, au pire … bon, je crois que tout le monde sait à quel point l’homme minuscule est capable d’abaisser les minorités, visibles ou non. Parce que cette réification touche évidement bien d’autres catégories ethniques, physiques, spirituelles. Là aussi, les exemples ne manquent pas.

Ce dont j’aimerais parler aujourd’hui, c’est d’un cas assez spécifique.

Spécifique, mais conditionnant peut-être la mise en visibilité des autres.

Aujourd’hui, comme le titre l’indique clairement, je voudrais parler de la réification de la stupidité. C’est-à-dire l’instrumentalisation, souvent par des gens malins plutôt que sages, de la stupidité des masses. Cette réification, on la retrouve à chaque fois qu’on appelle quelqu’un à réagir avec ces tripes. Et là, je pense que vous me voyez venir … Qui aujourd’hui vous appelle à réagir, à vous indigner ? Contrairement à ce que le dernier lien indique, certainement pas un vieux résistant appelant à la solidarité, mais plutôt tous les médias, qu’ils soient de l’ancien ou du nouveau monde, qui vous proposent des solutions faciles et une égalité de parole entre partisans et opposants, quel que soit le sujet.

Evidement, en ce moment, c’est assez flagrant : les processus scientifiques sont mis à mal par des processus médiatiques au prétexte que « la science ne peut pas s’isoler dans une tour d’ivoire ». Ce qui est vrai, mais qui ne peut être le prétexte à la critique par des authentiques ignorants (président de la république compris) de mécanismes qui nécessitent la compréhension pleine et entière de concepts d’épidémiologie, de statistiques, de virologie et autres.

C’est également tout aussi flagrant lorsqu’on voit des gens qui, encore une fois n’y connaissent rien, imaginer des chiffres de consommation électrique d’équipements électroniques qui sont authentiquement délirants, et qui sont repris parce que nul ne se soucie réellement de leur provenance.

Je pourrais multiplier les exemples jusqu’à la nausée …

Et évidement, je pense que vous savez tout autant que moins d’où vient cette exploitation de la stupidité.

Et ce qui est cool, c’est que c’est plutôt bien documenté : Madmoizelle, Le Monde, et même BFMtv… tous vous parleront des ignobles réseaux sociaux qui ne font rien d’autre que manipuler le flux d’informations qui vous est présenté pour susciter chez vous un niveau d’indignation correct, qui vous poussera vers l’engagement. Et je dois dire que voir les médias traditionnels (et spécialement BFM) pointer du doigt l’algorithmisation de cette exploitation quand certains s’en sont fait une spécialité navrante est assez … triste.

Mais comment lutter contre ça ?

D’abord en refusant le flux algorithmique. Pour donner un exemple typique, j’utilise Twitter à travers Tweeltedee, qui me donne un flux RSS complet, contenant donc tous les tweets des gens que je suis. Et quand j’ai été coincé chez moi, j’ai installé twidere. Et j’ai été toute à fait surpris – et déçu – de découvrir que celui-ci utilisait le flux « optimisé par twitter » pour maximiser mon engagement. Il y avait donc moins de messages, et surtout des messages censés susciter plus de réactions de ma part. Je ne suis pas sûr que ça ait été le cas. En tout cas, j’ai vu la différence … et elle m’a déplu. Je vous recommande du coup d’avoir un flux aussi brut que possible, parce que ça vous poussera à faire vous-même la sélection des gens que vous suivez, plutôt que de laisser un algorithme choisir selon des critères définis pour optimiser certaines caractéristiques opaques.

Par ailleurs, je vous encourage à ne pas lire les messages « en direct ». C’est-à-dire à laisser un délai entre l’envoi des messages et votre lecture. Tout ce qui peut limiter la réactivité est bon à prendre.

Et puis, surtout, prenez le temps de répondre … Et de réfléchir … Et de questionner vos certitudes ainsi que vos connaissances sur le sujet mentionné avant de réagir. Des conseils beaucoup plus faciles à donner qu’à suivre … plus que le suivant d’ailleurs.

Le dernier conseil que je peux vous donner, c’est de favoriser l’émergence de l’intelligence. Dit comme ça, ça a l’air … prétentieux et facile. En vérité, c’est plus facile qu’authentiquement prétentieux. La méthode la plus efficace, c’est de répondre aux certitudes par des questions bienveillantes : ne poussez pas les gens dans leurs retranchements, ça les mets dans une position défensive qui inhibe l’intelligence. Poussez-les plutôt à approfondir leur raisonnement. Parce que c’est en explorant les limites des connaissances des autres qu’on peut les aider à augmenter ces connaissances, et peut-être à comprendre qu’il faut douter pour apprendre.

Catala

Il y a quelques temps, j’ai découvert sur Twitter le langage de programmation Catala. Et j’avais été impressioné par l’idée de créer un DSL (mais quel DSL) pour encoder un domaine législatif et y utiliser les capacités de l’informatique théorique.

Et ce matin, j’ai enfin eu le temps de regarder la présentation qu’en a fait Denis Merigoux à Lambda Lille.

Et je suis encore plus impressioné, et nourri d’idées originales (mais plus les mêmes qu’avant).

Ma première idée, à la lecture du peu d’informations que j’avais cherché, avait été de tenter d’utiliser Catala comme support à une partie de nomic. Mais, en regardant cette présentation, j’ai compris que l’objectif de Catala était avant tout d’alimenter un moteur de calcul à partir d’une description de la loi fondée sur une logique à exceptions, ce qu’illustre fort bien Denis dans sa présentation.

Et du coup, j’ai complètement changé de fusil d’épaule. Je me dis aujourd’hui qu’au-dela de fournir un moteur de calcul plus correct à la DGFIP, il est tout à fait possible de créer un « robot fiscaliste » proposant des optimisations d’impôts.

Mais une partie de moi se dit que ce serait éthiquement mal d’aider les gens à « optimiser » leurs impôts … Sauf qu’en fait, la réalité n’est pas si simple, et il faut avoir une vision politique des choses, parce qu’aucune entreprise ne peut prétendre être apolitique. Pour le dire autrement, je pense sincèrement que le fait que le droit fiscal soit rempli d’exceptions plus ou moins curieuses est une forme de clientélisme qui mérite d’être exposée plus clairement (regardez par exemple cette liste de niches fiscales, certaines sont … curieuses). Et comment mieux exposer ça qu’en traçant clairement, comme le permet Catala, une optimisation d’impôt au texte de lui la permettant ?

Je vais donc mettre cette idée à côté de Proust, dont je vous parlerai prochainement.

Numérique responsable

Il y a quelques temps, mes collègues rennais ont participé à la rédaction d’un numéro hors-série de Kaizen consacré au numérique responsable.

Et devinez quoi ? J’ai pris le temps de lire ces 132 pages d’articles de 4 pages sur des sujets variés, mais toujours autour du même thème, qui est évidement celui du numérique responsable (dingue, hein). En l’occurrence, le magazine parle beaucoup d’écologie et de consommation de ressources et d’énergie, et un peu de responsabilité sociale ou éthique. Et c’est bien comme ça. Il y a par ailleurs plusieurs chiffres marquants : 90% des rejets de gaz à effets de serre sont liés à la fabrication des matériels, et seuls 10% concernent leur utilisation. Au début, cette répartition semble folle … Et elle devient d’un coup moins dingue quand on sait combien de métaux et terres rares sont utilisées pour fabriquer un ordinateur ou, pire encore, un smartphone. Ce qui pousse à un constat, également fait sur IFTTD avec Raphaël Lemaire : pour construire un logiciel qui soit raisonnablement correct d’un point de vue écologique, il faut avant tout ne pas pousser les utilisateurs à renouveler leur matériel. Ca implique de ne pas sauter sur les dernières nouveautés à la mode, mais aussi de s’intéresser à la performance de l’application en tant que fonctionnalité essentielle.

Et ce qui est bien avec cette lecture, c’est que j’ai pu l’aborder avec un oeil critique assez intéressant. Parce qu’il y a certaines choses qui m’ont chagriné dans ce magazine. D’abord le fait que certains des interviewés ont une hiérarchie des usages qui m’a un peu déplu : utiliser un ordinateur pour travailler, ok, mais pour se distraire, pouah ! Ensuite un élément d’ordre conceptuel sur la définition de ce qu’est l’écologie. Parce que si il y a bien un terme galvaudé aujourd’hui, c’est celui-là. Et pendant cette lecture, j’ai distingué au moins trois sens.

  • L’écologie scientifique, qui est l’étude des interactions entre organismes et dont on entend trop peu parler.
  • L’écologie politique, qui est parfois un peu confuse dans ses objectifs, ses moyens et sa vision mais qui cherche globalement à remettre la planète au coeur de la politique, si j’ai bien compris
  • L’écologie technique, qui est l’application de techniques et de méthodes industrielles dans l’objectif de diminuer l’impact sur le réchauffement climatique

Et en fait, la confusion entre ces trois sens apparaît à la lecture.

Un autre inconvénient de cette lecture est qu’à mon avis, la bataille des chiffres continue entre les différents lobbies. Quand j’entends par exemple que le numérique produit plus de gaz à effets de serre que l’aviation … j’ai des doutes très sérieux. Et d’un autre côté, chaque transaction bitcoin consomme autant d’électricité que l’alimentation d’une ville entière. Donc il y a là-dedans une réalité mesurable, qui mériterait d’être trouvée. Mais il y a tellement d’intérêts politiques ou économiques que la vérité sera difficilement trouvable. Ca n’est pas un appel au complotisme en mode « on nous cache tout », mais plus le constat que si l’écologie s’envisage désormais comme une force politique, elle met nécessairement en place une opposition, ou plutôt plusieurs oppositions, qui vont rendre les débats sur ces sujet fascinants pour les années à venir.

Et je me réjouis de voir que certains collègues participent avec autant d’implication à ce débat, dans une publication de cette qualité.