POC WinDev : extraction de factures par IA locale avec Gemma et WebGPU

La saisie manuelle des notes de frais : un gouffre discret

Un responsable commercial rentre d’un déplacement de trois jours. Il a une quinzaine de justificatifs : restaurants, hôtel, carburant, péage. Il ouvre le logiciel de notes de frais. Et il commence à taper.

C’est lent. C’est sujet à erreur. Et ça arrive tous les mois.

Dans une PME de 30 à 80 personnes avec des équipes mobiles, la saisie manuelle des NDF représente facilement deux à quatre heures par personne et par mois, entre la saisie, la correction et le contrôle comptable. Multiplié par dix collaborateurs en déplacement régulier, le coût caché dépasse facilement une journée de travail par cycle.

Ce POC part d’une question simple : est-il possible d’extraire automatiquement les données d’une photo de facture — date, type de dépense, montant TTC — sans envoyer ces données vers un service cloud ? Avec WinDev comme socle applicatif et Gemma-4-E2B-it comme modèle vision local, la réponse est oui.

Ce que démontre ce POC

L’objectif n’est pas de produire un module NDF complet. C’est de prouver une chose : une IA vision multimodale peut fonctionner localement dans WinDev, analyser une image de facture, et retourner un JSON structuré exploitable directement par l’application.

Le scénario est volontairement simple et représentatif du cas métier réel.

Import d’une photo de facture dans WinDev

L’utilisateur sélectionne ou capture une photo de justificatif : ticket restaurant, note d’hôtel, reçu de carburant, ou facture diverse. L’image est transmise au champ HTML de la fenêtre WinDev, qui joue le rôle de zone d’exécution du moteur IA.

Pas de redimensionnement, pas de pré-traitement complexe. L’image brute est envoyée au modèle, comme elle est. C’est une contrainte volontaire du POC : tester la robustesse réelle dans des conditions terrain.

Gemma-4-E2B-it : un modèle vision embarqué via WebGPU

Gemma-4-E2B-it est un modèle de la génération Gemma 4 de Google, sorti en 2025. La variante E2B signifie “Efficient 2 Billion” — environ 2 milliards de paramètres, quantizé pour l’exécution sur GPU grand public. Le suffixe “it” indique qu’il est instruction-tuned : il suit des consignes structurées, ce qui est précisément ce dont on a besoin pour extraire un JSON.

Ce qui le distingue pour ce cas d’usage : il est multimodal. Il accepte à la fois une image et du texte en entrée. On lui passe la photo de la facture avec une consigne précise, et il produit un JSON.

La variante WebGPU du modèle tourne via WebLLM dans l’environnement navigateur embarqué de WinDev. Elle est conçue pour des GPU grand public avec 4 à 8 Go de VRAM — des machines de bureau ou portables professionnels courants.

Le résultat : un JSON structuré, sans cloud

Le modèle reçoit l’image et une consigne de type :

Analyse cette facture et retourne uniquement un JSON valide avec les champs suivants :
{"date": "YYYY-MM-DD", "type": "restaurant|hotel|carburant|autre", "montant_ttc": float}

Le résultat retourné par le modèle ressemble à :

{"date": "2026-03-18", "type": "restaurant", "montant_ttc": 42.50}

Ce JSON est récupéré par WinDev, parsé, et les champs sont automatiquement renseignés dans le formulaire NDF. L’utilisateur valide ou corrige. Il ne saisit plus de zéro.

Aucune donnée ne quitte le poste. Pas de clé API, pas d’abonnement à un service cloud de reconnaissance documentaire, pas de facture transmise à un tiers.

Comment ça fonctionne techniquement

Le champ HTML WinDev comme zone d’exécution IA

WinDev dispose d’un composant natif : le champ HTML. Dans ce POC, ce champ ne sert pas à afficher une page web externe. Il héberge un fichier index.html local qui initialise le moteur WebLLM, vérifie la disponibilité de WebGPU, charge le modèle Gemma-4-E2B-it et gère les échanges avec l’application WinDev.

C’est la même approche que dans notre POC précédent avec Llama-3.1-8B pour la génération de comparatifs produits. La différence ici : le modèle est multimodal, il reçoit une image en plus du prompt texte.

Le champ HTML devient une brique d’inférence locale embarquée dans l’application métier. L’architecture reste simple : WinDev prépare l’image et le prompt, les envoie au champ HTML via des appels JavaScript, et récupère la réponse JSON.

WebGPU : l’accélérateur qui rend le local crédible

Sans WebGPU, faire tourner un modèle vision de 2 milliards de paramètres sur un poste standard prendrait plusieurs dizaines de secondes par inférence. Ce n’est pas utilisable en pratique.

Avec WebGPU, le navigateur embarqué peut déléguer les calculs au GPU de la machine. Pour un modèle quantizé comme Gemma-4-E2B-it, cela ramène le temps d’inférence à quelques secondes sur un poste compatible — acceptable pour un usage NDF.

WebGPU n’est pas un détail technique dans ce contexte. C’est la condition sine qua non pour que l’IA locale soit crédible face à une API cloud.

La chaîne complète : WinDev → image → modèle → JSON → application

Le flux complet est lisible :

1. L’utilisateur importe ou capture la photo dans WinDev
2. WinDev encode l’image et prépare le prompt structuré
3. Le champ HTML reçoit image + prompt, les transmet au moteur WebLLM
4. Gemma-4-E2B-it analyse l’image localement via WebGPU
5. Le modèle retourne un JSON structuré
6. WinDev parse le JSON et pré-remplit le formulaire NDF

À aucun moment une connexion réseau externe n’est établie pour le traitement. Le modèle, une fois chargé, fonctionne hors ligne.

Les limites réelles à connaître avant de décider

La qualité de la photo : premier facteur de fiabilité

C’est la limite principale. Un ticket de caisse flou, photographié de biais avec un mauvais éclairage, donnera des résultats médiocres — parfois un montant erroné, parfois une date manquante.

Dans les tests terrain de ce POC, les photos correctement cadrées, avec un éclairage suffisant, donnent des extractions fiables à plus de 85 %. Les photos dégradées tombent à 50-60 % de fiabilité. C’est un chiffre qui milite pour un flux de validation humaine systématique, au moins dans un premier temps.

L’erreur serait de croire qu’un modèle 2B remplace un OCR cloud spécialisé sur des cas dégradés. Il ne le remplace pas. Il complète ou automatise le cas standard — ce qui représente déjà l’essentiel du volume en pratique.

VRAM, compatibilité poste, chargement initial

Gemma-4-E2B-it quantizé nécessite environ 3 à 4 Go de VRAM pour tourner via WebGPU. Un poste avec une carte graphique intégrée récente (Intel Iris Xe, AMD Radeon intégré de génération récente) ou une dédiée d’entrée de gamme peut suffire.

Le temps de chargement initial du modèle est de 20 à 60 secondes selon le poste, lors de la première utilisation. Après le premier chargement, le modèle reste en mémoire tant que la session est ouverte. C’est acceptable en pratique si l’utilisateur lance le module NDF en début de session.

Un poste sans WebGPU compatible affiche une erreur à l’initialisation. Il faut donc prévoir un fallback — saisie manuelle ou redirection vers un service alternatif — pour les postes non compatibles.

Arbitrage : quand ce POC mérite d’être industrialisé

Ce POC n’a pas vocation à être déployé tel quel en production. Il démontre une faisabilité. La décision d’industrialiser dépend de quelques conditions claires.

Pour quels volumes et quels profils PME ?

Ce type de solution est pertinent si :

• La PME traite plus de 50 justificatifs par mois en volume consolidé
• Elle dispose d’un parc de postes relativement homogène et récent (GPU compatible WebGPU)
• Elle a une contrainte réelle sur la confidentialité des données financières (secteur sensible, audit en cours, données clients sur les justificatifs)
• Elle veut éviter un abonnement cloud supplémentaire pour la reconnaissance documentaire

Elle est moins pertinente si le volume est faible, si le parc est hétérogène avec des postes anciens, ou si la PME utilise déjà un outil de gestion des frais avec OCR intégré performant.

IA locale vs API cloud de reconnaissance documentaire

Le bon arbitrage n’est pas “l’un ou l’autre”. C’est “lequel est cohérent avec le contexte de la PME”. Une PME avec des données sensibles et un parc récent a des raisons solides de regarder l’option locale. Une PME avec un parc vieillissant et un faible volume ira plus facilement vers une API.

Dans le cadre d’une modernisation progressive d’une application WinDev existante, intégrer une brique d’IA locale comme celle-ci représente une évolution ciblée et réversible — sans refonte de l’architecture globale.

Aide à la décision : 5 questions à vous poser

Avant de décider si ce type de POC mérite d’être industrialisé dans votre contexte, posez-vous ces questions :

1. Quel est le volume mensuel de justificatifs traités ? En dessous de 30-40 pièces par mois, l’automatisation ne justifie pas l’investissement d’intégration. Au-delà de 100 pièces, le gain est mesurable dès les premiers mois.

2. Vos postes utilisateurs sont-ils compatibles WebGPU ? Un inventaire rapide des GPU installés sur les postes concernés évite les mauvaises surprises au déploiement. Moins de 20 % des postes compatibles = frein opérationnel réel.

3. Avez-vous une contrainte de confidentialité sur vos données financières ? Si vos justificatifs contiennent des informations clients ou des données commerciales sensibles, envoyer ces images vers un cloud tiers pose une question de conformité que peu de PME ont formalisée.

4. Votre application WinDev est-elle maintenue et évolutive ? Ce POC suppose une capacité à modifier l’application existante. Si l’application souffre d’une dette technique importante, commencer par là avant d’ajouter une couche IA.

5. Êtes-vous prêt à maintenir un flux de validation humaine ? L’IA locale n’est pas infaillible sur des photos dégradées. Un flux où l’utilisateur valide l’extraction avant d’enregistrer est non négociable en production comptable.

Questions fréquentes

Gemma-4-E2B-it est-il vraiment capable d’analyser des photos de factures ?

Oui — à condition que la photo soit lisible. Gemma 4 est un modèle multimodal : il reçoit une image et du texte simultanément. La variante E2B (Efficient 2B) est instruction-tuned, ce qui signifie qu’il suit des consignes structurées comme “retourne un JSON avec ces champs précis”. Sur des tickets restaurant standards ou des factures hôtel classiques bien cadrés, l’extraction est fiable. Sur des reçus thermiques froissés ou des photos en contre-jour, les résultats sont variables. C’est un modèle de 2 milliards de paramètres — puissant pour sa taille, mais pas comparable à un OCR cloud spécialisé entraîné sur des millions de factures.

Faut-il une connexion internet pour faire tourner ce POC ?

Non, une fois le modèle chargé. Le premier chargement nécessite de télécharger les poids du modèle (plusieurs centaines de Mo), mais ensuite l’inférence est 100 % locale. C’est précisément ce qui en fait un cas d’usage pertinent pour des environnements avec contraintes réseau ou des exigences de confidentialité strictes. Le modèle reste en mémoire tant que la session WinDev est active.

Quelle configuration matérielle est nécessaire pour ce type d’IA locale ?

Un GPU compatible WebGPU avec 4 Go de VRAM minimum est recommandé. En pratique, les cartes graphiques intégrées des processeurs Intel Core de 12e génération et suivantes, ainsi que les AMD Radeon intégrés récents, supportent WebGPU. Les GPU dédiés d’entrée de gamme (NVIDIA GTX 1650, RTX 3050 et suivants) fonctionnent aussi. Les postes plus anciens avec GPU intégré de génération 2018-2020 peuvent bloquer sur la compatibilité WebGPU. Un test rapide avec la page de diagnostic WebGPU de MDN permet de vérifier avant tout développement.

Quel est le risque si le modèle extrait un montant erroné ?

C’est le risque opérationnel principal. Une extraction incorrecte non détectée dans une note de frais peut générer un remboursement erroné. C’est pourquoi un flux de validation humaine est non négociable en production. L’utilisateur voit le JSON extrait avant enregistrement, corrige si besoin, et valide. L’IA réduit le travail de saisie, elle ne le remplace pas intégralement. En pratique, même à 85 % de fiabilité, le gain de temps est réel : sur 10 justificatifs, 8-9 sont pré-remplis, 1-2 nécessitent une correction manuelle.

Ce POC est-il directement utilisable en production ?

Non. C’est un démonstrateur de faisabilité, pas un module prêt à déployer. Pour aller en production, il faut : gérer les cas de compatibilité WebGPU (fallback pour postes non compatibles), robustifier la gestion des erreurs de parsing JSON, définir le flux de validation utilisateur, et tester sur un corpus représentatif de vos justificatifs réels. Ce travail d’industrialisation est distinct du POC. Un audit applicatif préalable de l’application WinDev cible permet d’estimer le périmètre réaliste d’intégration.

Conclusion

Ce POC répond à une question que beaucoup de PME n’ont pas encore posée : est-il possible d’automatiser la saisie des notes de frais sans envoyer les données financières dans un cloud tiers ?

La réponse est oui — avec des conditions claires.

Gemma-4-E2B-it via WebGPU dans un champ HTML WinDev fonctionne. Le JSON est produit localement, les données restent sur site, et l’intégration dans une application WinDev existante est réaliste sans refonte.

Les limites sont connues et gérables : qualité photo, compatibilité GPU, temps de chargement initial. Ce ne sont pas des blocages — ce sont des paramètres à intégrer dans la décision d’industrialisation.

La prochaine étape n’est pas forcément de déployer. C’est de mesurer votre volume de justificatifs réels, de vérifier la compatibilité de vos postes, et de décider si le gain opérationnel justifie l’intégration. Ce POC vous donne les éléments pour trancher — pas une réponse universelle.

Est-ce que vos équipes perdent du temps sur la saisie des notes de frais chaque mois ?