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.mjs initialise le fichier icons-metadata.json à partir des données existantes afin de disposer d’une base homogène.
  • metadata-enrich.mjs enrichit 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.mjs analyse 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.mjs applique automatiquement les règles définies dans metadata-rules.json afin de maintenir un format cohérent sur l’ensemble de la bibliothèque.
  • metadata-apply.mjs permet d’intégrer les suggestions validées tout en conservant une maîtrise des modifications apportées.
  • site-data.mjs génère les données utilisées directement par le site web de Socicon.
  • generate.mjs construit l’ensemble des fichiers générés du projet, notamment les fichiers chart-list.*, qui ne dépendent désormais plus de templates présents uniquement sur une machine locale.
  • check.mjs effectue 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.mjs nettoie automatiquement les fichiers générés afin de repartir d’un environnement propre.
  • Enfin, release-build.sh automatise 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é.

 
Industrialisation
Git
Statut
Bénévole