LaunchRepoRéponse courte
- Commencez par le dépôt lui-même : un README qui dit quoi, pourquoi et comment démarrer, une licence, jusqu’à 20 topics GitHub et une image d’aperçu social.
- Allez ensuite là où vos utilisateurs discutent déjà : le forum, le chat ou le subreddit de votre langage ou framework, puis Show HN dès qu’on peut lancer le projet sans créer de compte.
- Sollicitez les mainteneurs d’une ou deux awesome lists adaptées, en suivant les règles de contribution propres à chaque liste.
- Inscrivez un site web ou une version hébergée dans quelques annuaires et plateformes de lancement, et continuez de publier des releases. Une activité régulière continue d’amener de nouveaux visiteurs.
La carte de distribution de l’open source
En open source, la découverte se fait sur quatre niveaux. Chacun s’appuie sur le précédent : un post dans une communauté envoie les gens vers votre dépôt, et c’est donc le dépôt qui doit d’abord les convaincre.
- 1 · Le dépôtCe que chaque visiteur voit en premier.
- README
- Licence
- Topics
- Aperçu social
- Releases
- 2 · La découverte sur GitHubComment on vous trouve à l’intérieur de GitHub.
- Pages de topics
- Recherche GitHub
- Explore
- Étoiles et listes
- 3 · Les communautésLà où vos utilisateurs discutent déjà.
- Show HN
- Forums et chats de l’écosystème
- Subreddits
- Réponses en Q&R
- 4 · Sélectionné et référencéLes endroits qui continuent de pointer vers vous.
- Awesome lists
- Registres de paquets
- Annuaires
- Newsletters
Construisez votre plan de quatre semaines
Répondez à huit questions et collez vos topics. Le planificateur vérifie les topics selon les règles de GitHub et place chaque canal dans une semaine, marqué comme prêt ou avec ce qu’il faut corriger d’abord. Tout s’exécute dans votre navigateur ; rien n’est envoyé ni stocké.
Rendez le dépôt facile à trouver
Chaque canal de cette page mène à la page de votre dépôt. La documentation de GitHub indique à quelles questions un README doit répondre ; le tableau en tire un contenu concret pour le premier écran.
| Élément | Ce dont le visiteur a besoin | Ce qui marche |
|---|---|---|
| Ce que fait le projet | Décider en quelques secondes s’il répond à son problème | Une phrase sous le titre, avec les mots que vos utilisateurs taperaient dans une recherche |
| Pourquoi il est utile | Une raison de le choisir plutôt que l’alternative évidente | Une différence concrète, ou une courte comparaison |
| Comment démarrer | Un premier succès en quelques minutes | Une commande d’installation et un exemple minimal qui fonctionne tel quel une fois collé |
| Le montrer en action | Une preuve avant d’installer | Une capture d’écran, un GIF ou un enregistrement de terminal en haut de page |
| Où trouver de l’aide | La certitude de ne pas rester seul | Liez les Issues, les Discussions ou un chat ; précisez ce qui va où |
| Qui le maintient | La confiance que le projet est vivant | Mainteneurs, release récente, guide de contribution |
Topics : jusqu’à 20 portes d’entrée dans la recherche GitHub
- Combinez les quatre types que GitHub suggère : usage (cli, static-site-generator), sujet (accessibility), communauté (hacktoberfest) et langage (rust).
- Utilisez les topics que les gens parcourent vraiment. Ouvrez github.com/topics/ et vérifiez qu’un topic contient déjà des dépôts.
- GitHub propose aussi des topics pour les dépôts publics. Acceptez ceux qui conviennent et refusez les autres.
Aperçu social
Sans image, un lien partagé affiche quelques informations de base sur le dépôt et votre avatar. Une image claire de 1280 × 640 avec le nom du projet et une ligne qui dit à quoi il sert rend chaque partage reconnaissable. Vérifiez la taille et le format avec le vérificateur gratuit de taille d’image avant de la téléverser. Vérifiez vos images de lancement selon les tailles des plateformes →
| Règle | Formulation officielle | Ce que cela signifie pour vous |
|---|---|---|
| README | A README is often the first item a visitor will see when visiting your repository. | Traitez le README comme votre page d’accueil : le premier écran décide si les gens restent. |
| Taille du README | When your README is viewed on GitHub, any content beyond 500 KiB will be truncated. | Les README trop longs sont tronqués. Déplacez la référence détaillée dans la documentation et ajoutez un lien. |
| Types de topics | Helpful topics to classify a repository include the repository's intended purpose, subject area, community, or language. | Choisissez des topics qui couvrent usage, sujet, communauté et langage, pas dix variantes d’un même mot. |
| Format des topics | Use lowercase letters, numbers, and hyphens. Use 50 characters or less. Add no more than 20 topics. | Le vérificateur du planificateur applique exactement ces trois règles. |
| Aperçu social | Your image should be a PNG, JPG, or GIF file under 1 MB in size. For the best quality rendering, we recommend a size of at least 640 by 320 pixels (1280 by 640 pixels for best display). | Préparez un PNG ou un JPG de 1280 × 640 de moins de 1 Mo. |
| Profil communautaire | The community profile checklist checks to see if a project includes recommended community health files, such as README, CODE_OF_CONDUCT, LICENSE, or CONTRIBUTING, in a supported location. | Ouvrez Insights → Community Standards dans votre dépôt et ajoutez ce qui manque. |
Awesome lists : deux voies différentes
Les awesome lists sont des collections sélectionnées sur GitHub, une par sujet. Les règles souvent citées, comme les 30 jours et les quatre revues, concernent un cas bien précis. Sachez sur quelle voie vous êtes.
Voie A : votre projet entre dans une liste thématique
C’est le cas habituel pour une bibliothèque, un outil ou une application. Trouvez une ou deux listes actives sur votre sujet, lisez le fichier de contribution de cette liste et proposez une ligne dans son format. Les listes n’acceptent pas toutes la même chose : leur propre guide fait donc foi. Ce sont votre README, votre licence et votre activité récente qui convainquent le mainteneur.
Voie B : votre liste sélectionnée entre dans la méta-liste awesome
Uniquement si vous maintenez vous-même une liste. Le modèle strict de la méta-liste s’applique alors : au moins 30 jours d’existence, relire 4 autres pull requests ouvertes, lancer awesome-lint, une licence Creative Commons, les topics awesome et awesome-list, et un titre de la forme « Add Name of List ».
| Règle | Formulation officielle | Ce que cela signifie pour vous |
|---|---|---|
| Ajout à une liste | If you have something awesome to contribute to an awesome list, this is how you do it. | Chaque liste explique sa propre procédure. Lisez le guide de contribution de cette liste, pas un guide général. |
| Âge de la liste | That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent. | Uniquement pour les listes qui veulent entrer dans la méta-liste awesome : attendez 30 jours après le premier vrai commit. |
| Revues | Just commenting “looks good” or simply marking the pull request as approved does not count! | Pour la méta-liste, il faut relire au moins 4 autres pull requests ouvertes, avec de vrais retours. |
| IA | Fully AI-generated pull requests are not accepted. | Rédigez la pull request vous-même. Une pull request entièrement générée est fermée. |
| Licence | A code license like MIT, BSD, Apache, GPL, etc, is not acceptable. | Une liste doit être sous licence Creative Commons, CC0 de préférence. Les licences de code ne comptent pas. |
| Qualité | Only has awesome items. Awesome lists are curations of the best, not everything. | Les listes retiennent le meilleur, pas tout. Ce sont votre README et votre activité qui vous y font entrer. |
Nous citons les règles telles qu’elles étaient à la date de vérification ; les mainteneurs les mettent à jour. LaunchRepo n’ouvre pas de pull requests et ne contacte pas les mainteneurs de listes à votre place.
Les communautés qui accueillent les projets
L’open source a ici un avantage : beaucoup de communautés de développeurs voient d’un bon œil un projet qui fonctionne, tant qu’il résout un vrai problème et que vous restez pour répondre aux questions.
| Canal | Idéal pour | Première étape |
|---|---|---|
| Show HN (Hacker News) | Les outils que l’on peut lancer tout de suite | Publiez une fois, restez dans le fil, répondez à chaque question |
| Le forum ou le chat de votre écosystème | Bibliothèques et plugins pour un langage ou un framework | Lisez les règles de présentation de projets, puis publiez un cas d’usage, pas un slogan |
| Un subreddit adapté | Les projets qui ont un public clair sur Reddit | Vérifiez d’abord la règle d’autopromotion de chaque subreddit |
| Réponses en Q&R | Les projets qui résolvent une question récurrente | Répondez complètement à la question ; mentionnez le projet là où il aide vraiment |
| Newsletters hebdomadaires de votre écosystème | Les releases qui ont une histoire | Envoyez une courte note avec le lien de la release aux rédacteurs |
| Meetups et conférences | Les projets qui ont une leçon à transmettre | Commencez par un meetup local autour de votre langage |
Dans notre jeu de données public regroupant les 15 859 posts Show HN qui renvoyaient vers un dépôt de code entre septembre 2025 et août 2026, le post médian a obtenu 2 points et 9,5 % ont atteint 10 points ou plus. Un post est un début, pas le plan.
Comment lancer votre projet sur Show HN →Promouvoir votre SaaS sur Reddit sans enfreindre les règles →
| Règle | Formulation officielle | Ce que cela signifie pour vous |
|---|---|---|
| Ce qui convient | Show HN is for something you've made that other people can play with. | Quelque chose que l’on peut lancer, pas une annonce ni une landing page. |
| Substance | The project should be non-trivial. Don't post quickly-generated one-offs; anybody can do that now. | Publiez un projet dans lequel vous avez mis un vrai travail et dont vous pouvez parler. |
| Obstacles | Please make it easy for users to try your thing out, ideally without barriers such as signups or emails. | Un dépôt public avec une seule commande d’installation, c’est le Show HN idéal. |
| Votes | Please don't ask friends to upvote or comment. That's not ok on HN. | Partagez le lien sans demander de votes. Laissez le travail parler. |
| Ciblage | Don’t spam as many people as possible. Instead, target your efforts to communities that will benefit from knowing about your project. | Choisissez quelques communautés où le projet résout un vrai problème. |
| Réputation | the best way to invite people to share and contribute to your project is to share and contribute to their projects. | Aidez d’abord sur d’autres projets. Les gens le remarquent et regardent le vôtre. |
Annuaires et plateformes de lancement
Dès qu’il existe un site web, un site de documentation ou une version hébergée, quelques annuaires deviennent une source régulière de visiteurs et de liens supplémentaires. Trois d’entre eux conviennent bien à l’open source :
- AlternativeTo : quand votre projet est une alternative gratuite à un logiciel connu.
- SourceForge : héberge des projets open source avec téléchargements via sa procédure Create a Project, distincte de ses fiches de logiciels professionnels.
- Product Hunt : pour les projets à l’interface soignée, avec un jour de lancement auquel vous pouvez être présent.
Choisissez les plateformes selon leur public et vérifiez les règles en vigueur de chacune ; une fiche est une porte d’entrée, pas une garantie d’utilisateurs. Lancez votre outil développeur sur 299 annuaires avec votre propre agent →
Ce qu’il vaut mieux laisser de côté
- Des étoiles achetées ou échangées
- Les règles de GitHub interdisent la manipulation des classements, et la recherche montre que les étoiles achetées n’aident que brièvement. Les détails, avec notre propre mesure : Gagner des étoiles GitHub en étant vraiment utile →
- Demander à des amis de voter
- Hacker News le dit sans détour : ce n’est pas acceptable. Les votes d’un groupe d’amis ne vous apprennent d’ailleurs rien sur l’intérêt réel.
- Le même post partout
- Des annonces copiées-collées dans de nombreuses communautés le même jour ressemblent à du spam. Choisissez quelques endroits et écrivez pour chacun.
- Un lancement avant le README
- L’attention est courte. Soignez le premier écran du dépôt avant de publier quoi que ce soit.
La place de LaunchRepo
LaunchRepo prend en charge le niveau des annuaires et des plateformes de lancement : votre agent de code prépare et soumet le site de votre projet à un large catalogue d’annuaires, avec un suivi qui distingue une fiche en ligne d’une fiche en attente.
Les posts dans les communautés, les demandes aux awesome lists et les conversations restent entre vos mains, car ils fonctionnent mieux avec votre propre voix. LaunchRepo vous rend les heures que prendraient les formulaires, pour que vous puissiez les consacrer à ces échanges.
Sources
Toutes les règles ont été lues le 1 octobre 2026 et sont citées mot pour mot en anglais. Des copies texte sont conservées avec nos preuves.
| Source | Dernière mise à jour | Vérifié le |
|---|---|---|
| GitHub Docs: About the repository README file | aucune date indiquée | |
| GitHub Docs: Classifying your repository with topics | aucune date indiquée | |
| GitHub Docs: Customizing your repository's social media preview | aucune date indiquée | |
| GitHub Docs: About community profiles for public repositories | aucune date indiquée | |
| GitHub Docs: Accessing a project's community profile | aucune date indiquée | |
| GitHub Docs: Saving repositories with stars | aucune date indiquée | |
| sindresorhus/awesome: pull request template | aucune date indiquée | |
| sindresorhus/awesome: contribution guidelines | aucune date indiquée | |
| Hacker News: Show HN Guidelines | aucune date indiquée | |
| Open Source Guides: Finding Users for Your Project | aucune date indiquée | |
| GitHub Acceptable Use Policies | aucune date indiquée | |
| He et al.: Six Million (Suspected) Fake Stars in GitHub (ICSE 2026, arXiv:2412.13459v2) |
Questions fréquentes
- Comment promouvoir un projet open source ?
- Commencez par le dépôt : un README qui dit quoi, pourquoi et comment démarrer, une licence, des topics et une image d’aperçu. Partagez-le ensuite dans la communauté de votre écosystème et sur Show HN dès qu’on peut l’essayer sans créer de compte, sollicitez une ou deux awesome lists adaptées et continuez de publier des releases.
- Comment faire entrer mon projet dans une awesome list ?
- Ouvrez la liste, lisez son fichier de contribution et proposez une entrée dans son format. Les règles strictes (30 jours, quatre revues, awesome-lint) ne s’appliquent que si vous soumettez votre propre liste sélectionnée à la méta-liste awesome.
- Combien de topics GitHub ajouter ?
- GitHub en autorise jusqu’à 20. Utilisez ceux qui décrivent l’usage, le sujet, la communauté et le langage, écrits en lettres minuscules, chiffres et tirets, avec 50 caractères au maximum chacun.
- Show HN est-il un bon endroit pour l’open source ?
- Oui, si l’on peut lancer le projet tout de suite et que vous pouvez rester pour répondre aux questions. Show HN demande quelque chose que l’on peut essayer, sans obstacle d’inscription, et sans demander à des amis de voter.
- Faut-il acheter des étoiles GitHub pour paraître établi ?
- Non. Les Acceptable Use Policies de GitHub interdisent la manipulation des classements, comme l’attribution automatisée d’étoiles, et une vaste étude a montré que les étoiles achetées n’aident que brièvement et nuisent sur le long terme.
- LaunchRepo publie-t-il dans les communautés à ma place ?
- Non. LaunchRepo donne à votre agent les playbooks pour les soumissions aux annuaires et aux plateformes de lancement du site de votre projet. Les posts dans les communautés et les demandes aux awesome lists restent personnels.
Laissez votre agent s’occuper des annuaires
Un seul achat, votre agent de code, tous les produits que vous construisez : votre agent utilise LaunchRepo pour soumettre le site de votre projet aux annuaires et plateformes de lancement pendant que vous parlez à vos utilisateurs.
Voir les tarifs