API vs XML automobile : la même donnée, deux chemins
Votre logiciel VO connaît votre parc à la minute près. Votre site WordPress, lui, n'affiche que ce que la dernière synchronisation lui a transmis. Entre les deux, il n'existe que deux chemins possibles : un fichier XML que votre éditeur dépose sur un serveur, ou une API que la passerelle interroge avec des identifiants. La question API vs XML automobile n'est pas un débat d'ingénieurs : elle décide de la fraîcheur de vos annonces, de la fréquence de synchronisation qui a réellement un sens dans votre cas, et de la manière dont on répare quand le stock cesse de remonter.
Ce choix ne vous appartient pas : il dépend de ce que votre éditeur expose, et un même logiciel propose rarement les deux. Savoir dans quelle famille vous êtes change en revanche les questions à poser le jour où le site affiche un véhicule vendu depuis trois jours.
Le flux XML : une photographie du stock à l'heure du dépôt
Le principe est ancien et il n'a pas bougé. Votre éditeur génère à intervalles réguliers un fichier contenant l'intégralité de votre stock, puis le dépose sur un serveur de fichiers. La passerelle s'y connecte avec un identifiant et un mot de passe, télécharge le fichier, le lit de bout en bout et met le site à jour.
C'est le mode de la passerelle PlanetVO pour WordPress, qui récupère le fichier en FTP et bascule en SFTP quand le serveur l'exige. Une entrée du fichier porte tout ce qui décrit un véhicule : version, mise en circulation, kilométrage, motorisation, couleurs, équipements de série distingués des options, garantie, numéro de série, URL des photos, jusqu'aux coordonnées de l'annonceur.
Les plateformes de multidiffusion relèvent de la même famille. La passerelle Ubiflow pour WordPress lit elle aussi un fichier XML, avec une nuance de contenu : conçue pour alimenter plusieurs portails, elle transporte la notion d'offre et le contact à publier.
Sa force : il est complet, rejouable et lisible
Un fichier XML a trois qualités que l'on sous-estime. Il est autonome : tout le stock est dedans, sans session à maintenir ni appel qui s'interrompe au milieu. Il est rejouable : on relance la lecture du même fichier et on obtient le même résultat. Il est lisible : on l'ouvre et on vérifie de ses yeux si le champ « prix » du véhicule qui pose problème contient bien la valeur attendue. En dépannage, cette dernière propriété fait gagner un temps considérable.
Sa limite : il est figé à l'heure de sa génération
Le fichier est une photographie. Elle date du moment où votre éditeur l'a produite, pas du moment où votre passerelle l'a téléchargée. Synchroniser toutes les heures un fichier régénéré deux fois par jour ne change rien à la fraîcheur de vos annonces : vous relisez douze fois la même photo.
C'est la première chose à faire vérifier lors d'une mise en service : à quel rythme votre éditeur régénère-t-il le fichier, et à quelles heures. Sans cette information, tout réglage de fréquence relève de la superstition.
Conséquence directe sur le terrain : une remise consentie un vendredi à 18 h n'apparaîtra sur le site qu'après la prochaine génération du fichier. Si celle-ci a lieu la nuit, le week-end démarre avec l'ancien prix affiché — et c'est précisément le moment où votre trafic est le plus fort.
L'API authentifiée : le stock interrogé à la demande
Avec une API, il n'y a plus de fichier. La passerelle s'authentifie auprès du service de l'éditeur, puis demande les véhicules. La donnée renvoyée est celle de l'instant : elle sort de la base du logiciel, pas d'un export produit quelques heures plus tôt. Trois formes d'authentification couvrent l'essentiel des cas rencontrés.
- Le jeton JWT. Un couple client_id / client_secret permet d'obtenir un jeton, qui autorise ensuite les appels pendant une durée limitée. C'est le fonctionnement de la passerelle TEC3H pour WordPress, qui gère en plus le multi-concession : chaque véhicule doit être rattaché au bon point de vente, avec son adresse, sa ville et ses téléphones.
- OAuth. Même logique d'échange d'identifiants contre une autorisation, avec un protocole normalisé. La passerelle AutoScout24 pour WordPress s'y appuie, et son flux transporte des champs que l'on ne trouve pas partout : norme antipollution, groupes d'équipements, et pour l'électrique la capacité de batterie, le type de prise, la puissance et le temps de charge.
- L'URL signée. Pas de jeton à conserver : chaque requête est signée à l'aide d'une clé et d'un secret. C'est le principe de la passerelle Auto-Gestion pour WordPress.
Pagination, quotas et interruptions
Une API ne renvoie pas 400 véhicules d'un coup. Elle les livre par pages, et la passerelle doit parcourir toutes les pages avant de considérer la synchronisation terminée. Cette mécanique introduit une fragilité que le fichier XML ignore : un appel qui échoue à la page 7 sur 12 laisse un stock partiel.
Deux causes reviennent. Le jeton peut expirer en cours de traitement, sur un parc important dont l'import prend du temps ; une passerelle correcte le renouvelle sans s'arrêter. Et beaucoup d'API limitent le nombre d'appels sur une période donnée : dépasser ce plafond fait échouer les requêtes suivantes, avec un message qui ne parle ni de vos identifiants ni de vos véhicules.
Comparatif API vs XML automobile
| Critère | Flux XML sur FTP / SFTP | API authentifiée |
|---|---|---|
| Fraîcheur de la donnée | Celle de la génération du fichier | Celle de l'instant de l'appel |
| Ce que vous fournissez | Hôte, identifiant, mot de passe | Identifiants d'API ou clé et secret |
| Complétude d'une passe | Tout le stock en une fois | Page par page, à parcourir en entier |
| Risque principal | Fichier périmé, tronqué ou absent | Jeton expiré, quota atteint, import partiel |
| Vérification manuelle | Le fichier s'ouvre et se lit | Nécessite de rejouer un appel authentifié |
| Sensible à l'heure du serveur | Non | Oui pour les URL signées |
Ce que ça change pour la fréquence de mise à jour
Le délai réel entre une modification dans votre logiciel et son affichage sur le site n'est pas un chiffre que l'on peut vous annoncer : c'est une addition que vous seul pouvez poser, avec trois termes.
- Le délai de production de la donnée. Nul avec une API. Égal à l'intervalle entre deux générations du fichier avec un flux XML.
- Le délai de la passerelle. La synchronisation planifiée du plugin AutoWP se règle sur deux rythmes : toutes les heures, ou deux fois par jour. En moyenne, comptez la moitié de cet intervalle ; au pire, l'intervalle entier.
- Le retard de déclenchement. Le cron de WordPress n'est pas un planificateur système : il se réveille à la visite d'une page. Sur un site peu fréquenté, une tâche « horaire » peut attendre. Un cron serveur qui appelle le site à heure fixe supprime ce terme.
Quand ça casse, le diagnostic n'est pas le même
C'est là que la distinction devient très concrète, parce que les symptômes se ressemblent — le site n'est plus à jour — alors que les causes n'ont rien à voir.
Sur un flux XML
On commence toujours par la même question : le fichier existe-t-il, et de quand date-t-il ? Un fichier daté de l'avant-veille désigne l'éditeur, pas la passerelle. Un fichier absent oriente vers un mot de passe FTP changé, un nom de fichier qui a tourné, un dossier déplacé. Un fichier présent mais plus petit que d'habitude trahit une génération interrompue côté source : cas traître, puisqu'il reste valide, simplement incomplet.
Sur une API
Le premier réflexe est de rejouer un appel authentifié. Un refus d'authentification pointe vers des identifiants révoqués ou un jeton non renouvelé. Un refus qui apparaît seulement à partir d'une certaine page évoque un plafond d'appels. Et sur une URL signée, une erreur d'authentification alors que rien n'a changé chez vous a souvent une cause inattendue : l'horloge de votre serveur a dérivé, ou vous venez de migrer d'hébergeur. La signature intègre des éléments variables, elle ne pardonne pas le décalage.
Le point commun : ne jamais supprimer sur un import partiel
Un import interrompu à mi-parcours ressemble, vu de WordPress, à un parc qui aurait perdu la moitié de ses véhicules. Si le plugin est réglé sur la suppression définitive des véhicules absents du flux, une simple panne réseau efface des fiches qui n'ont jamais été vendues, avec leurs URL et leur référencement.
C'est pourquoi nous conseillons, au moins les premières semaines, la mise à la corbeille ou le basculement en catégorie « vendus » plutôt que la suppression. La corbeille laisse le temps de récupérer ; la catégorie « vendus » sort le véhicule du listing des disponibles tout en gardant sa page en ligne.
La photo qui n'arrive pas
Le cas revient dans les deux familles, avec un mécanisme identique. Le flux ne transporte pas les images : il transporte leurs URL. La passerelle doit les télécharger une par une, les ranger dans la médiathèque et conserver l'ordre d'origine — la première photo devient l'image mise en avant.
Quand une seule photo manque sur un véhicule qui en compte trente, la cause est presque toujours à l'autre bout : l'URL renvoie une erreur, ou l'image n'était pas encore publiée côté éditeur au moment de la passe. La suivante la récupère. Si aucune photo n'arrive sur l'ensemble du parc, cherchez plutôt du côté des restrictions de téléchargement de votre hébergement.
Ce que vous pouvez vérifier avant d'appeler
- La date et la taille du dernier fichier déposé, s'il s'agit d'un flux XML.
- La date de la dernière synchronisation réussie côté WordPress.
- Le nombre de véhicules affichés sur le site comparé au nombre présent dans votre logiciel : un écart de quelques unités et un écart de moitié ne racontent pas la même histoire.
- Un changement récent d'identifiants, de mot de passe ou de contrat chez votre éditeur.
- Une migration d'hébergement ou un changement de serveur dans les jours précédents.
Vous ne choisirez pas le mode de connexion de votre logiciel, mais vous pouvez savoir lequel vous concerne avant de lancer un projet : la liste des passerelles disponibles précise, pour chaque logiciel, le mode de connexion réellement développé et les champs que son flux transporte jusqu'à la fiche véhicule.