Jev analyse désormais les photos : du contrôle des retours au repérage des dégâts

Schéma explicatif original : une photo en entrée, des jugements distincts et des coordonnées en sortie, puis une personne qui examine les dégâts proposés. Il illustre un workflow et non un résultat effectivement produit par le modèle.

Un client photographie un mug ébréché. Votre outil d’assistance doit répondre à trois questions distinctes : le mug est-il visible, la photo montre-t-elle des dégâts et où le réviseur doit-il regarder ? Un paragraphe bien tourné sur la céramique n’est pas le résultat intermédiaire le plus utile.

Le 14 octobre 2026, TypeSafe AI a annoncé la prise en charge expérimentale des images dans Jev, en même temps que Jev 1.14.0 et un nouveau type de sortie box. Les images sont compatibles avec Jev 1.13 et 1.14 ; Box nécessite la version 1.14. TypeSafe qualifie explicitement ces fonctionnalités d’expérimentales et ne les recommande pas pour l’automatisation en production. Annonce officielle

Le changement utile est plus limité que celui d’un assistant multimodal généraliste : une photo peut devenir une décision typée ou un emplacement exploitable dans un programme. Voyons ce que cela change pour un workflow de retour, les formats acceptés par l’interface et la manière de bâtir un prototype prudent sans prendre un rectangle pour une preuve.

En bref :

• Jev propose désormais une fonction expérimentale de compréhension des images fixes, pas de génération d’images.
• Vérifiez la présence de la cible avant de vous fier à l’emplacement proposé.
• Conservez la photo originale et la vérification humaine ; laissez le code valider les coordonnées, les autorisations et les conséquences.

Une photo peut produire une décision plutôt qu’une description

L’intérêt initial de Jev résidait dans des réponses circonscrites : choisir parmi les options proposées, évaluer des niveaux décrits ou répondre à une question par oui ou par non. Notre guide précédent sur le modèle décisionnel de Jev présente ces principes. La nouveauté consiste à étayer ces questions par des éléments visuels et à pouvoir renvoyer des coordonnées spatiales.

Dans une interface de retour, la répartition du travail change. Le modèle peut indiquer que des dégâts sont visibles ; le code de l’application peut afficher cette proposition à côté de l’image envoyée. Ni l’une ni l’autre de ces opérations n’établit quand les dégâts sont apparus, si la photo correspond à cette commande ni si le remboursement est autorisé. Ce sont des questions distinctes qui exigent des éléments différents.

Ces limites sont décrites dans la référence des modèles, le contrat des requêtes API et le SDK compatible avec les images. Un dossier de PDF ne devient pas un pipeline de traitement documentaire simplement parce que certaines pages contiennent des images. De même, plusieurs images extraites ne prouvent ni une compréhension native de la vidéo ni l’accès à sa bande-son.

Notre point de vue : l’unité intéressante est un jugement limité, vérifiable et associé à des éléments de preuve. Ce n’est pas une nouvelle autorisation d’automatiser tout ce qui suit.

Trois exemples officiels confient des tâches différentes à la même photo

La documentation JavaScript de TypeSafe propose trois points de départ concrets. Ce sont des exemples de code publiés, et non des comptes rendus de déploiements clients réels ou des résultats mesurés. Considérez-les comme des modèles de prototype, pas comme des promesses de précision sur vos photos.

Le premier associe une réclamation pour mug endommagé à une photo du produit, puis demande à un Noul si des dégâts sont visibles et à un Score d’en évaluer la gravité. Dans une file d’assistance, une adaptation pourrait mettre en tête les dégâts présumés à inspecter. Le réviseur doit toujours voir la photo entière, la description du client et pouvoir rejeter la proposition.

Le deuxième exemple compare la photo envoyée par un vendeur à une image du catalogue. Il vérifie s’il s’agit du même produit et classe l’utilisabilité de la photo : flou, recadrage ou contenu étranger au produit. Pour une place de marché, cela suggère une distinction utile : la correspondance du produit et la qualité de la photo n’ont pas à dépendre d’une même décision d’approbation. Une image nette du mauvais produit ne doit pas être acceptée simplement parce qu’elle paraît professionnelle.

Le troisième demande à Box de repérer la zone endommagée. Le résultat peut servir à dessiner un calque ou à proposer un recadrage au réviseur. Conservez également l’original non recadré : focaliser l’attention peut aider à examiner une réclamation, mais aussi masquer un contexte qui en change le sens.

Consultez les exemples officiels d’évaluation des dégâts, de comparaison au catalogue et de localisation des dégâts. Le workflow de retour proposé ici ajoute des garde-fous applicatifs à ces modèles ; il ne s’agit pas du compte rendu d’un essai.

Un cadre ne peut pas vous dire qu’il n’y a rien à trouver

Le point essentiel du contrat Box de TypeSafe est qu’aucune sortie n’indique l’absence de la cible. Une question Box renvoie quatre bords même si la cible demandée est absente. Un rectangle autour d’un mug intact ne suffit donc pas à établir l’existence de dégâts.

Posez la question de présence de la cible séparément avec un Noul. Dans ce workflow, distinguez la présence du mug de celle des dégâts. Une réponse positive sur la présence du mug ne suffit pas pour autoriser le calque des dégâts. Ignorez le cadre proposé tant que les contrôles de présence pertinents ne satisfont pas vos règles validées.

Ce contrôle de présence ne supprime pas les erreurs. Les deux jugements peuvent être faux simultanément. Un reflet vif peut ressembler à un éclat, tandis qu’une vraie fissure peut se confondre avec un émail à motifs. Avant de choisir des seuils, testez des photos sans mug, de mugs intacts, de reflets ambigus, de plusieurs objets et de dégâts clairement visibles.

Schéma décisionnel original : un rectangle valide ne peut être utilisé qu’après réussite du contrôle de présence de la cible. Si les contrôles échouent ou restent incertains, la photo originale est conservée pour une vérification humaine ; elle n’entraîne pas de rejet automatique.

Considérez le rectangle comme un repère, pas comme un verdict.

Traitez les coordonnées comme une géométrie, puis vérifiez leur sens

Box renvoie left, right, top et bottom sous forme de fractions des dimensions de l’image, mesurées à partir du coin supérieur gauche. Les valeurs sont comprises entre 0 et 1, avec left < right et top < bottom. Une question produit un seul cadre, et non une liste de détections d’objets. Contrat de réponse Box

Pour une image préparée de 1200 x 900 pixels donnée à titre d’exemple, des bords gauche 0.20, supérieur 0.30, droit 0.60 et inférieur 0.70 correspondent aux coordonnées de pixels 240, 270, 720, 630. Ce sont des exemples de calcul, pas une réponse de Jev. Les API de recadrage attendent souvent les valeurs dans l’ordre gauche, haut, droite, bas ; faites donc correspondre explicitement les champs nommés au lieu de vous fier à l’ordre des propriétés JSON.

Avant de dessiner quoi que ce soit, validez les nombres finis, les bornes et leur ordre. Vérifiez ensuite si la zone désigne réellement les dégâts. Si vous redimensionnez, faites pivoter, ajoutez des marges ou découpez une photo en tuiles, conservez les transformations nécessaires pour retrouver les coordonnées d’origine ; sinon, un cadre plausible risque de pointer vers les mauvais pixels.

Préparez l’image avant la requête, pas après une erreur

Les limites officielles des images sont précises et inclusives. Une image hors limites est rejetée, et non redimensionnée automatiquement ; une seule image rejetée fait échouer toute la requête.

Les références répétées sont comptées à nouveau dans la requête développée. La taille des fichiers, les dimensions et la longueur du contexte sont des vérifications distinctes. Limites des images

Schéma original des contraintes, établi à partir de la documentation des images de TypeSafe, consultée le 18 octobre 2026. Les limites par fichier, pour les images traitées, la requête développée et le corps de la requête s’appliquent indépendamment.

TypeSafe recommande également de réorienter les pixels à la verticale avant l’envoi : l’API supprime les métadonnées et n’applique pas l’orientation EXIF. Convertissez d’abord les formats non pris en charge. Conseils de préparation

Pour un prototype, préparez une copie clairement nommée d’une photo qui vous appartient et conservez l’original intact. Vérifiez les dimensions localement et prévisualisez exactement la copie qui sera envoyée. Un recadrage étroit peut nécessiter des marges pour atteindre la dimension minimale ; consignez-les avant d’interpréter les coordonnées.

Épinglez la version 1.14 et activez explicitement le mode expérimental

Au 18 octobre, le tableau publié des alias associe jev-latest à jev-1.13.0 et jev-preview à jev-1.14.0. Pour un exemple Box, épinglez jev-1.14.0 au lieu de supposer que l’alias latest désigne la dernière préversion. Alias des modèles

La procédure suivante crée un exemple local destiné uniquement à la vérification. L’exécution de la dernière commande envoie une requête d’inférence facturable que le SDK peut réessayer ; elle n’approuve jamais un retour ni ne modifie un compte. Utilisez une photo préparée qui vous appartient, sans personne, étiquette d’expédition, adresse ni document privé.

1. Obtenez l’accès et choisissez la bonne organisation. TypeSafe indique que l’inscription ne nécessite plus d’approbation sur liste d’attente. Créez une clé API dans la console et vérifiez le solde de crédits de l’organisation avant tout test. Accès au compte, gestion des crédits

2. Utilisez Node.js 22 ou une version ultérieure. La version du SDK JavaScript compatible avec les images est 0.7.0, datée du 14 octobre. L’épingler rend explicite la dépendance client de cet exemple. Journal des modifications du SDK

node --version
mkdir jev-photo-check
cd jev-photo-check
npm init -y
npm install @typesafe-ai/[email protected]

3. Définissez une clé valable uniquement pour la session. Sous Windows, utilisez le premier bloc dans PowerShell ; sous macOS ou Linux, utilisez le second dans Bash/Zsh. Remplacez localement la valeur fictive et ne validez jamais une vraie clé dans le dépôt.

$env:TYPESAFE_API_KEY = "your-api-key"

export TYPESAFE_API_KEY="your-api-key"

4. Préparez owned-mug.jpg et créez inspect-return.mjs. Cette adaptation originale utilise les fonctions d’assistance documentées du SDK. L’en-tête expérimental est configuré avant toute requête d’image. Les deux seuils de probabilité ci-dessous sont des règles applicatives illustratives, pas des recommandations de TypeSafe. Chaque résultat reste soumis à une vérification humaine. Utilisation du SDK

import { readFile } from "node:fs/promises";
import { box, image, noul, TypeSafeClient } from "@typesafe-ai/sdk";

if (!process.env.TYPESAFE_API_KEY) {
  throw new Error("Set TYPESAFE_API_KEY before choosing to run this example.");
}

const client = new TypeSafeClient({
  defaultHeaders: { "TypeSafe-Danger-Zone-Images": "true" },
});
const photo = image(await readFile("owned-mug.jpg"));
const response = await client.systemOne({
  model: "jev-1.14.0",
  state: { photo },
  questions: {
    mugVisible: noul("Is a mug clearly visible in `photo`?"),
    damageVisible: noul("Is physical damage clearly visible on the mug in `photo`?"),
    damageRegion: box("The physically damaged area of the mug in `photo`"),
  },
});

const { mugVisible, damageVisible, damageRegion } = response.answers;
const edges = damageRegion.box;
const coordinates = [edges.left, edges.top, edges.right, edges.bottom];
const validBox = coordinates.every(
  (value) => Number.isFinite(value) && value >= 0 && value <= 1,
) && edges.left < edges.right && edges.top < edges.bottom;

const presencePasses = [mugVisible.noul, damageVisible.noul].every(
  (value) => Number.isFinite(value) && value >= 0.95 && value <= 1,
);

console.log({
  model: response.model,
  usage: response.usage,
  humanReviewRequired: true,
  suggestedBox: presencePasses && validBox ? edges : null,
});

5. Lancez l’exemple uniquement si vous êtes prêt à envoyer l’image et à générer des frais. Sur les trois systèmes d’exploitation, la commande est node inspect-return.mjs. Une exception ou la valeur suggestedBox: null doit laisser l’image originale disponible pour examen, et non déclencher de nouveaux envois automatiques.

Les questions partagent une seule requête, mais le cadre est ignoré si le contrôle applicatif n’est pas réussi. Cela n’évite pas de payer le calcul d’un cadre inutilisé. Une conception ultérieure pourrait demander la localisation dans une seconde requête après les contrôles de présence : un aller-retour supplémentaire en échange de l’élimination des appels de localisation inutiles.

Un faible tarif par jeton ne correspond pas au prix d’une photo

Le tarif publié pour les deux versions est de 0,042 $ par million de jetons d’entrée, les jetons de sortie étant gratuits. Ainsi, 10 millions de jetons d’entrée facturés coûtent 0,42 $ au tarif indiqué ; cela ne signifie pas que dix millions d’images coûtent cette somme. Tarifs publiés

Les images sont comptabilisées comme des jetons d’entrée au tarif du texte, sans frais d’image distincts. TypeSafe n’a pas encore publié de formule d’estimation du nombre de jetons image dans sa documentation. Pour budgéter une évaluation autorisée, utilisez usage.input_tokens de la réponse au lieu d’inventer un coût par photo. Facturation des images

Votre budget doit inclure les tentatives échouées, les nouvelles tentatives, le prétraitement, le stockage et le temps de vérification. Évaluez ensemble le coût et la qualité : économiser une fraction de centime ne sert à rien si un recadrage trop serré oblige chaque réviseur à rouvrir l’original. Comparez l’ensemble de la tâche de vérification à une méthode manuelle simple.

Concevez pour l’incertitude, la confidentialité et les périodes de forte activité

Un Noul renvoie une probabilité sans champ confidence distinct. Choice et Score fournissent des distributions et des valeurs de confiance dérivées. Ces valeurs décrivent l’incertitude du modèle ; elles ne constituent pas une garantie générale d’exactitude. Documentation sur la confiance

Pour le workflow du mug, validez le contrôle avec des photos mises de côté et des annotations convenues. Regroupez les résultats similaires et comparez-les à l’exactitude observée afin d’évaluer le calibrage pour votre tâche. Mesurez séparément les dégâts non détectés et les fausses alertes ; distinguez un calque mal placé d’une décision de remboursement incorrecte. Réévaluez les seuils après toute modification du modèle, de l’éclairage, de la catégorie de produit ou du processus de prise de vue.

Ne considérez pas chaque photo qui échoue au contrôle comme une preuve à charge contre le client. Une photo peut être insuffisante parce que l’appareil est médiocre, que l’objet est réfléchissant ou que le défaut nécessite un autre angle. Une bonne interface de vérification permet de demander une autre photo ou de procéder à une inspection manuelle sans faire porter au client la responsabilité de l’incertitude du modèle.

TypeSafe indique que les requêtes et les réponses des clients ne servent pas à entraîner Jev. Son centre d’aide précise également que le traitement peut inclure la fourniture du service, la facturation, la prévention des abus et la télémétrie ; la conservation dépend des données, des accords et d’un éventuel dispositif de conservation nulle. L’absence d’entraînement ne signifie pas l’absence de conservation. Politique de traitement des données

La page publique d’état du service indique les États-Unis comme zone géographique et répertorie les régions us-east-1, us-east-2 et us-west-2. Les équipes soumises à des exigences régionales de résidence des données doivent clarifier le lieu de traitement avant d’envoyer des photos de clients ; pouvoir accéder à une console ne vaut pas accord de résidence des données.

Appliquez le principe de minimisation des données avant l’envoi. Recadrez l’étiquette d’adresse dans une copie préparée si elle n’est pas pertinente, limitez l’accès aux originaux et évitez d’inclure des images ou des secrets dans les journaux courants. Définissez la durée de conservation de vos propres dossiers de vérification indépendamment de la politique du fournisseur.

Les limites de l’organisation concernent le nombre de requêtes et de jetons par seconde. L’API associe le code 429 à la limitation du débit et le code 529 à une surcharge ; une entrée mal formée ou trop volumineuse doit être corrigée, pas renvoyée à l’identique. Limites de débit, erreurs de l’API

La politique de nouvelle tentative du SDK JavaScript prévoit deux nouvelles tentatives par défaut et respecte les en-têtes de délai pris en charge. Évitez d’ajouter une boucle externe de nouvelles tentatives sans limite. Fixez une durée maximale, conservez un état d’erreur exploitable et séparez toute action métier ultérieure afin qu’une nouvelle tentative d’inférence ne puisse pas provoquer de remboursements en double. Politique de nouvelle tentative

Questions à examiner avant votre premier workflow photo

Jev va-t-il retoucher ou générer la photo de retour ?

Non. L’image constitue un élément de preuve pour un jugement ou une zone proposée. Votre application dessine un calque ou effectue un recadrage à l’aide de code de traitement d’images classique. Conservez séparément la source intacte : un rectangle utile ne remplace pas la preuve originale.

Pourquoi l’exemple épingle-t-il la version 1.14 au lieu d’utiliser latest ?

Le tableau publié des alias associe actuellement jev-latest à la version 1.13, tandis que Box nécessite la version 1.14. Épingler jev-1.14.0 rend cette dépendance explicite. Avant de changer de version, consultez les notes de version et votre jeu de tests au lieu de supposer qu’une mise à jour d’alias préservera le comportement.

Une forte probabilité de dégâts peut-elle déclencher un remboursement ?

Pas de manière sûre sur la seule base de cet élément. La probabilité répond à une question portant sur l’image envoyée ; elle n’authentifie pas la commande, n’établit pas les responsabilités et n’applique pas votre politique de remboursement. Commencez par une aide à la vérification, validez des exemples représentatifs et gardez une décision humaine pour les actions lourdes de conséquences.

La gratuité des sorties signifie-t-elle qu’une requête avec image ne coûte rien ?

Non. Les jetons d’entrée, y compris ceux des images, sont facturés. Le tarif publié ne permet pas de calculer un prix par photo, car la formule d’estimation des jetons image n’est pas encore documentée. Lors d’un essai autorisé, examinez l’utilisation rapportée et incluez les nouvelles tentatives ainsi que le temps de vérification dans le total.

Puis-je envoyer directement une vidéo de produit ou un PDF ?

Pas via l’interface documentée pour les images fixes. Votre application doit d’abord en extraire des images pertinentes, du texte ou des pages rendues, avec l’autorisation de les traiter. Extraire une image fixe fait perdre les informations temporelles et audio ; posez uniquement des questions auxquelles les éléments fournis permettent de répondre.

En bref : guider l’attention avant de déléguer l’autorité

L’aperçu des capacités d’image de Jev ouvre une piste concrète : transformer des éléments visuels en réponses limitées que le logiciel peut examiner. Un outil de retour de mug peut tester cette idée en distinguant la présence, les dégâts, leur emplacement et la vérification. Le premier résultat utile n’est pas un remboursement autonome, mais une décision mieux étayée que le réviseur peut prendre plus rapidement.

Voilà le critère qui mérite d’être mesuré : la zone proposée aide-t-elle une personne à comprendre les éléments d’origine, y compris lorsque le modèle se trompe ?

Sources et périmètre

Sources primaires consultées le 18 octobre 2026 : l’annonce du 14 octobre, les modèles et tarifs, les limites d’image et la facturation, le contrat Box, les exemples JavaScript et les notes de version du SDK de TypeSafe. Les autres sources relatives aux politiques et à la fiabilité sont liées à côté des affirmations correspondantes. Le workflow et les schémas sont des adaptations explicatives, pas un benchmark pratique ; aucun appel payant au modèle n’a été effectué pour cet article. Les schémas sont originaux et ne reprennent pas les médias du fournisseur.

Gardez la source avec la conclusion

Pour vos propres recherches sur les modèles, conservez les sources originales séparément des conclusions que vous en tirez. Créez un compte Telli.sh pour organiser vos documents de recherche et vos notes dérivées tout en préservant le contexte des sources.