L’essentiel en bref
- Le branding d’un projet open source vit surtout à quatre endroits : le logo, l’en-tête du README, l’image d’aperçu social du dépôt et les annonces de release.
- Un bon logo open source est assez simple pour se lire à 16 pixels en favicon et en petit dans une liste de dépendances.
- Les README GitHub peuvent alterner l’image d’en-tête entre versions claire et sombre grâce à l’élément HTML picture et à prefers-color-scheme.
- L’image d’aperçu social s’affiche quand quelqu’un partage le lien du dépôt : elle doit donc indiquer le nom du projet et ce qu’il fait.
- Des posts de release dans un style constant aident les utilisateurs à repérer les nouvelles versions et à les relier au même projet.
Sur cette page
Le branding d’un projet open source n’a pas besoin d’une agence de design. Il demande quatre choses faites une fois et gardées cohérentes : un logo simple, un en-tête de README lisible en mode clair et sombre, une image d’aperçu social pour quand le dépôt est partagé, et un modèle reconnaissable pour les annonces de release. Ensemble, elles disent à un visiteur en quelques secondes que le projet est suivi et a un point de vue, ce qui vaut souvent la première étoile ou le premier contributeur.
Pourquoi le branding compte pour un projet open source
Les développeurs jugent vite les projets, et ils jugent sur des signes de soin : un README clair, des releases récentes, un nom facile à retrouver. Une identité visuelle cohérente est l’un de ces signes. Elle aide aussi à retenir votre projet parmi plusieurs bibliothèques semblables, et elle donne aux contributeurs et aux intervenants de conférences quelque chose à mettre sur une slide. Rien de tout cela ne remplace une bonne documentation ; cela la rend plus facile à remarquer.
Un logo open source qui tient à 16 pixels
Votre logo apparaîtra en favicon, en avatar GitHub, en petit badge sur un site de documentation et parfois en sticker. Dessinez d’abord pour le cas le plus petit. Une seule forme marquée ou une lettre dans une police affirmée vaut mieux qu’une illustration détaillée. Exportez un SVG pour le web et des PNG transparents pour tout le reste ; SVG ou PNG explique lequel utiliser où, et le design d’un favicon couvre les tailles minuscules.
Difficile à utiliser
- Une mascotte détaillée aux traits fins
- Cinq couleurs qui disparaissent en petit
- Un logotype trop long pour se lire dans un avatar
- Seulement un PNG sur fond blanc
Facile à utiliser
- Une forme ou une lettre lisible à 16 px
- Une ou deux couleurs plus un fond
- Un signe court pour les avatars, un logotype pour les en-têtes
- SVG plus PNG transparent, versions claire et sombre
Posez le signe sur un fond dégradé pour les avatars et les en-têtes, et il cesse de ressembler à une icône par défaut. Gardez le dégradé calme derrière le logo, là où il se place ; le logo sur fond dégradé explique comment.
Un en-tête de README qui tient en mode sombre
Beaucoup de développeurs lisent GitHub en mode sombre, et un en-tête pensé pour le blanc brillera comme une torche. GitHub accepte l’élément HTML <picture> dans le Markdown : vous pouvez donc servir une version claire et une version sombre du même en-tête. Une bannière de 1200×600, le format d’une bannière de blog, est une largeur confortable pour un README. Le design du mode sombre couvre le côté couleur.
<p align="center">
<picture>
<source media="(prefers-color-scheme: dark)" srcset="./.github/header-dark.png">
<img alt="Tidepool: a tiny job queue for Postgres" src="./.github/header-light.png" width="600">
</picture>
</p>Mettez trois choses sur l’en-tête : le logo, le nom du projet et une description en une ligne. Badges, commandes d’installation et captures d’écran vont dessous, en texte, où on peut les copier et les tenir à jour.
Comment ajouter une image d’aperçu social GitHub
Quand quelqu’un colle le lien de votre dépôt dans une discussion, un forum ou un post, la plateforme affiche son image d’aperçu social. Sans elle, GitHub génère une carte par défaut à partir des informations du dépôt. Vous pouvez importer la vôtre dans les Settings du dépôt, sous Social preview ; GitHub y indique ses dimensions recommandées. Créez-la à partir de votre modèle maître d’aperçu de lien en 1200×630 et gardez les mots au centre, pour que de petites différences de forme ne rognent rien. La taille d’une image Open Graph explique les recadrages, et les balises Open Graph couvrent la même image pour votre site de documentation.
Un aperçu social en 1200×630 : le nom, une ligne, rien près des bords.
Des visuels d’annonce de release que l’on remarque
Beaucoup d’utilisateurs apprennent une nouvelle version par un post plutôt que par le changelog. Un visuel de release constant, avec le même fond et la même mise en page où seuls le numéro de version et le titre changent, habitue les gens à reconnaître vos annonces. Ouvrez avec ce que les utilisateurs peuvent faire désormais, pas avec le seul numéro de version.
Un post de release pour X ou Bluesky en 1600×900 : la fonctionnalité ouvre, la version soutient.
La version carrée pour LinkedIn en 1200×1200, qui liste les temps forts.
Format
Où il apparaît
Format
Où il apparaît
Format
Où il apparaît
Format
Où il apparaît
Format
Où il apparaît
Format
Où il apparaît
- 1
Créez le signe
Une forme ou une lettre, testée à 16 px. Exportez en SVG et PNG transparent.
- 2
Choisissez un fond
Un dégradé ou une couleur qui s’accorde avec les thèmes sombre et clair de GitHub.
- 3
Construisez l’en-tête du README
Versions claire et sombre, logo, nom et une ligne.
- 4
Importez l’aperçu social
Settings du dépôt, Social preview. Testez en collant le lien dans une discussion.
- 5
Faites un modèle du post de release
Gardez la mise en page ; changez la version et le titre à chaque fois.
Gradiently convient aux mainteneurs qui préfèrent ne pas ouvrir un outil de design. Il fonctionne dans ChatGPT, Claude et tout assistant qui prend en charge les serveurs MCP distants : vous pouvez demander un visuel de release en écrivant les notes de version, et le design s’ouvre dans le Studio pour une dernière vérification. Les designs reposent sur un Mark, un fond dégradé avec lequel personne d’autre ne peut exporter une fois que vous l’avez réservé : l’image de votre projet est vraiment la sienne. Le guide de configuration MCP prend quelques minutes.
Les questions qu’on nous pose
Comment ajouter une image d’aperçu social à un dépôt GitHub ?
Ouvrez les Settings du dépôt, trouvez Social preview et importez une image. GitHub y indique ses dimensions recommandées ; gardez le texte au centre pour que rien d’important ne soit rogné.
Comment faire changer une image de README en mode sombre ?
Utilisez l’élément HTML picture avec une source pour prefers-color-scheme: dark et un repli img pour le clair. GitHub l’affiche dans les fichiers Markdown.
Un projet open source a-t-il besoin d’un logo ?
Ce n’est pas obligatoire, mais un logo simple rend le projet plus facile à reconnaître dans les avatars, la documentation et les conférences. Dessinez-le pour qu’il se lise à la taille d’un favicon.
Que doit contenir un visuel d’annonce de release ?
Le nom du projet, la version, et la fonctionnalité phare écrite comme ce que les utilisateurs peuvent faire désormais. Gardez la même mise en page pour chaque release.
Écrit par Gradiently
L’équipe derrière Gradiently, un outil de création construit autour des Marks : des dégradés vivants qui donnent à tout ce que vous créez votre propre signature.
Voir notre profil