Quelques mots sur le nouveau site de Paris Web

mardi 13 mai 2025

Le site précédent

2018, c’était un moment où j’ai beaucoup évolué professionnellement : je me suis retrouvé au chômage quand la SSII qui m’employait a cessé son activité, et je me suis orienté vers le développement après une dizaine d’années à avoir pratiqué le design web/motion design/flash. Mon recentrage depuis le design vers le code a été poussé par deux choses. D’une part je ne trouvais plus de satisfaction dans le monde du design web (qui s’orientait vers une pratique très utilitariste sans créativité) ni dans la pratique du design en général, et je trouvais plus important d’agir sur l’accessibilité là où j’aurais le plus de pouvoir. C’est à l’étape de l’intégration HTML/CSS/JS qu’on a le maximum de capacité sur l’amélioration de l’expérience pour les personnes handicapées.

C’est à ce moment là que j’ai commencé à bénévoler chez Paris Web. L’équipe désirait mener à bien une refonte complète du site web. Un travail avait été commencé mais s’était arrêté après les études UX et les premières ébauches design. Le débat bloquant portait sur la technologie de CMS. (Lâchez 10 développeur·ses web et dites-leur de créer un site, c’est toujours à cette étape qu’il y aura le plus de débats.) Pour couper court à ces discussions, en 2018 on avait opté pour garder le CMS existant. Movable Type est vénérable, soit, mais il était en place depuis 2009 (ou avant ?), et l’installation était déjà réglée aux petits oignons par François pour les besoins du site. En revanche on avait opté pour une refonte complète du design : mise à jour du logo, de toute l’identité visuelle, etc.

Dans ce genre de projet bénévole, on ne fonctionne qu’à l’énergie qu’on peut donner. C’est aussi pour ça que certains sujets restent dans les cartons d’une année sur l’autre—s’il n’y a personne pour les porter, ils ne vont pas avancer. C’est une fois que j’ai compris ça que j’ai pu réfléchir à mon engagement et ma stratégie. Pour mener ce genre de projet à bien il faudrait cravacher pendant quelques mois en équipe réduite des personnes les plus motivées. Ça tombe bien, ça me convient mieux que le travail de longue haleine (même à faible effort).

On a donc cravaché pendant deux ou trois mois, moi au design et Julien et Pierre à l’intégration. On a travaillé sur un guide de style, produit des pages HTML, des feuilles CSS et du JS, qui ont ensuite ensuite été transformées en gabarits Movable Type par François. J’avais donné quelques détails à l’époque dans un billet sur Paris Web 2018, ma mission au cours de l’année.

Un nouveau CMS

Lors de l’assemblée générale ordinaire de l’asso qui suivait l’édition 2023, J’ai commencé à suggérer l’idée de faire évoluer le site. Étant donné qu’on n’avait pas d’idée d’évolution du design, on a commencé par parler de technologie. On était quelques-uns à avoir des opinions, mais j’ai poussé Kirby pour plusieurs raisons. D’une part, Movable Type est en Perl, donc l’entretien et la maintenance ne reposait que sur la personne de François sans qu’on puisse l’épauler, un CMS en PHP réduirait le clown school factor en permettant à plus de monde de comprendre et modifier le code. D’autre part, là où les limitations de Movable Type nous gênaient aux entournures, Kirby nous permettait beaucoup plus de choses. Kirby nous a aussi beaucoup simplifié la gestion et le déploiement des nouvelles versions, et surtout l’installation côté serveur. Pas de base de donnée, pas de Perl, pas de prérequis farfelus.

La migration des données depuis la base de Movable Type vers la structure de répertoires de Kirby aurait pu être très complexe, mais la possibilité pour Movable Type de générer n’importe quel type de contenus—même des contenus en texte avec une structure particulière—a sauvé la mise. Il y a évidemment eu des ajustements à faire et des données à corriger, mais tout a pu être transféré sans perte.

La nouvelle mouture a été mise en ligne de manière transparente : mis à part un ou deux petits soucis pour les personnes abonnées au flux RSS des nouvelles, peu de gens se sont aperçus du changement de technologie. Les membres de l’asso ont pu s’approprier le nouvel outil, et proposer des améliorations sur la présentation de l’interface d’administration—c’est une autre force de Kirby : le design se fait du côté front-end pour tous les visiteurs, mais aussi côté back-end pour optimiser l’expérience de contribution.

En aparté : Oui, comme tout plein de mes billets sur ce blog, c’est encore un panégyrique à Kirby. Plus de détails dans le billet Bon, tu veux te faire ton site web ? Le CMS par excellence : Kirby ou dans celui sur 30 jours de Kirby pour 24 jours de web. Je ne suis pas payé (mais ils ont sponsorisé Paris Web à hauteur de deux licences, une pour paris-web.fr et une pour 24joursdeweb.fr, Danke schön, Bastian und andere!). Fin de l’aparte.

…et un redesign

C’est pendant l’édition 2024, ou plutôt au cours des discussions qu’on a entre membres de l’équipe pendant les temps morts de l’édition 2024, qu’on s’est parlé des idées qu’on avait pour 2025, la 20e édition. Une idée s’est imposée : un rafraichissement du site, voire un redesign complet, serait une bonne manière de marquer le coup.

Au niveau des efforts, le pôle Design ne pouvait pas porter tout le projet, donc on a fait appel à Christophe Andrieu, avec qui Paris Web a plein de liens depuis des années.

La première étape côté code, ça a été de paramétrer les nouvelles données.

Par exemple, le cycle annuel de la page d’accueil se passe en cinq étapes : l’appel à sujet, le suspense avant le programme, la publication du programme, pendant l’événement, et enfin après l’événement. L’interface d’administration a donc été adaptée pour la gestion des contenus en fonction du moment dans ce cyle. Pour gérer ça, c’est quelques lignes dans un fichier de configuration pour la partie administration, et quelques lignes de plus dans le gabarit de la page. Les contenus sont conservés au fur et à mesure du cycle, pour être ensuite redéployés l’année suivante.

Peu à peu les nouvelles maquettes m’ont permis de travailler sur les structures des pages intérieures du site. Par exemple, en 2018 on n’aurait pas pu utiliser les grid CSS par crainte d’incompatibilité, mais ça n’est plus un souci en 2025, ce qui m’a permis de revoir la structure dans les différentes vues de programme et d’éliminer les <table> (dont je préfère limiter l’usage aux véritables données tabulaires).

À ce moment-là, j’ai eu accès aux sources du design sur Figma. J’ai supprimé tout l’ancien code CSS du site pour partir sur des bonnes bases. La deadline était trois semaines plus tard, j’avais des soirées, des très longs week-ends, mais pas beaucoup plus. J’ai choisi une organisation du CSS qui permettait assez de flexibilité et de rapidité, mais qui garde une certaine logique. Dans l’idéal, c’était me rapprocher de la stratégie CUBE CSS en séparant chaque couche grâce aux @layers. Depuis des années je suis partisan de conjuguer les styles utilitaires avec des styles dédiés et plus pragmatiques, CUBE propose une approche pertinente. En raison de la rapidité du développement j’ai pas pu passer trop de temps à simplifier—ce qui explique que la couche Blocks est plus fournie que je n’aurais souhaité. Après il y a toujours des limites à ce qu’on peut factoriser. Le but est d’avoir un code qui fonctionne, avec une logique prévisible dans la mesure du possible. Les classes utilitaires m’ont fait gagner du temps sur certains aspects mais ont leur problème (je n’ai qu’une media query, ça limite la multiplication de classes). Je suis très content de la manière dont le CSS “moderne” me permet d’avancer rapidement. Le nesting est très pratique (mais il ne faut pas en abuser) surtout pour l’inclusion des media queries, les custom properties évitent les erreurs de répétition, et tout ça fonctionne sans pré-processeur.

Un projet n’est pas terminé tant qu’on n’a pas atteint au moins une fois les limites des outils. En l’occurence, c’est arrivé une fois avec Kirby. La structure des données de Paris Web a une certaine complexité par rapport à un site basique. La page d’accueil affiche les auteurices des conférences de l’année, tirés au sort à chaque chargement. La première solution était de laisser Kirby générer cette sélection, mais c’est là que Kirby n’est pas aussi optimal qu’un système qui utilise une base de données. Donc cette première approche prenait un peu de temps, et du fait du tirage au sort elle ne permettait pas l’usage d’un cache aussi agressif que celui du reste du site (cache statique : au premier chargement d’une page, Kirby en sauve une copie en HTML, les requêtes suivantes chargent cette copie sans avoir à appeler Kirby pour recalculer la page). Donc j’ai tenté une autre approche : au premier chargement, on pose dans la réponse un objet JSON qui contient toutes les infos des orateurices et conférences de l’édition courante, et lorsque le navigateur lit le contenu, quelques lignes de JavaScript vont faire le tirage au sort et afficher les orateurices avec le lien vers leurs conférences. Cette approche doit être la plus simple possible pour éviter toute réorganisation de la page et que le chargement soit le plus fluide possible. C’est pour ça que le code JavaScript est directement dans la page, juste sous le contenu à afficher, sans dépendances externe.

Cette refonte a provoqué la décommission de l’ancien guide de styles, mais avant ça j’ai pu récupérer le dernier élément commun avec l’ancien site, la page de recherche dans les archives, ou plutôt les scripts qui gèrent la recherche instantanée via Algolia. Cette partie-là n’avait pas encore été remplacée par du code plus récent, et je n’avais pas le temps de m’y pencher. Et puis soyons honnêtes, c’était pas cassé, donc autant réutiliser tout ce que je peux. J’ai donc pu copier les sources dans un plugin Kirby personnalisé (la raison du plugin Kirby, c’est pour avoir les trucs liés à Node ailleurs qu’à la racine de mon projet). J’en ai aussi profité pour passer à esbuild au lieu de Webpack pour la compilation, j’ai gagné en simplicité et en rapidité.

Au fur et à mesure que le site avançait j’ai pu le pousser sur l’environnement de staging, pour que le reste de l’équipe puisse découvrir, tester, ajuster le contenu… les retours qu’ils ont fait dans ces conditions proches du réel ont été primordiales pour permettre au site d’être mis en ligne sans problèmes.

Finalement, la mise en ligne a été rapide : il m’a suffi de récupérer le code du site via git, copier les fichiers du contenu depuis l’environnement de staging, vérifier que tout était dans les bons répertoires… et voilà. Pas de migration ni de copie de base de données.

https://www.paris-web.fr/

Comme d’habitude, allez lire le fichier /humans.txt.

Et si on demande ce que je veux dire par clown school factor, c’est comme le bus factor, mais au lieu du risque de se faire écraser par un bus (négatif, ne remet pas an cause l’hégémonie automobile, cautionne le décès des collègues) on parle du risque de tout lâcher et aller s’inscrire dans une école de clowns (cocasse mais réaliste).

Edit : Si vous voulez faire part de bugs graphiques ou autres problèmes liés aux sites de Paris Web (on a beau faire gaffe, il en reste toujours un ou deux), on a ouvert un dépôt sur Github, rendez-vous sur https://github.com/Paris-Web/tickets.