Cette page décrit la démarche technique derrière Pétanque Scanner. Si vous cherchez l'application elle-même — ce qu'elle fait, ce qu'elle coûte, où la télécharger — la page de l'application est faite pour ça.
Le problème
Mesurer l'écart entre deux boules et un cochonnet demande une position 3D, au centimètre, sur un sol irrégulier. Avec un téléphone seul, aucune des voies évidentes ne tient : une image unique ne donne aucune échelle, et les API de profondeur varient trop d'un appareil à l'autre pour être fiables sur du gravier fin à un mètre cinquante. Poser un marqueur au sol réglerait l'échelle, mais imposerait au joueur un accessoire — c'est exactement ce que l'application est censée remplacer.
L'approche : accumuler des rayons
Le geste naturel de l'utilisateur devient la source de l'information. Chaque image de la caméra passe dans un détecteur d'objets qui repère les boules et le cochonnet en 2D. Chaque détection est convertie en un rayon partant de la caméra, dont la pose est fournie par AR Foundation (ARCore / ARKit). En tournant autour du jeu, on accumule des dizaines de rayons issus de points de vue différents : leur intersection donne la position 3D de chaque boule.
Le sous-produit est aussi utile que le résultat : le degré de convergence des rayons est une mesure de confiance gratuite. Des rayons qui se croisent proprement signifient une position fiable ; des rayons dispersés signalent une détection instable. C'est cet indice qui s'affiche en direct pendant le scan, et il évite d'annoncer un chiffre faux avec aplomb.
Les données : tout en synthèse
Constituer et annoter à la main un jeu de données couvrant toutes les surfaces, toutes les lumières et toutes les finitions de boules n'était pas réaliste en solo. Le jeu d'entraînement est donc rendu dans Unity, avec randomisation de domaine et des annotations exactes au pixel produites par le moteur — aucune annotation manuelle.
Un premier passage sur photos réelles a d'abord servi de socle : sur 471 photos nettoyées, passer de YOLOX tiny @416 à YOLOX-s @640 a rapporté +9,25 points de mAP@.50:.95 (67,19 → 76,44), en confirmant au passage que la capacité du modèle comptait davantage que la résolution, l'augmentation ou le nombre d'époques.
Ce qui a marché, et ce qui a échoué
Les données synthétiques se sont révélées beaucoup moins dociles que prévu. Trois expériences, une réussie et deux ratées :
- +1500 scènes synthétiques simples : gain. Environ +3,5 points d'AP sur le cochonnet, la classe qui limite tout le reste.
- Un générateur enrichi en décor et objets parasites : perte. L'idée était de rapprocher les rendus d'une scène réelle. Le résultat a été moins bon que le générateur simple.
- 1500 scènes centrées sur l'occlusion du cochonnet : perte. C'est pourtant le cas d'échec dominant. Le rappel sur cochonnet est descendu à 86,1 % contre 88,9 % pour le modèle en place. Expérience abandonnée, modèle non déployé.
La leçon que j'en tire : en synthèse, couvrir la distribution paie, et cibler les cas difficiles punit. J'ai relancé l'expérience d'occlusion une deuxième fois, convaincu d'avoir raté quelque chose au premier essai — le réflexe « il faut miner les exemples durs » est tenace, et il était faux ici.
Le modèle déployé
Le modèle embarqué est un YOLOX-s à 448 px, exporté en ONNX (34 Mo) et exécuté par OpenCV DNN sur l'appareil. Il est évalué sur un jeu de validation volontairement représentatif de l'usage réel : des photos prises au téléphone, tenu au-dessus du terrain — et non des images collectées sur le web, qui surreprésentent les plans de compétition et les photos produits.
| Classe | Rappel | Précision |
|---|---|---|
| Boule | 99,4 % | 100 % |
| Cochonnet | 88,9 % | 91,4 % |
Méthodologie : seuil de confiance 0,25, IoU > 0,5, appariement glouton un-à-un avec la vérité terrain. Le jeu de validation ne compte que 34 photos — assez pour trancher entre deux modèles, pas pour publier un chiffre définitif, et c'est la première chose que j'élargirais.
Les échecs restants sur le cochonnet sont presque tous les mêmes : trop petit dans l'image, ou masqué par une boule. C'est une limite acceptable ici parce que l'application ne travaille pas sur une image isolée mais sur une séquence : une frame ratée est rattrapée par les suivantes.
Le travail de robustesse
L'essentiel du temps de développement n'est pas passé dans le modèle, mais autour : regrouper des détections successives en boules distinctes, verrouiller la scène sur le plan du sol, filtrer les poses tremblantes avant qu'elles ne polluent l'accumulation, et offrir un mode « magnétise » pour recaler une boule à la main quand la lumière joue des tours. C'est ce qui sépare une démonstration qui marche d'une application qu'on ose publier.
Contraintes d'embarqué
Tout tourne sur le téléphone : aucune image n'est envoyée, il n'y a ni serveur ni compte utilisateur. Le prix à payer est le poids du binaire — les modèles ONNX écartés au fil des expériences ont été sortis des assets embarqués, ce qui a rendu environ 145 Mo à l'APK.
Disponibilité
L'application est disponible sur Android et iOS :
Voir aussi : la page de l'application, sa politique de confidentialité et ses conditions d'utilisation.
