OCR sur l'appareil pour un cas de niche : ce que PGNify m'apprend sur la reconnaissance manuscrite
Une feuille de partie d'échecs manuscrite ressemble à ceci : des colonnes de coups au crayon, une écriture qui varie d'un joueur à l'autre, parfois une rature. Miser sur une reconnaissance d'écriture parfaite pour numériser ça est irréaliste, l'écriture manuscrite reste un problème mal résolu même avec les meilleurs modèles. PGNify part d'un principe différent : l'OCR n'a pas besoin d'être parfait, il a juste besoin d'être corrigeable vite.
Le vrai levier n'est pas la précision de l'OCR#
L'OCR sur l'appareil (ML Kit) pré-remplit une suggestion pour chaque coup, sans connexion réseau et sans envoyer la photo à un service tiers. Cette suggestion peut être fausse : une écriture ambiguë, un chiffre confondu avec une lettre, ça arrive constamment. Ce qui rend la correction rapide n'est pas la qualité de cette suggestion, c'est ce qui se passe juste après.
Le moteur de légalité fait le travail que l'OCR ne peut pas faire#
Après chaque suggestion OCR, un vrai moteur d'échecs calcule la liste des coups légaux dans la position actuelle. Cette liste est presque toujours courte, entre deux et une trentaine de coups selon l'ouverture de la position, jamais l'espace complet de la notation algébrique. Corriger un coup mal reconnu devient alors un choix dans une liste courte, en un ou deux tapotements, plutôt que retaper une notation au clavier.
OCR suggère : "Cf3" (ambigu, illisible)
Moteur calcule les coups légaux : [Nf3, Nc3, e4, d4, ...]
Utilisateur choisit dans la liste, en 1 tapotement
C'est une différence de nature, pas seulement de vitesse : l'OCR seul demande à l'utilisateur de vérifier une chaîne de caractères contre son souvenir de la partie. Le moteur de légalité demande de reconnaître un coup dans une liste courte, une tâche perceptuelle beaucoup plus rapide qu'une tâche de relecture.
Le coup illisible : accepter l'échec plutôt que le masquer#
Un coup reste parfois totalement illisible, ni l'OCR ni la mémoire du joueur ne permettent de le retrouver avec certitude. PGNify permet de passer ce coup explicitly, et la partie reste exportable jusqu'au point d'arrêt. Ce choix de conception compte plus qu'il n'y paraît : forcer une réponse là où il n'y en a pas produirait un PGN silencieusement faux, ce qui est pire qu'un PGN incomplet mais honnête sur ses trous.
Ce que ça généralise au-delà des échecs#
La leçon dépasse la reconnaissance de coups d'échecs : dès qu'un domaine dispose d'une structure de contraintes qui réduit drastiquement l'espace des réponses possibles à un instant donné (les coups légaux, ici), la précision de la reconnaissance brute compte moins que la qualité du mécanisme de correction qui l'entoure. Un OCR à 80 % de précision combiné à une liste de trois choix corrects va plus vite qu'un OCR à 95 % combiné à un champ de texte libre à corriger à la main. Le problème à résoudre n'était donc jamais « comment améliorer l'OCR », c'était « comment rendre l'erreur d'OCR la moins coûteuse possible à corriger ».
