PROJET AUTOBLOG


Marien Fressinaud

Site original : Marien Fressinaud

⇐ retour index

Mise à jour

Mise à jour de la base de données, veuillez patienter...

Concevoir les logiciels de demain

mardi 16 avril 2019 à 11:05

J’ai donné le dimanche 7 avril dernier une conférence à l’occasion des Journées du Logiciel Libre (JdLL). L’article qui suit correspond à la transcription de ce que j’y ai raconté. Je me proposais de poser des réflexions autour de la conception des logiciels de « demain », en intégrant à la fois des considérations environementales et d’impact utilisateurice. Loin d’être exhaustive, cette présentation était surtout l’occasion de jeter quelques pistes à défricher ensuite ensemble. Le format lui-même tentait de faire intervenir les personnes venues m’écouter. Sur ce point j’ai été particulièrement satisfait que les conversations se déroulent de manière aussi fluide, sans accaparement de la parole ; vraiment merci aux personnes qui étaient là ! J’ignore si elles sont reparties avec ce qu’elles étaient venues chercher, c’était finalement assez éloigné de ce que j’avais en tête au moment de proposer le sujet. J’ai en tout cas pris plaisir à donner cette conférence (même pas stressé !) Pour bien faire, il faudrait maintenant que je creuse chaque sujet dans des articles spécifiques, il y a de quoi faire.

La transcription est plus complète que ce que j’ai raconté à l’oral vu que j’ai nécessairement oublié de dire des choses. Je l’ai aussi annotée pour redonner du contexte lorsque nécessaire. Les quelques diapos sont accessibles en suivant ce lien.


Introduction

Je vais commencer par vous poser une question : qui ici s’est déjà posé la question d’adopter un mode de vie numérique plus en accord avec la planète ?

Note : tout le monde ou presque a levé la main alors que la salle était pleine. Très content de cette réponse même si du coup ça a augmenté mon syndrome de l’imposteur. Ça a toutefois bien aidé à alimenter les discussions qui ont suivi.

Si je vous pose la question, c’est parce qu’en préparant cette conférence, je me suis rendu compte que je n’arriverais jamais à aborder tous les sujets qui pourraient l’être. Je risque de perdre des gens, et je risque surtout de ne pas répondre aux attentes de celleux qui se sont posées plus de questions que moi. Alors j’aimerais faire de cette conférence un espace participatif en tentant un format un peu particulier. Je vais introduire les deux parties de notre conférence pendant 10 à 15 minutes chacune, et à la fin de chaque partie, je vous poserai une question pour ouvrir le sujet. Le but étant de venir compléter ce que j’aurais dit, ou de débattre selon les envies. Ce que je vais raconter paraîtra sûrement incomplet aux yeux de certaines personnes, mon but n’est pas forcément de rentrer dans le détail mais de défricher un certain nombre de sujets… en les survolant donc.

Mon objectif est que vous repartiez avec trois éléments. Le premier, c’est que vous vous posiez la question de savoir si votre vie numérique est en accord avec vos convictions. Le deuxième, ce sont des idées, des outils pour concevoir plus simple, plus orienté « bien-être » utilisateurices. Enfin, je voudrais tracer quelques sillons de sujets que vous auriez envie de creuser, d’approfondir en sortant de cette salle.

Je vous mets un pad à disposition pour retrouver la transcription de ce que je vais raconter ainsi que les diapos. Mais je vous encourage, si vous prenez des notes, à le faire de manière collaborative sur ce pad. Si vous avez des questions, des retours à faire sur le fond comme sur la forme, allez-y. Si vous voulez partager des liens, des ressources ou si vous voulez échanger des coordonnées pour discuter de tout ça entre vous plus tard, faites-vous plaisir !

Note : personne n’avait son PC sur les genoux du coup l’idée du pad collaboratif est tombée à l’eau. Pas très grave, les gens étaient d’autant plus à l’écoute.

Moi, super-héros et développeur de sites statiques

Pour commencer, je vais vous parler de moi. Et donc aussi un peu de vous, je l’espère.

L’autre jour en trainant sur Twitter, je suis tombé sur une photo montrant un ours sur la banquise, rachétique et visiblement mal en point. Le commentaire sous la photo laissait entendre que son état était dû au réchauffement de la planète. Du coup, ni une ni deux, un sentiment de révolte m’envahit ! « Comment peut-on laisser faire ça ? » Mais l’ours n’est pas la seule raison de cette colère : chaque tweet, chaque article traitant d’inégalité, de racisme ou d’effondrement vient alimenter ce sentiment d’injustice, et par la même occasion, cette envie de vouloir tout résoudre. Ce syndrome, c’est celui du super-héros, celui qui est capable de tout remettre dans l’ordre. Nous avons tous envie d’être un super-héros pour résoudre les problèmes dans le monde. Mais notre kryptonite à nous, ce n’est pas un caillou radioactif, c’est les photos de chats « vraiment-trop-mignons ». Invariablement après une telle photo, notre colère s’estompe.

Heureusement, il y a celleux qui font. Celleux qui font pipi sous la douche pour économiser l’eau de la planète. Celleux qui éteignent la télé avant de se coucher pour sauver la banquise de ce pauvre ours famélique. Et il y a celleux qui développent des sites statiques pour réduire leur impact carbone. Alors oui, ça vous fait peut-être rire : « C’est pas comme ça qu’ils vont sauver le monde, hé ! » Mais en attendant, est-ce qu’ils et elles ne font déjà pas un peu plus que vous, en colère derrière votre écran ?

Évidemment, je vous présente des situations caricaturales, on est toutes et tous un peu des deux à la fois, et il est hors de question de confronter celleux qui font à celleux qui se révolent. Nous ne sommes pas toutes et tous égaux face à l’action politique (au sens large du terme), notamment à cause de nos inégalités face au temps, aux ressources ou à notre position sociale. Je propose que nous restions tous humble vis-à-vis de ce que l’on peut entreprendre et d’accepter que nous avons tous une part d’incohérence que nous travaillons chacun·e à notre rythme. Je suis convaincu par ailleurs (c’est donc subjectif) que ce sont nos actions individuelles (bien que parfois un peu ridicules) qui nous font avancer sur le chemin d’une action plus collective et plus efficace. C’est parce que j’ai rejoint une AMAP un jour que j’ai eu l’idée de faire une conférence participative et que demain je m’associerai peut-être à un collectif pour faire avancer les causes qui m’importent, en espérant peut-être un effet boule de neige.

Mais revenons-en à notre sujet : j’ai moi-même développé un générateur de sites statiques avec dans l’idée de faire « mieux ». Évidemment, je sens bien que c’est totalement insuffisant, mon site personnel notamment a une toute petite visibilité, quel impact pourrait-il bien avoir sur la planète ? Alors si mon site statique est insuffisant, qu’est-ce que je fais ? J’ai essayé de formaliser un peu les problèmes que le numérique me pose.

Partons de ce schéma représentant la répartition de notre empreinte carbone. On y voit notamment que notre usage du numérique possède un impact aussi important que celui de notre consommation de viande et de poisson et on peut parier sur une augmentation au moins à court terme.

schéma montrant que l’empreinte carbone des Français concernant nos achats et usage du numérique est de 1180 Kg eq CO2/an tandis que notre consommation de viande et de poisson est de
1144.

Cet empreinte est notamment due à notre façon d’acheter compulsivement du matériel et d’en changer sans réel besoin : on change de téléphone en moyenne tous les 2 ans et d’ordinateur tous les 3 à 4 ans ! Mais je laisse ce sujet à d’autres, je veux me concentrer sur le sujet du développement logiciel aujourd’hui.

Lorsqu’on cherche comment est réparti cet impact numérique, c’est la consommation de vidéos qui ressort principalement. Ainsi, selon le Shift Project, « Le visionnage d’une vidéo en ligne de dix minutes disponible dans le “Cloud” induit par exemple une consommation électrique équivalente à la consommation propre d’un smartphone sur dix jours ». Vous penserez à moi la prochaine fois que vous regarderez une vidéo de « chatons-trop-mignons » en haute définition sur Youtube !

On pourra donc commencer à nous questionner sur nos usages un par un, en commençant peut-être par regarder moins de vidéos et en qualité plus basse, le but étant à terme d’avoir un usage plus respectueux de la planète. Mais je me pose quand même une question : suis-je vraiment le fautif dans l’affaire ? Je veux dire, nous sommes tout de même des millions d’utilisateurs et utilisatrices à partager une consommation irraisonnée de vidéos en ligne et nous partagerions un même usage sans s’être jamais concerté·es ? Excusez-moi mais je flaire quand même quelque chose de louche dans l’affaire ! Est-ce que ce ne serait pas plutôt l’outil qui me pousse à l’usage ? Mais pourquoi ? Qui l’a conçu ? Dans quel but ?

Lorsque je me rends sur Youtube, c’est facile : c’est Google qui a conçu cette plateforme de divertissement. Mais moi, lorsque j’entends Google, j’ai un petit drapeau qui se lève dans la tête et qui me dit « attention, Google est l’une des plus grosses capitalisations boursières et génère la grande majorité de son chiffre d’affaire à partir de la pub ! » Et pour que la pub génère de l’argent, il faut des personnes pour la regarder. Idéalement beaucoup. Et qui reste longtemps. Est-ce que j’ai réellement consenti à regarder beaucoup de vidéos à la suite… ou est-ce Google qui m’a incité à le faire pour vendre du « temps de cerveau disponible » (comme dirait l’autre) et donc m’incite à rester sur sa plateforme ? Vous l’aurez compris, je touche du doigt un problème du capitalisme design de l’attention.

Donc non seulement il y a des usages, des logiciels qui ne respectent pas l’environnement, mais en plus ils ne respectent pas non plus leurs utilisateurices ! Est-ce qu’on ne pourrait pas y faire quelque chose ? Par exemple, si on commençait à virer cette colonne de suggestions de vidéos « qui pourraient nous intéresser » ainsi que l’enchainement automatique de vidéos ? Évidemment Youtube ne vous permet pas de le faire… mais est-ce qu’on aurait pas inventé une chose qui se nomme « le logiciel libre » ? Si je n’aime pas ce que fait telle ou telle plateforme de mon attention, alors je vais la modifier pour qu’elle me respecte, n’est-ce pas la promesse du logiciel libre ?

Nous sommes sauvé·es !

Vraiment ?

Prenons une plateforme de vidéos libre comme Peertube, et imaginons qu’il y ait au sein de Peertube un tel système de suggestions de vidéos ainsi que l’enchainement automatique de vidéos. Qui dans la salle se sent capable de modifier le code pour virer ces deux fonctionnalités ? Et en moins d’une heure (le temps que je considère comme raisonnable pour ne pas avoir l’impression de le perdre) ? Et bien je suis désolé de vous annoncer que toutes les personnes qui ont levé la main ne sont pas vraiment libre ! Ils ou elles sont dépendantes soit d’une personne externe, soit de temps et de ressources qu’elles devront dépenser de façon disproportionnée vis-à-vis du gain consenti. La liberté 1 du logiciel libre, celle qui implique que l’on peut modifier le code n’est finalement peut-être pas si bien respectée.

Note : quelques mains se sont levées dans la salle lorsque j’ai posé la première question, mais toutes se sont rabaissées lorsque j’ai précisé « en moins d’une heure ». J’ai bien conscience qu’il s’agit d’un temps arbitraire, mais j’avais à cœur de remettre en perspective le « temps disponible » que nous n’avons pas toutes et tous à disposition de manière égale.

J’ai donc posé lors de cette partie trois questions / problèmes qui se posent à moi aujourd’hui dans le numérique : mon usage du numérique respecte-t-il la planète ? Suis-je maître de mon attention lorsque j’utilise un logiciel ? Et suis-je capable de modifier ce logiciel pour qu’il respecte l’usage que je souhaite avoir de lui ?

Mais vous, quels problèmes vous pose le numérique aujourd’hui et aimeriez voir disparaître / résolu demain ?

Note : la discussion a eu tendance à dévier vers des solutions aux problèmes que j’ai soulevés. En cela le résultat de cette première question est mitigé, bien qu’il y ait eu des prises de parole vraiment pertinentes. N’ayant pas pris de notes, je ne serai pas capable de tout retranscrire ici cependant.

Cultivons notre jardin (ou une vision positive du numérique de demain)

Bien, maintenant que nous avons établi les problèmes que nous pose le numérique, on voit un peu mieux ce dont on ne veut pas… mais du coup, on veut quoi ?

Essayons pour cela de commencer par déterminer ce qui nous fait vibrer. Pour ma part, mon premier gros coup de cœur pour le numérique a été un jour d’hiver lorsque j’étais en troisième et que j’ai reçu mon premier PC à Noël. Lorsque j’ai réalisé que j’allais pouvoir avoir Internet directement dans ma chambre, je me suis tout de suite imaginé converser avec des personnes aux quatres coins du monde. C’est difficile de définir ce que j’ai ressenti mais je m’en souviens encore. Et c’était synonyme d’un numérique très positif.

Mais bon, à l’époque c’était compliqué l’informatique pour moi, on était encore en 56K avec le modem qui faisait du bruit dans le bureau de mes parents et j’étais persuadé qu’il fallait que j’installe le cédérom fourni par Orange pour que ça marche. Révélation : ça n’a jamais marché. Le temps est passé, Internet s’est fait omniprésent et me vendait de moins en moins de rêve ; une sorte de routine s’est installée.

Mais voilà qu’en 2017, avec les copains de Framasoft on lançait la campagne Contributopia. Je me souviens très bien du sentiment positif que j’ai eu lorsque Pouhiou et pyg nous ont présenté ce qu’ils avaient en tête. C’était le même sentiment que quelques années plus tôt, et ça dessinait un numérique tout aussi positif, voire plus.

Ce sont ces sentiments, ces imaginaires que j’aimerais qu’on arrive ensemble à reconstruire. Si on pouvait appuyer sur un bouton reset, il ressemblerait à quoi notre monde numérique ? Plutôt que de faire une liste détaillée qui prendrait des plombes à faire, je vais me contenter de parler de trois « zones » que j’aimerais rebatir si je devais repartir de zéro. Cette liste est donc très loin d’être exhaustive ! Notez que je vais mélanger alégrement numérique et Internet dans cette partie, c’est voulu.

Le premier point, c’est celui qui m’a fait vibrer au collège. C’est cette possibilité de pouvoir faire des voyages culturels, le cul vissé sur ma chaise et au prix d’une connexion Internet ; rencontrer son prochain sans contrainte de distance. Peut-être que ça ne fait pas rêver tout le monde, mais ça faisait rêver un garçon de 13 ans, donc pourquoi pas commencer par là ? Et de toute façon demain sera sans avion, autant commencer à changer notre façon de voyager.

Le deuxième sujet numérique qui me donne ce sentiment « wahou ! », c’est le partage des ressources et des connaissances. Vous connaissez peut-être ce petit site qui se nomme Wikipédia : il s’agit d’une encyclopédie en ligne alimentée uniquement par des bénévoles… je vous jure que ça marche ! Et tout le monde peut participer, donc même des sujets hyper spécifiques peuvent se retrouver être présentés en long et en large. Ce que j’aime, c’est ce pot commun, tout le monde contribue et tout le monde peut se servir sans léser personne. Il n’y a pas d’accaparement de la connaissance, c’est pour tout le monde.

Enfin, le troisième coin d’Internet que je trouve « beau », ce sont les zones d’information et d’entraide entre oppressé·es et personnes ayant besoin de se renseigner pour « améliorer » leur cadre de vie, pour s’organiser ou tout simplement pour discuter. L’anonymat notamment que permet Internet offre la possibilité de se dégager d’une certaine honte et de se sentir plus en confiance pour aborder certaines recherches et discussions. Les liens tissés entre les individus sur Internet sont généralement décrits comme « virtuels », mais je vous assure que ça ne l’est pas du tout. Ces liens numériques se prolongent d’ailleurs bien souvent dans la vie « réelle » (mais je préfère le terme « vie physique »).

Vous me rétorquerez alors : « ton Internet de demain il ressemble quand même vachement à celui d’aujourd’hui » et vous aurez sans doute raison. Sauf que dans celui d’aujourd’hui, ce ne sont pas ces aspects-là qui dominent. J’aimerais que les logiques de communautés prennent le pas sur les logiques individuelles en quelque sorte. Et l’élagage des usages que j’ai effectué permet de rendre le numérique plus soutenable. Mais un réseau d’entraide basé sur des vidéos en très haute qualité n’est pas forcément beaucoup plus soutenable, il faut bien évidemment se poser aussi la question de la conception en plus de celle des usages.

Alors comment on conçoit pour demain ? Quel est le secret si bien gardé de cette conférence ?

Je vous propose de partir sur une idée que j’applique de temps en temps lorsque je veux progresser dans ma pratique d’un sujet : je me pose des contraintes fortes. Ces contraintes ne sont pas des axiomes de conception qu’il faudrait appliquer coûte que coûte, mais des exercices qui doivent vous pousser à vous questionner sur des pratiques que vous auriez plus ou moins intégrées comme « normales ». Ces contraintes doivent répondre à un problème que vous cherchez à résoudre. Et ça tombe bien, on a identifié au moins trois problèmes dans la partie précédente !

Concernant l’impact environnemental tout d’abord, quel genre de contraintes peut-on imaginer ? Le poid des pages étant souvent pointé du doigt, commençons par là. Première contrainte : transformer un site ou une application pour que ses pages de fassent pas plus de 200Ko, images comprises ! Cette première contrainte devrait déjà soulever des questions : est-ce que mon fichier HTML est suffisamment simple ? Et mon fichier CSS ? Mais cette librairie JavaScript pèse déjà 200Ko, quelles implications si je dois m’en passer ? Combien d’images puis-je insérer ? Avec quelle qualité ? Et comment appliquer ça à un service de partage de photos ou de vidéos ? Quels choix de conception cela implique-t-il ? Peut-être que vous ne trouverez pas de réponse satisfaisante sans relacher légèrement la contrainte, mais ce n’est pas grave car vous aurez déjà commencé à vous poser la question et imaginer des solutions plus « simples ».

Sur l’attention de l’utilisateurice maintenant. Je rappelle que son but dans la vie n’est pas de passer son temps sur votre site ou application, il ou elle a bien d’autres chats à fouetter (mais ne faites pas ça chez vous, c’est de la maltraitance animale et c’est mal). Imaginons la contrainte suivante : au bout de 5 minutes passées (durant une journée) sur votre application, celle-ci se ferme automatiquement. Comment allez-vous la concevoir pour que l’utilisateurice fasse tout de même ce qu’elle est censée faire ? Cela pose la question de ce que doit faire votre application car il vous faut maintenant définir quelles fonctionnalités sont maintenant essentielles. Par exemple, comment appliquer cette contrainte à un réseau social ? Quels choix allez-vous faire pour que la personne qui se rend sur Twitter ou Mastodon puisse toujours lire ce qu’il ou elle l’intéresse ? Et au fait, à quoi ça doit servir un réseau social ? Faire de la veille ? se détendre ? créer des liens ? organiser des communautés ? tout à la fois ?

Enfin, concernant la maintenabilité des logiciels, comment favoriseriez-vous la possibilité pour un néophyte de rentrer dans votre code ? Exemple de contrainte : votre programme doit faire moins de 500 lignes de code. Là encore peut-être qu’il va devenir compliqué de recréer quelque chose comme un réseau social ou une plateforme de partage de vidéos, mais posez-vous les questions que cela engendre. Que doit faire mon programme ? Comment j’organise mon code ? Vous réaliserez sans doute qu’on ne peut pas faire l’impasse sur une « éducation au code » et tant mieux. Maintenant : quelles sont les actions que vous prendrez pour qu’un minimum d’éducation soit nécessaire pour au moins comprendre l’architecture de votre logiciel ? Et on voit que des tas de questions peuvent découler d’une bête question (celle de rendre votre code accessible au plus grand nombre).

On peut évidemment imaginer des tas d’autres contraintes comme limiter le temps de chargement de votre site ou application à moins de 0,5 seconde, limiter le nombre d’écrans à 2, développer une application sans aucune dépendance autres que celle du langage et de sa librairie standard ou encore limiter l’accès au réseau au strict minimum. Vous pouvez aussi les mixer, les modifier, etc. Ces contraintes vont sans doute vous paraître contre-productives par moment, voire totalement opposées à leur objectif et c’est pour ça que j’insiste sur le fait qu’il ne s’agit que de guides de conception. Le risque étant d’appliquer aveuglément ces contraintes en perdant de vue votre objectif initial.

En appliquant ces différentes contraintes, j’ai bon espoir que vos logiciels deviennent plus simples, plus respectueux d’un environnement mal en point et d’utilisateurices souvent malmené·es. In fine, ce sont vos logiciels qui deviendront plus libres. Pour rappel, ce n’est pas vraiment le logiciel qui doit être libre (lui il s’en fout, vous pouvez lui demander mais il y a peu de chances qu’il réponde), c’est son utilisateur ou utilisatrice. Alors la prochaine fois que vous concevrez un logiciel, merci de penser à sa liberté à ellui.

Et vous, quels usages vous semble prendre tout leur sens dans le numérique ? Qu’est-ce qui vous fait vibrer là-dedans ? Et comment le concevriez-vous ?

Conclusion

J’ai évoqué à un moment donné que je faisais parti de l’association Framasoft. Bien que les questions posées lors de cette conférence et les esquisses d’un monde numérique plus sobre fassent parties des réflexions qu’on mène dans l’asso et plus spécifiquement dans le cadre de notre campage Contributopia, je voulais souligner le fait que le sujet ne nous appartient pas. À partir du moment où vous vous sentez concerné·e, alors vous êtes légitime pour traiter le sujet et probablement tout aussi pertinent·e que nous. Je voulais faire ce petit aparte car il semble y avoir de plus en plus d’attentes envers l’association pour porter ces réflexions. Cette confiance nous fait certes plaisir, mais notre monde à nous (celui de demain) est émancipé et ne repose pas sur un groupe de quelques copain·ines. Alors n’hésitez surtout pas à cogiter sur tout ça dans votre coin et à lancer ensuite d’autres structures collectives pour imaginer d’autres imaginaires. C’est en les multipliant qu’on avancera !

Conception de la v8 du site

vendredi 1 mars 2019 à 13:20

Au fil des années, j’ai pris le temps d’annoncer les changements importants du site, je ne vais donc pas non plus déroger à la règle cette fois-ci. Cette huitième version (quand même) arrive presque deux ans après la dernière. C’est avant tout pour moi un retour au « fait-maison » qui était la base lorsque j’ai démarré. J’avais été lassé de maintenir des outils souvent complexes ; la cinquième version introduisait notamment une idée un peu fumeuse consistant à agréger les éléments que je partageais via 3 outils que j’avais moi-même développé…

En revenant à un outil plus simple (je vous renvoie à ma série d’articles), je reviens aussi à une idée de l’informatique qui me plaît : maîtriser (ou au moins comprendre) les outils que j’utilise.

Cet article, donc, revient sur les grandes lignes directrices que j’ai souhaitées pour cette énième version de mon site. Notez que le contenu n’est pas terminé, il manque notamment le manifeste qu’il me reste à rédiger et la liste des projets que je souhaite mettre en avant. J’envisage aussi une page « à propos » mais je ne suis pas certain de son intérêt.

Une approche pédagogique et ouverte

Si j’ai toujours tenté d’adopter une démarche pédagogique, je crois que je commence à avoir une certaine maturité sur le sujet. La série d’articles dans laquelle s’inscrit celui-ci en est la preuve la plus évidente puisque j’y explique toute la démarche qui se cache derrière ce site. Un autre exemple que j’aime bien est celui de la partie « Traitement des données » de ma page « Mentions légales » dans laquelle j’explique que malgré le fait que je ne collecte pas de données… et bien j’en collecte quand même ; j’en profite pour expliquer la raison et les circonstances.

Le côté ouverture est quant à lui illustré par les liens qui renvoient à chaque fois vers les articles qui décrivent la raison de tel ou tel paragraphe, ou pour compléter en informations. J’ai aussi insisté sur les liens renvoyant au code source. J’envisage, pour aller plus loin, d’ajouter pour chaque page des liens discrets vers les fichiers sources correspondants.

L’une des conséquences de cette approche est que cela rend le site plus verbeux. C’est voulu. Celleux qui me connaissent savent que j’écris facilement de gros pavés et cela fait partie intégrante de qui je suis, j’assume. Pour équilibrer cela, j’ai appliqué une série de bonnes pratiques de typographie pour que le contenu reste agréable à lire, notamment le principe du « triangle équilatéral du paragraphe parfait » (c’est-à-dire équilibrer la taille de la police d’écriture avec la largeur et l’espacement des lignes). Le choix de couleurs qui contrastent bien entre elles a pris un peu de temps, mais l’outil d’accessibilité intégré à Firefox a été d’une aide précieuse.

Capture d’écran qui montre que le ratio de contraste du titre de cet article avec l’arrière-plan est de 14,32

Le but de tout cela est aussi d’apposer une « patte » particulière sur mon site, pour faire en sorte que la forme du blog épouse le fond de ce que je veux promouvoir.

Navigation restreinte

Deux choses m’agacent souvent dans la navigation des sites :

Pour cette nouvelle version du site, la navigation se passe en majorité « dans le texte ». C’est-à-dire que la majorité des liens vers les autres pages sont (ou seront) contextualisés au sein du texte de la page d’accueil. Dans l’en-tête du site, seulement deux liens : l’un pour revenir à l’accueil, l’autre pour accéder au blog (qui reste le « lieu de vie » du site). Cette économie de navigation m’évite en plus le fameux menu « hamburger ».

Conscient que ce type de navigation est là encore verbeux, les différents liens sont accessibles depuis le pied de page pour avoir une vue d’ensemble du site.

Le dernier élément de navigation présent sur le site est le bouton qui apparaît en bas de la page une fois que vous l’avez faite défiler un peu et qui permet de remonter en haut de la page. Pour le créer, je me suis basé sur un article de Signal v. Noise. J’ai dû légérement adapter le code qui s’appuie sur leur cadriciel JavaScript, ce qui donne un petit script d’une dizaine de lignes. Le code CSS quant à lui est un peu plus long, mais principalement pour l’apparence.

Un thème moins bleu

Le thème de ce site a toujours été bleu, voire très bleu. Chose révolue donc puisque je suis parti sur du rouge brique (il y aura bien quelqu’un·e pour me dire que c’est orange, non ? /private-jock). Pourquoi ce rouge ? Pas de raison particulière pour le coup, ça ne transmet pas de message particulier. On pourra toujours disserter sur la signification des couleurs qui irait, dans le cas présent, à l’encontre de ce que je veux transmettre ; mon pari est que ça ne joue qu’à la marge et qu’on peut bien choisir un peu les couleurs que l’on veut tant qu’elles nous plaisent ! Si quelqu’un vient argumenter sur le fait qu’il trouve le thème agressif, je reconsidèrerai toutefois volontier mon sentiment.

La « charte » se décline ainsi :

La règle est de ne jamais superposer deux couleurs différentes, à part la couleur de contraste qui est prévue pour cela (son ratio avec les autres couleurs est suffisant pour assurer une bonne lisibilité).

Mobile avant tout

J’ai pensé le site pour fonctionner sur mobile. Même si je n’utilise plus que très peu le téléphone pour aller sur Internet, il est toujours plus agréable de naviguer sur les sites prévus pour (c’est quand même l’une des promesses des technologies web, de pouvoir être accessibles quel que soit le périphérique).

Pour cela j’ai utilisé le mode « mobile » de Firefox (le raccourci pour l’utiliser est ctrl+maj+M). J’ai commencé par faire en sorte de supporter la largeur d’écran la plus petite que je souhaitais pouvoir gérer (360 pixels), puis j’ai ajouté quelques points de « rupture » (c’est-à-dire des largeurs d’écran pour lesquelles le style doit changer). Par exemple, pour les blocs des séries sur la page de blog, les blocs sont affichés en colonne par défaut :

.blog-series {
    display: flex;
    flex-direction: column;
}
.blog-serie {
    margin-bottom: 1rem;
}

Ce qui donne :

Capture d’écran de la page principale du blog où l’on voit les blocs des séries en colonne

Mais à partir d’une largeur de 40rem (qui correspond à 640 pixels dans ce cas), on les affiche en lignes avec retour à la ligne autorisée.

@media(min-width: 40rem) {
    .blog-series {
        flex-direction: row;
        flex-wrap: wrap;
        justify-content: center;
    }
    .blog-serie {
        width: 30%;
        margin-right: .5%;
        margin-left: .5%;
    }
}

Ce qui donne donc :

Capture d’écran de la page principale du blog où l’on voit les blocs des séries qui sont passés en lignes

Mise en production imminente

Ayant suffisamment repoussé la mise en production jusque-là, j'envisage de le faire dès la semaine prochaine même si je n’ai pas tout à fait fini le contenu du site. Tout viendra en temps et en heure. J’ai pu tester que l’importation des articles de l’ancien site se faisait sans soucis. À part quelques flux RSS, les liens ne devraient donc pas se casser.

Vous pouvez donc supprimer ce site de votre agrégateur de flux RSS et repasser sur celui du site initial, tous les articles y seront transférés.

Construire un site complet à base de Boop!

mardi 26 février 2019 à 09:30

Après une petite pause d’un mois sur la refonte de ce site, il est temps pour moi de m’y remettre. La dernière phase avait consisté à imaginer un prototype pour me donner une vision globale de l’architecture du site. Cela devait aussi me permettre de pointer du doigt les manques de Boop!, mon générateur de sites statiques. Et il y en avait, des manques ! Je reviendrai prochainement sur les évolutions du contenu du site ainsi que sur son habillage (qui n’est d’ailleurs pas terminé). Pour l’instant je vais me contenter de détailler les dernières évolutions techniques.

Des améliorations dans le processus de développement

L’une des choses qui me tenait à cœur avec Boop! était de pouvoir travailler de la manière la plus agréable possible sur mon site. Le mieux dans cette situation étant de s’observer râler.

Premièrement, lors de la génération du site, je voulais pouvoir ouvrir rapidement les fichiers générés. Comme la plupart du temps je travaille sur un article, je veux pouvoir l’ouvrir immédiatement. J’ai donc fini par afficher le nom des fichiers dans la console, et comme il s’agit de chemins absolus commençant par file://, je n’ai plus qu’à cliquer dessus pour ouvrir mon article. Une exécution de Boop! ressemble grosso-modo à ça :

[marien@pizza marienfressinaud.fr]$ boop.py --development
Written page: file:///home/marien/marienfressinaud.fr/site/index.html
Written page: file:///home/marien/marienfressinaud.fr/site/blog.html
Written article: file:///home/marien/marienfressinaud.fr/site/construire-un-site-complet-a-base-de-boop.html
Written article: file:///home/marien/marienfressinaud.fr/site/suivre-le-boop-blog.html
Written article: file:///home/marien/marienfressinaud.fr/site/simplifier-la-redaction-darticles-dans-boop.html
Written article: file:///home/marien/marienfressinaud.fr/site/boop-une-introduction.html
Written feed: file:///home/marien/marienfressinaud.fr/site/feeds/all.atom.xml
Static files copied
Boop!

Ici vous ne pouvez évidemment pas cliquer sur les noms des fichiers, mais ça fonctionne dans un terminal.

À noter que lorsque je génère les fichiers pour la mise en production, ce sont les URL finales qui sont affichées (voir le code), ce qui me permet d’ouvrir l’article directement une fois en ligne.

Le deuxième point agaçant était que je devais quitter mon éditeur de texte régulièrement pour générer les fichiers et vérifier que le résultat me convenait. Lors de la phase de relecture d’un article par exemple, je peux vouloir regénérer le site plusieurs fois en quelques secondes : passer de la fenêtre de mon éditeur à celle de mon terminal pour revenir de nouveau à l’éditeur est très pénible. Utilisant Vim, j’ai ajouté deux raccourcis dans mon .vimrc : l’un pour générer le site (,,) et un autre pour publier le site en ligne (,p).

autocmd BufRead,BufNewFile */*marienfressinaud.fr/* nnoremap <leader><leader> !boop.py --development<CR>
autocmd BufRead,BufNewFile */*marienfressinaud.fr/* nnoremap <leader>p make publish<CR>

Habituellement les générateurs de sites statiques proposent un serveur surveillant les changements faits dans les fichiers et qui les regénère à la volée… mais je trouvais cette solution bien compliquée pour un intérêt limité. Cela me permet aussi de garder Boop! concentré sur une seule tâche : générer un site statique.

Enfin, notons que je dispose d’un fichier Makefile dans le répertoire du site qui me permet d’effectuer des tâches usuelles de manière unifiée :

$ make boop    # génère le site en mode développement
$ make publish # génère le site en mode production et le téléverse sur le serveur
$ make clean   # nettoie le répertoire `site`
$ make open    # ouvre la page d'index du site dans le navigateur
$ make tree    # affiche la structure des fichiers en excluant le répertoire `site`

Une réécriture partielle de Boopsy

Si vous vous souvenez, Boopsy est mon système de template maison. Jusque-là, il se contentait d’afficher des variables au sein de fichiers HTML. Cependant, j’ai très vite eu besoin de pouvoir écrire des conditions (if) et des boucles (for). Ces structures ont cela de particulier qu’elles ont un impact sur la portée des variables. La boucle en particulier pose un problème, par exemple dans le cas suivant :

{% for article in liste_articles %}
    <div>{{ article.title }}</div>
{% endfor %}

Avant d’entrer dans la boucle for, la variable article n’existe pas, il faut donc gérer le contexte. L’article sur lequel je me base depuis le début gère cela de manière relativement maline : il transforme le template en mini-programme Python. Le for est donc transformé en syntaxe Python, ce qui permet de déléguer la gestion de la portée des variables à l’interpréteur de ce dernier. J’avais fort justement décidé de ne pas partir sur cette solution initialement (ne la comprenant pas, j’étais allé au plus simple), et j’ai donc réécrit en partie ce que j’avais fait.

Une fois ce travail fait, l’ajout du if et du for a ensuite été très facile vu que je n’avais plus qu’à traduire le code récupéré depuis le template en code Python.

L’apparition des pages…

J’en avais besoin pour avancer : les pages ont été ajoutées très rapidement après mon dernier article. Jusque-là, je ne pouvais avoir qu’une unique page (d’accueil) et des articles. Pourtant, les pages statiques sont bien pratiques pour donner des informations « intemporelles ».

Contrairement aux articles, les pages sont écrites exclusivement en HTML et se trouvent dans un répertoire qui se nomme… pages. Elles peuvent partager elles-aussi un template commun (voir le code).

Le problème auquel j’ai alors fait face a été de pouvoir définir des variables dans les pages pour pouvoir les utiliser dans le template. En effet, le HTML ne permet pas de définir de variables. Je suis donc parti sur la solution utilisée par Jekyll, celle d’accepter un en-tête YAML en haut des fichiers HTML. Je trouvais cette solution d’autant plus élégante qu’au final il s’agissait de la même façon de faire dans les fichiers Markdown.

… d’une page de blog…

Une fois tout cela en place, je n’avais plus grand chose à faire pour avoir le site de mes rêves. Une chose toutefois continuait de m’embêter : je devais lister les articles à la main, un par un, manuellement sur une page de blog.

Disposant désormais de tout ce qu’il me fallait pour construire une liste d’articles automatiquement, il m’a fallu très peu de temps pour ajouter une page de blog générée par Boop!.

… et des séries.

La dernière fonctionnalité que j’ai développée a été celle des « séries ». Une série est une sorte de catégorie regroupant une liste d’articles. La différence avec le système de catégories que l’on peut retrouver ailleurs est que la série liste les articles dans un ordre décidé par l’auteur. C’est-à-dire, dans mon cas actuel, du plus ancien au plus récent (l’inverse donc de la page de blog). Mais on pourrait imaginer que cet ordre soit encore différent ; c’est à l’auteur de voir ce qu’il préfère.

La conséquence de cela est que les liens vers les articles sont aujourd’hui à faire manuellement sur les pages des séries (c’est dommage alors que je viens de vanter les mérites de l’automatisation dans la partie d’avant). J’envisage toutefois un système un peu plus sympathique à terme, sans perdre pour autant en flexibilité.

Une série dispose aussi d’un flux Atom spécifique, de la même manière que les catégories dans Pelican. Je sais qu’ils étaient utilisés sur mon ancien site (pour Lessy notamment), je voulais donc retrouver ce système sur le nouveau. Dans le flux, les articles continuent par contre d’être listés du plus récent au plus ancien.

Une série est créée en regroupant des articles dans un répertoire et en créant une page nommée serie.html dans ce répertoire (voir l’exemple du « Boop! blog »).

Et une grosse réorganisation du code

Vous vous doutez que tous ces changements ont apporté leur lot de dette technique et le fichier presque unique qui contenait le code de Boop! commençait à devenir hors de contrôle (500 lignes de code dont 220 pour la seule fonction principale). Il était grand temps de faire quelque chose, mais pas n’importe comment.

Une chose que je n’aime pas quand je lis le code d’une autre personne, c’est lorsqu’il y a des indirections dans tous les sens et que je dois ouvrir 5 fichiers pour comprendre ce qu’il se passe. Dans mon cas, je voulais que le fichier principal contienne l’ensemble de la logique métier, c’est-à-dire :

  1. chargement de la configuration du site ;
  2. collecte de l’ensemble des articles et des pages ;
  3. écriture des articles et des pages ;
  4. écriture des flux Atom (le principal ainsi que ceux des séries) ;
  5. copie des fichiers contenus dans static.

Ensuite, les fonctions qui ne revêtent pas un caractère important dans la logique métier sont extraites vers un fichier utils.py. Ce fichier apporte néanmoins des informations importantes quant au fonctionnement de Boop!.

Les derniers fichiers quant à eux contiennent quelques classes utiles au fonctionnement, notamment Article, Page et Feed.

Pour les plus curieuses et curieux d’entre vous, vous pouvez retrouver les différents commits de cette réorganisation de code de cette manière :

$ git clone git@framagit.org:marien.fressinaud/boop.git && cd boop
$ git log --reverse --oneline 694c4e3f..7bfac8f4
e3c382a Move extension filtering in utility functions
9a2c645 Extract function to build an article from filepath
...
7bfac8f Refactor feeds generation
$ git show [le commit que vous voulez voir]

Je pense toutefois que l’intérêt reste limité, mais c’est vous qui voyez si ça vous intéresse.

Un outil taillé au poil

Boop! a cela de bien qu’il fait très exactement ce dont j’ai besoin : pas une fonctionnalité n’est superflue. Et s’il manque très certainement des choses, ce sont pour d’autres besoins que les miens. Alors, oui, ça m’a pris un certain temps à développer ; je ne conseille évidemment pas à tout le monde de développer son propre générateur de sites statiques. Il y avait avant tout une visée pédagogique dans ma démarche, en montrant comment en partant de zéro on peut concevoir un outil qui fonctionne tout aussi bien qu’un « plus connu ». J’ai d’ailleurs pris le soin au fur et à mesure de l’article (ainsi que des précédents) d’ajouter des liens vers les commits correspondants à ce dont je parlais, pour comprendre « comment j’ai fait ». Je voulais aussi montrer qu’en restant le plus simple possible, on obtient une meilleure maîtrise sur l’outil et on peut le faire évoluer plus facilement. On favorise ainsi la liberté 1 du logiciel libre.

Boop! n’est pas pour autant totalement terminé. Il me reste à l’utiliser régulièrement sur une longue période de temps, comprendre là où ça bloque, fluidifier mon processus de travail, fignoler les morceaux de code toujours pas très élégants, améliorer la documentation que je n’ai jamais pris le temps de structurer correctement… Cela pourrait presque être comparé à du travail d’orfèvre à ce niveau de précision, mais j’aime être pointilleux quand je peux me le permettre. Et je peux.

Introspection professionnelle : communication et site

vendredi 11 janvier 2019 à 11:45

Pour ce dernier article de mon « introspection professionnelle », je vais aborder le sujet de la communication et dessiner une esquisse de ce que sera l’architecture du site. Pour rappel, le premier article définissait mes valeurs et ma raison d’être, tandis que le second décrivait les compétences que je souhaite appliquer dans mon futur métier ainsi que l’objectif que je me fixe.

Les choses commencent doucement à se clarifier pour moi, ce troisième article aborde enfin la phase concrète de la démarche et les premiers traits du site seront tirés dans la dernière partie. J’ignore encore qu’elles seront les missions sur lesquelles je serai amené à travailler, mais l’accueil qui a été réservé à mes deux premiers articles me conforte dans la voie que j’ai commencé à emprunter.

Différents supports pour communiquer

J’ai commencé à me poser la question du support de communication lorsque j’ai réalisé la diversité des médias que j’utilisais jusque-là : mon site évidemment, Twitter, Mastodon, Diaspora* (plus trop maintenant), mais aussi GitHub, sans compter les différents blogs ou espaces où j’ai été amené à écrire au compte-goutte. Je me posais régulièrement la question de quelle information devait être partagée où et sur quel ton. Il est grand temps de remettre tout cela à plat.

Pour commencer, parlons de ce dont je ne veux plus avoir à m’occuper : GitHub et Gitlab, et en particulier du premier. Il s’agit là de forges logicielles, c’est-à-dire d’espaces où l’on dépose du code source, agrémentés d’outils pour contribuer à ce code (notamment un bugtracker ainsi qu’un système de pull requests permettant de proposer des modifications du code). Mais ce n’est pas tout : GitHub en particulier n’est pas une simple forge, ce qui en fait sa force se trouve aussi dans ses aspects communautaires. On y met en avant les projets sur lesquels on travaille, notre activité quantifiée sous forme de beaux diagrammes et on peut même suivre ou être suivi par d’autres développeurs et développeuses pour voir ce qu’ils font. Gitlab est sans doute légèrement moins orienté vers cela, mais intègre tout de même certains de ces méchanismes. Le défaut de ces deux plateformes, c’est qu’elles sont orientées exclusivement vers le code, vers la technique. Si vous avez suivi mes articles précédents, vous aurez compris que cela m’intéresse assez peu au final. Quantifier le nombre de lignes de code ou de tickets que j’ai ouverts ne m’intéresse pas, cela flatte tout juste l’égo lorsque l’on est « productif ». Utiliser GitHub ou Gitlab pour communiquer m’apparaît donc comme trop restrictif et orienté vers un but qui n’est pas le mien. Je ferai donc désormais le minimum pour maintenir mes profils à jour sur ces plateformes.

Ensuite, le couple Twitter / Mastodon est légèrement plus compliqué. Ces deux médias sociaux se ressemblent énormément dans leur mode de fonctionnement (c’est-à-dire le partage de courts messages instantanés). Toutefois, Mastodon possède une communauté plus petite et plus ouverte où l’on trouve des personnes avec qui échanger de façon plus proche. Twitter me fait l’impression d’une population très (trop ?) hétérogène, où n’importe qui peut s’immiscer dans une conversation dans laquelle il n’est pas le ou la bienvenu·e (et s’y accrocher en plus, le bougre !) Dans les deux cas, l’argumentation est compliquée de part la limite du nombre de caractères dans les messages (280 sur Twitter, 500 sur Mastodon), alors autant privilégier la plateforme qui offre le cadre le plus accueillant pour échanger. Par conséquent, j’utiliserai Mastodon pour partager des choses professionnelles et plus personnelles. Je conserverai toutefois mon compte Twitter pour partager des choses exclusivement professionnelles et pour continuer ma veille de l’actualité. Quant à mon compte Diaspora* qui est à l’abandon depuis un moment, il risque de disparaître pour de bon un de ces jours.

Le dernier support de communication d’importance que je souhaite utiliser est bien entendu mon site Internet. Je le souhaite au centre de mes partages, en espérant écrire plus qu’auparavant (la fin de l’année 2018 m’a montré que j’en étais capable). Je détaille plus en détails comment j’imagine mon site dans la dernière partie de cet article.

Les petits à-côtés de la communication

En travaillant les supports de communication, quelques éléments sont ressortis que je n’ai pas encore traités.

En premier lieu, le CV est un support que je trouve intéressant. Il est surtout utilisé pour postuler en tant que salarié, mais aussi pour faire de la prestation chez des clients. J’aime bien y jeter un coup d’œil pour savoir comment les gens se présentent de manière succincte. D’un point de vue plus personnel, je trouve qu’il s’agit d’un exercice de synthèse assez intéressant et j’aime bien me limiter à une page A4 bien qu’aujourd’hui j’aurais sans doute matière à déborder un peu. Il ne s’agit toutefois pas d’un besoin urgent, bien que je m’y pencherai sans doute avec intérêt d’ici quelques mois.

Un autre sujet facultatif dans l’immédiat est celui des cartes de visite. Je vais sans doute rencontrer des gens qui chercheront à me contacter et la carte est dans ces cas-là intéressante pour donner les informations essentielles. Je devrais toutefois être capable de découper un bout de papier dans un coin de nappe et y écrire mon nom ainsi qu’une adresse courriel. Il manquera l’aspect « objet à collectionner », mais je suis persuadé que les gens sauront s’en passer. La fin du monde est pour demain après tout.

En parlant d’adresse courriel, se pose la question du moyen de me contacter. Je ne privilégie pas Twitter et je risque d’oublier des choses si les gens me contactent par Mastodon. De plus, j’aime centraliser ma correspondance, et le courriel est idéal pour cela. Ainsi, je compte mettre en évidence sur mon site une adresse unique pour me contacter. Certains préfèrent passer par un formulaire pour éviter que des personnes ne récupèrent leur adresse et limiter ainsi le spam, mais la mienne traîne déjà depuis plusieurs années sur mon site et j’arrive à peu près à limiter le spam. Je me suis aussi posé la question de proposer un numéro de téléphone, à Sogilis cela était fait car certains clients appellent plus volontiers qu’ils ne rédigent un courriel. Le téléphone est toutefois pour moi un élément relativement intrusif de par la présence physique qu’il requiert et je le réserve à un cadre privé.

Enfin, le dernier sujet que je souhaitais aborder est la photo de profil. Si je ne compte pas en mettre une en évidence sur le site, j’apprécie toujours de pouvoir me faire une idée du visage d’une personne avant de la rencontrer, ne serait-ce que pour la reconnaître plus facilement. La photo que j’utilise aujourd’hui commence à dater un petit peu, et les personnes qui m’ont croisé récement seront sans doute d’accord pour dire qu’elle n’est plus vraiment au goût du jour. J’ai vu à plusieurs reprises le conseil de passer par un photographe professionnel, mais je vais encore laisser le sujet de côté quelques semaines avant de me décider sur ce que je fais.

L’architecture du site, pour me représenter

Mon futur site aura deux objectifs : me servir de vitrine professionnelle (et donc me présenter) et à partager ce sur quoi je travaille. La structure de base de la page d’accueil que j’envisage n’a rien de très originale :

  1. présentation en une phrase de qui je suis, ainsi que mise en avant de mon objectif ;
  2. énumération de mes compétences pour indiquer sur quoi je peux travailler et comment ;
  3. présentation de mon manifeste pour mettre en évidence mes valeurs et préciser que je ne travaille pas sur n’importe quoi ;
  4. indication de mon adresse courriel ainsi que les médias sociaux sur lesquels on peut me trouver ;
  5. enumération des projets sur lesquels j’ai travaillé et que je souhaite mettre en avant (limités à environ 5) ;
  6. enfin, un pied de page pour servir de rappel (liens vers les différentes pages du site, rappel des informations de contact, etc.)

Il existera des pages supplémentaires pour détailler certaines parties, notamment mes compétences et mon manifeste (qu’il me reste à écrire !) J’intégrerai aussi au niveau de la liste des projets, un lien amenenant vers ma page « now » que je tiens à jour pour indiquer ce sur quoi je travaille en ce moment.

J’aimerais limiter le nombre de liens dans la barre de navigation en haut de la page, et je me contenterais d’ailleurs bien d’un simple lien vers le blog. Au passage, j’essayerai d’effacer la frontière qui peut exister habituellement entre la partie site et le blog. Il paraîtrait en effet logique qu’un lien partant de la liste des projets amène vers une série d’articles liée à un projet en particulier. La page de blog en elle-même se contenterait de présenter la liste complète des articles, mais deviendrait optionnelle pour accéder aux articles. Je souhaite de ce fait les placer dans leur contexte.

Afin d’illustrer ce vers quoi je veux tendre, j’ai créé une page de démonstration relativement complète. Avec cela, j’ai déjà une bonne base de travail pour avancer rapidement. Il me reste encore pas mal de contenu à écrire et Boop!, mon générateur de sites statiques, va encore devoir évoluer un peu, mais je peux dorénavant envisager une mise en ligne à la fin du mois.

Introspection professionnelle : compétences et objectif

mercredi 2 janvier 2019 à 15:15

En 2019, je change de vie professionnelle. Afin d’accompagner ce changement, je souhaitais entreprendre la refonte de mon site pour qu’il mette mieux en avant mes aspirations. Dans mon précédent article, j’ai décrit mes valeurs et ma raison d’être (c’est-à-dire ce qui me motive au quotidien), à travers une démarche d’introspection professionnelle. Pour rappel, les différentes étapes que je prévois dans le cadre de cette démarche sont :

  1. définition de mes valeurs ;
  2. définition de ma raison d’être ;
  3. définition de mes compétences ;
  4. établissement d’un objectif personnel ;
  5. définition de mes moyens de communication ;
  6. conception de l’architecture du site.

Les deux premiers points ont donc été détaillés dans le précédent article, je vais désormais aborder les deux points suivants, à savoir mes compétences et mon objectif personnel afin d’étudier comment je compte mettre en œuvre ma raison d’être. Dis autrement, je vois mes compétences comme des outils à mon service pour atteindre un objectif qui saura satisfaire ma raison d’être et mes valeurs.

Aujourd’hui mes compétences sont essentiellement techniques, orientées spécifiquement dans le développement web. À ce niveau-là, je suis plutôt polyvalent et capable d’apprendre assez aisément. Ce qui m’importe toutefois aujourd’hui concerne plutôt le champ de compétences que je souhaite être capable de couvrir en totale autonomie. J’ai relevé trois points principaux (vous remarquerez que j’aime bien ce chiffre !) ainsi que quatre transversaux pour arriver à un total de sept compétences que je pourrai mettre en œuvre au sein d’un projet.

Des compétences fondamentales pour définir mon métier

Tout d’abord, je souhaite monter en compétences dans le domaine de l’acquisition des besoins métiers orientés utilisateurs. Je pense que c’est une démarche saine que de d’abord chercher à comprendre les enjeux d’un métier et en mesurer sa complexité avant de développer une solution logicielle. Cela permet notamment d’être force de propositions pertinentes. J’ai par ailleurs trop souvent vu des clients qui fonçaient bille en tête avec une idée bien définie, sans questionner les usages des autres utilisateurs et utilisatrices. J’ai dans ces moments-là eu l’impression de ne développer que pour une personne et que l’outil ne serait jamais pleinement utilisé ou adopté. Je crois que ce n’est pas une démarche toujours évidente que de questionner un client sur ce qu’il a muri en lui-même, en particulier en tant que développeur, et de lui faire comprendre que sa solution n’est pas forcément la meilleure pour tout le monde. Il sera essentiel que je sache établir une confiance quant à ma capacité à comprendre le métier.

Ensuite, la deuxième compétence que je saurai mettre en pratique au sein d’un projet est celle du développement logiciel. Comme je le disais plus haut, il s’agit d’un domaine où je suis polyvalent et capable d’apprendre ; c’est le cœur de mon expertise aujourd’hui. Je suis à l’aise à la fois en frontend comme en backend. Je connais un certain nombre de bonnes pratiques en matière de déploiement automatisé/continu et connais relativement bien les problèmes qui peuvent se poser aux administrateurs système. J’essaye notamment de mettre en pratique les recommandations de la méthodologie « The Twelve-Factor App ». Ainsi, lorsque je développe une fonctionnalité, je pense à ce qu’elle deviendra une fois en production. Dans cette optique, j’essaye aussi de faire en sorte que ce que je développe arrive le plus rapidement possible en production afin d’éviter un décalage trop important entre mon code et la base initiale. En terme de langages, cela a relativement peu d’importance pour moi vu que je suis capable d’apprendre si la situation le demande. J’ai toutefois plus d’expérience en Ruby (très orienté Ruby on Rails), Python, JavaScript et PHP. Il s’agit là de compétences que je maîtrise suffisamment pour être autonome sur un projet sans aucun soucis. Bien entendu, mon code s’accompagne de tests et je fonctionne souvent en TDD (pour Test-Driven Development). Par ailleurs, j’ai un attachement particulier aux logiciels simples, qui ne cherchent pas à faire trop de choses et dont on peut fouiller le code pour y trouver rapidement ce que l’on cherche.

Enfin, la dernière compétence fondamentale que j’aimerais mettre en application au sein des projets où j’aurai à intervenir porte sur l’accompagnement à la mise en place d’une méthodologie documentaire. J’en parlais lorsque je détaillais mes valeurs, la transmission des connaissances est primordiale pour qu’un groupe ne dépende pas de quelques personnes clés. Je crois qu’il y a aujourd’hui un manque énorme de culture écrite dans nos modes de fonctionnement (je l’ai retrouvé à différents niveaux professionnel et associatif) ou alors cette culture n’est pas orientée vers le partage et la conservation des connaissances. C’est un sujet que j’ai commencé à toucher du doigt et sur lequel j’aimerais véritablement progresser. Et pour progresser, rien de tel que de pratiquer. Les wikis et les blogs sont pour moi deux outils très puissants dans cette recherche du partage mais qui ont le défaut de figer la connaissance à un instant T. J’aimerais étudier des modes de fonctionnement qui font vivre cette connaissance, qui lui permettent véritablement d’évoluer dans le temps et qui replacent la documentation au centre des préoccupations.

Des compétences transverses, au bénéfice des projets

En plus des trois compétences fondamentales listées au-dessus et qui forment un tout dans la vie d’un projet, j’ai voulu ajouter quatre compétences que je peux appliquer de façon générale sur tout type de projet.

Tout d’abord, une communication que je décrirais de transparente. Je parlais plus haut de confiance à établir avec les client·es, cela passe avant tout par la communication (écrite comme orale). Il est notamment important de ne pas cacher des éléments dont on pourrait avoir « honte ». Par exemple, la production est tombée, on l’a réparée en catimini sans que la cliente n’en sache rien mais on la tient quand même informée de ce qu’il s’est passé, par transparence. Savoir communiquer peut notamment servir à désamorcer des sujets qui pourraient être tabous et donc dangereux dans la vie d’un projet. Afin de communiquer de façon efficace, j’essaye de me placer tout d’abord dans une position d’écoute. Cette position me sert à comprendre mon interloteur ou interlocutrice, comprendre comment il ou elle intéragit avec moi, quel degré de familiarité je peux me permettre, si elle est sensible à mon argumentaire ou s’il est plutôt fermé à des approches différentes. Ce n’est pas toujours chose aisée, mais en exprimant aussi ce que l’on ressent, en partageant les doutes qui peuvent surgir en nous, on arrive à poser un terrain propice à la collaboration.

La deuxième compétence dont je pense pouvoir tirer partie est ma capacité à rendre compte de façon claire et argumentée un travail que j’ai produit. Que ce soit à l’oral ou à l’écrit, j’essaye toujours de me rendre compréhensible et je n’hésite pas à reformuler si je sens que je ne suis pas clair. Cela peut toutefois me demander un certain temps de préparation pour me laisser le temps de répéter ou de me relire au minimum deux à trois fois. Je suis par ailleurs très attaché à la pratique de la langue française et j’aime jouer sur les nuances que peuvent porter des mots ou la construction d’une phrase. Cela peut paraître anecdotique vis-à-vis d’autres compétences, mais j’ai réalisé il y a peu que le fait de savoir exprimer correctement ses idées joue un rôle très important dans la façon dont on est perçu par les autres. Cela affecte notre capacité à convaincre et à être suivi.

Ensuite, la gestion de projet intervient à tout les instants d’un projet. Afin d’être efficaces, il me semble que les méthodes agiles sont idéales. Je n’ai commencé à pratiquer qu’en arrivant au sein de Sogilis où j’ai pratiqué un mélange de Scrum et d’Extreme programming, mais j’ai très rapidement saisi un certain nombre d’avantages que ces pratiques offraient. Ce que j’en retire avant tout, c’est le fait de partir du constat que nos méthodes de travail ne fonctionneront pas parfaitement au démarrage d’un projet, et donc d’intégrer dans le processus de travail les outils qui permettront d’améliorer et corriger le processus lui-même, en cours de route. De plus, et cela rejoint mon premier point, la communication est placée au centre des préoccupations ce qui permet une bonne compréhension des enjeux par tout le monde et facilite la détection des problèmes qui ne manquent pas d’arriver au fil de l’eau. Les méthodes agiles offrent donc un cadre sain et malléable pour gérer et faire vivre un projet, elles seront donc au cœur de ma façon de travailler.

Enfin, le dernier point que je souhaitais aborder est l’intégration aux équipes. Il est pour moi important de faire partie d’une équipe et de ne pas travailler dans mon coin. Cela aide à mieux communiquer (encore !), à partager les connaissances pour ne pas devenir indispensable et à améliorer la qualité du produit final. La confrontation des points de vue sur un sujet donné, un bout de code par exemple, aide à penser un problème sous différents angles et prendre du recul sur ce que l’on fait. Je n’ai quasiment jamais travaillé ces trois dernières années tout seul sur un projet, et même sur Lessy qui reste un projet très personnel, j’ai eu à cœur de demander conseil autour de moi. Je pense être capable de m’intégrer facilement à une équipe, mais cela dépend aussi beaucoup des personnalités au sein de l’équipe ; je ne saurais donc en faire une règle absolue.

Un objectif au service de ma raison d’être

Arrive donc le moment où je dois résumer les quelques 3 200 mots de mes deux articles abordant mon introspection professionnelle ainsi qu’un an de réflexions plus ou moins poussées, en une phrase d’accroche qui définira la façon dont je veux aborder mon travail durant les prochains mois et/ou prochaines années.

Après plusieurs reformulations, je suis arrivé à déterminer un objectif qui me convient plutôt bien :

J’accompagne les humain·es de notre société de demain dans une démarche de résilience en participant à la conception de leurs outils numériques et en les aidant à améliorer leurs méthodes de travail, le tout dans un esprit de sobriété.

J’ai essayé d’y insuffler un maximum d’éléments issus des étapes précédentes sans pour autant en abuser pour que le message reste clair. Tout d’abord, la notion de « société de demain » fait directement référence à un monde post-effondrement que j’évoquais dans mon article précédent. J’y fais aussi référence en tentant de dessiner une première esquisse d’une société que je souhaite résiliente et sobre. La sobriété fait aussi référence à ma volonté de développer des logiciels simples et « bidouillables ». Mes compétences sont lisibles au creux de mon objectif : la conception d’outils numériques et l’amélioration des méthodes de travail qui incluent les méthodes agiles et une démarche de documentation. Aussi, je m’inscris dans une position de complémentarité (à l’inverse d’être indispensable) des équipes déjà en place en « accompagnant », « participant » et en « aidant ».

Cet objectif pourra être amené à évoluer dans le futur, mais j’espère qu’il saura m’accompagner dans mes premières missions et qu’il permettra de poser sur la table des sujets de discussion que l’on aborde trop peu dans le monde de la technologie. J’espère qu’il véhicule correctement le message politique que je lui ai imaginé.

J’entrevois d’ailleurs déjà des limites à cet objectif très orienté vers un métier que je pense voué à être marginalisé à long terme. Métier par ailleurs pratiqué par et pour une population privilégiée dans le sens où elle possède et maitrise des outils informatiques. Je crois que ces outils doivent s’accompagner d’une démarche complémentaire au risque d’abandonner sur le bord de la route les personnes les moins à l’aise avec le numérique. L’informatique reste un outil à notre service, en aucun cas il ne s’agit d’une fin en soi. Je souhaiterai à terme évoluer vers un métier plus ancré dans le réel. Aujourd’hui je vais toutefois profiter des compétences acquises durant ces dernières années pour orienter le domaine au sein duquel j’agis (le développement logiciel, principalement) vers un horizon qui me semble plus enviable. Ce sera l’occasion aussi de rencontrer des personnes qui pourront me guider vers des voies que je n’imagine pas encore. Mon objectif, tout imparfait soit-il, est une image à cet instant précis de mes envies et une piste à explorer pour pouvoir imaginer et construire « autre chose » par la suite.

Avec cet objectif défini, je considère que le gros du travail introspectif est terminé. Il reste toutefois quelques étapes supplémentaires avant d’attaquer la refonte du site à proprement parler. J’aborderai dans le prochain article les deux derniers points de ma démarche, à savoir de quelle manière je souhaite communiquer et, enfin, la conception de l’architecture du site.