ZeDaq.ai
Try it on and Find my size button on a fashion product page

API d'essayage virtuel : le guide pour les développeurs e-commerce

Par l'équipe ZeDaq.ai · · 5 min de lecture

Sommaire
  1. Quand choisir l'API plutôt que le widget ?
  2. Comment fonctionne un appel à l'API ?
  3. Comment protéger votre clé API ?
  4. Quelles données personnelles traitez-vous ?
  5. Comment gérer la recommandation de taille ?
  6. Comment tester l'intégration ?
  7. Combien coûte l'API ?

L'API d'essayage virtuel de ZeDaq.ai est une API REST : vous envoyez une requête POST /api/v1/tryon avec votre clé dans l'en-tête x-api-key, et vous recevez le rendu du vêtement porté par le client. C'est la bonne option pour les développeurs e-commerce qui construisent leur propre interface, un front headless ou une application.

Ce guide s'adresse aux développeurs et aux agences qui travaillent pour des marques de mode. Il couvre l'architecture, la sécurité de la clé et le choix entre API et widget. Pour le contexte côté marque, voyez notre guide de la cabine d'essayage virtuelle.

Quand choisir l'API plutôt que le widget ?

ZeDaq.ai propose trois intégrations. L'API n'est pas toujours la plus adaptée.

Besoin Intégration conseillée
Boutique Shopify standard Application Shopify
WooCommerce, Wix, Squarespace, BigCommerce, PrestaShop ou site sur mesure, avec l'interface fournie Balise script (widget)
Front headless, application mobile, parcours d'essayage sur mesure API REST
Traitement côté serveur, par exemple dans un back-office API REST

Si votre client veut juste un bouton d'essayage sur ses fiches produit, le widget demande beaucoup moins de travail. Notre article sur le widget pour Wix et Squarespace montre à quel point il est simple à poser.

L'API devient intéressante quand l'interface doit suivre une charte précise, s'intégrer à un parcours existant ou fonctionner hors navigateur.

Comment fonctionne un appel à l'API ?

Le principe est celui d'une API REST classique :

POST /api/v1/tryon
x-api-key: VOTRE_CLE

Le corps de la requête contient les éléments nécessaires au rendu : l'image du client et le vêtement à essayer. Le format exact des champs, les types acceptés et la structure de la réponse sont décrits dans la référence de l'API (en anglais). Basez-vous sur ce document, pas sur un exemple trouvé ailleurs.

Le parcours type

  1. Le client choisit un vêtement dans votre interface.
  2. Il importe ou prend une photo de lui, en pied.
  3. Votre front envoie la photo à votre serveur.
  4. Votre serveur appelle POST /api/v1/tryon avec la clé.
  5. Votre serveur renvoie le rendu au front, qui l'affiche.

Afficher le résultat côté front

Le rendu prend quelques instants. Prévoyez un état d'attente clair dans votre interface : un indicateur de chargement et une phrase du type « Nous préparons votre essayage ». Évitez de bloquer toute la page pendant ce temps.

Affichez ensuite le résultat à côté de la photo produit, pas à sa place. Le client compare plus facilement les deux images. Proposez enfin deux actions simples : essayer un autre vêtement ou ajouter au panier. Si le client veut recommencer avec une autre photo, laissez-le faire sans recharger la page.

Comment protéger votre clé API ?

La clé donne accès à votre quota d'essayages. Elle doit être traitée comme un secret.

  • Appelez l'API depuis votre serveur, jamais directement depuis le navigateur avec la clé en clair dans le code.
  • Stockez la clé dans une variable d'environnement, hors du dépôt Git.
  • Créez une clé par environnement (développement, préproduction, production) pour pouvoir en révoquer une sans tout couper.
  • Limitez l'accès à votre propre endpoint : authentification de session, limitation du nombre de requêtes par utilisateur, taille maximale des fichiers envoyés.

Le widget fonctionne autrement : sa clé est visible dans la page, mais elle doit être verrouillée sur le domaine de la boutique dans le tableau de bord, rubrique API keys. Ce verrouillage est obligatoire pour une clé de widget.

Quelles données personnelles traitez-vous ?

Une photo de client est une donnée personnelle au sens du RGPD. En tant que développeur, vous êtes bien placé pour réduire les risques dès la conception.

  • Ne conservez pas la photo sur votre serveur plus longtemps que nécessaire au rendu.
  • Ne journalisez pas le contenu des images dans vos logs.
  • Chiffrez les échanges (HTTPS de bout en bout).
  • Prévoyez un texte d'information près du bouton, validé par la marque.
  • Documentez le parcours des données pour le registre de traitement de votre client.

Notre article sur l'essayage virtuel et le RGPD détaille ce que la marque doit expliquer à ses clients.

Comment gérer la recommandation de taille ?

La recommandation de taille repose sur un scan corporel d'environ 30 secondes : une photo et la taille du client. Les mesures sont comparées au guide des tailles de la marque, saisi dans le tableau de bord, rubrique Size charts.

Le guide se saisit par type de vêtement : hauts, vêtements d'extérieur, robes, bas. La recommandation renvoie les étiquettes de la marque, et choisit la taille au-dessus selon la mesure la plus large concernée. Sans guide, un tableau générique UK, US, EU ou AU sert de secours.

Avant de câbler quoi que ce soit, demandez à la marque de saisir ses tableaux. C'est souvent la tâche qui prend le plus de temps, et elle ne dépend pas de vous.

Comment tester l'intégration ?

Prévoyez un plan de test simple avant la mise en production :

  1. Jeu de photos de test : plusieurs morphologies, de face, en pied, avec l'accord des personnes photographiées.
  2. Jeu de vêtements : un haut, une robe, un pantalon, une veste, avec des photos produit de face.
  3. Cas d'erreur : clé absente ou invalide, fichier trop lourd, photo non exploitable. Votre interface doit afficher un message clair dans chaque cas.
  4. Test mobile : la majorité des essais se font sur téléphone, avec des photos prises sur l'instant.
  5. Test de charge raisonnable : vérifiez le comportement de votre serveur quand plusieurs clients lancent un essai en même temps.

Combien coûte l'API ?

L'API utilise les mêmes formules que les autres intégrations, en dollars américains. La formule Free est à 0 $ avec 3 essayages et 3 mesures par mois, utile pour le développement. Viennent ensuite Micro à 14 $/mois, Starter à 49 $/mois, Growth à 129 $/mois et Scale à 299 $/mois.

Chaque formule payante démarre par un essai gratuit de 3 jours, sans carte bancaire. Pour un panorama plus large des usages, notre guide de l'API pour développeurs (en anglais) complète cette page.

Obtenez votre clé et lancez votre premier appel

Questions fréquentes

L'API d'essayage est-elle une API REST ?

Oui. Vous appelez POST /api/v1/tryon avec votre clé dans l'en-tête x-api-key.

Puis-je appeler l'API depuis le navigateur ?

C'est déconseillé, car la clé serait exposée. Passez par votre serveur, ou utilisez le widget avec une clé verrouillée sur votre domaine.

Où trouver le format exact des requêtes ?

Dans la référence de l'API, disponible depuis la documentation de ZeDaq.ai. C'est la source à suivre pour les champs et les réponses.

L'API couvre-t-elle l'essayage de lunettes ?

ZeDaq.ai propose un essayage de lunettes en direct avec la caméra. Vérifiez dans la documentation comment l'intégrer à votre projet.

Essayez ZeDaq.ai gratuitement

Essayage virtuel et recommandation de taille pour votre boutique, plus des outils clients, commandes et factures pour les couturiers.

Articles liés