Logiciels de gestion de flotte : données véhicule de l’entrée à la sortie du parc

Où les données manquent dans le processus

Un logiciel de flotte vaut ce que valent ses données de base. En pratique, elles naissent là où quelqu’un retape un document ou rattache une photo à la main. Lacunes typiques :

• À l’entrée au parc. Le certificat d’immatriculation est retapé — pour les flottes internationales à partir de documents dont la mise en page change selon le pays. Les erreurs de VIN, de codes de type ou de première immatriculation se propagent dans chaque analyse ultérieure. Voir Certificat d’immatriculation : les champs qui comptent.
• Dans les déclarations de sinistre. Une photo arrive avec une plaque mais sans identifiant véhicule ; quelqu’un cherche la plaque dans le parc et l’affecte.
• Pour les rappels. Courriers constructeur et avis des registres sont vérifiés à la main, souvent seulement quand un conducteur pose la question.
• À la restitution. L’état est coché sur un formulaire, les photos restent à côté sans structure ; en cas de litige, le lien entre constat et photo manque.
• À la sortie du parc. Vente, export ou traitement se décident sans base chiffrée — et sans se demander si le véhicule est juridiquement encore une marchandise. Voir Occasion ou VHU ? La frontière qui décide de l’exportation.

Ce que l’API fournit

Un déroulé de bout en bout

1. Entrée au parc. Le document d’immatriculation est transmis en image ou PDF par fileUrl à POST /scanner/document/registration/international. Les champs de base normalisés remplissent les données de base, sourceValue conserve l’imprimé. Noms, adresses, plaques et VIN ne sont jamais traduits.
2. Identification. Le VIN reconnu part vers GET /vin/{vin}/vehicle ; les fournisseurs 2 et 3 répondent directement, le fournisseur 1 répond aux systèmes tiers par redirect_required. Le back-end crée alors une session via POST /vin/redirect-sessions à partir de vin, returnUrl et state et envoie l’utilisateur vers redirectUrl ; le rapprochement a lieu dans l’interface tapinoma, le retour porte status=completed, tapiId et state — jamais de données véhicule. La session expire après dix minutes. Structure du numéro dans VIN : lire, vérifier et exploiter le numéro d’identification.
3. Exploitation. Une déclaration de sinistre arrive avec une photo. POST /vision/license-plate renvoie, à partir de 3 prises de vue au plus, les caractères, une forme de comparaison et le pays en ISO 3166-1 alpha-2 ; la forme de comparaison est rapprochée du parc.
4. Rappels. Un passage nocturne appelle GET /recalls/vehicles/{vin} pour le parc ; le VIN n’est résolu qu’à partir du propre stock déjà rapproché, sans appel à un fournisseur. Une mesure avec indicateur stop-drive crée un blocage et une tâche.
5. Restitution. Jusqu’à 8 prises de vue du tour du véhicule partent vers POST /vision/condition-report. Les constats par zone — avant, flanc gauche, flanc droit, arrière, toit, habitacle, compartiment moteur, autres — et la note globale vont dans le procès-verbal ; quelle photo correspond à quelle zone, c’est le logiciel de flotte qui le consigne lui-même, la réponse n’indique que imageCount.
6. Sortie du parc. POST /vision/vehicle/elv-classification établit à partir de 1 à 10 prises de vue s’il existe un soupçon de VHU ; gutachten_empfohlen signifie qu’une expertise doit porter la décision. Pour vendre ou faire traiter, GET /vin/{vin}/economic-evaluation avec provider=1 fournit le potentiel de recette des pièces en min, average et max — 200 immédiatement si la liste de pièces et les évaluations sont déjà disponibles, sinon 202 avec un identifiant de tâche et le résultat via GET /vin/economic-evaluation/jobs/{jobId}. Contexte dans Véhicules accidentés : épave, valeur résiduelle et intérêt pour le centre et Achat de véhicules : ce que vaut réellement un VHU.

curl \
  -H 'X-Api-Key: <API_KEY>' \
  -H 'Content-Type: application/json' \
  -d '{"fileUrl": "<FILE_URL>"}' \
  'https://api.tapinomahub.com/scanner/document/registration/international'

L’intégration

1. Garder la clé côté serveur. La X-Api-Key réside dans la configuration du back-end. Applications conducteur et navigateurs parlent à votre serveur, jamais à l’API directement.
2. Commencer par un point d’entrée. Pour un logiciel de flotte, c’est le plus souvent la lecture du document d’immatriculation à l’entrée ; qui dispose d’un stock de VIN rapprochés commence par les rappels.
3. Définir la correspondance des champs. Quel champ du document remplit quel champ des données de base ? fields et sourceValue sont conservés, chaque champ porte sa provenance : document, rapprochement ou saisie.
4. Distinguer résultat vide et erreur. 404 vehicle_not_found est un résultat vide au sens métier, pas une erreur technique ; un champ null reste vide et génère une tâche. Une analyse d’image effectuée est facturée même sans résultat.
5. Récupérer les appels longs. Un 202 porte Location, Retry-After et un identifiant de tâche. Le back-end interroge le point d’entrée de tâche et écrit le résultat dès qu’il est là.
6. Déployer par étapes. Un client d’abord, puis tous. GET /client/usage montre quels appels tournent et à quelle fréquence ; X-Tapinoma-Usage-Warning signale un solde qui baisse.

Points de vigilance

• Poser `Idempotency-Key`. Un appel répété après une coupure réseau ne doit pas déclencher une seconde analyse ; X-Tapinoma-Idempotent-Replay signale la répétition. Les appels qui délivrent une clé ne sont pas rejoués — après un délai dépassé, rapprocher le stock via GET /client/users.
• Laisser vides les champs vides. Ce que document ou image ne donnent pas revient en null. Une valeur par défaut plausible est plus dangereuse qu’un manque visible.
• Enregistrer la `tapiId`. Elle est stable, et GET /vehicles/{tapiId} fournit les données techniques dans le cadre du parcours VIN déjà facturé — sans second rapprochement à chaque ouverture du dossier.
• Jamais la clé dans le navigateur. Ni dans une application conducteur, ni dans une borne sur site.
• Limites de débit par client. Le passage des rappels a sa fenêtre horaire, et PUT /client/users/{clientId}/rate-limits plafonne ce qu’un utilisateur seul peut déclencher.
• Vérifier les résultats. La confiance sur la plaque, la confiance de correspondance sur le rappel et A/B/C sur l’état sont des indications de fiabilité, pas des décisions. Ce qui est dû est l’analyse, l’usage revient au client — cadre juridique dans Données dans un VHU : ce qui reste dans l’infodivertissement.

Ce que l’API ne fait pas

Elle n’identifie pas de titulaire : POST /vision/license-plate lit la plaque sur la photo, sans confrontation à un registre ni à un fichier de titulaires. Elle ne remplace pas une expertise : le rapport d’état est un contrôle visuel sans calcul de réparation ni de valeur résiduelle, et gutachten_empfohlen veut dire exactement cela. Elle ne garantit aucun prix : l’analyse de rentabilité donne un potentiel de recette issu de références de marché, pas un prix de vente. Le contrôle des rappels est une aide de travail au niveau de la série, pas une déclaration du constructeur propre au véhicule. Le fournisseur 1 n’est accessible aux systèmes tiers que par le parcours de redirection. Et elle ne vend aucune base de données : ce qui est dû est l’analyse et la restitution du résultat. Ce qui part au traitement peut être accompagné d’attributs prouvés — voir CO₂ et pièces d’occasion : ce qu’on peut dire sérieusement.