Liste de contrôle pour les clients entreprise

La liste de contrôle de lancement#

Copie-la dans le dépôt ou le wiki du projet. Chaque section correspond à une leçon de ce cours et est formulée de façon à ce qu’une personne qui n’est pas ingénieure puisse y répondre :

# Vision Project Kickoff Checklist

Project: ...   Owner: ...   Date: ...

## 1. What should the model do?
   Business goal (one sentence, with a deadline): ...
   Task: [ ] detect [ ] segment [ ] semantic [ ] classify [ ] pose [ ] OBB [ ] depth
   Classes, each with a definition and a look-alike it excludes: ...

## 2. Where will the model run?
   [ ] Cloud GPU  [ ] Cloud CPU  [ ] Edge device  [ ] Mobile  [ ] Browser
   Latency target: ... ms   Cameras / resolution: ...

## 3. What visual variation exists?
   Times of day: ...   Weather: ...   Sites: ...
   Cameras: ...   Operators / shifts: ...   Variants: ...

## 4. Which edge cases matter?
   ...

## 5. Do we have background images?
   [ ] Yes, ...% of images (target 0-10%)   [ ] No, collect first

## 6. Are labels consistent?
   [ ] Labeling guide written   [ ] Agreement measured: ...%
   [ ] QC audit and suspect review run, notes attached

## 7. Did we check for leakage?
   Split unit: [ ] clip [ ] camera [ ] day [ ] site [ ] customer
   [ ] No group appears in more than one split
   [ ] Every class appears in every split

## 8. Is the test set truly unseen?
   [ ] Locked; used once for the final go/no-go

## 9. What defines success?
   Acceptance test (metric, threshold, holdout): ...

Volume: [ ] >=1,500 images and >=10,000 instances per class
        [ ] or documented exception with expected impact: ...

Ready to fine-tune YOLO26?  [ ] Yes   [ ] No, fix item ... first

Quand chaque section conditionne le projet#

Animer la réunion de lancement#

Parcours la page avec la personne responsable du résultat métier, pas seulement avec les ingénieurs. Trois habitudes contribuent à sa réussite :

• Consacre du temps à la section 9. C’est dans le test d’acceptation que les désaccords réels apparaissent, et une heure passée à s’entendre sur ce test évite des semaines de discussions sur la qualité suffisante ou non d’un modèle.
• Accepte « je ne sais pas » comme réponse. Note à côté un responsable et une échéance. Les questions sans réponse constituent le plan de projet des deux prochaines semaines.
• Aborde rapidement la section 2. La cible de déploiement impose des limites à la taille du modèle et des images, qui déterminent à leur tour la taille minimale des objets que le jeu de données doit couvrir.

Conserve la liste de contrôle remplie avec le jeu de données, à côté des notes de contrôle qualité et des fichiers de partition. Des mois plus tard, quand quelqu’un demandera pourquoi le modèle se comporte d’une certaine façon, la réponse se trouvera généralement sur cette page.

Ce que tu peux faire maintenant#

Tu peux transformer un objectif métier en test d’acceptation, rédiger une spécification de jeu de données avec des quotas, collecter des données représentatives avec des métadonnées dans chaque nom de fichier, annoter de façon cohérente et mesurer la concordance, vérifier la qualité avec des scripts, répartir les données par groupe sans fuite, choisir une augmentation adaptée au déploiement, conditionner l’entraînement à une vérification de préparation et transformer une exécution de référence en prochaine amélioration du jeu de données.

Quelle est la suite ?#

• Entraîne ton premier modèle YOLO : convertis les annotations dans Préparer un jeu de données personnalisé, puis entraîne, valide et exporte le modèle.
• Développe avec la plateforme Ultralytics : exécute tout le cycle de vie (annotation, sélection, entraînement cloud, déploiement, surveillance) au même endroit, en commençant par Sélectionner, dédupliquer et répartir.
• Ultralytics YOLO en production : exporte et déploie le modèle, puis surveille sa dérive une fois qu’il est en service.
• Le guide de réglage fin : gel des couches, entraînement en deux étapes et choix de l’optimiseur lorsque les paramètres par défaut ne suffisent plus.