# Famille de dépôts

> Un dépôt suite, plusieurs dépôts de composants ciblés, et une frontière d'artefact propre, le modèle subtree et l'état de transition actuel.

*Page HTML : https://grassmarlin.com/fr/wiki/repo-family/*
*Source Markdown : https://grassmarlin.com/fr/wiki/repo-family.md*
*English: https://grassmarlin.com/wiki/repo-family.md*

---

MarlinSpike passe d'un dépôt unique mixte vers une famille de dépôts où le dépôt suite vendore une combinaison connue pour fonctionner d'atelier, de moteur, de plugins et de moteurs Rust.

**Dépôt suite**, Le dépôt marlinspike de niveau supérieur est la surface d'intégration pour les équipes qui veulent un seul clone.

**Composants faisant autorité**, Le moteur, l'atelier, les plugins et les moteurs Rust ont chacun vocation à devenir faisant autorité dans leur propre dépôt.

**Modèle subtree**, Le dépôt suite utilise git subtree, pas les sous-modules, pour vendorer les dépôts de composants.

## Modèle de dépôts

| Dépôt | Rôle |
|---|---|
| `marlinspike` | Le dépôt suite, foyer d'intégration et option clone unique. |
| `marlinspike-msengine` | Le dépôt du moteur d'analyse principal. Nom de package interne et CLI : `msengine`. |
| `marlinspike-workbench` | L'interface web et la surface de collaboration qui lit les artefacts de rapport et peut optionnellement invoquer le moteur. |
| `marlinspike-plugins` | Le monorepo de plugins Python pour les extensions consommatrices de rapports. |
| `marlinspike-engines` | L'espace de travail de moteurs Rust pour les composants face aux paquets et fortement orientés événements. |

## Un seul clone pour tout

Le dépôt suite vendore les dépôts de composants via `git subtree`. Les docs le présentent comme un compromis pratique :

- Les utilisateurs gardent un comportement normal de `git clone`.
- Les équipes évitent la charge de configuration des sous-modules git.
- Les dépôts de composants peuvent garder leurs propres cycles de version.
- Le dépôt suite peut épingler une combinaison connue pour fonctionner pour les opérateurs qui veulent toute la stack ensemble.

## Frontière de contrat

L'artefact de rapport portable est la frontière de passage entre les composants :

1. `msengine` produit un artefact de rapport depuis le trafic capturé.
2. `marlinspike-workbench` consomme cet artefact pour la revue, le triage et la collaboration.
3. Les plugins Python consomment le même rapport fini et émettent des artefacts sidecar.
4. Les moteurs Rust peuvent produire des artefacts en amont ou des flux d'événements qui alimentent le moteur ou d'autres composants.

L'atelier est intentionnellement utilisable même quand le rapport a été généré ailleurs et qu'aucun binaire de moteur local n'est présent.

## État de transition actuel

Les docs reconnaissent honnêtement que le dépôt actuel contient encore le code du moteur et de l'atelier pendant que la scission se prépare.

- Le dépôt racine `marlinspike` porte encore le code opérationnel du moteur et de l'interface Flask aujourd'hui.
- Le premier préfixe subtree bootstrap est `msengine/`.
- Jusqu'à la fin de la bascule, le `_ms_engine.py` racine reste la source opérationnelle du moteur.
- Le script helper `scripts/sync-msengine-bootstrap.sh` copie en miroir le moteur opérationnel vers la copie subtree.

## Limites de propriété pour les contributeurs

Les docs de contribution encouragent déjà les développeurs à penser en termes de futures frontières de composants, même avant que l'extraction soit terminée :

- L'analyse face aux paquets, les observables et le travail CLI du moteur appartiennent à la frontière `msengine`.
- Les routes Flask, les templates, l'auth, les projets et l'UX de revue de rapport appartiennent à la frontière `workbench`.
- ATT&CK, IEC 62443, PERA et autres superpositions consommatrices de rapports appartiennent à la future frontière `plugins`.
- Les parseurs Rust fortement orientés paquets appartiennent à la future frontière `engines`.

Les docs d'extensibilité définissent comment les moteurs Rust, les plugins Python et les packs de règles YAML sont censés interagir avec l'artefact de rapport et entre eux. Voir [Extensibilité](/fr/wiki/extensibility.md) et [Contribution](/fr/wiki/contributing.md).

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