Comment contribuer et lancer un projet open source

17 juil. 2025

Contribuer à un projet open source

Le plus important :

Trouver un projet adapté
Choisir un projet qui vous passionne

Utiliser potentiellement des plateformes de découverte

GitHub Explore : Filtrez par langage et explorez les projets tendance
CodeTriage : Inscrivez-vous pour recevoir des issues quotidiennes
Up For Grabs : Site dédié aux issues pour débutants
First Contributions : Dépôt d'entraînement pour votre première

Comprendre le projet

Lire la documentation et le README
Explorer les issues ouvertes et les discussions

Préparation à la contribution

Forker le projet depuis la forge (Github par exemple)

usecase : Imaginons ajouter de la doc sur la fonction de login de l'application

Exemple via Github par exemple

# Forker le projet via l'interface GitHub
# Puis cloner votre fork
git clone https://github.com/votre-username/projet.git
cd projet

# Ajouter le dépôt original comme "upstream"
git remote add upstream https://github.com/original/projet.git

# Créer une branche pour votre contribution
git checkout -b doc-login

Comprendre la structure

Examinez l'arborescence des fichiers
Identifiez les composants principaux et l'architecture du logiciel
Localisez les tests existants (si il y en a)

Prérequis technique

Processus de contribution

Types de contributions pour débutants :

Documentation : Corriger des typos, clarifier des explications
Traduction : Traduire le README ou la documentation
Tests : Ajouter des tests unitaires manquants
Bugs simples : Corriger des problèmes étiquetés "good first issue"

Exemple de workflow complêt de contribution du point vue VCS

Pour notre exemple

# Mettre à jour votre fork
git fetch upstream
git checkout main
git merge upstream/main

# Créer une branche pour votre travail
git checkout -b ajouter-doc

# Faire vos modifications...
# Ajouter et commiter
git add .
git commit -m "test: ajouter doc pour la fonction de login"

# Pousser vers votre fork
git push origin ajouter-doc

# Créer une Pull Request via GitHub

Gestion des dépendances : cas d'usage en ruby

# Forker le projet via l'interface GitHub
# Puis cloner votre fork
git clone https://github.com/votre-username/projet-ruby.git
cd projet-ruby

# Ajouter le dépôt original comme "upstream"
git remote add upstream https://github.com/original/projet-ruby.git

# Installer les dépendances
bundle install

Anatomie d'une "pull request" réussie

Titre et description

feat: ajouter la doc sur le formulaire d'inscription et la fonction de login

Cette PR ajoute la doc inline et des modifications dans le Readme pour la fonction de login.

FIX issue #123

Changements:
- Ajout doc inline & commentaires
- Modification README

Bonnes pratiques

Suivre les conventions
- Style de code
- Format des commits
- Processus de pull request
Communiquer efficacement
- Être précis dans vos descriptions
- Répondre aux retours avec ouverture
- Respecter la gouvernance du projet :
  - lire les règles dans leCODE_OF_CONDUCT.md
  - les les processus dans le CONTRIBUTING.md

Lancer votre propre projet

Structurer votre projet

Cela peut dépendre de votre projet

Structure de base

projet/
├── .github/
│   ├── ISSUE_TEMPLATE/
│   │   ├── bug_report.md
│   │   └── feature_request.md
│   └── workflows/
│       └── ci.yml
├── docs/
│   ├── installation.md
│   └── usage.md
├── src/ (ou lib/, app/, etc.)
├── tests/
├── .gitignore
├── CODE_OF_CONDUCT.md
├── CONTRIBUTING.md
├── LICENSE
└── README.md

Documentations essentielles

CONTRIBUTING.md
- Guide pour les contributeurs
- Processus de développement
- Standards de code

Utilisez le Markdown !

## Guide de Contribution Détaillé

### Exemple de CONTRIBUTING.md
```markdown
# Guide de Contribution

Merci de votre intérêt pour contribuer à notre projet !

## Processus de développement

1. Forker le projet
2. Créer une branche (`git checkout -b feature/amazing-feature`)
3. Commiter vos changements (`git commit -m 'feat: add amazing feature'`)
4. Pousser vers la branche (`git push origin feature/amazing-feature`)
5. Ouvrir une Pull Request

## Conventions de commit

Nous suivons les [Conventional Commits](https://www.conventionalcommits.org/):

- `feat:` Nouvelle fonctionnalité
- `fix:` Correction de bug
- `docs:` Changements dans la documentation
- `style:` Formatage, point-virgules manquants, etc.
- `refactor:` Refactorisation de code
- `test:` Ajout ou correction de tests
- `chore:` Tâches de maintenance

## Style de code

- Utilisez Rubocop avec notre configuration
- Exécutez `npm run lint` avant de soumettre
- Les tests doivent passer (`rake spec`)

## Revue de code

- Chaque PR nécessite au moins une approbation
- Les commentaires doivent être adressés avant la fusion
- Les CI checks doivent passer

CODE_OF_CONDUCT.md
- Comportements attendus
- Procédures en cas de violation

Utilisez le Markdown !



# Code de Conduite

## Notre engagement

Nous nous engageons à créer un environnement ouvert et accueillant pour tous, indépendamment de l'âge, de la taille, du handicap, de l'ethnicité, de l'identité et expression de genre, du niveau d'expérience, de la nationalité, de l'apparence, de la race, de la religion ou de l'identité et orientation sexuelle.

## Nos standards

Exemples de comportements qui contribuent à créer un environnement positif :
- Utiliser un langage accueillant et inclusif
- Respecter les différents points de vue et expériences
- Accepter gracieusement les critiques constructives
- Se concentrer sur ce qui est meilleur pour la communauté
- Faire preuve d'empathie envers les autres membres

Exemples de comportements inacceptables :
- Utilisation de langage ou d'images à caractère sexuel
- Trolling, commentaires insultants/désobligeants, 
attaques personnelles ou politiques
- Harcèlement public ou privé
- Publication d'informations privées sans autorisation
- Autre conduite qui pourrait raisonnablement être considérée comme inappropriée

## Application

Les violations du code de conduite peuvent être signalées à l'équipe du projet à [email@exemple.com]. Toutes les plaintes seront examinées et feront l'objet d'une réponse appropriée aux circonstances.

Rédiger un README Exemplaire

README.md

Description du projet
Instructions d'installation
Guide d'utilisation rapide
Exemples concrets

Structure recommandée

Utilisez le Markdown !

Utilisez des badges

# Nom du Projet

[![Build Status](https://super-ci-perso.com/username/projet.svg?branch=main)](https://super-ci-perso.com/username/projet)

[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)

> Description concise en une ligne du projet

![Capture d'écran ou démo](screenshot.png)

## Fonctionnalités

- Fonctionnalité A qui résout X
- Fonctionnalité B qui améliore Y
- Support pour Z

## Installation

```bash
gem install mon-projet

## Quickstart

<exemple d'usage CLI>
ou/et
<exemple de code pour une lib>

## Documentation

Pour une documentation complète, visitez docs/.

## Contribuer

Les contributions sont bienvenues ! Consultez CONTRIBUTING.md.
Licence

MIT © [Votre Nom]

Remarque : ici les exemples sont en fançais, mais il est conseillé de les faire en anglais !

Choisir une Licence

Licences permissives
- MIT : simple et permissive
- Apache 2.0 : protection des brevets
- BSD : variantes selon les restrictions
Licences copyleft
- GPL : code dérivé doit rester open source
- AGPL : inclut l'utilisation réseau (SaaS)
Considérations
- Compatibilité avec d'autres licences
- Objectifs de votre projet

En synthèse

Comparaison détaillée

Licence	Permet usage commercial	Permet modification	Exige partage modifications	Protection brevets
MIT, BSD	✅	✅	❌	❌
Apache 2.0	✅	✅	❌	✅
GPL 3.0	✅	✅	✅	✅
AGPL 3.0	✅	✅	✅ (même pour usage réseau)	✅

Exemple d'ajout de licence

# Télécharger une licence MIT 
curl https://opensource.org/licenses/MIT > LICENSE 

# Personnaliser avec votre nom et année 
sed -i 's/\[year\]/2023/' LICENSE 
sed -i 's/\[fullname\]/Votre Nom/' LICENSEbash

Exemple de changelog

Remarque : utiliser du conventional Commit & du Renovate

# Changelog

Toutes les modifications notables apportées à ce projet seront documentées dans ce fichier.

## [1.1.0] - 2023-09-15

### Ajouté
- Nouvelle fonctionnalité 
- Nouvelle fonctionnalité 2

### Modifié
- Fonctionnalité B
- Fonctionnalité C

### Corrigé
- Bug #123: Bug A
- Bug #124: Bug B

## [1.0.0] - 2023-08-01

### Ajouté

- Première version stable
- Documentation complète
- Tests automatisés

Cas d'usage Ruby (Gem)

Structure de base d'une gem Ruby

ma_gem/
├── .github/
│   ├── ISSUE_TEMPLATE/
│   │   ├── bug_report.md
│   │   └── feature_request.md
│   └── workflows/
│       └── ci.yml
├── bin/
│   ├── console
│   └── setup
├── lib/
│   ├── ma_gem/
│   │   ├── version.rb
│   │   └── core.rb
│   └── ma_gem.rb
├── spec/
│   ├── spec_helper.rb
│   └── ma_gem_spec.rb
├── .gitignore
├── .rspec
├── .rubocop.yml
├── CODE_OF_CONDUCT.md
├── CONTRIBUTING.md
├── Gemfile
├── LICENSE.txt
├── ma_gem.gemspec
├── Rakefile
└── README.md

Exemple de .gitignore pour Ruby

/.bundle/ 
/.yardoc 
/_yardoc/ 
/coverage/ 
/doc/ 
/pkg/ 
/spec/reports/
/tmp/ 
*.gem 
*.rbc 
.DS_Store 
.byebug_history 
.ruby-version 
.ruby-gemset

Exemple de gemspec

# ma_gem.gemspec
require_relative 'lib/ma_gem/version'

Gem::Specification.new do |spec|
  spec.name          = "ma_gem"
  spec.version       = MaGem::VERSION
  spec.authors       = ["Votre Nom"]
  spec.email         = ["votre.email@exemple.com"]

  spec.summary       = "Description courte de ma gem"
  spec.description   = "Description plus longue expliquant ce que fait ma gem"
  spec.homepage      = "https://github.com/username/ma_gem"
  spec.license       = "MIT"
  spec.required_ruby_version = Gem::Requirement.new(">= 2.7.0")

  spec.metadata["homepage_uri"] = spec.homepage
  spec.metadata["source_code_uri"] = "https://github.com/username/ma_gem"
  spec.metadata["changelog_uri"] = "https://github.com/username/ma_gem/blob/main/CHANGELOG.md"

  # Spécifier quels fichiers doivent être inclus dans la gem
  spec.files = Dir.chdir(File.expand_path('..', __FILE__)) do
    `git ls-files -z`.split("\x0").reject { |f| f.match(%r{^(test|spec|features)/}) }
  end
  spec.bindir        = "exe"
  spec.executables   = spec.files.grep(%r{^exe/}) { |f| File.basename(f) }
  spec.require_paths = ["lib"]

  # Dépendances
  spec.add_dependency "activesupport", "~> 6.1"
  
  spec.add_development_dependency "bundler", "~> 2.0"
  spec.add_development_dependency "rake", "~> 13.0"
  spec.add_development_dependency "rspec", "~> 3.0"
  spec.add_development_dependency "rubocop", "~> 1.0"
end

Processus de développement : cas d'usage Ruby

On adopte le Test driven development

On applique une règle STRICTE, un change, une feature, une branche !

Voir usage de Gitflow

Forker le projet
Créer une branche (git checkout -b feature/amazing-feature)
Écrire des tests pour votre fonctionnalité
Implémenter votre fonctionnalité
S'assurer que tous les tests passent
Commiter vos changements (git commit -m 'feat: add amazing feature')
Pousser vers la branche (git push origin feature/amazing-feature)
Ouvrir une Pull Request

Conventions de commit

Nous suivons les https://www.conventionalcommits.org/:

feat: Nouvelle fonctionnalité
fix: Correction de bug
docs: Changements dans la documentation
style: Formatage, corrections RuboCop, etc.
refactor: Refactorisation de code
test: Ajout ou correction de tests
chore: Tâches de maintenance

Documentation

Nous utilisons YARD pour la documentation.

Assurez-vous de documenter les nouvelles méthodes

Exemple :

# Normalise un numéro de téléphone au format international
#
# @param phone [String] le numéro de téléphone à normaliser
# @param country_code [String] le code pays par défaut si non spécifié
# @return [String] le numéro normalisé
# @raise [InvalidPhoneError] si le numéro ne peut pas être normalisé
def normalize(phone, country_code = nil)
  # ...
end

Revue de code

Chaque PR nécessite au moins une approbation
Les tests CI doivent passer
La couverture de code ne doit pas diminuer

Configuration CI/CD pour Ruby

Utilisation d'outil de contrôle de la qualité du code : Rubocop

Utilisation de test par spécificatio : rspec

Exemple : GitHub Actions pour un projet Ruby

# .github/workflows/ci.yml
name: Ruby CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        ruby-version: ['2.7', '3.0', '3.1']

    steps:
    - uses: actions/checkout@v3
    - name: Set up Ruby ${{ matrix.ruby-version }}
      uses: ruby/setup-ruby@v1
      with:
        ruby-version: ${{ matrix.ruby-version }}
        bundler-cache: true # runs 'bundle install' and caches installed gems
    
    - name: Run RuboCop
      run: bundle exec rubocop
    
    - name: Run tests
      run: bundle exec rake
    
    - name: Upload coverage to Codecov
      uses: codecov/codecov-action@v3
      with:
        file: ./coverage/lcov.info
        fail_ci_if_error: true

  publish:
    needs: test
    if: github.event_name == 'push' && startsWith(github.ref, 'refs/tags')
    runs-on: ubuntu-latest
    
    steps:
    - uses: actions/checkout@v3
    - name: Set up Ruby
      uses: ruby/setup-ruby@v1
      with:
        ruby-version: '3.0'
        bundler-cache: true
    
    - name: Build gem
      run: gem build *.gemspec
    
    - name: Publish to RubyGems
      run: |
        mkdir -p $HOME/.gem
        touch $HOME/.gem/credentials
        chmod 0600 $HOME/.gem/credentials
        printf -- "---\n:rubygems_api_key: ${GEM_HOST_API_KEY}\n" > $HOME/.gem/credentials
        gem push *.gem
      env:
        GEM_HOST_API_KEY: ${{secrets.RUBYGEMS_API_KEY}}

Aspects Techniques généraux

Système de contrôle de version

Git: branches, tags, releases
Workflow: GitFlow ou GitHub Flow

CI/CD

Tests automatisés
Intégration continue
Déploiement continu

Documentation technique

API docs
Guides de développement

Construire une Communauté active

Canaux de communication

Issues GitHub
Canaux / chatops / chat
Forums de discussion

Reconnaissance des contributions

Fichier CONTRIBUTORS
Mentions dans les releases
Badges et récompenses, dans le README :

# Contributeurs

Merci à ces personnes merveilleuses ([emoji key](https://allcontributors.org/docs/en/emoji-key)):

<!-- ALL-CONTRIBUTORS-LIST:START -->
<!-- prettier-ignore-start -->
<!-- markdownlint-disable -->
<table>
  <tr>
    <td align="center">
      <a href="https://github.com/username1">
        <img src="https://avatars.githubusercontent.com/username1" width="100px;" alt=""/>
        <br /><sub><b>Nom Complet</b></sub>
      </a>
      <br />
      <a href="#code" title="Code">💻</a>
      <a href="#doc" title="Documentation">📖</a>
    </td>
    <td align="center">
      <a href="https://github.com/username2">
        <img src="https://avatars.githubusercontent.com/username2" width="100px;" alt=""/>
        <br /><sub><b>Autre Nom</b></sub>
      </a>
      <br />
      <a href="#test" title="Tests">⚠️</a>
    </td>
  </tr>
</table>
<!-- markdownlint-restore -->
<!-- prettier-ignore-end -->
<!-- ALL-CONTRIBUTORS-LIST:END -->

Gouvernance

Processus de décision
Rôles et responsabilités

Promouvoir Votre Projet

Présence en ligne

diffuser sur un Site web dédié ou de l'organisation
Réseaux sociaux : lien vers le GitXXX et/ou doc à chaque realease/
Articles de blog lié au sujet ou la technologie.

Démonstrations

Vidéos tutoriels : youtube
Présentations / support
Études de cas

Participation à des événements

Conférences
Hackathons
Meetups

Maintenir le Projet

C'est la que les choses deviennent sérieuse, maintenir le projet va nécessite de traiter le MCO/MCS de la solution de façon régulière !

Il est souhaitable si le projet est gros de savoir accepter l'aide et la contribution et savoir créer une communauté.

Gestion des versions

Versionnement sémantique
Notes de version
Roadmap publique

Répondre aux contributions

Revues de code
Feedback constructif
Mentoring

Évolution du projet

Adaptabilité
Rétrocompatibilité
Dépréciation responsable

Romain GEORGES

Open Source evangelist & Ruby enthousiast

L’histoire des systèmes d’exploitations

Trust me i'm an Expert

De la bonne consommation de l’open source