# Branding de projet open source : du README aux releases [Canonical HTML page](https://gradiently.design/fr/guide/open-source-project-branding) La plupart des gens découvrent un projet open source par un aperçu de lien, un README et un post de release. Un peu de branding sur ces trois points donne l’image d’un projet suivi, fiable et digne d’une étoile. ## The short version - 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. 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](https://gradiently.design/fr/guide/svg-vs-png) explique lequel utiliser où, et [le design d’un favicon](https://gradiently.design/fr/guide/favicon-design) 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é](https://gradiently.design/fr/guide/logo-on-gradient-background) explique comment. - Bleu terminal: `linear-gradient(135deg, #0d1117 0%, #1f2a44 55%, #3b82f6 100%)` - Vert build: `radial-gradient(circle at 25% 25%, #a7f3d0 0%, #10b981 45%, #064e3b 100%)` - Violet release: `linear-gradient(160deg, #1a1033 0%, #6d28d9 50%, #f0abfc 100%)` - Ambre chaud: `linear-gradient(120deg, #fff7ed 0%, #fdba74 50%, #c2410c 100%)` Quatre fonds de projet qui s’accordent avec les thèmes sombre et clair de GitHub. Copiez-en un pour les avatars, les en-têtes et l’aperçu social. ## 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 `` 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](https://gradiently.design/fr/guide/dark-mode-design) couvre le côté couleur. ```html

Tidepool: a tiny job queue for Postgres

``` À coller en haut de README.md. GitHub montre l’image sombre aux lecteurs en mode sombre et la claire aux autres. Exportez les deux en 1200×600 et affichez-les en 600 de large pour qu’elles restent nettes sur les écrans haute densité. 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](https://gradiently.design/fr/guide/open-graph-image-size) explique les recadrages, et [les balises Open Graph](https://gradiently.design/fr/guide/open-graph-tags) couvrent la même image pour votre site de documentation. Une image d’aperçu social en paysage pour un projet open source nommé Tidepool, avec sa description en une ligne 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. Une annonce de release en paysage pour la version 2.0 d’un projet open source, titrée Des nouvelles tentatives avec backoff Un post de release pour X ou Bluesky en 1600×900 : la fonctionnalité ouvre, la version soutient. Un visuel de release carré listant les temps forts de Tidepool 2,0 sur le même dégradé La version carrée pour LinkedIn en 1200×1200, qui liste les temps forts. | Visuel | Format | Où il apparaît | | --- | --- | --- | | En-tête de README | 1200×600 px | Haut du dépôt | | Aperçu social | Modèle maître d’aperçu de lien, 1200×630 px | Liens de dépôt partagés | | Post de release | 1600×900 px | X et Bluesky | | Post de release, carré | 1200×1200 px | LinkedIn | | Bannière de communauté | 960×540 px | Bannière de serveur Discord | | Aperçu du site de documentation | 1200×630 px | Liens de documentation partagés | Le jeu de travail d’un projet. Un design maître les couvre tous. 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](https://gradiently.design/fr/developers/mcp) prend quelques minutes. ## FAQ ### 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.