Estimation de Prix par IA à partir d'Images : 3 Tentatives, 1 Solution Fonctionnelle

Pourquoi dit-on que l'IA ne peut pas mesurer à partir de photos ?

En 2024, des chercheurs de Google ont publié SpatialVLM — un benchmark testant la capacité des modèles de vision-langage à comprendre les relations spatiales. Les résultats furent édifiants : lorsqu'on leur demandait d'estimer des distances et des dimensions à partir de photos, les modèles de pointe se situaient dans la bonne fourchette (0,5× à 2× de la réalité) seulement 37,2% du temps. Près des deux tiers des estimations étaient erronées de plus du double.

Une étude de suivi, SpatiaLab (2026), a confirmé que le problème est profond — les benchmarks précédents surestimaient en fait la capacité de ces modèles à percevoir l'espace. Les chiffres réels sont pires.

Le problème fondamental est appelé ambiguïté monoculaire : à partir d'une seule image 2D sans point de référence, il est physiquement impossible de récupérer des dimensions 3D absolues. Un pot de 30cm photographié de près ressemble à une jardinière de 3m prise de loin. Aucune quantité de données d'entraînement ne change cela — ce n'est pas une limitation de l'IA, c'est de la géométrie.

Et les images générées par l'IA rendent la tâche encore plus difficile. Les vraies photos contiennent au moins des métadonnées EXIF (longueur focale, taille du capteur) qui pourraient théoriquement ancrer les calculs de perspective. Les images générées n'en ont aucune.

Fait intéressant, la recherche a également révélé où se situait réellement le goulot d'étranglement : le problème de transfert vision-langage. L'encodeur visuel représente correctement l'information spatiale en interne — mais le modèle de langage ne peut pas l'extraire lors de la génération de réponses textuelles. Le modèle « voit » les dimensions plus précisément qu'il ne peut les « dire ».

Ainsi, lorsque nous avons décidé de créer des estimations de prix automatiques pour des designs de jardin générés par l'IA, le consensus académique était clair : ne pas mesurer. Classifier.

Voici ce que fait l'industrie à la place :

Personne dans le domaine de la conception de jardins par IA (marché de 1,72 milliard de dollars, croissance de 21,4% TCAC) n'offre d'estimations de prix à partir de designs générés. Pas un seul concurrent. Nous avons décidé d'essayer quand même.

Comment notre IA génère des designs de jardin (et pourquoi cela rend la tarification difficile)

Avant de nous plonger dans la tarification, il est utile de comprendre ce que nous évaluons. Notre Concepteur de Jardin AI permet aux utilisateurs de télécharger une photo de leur jardin réel. L'IA génère ensuite une visualisation photoréaliste de l'aspect que cet espace pourrait avoir avec des bacs potagers surélevés modulaires.

Le générateur d'images (Gemini Imagen) reçoit deux types d'entrées :

• Contraintes produit : Trois photos de référence de notre système Brick réel — de vraies photos de produits montrant la construction en planches empilées, les coins en bois empilé, la texture du mélèze vieilli. Plus une description textuelle détaillée : « planches épaisses (120mm de haut × 60mm d'épaisseur), empilées horizontalement avec des joints décalés rangée par rangée comme de la maçonnerie. »
• Liberté créative : Tout le reste — combien de structures, où elles vont, quelles formes elles prennent, comment elles se rapportent au jardin existant. L'IA décide de l'agencement, de la disposition, des types de bacs potagers surélevés. Une forme en L enveloppant un arbre ? Un banc intégré dans un mur de soutènement ? Un ensemble d'escaliers suivant une pente ? Tout dépend du modèle.

Les utilisateurs contrôlent un curseur de densité (0-100) qui correspond à environ 0-20 structures. À une densité de 25, vous obtenez un jardin naturaliste avec quelques bacs potagers surélevés subtils nichés parmi les fleurs sauvages. À une densité de 80, vous obtenez un espace de vie extérieur entièrement organisé avec des zones distinctes reliées par des chemins. L'IA choisit les types de structures qui ont du sens pour la scène.

Cette liberté créative est tout l'intérêt de l'outil. Personne ne veut d'un configurateur qui produit les mêmes trois bacs potagers surélevés rectangulaires à chaque fois. Mais cela crée un problème de tarification fondamental : chaque image générée est unique. Il n'y a pas de nomenclature prédéfinie. Pas de liste de SKU. Juste une image photoréaliste de structures en bois qui pourraient être n'importe quoi, d'une simple jardinière à un jardin multi-zones élaboré.

Alors, comment évaluer le prix de quelque chose qui n'existe pas encore, à partir d'une image qui a été générée il y a 5 secondes ?

Tentative n°1 : Demander simplement les dimensions à l'IA

Notre première approche fut la plus naïve : donner à Gemini 2.5 Pro l'image de jardin générée et lui demander d'estimer les dimensions en mètres.

// Le prompt que nous avons mis en production
Vous êtes un expert en estimation des dimensions des structures de jardin
à partir de photographies.

Pour CHAQUE structure en bois distincte que vous pouvez identifier
(bacs potagers surélevés, bancs, murs, escaliers, jardinières),
estimez ses dimensions en mètres :
- length_m: la plus longue dimension horizontale
- width_m: la plus courte dimension horizontale (profondeur)
- height_m: la dimension verticale

Retournez JSON :
{ "structures": [
    { "type": "raised_bed",
      "length_m": 2.0, "width_m": 1.0, "height_m": 0.6 }
]}

La tarification était une géométrie simple — calculer la surface visible du mur et multiplier par 125 €/m² :

// Calcul de la surface du mur par type de structure :
// raised_bed: 2 × (length + width) × height
// wall: 2 × length × height
// stairs: length × height × 1.5
const wallArea = 2 * (s.length_m + s.width_m) * s.height_m;
const price = wallArea * 125; // EUR par m²

Cela a fonctionné. Mieux que prévu. Un bac potager surélevé qui mesurait en réalité 1,8m de long revenait à 1,4m ou 2,2m — les dimensions individuelles étaient imprécises, mais la géométrie compensait : lorsque la longueur était surestimée, la hauteur avait tendance à être sous-estimée. L'estimation de prix se situait finalement à ±20-25% de la réalité. Pour une estimation gratuite et instantanée à partir d'une image générée par l'IA, cela semblait étonnamment utile.

Le modèle était particulièrement efficace pour compter les structures — si l'image montrait 3 bacs potagers surélevés et un banc, il trouvait généralement 3 bacs potagers surélevés et un banc. Il comprenait à quoi ressemblait notre système Brick. Les dimensions étaient floues, mais la détection des structures était solide.

Mais ensuite, nous avons lu les études. Le taux de précision de 37,2% de SpatialVLM. La propre documentation de Google mettant en garde contre la mesure spatiale à partir d'images uniques. Les fils de discussion Stack Overflow remplis de « c'est fondamentalement impossible ». Nous avons eu peur.

« Cela ne peut pas fonctionner à long terme », nous sommes-nous dit. « Nous avons juste de la chance. Faisons-le correctement — comme tout le monde le recommande. »

Tentative n°2 : La « bonne » méthode — Classification par catalogue

L'approche recommandée est claire : ne pas mesurer, classifier. Identifier le type de structure, l'assigner à une catégorie de taille, rechercher un prix fixe. Pas de mesure, pas d'ambiguïté. C'est ce que fait Zillow. C'est ce que fait SimplyWise. C'est ce que la recherche recommande de faire.

L'idée était simple :

// Classer le type et la taille de la structure → recherche de prix fixe
const PRICE_TABLE = {
  raised_bed: { small: 50, medium: 100, large: 180 },
  wall:       { small: 25, medium: 50,  large: 90 },
  bench:      { small: 30, medium: 60,  large: 100 },
  stairs:     { small: 45, medium: 90,  large: 140 },
  planter:    { small: 15, medium: 30,  large: 55 }
};

Mais nous avons rencontré un problème que nous n'avions pas anticipé — et cela n'avait rien à voir avec la précision de l'IA.

Notre concepteur de jardin AI génère des designs créatifs. Un utilisateur télécharge une photo de son jardin, et Gemini Imagen crée une visualisation unique avec des bacs potagers surélevés modulaires agencés pour s'adapter à cet espace spécifique. Les structures qu'il génère sont variées — formes en L, courbes qui suivent un chemin de jardin, bacs potagers surélevés intégrés dans des pentes, bancs connectés à des bacs potagers surélevés, arrangements étagés qui brouillent la ligne entre « escaliers » et « mur ».

Pour que la classification par catalogue fonctionne, nous aurions dû contraindre le générateur d'images. « Ne générez que ces 5 types. Ne générez que ces 3 tailles. Gardez tout rectangulaire. » Cela aurait rendu la tarification précise — mais cela aurait tué ce qui rend l'outil précieux : les designs créatifs et personnalisés.

Nous étions confrontés à un compromis fondamental : précision de la tarification vs. liberté créative dans les images générées.

Et même lorsque nous avons essayé de faire fonctionner la classification sans contraindre le générateur, les résultats étaient médiocres :

• « Petit/Moyen/Grand » ne signifiait rien pour le modèle. Sans objet de référence dans l'image, le même bac potager surélevé était « petit » dans une analyse et « grand » dans la suivante. Il n'y a pas d'ancrage physique pour ces mots — « moyen » est un concept linguistique, pas une mesure.
• Les structures créatives ne rentrent pas dans des catégories nettes. Un bac potager surélevé en forme de L est-il un « grand » bac potager surélevé ou deux « moyens » ? Un banc intégré dans un bac potager surélevé est-il un « banc » ou une partie du bac potager surélevé ? Les catégories étaient trop rigides pour ce que le générateur produisait réellement.
• Nous nous sommes retrouvés à ajouter des astuces. Une remise pour surcomptage (-15% pour chaque structure au-delà de 3, car le modèle hallucinait des extras). Une étape de reclassification. Une table de remplacement manuel. Chaque astuce était un signe que l'approche ne correspondait pas à notre cas d'utilisation.

Le problème principal : la tarification par catalogue suppose un catalogue. Cela fonctionne pour Zillow car les maisons ont des types connus (ranch, colonial, à niveaux décalés) avec des décennies de données de ventes comparables. Cela fonctionne pour SimplyWise car les projets de construction correspondent à des catégories standardisées. Notre IA génère des designs uniques à chaque fois — il n'y a pas de catalogue contre lequel classifier.

Nous n'avons jamais mis cette version en production. Au lieu de cela, nous sommes revenus à ce qui fonctionnait réellement — la mesure — mais avec une perspicacité cruciale.

Tentative n°3 : Faire du produit la règle

La recherche avait raison sur un point : vous ne pouvez pas récupérer des dimensions absolues à partir d'une seule image sans point de référence. Mais elle avait tort sur une hypothèse — qu'aucun point de référence n'existe.

Notre produit intègre une règle.

Le système modulaire Brick utilise des planches de bois de 60mm d'épaisseur qui s'empilent les unes sur les autres. Chaque couche horizontale — visible comme une ligne distincte dans chaque image générée — mesure exactement 12cm (0,12m) de haut. C'est une constante physique du produit. C'est la même chose dans chaque image, chaque design, chaque angle. Et le générateur d'images le sait déjà — chaque prompt spécifie « système Brick de 60mm », donc les planches sont rendues de manière cohérente.

Avec la V1, nous avions demandé : « Combien de mètres de long fait ce bac potager surélevé ? » — une question qui nécessite de résoudre le problème de l'ambiguïté monoculaire.

Avec la V3, nous demandons : « Combien de couches de planches voyez-vous, et combien de fois le mur est-il plus long que sa hauteur ? » — des questions qui ne nécessitent que le comptage et l'estimation d'une proportion. Ce sont deux choses que les modèles de vision font bien.

// Le prompt actuel en production (v3)
RÉFÉRENCE D'ÉCHELLE : Chaque couche de planche horizontale = exactement 12cm
(0,12m) de haut. Comptez les couches pour obtenir la hauteur, puis estimez
la longueur par rapport à la hauteur connue.

MESUREZ chaque structure :
- layers: comptez les couches de planches horizontales visibles (chaque = 12cm)
- length_ratio: combien de fois le mur est-il plus long que sa hauteur
- visible_faces: combien de faces de mur sont visibles

VÉRIFIEZ : Les jardins typiques ont 2 à 5 structures.
Si vous en avez trouvé >6, vous avez probablement surcompté.

Retournez JSON :
{"structures": [
  {"reasoning": "4 couches horizontales visibles, le mur s'étend
    environ 3,5x la hauteur, face avant et latérale visibles",
   "type": "raised_bed",
   "layers": 4,
   "length_ratio": 3.5,
   "visible_faces": 2}
]}

Le moteur de tarification effectue l'arithmétique :

const LAYER_HEIGHT_M = 0.12;
const PRICE_PER_M2 = 120;

function calculatePrice(structure) {
  const height = structure.layers * LAYER_HEIGHT_M;
  // 4 couches = 0,48m

  const length = height * structure.length_ratio;
  // 0,48m × 3,5 = 1,68m

  const faceArea = height * length;
  // 0,48 × 1,68 = 0,81 m²

  const totalM2 = faceArea * structure.visible_faces;
  // 2 faces = 1,61 m²

  return totalM2 * PRICE_PER_M2;
  // 1,61 × 120 € = 193 €
}

Pourquoi cela fonctionne là où les V1 et V2 ont échoué :

• Compter est ce que les modèles de vision font bien. Les lignes horizontales dans les structures de planches empilées sont des caractéristiques visuelles répétitives à contraste élevé. Compter des couches discrètes est fondamentalement différent d'estimer « combien de mètres » — c'est de la reconnaissance de formes, pas du raisonnement spatial.
• Les ratios sont plus faciles que les absolus. « Ce mur est environ 3,5 fois plus long que haut » est un jugement de proportion visuelle. Le modèle n'a pas besoin de connaître la taille absolue — juste la forme. Cela contourne entièrement l'ambiguïté monoculaire.
• La référence d'échelle est réelle. 12cm par couche n'est pas une supposition — c'est une spécification de fabrication intégrée à la fois au produit physique et au prompt de génération d'images. L'IA « connaît » l'épaisseur des planches car elle a généré l'image avec cette contrainte.
• La liberté créative est préservée. Contrairement à l'approche par catalogue de la V2, nous ne contraignons pas les structures que le générateur peut créer. Formes en L, courbes, bancs intégrés — tout est permis. L'approche de comptage des couches fonctionne sur n'importe quelle forme car elle mesure la surface visible du mur, et non des catégories prédéfinies.
• L'IA observe, le code calcule. Nous avons séparé la tâche en ce que l'IA fait bien (reconnaissance de motifs visuels) et ce que le code fait bien (arithmétique). Ni l'un ni l'autre ne fait le travail de l'autre. Le champ reasoning force le modèle à décrire ce qu'il voit avant de donner des chiffres, ce qui révèle les mauvaises estimations dans les logs et maintient les sorties ancrées.

Ce qui a changé entre les approches

La fourchette de prix asymétrique de la V3 mérite une note. Nous privilégions délibérément la sous-estimation : -20% à l'extrémité inférieure, +10% à l'extrémité supérieure. Nous préférons citer 160 €-210 € et que le prix réel soit de 190 € plutôt que de citer 190 €-250 € et d'effrayer quelqu'un avant même qu'il ne demande. Sous-promettre et sur-livrer est mieux que l'inverse.

De l'image générée à l'estimation de prix en 5 secondes

Voici ce qui se passe après qu'un utilisateur a généré un design de jardin :

Pour les utilisateurs enregistrés, l'estimation de prix se déclenche automatiquement — aucun clic sur un bouton n'est nécessaire. L'image générée est redimensionnée à 1024px et envoyée à un deuxième modèle d'IA (Gemini 2.5 Flash, configuré pour l'analyse visuelle à une température de 0,2 pour un comptage déterministe). Il s'agit d'un appel de modèle différent de celui qui a généré l'image — le générateur crée, l'analyseur mesure.

L'analyseur renvoie un JSON avec son raisonnement pour chaque structure : « 4 couches horizontales visibles, le mur s'étend environ 3,5× la hauteur, face avant et latérale visibles. » Notre code multiplie les couches par 0,12m, applique le ratio, calcule les m², et additionne le tout.

Le résultat apparaît directement sous l'image générée — un panneau vert avec un tableau de ventilation par structure. Chaque ligne affiche : type de structure, dimensions (hauteur × longueur), faces visibles, surface du mur en m², et prix estimé. Le total affiche X.XX m² × 120 €/m² avec la fourchette de prix en grand texte. Pas de boîte noire — les utilisateurs peuvent voir exactement comment l'estimation a été calculée et juger par eux-mêmes si le nombre de couches semble correct.

Simultanément, un e-mail arrive avec la même ventilation plus l'image du jardin. Si l'utilisateur ne répond pas dans les 3 jours, un seul rappel suit : « Vous pensez toujours à votre jardin ? » avec un bouton en un clic pour demander un devis exact à un humain. Toute la chaîne — de la génération d'images à l'estimation de prix en passant par l'e-mail — coûte moins de 0,01 $.

L'économie : 0,135 $ par image, 0,001 $ par devis

Construire un outil alimenté par l'IA est une chose. Le rendre économiquement durable en est une autre. Voici à quoi ressemblent réellement les chiffres.

La génération d'images coûte 0,134 $ par image. Nous utilisons le modèle d'image Pro de Gemini — le niveau le plus cher. Nous avons essayé le modèle Flash moins cher au début. La qualité de sortie n'était pas suffisante : les textures semblaient plates, le grain du bois était incohérent, les proportions des planches Brick variaient. Pour un outil où la qualité visuelle est le produit, économiser 60% sur le coût de génération tout en produisant des images qui ne semblent pas convaincantes n'était pas un compromis qui valait la peine d'être fait. Pro uniquement, pas de solution de repli.

L'estimation de prix coûte 0,001 $ par devis. Ici, le calcul est inversé — nous utilisons Gemini 2.5 Flash pour l'analyse visuelle. Le comptage des couches de planches et l'estimation des proportions ne nécessitent pas le même modèle qui génère des images photoréalistes. Flash gère les tâches de comptage de manière fiable à une fraction du coût. Choisir le bon modèle pour chaque tâche — Pro là où la qualité compte, Flash là où la précision d'une tâche étroite spécifique compte — est la différence entre un produit durable et un produit non durable.

Une session utilisateur typique ressemble à ceci :

Chaque utilisateur bénéficie de 2 générations gratuites sans inscription. Fournir une adresse e-mail en débloque 3 de plus (5 au total par jour). Au-delà, les utilisateurs achètent des packs de crédits — 3 images pour 1 € jusqu'à 50 pour 10 €. À 0,134 $ par génération, les marges s'élèvent à environ 40-60% selon la taille du pack.

L'estimation de prix elle-même est toujours gratuite — à 0,001 $ par devis, la bloquer derrière un paywall coûterait plus en engagement perdu que ce qu'elle économiserait en frais d'API. Et le calcul de prix (couches × 0,12m × ratio × faces × 120 €/m²) s'exécute entièrement dans notre code sans aucun appel API. Une fois que Gemini Flash renvoie le nombre de couches, tout le reste est une arithmétique déterministe.

Nous optimisons également les coûts d'entrée à chaque étape. Les photos téléchargées par l'utilisateur sont prétraitées avec Sharp — redimensionnées à un maximum de 2048px et dépouillées des données EXIF avant d'atteindre l'API. Pour l'analyse des devis, l'image générée est compressée davantage à 1024px JPEG. Trois photos de produits de référence sont mises en cache localement et servies à partir du disque au lieu d'être récupérées du CDN à chaque requête. Le prompt de génération est maintenu en dessous de 150 mots — au-dessus de 200, le modèle d'image commence à ignorer des parties de l'instruction.

Le modèle économique : Nous perdons de l'argent sur la génération. C'est le but.

Soyons honnêtes sur l'économie. La plupart des utilisateurs génèrent 2 à 5 images en utilisant leur allocation gratuite et n'achètent jamais de pack de crédits. Les quelques-uns qui achètent des crédits ne couvrent pas la totalité des coûts d'API pour tous les utilisateurs. Sur les revenus de génération pure, nous opérons à perte.

C'est intentionnel. Le Concepteur de Jardin AI n'est pas un produit — c'est un entonnoir.

Voici ce que nous obtenons réellement d'un utilisateur qui génère un design de jardin et entre son e-mail :

• Un prospect qualifié avec intention d'achat. Quelqu'un qui télécharge une photo de son jardin, génère un design avec des bacs potagers surélevés et examine une estimation de prix n'est pas un simple curieux. Il envisage activement un projet de jardin. C'est qualitativement différent de quelqu'un qui a cliqué sur une publicité.
• Un ancrage de prix personnalisé. L'utilisateur a maintenant un chiffre spécifique en tête — « mon jardin coûterait environ 350 € ». C'est bien plus efficace qu'une page produit générique listant les prix des planches à l'unité.
• Un visuel dont ils sont déjà tombés amoureux. Ils ont généré le design eux-mêmes. Ils ont choisi la densité, le style, l'agencement. Il y a une appropriation dans cette image qu'aucune photo de catalogue ne peut égaler.

La séquence d'e-mails renforce cela. Immédiatement après avoir généré un design, l'utilisateur reçoit un e-mail de devis avec l'image de son jardin intégrée — le design spécifique qu'il a créé, pas une photo de stock. L'e-mail comprend une ventilation par structure (type, surface du mur, prix estimé) et un bouton bien visible pour demander un devis exact à un humain.

S'ils ne répondent pas dans les trois jours, un seul rappel arrive : « Vous pensez toujours à votre jardin ? » — même image, même fourchette de prix, même bouton en un clic. Un seul rappel, pas une campagne de goutte à goutte. Nous voulons être utiles, pas ennuyeux.

Sous le design généré sur le site web, il y a toujours deux CTA : un lien vers le Configurateur 3D où ils peuvent spécifier les dimensions exactes, et un lien pour parcourir la boutique en ligne. Le parcours de « Je me demande à quoi mon jardin pourrait ressembler » à « Je configure ma commande » peut se faire en une seule session.

Sur la confidentialité : la soumission d'e-mails est toujours accompagnée d'un lien vers notre politique de confidentialité et d'une note claire indiquant que les utilisateurs peuvent se désabonner à tout moment. L'e-mail de devis est transactionnel — l'utilisateur a explicitement demandé une estimation de prix. Les e-mails marketing (newsletter) nécessitent une case à cocher d'opt-in explicite séparée. Nous ne stockons que ce qui est nécessaire : e-mail, locale, l'image du design et la ventilation des prix. La conformité au RGPD n'est pas seulement une exigence légale — c'est la seule façon d'établir la confiance avec les personnes qui vous donnent leurs coordonnées ainsi qu'une photo de leur maison.

La grande leçon : Demandez à l'IA d'observer, pas de répondre

L'erreur de la V1 n'était pas d'utiliser l'IA pour des tâches spatiales — c'était de demander au modèle de produire la réponse finale directement. « Combien de mètres de long fait ceci ? » exige du modèle qu'il résolve l'ambiguïté monoculaire, convertisse les caractéristiques visuelles en unités physiques et produise un nombre calibré. Ce sont trois problèmes difficiles empilés.

La V3 le décompose en morceaux. « Combien de couches horizontales ? » est une tâche de comptage — l'une des choses les plus fiables que les modèles de vision font. « Combien de fois plus long que haut ? » est une estimation de proportion — également fiable, car les ratios sont invariants à l'échelle. La conversion des couches en mètres, et des ratios en dimensions absolues, est un code déterministe avec une constante physique connue.

Le même principe s'applique au-delà de notre cas d'utilisation :

• Ne demandez pas « quelle est la hauteur de ce bâtiment ? » — demandez « combien d'étages ? » et multipliez par la hauteur d'étage standard.
• Ne demandez pas « quelle est la largeur de cette pièce ? » — demandez « combien de carreaux en travers ? » et multipliez par la taille du carreau.
• Ne demandez pas « quelle est la longueur de cette clôture ? » — demandez « combien de poteaux ? » et multipliez par l'espacement standard.

Si votre produit ou scène contient un élément répété, visible et dimensionnellement cohérent, vous avez déjà une règle. Vous n'avez pas besoin que l'IA mesure — vous avez juste besoin qu'elle compte.

Essayez par vous-même

Téléchargez une photo de votre jardin, laissez l'IA le concevoir avec des bacs potagers surélevés modulaires, et obtenez une estimation de prix instantanée. L'ensemble du processus prend environ 30 secondes. Le design et l'estimation de prix sont gratuits.

Foire aux questions

Quelle est la précision des estimations de prix générées par l'IA à partir d'images de jardin ?

Notre système atteint une précision d'environ ±20%, avec une fourchette asymétrique intentionnellement conservatrice (-20%/+10%). Cela signifie que les estimations ont tendance à être légèrement inférieures au prix réel plutôt que supérieures — nous préférons sous-promettre que de surestimer.

Quel modèle d'IA est utilisé pour l'estimation de prix ?

Nous utilisons Gemini 2.5 Flash de Google pour l'analyse visuelle. Chaque estimation coûte environ 0,001 $ (un dixième de centime). Nous sommes passés du plus coûteux Gemini 2.5 Pro après avoir constaté que Flash est comparable pour notre cas d'utilisation spécifique de comptage des couches structurelles.

L'IA peut-elle réellement mesurer des dimensions à partir d'une seule photo ?

Pas directement — la recherche montre que les modèles de vision AI se trompent sur les mesures absolues 63% du temps. Notre approche contourne ce problème en utilisant la structure propre du produit (couches de planches de 12cm) comme référence d'échelle intégrée. L'IA compte les couches et estime les proportions, puis notre code fait le calcul.

Pourquoi ne pas utiliser GPT-4 Vision au lieu de Gemini ?

Gemini Flash est environ 4 fois moins cher avec des performances de raisonnement spatial comparables pour notre cas d'utilisation spécifique. Puisque nous effectuons un appel API par estimation, le coût par appel est important — à 0,001 $ chacun, nous pouvons offrir des estimations gratuites illimitées.

Cette approche peut-elle fonctionner pour d'autres produits ?

Oui — si votre produit possède une caractéristique connue, visible et dimensionnellement cohérente qui apparaît dans les images. Les rangées de briques en maçonnerie, les carreaux de sol, les largeurs de bois standard, les parpaings — tout élément ayant une dimension réelle fixe que l'IA peut compter peut servir de référence d'échelle.

L'estimation de prix est-elle un devis contraignant ?

Non, c'est une estimation indicative pour vous aider à planifier. Vous pouvez demander un devis exact en un clic — un humain examine le design et fournit un prix précis dans les 24 heures.