Un README sans badges, c’est comme un burger sans fromage : techniquement comestible, mais où est passé le fun ? Les badges, ces petites pastilles colorées qui squattent le haut de ton fichier, servent à la fois de vitrine et de preuve sociale. Ils disent : « Regardez, mon projet est sérieux, il a des tests, il passe en CI, et oui, il est même couvert à 95% (enfin, presque) ». Mais attention, tous les badges ne se valent pas. Certains sont utiles, d’autres relèvent du flex inutile. Faisons le tri.
Les badges indispensables : ceux qui servent vraiment
Commençons par le strict minimum, les badges qui apportent une information concrète et actionnable. Sans eux, ton projet ressemble à une voiture sans tableau de bord : tu roules, mais tu ne sais pas si tu vas tomber en panne d’essence dans 5 minutes.
- Build Status : Le plus basique, mais aussi le plus crucial. Un badge
build passingoubuild failingindique si ta CI/CD fait son boulot. Sur GitHub, utilise GitHub Actions pour générer le lien. Exemple :[](https://github.com/ton-user/ton-projet/actions)
Sur GitLab, c’est encore plus simple : le badge est généré automatiquement pour les pipelines. - Coverage : Le badge qui fait mal (ou qui flatte l’ego). Il affiche le pourcentage de code couvert par tes tests. Si tu utilises Coveralls ou Codecov, le badge est fourni clé en main. Exemple avec Codecov :
[](https://codecov.io/gh/ton-user/ton-projet)
Attention, un badge à 100% ne signifie pas que ton code est parfait. Ça signifie juste que tu as écrit des tests pour tout, même pour les fonctions qui ne servent à rien. La qualité > la quantité, toujours. - Version : Un badge qui affiche la dernière version stable de ton projet (via Shields.io ou badge.fury.io). Utile pour les libs et les outils distribués. Exemple :
[](https://badge.fury.io/js/ton-projet)
Si tu utilises GitHub Releases, tu peux aussi afficher la dernière version taggée.
Les badges « flex » : ceux qui font joli (mais pas toujours utile)
Passons aux badges qui relèvent plus du bling-bling que de l’information critique. Ils ont leur place, mais à dose homéopathique. Un README surchargé de badges, c’est comme un CV avec 15 polices différentes : ça donne mal aux yeux et ça sent le désespoir.
- Licence : Un badge qui affiche la licence de ton projet (MIT, GPL, etc.). C’est sympa, mais est-ce que quelqu’un va vraiment cliquer dessus ? Si tu veux vraiment le mettre, utilise Shields.io :
[](https://opensource.org/licenses/MIT)
Perso, je préfère écrire la licence en toutes lettres dans le README. Un badge, c’est du sucre syntaxique. - Downloads : Un badge qui affiche le nombre de téléchargements (npm, PyPI, etc.). Si ton projet a 10 téléchargements par mois, ça peut être déprimant. Si tu es à 10 millions, ça peut être gratifiant. Dans les deux cas, ça n’apporte rien de concret. Exemple :
[](https://www.npmjs.com/package/ton-projet)
- Social : Les badges « GitHub stars », « Twitter followers », ou « Discord members ». À moins que ton projet ne soit une communauté à part entière, ces badges sont juste du vanity metrics. Ils ne disent rien sur la qualité du code, juste sur ta capacité à faire du bruit sur les réseaux.
Les badges à éviter : ceux qui servent à rien (ou pire)
Certains badges sont soit redondants, soit carrément contre-productifs. En voici une petite sélection, à bannir de ton README si tu veux garder un minimum de crédibilité.
- « Made with » : Les badges du type « Made with React », « Made with Python », ou « Made with Love ». Sérieusement ? Ton README est déjà dans un repo GitHub, on sait que c’est du code. Si tu veux vraiment préciser la stack, écris-le en texte. Un badge, c’est du bruit visuel.
- « Awesome » : Les badges « Awesome [Techno] » qui renvoient vers des listes Awesome sur GitHub. Si ton projet est vraiment awesome, les gens le verront sans badge. Sinon, ça ressemble à de l’auto-promotion désespérée.
- « W3C Valid » : Un badge qui certifie que ton HTML/CSS est valide W3C. À moins que tu ne développes un validateur W3C, personne ne s’en soucie. Les standards, c’est bien, mais un badge ne remplace pas un bon linter.
- « Hacktoberfest » : Le badge « Hacktoberfest » qui indique que ton projet participe à l’événement. C’est sympa pour les contributeurs, mais ça n’a rien à voir avec la qualité du code. Et puis, après octobre, le badge devient obsolète. Bref, du seasonal content inutile.
Comment les ajouter sans se prendre la tête ?
Ajouter des badges, c’est simple, mais il y a quelques pièges à éviter. Voici la méthode propre :
- Utilise Shields.io : C’est le service le plus complet pour générer des badges. Tu peux tout faire : coverage, version, licence, etc. Exemple pour un badge personnalisé :
[](https://example.com)
- Évite les badges cassés : Rien de pire qu’un badge
build failingqui traîne depuis 6 mois. Si un badge n’est plus pertinent, retire-le. Un README propre > un README surchargé. - Groupe les badges par thème : Regroupe les badges techniques (build, coverage) ensemble, et les badges « sociaux » (stars, downloads) ailleurs. Ça évite la surcharge visuelle.
- Teste les liens : Un badge qui renvoie vers une page 404, c’est le comble de l’anti-pro. Vérifie que tous les liens fonctionnent avant de commiter.
Conclusion : moins, mais mieux
Les badges, c’est comme les épices : une pincée, ça relève le plat, trop, et c’est immangeable. Privilégie les badges qui apportent une information utile (build, coverage, version) et évite ceux qui ne servent qu’à flatter ton ego (downloads, stars). Un README pro, c’est un README qui va à l’essentiel. Le reste, c’est du bruit.
Et si tu veux vraiment impressionner, écris du bon code. Les badges, c’est juste la cerise sur le gâteau. Le gâteau, lui, doit être bon.