> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Projets et versions

> Utilisez des noms de modèles proxy stables et des versions d’acheminement isolées pour faire évoluer le comportement en toute sécurité.

Un **projet** représente le comportement stable que sollicite votre application. Il comprend un projet W\&B, des datasets, des modèles fine-tunés, des évaluations, des analyses et une ou plusieurs versions d’acheminement.

Cette page explique comment s’articulent les projets, les noms de modèles proxy et les versions, afin que vous puissiez modifier l’acheminement d’un projet sans perturber le trafic que votre application envoie déjà.

<Note>
  Dans l’API de gestion, un projet est appelé une tâche (task). Les chemins d’API commencent par `/tasks/{alias}`, où `alias` est le nom du modèle proxy. Voir [Conventions de l’API](/fr/model-distillation/reference/conventions#projects-and-tasks).
</Note>

<h2 id="proxy-model-name">
  Nom de modèle proxy
</h2>

Le nom de modèle proxy est la chaîne de modèle qu'utilise votre application, par exemple `ticket-classifier`. Il est unique au sein d'une entity W\&B et reste stable même lorsque les modèles changent. Il peut différer du nom du projet W\&B dans lequel sont stockées les traces du projet.

Utilisé seul, le nom de modèle proxy désigne toujours la version 1 :

```json theme={"system"}
{"model": "ticket-classifier"}
```

Fixez explicitement une version plus récente :

```json theme={"system"}
{"model": "ticket-classifier@v2"}
```

<h2 id="when-to-create-a-version">
  Quand créer une version
</h2>

Créez une nouvelle version lorsque vous souhaitez tester une autre combinaison de modèles ou d’autres paramètres de fournisseur sans affecter le trafic actuel de l’application. Chaque version dispose de sa propre configuration d’acheminement, indépendante des autres.

<Note>
  La création d’une version ne redirige pas le trafic. Un appelant n’y accède qu’après avoir remplacé la valeur de `model` par `name@vN`.
</Note>

<h2 id="what-versions-do-not-copy">
  Ce que les versions ne copient pas
</h2>

Une version n’est pas une copie du projet. Les datasets, les modèles fine-tunés et les évaluations restent des ressources rattachées au projet. Les requêtes de dataset permettent de choisir la version du projet dont le trafic doit être utilisé.

<h2 id="recommended-progression">
  Progression recommandée
</h2>

Pour valider une nouvelle version avant qu’elle ne reçoive le moindre trafic de production, procédez comme suit :

1. Maintenez la production sur le nom de modèle proxy seul et la version 1.
2. Créez une nouvelle version avec l’acheminement proposé.
3. Envoyez le trafic interne ou canari vers `name@vN`.
4. Examinez les analyses et les évaluations.
5. Ne modifiez le modèle configuré de l’application que lorsque la nouvelle version est prête.

Le trafic de votre application utilise alors l’acheminement de la nouvelle version.

<Accordion title="API : créer une version de projet (POST /tasks/{alias}/versions)">
  Cette requête crée la version suivante avec son propre acheminement. La réponse contient le numéro de version attribué.

  ```bash theme={"system"}
  curl --request POST \
    --url "https://distillation.training.wandb.ai/v1/tasks/ticket-classifier/versions" \
    --header "Authorization: Bearer $WANDB_API_KEY" \
    --header "Wandb-Entity: your-team" \
    --header "Content-Type: application/json" \
    --data '{
      "targets": [
        {"model_ref": "wandb-inference/your-fine-tuned-model", "weight": 1}
      ]
    }'
  ```

  Pour consulter l’opération complète, voir [Créer une version de tâche](/fr/model-distillation/reference/management/routing/create-a-task-version).
</Accordion>


## Related topics

- [Projets et trafic](/fr/model-distillation/studio/projects-and-traffic.md)