Une automatisation à la fois : mon travail sur Socicon, open source

Lorsque l’on utilise une bibliothèque open source, on oublie parfois qu’elle est avant tout le fruit du travail de bénévoles qui essaient, chacun à leur manière, d’améliorer un projet commun.
Ces derniers mois, j’ai eu l’occasion de contribuer à Socicon, une bibliothèque d’icônes dédiée aux réseaux sociaux, services web et plateformes communautaires. Une bibliothèque que l’on retrouve dans de nombreux projets web.
Au départ, mon objectif était relativement simple : contribuer à l’ajout de nouvelles icônes. En explorant le fonctionnement du projet, je me suis rapidement aperçu qu’il était possible d’aller beaucoup plus loin que cela.
Finalement… je me suis retrouvé à revoir une bonne partie de la chaîne de génération du projet.
Partir d’un besoin concret
En travaillant sur les nouvelles icônes, je me suis rapidement aperçu que certaines opérations étaient encore réalisées manuellement. Par exemple, les fichiers chart-list.*, qui présentent l’ensemble des icônes disponibles, étaient générés à partir de templates conservés uniquement en local.
Ce fonctionnement faisait le travail, mais il avait plusieurs inconvénients :
- impossible pour un autre contributeur de régénérer ces fichiers facilement ;
- risque d’oublier une étape avant une publication ;
- dépendance à un environnement de développement particulier.
J’aime généralement éviter ce genre de situation. Si une opération peut être automatisée, documentée et reproductible, alors autant le faire.
Automatiser plutôt que répéter
J’ai donc entrepris de remplacer ces anciens templates locaux par une véritable chaîne de génération intégrée au projet.
L’idée n’était pas simplement d’écrire quelques scripts supplémentaires, mais de faire en sorte que toute personne qui clone le dépôt puisse produire exactement les mêmes fichiers, sans dépendre d’outils personnels ou de manipulations particulières.
Au fil des développements, cette automatisation s’est progressivement transformée en un véritable pipeline de maintenance du projet.
Chaque script répond désormais à une étape bien précise :
-
metadata-bootstrap.mjsinitialise le fichiericons-metadata.jsonà partir des données existantes afin de disposer d’une base homogène. -
metadata-enrich.mjsenrichit automatiquement ces métadonnées en proposant des catégories, des tags et différentes informations complémentaires qui seraient fastidieuses à renseigner manuellement. -
metadata-audit.mjsanalyse la qualité des métadonnées et met en évidence les incohérences ou les éléments qui méritent d’être revus. -
metadata-update.mjsapplique automatiquement les règles définies dansmetadata-rules.jsonafin de maintenir un format cohérent sur l’ensemble de la bibliothèque. -
metadata-apply.mjspermet d’intégrer les suggestions validées tout en conservant une maîtrise des modifications apportées. -
site-data.mjsgénère les données utilisées directement par le site web de Socicon. -
generate.mjsconstruit l’ensemble des fichiers générés du projet, notamment les fichierschart-list.*, qui ne dépendent désormais plus de templates présents uniquement sur une machine locale. -
check.mjseffectue un contrôle global du dépôt afin de vérifier que toutes les données générées sont cohérentes avant une publication. -
clean.mjsnettoie automatiquement les fichiers générés afin de repartir d’un environnement propre. - Enfin,
release-build.shautomatise la préparation des livrables d’une nouvelle version.
Petit à petit, le projet est devenu plus cohérent.
Aujourd’hui, l’ensemble de cette chaîne est versionné dans le dépôt Git. Plus besoin de conserver des scripts ou des templates « cachés » sur une machine personnelle : tout est partagé, documenté, reproductible et accessible à n’importe quel contributeur.
Rendre la contribution plus simple
Ce que j’apprécie dans l’open source, ce n’est pas seulement ajouter une fonctionnalité. C’est aussi essayer de faciliter le travail du prochain contributeur. Moins il y a d’étapes cachées, de fichiers personnels ou de manipulations manuelles, plus il est simple de participer au projet.
À terme, cela réduit également les risques d’erreurs lors des futures publications.
Bien plus que quelques icônes
Au final, cette contribution ne se résume pas à l’ajout de nouvelles icônes. Elle a surtout consisté à améliorer l’outillage du projet afin que les prochaines évolutions soient plus simples, plus fiables et entièrement reproductibles.
Ce sont souvent ces changements invisibles qui apportent le plus de valeur sur le long terme.
Ils ne se voient pas forcément lorsque l’on télécharge la bibliothèque, mais ils facilitent la vie de tous ceux qui la font évoluer. Et c’est probablement ce que j’aime le plus dans ce type de contribution : améliorer le quotidien des développeurs… parfois sans qu’ils s’en rendent compte.
Oui, mais la suite ?
Coolseed m’a confié, en mars 2024, la maintenance et l’évolution de la librairie. Il a réalisé un travail considérable pour faire de Socicon la référence qu’elle est aujourd’hui.
Depuis, j’essaie de poursuivre cette aventure à ma manière. J’ai ajouté de nouvelles icônes et diverses améliorations, tout en cherchant à rendre le projet plus simple à maintenir et plus agréable à faire évoluer.
L’un des chantiers actuels consiste à remettre de l’ordre dans les métadonnées de certaines icônes. Avec le temps, certains services ont changé de nom, d’identité visuelle ou ont tout simplement disparu. D’autres informations étaient devenues incomplètes, peu structurées ou obsolètes. L’objectif est donc de disposer, à terme, d’une base de données aussi fiable que possible, qui puisse servir aussi bien à la génération de la bibliothèque qu’au site web et aux futurs outils gravitant autour du projet.
Et ce n’est probablement qu’une étape.
J’aimerais continuer à enrichir les métadonnées, améliorer encore les outils de validation, faciliter la contribution des futurs mainteneurs et poursuivre l’automatisation de tout ce qui peut l’être. J’ai également quelques idées autour de la qualité des données, de la documentation et de l’expérience des contributeurs.
L’open source est rarement un projet que l’on termine.
C’est plutôt un projet que l’on transmet, en essayant de le laisser dans un meilleur état que celui dans lequel on l’a trouvé.
Derniers commentaires
# Le 19 octobre 2024 à 13:09, par nico
En réponse à : MagicMirror², ma configuration personnalisée
# Le 25 septembre 2024 à 12:01, par Teddy Payet
En réponse à : Un Nouveau Chapitre : Mon Admission dans un MBA en Intelligence Artificielle et Data Innovation
# Le 25 septembre 2024 à 11:20, par vY
En réponse à : Un Nouveau Chapitre : Mon Admission dans un MBA en Intelligence Artificielle et Data Innovation
# Le 21 juin 2024 à 13:49, par Teddy Payet
En réponse à : Home Assistant : Routine le matin avant l’école
# Le 21 juin 2024 à 10:47, par Teddy Payet
En réponse à : Ma domotique open source
# Le 16 juin 2024 à 17:15, par Eric
En réponse à : Ma domotique open source