API de traçabilité : ce qu’il faut demander à un éditeur avant de signer

Une API (interface de programmation) est ce qui permet à deux logiciels d'échanger des données automatiquement — entre un outil de traçabilité et une caisse, un ERP, ou le système d'un partenaire commercial. Ce guide traduit, en langage non technique, les questions qui comptent avant de s'engager sur un outil dont l'API sera sollicitée.

Ce que « avoir une API » ne garantit pas

Presque tous les éditeurs annoncent « une API disponible » — l'existence d'une API ne dit rien de sa qualité réelle. Ce qui distingue une API exploitable d'une API annoncée mais inutilisable en pratique tient à des détails précis, listés ci-dessous.

Les questions à poser

1. La documentation est-elle publique et à jour ?Une documentation accessible sans compte préalable, à jour avec la version en production, permet à un prestataire de chiffrer un développement d'intégration sans dépendre du support commercial de l'éditeur.
2. Quel est le débit d'appels autorisé ?Une limite trop basse (nombre de requêtes par minute) peut bloquer une intégration dès qu'un volume significatif de données doit transiter, notamment lors d'un import initial de l'historique.
3. Quels formats d'export sont disponibles ?Un format standard (CSV, JSON structuré) facilite l'intégration ; un format propriétaire non documenté impose de dépendre de l'éditeur pour chaque évolution.
4. Quelle disponibilité est garantie contractuellement ? Un engagement de disponibilité (souvent exprimé en pourcentage annuel) donne une base pour évaluer le risque d'interruption, à défaut d'une garantie de fonctionnement parfait.
5. L'export complet des données est-il possible sans l'API ?Une solution de secours (export manuel complet) protège en cas de panne prolongée de l'API elle-même.

La réversibilité : la question la plus souvent négligée

Réversibilité signifie : si l'entreprise change d'outil dans deux ou trois ans, peut-elle récupérer l'intégralité de ses données, dans un format réutilisable ailleurs ? Cette question se pose avant de signer, pas au moment du changement d'outil — un contrat ou des conditions générales qui restent muettes sur ce point exposent à une dépendance de fait, même sans clause d'exclusivité explicite.

Ce qu'un développeur ou prestataire vérifie techniquement

Sans entrer dans le détail technique, un prestataire chargé de l'intégration vérifiera généralement :

• Le mécanisme d'authentification (comment l'accès est sécurisé).
• La gestion des erreurs (ce qui se passe quand un appel échoue, et comment le détecter).
• La présence de webhooks (notifications automatiques de changement) pour éviter d'interroger l'API en permanence.

Il n'est pas nécessaire de comprendre ces mécanismes en détail pour piloter le projet — il suffit de savoir qu'ils existent et de demander à son prestataire de les vérifier avant signature.

Erreurs fréquentes

• Signer sans avoir fait vérifier l'API par un technicien, même externe, avant de s'engager sur un projet d'intégration.
• Ignorer la question de la réversibilitéjusqu'au jour où elle devient nécessaire — trop tard pour négocier de meilleures conditions.
• Se fier à une démonstration commercialede l'API plutôt qu'à un test réel sur un cas d'usage représentatif du volume attendu.

Checklist

1. Demander l'accès à la documentation publique avant tout engagement commercial.
2. Vérifier le débit d'appels et les formats d'export disponibles.
3. Demander l'engagement de disponibilité contractuel, s'il existe.
4. Clarifier explicitement la réversibilité et l'export complet des données.
5. Faire vérifier l'API par un technicien avant de signer, même pour un projet modeste.