Google ne propose pas d’API publique estampillée « Google Lens » que les développeurs pourraient appeler directement. La fonctionnalité de recherche visuelle, omniprésente sur Android et dans Chrome, repose sur des briques internes auxquelles Google n’ouvre pas d’accès commercial dédié. Pour reproduire tout ou partie des capacités de Lens dans une application tierce, il faut passer par des chemins détournés : l’API Cloud Vision, le module Product Search, ou des services tiers qui automatisent des requêtes côté client.
Cette absence d’API directe crée un flou que beaucoup de guides esquivent. Elle conditionne pourtant chaque décision technique, du choix de la brique d’identification visuelle au traitement des données personnelles.
A voir aussi : Comment obtenir rapidement l'adresse mail pour contacter CDC Habitat efficacement
Cloud Vision et Product Search : les briques réellement disponibles
L’API Cloud Vision reste le point d’entrée principal pour qui veut analyser des images via l’infrastructure Google. Elle couvre la détection de labels, la reconnaissance de texte (OCR), la détection de visages, la recherche de logos et la modération de contenu. Pour la recherche de produits similaires à partir d’une photo (le cas d’usage le plus associé à Lens), c’est le module Product Search de Cloud Vision qui entre en jeu.
La distinction compte. Cloud Vision traite l’image comme un objet à classifier. Product Search va plus loin : il compare l’image soumise à un catalogue de produits préalablement indexé. Avant de pouvoir exploiter cette fonctionnalité, il faut créer un « product set », y importer les références avec leurs images, puis attendre l’indexation. Le processus demande une préparation côté données qui n’a rien de trivial.
A lire aussi : Tout savoir sur le monde de l'informatique : actualités, conseils et innovations
L’authentification s’appuie sur un compte de service Google Cloud, avec un jeton de support (bearer token) ou les identifiants par défaut de l’application (ADC). L’approche recommandée par Google passe par la création d’un compte de service au format JSON, puis l’activation de la gcloud CLI pour obtenir un jeton d’autorisation.
Chaque requête envoyée à l’API doit inclure ce jeton dans l’en-tête Authorization. Ceux qui souhaitent intégrer l’API Google Lens via Cloud Vision doivent anticiper cette couche d’authentification dès la conception de leur architecture.
Services tiers type SerpApi : ce qu’ils font et ce qu’ils ne font pas
Faute d’API officielle Lens, des services comme SerpApi proposent de simuler des requêtes Google Lens en automatisant la soumission d’images au moteur de recherche. Le principe : l’image est envoyée au service tiers, qui la transmet à Google comme le ferait un utilisateur, puis récupère et structure les résultats (produits similaires, sources visuelles, texte détecté).
Cette approche fonctionne, mais elle comporte des limites structurelles :
- La stabilité dépend de l’interface Google, qui peut changer sans préavis. Une modification du rendu des résultats Lens casse potentiellement le parsing côté tiers.
- Les conditions d’utilisation de Google n’autorisent pas explicitement le scraping automatisé de ses résultats de recherche. Le risque juridique existe, même si ces services opèrent depuis plusieurs années.
- La latence est supérieure à un appel API natif : la requête transite par un intermédiaire qui doit lui-même interroger Google, parser le HTML, puis renvoyer un JSON structuré.
Pour un prototype ou un outil interne à faible volume, ces services offrent un raccourci efficace. Pour une application en production à fort trafic, la dépendance à un tiers non contractualisé avec Google représente un risque opérationnel que les retours terrain confirment.
Données d’entraînement et RGPD : un angle que les guides techniques ignorent
Frandroid et d’autres médias français ont rapporté que les contenus soumis via Lens et d’autres services Google Search peuvent devenir des données d’entraînement pour Gemini et d’autres modèles d’IA de Google. En Europe, cette option n’est pas encore activée par défaut en raison des contraintes RGPD, mais Google indique que les conditions d’utilisation peuvent évoluer à partir du 30 juillet 2026.
Pour une application B2B qui traite des images sensibles (documents internes, photos de production, imagerie médicale), cette information change la donne. Chaque image envoyée à Cloud Vision ou transitant par un service simulant Lens peut potentiellement alimenter les modèles de Google.
Les conséquences pratiques sont directes :
- La politique de confidentialité de l’application doit mentionner explicitement que les contenus visuels soumis transitent par les serveurs Google et peuvent être utilisés à des fins d’amélioration de modèles.
- Le DPA (Data Processing Agreement) signé avec Google Cloud doit être vérifié sur ce point précis, avec si possible un mécanisme d’opt-out contractuel.
- Pour les cas les plus sensibles, une segmentation des flux s’impose : les images confidentielles passent par un modèle hébergé en interne, les images publiques par Cloud Vision.
Les données disponibles ne permettent pas de conclure sur la manière exacte dont Google traitera ces contenus après juillet 2026. Les retours terrain divergent sur la portée réelle de l’opt-out proposé par Google dans ses paramètres utilisateur, qui ne couvre pas nécessairement les appels API effectués via un compte de service.
Anonymisation avant envoi : une précaution technique sous-estimée
Flouter les métadonnées EXIF, supprimer les informations de géolocalisation, redimensionner les images avant de les soumettre à l’API : ces étapes réduisent la surface d’exposition. Elles n’éliminent pas le risque lié au contenu visuel lui-même, mais elles limitent les données contextuelles exploitables par un tiers.
Bonnes pratiques techniques pour une intégration robuste
La documentation Google insiste sur plusieurs points que les intégrateurs négligent souvent en phase de développement, pour les découvrir en production.
Le mécanisme de retry avec intervalle exponentiel (exponential backoff) est indispensable. Les API Google appliquent des quotas stricts, et une rafale de requêtes après un premier échec aggrave la situation. Chaque tentative doit espacer davantage l’appel suivant.
Le cache des résultats réduit à la fois les coûts et la latence. Si la même image est soumise plusieurs fois (cas fréquent dans un contexte e-commerce où les fiches produit sont consultées en boucle), stocker le résultat localement pendant une durée définie évite des appels inutiles.
La gestion des erreurs doit distinguer les erreurs transitoires (timeout réseau, quota temporairement atteint) des erreurs permanentes (image corrompue, format non supporté). Traiter les deux de la même façon, c’est gaspiller des ressources en tentatives vouées à l’échec.
L’accès aux API se fait exclusivement en SSL. Toute requête non chiffrée sera rejetée. Ce point paraît évident, mais des configurations de proxy ou de load balancer mal paramétrées cassent parfois la chaîne TLS sans que l’erreur soit immédiatement lisible dans les logs applicatifs.
L’absence d’API Google Lens dédiée oblige chaque projet à assembler ses propres briques. Cette contrainte a un avantage : elle force une réflexion architecturale en amont, là où une API clé en main aurait encouragé une intégration superficielle. Le vrai travail commence après le premier appel réussi, quand il faut gérer les quotas, protéger les données et maintenir la compatibilité dans la durée.