# Contribution

> Gardez les modifications ciblées, respectez les frontières de gestion des données, et exécutez les vérifications locales avant d'ouvrir une PR.

*Page HTML : https://grassmarlin.com/fr/wiki/contributing/*
*Source Markdown : https://grassmarlin.com/fr/wiki/contributing.md*
*English: https://grassmarlin.com/wiki/contributing.md*

---

Le guide de contribution est intentionnellement pragmatique : gardez les PRs petites, ne commitez pas de captures ni de secrets, et comprenez à quelle frontière de dépôt future votre modification appartient.

**Modifications ciblées**, Les petites PRs sont plus faciles à réviser que les refactors larges.

**Exécuter les vérifications locales**, Au minimum, exécutez la vérification de syntaxe Python avant d'ouvrir une PR.

**Pas de données sensibles**, Ne commitez pas de captures, de secrets ou de détails d'environnement privés.

## Avant de commencer

- Les issues ou petits fils de discussion sont les bienvenus pour les bugs, les lacunes de parseur, les problèmes d'interface et les améliorations de déploiement.
- Gardez les modifications ciblées plutôt que de mélanger de nombreuses préoccupations sans rapport.
- Évitez de commiter des captures privées, des secrets, des captures d'écran locales ad hoc ou des métadonnées d'outils locaux.
- Les captures d'écran de documentation sous `docs/screenshots/` sont l'exception explicite à la règle sans capture d'écran.

## Notes de développement

Les fichiers source canoniques mentionnés par le projet sont `_ms_engine.py`, `_auth.py`, `_models.py`, `_config.py` et `app.py`. Les shims de compatibilité tels que `auth.py`, `models.py` et `config.py` ne sont pas la principale source de vérité.

Le guide de contribution renforce aussi le vocabulaire du projet :

- Les moteurs Rust traitent le travail face aux paquets et fortement orienté événements.
- Les plugins Python traitent l'analyse face aux rapports, l'enrichissement et la logique de triage.
- Les packs de règles YAML traitent les mappings déclaratifs, les suppressions et la politique locale.

## Flux de la suite et helpers subtree

Le dépôt suite garde des copies vendorées de composants dans des préfixes subtree. Les docs de contribution mentionnent des commandes helper pour travailler avec ce modèle :

```
./scripts/update-subtrees.sh status
./scripts/sync-msengine-bootstrap.sh
```

Les préfixes subtree prévus sont `msengine/`, `workbench/`, `plugins/` et `engines/`. Aujourd'hui, `msengine/` est le premier vrai préfixe bootstrap.

## Vérifications locales

Avant d'ouvrir une PR, les docs demandent aux contributeurs d'exécuter la vérification de syntaxe de base :

```
python3 -m py_compile app.py _auth.py _config.py _models.py _ms_engine.py
```

Si vous avez touché le subtree bootstrap du moteur, vérifiez aussi le point d'entrée du package en miroir :

```
PYTHONPATH=msengine python3 -m msengine --help
```

Si vous avez fait des modifications liées à Docker, le guide dit aussi de valider la stack localement :

```
docker compose up --build
```

## Sécurité et gestion des données

- Ne commitez pas de secrets, de fichiers `.env`, de credentials d'infrastructure ou de notes de déploiement internes.
- Ne commitez pas de captures client ni de corpus PCAP tiers embarqués sauf si les conditions de redistribution sont explicitement documentées.
- Si vous trouvez un problème de sécurité, signalez-le en privé avant d'ouvrir une issue publique.

La page des versions suit les jalons récents du moteur, de l'interface et du visualiseur live pour que les contributeurs puissent voir où les changements majeurs ont déjà eu lieu. Voir [Versions](/fr/wiki/releases.md) et [Famille de dépôts](/fr/wiki/repo-family.md).

Références source : [CONTRIBUTING.md](https://github.com/eris-ot/marlinspike/blob/main/CONTRIBUTING.md)