Guide pratique pour créer une application mobile qui capture des reçus, extrait les données via OCR, catégorise les dépenses et exporte vers des outils comptables.
Avant de choisir des fonctionnalités ou des écrans, précisez le problème que vous résolvez. « Suivre les dépenses » est trop vague ; la vraie douleur est souvent les reçus perdus, la saisie manuelle fastidieuse et les cycles de remboursement lents.
Écrivez une phrase de problème testable à opposer à chaque décision :
« Aider les gens à capturer un reçu en quelques secondes, le transformer automatiquement en dépense complète, et le soumettre sans courir après les détails manquants. »
Cela maintient le périmètre sous contrôle et empêche votre application de devenir un outil financier générique.
La plupart des applications de reçus numériques servent plusieurs audiences :
Choisissez d'abord un utilisateur principal (souvent employés ou freelances), puis concevez l'expérience équipe-finance comme une « couche de relecture » plutôt que le flux central.
Concentrez la première version sur un petit ensemble de résultats :
Mettez-vous d'accord sur quelques métriques reflétant la valeur réelle :
Quand l'objectif, les utilisateurs, les jobs et les métriques sont clairs, le reste du développement devient une série de compromis simples plutôt que des conjectures.
Avant de choisir des fonctionnalités ou des écrans, décrivez le parcours de bout en bout que votre application doit supporter. Un workflow clair empêche que la « numérisation de reçus » ne devienne un tas d'outils déconnectés.
Au minimum, mappez le parcours complet :
Pour chaque étape, notez ce que l'utilisateur voit, quelles données sont créées, et ce qui doit arriver automatiquement (par exemple : totaux calculés, devise normalisée, taxes détectées).
Décidez des principaux points d'entrée, car ils façonnent l'UI et vos hypothèses backend :
Choisissez un « départ par défaut » pour votre MVP, puis supportez les autres comme voies secondaires.
Clarifiez qui peut faire quoi :
Concevez les règles de transfert tôt (par ex. : quand une dépense devient en lecture seule, qui peut la modifier, et comment les changements sont journalisés).
Documentez les réalités désordonnées : retours/remboursements, notes partagées, multi-devise, pourboires, reçus manquants, et per diem. Même si vous ne les automatisez pas complètement en v1, votre workflow doit prévoir un chemin clair qui ne bloque pas les utilisateurs.
Un bon modèle de données facilite tout : recherche plus rapide, moins de corrections manuelles, et exports propres pour la compta. L'essentiel est de séparer ce que l'utilisateur a capturé (le fichier original) de ce que votre appli comprend (champs normalisés sur lesquels on peut filtrer et reporter).
Traitez un Receipt comme preuve (un fichier plus les résultats d'extraction) et une Expense comme l'enregistrement métier utilisé pour le remboursement, les contrôles de politique et le reporting.
Une dépense peut avoir un reçu unique, plusieurs reçus (paiements partagés) ou aucun reçu (saisie manuelle), modélisez cela par une relation flexible.
Prévoyez un champ capture_method pour pouvoir évoluer au-delà des scans caméra :
Ce champ vous aide aussi à diagnostiquer les problèmes de qualité et à affiner l'OCR/parsing plus tard.
Au minimum, stockez ces champs sur l'Expense (même s'ils proviennent de l'OCR) : commerçant, date, total, taxe, devise, moyen de paiement. Conservez à la fois le texte brut et les valeurs normalisées (ex. codes ISO de devise, dates parsées) pour que les modifications soient réversibles et traçables.
Stockez aussi des métadonnées comme :
merchant_normalized (pour une recherche cohérente)transaction_last4 ou référence tokenisée de carte (pour éviter les doublons)timezone et locale (pour parser correctement dates/taxes)Conservez l'image/PDF brut séparément des données extraites/normalisées. Cela permet un retraitement (meilleur OCR plus tard) sans perdre l'original.
Concevez la recherche pour répondre aux vraies questions des utilisateurs :
Indexez ces champs tôt ; c'est la différence entre « scroller sans fin » et réponses instantanées.
Incluez les contrôles de rétention dans votre schéma, pas en complément :
Avec ces éléments, votre appli peut évoluer de la capture personnelle à la conformité d'entreprise sans réécrire les bases.
La capture du reçu est le moment où l'utilisateur décide si votre appli est fluide ou pénible. Traitez la caméra comme un « scanner », pas comme un outil photo : rendez le chemin par défaut rapide, guidé et tolérant.
Utilisez la détection de bords en direct et le recadrage automatique pour que l'utilisateur n'ait pas à cadrer parfaitement. Ajoutez des indices discrets et actionnables (« Rapprochez-vous », « Évitez les ombres », « Tenez stable ») et un avertissement d'éblouissement quand les reflets saturent le papier.
La capture multipage est importante pour les folios d'hôtel et les reçus longs. Laissez l'utilisateur continuer à prendre des pages dans un même flux, puis confirmer une fois.
Un peu de prétraitement améliore souvent la précision plus que changer de moteur OCR :
Appliquez ce pipeline de façon cohérente pour que l'OCR reçoive des entrées prévisibles.
L'OCR sur l'appareil est excellent pour la rapidité, l'usage hors-ligne et la confidentialité. L'OCR cloud peut être meilleur pour les images de faible qualité et les mises en page complexes. Une approche pratique est hybride :
Soyez transparent sur ce qui déclenche les uploads et donnez le contrôle aux utilisateurs.
Commencez par les champs à haute valeur : commerçant, date, devise, total, taxe et pourboire. Les lignes d'articles sont utiles mais beaucoup plus difficiles : considérez-les comme une amélioration.
Stockez un score de confiance par champ, pas seulement par reçu. Cela vous permet de surligner uniquement ce qui nécessite une attention (ex. « Total incertain »).
Après le scan, affichez un écran de relecture rapide avec des corrections en un tap (corriger le total, définir la date, changer le commerçant). Capturez les corrections comme signaux d'entraînement : si les utilisateurs modifient souvent « TotaI » en « Total », votre extraction peut apprendre ces patrons courants et s'améliorer avec le temps.
La bonne capture n'est que la moitié du travail. Pour garder les dépenses propres (et réduire les échanges), votre appli a besoin d'une catégorisation rapide, de métadonnées flexibles et de solides garde-fous contre les doublons.
Commencez par des règles déterministes que les utilisateurs comprennent et que les admins peuvent gérer. Exemples : « Uber → Transport », « Starbucks → Repas », ou « USD + codes marchands d'aéroport → Voyage ». Les règles sont prévisibles, auditable, et peuvent fonctionner hors-ligne.
Sur cela, ajoutez des suggestions basées sur le ML (optionnel) pour accélérer la saisie sans retirer le contrôle. Gardez l'UI claire : montrez la catégorie suggérée, pourquoi elle a été suggérée (ex. « basé sur le commerçant ») et laissez l'utilisateur outrepasser en un tap.
Un troisième accélérateur est les favoris utilisateur : catégories récemment utilisées par commerçant, catégories épinglées, et « dernière utilisée pour ce projet ». Elles surpassent souvent « l'IA » en vitesse réelle.
La plupart des organisations ont besoin de plus qu'une catégorie. Créez des champs personnalisés tels que projet, centre de coûts, client, et tags de politique (ex. « facturable », « personnel », « récurrent »). Rendez-les configurables par workspace, avec des règles requis/optionnels selon la politique.
Les splits sont courants : une facture d'hôtel répartie sur plusieurs projets, ou un repas de groupe partagé par participants.
Permettez de diviser une dépense en plusieurs lignes avec des catégories, projets ou participants différents. Pour les paiements partagés, laissez les utilisateurs indiquer « payé par » et allouer des parts—tout en conservant un unique reçu sous-jacent.
Exécutez des contrôles de politique à l'enregistrement et à la soumission :
Pour les doublons, combinez plusieurs signaux :
Quand vous détectez un probable doublon, ne bloquez pas immédiatement—proposez « Revoir » avec les détails côte à côte et une option sûre « Conserver les deux ».
Une appli de reçus et dépenses réussit ou échoue sur la fiabilité : les gens peuvent-ils capturer un reçu dans un café en sous-sol, faire confiance à ce qu'il ne disparaisse pas, et le retrouver quand la finance le demande ? Les décisions d'architecture prises tôt déterminent ce ressenti quotidien.
Pour un MVP, décidez si vous optimisez la vitesse de livraison ou l'expérience native de haute qualité.
La capture de reçus se fait quand la connectivité est peu fiable. Traitez le téléphone comme le premier lieu où les données sont sauvegardées.
Utilisez une file locale : quand un utilisateur soumet un reçu, stockez image + brouillon localement, marquez-le « pending », et synchronisez après. Prévoyez des retries (avec backoff exponentiel), et définissez comment gérer les conflits de sync (ex. « server wins », « latest wins », ou « demander à l'utilisateur » pour les rares cas comme des montants modifiés).
La plupart des équipes ont besoin d'un backend pour :
Garder ces services modulaires vous permet de changer de fournisseur OCR ou d'améliorer le parsing sans reconstruire l'app.
Les index comptent quand les gens cherchent « Uber » ou filtrent « Repas en mars ». Stockez noms de commerçants normalisés, dates, totaux, devise, catégories et tags. Ajoutez des index pour les requêtes fréquentes (plage de dates, commerçant, catégorie, statut), et pensez à une couche de recherche légère si « stockage et recherche de reçus » est une promesse centrale.
Utilisez la synchronisation en arrière-plan quand possible, mais ne dépendez pas uniquement d'elle. Affichez un statut clair dans l'app, et envisagez des push notifications pour des événements comme « OCR prêt », « reçu rejeté », ou « dépense approuvée », afin que les utilisateurs n'ouvrent pas l'app juste pour vérifier.
Si vous voulez valider le flux rapidement (capture → OCR → relecture → soumission) avant d'investir dans une build complète, une plateforme de type « vibe-coding » comme Koder.ai peut vous aider à prototyper et livrer plus vite via une interface pilotée par chat. C'est utile pour construire la console admin et les services backend (par ex. un panneau admin React + une API Go + PostgreSQL), itérer en « planning mode » et revenir en arrière avec des snapshots pendant les tests utilisateurs.
Les reçus et dépenses contiennent des données sensibles : noms, 4 derniers chiffres de cartes, adresses, habitudes de déplacement, et parfois des identifiants fiscaux. Traitez la sécurité et la confidentialité comme des features produit, pas seulement des cases à cocher de conformité.
Choisissez un mode de connexion qui correspond au déploiement :
Utilisez TLS pour tous les appels réseau, et chiffrez les données sensibles côté serveur. Les reçus sont souvent stockés en tant qu'images ou PDFs : sécurisez le stockage média séparément des enregistrements DB (buckets privés, URLs signées courtes, et politiques d'accès strictes).
Sur l'appareil, cachez le moins possible. Si le stockage hors-ligne est nécessaire, chiffrez les fichiers locaux et protégez l'accès derrière la sécurité OS (biométrie/code).
Définissez les rôles tôt et rendez les permissions explicites :
Ajoutez des garde-fous comme l'accès « view-only » pour les auditeurs et une visibilité restreinte pour catégories sensibles (ex. médical).
Collectez seulement ce dont vous avez besoin. Si vous n'avez pas besoin des numéros complets de carte ou des emplacements exacts, ne les stockez pas. Expliquez ce qui est extrait des reçus, combien de temps vous le conservez, et comment les utilisateurs peuvent le supprimer.
Maintenez un log d'audit pour les actions clés : qui a changé quoi, quand et pourquoi (y compris les modifications de montants, catégories et approbations). Cela facilite la résolution de litiges, les revues de conformité et le dépannage des intégrations.
Une excellente appli de reçus/dépenses ressemble à un raccourci : les utilisateurs passent des secondes à capturer, pas des minutes à corriger. L'objectif est de transformer « j'ai payé » en « prêt à soumettre » avec le moins de taps possible.
La plupart des équipes peuvent couvrir 90% des usages avec six écrans :
Concevez ces écrans comme un flux unique : capture → relecture → auto-save dans la liste → soumettre quand prêt.
Favorisez la capture à une main : gros bouton déclencheur, contrôles accessibles, et une action « Terminé » claire. Utilisez des valeurs par défaut intelligentes pour éviter la saisie répétitive—préremplissez devise, moyen de paiement, projet/client et catégories courantes.
Dans l'écran Relecture, utilisez des « chips » et actions rapides (ex. Changer catégorie, Fractionner, Ajouter participants) plutôt que de longs formulaires. L'édition inline vaut mieux que pousser l'utilisateur vers des pages d'édition séparées.
Les utilisateurs n'accepteront pas l'automatisation s'ils ne la comprennent pas. Mettez en évidence les champs extraits (commerçant, date, total) et ajoutez un court « pourquoi » pour les suggestions :
Marquez visuellement la confiance (ex. Besoin d'attention pour champs à faible confiance) pour orienter le regard.
Quand la capture est de mauvaise qualité, ne vous contentez pas d'échouer. Donnez des conseils précis : « Reçu flou—rapprochez-vous » ou « Trop sombre—activez le flash ». Si l'OCR échoue, proposez des états de retry et une saisie manuelle rapide pour les seuls champs manquants.
Utilisez une typographie lisible, un contraste fort et des cibles tactiles larges. Supportez la saisie vocale pour les notes et participants, et assurez-vous que les messages d'erreur sont annoncés par les lecteurs d'écran. L'accessibilité n'est pas un extra—elle réduit la friction pour tout le monde.
Une appli de capture devient vraiment utile quand elle fait circuler les dépenses via la relecture, le remboursement et la comptabilité avec un minimum d'échanges. Cela implique des étapes d'approbation claires, des rapports utilisables immédiatement et des intégrations avec les outils déjà en place.
Gardez le workflow simple, prévisible et visible. Une boucle typique :
Les détails comptent : montrez « ce qui a changé depuis la dernière soumission », permettez des commentaires inline sur une ligne spécifique, et conservez chaque transition d'état (Submitted → Approved → Exported, etc.). Décidez aussi tôt si les approbations se font par dépense, par rapport, ou les deux—les équipes finance préfèrent souvent approuver un rapport, tandis que les managers veulent parfois contrôler des lignes.
Supportez les exports fréquents pour éviter aux utilisateurs de reconstruire des rapports :
Si vous fournissez un PDF packet, faites en sorte que la page résumé corresponde aux attentes finance : totaux par catégorie, devise, taxe, et flags de politique (ex. « reçu manquant », « montant dépassant »).
Pour les plateformes populaires (QuickBooks, Xero, NetSuite), les intégrations consistent généralement à : créer des dépenses/factures, attacher les fichiers reçus, et mapper correctement les champs (fournisseur/commerçant, date, montant, catégorie/compte, taxe). Même si vous n'implémentez pas immédiatement des intégrations natives, fournissez un webhook/API générique pour que les équipes connectent votre appli à leurs outils.
Pour réduire les tickets support, rendez les mappings configurables : un admin doit pouvoir mapper vos catégories vers leurs comptes et définir des valeurs par défaut par équipe, projet ou commerçant.
Les utilisateurs veulent surtout savoir « quand je serai payé ? » Même si les paiements passent par la paie, votre appli peut suivre le statut de remboursement :
Si vous ne pouvez pas confirmer « Payé » automatiquement, prévoyez une étape de transfert manuelle ou un import paie pour rapprocher les statuts.
Pour la planification et les intégrations, il peut aider de préciser ce qui est inclus à chaque niveau—lier vers /pricing clarifie les attentes sans noyer le lecteur dans les détails.
Une appli de dépenses réussit quand elle supprime la corvée, pas quand elle a la plus longue liste de fonctionnalités. Commencez par la plus petite boucle utile et prouvez qu'elle marche pour de vraies personnes faisant de vrais rapports.
Construisez uniquement ce qui est nécessaire pour compléter : capture → extraction → catégorisation → export.
Autrement dit, un utilisateur peut prendre un reçu, voir les champs clés (commerçant, date, total) remplis, choisir ou confirmer une catégorie, et exporter/partager un rapport de dépenses (CSV, PDF, ou email simple). Si les utilisateurs ne peuvent pas boucler rapidement, les fonctionnalités additionnelles ne sauveront pas l'expérience.
Notez ce que vous ne construisez pas encore volontairement :
Une roadmap claire empêche le scope creep et facilite la priorisation des retours utilisateurs.
Suivez l'entonnoir capture→soumission :
Associez cela à des invites in-app légères du type « Qu'est-ce qui vous a frustré sur ce reçu ?» au moment de l'échec.
Constituez un petit jeu diversifié de reçus réels (différents commerçants, polices, langues, photos froissées). Servez-vous-en pour l'évaluation et les tests de régression afin que la qualité OCR ne se dégrade pas silencieusement.
Pilotez avec une petite équipe pendant 1–2 cycles de soumission. Demandez aux utilisateurs de corriger les champs extraits et catégoriser les reçus ; considérez ces corrections comme des données étiquetées d'entraînement/qualité. Le but n'est pas la perfection—c'est prouver que le workflow fait gagner du temps de façon cohérente.
Si l'objectif est d'arriver rapidement à une bêta fonctionnelle, envisagez d'utiliser Koder.ai pour construire les pièces de support (console admin, exports, dashboard jobs OCR et API core) depuis une spécification pilotée par chat. Comme il supporte l'export du code source, le déploiement/hosting et des snapshots avec rollback, vous pouvez itérer vite avec des pilotes tout en gardant la propriété du code à mesure que le produit mûrit.
Même des applis bien conçues peuvent échouer sur des points prévisibles. Anticiper ces problèmes tôt économise des semaines de refonte et beaucoup de tickets support.
Les reçus réels ne sont pas des photos studio. Papier froissé, encre fanée, et surtout le papier thermique produisent du texte partiel ou déformé.
Pour réduire les échecs, guidez l'utilisateur lors de la capture (recadrage auto, détection d'éblouissement, invites « rapprochez-vous ») et conservez l'image originale pour pouvoir rescanner sans ressaisir tout. Traitez l'OCR comme un « best effort »: affichez les champs extraits avec indicateurs de confiance et facilitez les corrections. Envisagez aussi une voie de secours pour les scans à faible confiance (saisie manuelle ou relecture humaine pour reçus de forte valeur).
Dates, devises et taxes varient largement. Un reçu « 03/04/25 » peut signifier différentes choses, et VAT/GST change la façon de stocker les totaux.
Évitez de coder en dur les formats. Stockez les montants comme nombres plus code devise, les dates en ISO timestamps, et conservez le texte brut du reçu pour l'audit. Gérez les champs taxe pouvant être inclus/ exclus et plusieurs lignes de taxe. Si vous multipliez les langues, conservez les noms de commerçants dans leur forme originale mais localisez les labels UI et les noms de catégories.
Les images haute-résolution sont lourdes et les uploads mobiles peuvent être lents—ce qui use la batterie et frustre.
Compressez et redimensionnez côté client, téléversez en arrière-plan avec retries, et utilisez une file pour que les reçus ne « disparaissent » pas quand le réseau tombe. Mettez en cache les reçus récents et les vignettes pour une navigation rapide. Imposez des limites mémoire pour éviter les crashes sur anciens téléphones.
Totaux altérés, soumissions en double et faux reçus apparaissent rapidement en production.
Ajoutez détection de doublons (même commerçant/montant/date, textes OCR similaires, empreintes image) et signalez les éditions suspectes (ex. total modifié après OCR). Conservez des logs immuables de ce qui a été capturé vs modifié, et exigez une justification pour les overrides manuels sur les champs sensibles aux politiques.
Les utilisateurs demanderont des exports, des suppressions, et de l'aide pour récupérer des reçus manquants.
Préparez des outils support basiques : recherche par user/ID reçu, vue du statut de traitement, relancer l'OCR, et exporter des données sur demande. Définissez des runbooks d'incident : que faire si l'OCR est down ou si les uploads échouent ? Avoir une page de statut simple (/status) et des procédures claires transforme la panique en flux gérable.
Un lancement réussi n'est pas seulement « publier sur l'App Store ». C'est fixer des attentes, observer le comportement réel, et raccourcir la boucle entre l'expérience utilisateur et les corrections de l'équipe.
Définissez des SLA pour les deux moments qui importent le plus : le traitement des reçus (OCR) et la synchronisation entre appareils.
Par ex. : si l'OCR prend habituellement 10–30 secondes mais peut être plus long sur de mauvais réseaux, dites-le : « Traitement… généralement moins de 30 s. » Si la sync peut être retardée, affichez un statut léger comme « Enregistré localement • Synchronisation » et une option de retry. Ces indications réduisent les tickets support et les uploads répétés.
Suivez un petit nombre d'indicateurs révélant les problèmes de fiabilité tôt :
Alertez sur les pics et examinez les tendances chaque semaine. Une baisse de confiance OCR signale souvent un changement de fournisseur, une mise à jour caméra, ou un nouveau format de reçu en circulation.
Ajoutez un bouton de feedback in-app près de l'écran de détails du reçu, là où la frustration survient. Facilitez les corrections, puis examinez les « logs de corrections » agrégés pour identifier les erreurs de parsing fréquentes (dates, totaux, taxes, pourboire). Utilisez cette liste pour prioriser les mises à jour de modèles/règles.
Une fois la capture et la recherche stables, pensez à :
Proposez un tour de 60 s, un reçu d'exemple que l'utilisateur peut éditer, et une courte page "conseils" (bonne lumière, surface plate). Liez vers /help/receipts pour référence rapide.
Commencez par une déclaration de problème étroite et testable (par ex. : « capturer un reçu en quelques secondes, créer automatiquement une dépense et soumettre sans détails manquants »). Puis choisissez un utilisateur principal (employés ou freelances) et définissez 2–4 indicateurs de succès mesurables, comme :
Ces contraintes évitent que le projet ne dérive vers une application financière générique.
Une boucle MVP pratique : capture → extraction → catégorisation → export/soumission.
En v1, priorisez :
Reportez les lignes d'articles, les flux de cartes, les politiques avancées et les intégrations profondes jusqu'à ce que la boucle fasse gagner du temps de façon fiable.
Cartographiez le parcours complet du « justificatif » au « payable » :
Pour chaque étape, spécifiez ce qui est automatique, ce que l'utilisateur voit et quelles données sont créées. Cela évite de construire des outils déconnectés qui n'aboutissent pas au remboursement.
Choisissez un point d'entrée par défaut pour votre MVP (généralement la capture par caméra) et ajoutez les autres en secondaire :
Ce choix impacte l'UI et les hypothèses backend (prétraitement d'images vs parsing de PDFs/HTML d'email). Suivez la source via un champ capture_method pour déboguer la qualité et la conversion par origine.
Modélisez Receipt et Expense comme des enregistrements distincts mais liés :
Gérez les relations de façon flexible : une dépense peut avoir plusieurs reçus (paiements partagés) ou aucun (saisie manuelle). Conservez à la fois le texte brut OCR et les champs normalisés pour que les modifications soient explicables et réversibles.
Offrez une expérience caméra qui se comporte comme un scanner :
Avant l'OCR, appliquez un prétraitement cohérent (deskew, correction de perspective, débruitage, contraste/normalisation d'éclairage). Souvent, cela améliore l'exactitude plus que changer de moteur OCR.
Une approche hybride est souvent la plus pratique :
Quelle que soit l'approche, stockez une confiance par champ (pas seulement par reçu) et proposez un écran de relecture rapide qui met en avant uniquement ce qui nécessite une correction (ex. « Total incertain »). Soyez transparent sur ce qui déclenche les envois et laissez l'utilisateur contrôler cela.
Commencez par des règles déterministes compréhensibles, puis superposez des suggestions :
Ajoutez des champs personnalisés (projet, centre de coût, client, tags de politique) pour que la catégorisation reflète les flux réels.
Combinez plusieurs signaux et évitez le blocage direct :
Quand un probable doublon est détecté, affichez une revue côte à côte et proposez « Conserver les deux ». Enregistrez aussi les modifications suspectes (ex. total modifié après OCR) dans une piste d'audit pour la finance.
Intégrez un mode « offline-first » dans le flux principal :
Affichez des états clairs comme « Enregistré localement • Synchronisation » et utilisez des notifications pour les événements clés (OCR prêt, rejeté, approuvé). C'est ce qui rend l'app fiable en cas de connexion instable.