> For the complete documentation index, see [llms.txt](https://docs.ipcheck.ing/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ipcheck.ing/developer/fr/contributing/how-to-contribute.md).

# Comment contribuer

Discipline des branches, consignes pour les pull requests et style des messages de commit.

MyIP est open source et accueille les contributions externes. Cette page décrit le flux réellement utilisé par le projet, depuis le premier ticket jusqu’à une pull request fusionnée.

Tout ici reflète [`CONTRIBUTING.md`](https://github.com/jason5ng32/MyIP/blob/main/CONTRIBUTING.md) et `AGENTS.md` dans le dépôt. Le projet a aussi un [Code de conduite](https://github.com/jason5ng32/MyIP/blob/main/CODE_OF_CONDUCT.md) (Contributor Covenant). En participant, vous acceptez de le respecter.

## Avant d’écrire du code

Ouvrez d’abord un ticket pour tout ce qui n’est pas trivial. Une courte discussion en amont coûte moins cher qu’une pull request rejetée. Les nouvelles fonctionnalités, les changements de comportement, les nouvelles dépendances et les refactorisations entrent tous dans ce cas.

Les petites corrections évidentes — une faute de frappe, un lien cassé, un bug d’une ligne — peuvent aller directement dans une pull request.

Si vous êtes nouveau dans le projet, cherchez les tickets étiquetés `bon premier ticket`.

## Le flux

{% stepper %}
{% step %}

### Ouvrir un ticket

Décrivez le changement et pourquoi il est nécessaire. Attendez qu’un mainteneur confirme l’orientation avant d’investir du temps. Voir [Signaler des problèmes](/developer/fr/contributing/reporting-issues.md).
{% endstep %}

{% step %}

### Forkez et créez une branche à partir de `dev`

Forkez le dépôt, puis créez votre branche à partir de **`dev`** — pas `main`.

```bash
git clone https://github.com/<you>/MyIP.git
cd MyIP
git checkout dev
git checkout -b fix/mac-input-validation
```

{% endstep %}

{% step %}

### Configurer et compiler

Installez avec pnpm et lancez l’application. Voir [Environnement de dev](/developer/fr/development/dev-environment.md).

```bash
pnpm install
pnpm dev
```

{% endstep %}

{% step %}

### Apportez la modification

Une seule préoccupation par branche. Suivez les [conventions de codage](/developer/fr/development/coding-conventions.md), et ajoutez ou mettez à jour les tests dans `tests/` pour toute logique non visuelle que vous touchez.
{% endstep %}

{% step %}

### Exécutez `pnpm check`

`pnpm check` exécute la suite de tests et une compilation de production. Tout doit être vert avant que vous poussiez.

```bash
pnpm check
```

{% endstep %}

{% step %}

### Rebasez-vous sur le dernier `dev`

Rebasez — ne fusionnez pas `dev` dans votre branche. Cela garde l’historique lisible.

```bash
git fetch upstream
git rebase upstream/dev
```

{% endstep %}

{% step %}

### Ouvrez la pull request contre `dev`

Remplissez le modèle de pull request : un résumé, le type de changement et la checklist. Liez le ticket qu’elle corrige.
{% endstep %}
{% endstepper %}

## Pourquoi les pull requests ciblent `dev`

{% hint style="warning" %}
**N’ouvrez jamais une pull request contre `main`.** `main` ne reçoit que les fusions de version depuis `dev` branche. Une pull request ciblant `main` devra être redirigée vers la bonne cible.
{% endhint %}

Le dépôt est `dev` en entrée, `dev` en sortie. Tout le travail aboutit sur `dev` d’abord ; `main` ne passe que par une `dev` → `main` fusion de version. Cela maintient `main` aligné sur ce qui est publié, et cela signifie que chaque changement est testé sur `dev` d’abord.

## Règles des pull requests

* **Cible `dev`.** Voir ci-dessus.
* **Une seule préoccupation par pull request.** Ne regroupez pas une fonctionnalité avec une modification sans rapport de l’environnement de dev. Séparez-les.
* **Rebasez avant de soumettre**, afin que votre branche se place au-dessus du dernier `dev`.
* **Décrivez ce qui a changé et pourquoi.** Les relecteurs ne devraient pas avoir à reconstituer l’intention à partir du diff.
* **`pnpm check` vert.** La CI exécute `pnpm test` et `pnpm run build` sur Node 24 pour chaque pull request vers `dev` ou `main` ; une exécution rouge bloque la fusion.

## Style des messages de commit

Les commits utilisent un `Type(portée):` préfixe, repris de l’historique propre du projet. La portée est facultative et désigne la zone touchée (`ui`, `api`, un nom de fonctionnalité, un nom de module).

| Préfixe         | Utilisé pour                                     | Exemple réel du dépôt                                                                                    |
| --------------- | ------------------------------------------------ | -------------------------------------------------------------------------------------------------------- |
| `Feat(...)`     | Nouvelle capacité                                | `Feat(ui) : sélecteur de pays Globalping partagé pour MTR / latence / censure`                           |
| `Fix(...)`      | Correction de bug                                | `Fix(ui) : aligner la validation de la saisie MAC avec le backend (exactement 12 chiffres hexadécimaux)` |
| `Refactor(...)` | Restructuration, sans changement de comportement | `Refactor(country-name) : remplacer le tableau maintenu à la main par Intl.DisplayNames`                 |
| `Perf(...)`     | Travail sur les performances                     | `Perf(frontend) : charger à la demande uniquement la locale active de l’interface`                       |
| `Style(...)`    | Finition visuelle ou rédactionnelle              | `Style(toggle) : état enfoncé à contraste élevé pour les primitives de bascule`                          |
| `Chore(...)`    | Outils, dépendances, maintenance                 | `Chore : simplifier le mappage des chemins jsconfig`                                                     |

Écrivez les messages en anglais, à l’impératif, et gardez une seule préoccupation par commit.

## Règle i18n

Les langues proposées par l’interface reposent sur un registre central, `common/locale-registry.js`. Chacune porte un `statut`: un **`locale`** locale est celle dans laquelle chaque changement de texte doit impérativement atterrir, un **`bêta`** peut livrer un pack partiel et revenir à l’anglais. Le registre lui-même est la liste actuelle indiquant quelle locale a quel statut.

{% hint style="danger" %}
Tout changement qui expose du texte visible par l’utilisateur doit mettre à jour **chaque `locale` le fichier de locale dans le même commit** — y compris les `frontend/data/changelog.json` entrées. `tests/locale-packs.test.js` et `tests/changelog.test.js` enforcent cela, donc une traduction partielle échoue `pnpm check`.
{% endhint %}

Si vous ne pouvez pas écrire une locale avec assurance, ajoutez quand même la clé à chaque fichier avec votre meilleure tentative, et indiquez-le dans la pull request. Détails : [i18n](/developer/fr/development/i18n.md).

**Ajouter une nouvelle langue est une tâche différente, beaucoup plus petite** — côté front-end uniquement, généré par `pnpm i18n-new <code>`, et une traduction partielle est une première PR bienvenue. Voir [Traduire MyIP](/developer/fr/contributing/translating.md).

## Tests

La logique non visuelle qui peut s’exécuter sans appel réseau — fonctions pures, validateurs, transformations, composables avec des entrées simulables — est livrée avec une spec dans `tests/` dans le même changement. Le rendu de l’interface, le comportement réseau réel et les API du navigateur sont hors périmètre. Voir [Testing](/developer/fr/development/testing.md).

## Relecture de code

Un mainteneur relit chaque pull request. Attendez-vous à des questions, à des changements demandés ou à une discussion sur l’approche avant une fusion. C’est normal, pas un rejet.

Poussez les commits de suivi sur la même branche — la pull request se met à jour automatiquement. Si votre changement est visuel et ne peut pas être vérifié en mode headless, dites-le et joignez une capture d’écran ou un court enregistrement.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.ipcheck.ing/developer/fr/contributing/how-to-contribute.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.