Des cartes de visite sans cloud : PaddleOCR dans React Native passe de 7,8 à 3 secondes

Un scanner de cartes de visite ressemble à un projet d'une soirée : on photographie, on envoie à une API, on récupère un nom et un numéro de téléphone. Mais la carte n'appartient pas à l'utilisateur, elle appartient à un tiers. Son nom, son numéro et sa fonction arrivent sur un serveur à son insu, ce qui, dans la pratique russe, se heurte à la loi 152-FZ. L'équipe dont parle l'auteur de l'article sur Habr a choisi une solution radicale : la photo ne quitte jamais le téléphone.

Ce qui a été construit, et pourquoi sans LLM

La pile technique : PaddleOCR v5, exécuté via ONNX Runtime dans une application React Native sous Android. Autrement dit, le modèle de reconnaissance réside sur l'appareil et aucun réseau n'est nécessaire pour traiter l'image.

L'auteur précise que les LLM ont été écartés. L'annonce ne détaille pas les raisons, mais elles sont généralement évidentes. Un grand modèle est lourd et lent sur un téléphone. Et si on l'appelle dans le cloud, on retombe sur le problème initial : la photo sort de l'appareil. Pour une carte de visite, où il suffit d'extraire quelques champs courts, un OCR classique associé à des règles d'analyse s'avère souvent plus pratique. Ce n'est pas une conclusion de l'article, mais un repère d'ingénierie général qui explique bien ce choix.

Un exemple simple. L'utilisateur photographie une carte, l'OCR repère les blocs de texte et les lit, puis l'application détermine à l'aide de modèles où se trouvent le téléphone, l'e-mail et le nom. Tout se passe en local, et l'utilisateur voit à la fin une fiche de contact remplie.

De 7,8 à 3 secondes

Le chiffre le plus parlant de l'annonce : le traitement d'une photo est passé de 7,8 à 3 secondes. La différence est déterminante pour le produit. Près de huit secondes d'attente après la prise de vue donnent à l'utilisateur l'impression que l'application est figée. Trois secondes restent tolérables, même si on est loin d'une réponse instantanée.

L'annonce ne dit pas comment cette accélération a été obtenue ; il faudra consulter le texte complet pour les détails. Mais l'OCR local sur téléphone offre les leviers d'optimisation habituels : la taille de l'image d'entrée, le nombre d'exécutions de modèles dans la chaîne, le format des poids et la manière de transmettre les données entre JavaScript et le code natif. Dans React Native, ce dernier point constitue souvent le goulot d'étranglement.

La télémétrie cachée d'ONNX Runtime

Le détail le plus utile pour les praticiens ne concerne pas la vitesse, mais la confidentialité. L'auteur écrit qu'ONNX Runtime envoie par défaut quelque chose à Microsoft. L'annonce ne précise ni quoi ni dans quelles versions, on ne peut donc pas évaluer l'ampleur exacte de la fuite. Mais la leçon est importante : l'affirmation « le modèle fonctionne en local » ne garantit pas que l'application n'accède jamais au réseau.

Pour un produit fondé sur l'argument « les données ne quittent pas l'appareil », c'est critique. Si votre politique de confidentialité promet une chose et qu'une bibliothèque en fait discrètement une autre, vous cumulez risque juridique et perte de confiance.

Ce que doivent faire développeurs et product managers

• Vérifiez le trafic réseau de l'application sur un appareil réel, et pas seulement le code. Un proxy comme mitmproxy montre où partent les requêtes.
• Examinez les paramètres et les builds de chaque dépendance qui traite des données utilisateur, en particulier photos et documents. Désactivez tout ce qui n'est pas nécessaire.
• Intégrez la vitesse aux métriques du produit. Le traitement local est presque toujours plus lent que dans le cloud, et l'écart entre 7,8 et 3 secondes détermine si la fonctionnalité sera utilisée.
• Ne choisissez pas un LLM par défaut. Pour une tâche étroite à structure claire, un OCR léger sur l'appareil peut l'emporter en matière de confidentialité, de coût et de prévisibilité.

Limites

Nous n'avons vu que l'annonce : elle ne contient ni mesures complètes, ni modèles de téléphones, ni précision de reconnaissance, ni comparaison avec des solutions cloud. Les chiffres de 7,8 et 3 secondes correspondent à la configuration précise de l'équipe et peuvent différer sur un autre matériel. L'interprétation juridique de la loi 152-FZ dépend aussi de votre cas ; mieux vaut en discuter avec un juriste.

Ce cas montre néanmoins une voie viable : un périmètre de données fermé, un OCR open source mature et une vérification rigoureuse de ce que font réellement les dépendances. Pour les équipes qui développent des applications manipulant des données personnelles, c'est une bonne checklist pour le prochain sprint.