> For the complete documentation index, see [llms.txt](https://docs.augelab.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.augelab.com/french/key-features/train-custom-ai-models-with-training-window/after-training.md).

# Après l'entraînement

Vous êtes désormais proche du déploiement de votre modèle — c’est le moment où vous transformez des “chiffres” en un modèle qui fonctionne réellement dans votre flux de travail.

***

## 1) Trouver les sorties de l’entraînement (weights + config + names)

À la fin de l’entraînement, les messages de log/statut indiquent où les sorties sont écrites.

Dans AugeLab Studio, les sorties d’entraînement sont généralement créées dans un dossier nommé :

**XXX\_config**

juste à côté de votre dossier de dataset (où **XXX** est le nom du dossier dataset).

Structure typique :

```
XXX_config/
    XXX.names
    XXX.cfg
    backup/
        XXX_last.weights  (si disponible)
        XXX_best.weights  (si disponible)
```

Au minimum, conservez ensemble :

* Fichier de poids : `.weights` (parfois il y a un fichier `best` et un `last`)
* Fichier de configuration : `.cfg`
* Fichier des noms de classes : `.names`

> ⚠️ Ne renommez pas / ne réordonnez pas les classes dans votre fichier `.names` après l'entraînement, sauf si vous remappez aussi les IDs des labels. L’ordre des classes doit correspondre aux label IDs.

<details>

<summary><strong>Quel poids utiliser : best ou last ?</strong></summary>

Si votre entraînement rapporte le mAP pendant l’entraînement, beaucoup de workflows YOLO/Darknet conservent un checkpoint “best so far”.

* Utilisez `best` lorsque le mAP s’est amélioré puis a baissé (signe d’overfitting).
* Utilisez `last` si l’entraînement s’est terminé alors que le mAP s’améliorait encore ou était stable.

Si vous n’avez pas de fichier “best”, prenez d’abord les weights finaux, puis validez.

</details>

***

## 2) Valider le modèle avant de le déployer

Avant d’intégrer le modèle dans la logique de production, effectuez une validation rapide.

Ensembles de validation recommandés :

* **Validation set** : 30–100 images représentatives (bonnes et mauvaises conditions d’éclairage, flou, encombrement, cas limites).
* **Courtes vidéos ou images** : un court enregistrement de la vraie caméra (si vous déployez sur une caméra fixe).

Ce que vous devez vérifier :

* Le modèle détecte l’objet cible de façon cohérente.
* Les boîtes sont “suffisamment bonnes” pour votre logique (pas besoin d’être parfaites).
* Les faux positifs sont acceptables ou filtrables.
* Les cas rares mais importants sont détectés.

> ⚠️ Un mAP élevé peut quand même échouer en production si votre split de validation était trop petit ou trop “propre”. La vérification sur un ensemble de validation réel empêche cela.

***

## 3) Charger le modèle dans Studio (inference)

Dans AugeLab Studio, l’étape suivante est généralement de construire (ou mettre à jour) un scénario `.pmod` qui exécute l’inférence.

### A) Utiliser “Object Detection - Custom” (recommandé)

Utilisez ce nœud si vous souhaitez exécuter votre modèle YOLO/Darknet entraîné dans un workflow.

Workflow :

1. Ajoutez **Object Detection - Custom** à votre graphe (catégorie AI Applications).
2. Dans l’interface du bloc :
   * Cliquez sur **Open Weight File** et sélectionnez votre `.weights`
   * Cliquez sur **Open Config File** et sélectionnez votre `.cfg`
   * Cliquez sur **Open Class File** et sélectionnez votre `.names`
3. Sélectionnez les classes que vous souhaitez détecter (liste à cocher).
4. Réglez la **Confidence Threshold** (commencez autour de 0.5–0.8 et ajustez).
5. Connectez une source d’image à l’entrée du bloc et prévisualisez la sortie.

Sorties exploitables dans votre logique :

* Image de sortie avec détections dessinées
* Object Count
* Object Locations / Sizes
* Object Classes
* Rectangles

> ℹ️ Si “Object Detection - Custom” n’est pas disponible, votre build peut ne pas avoir le support CUDA/OpenCV DNN activé. Essayez le bloc CPU ci‑dessous, ou installez les modules requis depuis le Module Downloader (voir [ai-training.md](/french/key-features/train-custom-ai-models-with-training-window.md)).

### B) Utiliser “Object Detection - Custom (CPU)” (solution de repli)

Utilisez ce bloc si vous voulez le même flux sans accélération GPU.

* Il effectue l’inférence sur CPU, donc plus lent.
* La configuration est la même : weights + cfg + names.

***

## 4) Ajuster les seuils (ce qui compte vraiment)

La plupart des améliorations “prêtes pour la production” proviennent du réglage des seuils, pas nécessairement d’un entraînement plus long.

Étapes pratiques de départ :

* Augmentez le seuil de confiance si vous avez trop de faux positifs.
* Diminuez le seuil de confiance si vous manquez des objets.
* Évaluez sur le golden set et au moins un clip réel caméra.

> ⚠️ Ne faites pas de tuning sur une seule image. Ajustez toujours sur un petit ensemble. Sinon vous “overfitterez votre seuil” à une seule scène.

***

## 5) Packager pour le partage / la reproductibilité

Si vous voulez que le modèle soit réutilisable plus tard (ou par quelqu’un d’autre), empaquetez-le de façon réfléchie.

Structure de dossier recommandée :

```
my_model_release/
    model.weights
    model.cfg
    classes.names
    README.txt
    validation_set/   (optionnel)
```

Que mettre dans le README :

* Sur quel dataset le modèle a été entraîné (version/date)
* Signification des classes (si ambiguë)
* Plage recommandée pour la confidence threshold
* Cas d’échec connus (éblouissement, objets très petits, occlusion extrême)

> ℹ️ Si votre scénario `.pmod` référence ces ressources, conservez-les comme ressources relatives de projet pour que le scénario reste portable. Voir aussi : [headless-studio](/french/key-features/headless.md) (comportement de chargement des ressources manquantes).

***

## 6) Si ça échoue en production (quoi faire ensuite)

Quand un modèle échoue après déploiement, la correction est généralement l’une des suivantes (dans cet ordre) :

1. **Collecter les échecs** (sauvegarder les frames montrant le miss / le faux positif)
2. **Les annoter correctement**
3. **Retrain ou fine-tune** avec ces nouvelles données

C’est ainsi que les modèles deviennent robustes.

<details>

<summary><strong>Modes d’échec courants et la correction la plus rapide</strong></summary>

* Faux positifs dus à la texture de fond → ajoutez des négatifs de cet environnement précis.
* Misses sur objets petits → augmentez la taille d’entrée (si le GPU le permet) et collectez plus d’exemples d’objets petits.
* Misses sous éblouissement / flou → ajoutez ces cas explicitement au dataset (ne comptez pas uniquement sur l’augmentation).
* Boîtes systématiquement trop lâches / serrées → corrigez la cohérence du style d’annotation, puis ré-entraînez.

</details>