Ce qui est réalisé
Extraction locale depuis des photos et production de données structurées avec conservation du texte brut. Une variante vidéo distincte prévoit l’extraction de vues nettes et l’assemblage des chevauchements.
Données documentaires / UML activité
Du ticket de caisse
à la donnée vérifiable.
Un ticket est facile à photographier. En extraire des données justes, repérer les ambiguïtés et contrôler le total demande un travail plus précis.
Le besoin
Transformer les photos de tickets collectées dans le Drive en données structurées — articles, prix, remises, total — pour suivre ses achats et l’évolution des prix, sans ressaisie.
Un choix de départ : tout reste local
Les tickets décrivent des habitudes de consommation. Le traitement a donc été cadré pour fonctionner sur le PC, sans envoyer les photos à une API distante. Deux approches locales ont été essayées : un modèle multimodal servi par Ollama, qui lit l’image d’un bloc, et PaddleOCR associé à des règles explicites, sur lequel repose l’itération documentée.
Ce qui a été observé
Sur un ticket de référence photographié en deux parties, l’itération documentée a retrouvé les 42 articles et leurs montants, ainsi que les 15 remises. Un libellé reste mal reconnu.
Le périmètre compte. Ces résultats concernent un ticket et un format précis. Ils ne constituent pas une mesure de fiabilité sur tous les magasins.
Le processus documenté
Extraire un ticket et rendre l’incertitude visible
UML 2 · diagramme d’activité← Faire défiler le schéma →
Règles de gestion
Ce que l’outil doit respecter.
- RG-01Aucune photo n’est envoyée à un service distant pour la reconnaissance.
- RG-02Le JSON reprend toutes les informations imprimées, pas seulement l’enseigne, la date et le total.
- RG-03Le fichier de sortie porte le nom de la photo d’entrée, seule l’extension change : la traçabilité est immédiate.
- RG-04Somme des articles moins remises = total imprimé : sinon, les champs incertains sont signalés, jamais corrigés en silence.
Ce qui reste à travailler
- Structurer complètement l’en-tête, les paiements et la fidélité.
- Tester d’autres enseignes et conditions de prise de vue.
- Rendre les champs incertains faciles à relire.
Ce que ce projet démontre
Une extraction utile associe reconnaissance, règles métier et contrôle. L’IA fournit une lecture ; le processus doit rendre visibles les erreurs possibles.
Résultats issus des essais de septembre 2026. Aucun ticket personnel ni numéro de paiement n’est reproduit ici.
État au 13 octobre 2026
Une réalisation, un périmètre précis.
Ce qui a été vérifié
Sur le ticket photo de référence : 42 montants d’articles et 15 remises conformes, un libellé restant imparfait. La variante vidéo n’a reçu que des tests synthétiques et OCR simulés.
Limites actuelles
Paiements, fidélité et mentions annexes restent à structurer. L’échantillon photo ne valide pas toutes les enseignes ; aucune vraie vidéo n’est validée.
Prochaine étape
Constituer un petit jeu de tickets de plusieurs enseignes, préciser les champs à relire et valider la variante vidéo sur une capture réelle.
Exemples de critères de recette
Ces critères décrivent le résultat attendu. Ils ne constituent pas, à eux seuls, des tests réussis.
- Sur le ticket de référence, restituer les 42 montants et 15 remises attendus tout en signalant le libellé incertain.
- Pour un total incohérent ou un texte ambigu, conserver la lecture brute et demander une relecture sans modifier silencieusement les valeurs.
Parlons de votre projet
Un besoin concret.
Une première discussion.
Un processus trop manuel, une donnée peu fiable ou une idée à tester ? Commençons par clarifier ce qui vous serait vraiment utile.
Échanger avec Loïc