Côté écriture #
Si tout se passe comme prévu, je devrais exposer le week-end du 7 Juin au Printemps des Viennes, à Troyes.
La Voie Verte des Viennes, c’est un joli chemin boisé qui longe les deux Viennes et relie Troyes à Rivière de Corps (Oui, il y a un bled dans l’Aube qui s’appelle Rivière de Corps), en passant par Saint-André-les-Vergers et Sainte-Savine. Chaque année, autour du mois de Juin, l’association les Amis de la coulée verte organise le Printemps des Viennes, un week-end durant lequel il est possible de découvrir des associations (certaines actives à l’échelle nationale, comme la LPO, ainsi que d’autres petites associations très locales) et des peintres du coin. Cette année, les Maraîchers des Viennes, chez qui j’achète mes légumes bio sortis des serres à quelques centaines de mètres de chez moi, m’ont invitée à partager leur stand.
Je vous proposerai la version papier de Suzuha, ma nouvelle le Don de l’Hiver (un peu hors saison, mais tant pis), mes illustrations de la Lionne des Sables et du Renard Endormi, ainsi qu’un nouveau type de goodies qui me trotte dans la tête depuis un certain temps :p
Côté web #
Je suis consultante. Ces derniers temps, je passe plus de temps à auditer des bases de code qu’à coder. Mon travail, c’est d’analyser les projets de mes clients pour en déduire quelle est la meilleure marche à suivre pour atteindre un objectif qu’ils se sont fixé.
Assez souvent, il s’agit de maintenance. Beaucoup d’entreprises ont du mal à intégrer la maintenance technique de leur application dans leurs processus. Comme la valeur n’est pas aussi visuelle qu’une nouvelle fonctionnalité, les devs peinent parfois à convaincre le management du bien-fondé des tâches de maintenance. Surtout, beaucoup de devs n’ont pas la fibre de la gestion de projet et ne voient tout simplement pas que c’est leur rôle d’expliquer à leur manager qu’il faut intégrer ce travail dans les roadmaps. Résultat : des apps lentes et difficiles à maintenir, désalignées des standards du web, qui ont plusieurs versions majeures de retard dans leurs dépendances, et des équipes qui ne savent plus par où commencer pour moderniser leur stack, ou même s’il ne vaudrait pas mieux tout recommencer avec un autre framework. Mon travail, c’est de leur ouvrir le meilleur chemin possible et de leur proposer un plan d’action pour les rassurer et leur redonner de la visibilité sur où ils sont et où ils vont.
Dans ma carrière, j’ai vu trois méthodes pour intégrer la maintenance de la stack technique dans le développement :
-
L’équipe dédiée : La méthode la plus courante. Une équipe technique dédiée sert d’équipe référente pour tout ce qui touche à l’expérience développeur (DX). Cette équipe gère les dépendances, l’intégration continue (CI), surveille les performances, le temps que mettent les tests, etc. Elle est à l’écoute des devs qui font de la fonctionnalité, et développe des outils pour faciliter leur travail sur le projet. Cette équipe doit comporter suffisamment de personnes pour avoir la force de frappe d’implémenter les changements, selon la taille de l’application et du reste des équipes. L’approche est efficace, mais représente donc un certain investissement.
-
Le squad rotatif : Cette méthode est moins courante, mais fonctionne bien dans certaines entreprises qui l’utilisent. Plutôt que d’avoir une équipe dédiée, vous avez un·e seul·e lead technique qui prépare et priorise les tâches techniques dont le projet a besoin. Simplement, impossible de les effectuer seul·e, il faut une équipe. Cette équipe, on la construit en prenant un·e dev dans chaque équipe qui fait de la fonctionnalité, et on forme ainsi un squad temporaire pour le temps nécessaire. Par exemple, mettons qu’une app possède six modules fonctionnels gérés par six équipes. Une nouvelle bonne pratique est alors recommandée par le linter, mais le code actuel ne l’implémente pas, ce qui génère une erreur de lint dans 120 fichiers différents. Mettons qu’un·e dev seul·e peut corriger trois occurrences de l’erreur par jour. Le système de squad rotatif permet au lead technique d’avoir sous la main six devs venant de chacune des six équipes. Iel peut en mettre quatre sur l’erreur de lint pendant deux semaines, pendant que les deux derniers s’attellent à autre chose. Au bout des deux semaines, ce squad sera remplacé par d’autres devs qui seront affecté·es aux tâches techniques suivantes ou viendront renforcer celles toujours en cours, etc. Cette approche permet un bon niveau de transfert de connaissances au sein de la base de code, mais demande une bonne organisation et des managers qui jouent le jeu.
-
Le “20% time” : Pour chaque dev, 20% du temps est alloué au travail technique sous la forme d’un jour par semaine. C’est l’une des méthodes les plus simples et intuitives à mettre en place. Je vais le dire clairement : ça ne marche pas. En fait, ça marche pour de la maintenance de dépendances relativement basique, mais ça ne permet pas l’innovation et le traitement de problématiques techniques plus profondes. Avoir une seule journée ne permet pas de se concentrer suffisamment longtemps, il faut des semaines et des semaines pour voir le début d’une réalisation importante, et, la petite crotte sur la bouse de vache : les devs sont souvent désemparé·es. Dans cette approche, les devs sont souvent livré·es à eux-mêmes, seul·es, encouragé·es d’un simple « Vas-y, fais des trucs cool », sans vision des besoins techniques sur l’ensemble du projet. Alors le 20% time se délite de lui-même, avec un taux de participation faible et une majorité de devs qui préfèrent continuer à développer la fonctionnalité qu’iels avaient commencé la veille.
Côté culture #
Je n’en avais pas parlé précédemment, mais il y a quelque temps j’ai vu Zootopie 2. Je l’ai trouvé plutôt sympathique, et sans doute meilleur que le premier, même si je ne me rappelle pas trop du premier.
On a reproché au premier Zootopie d’avoir renversé la métaphore du système d’oppression. Zootopie, c’est une ville où tous les animaux vivent en harmonie. Les prédateurs mènent une vie pacifique aux côtés de leurs proies sans les boulotter. Mais sous cette bannière idyllique, les oppressions existent, et on peut discerner une sorte de hiérarchie “gros prédateur > grosse proie > petit prédateur > petite proie”. Or dans le premier film, les prédateurs, victimes d’un complot, redeviennent de terrifiantes créatures avides de viande de lapin (en gros). La population va donc commencer à les pointer du doigt et en faire un groupe opprimé. Sauf que… à l’origine, la peur des prédateurs est rationelle. Il est pour le moins curieux de dénoncer des oppressions infondées avec un scénario qui victimise le groupe originellement au sommet de la hiérarchie… J’avais bien aimé ce film et je l’avais trouvé divertissant, mais cette critique me paraît valide.
J’ai trouvé que le deuxième film ne posait pas ce problème et remettait plutôt les choses en ordre. La relation entre les deux héros n’est pas développée sous l’angle prédateur-proie, et les groupes antagonistes sont des groupes carnivores. Bref, si le premier film vous a hérissé le poil pour les raisons mentionnées ci-dessus, il me semble que vous pouvez quand même tenter ce film-là.