> 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

MyIP est open source et accueille les contributions externes. Cette page décrit le flux réellement utilisé par le projet, depuis la première issue jusqu'à une pull request fusionnée.

Tout ce qui est 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 une issue 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 refactorings sont tous concernés.

Les corrections petites et évidentes — une faute de frappe, un lien brisé, un bug en une ligne — peuvent aller directement dans une pull request.

Si vous êtes nouveau dans le projet, cherchez les issues étiquetées `bonne première issue`.

## Le flux

{% stepper %}
{% step %}

### Ouvrez une issue

Décrivez la modification et pourquoi elle est nécessaire. Attendez qu'un mainteneur confirme la direction avant d'y consacrer du temps. Voir [Signaler des issues](/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 faites fonctionner l'application. Voir [Environnement de développement](/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 code](/developer/fr/development/coding-conventions.md), et ajoutez ou mettez à jour les tests dans `tests/` pour toute logique non visuelle que vous modifiez.
{% endstep %}

{% step %}

### Exécutez `pnpm check`

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

```bash
pnpm check
```

{% endstep %}

{% step %}

### Rebasez sur la dernière version de `dev`

Rebase — ne fusionnez pas `dev` dans votre branche. Cela conserve un 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 l'issue qu'elle corrige.
{% endstep %}
{% endstepper %}

## Pourquoi les pull requests ciblent `dev`

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

Le dépôt est `dev` dans, `dev` dehors. Tout le travail arrive sur `dev` d'abord ; `main` ne passe que par une `dev` → `main` fusion de version. Cela garde `main` aligné avec 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.** N'associez pas une fonctionnalité à une modification sans rapport de l'environnement de développement. Séparez-les.
* **Rebasez avant de soumettre**, afin que votre branche repose sur la version actuelle de `dev`.
* **Décrivez ce qui a changé et pourquoi.** Les relecteurs ne devraient pas avoir à déduire l'intention à partir du diff.
* **`pnpm check` au vert.** Le CI exécute `pnpm test` et `pnpm run build` sur Node 24 pour chaque pull request afin de `dev` ou `main`; un échec bloque la fusion.

## Style des messages de commit

Les commits utilisent un `Type(scope):` préfixe, tiré de l'historique du projet. Le périmètre est facultatif et nomme 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 la table maintenue à la main par Intl.DisplayNames`                  |
| `Perf(...)`     | Travail sur les performances                     | `Perf(frontend) : charger paresseusement uniquement la locale d'interface active`                        |
| `Style(...)`    | Finition visuelle ou rédactionnelle              | `Style(toggle) : état enfoncé à fort contraste pour les primitives de bascule`                           |
| `Chore(...)`    | Outils, dépendances, maintenance                 | `Chore : simplifier le mappage des chemins jsconfig`                                                     |

Rédigez les messages en anglais, à l'impératif, et limitez-vous à une seule préoccupation par commit.

## La règle i18n

MyIP est proposé en quatre langues : `en`, `zh`, `fr`, `ru`.

{% hint style="danger" %}
Toute modification qui expose du texte visible par l'utilisateur doit mettre à jour **les quatre fichiers de langue dans le même commit** — y compris les `frontend/data/changelog.json` entrées. `tests/changelog.test.js` applique cette règle, donc une traduction partielle échoue `pnpm check`.
{% endhint %}

Si vous ne pouvez pas écrire une langue avec assurance, ajoutez quand même la clé dans chaque fichier avec votre meilleure tentative, et mentionnez-le dans la pull request. Détails : [i18n](/developer/fr/development/i18n.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 la même modification. Le rendu UI, le comportement réseau réel et les API du navigateur sont hors du périmètre. Voir [Tests](/developer/fr/development/testing.md).

## Revue de code

Un mainteneur examine chaque pull request. Attendez-vous à des questions, des modifications demandées 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, indiquez-le et joignez une capture d'écran ou un bref 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

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

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.