Conventions d'équipe¶

Standards, linting, commits et templates pour une base de code cohérente et une collaboration sans friction.

Pourquoi des conventions¶

Sans conventions partagees, chaque développeur applique ses propres préférences. Le résultat : une base de code qui ressemble a un patchwork, des reviews qui perdent du temps sur le style plutôt que le fond, et des conflits culturels inutiles.

Les conventions sont des décisions collectives, prises une fois, appliquees automatiquement. Leur valeur n'est pas d'imposer le meilleur style — c'est d'éliminer les décisions repetitives pour libérer l'énergie vers des problèmes réels.

La règle des conventions

Une convention non documentee n'est pas une convention — c'est une préférence individuelle. Une convention non enforced automatiquement finit par être ignoree.

Standards de codage¶

Choisir ses standards¶

Ne reinventez pas les standards : utilisez les guides établis dans votre écosystème et ajustez à la marge.

Langage	Guide de référence	Remarque
Python	PEP 8, Google Python Style	Ruff intégré la majorité des règles
JavaScript	Airbnb, StandardJS	ESLint + Prettier pour l'enforcement
TypeScript	ESLint + typescript-eslint	Strictness par paliers
Go	gofmt (officiel)	Pas de debat — un seul format
Rust	rustfmt (officiel)	Idem, impose par le toolchain
Java	Google Java Format, Checkstyle	Formatter + linter distincts

Ce qu'un standard doit couvrir¶

Indentation (espaces vs tabs, largeur)
Longueur maximale de ligne
Nommage (variables, fonctions, classes, constantes)
Imports (ordre, groupement, pas d'imports inutilises)
Structure de fichier (un fichier = une responsabilité)

EditorConfig : le socle minimal¶

.editorconfig est compris par la majorité des éditeurs sans plugin. C'est le premier fichier a ajouter dans tout projet multi-développeurs.

root = true

[*]
indent_style = space
indent_size = 4
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[*.{js,ts,json,yaml,yml}]
indent_size = 2

[Makefile]
indent_style = tab

Linting partage¶

Le problème des configs individuelles¶

Si chaque dev a sa propre config ESLint ou Ruff en local, les règles divergent silencieusement. La CI devient le seul arbitre — et elle renvoie des erreurs surprenantes.

Solution : config versionnee dans le dépôt¶

projet/
  .editorconfig
  .eslintrc.json        # ou eslint.config.js
  pyproject.toml        # [tool.ruff] et [tool.mypy]
  .pre-commit-config.yaml

Configs partageables¶

Pour les organisations avec plusieurs projets, publiez une config partagee :

// .eslintrc.json
{
  "extends": ["@mon-org/eslint-config"],
  "rules": {
    // surcharges specifiques au projet
  }
}

Conventions de commits¶

Conventional Commits¶

Le standard Conventional Commits structure les messages de commit de façon parseable.

<type>[scope optionnel]: <description>

[corps optionnel]

[footer optionnel]

Types courants :

Type	Usage
`feat`	Nouvelle fonctionnalité
`fix`	Correction de bug
`docs`	Documentation uniquement
`style`	Formatage, sans changement de logique
`refactor`	Ni feature ni bug fix
`test`	Ajout ou modification de tests
`chore`	Build, CI, dépendances — pas de code de production
`perf`	Amélioration de performance

Exemples :

feat(auth): ajouter la connexion via OIDC

fix(panier): corriger le calcul de TVA pour les DOM

docs: mettre a jour le guide d'installation

chore(deps): passer pytest a 8.1.0

BREAKING CHANGE

Signalez un changement incompatible avec ! après le type ou un footer BREAKING CHANGE:. Cela permet de générer automatiquement les changelogs et de versionner semantiquement.

feat(api)!: supprimer l'endpoint /v1/users deprecie

Conventions de branches¶

Choisissez un schéma et documentez-le dans votre CONTRIBUTING.md.

feature/<ticket>-description-courte
bugfix/<ticket>-description-courte
hotfix/<ticket>-description-courte
release/1.2.0
chore/mise-a-jour-dependances

Templates de MR/PR¶

Un template de MR assure que chaque contribution contient les informations nécessaires pour une review efficace.

## Description

Decrivez le changement et son contexte.

## Ticket

Fixes #<numero>

## Type de changement

- [ ] Bugfix
- [ ] Nouvelle feature
- [ ] Refactoring
- [ ] Documentation
- [ ] Breaking change

## Comment tester

1. ...
2. ...

## Checklist

- [ ] Tests ajoutes ou mis a jour
- [ ] Documentation mise a jour si necessaire
- [ ] Pas de console.log / print de debug
- [ ] Self-review effectuee

Placez ce fichier dans .gitlab/merge_request_templates/default.md (GitLab) ou .github/pull_request_template.md (GitHub).

Enforcement automatique¶

Convention	Outil	Moment d'exécution
Format de code	Prettier, Black, gofmt	pre-commit hook + CI
Lint	ESLint, Ruff, Checkstyle	pre-commit hook + CI
Message de commit	commitlint	commit-msg hook
Nom de branche	Regex CI (GitLab rules)	Au push
Secrets	detect-secrets, gitleaks	pre-commit hook + CI
Types Python	mypy, pyright	CI (optionnel en pre-commit)

Configuration pre-commit¶

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.6.0
    hooks:
      - id: trailing-whitespace
      - id: end-of-file-fixer
      - id: check-yaml
      - id: check-merge-conflict

  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.4.0
    hooks:
      - id: ruff
      - id: ruff-format

  - repo: https://github.com/commitizen-tools/commitizen
    rev: v3.24.0
    hooks:
      - id: commitizen

Ne pas punir les devs avec les hooks

Les hooks pre-commit doivent être rapides (< 5 secondes) et auto-correctifs quand possible. Un hook qui bloque 30 secondes sur chaque commit sera désactivé ou bypasse avec --no-verify.

Points clés¶

EditorConfig est le premier outil a ajouter dans tout projet partagee
Versionnez vos configs de linting dans le dépôt, pas dans les dotfiles personnels
Conventional Commits rend vos changelogs generables automatiquement
Automatisez l'enforcement via pre-commit et CI — pas via la bonne volonte
Les templates de MR reduisent les allers-retours en review

Précédent : Pair et Mob programming | Suite : Inner source