WinDev et WebGPU : un comparatif produit généré par une IA 100 % locale

Introduction

Dans beaucoup de projets, dès que l’on parle d’IA générative, on pense immédiatement à un service distant, à une API cloud et à des échanges réseau permanents. Ce POC WinDev prend volontairement le contre-pied de cette approche. Ici, le point central n’est pas seulement de générer un comparatif produit. Le point clé est que ce comparatif est produit par une IA qui fonctionne en local, directement sur le poste utilisateur.

L’application WinDev utilise un champ HTML dans une fenêtre métier. Ce champ charge un fichier index.html, initialise un moteur IA compatible navigateur, vérifie la disponibilité de WebGPU puis charge le modèle Llama-3.1-8B-Instruct-q4f16_1-MLC. À partir des produits sélectionnés dans l’interface, le moteur génère ensuite une synthèse comparative lisible, structurée et exploitable.

La démonstration est importante pour une entreprise comme EloNeva : il ne s’agit pas d’un appel à une IA externe masqué derrière une interface locale. Il s’agit bien d’un traitement local, exécuté au plus près de l’utilisateur, dans le périmètre même de l’application WinDev.

Un POC dont le message principal est clair

Ce type de démonstrateur peut évidemment séduire par son aspect moderne : une application WinDev qui produit un comparatif intelligent entre plusieurs produits. Mais la vraie valeur du POC se situe ailleurs. Elle se trouve dans la preuve qu’une IA locale peut être intégrée proprement dans une application métier existante.

Le message à faire passer est simple :

• les données produit sont manipulées dans l’application ;
• le moteur est chargé dans le champ HTML ;
• le modèle s’exécute sur la machine ;
• le résultat revient dans WinDev sans passer par un service cloud.

Autrement dit, l’intelligence ne se situe pas “quelque part sur Internet”. Elle est embarquée dans l’expérience locale. Cette nuance change complètement la lecture du projet, aussi bien pour les équipes techniques que pour les métiers.

Pourquoi l’exécution locale est le vrai sujet

Dans un comparatif produit, les données échangées peuvent sembler modestes : nom, prix, description, caractéristiques. Pourtant, dans un contexte réel, ces informations peuvent inclure des éléments sensibles : positionnement commercial, logique de recommandation, vocabulaire métier, sélection de références, voire arbitrage prix ou arguments de vente.

Dès lors, insister sur le fait que l’IA fonctionne en local apporte plusieurs bénéfices majeurs.

Confidentialité native

Le premier bénéfice est la maîtrise des données. Les informations utilisées pour construire le comparatif n’ont pas besoin de quitter le poste pour être interprétées. Cela réduit fortement l’exposition des données métier et facilite les discussions autour de la sécurité, de la conformité et de la confidentialité.

Dépendance réduite à l’infrastructure

Une IA locale ne repose pas sur une connectivité permanente vers un fournisseur externe. Le poste utilisateur conserve une autonomie bien plus forte. Pour certaines organisations, cette capacité est déterminante, notamment dans les environnements contraints, industriels, nomades ou peu tolérants aux dépendances réseau.

Démonstration plus crédible

Dans un POC, la crédibilité compte autant que le résultat. Montrer qu’un comparatif est généré est intéressant. Montrer qu’il est généré localement, dans la fenêtre WinDev, avec un moteur visible, un statut WebGPU actif et un modèle chargé sur le poste, est beaucoup plus fort. La démonstration devient immédiatement concrète.

Maîtrise de l’architecture

Faire fonctionner l’IA en local permet aussi de reprendre la main sur l’architecture. On ne construit pas une simple intégration d’API. On conçoit une brique d’assistance intelligente intégrée à l’application, avec sa logique de chargement, son cycle de vie et son interface métier.

Le rôle du champ HTML dans WinDev

L’un des points les plus intéressants du POC est le choix d’intégration. L’IA n’est pas injectée sous forme d’un exécutable opaque ou d’un composant externe difficile à piloter. Elle est hébergée dans un champ HTML de la fenêtre WinDev.

Ce choix a plusieurs avantages.

D’abord, il permet de charger une page dédiée, ici index.html, qui devient le point d’entrée technique du moteur local. Ensuite, il offre une surface d’affichage idéale pour exposer les statuts d’initialisation : disponibilité de WebGPU, chargement du modèle, état prêt ou erreur. Enfin, il sert de pont entre la logique WinDev et le moteur IA exécuté dans l’environnement HTML.

Le champ HTML ne doit donc pas être vu comme un simple conteneur visuel. Dans ce POC, il devient une zone d’exécution locale de l’IA. C’est lui qui héberge la pile Web nécessaire au moteur, et c’est lui qui rend visible le fait que le traitement est bien effectué sur la machine.

Fonctionnement global du POC

Le scénario d’exécution est lisible, ce qui renforce encore l’intérêt de la démonstration.

Chargement de la page locale

À l’ouverture de la fenêtre, le champ HTML charge le fichier index.html. Cette étape est importante, car elle montre que l’initialisation du moteur ne dépend pas d’une interface web distante appelée dynamiquement. La fenêtre WinDev ouvre une ressource locale qui porte toute la logique d’exécution du moteur navigateur.

Vérification de WebGPU

Une fois la page chargée, la première vérification porte sur la disponibilité de WebGPU. Ce point est capital, car il permet de confirmer que la machine peut utiliser son GPU pour accélérer l’inférence.

Cette phase est aussi très utile en démonstration. L’utilisateur ou le décideur voit immédiatement si l’environnement local est capable de supporter l’exécution du modèle. On ne parle plus d’un concept abstrait : on voit noir sur blanc que le poste est prêt à faire tourner l’IA localement.

Initialisation du moteur et du modèle

Lorsque WebGPU est disponible, le moteur charge ensuite le modèle Llama-3.1-8B-Instruct-q4f16_1-MLC. Là encore, le point important n’est pas seulement la réussite du chargement. C’est le fait que ce chargement a lieu dans l’environnement local de l’application, sans externalisation de la génération vers une IA distante.

L’interface affiche alors que le moteur est prêt. Cette notion de “prêt” est fondamentale : elle matérialise le passage d’une application métier classique à une application métier augmentée par une IA locale.

Transmission des produits sélectionnés

Quand l’utilisateur sélectionne plusieurs produits puis lance la comparaison, les informations nécessaires sont préparées dans l’application puis transmises au moteur. Le modèle reçoit les données utiles et une consigne de restitution claire : présenter les produits, mettre en avant les points forts et points faibles, puis formuler une recommandation.

Là encore, l’enjeu du POC n’est pas seulement la qualité textuelle. Il est dans la chaîne complète : WinDev prépare, le moteur local interprète, l’IA locale génère, WinDev affiche.

Retour du comparatif dans la fenêtre

Le comparatif revient enfin dans l’interface WinDev, où il est affiché à l’utilisateur. Le résultat est directement exploitable pour un usage métier : aide à la vente, aide au choix, argumentaire synthétique ou support à la décision.

Ce flux démontre clairement que la génération n’a pas été déléguée à un service externe. Le texte affiché est le produit d’une exécution locale pilotée par l’application.

Pourquoi WebGPU change la donne pour une IA locale

WebGPU joue ici un rôle déterminant. Sans lui, faire tourner un modèle de langage dans un environnement navigateur resterait beaucoup moins pertinent sur un poste classique. Avec WebGPU, le navigateur embarqué peut exploiter le GPU de la machine pour accélérer les calculs.

Pour un modèle de langage, cette capacité est essentielle. Les opérations nécessaires à l’inférence sont massivement parallélisables. Le GPU est donc un accélérateur naturel pour ce type de charge.

Dans le cadre de ce POC, WebGPU apporte plusieurs atouts :

• il rend l’exécution locale réaliste sur un poste compatible ;
• il réduit la dépendance à un backend d’inférence externe ;
• il permet de conserver une architecture légère côté application ;
• il donne une base moderne à l’intégration IA dans WinDev.

C’est précisément pour cela qu’il faut insister sur ce point dans l’article : WebGPU n’est pas un détail technique, c’est la brique qui rend crédible l’IA locale dans ce scénario.

Pourquoi le modèle Llama-3.1-8B-Instruct-q4f16_1-MLC est pertinent

Le choix du modèle renforce aussi le message du POC. Il faut un modèle suffisamment capable pour produire un comparatif utile, mais suffisamment optimisé pour rester exploitable dans un contexte local.

Dans ce cas précis, Llama-3.1-8B-Instruct-q4f16_1-MLC constitue un compromis intéressant. Il sait suivre une consigne structurée, reformuler des caractéristiques produit de manière intelligible et produire une recommandation synthétique. Surtout, il peut être utilisé dans un pipeline pensé pour l’exécution locale côté navigateur.

Ce point est stratégique : on ne cherche pas ici à faire une démonstration de puissance brute. On cherche à montrer qu’un cas d’usage métier concret peut fonctionner sur une machine locale, avec une latence acceptable et un rendu lisible.

La bataille des CORS

Dans ce type de POC, la bataille des CORS apparaît très vite comme un sujet plus concret que théorique. Dès qu’un champ HTML WinDev charge une page locale, initialise un moteur JavaScript et tente d’accéder à des ressources externes comme une bibliothèque, un manifeste de modèle ou des fichiers associés, le navigateur embarqué applique ses règles de sécurité d’origine. Résultat : une intégration qui semble simple sur le papier peut se heurter à des blocages silencieux, à des requêtes refusées ou à des comportements différents selon la façon dont les fichiers sont servis. En pratique, les CORS rappellent une règle essentielle : même dans une application desktop, dès que l’on embarque une couche web, on hérite aussi de ses contraintes.

Dans notre cas, cette “bataille des CORS” a surtout mis en évidence qu’une IA locale crédible ne dépend pas seulement du modèle et de WebGPU, mais aussi d’une stratégie propre de chargement des ressources, cohérente, maîtrisée et compatible avec le moteur HTML utilisé par WinDev.

Ce que l’écran montre réellement

L’interface du POC porte très bien le message que l’on veut transmettre.

À gauche, l’utilisateur sélectionne des produits dans la fenêtre WinDev. Au centre ou en bas, il lit le comparatif généré. À droite, une zone de statut indique que WebGPU est disponible et que le modèle local est prêt.

Cette combinaison visuelle est extrêmement parlante. Elle permet d’expliquer en une phrase ce que démontre le POC :

le comparatif affiché dans WinDev est produit par une IA qui tourne localement sur le poste utilisateur.

C’est un message beaucoup plus fort que “WinDev affiche une réponse IA”. Ici, WinDev ne fait pas que consommer une réponse. Il orchestre une exécution locale visible, compréhensible et démontrable.

Ce que cela change pour un projet métier

Mettre l’accent sur l’exécution locale ne relève pas du simple discours technique. Cela change la manière de concevoir la valeur du projet.

Dans une architecture cloud classique, la fonctionnalité IA est souvent perçue comme un service externe branché sur l’application. Dans ce POC, la logique est différente. L’IA devient une capacité embarquée de l’application métier.

Cela ouvre plusieurs perspectives :

• des outils d’aide à la vente plus autonomes ;
• des fonctions d’assistance utilisables dans des contextes réseau dégradés ;
• des usages IA mieux acceptés lorsque la confidentialité est sensible ;
• une intégration progressive de l’IA dans des applications WinDev existantes.

Pour EloNeva, cette approche est particulièrement intéressante, car elle permet d’apporter de la valeur très concrète sans imposer immédiatement une architecture lourde ou fortement dépendante d’un fournisseur tiers.

Limites et vigilance

Même si le message principal du POC est très positif, il faut garder une lecture technique réaliste.

La réussite de l’approche dépend de la compatibilité du poste, de la disponibilité de WebGPU, de la qualité des pilotes graphiques et du comportement du moteur HTML utilisé par l’application. Le temps de premier chargement du modèle peut aussi influencer l’expérience utilisateur.

Il faut également cadrer la qualité des sorties. Une IA locale bien intégrée n’est pas forcément une IA suffisante pour tous les cas d’usage. Le comparatif doit rester robuste, cohérent et aligné sur les attentes métier.

Mais ces limites ne remettent pas en cause le message central. Elles montrent simplement qu’après le POC, une phase d’industrialisation est nécessaire. Or cette industrialisation part déjà d’une preuve essentielle : oui, l’IA peut fonctionner localement dans WinDev pour produire un comparatif exploitable.

Conclusion

Ce POC doit avant tout être lu comme une démonstration d’IA locale intégrée à WinDev. Le comparatif produit n’est pas généré par un service cloud invisible. Il est obtenu à partir d’un moteur chargé dans un champ HTML, d’un modèle Llama-3.1-8B-Instruct-q4f16_1-MLC exécuté localement et d’une accélération WebGPU fournie par le poste utilisateur.

L’accent doit donc être mis sur cette réalité technique : le traitement se fait en local. Les données produit restent dans le périmètre de l’application, le moteur s’exécute sur la machine, et le résultat revient directement dans l’interface WinDev.

Pour EloNeva, c’est une perspective très prometteuse. Elle montre qu’il est possible d’ajouter de l’intelligence métier à une application existante tout en conservant la maîtrise des données, la lisibilité de l’architecture et une expérience utilisateur moderne. Ici, l’innovation ne réside pas seulement dans le comparatif généré. Elle réside dans le fait que ce comparatif est produit par une IA locale, visible, pilotée et intégrée au coeur de l’application.