Analyser un rendu architectural avec l’API Gemini, étape par étape

Ce que vous apprendrez dans ce tutoriel

Ce guide présente le processus de base pour envoyer un rendu architectural à l’API Gemini avec l’image et demander au modèle de l’examiner selon des critères précis. Il ne s’agit pas de faire valider automatiquement une image, mais de décrire les éléments visibles, de classer certaines caractéristiques ou de poser des questions sur le rendu. La documentation de Google indique que les modèles Gemini peuvent effectuer des tâches multimodales telles que la description et la classification d’images, ainsi que les réponses à des questions visuelles.

En architecture et en visualisation, cette approche peut aider à décrire les éléments visibles dans une scène, à vérifier les caractéristiques marquantes d’un visuel de présentation ou à amorcer une discussion autour d’un rendu. La réponse du modèle ne remplace ni une décision de conception ni une vérification technique. Considérez-la comme une évaluation d’appoint fondée sur l’image et confrontez-la aux informations du projet.

Prérequis

Ce flux de travail nécessite un accès à l’API Gemini, une image et une consigne d’analyse claire pour cette image. Le document source comprend des exemples en Python, JavaScript, Java, Go et REST. Les exemples indiquent gemini-3.8-flash comme identifiant de modèle ; aucune version précise du SDK ni information tarifaire n’étant fournie, aucune hypothèse n’est faite à ce sujet ici.

Vous pouvez fournir l’image de trois façons :

• URL publique : la documentation présente l’URL comme une option adaptée aux images accessibles publiquement.

• Base64 intégré à la requête : les données de l’image sont ajoutées à la requête avec le texte. La taille totale de la requête ne doit pas dépasser 20 MB, y compris les consignes textuelles, les instructions système et les données de l’image.

• Files API : pour les fichiers volumineux ou les images destinées à être réutilisées dans plusieurs requêtes, téléversez le fichier puis ajoutez l’URI renvoyée à la requête, accompagnée du type MIME.

L’exemple de la source, sous la rubrique consacrée aux URL, utilise également l’URI d’un fichier téléversé via la Files API. Vérifiez donc que le mode d’envoi choisi dans votre application correspond aux exemples les plus récents de la documentation de l’API. Pour les images intégrées dont la taille approche la limite, envisagez l’option Files API recommandée dans la documentation.

Analyser un rendu architectural étape par étape

1. Définissez l’objectif de l’analyse. Commencez par décider quelle question poser à propos du rendu. Plutôt qu’une consigne générale comme « analyse cette image », choisissez un sujet précis, par exemple les éléments visibles de l’espace, l’impression produite par l’éclairage ou la composition. N’attendez pas du modèle qu’il déduise des informations sur le projet qui ne figurent pas dans l’image.

2. Transmettez l’image par la méthode appropriée. Si le rendu est accessible à une adresse publique, envisagez l’option URL. Pour les petits fichiers, vous pouvez intégrer des données Base64 ; dans ce cas, la taille totale de la requête doit rester sous la limite de 20 MB. Si le fichier est volumineux ou si vous comptez réutiliser la même image, téléversez-la avec la Files API et ajoutez son URI et son type MIME à la requête. Quel que soit le mode choisi, veillez à ce que la consigne textuelle et l’image servent le même objectif d’analyse.

3. Formulez une consigne claire et précise. Le guide de Google sur la conception des requêtes recommande des instructions claires et précises et, si nécessaire, une description du format de réponse attendu. L’exemple original ci-dessous demande uniquement la liste des éléments visibles dans un rendu d’intérieur :

Bu iç mekân render’ını incele. Yalnızca görüntüde açıkça seçilebilen mekân öğelerini listele: duvar, döşeme, mobilya, aydınlatma ve açıklıklar. Görselde olmayan bilgileri tahmin etme. Emin olmadığın noktaları “belirsiz” olarak belirt. Yanıtı kısa maddeler hâlinde ver.

Cette consigne délimite le champ de l’analyse et précise explicitement qu’il ne faut pas inventer d’informations invisibles. Comparez également la réponse à l’image et aux documents du projet.

1. Demandez au modèle de classer une caractéristique visible. Définir les options à l’avance permet de clarifier la portée de la demande de classification. L’exemple ci-dessous étiquette l’impression produite par l’éclairage ; il ne demande pas une mesure physique de l’éclairement :

Görseldeki aydınlatma izlenimini şu seçeneklerden biriyle sınıflandır: doğal ışık baskın, yapay ışık baskın, dengeli veya belirsiz. Seçimini destekleyen, görüntüde görülebilen iki ipucu yaz. Ölçüm değeri verme.

Cette classification peut faciliter la prise de notes selon les mêmes critères pour plusieurs images. Elle ne signifie toutefois pas que les calculs d’éclairage ou les paramètres de rendu ont été vérifiés.

1. Posez une question précise sur l’image. Dans un flux de questions-réponses visuelles, il est utile de limiter la réponse aux éléments observables. Vous pouvez, par exemple, demander au modèle de décrire la zone qui ressort dans la composition :

Bu mimari görselde izleyicinin dikkatini ilk çekmesi muhtemel alanı tarif et. Görüntüdeki konumunu ve bu yorumu destekleyen görünür kompozisyon öğelerini belirt. Tasarım niyeti hakkında çıkarım yapma.

L’interprétation du modèle ne mesure pas la réaction réelle des spectateurs. Ne présentez donc pas la réponse comme le résultat d’une étude auprès d’utilisateurs ni comme une évaluation définitive de la conception.

1. Précisez le format de réponse et vérifiez le résultat. Dans votre consigne, vous pouvez demander un court paragraphe, une liste à puces ou des rubriques précises. Le guide souligne que les exemples peuvent également orienter la forme de la réponse et que la conception des requêtes repose sur un processus d’essais et d’améliorations. Si la première réponse reste trop générale, resserrez la consigne ; demandez, par exemple, de lister uniquement les matériaux visibles plutôt que de donner un avis général.

Erreurs fréquentes

• Donner une consigne vague : « Évalue le rendu » définit une tâche trop large. Précisez la caractéristique à examiner et le format de réponse souhaité.

• Attendre des données techniques précises à partir de l’image : une description ou une classification ne constitue ni un rapport de mesure ni une validation du modèle du projet.

• Poser des questions sur des éléments invisibles : n’attendez pas de réponse certaine sur la marque d’un matériau, une dimension ou un système constructif absent de l’image. Demandez explicitement au modèle de signaler les incertitudes.

• Ne pas choisir le mode d’envoi en fonction du besoin : les données intégrées sont soumises à une limite totale de 20 MB par requête. Pour les images volumineuses ou à réutiliser, tenez compte de la recommandation de la documentation concernant la Files API.

• Partager la réponse sans la vérifier : comparez les descriptions générées à l’image ; ne reprenez pas directement les interprétations non étayées dans une présentation ou les notes du projet.

Effets sur le flux de travail en architecture et en visualisation

Cette méthode peut aider les agences d’architecture, les architectes d’intérieur et les équipes de visualisation à décrire des rendus et à organiser leurs premières notes de vérification. Les équipes qui souhaitent réutiliser les mêmes critères peuvent standardiser leurs consignes. Le choix entre l’URL, Base64 et la Files API dépend de l’accessibilité de l’image, de sa taille et du besoin de la réutiliser.

L’utilisation de l’API ne remplace pas les logiciels de rendu existants ; les sources ne donnent aucune information sur les exigences matérielles ni sur la compatibilité avec les logiciels de visualisation. Avant de déployer cette solution, les équipes doivent également examiner les modalités d’accès à l’API et les coûts qui ne sont pas précisés. Les réponses du modèle ne doivent pas être le seul fondement des décisions de conception ou techniques ; elles doivent être vérifiées à partir de l’image et des données du projet.

Étapes suivantes

Pour votre premier essai, utilisez un seul rendu et une seule question cible. Essayez ensuite plusieurs consignes précises sur la même image pour voir comment les réponses évoluent. Lors de la comparaison de plusieurs images, demander les mêmes critères et le même format de réponse peut faciliter l’organisation des résultats ; veillez toutefois à limiter la comparaison aux informations visibles dans les images.

Pour des tâches plus spécialisées, comme la détection d’objets dans une image ou la segmentation de régions, la documentation indique qu’un entraînement complémentaire peut améliorer la précision dans certains cas d’usage. Cela ne signifie pas que les mêmes performances seront atteintes pour toutes les images architecturales. Si votre besoin dépasse la simple description ou les questions-réponses, vérifiez séparément la méthode utilisée et les résultats obtenus.

Sources et licence

Ce tutoriel est une adaptation en turc de la documentation de Google sur la compréhension des images avec l’API Gemini et la conception des requêtes. Les deux sources sont sous licence CC BY 4.0. Les consignes portant sur les rendus architecturaux présentées ici ont été rédigées spécialement et ne sont pas copiées des exemples des sources.