Aller au contenu
Omotola
FR/EN
Épisode spécial · ML · BMD-45 · Bengaluru · jeu public
← tous les projets

Détection de véhicules

Les caméras de chez moi regardent un trafic dense, désordonné, plein de motos, où les véhicules lointains ne font que quelques pixels. Un détecteur généraliste sait-il encore les voir ?

Voir le code sur GitHub →

Une rue de Bengaluru saturée de motos et de voitures, filmée d’une caméra de vidéoprotection. Le modèle générique n’entoure que quatre véhicules, tous au premier plan.
Avant4 véhicules détectés
La même rue de Bengaluru. Le modèle affiné entoure quarante-quatre véhicules, jusqu’aux motos les plus lointaines et les plus imbriquées du fond de l’image.
Après fine-tuning44 véhicules détectés
Livré

Acte I · Le problème

1. e4 e5

YOLOv8 pré-entraîné sur COCO reconnaît très bien une voiture qui remplit l’image. Mais dans une scène d’embouteillage filmée en hauteur, les véhicules éloignés deviennent minuscules et se chevauchent, et c’est exactement là que le modèle généraliste décroche.

La question du projet est précise : qu’est-ce qu’un fine-tuning sur des données de trafic dense change réellement, mesuré proprement, en particulier sur les petits objets ?

Acte II · La démarche

2. Cf3 Cc6

Premier constat, assumé dès le départ : il n’existe aucun jeu de données public de vision par ordinateur spécifique au Bénin. Plutôt que de prétendre le contraire, le projet utilise le jeu public le plus proche du problème : BMD-45, filmé par des caméras de surveillance à Bengaluru, en Inde. Le contexte béninois est la motivation du projet, pas la provenance de ses données, et cette transparence fait partie du protocole.

  1. Environ 3 000 images extraites de BMD-45 (45 000 au total), découpage train / test isolé.
  2. 4 classes compatibles COCO : voiture, moto, bus, camion.
  3. YOLOv8n évalué tel quel, puis fine-tuné sur ces données.
  4. Comparaison sur le même jeu de test, rappel ventilé par taille d’objet : petit, moyen, grand.

règle du jeu : tout est fixé avant le premier entraînement, ce qu’on fixe avant protège de ce qu’on aimerait se raconter après

Acte III · Les résultats

3. Fc4 Fc5
Métriques globales, pré-entraîné → fine-tuné
MétriqueAvantAprèsÉvolution
mAP@0.50.4380.825+88.4 %
mAP@0.5:0.950.2960.644+117.8 %
Précision0.4960.833+67.9 %
Rappel0.4170.714+71.1 %
F1-score0.4530.769+69.6 %
Débit (FPS)37.243.2+16.2 %
Rappel par taille de véhicule, avant → après
  • Petits (804)0.12 → 0.69 · +469,3 %
  • Moyens (1 415)0.37 → 0.88 · +135,6 %
  • Grands (332)0.79 → 0.95 · +20,1 %
Les limites, dites clairement

Ces chiffres valent sur le jeu de test de BMD-45, pas sur les routes béninoises, faute de données locales publiques. Et l’inférence sur processeur classique prend 1 à 2 secondes par image : suffisant pour une démonstration, pas pour du temps réel sans matériel dédié.

Acte IV · Ce que j’ai appris

4. O-O
  • Les moyennes mentent par omission

    Le mAP global du modèle de départ ne disait pas l’essentiel : presque neuf petits véhicules ratés sur dix. C’est la ventilation par taille qui a posé le vrai problème sur la table. Depuis, je ne crois plus une métrique avant de l’avoir découpée.

  • Le protocole se joue avant

    Comme une ouverture aux échecs : jeu de test isolé, métriques et règles de comparaison décidées avant le premier entraînement. Ce qu’on fixe avant protège de ce qu’on aimerait se raconter après.

  • La transparence est un choix méthodologique

    Écrire noir sur blanc qu’aucun jeu de données béninois n’existe a rendu le projet plus solide, pas plus fragile : on sait exactement ce que nos chiffres prouvent, et ce qu’ils ne prouvent pas.

  • Un rappel de 0.12 n’est pas une honte

    C’est le début du récit. Les personnages de mes histoires préférées grandissent à force de tomber ; un modèle progresse pareil, et celle qui l’entraîne aussi.

documenter, c’est penser : chaque page rédigée a clarifié une décision pendant qu’il était encore temps d’en changer