Validation d'images multi-modèles avec MOBILENET + GEMINI VISION

Salut les devs,

Comment j’ai utilisé un modèle Deep Learning et un grand modèle de langue (en anglais Large Language Model LLM) pour résoudre deux (2) problèmes de chargement d'images distincts?

Tous les problèmes de vision par ordinateur ne se ressemblent pas, et tous ne nécessitent

pas le même modèle. Dans cet article, je vous  explique comment j’ai implémenté deux fonctionnalités

de validation d'images distinctes sur le formulaire de soumission de publications de PublieDev, en

utilisant deux approches complètement différentes — l'une côté client, l'autre côté

serveur et pourquoi j’ai fait ces choix.

L'objectif ici est de fournir un retour consultatif non bloquant lorsque des développeurs uploadent

des images qui ne correspondent pas aux attentes, avant que la soumission n'atteigne le comité de lecture de PublieDev. 

Les deux problèmes de chargement d’images

Le formulaire de soumission de PublieDev comporte deux champs d'upload d'images qui sont le Schéma d'architecture et la Galerie / Captures d'écran. 

Dans le champ Schéma d'architecture, il est attendu soit un diagramme UML, un schéma de conception système, un organigramme ou un dessin technique. Lorsque le chargement est incorrect c’est-à-dire une photo du développeur, photo de bureau, ou une image de stock aléatoire, cela fait perdre du temps aux évaluateurs et ralentissent l'approbation.

Il en va de même pour le champ Galerie / Captures d'écran qui attend des captures d'écran de l'application, captures d'interface ou vues de l'UI et peut se retrouver avec des photos de nourriture, photos de nature ou des photos personnelles qui vont nuire à la crédibilité de la revue. 

Ainsi ces deux problèmes nécessitent des solutions différentes car ils relèvent de tâches fondamentalement différentes.

Des modèles différents pour des problèmes différents

MobileNet (entraîné sur ImageNet) est aveugle au contenu technique des diagrammes. Il voit

des pixels — des boîtes et des flèches sur fond blanc obtiennent au mieux les classes

« enveloppe » ou « page web ». Un diagramme ne peut pas être validé par sa forme visuelle

seule ; cela requiert de comprendre “CE QUI” est représenté.

Gemini Vision, en tant que LLM multimodal, peut raisonner ainsi : « Cette image montre des

boîtes reliées par des flèches avec des étiquettes comme "Firestore", "Cloud Functions" et

"Client". C'est un diagramme d'architecture système. » Il s'agit de compréhension visuelle

sémantique, pas de simple reconnaissance de formes.

À l'inverse, pour les captures d'écran de galerie, les classes ImageNet de MobileNet

incluent : « screen » (écran), « monitor » (moniteur), « desktop computer » (ordinateur de

bureau), « laptop » (portable), « notebook » (ordinateur portable), « hand-held computer »

(assistant personnel) — qui sont exactement les classes qu'une capture d'interface générerait.

Gemini Vision fonctionnerait, mais est plus lent (~800ms vs <100ms), plus coûteux (appel API vs inférence locale gratuite) et surdimensionné pour un simple test binaire « est-ce que ça ressemble à un écran ? »

Le bon modèle dépend entièrement de ce que l'on cherche à détecter.

La latence totale (service chaud) est d’environ 800 ms–1200 ms et le coût d’environ 0,0001 $ par validation (tarification Gemini 2.0 Flash)

IMPLÉMENTATION

Partie A : Validation côté client avec MobileNet

Chargement de TF.js (uniquement quand le champ galerie change)

Les décisions de conception liées au chargement sont : TF.js (~3,8 Mo) + les poids MobileNet (~16 Mo) ne se téléchargent que si l'utilisateur charge réellement une image. La plupart des utilisateurs naviguent sans interagir avec la section galerie. Une fois chargé, le modèle reste en mémoire pour toute la session (cache mobilenetModel) et l'utilisation de createObjectURL évite l'encodage base64 pour la validation côté client. 

MobileNet v2 classify() retourne les 3 classes ImageNet les plus probables avec leurs scores.

Nous n'utilisons pas les probabilités — la présence d'un TECH_KW dans les 3 noms de classes est suffisante.

Partie B : Validation côté serveur avec Gemini Vision

Ci-dessous les détails clés de l'implémentation: 

Une température à 0,1 (quasi-déterministe) qui pour une classification binaire OUI/NON, nous voulons des réponses cohérentes. Une température plus élevée ferait qu'une même image pourrait obtenir OUI lors d'un appel et NON lors d'un autre.

maxOutputTokens à 80 :OUI/NON + une phrase ≈ 10 à 25 tokens. On plafonne à 80 pour éviter des réponses verbeuses tout en laissant de la place pour les phrases françaises plus longues.

Prompt multi-parties (tableau avec media + text) : La fonction ai.generate() de Genkit accepte un tableau pour les entrées multimodales. La partie media envoie l'image en ligne via une data URL en base64. La partie textcontient l'instruction.

Analyse de la réponse : Le format de réponse « OUI\nexplication » ou « NON\nexplication » est imposé par le prompt. On découpe sur les sauts de ligne et on vérifie la première ligne pour « YES ».

Endpoint HTTP avec protection taille 2 Mo  

La limite de 2 800 000 caractères en base64 (≈ 2 097 152 octets décodés) est cruciale pour protéger le système contre l'upload accidentel de grandes photos RAW de 30 Mo et plus, tout en prévenant le flood de payloads malveillants et en évitant un coût excessif en tokens Gemini Vision par appel.

 Code côté client (envoi de l'image) :

Le e.target.result.split(',')[1] extrait uniquement le payload base64 de la data URL (supprime le préfixe « data:image/png;base64, » que FileReader ajoute automatiquement).

Notes sur la précision en conditions réelles

En ce qui concerne la précision de Gemini Vision pour la validation des schémas d'architecture, le modèle identifie correctement les diagrammes de classes UML, les diagrammes de séquence, les schémas de conception système, ainsi que les esquisses d'architecture dessinées à la main et les diagrammes de topologie réseau. Toutefois, il existe des cas limites où les diagrammes minimalistes comportant peu d'étiquettes peuvent générer une réponse hésitante. Pour pallier cela, l'utilisation d'une température réglée à 0,1 garantit la cohérence des résultats lors d'appels répétés pour une même image. 

Pour la validation des captures d'écran via MobileNet, la solution fonctionne efficacement pour les interfaces UI de smartphones, les applications de bureau, les tableaux de bord et les interfaces mobiles. Des faux négatifs sont néanmoins connus, notamment avec les terminaux à thème sombre ou les éditeurs de code qui peuvent être classifiés en « monitor » mais parfois rater la classe « screen ». À l'inverse, des faux positifs peuvent survenir, comme la photo d'une personne utilisant un ordinateur portable, car « laptop » fait partie des mots-clés techniques. Ce comportement reste acceptable car il est préférable de laisser passer quelques images incorrectes plutôt que de bloquer des captures d'écran légitimes.

Dans les deux cas : le comité éditorial est informé et prend la décision finale. La validation par les modèles est un pré-filtrage, pas une prise de décision.

Analyse des coûts

À notre échelle actuelle, cette implémentation n'ajoute pratiquement aucun coût à l'infrastructure.

Résumé des compromis architecturaux

Pour soumettre vos travaux, rendez-vous sur publiedev.com

Sur ce, je vous remercie et passez une excellente semaine !