Google Cloud Vision API - Vraiment utile en IT et cybersécurité ?

Quand il faut extraire du texte, reconnaître un logo ou filtrer des images sensibles sans monter une chaîne de vision artificielle sur mesure, la question utile n’est pas "est-ce possible ?", mais "qu’est-ce qui marche vite, proprement et à quel prix". Le service google cloud vision répond à ce besoin avec des appels API pour analyser des images, renvoyer de l’OCR, des libellés, des objets ou un signal de modération. Je vais surtout regarder ce qui compte pour un projet IT ou cybersécurité: le périmètre réel, l’intégration, les coûts et les limites qu’il vaut mieux connaître avant de le brancher en production.

Ce que l’API sait faire, et ce qu’il ne faut pas lui demander

La documentation Google Cloud précise que l’API fonctionne en REST via des requêtes POST et renvoie du JSON. En pratique, cela en fait un service assez simple à intégrer dans un backend, une fonction serverless ou un outil interne. Son intérêt n’est pas de remplacer une plateforme de vision complète, mais d’offrir un socle rapide pour des besoins visuels génériques.

Je la découpe généralement en deux familles d’usage. D’un côté, l’OCR avec TEXT_DETECTION pour du texte clair et peu dense, puis DOCUMENT_TEXT_DETECTION pour les PDF, les TIFF, les captures d’écran chargées ou l’écriture manuscrite. De l’autre, les signaux visuels plus larges: labels, logos, landmarks, couleurs dominantes, localisation d’objets et SafeSearch.

• OCR léger pour lire un texte court dans une image, une étiquette, une capture ou un panneau.
• OCR dense pour des pages scannées, des documents ou des fichiers multipages.
• Labels et objets pour comprendre rapidement ce que contient une scène.
• Logos et landmarks pour identifier une marque ou un lieu connu.
• SafeSearch pour obtenir un signal de contenu explicite avec les catégories adult, spoof, medical, violence et racy.

En revanche, je ne lui demanderais pas de faire de la reconnaissance faciale individuelle, ni de produire une taxonomie métier très précise sans couche complémentaire. Si vous avez besoin d’un classement spécifique à votre activité, le bon réflexe est souvent de compléter la Vision API par un modèle dédié ou par une logique métier en aval. C’est précisément ce qui mène à ses usages les plus utiles en informatique et en cybersécurité.

Pourquoi je la trouve utile en informatique et en cybersécurité

Dans un contexte IT, le vrai gain vient du fait qu’une image cesse d’être un bloc opaque. Elle devient un signal exploitable par un workflow, un moteur de règles ou une file de revue humaine. C’est là que la Vision API devient intéressante: elle ne remplace pas l’analyse métier, mais elle accélère la première lecture.

Je recommande malgré tout de traiter ces sorties comme des indices de triage, pas comme une vérité finale. Pour un portail public ou un espace collaboratif, cela évite de laisser passer du contenu à risque tout en gardant une revue humaine sur les cas ambigus. Autrement dit, le service fait gagner du temps, mais il ne dispense pas d’une gouvernance de décision.

Comment je l’intègre proprement dans un projet

Pour intégrer le service sans alourdir l’architecture, je pars toujours du même enchaînement: projet, authentification, choix des fonctionnalités, puis test sur un petit lot d’images réelles. Ce n’est pas l’étape la plus brillante, mais c’est celle qui évite la plupart des mauvaises surprises en coût et en précision.

1. Je crée un projet Google Cloud et j’active la facturation.
2. J’active l’API Vision pour ce projet.
3. J’installe et initialise gcloud pour gérer le projet et l’authentification.
4. En production, j’utilise un compte de service avec des droits minimaux plutôt qu’un compte personnel.
5. Je choisis la bonne fonction selon le besoin: OCR, labels, SafeSearch, objets ou logos.
6. J’appelle l’endpoint v1/images:annotate via une bibliothèque cliente, REST ou gRPC.
7. Si le volume monte, je passe au traitement par lot et je stocke les fichiers lourds dans Cloud Storage plutôt que de les pousser en base64 dans un JSON surdimensionné.

Je garde aussi trois règles de bon sens. D’abord, j’évite d’envoyer des images trop compressées, surtout pour l’OCR. Ensuite, je ne surcharge pas la requête si le fichier peut être référencé depuis un stockage objet. Enfin, je teste toujours avec des fichiers proches du réel: captures d’écran floues, photos prises en biais, scans partiels, pages avec contraste médiocre. C’est là que les écarts apparaissent vraiment, pas sur les démonstrations parfaites.

Pour les formats, la couverture est confortable: JPEG, PNG, GIF, BMP, WEBP, RAW, ICO, PDF et TIFF sont pris en charge. La bonne nouvelle, c’est que cela couvre la plupart des cas d’entreprise; la moins bonne, c’est qu’un format supporté n’est pas forcément un format performant. C’est justement ce qui m’amène au sujet des coûts et des limites pratiques.

Ce que cela coûte vraiment et où la précision baisse

Le prix se comprend mal si on oublie que la facturation est faite par image et par fonctionnalité. Une même photo analysée pour des labels et pour du texte compte donc comme deux unités facturables. C’est un détail qui change vite la note quand on multiplie les règles automatiques ou les traitements en cascade.

Google Cloud indique que le premier millier d’unités mensuelles est gratuit sur plusieurs fonctions, puis que les tarifs deviennent dégressifs selon le volume. Les prix ci-dessous sont exprimés en dollars US, ce qui reste la référence la plus claire pour calculer un budget d’intégration.

• PDF multipage: chaque page est traitée comme une image distincte.
• Taille des fichiers: au-delà de 20 MB, le fichier est rejeté.
• Taille du JSON: la requête ne doit pas dépasser 10 MB si vous l’envoyez en base64 dans le corps JSON.
• OCR: au-delà de 75 millions de pixels, l’image est redimensionnée par le service.
• Qualité: une compression trop forte dégrade la précision, surtout sur les petits caractères.

Je recommande aussi d’ajuster la résolution selon la fonction. En pratique, 640x480 sert bien pour beaucoup de cas généraux; l’OCR gagne souvent à monter vers 1024x768; la détection de visages a besoin d’images plus grandes, autour de 1600x1200, parce que les détails comptent davantage. Et si vous traitez des GIF animés, n’oubliez pas que seule la première image est prise en compte. C’est un point discret, mais il évite de mauvais diagnostics.

Quand je le choisis plutôt qu’un autre service Google Cloud

Quand je dois choisir entre plusieurs services Google Cloud, je raisonne d’abord par type de signal attendu, pas par marque. La Vision API est la plus rapide à mettre en place pour des images simples; dès que le document devient structuré ou que le média change, je change aussi d’outil.

Je le résume simplement: je garde la Vision API quand j’ai besoin d’un signal visuel rapide, générique et peu coûteux à intégrer. Je passe à autre chose dès que la structure, le contexte métier ou le volume de décision exigent plus qu’un simple annotateur d’images. C’est cette lucidité qui fait la différence entre un prototype utile et un outil que l’équipe conserve réellement.

Ce que je ferais avant de le passer en production

Avant d’exposer le service à des utilisateurs, je vérifie trois choses: la qualité du corpus réel, le comportement sur les cas ambigus et la stratégie d’escalade humaine. Un bon déploiement ne cherche pas une précision parfaite; il cherche un seuil de confiance suffisant, des coûts prévisibles et un échec propre quand l’image est mauvaise ou la décision sensible.

• Je teste sur des images réelles, pas seulement sur des exemples propres.
• Je définis un seuil de confiance et une revue manuelle pour les cas limites.
• Je journalise les métadonnées utiles, mais j’évite de stocker des images sensibles plus longtemps que nécessaire.
• J’utilise un compte de service et des permissions minimales.
• Je surveille les fonctionnalités retirées et les évolutions de tarification avant chaque mise à jour majeure.

Au fond, c’est un bon service d’entrée pour industrialiser une première couche de lecture d’image. Je le recommande quand il faut aller vite, rester sobre dans l’architecture et garder la porte ouverte à un moteur plus spécialisé si l’usage métier devient plus exigeant.