API, webhook ou fichier : comment choisir
Le mode d'échange entre deux systèmes détermine la latence, le coût et la fragilité d'une intégration. Comprendre les différences permet de poser les bonnes questions dès le cadrage et d'éviter les promesses intenables.
Distinction importante : le mode d'échange (API, webhook, fichier) est une propriété de la prestation — comment on exploite ce que le logiciel expose. Il dépend des capacités techniques du logiciel et du besoin métier du client.
Les trois modes d'échange
API (Application Programming Interface)
Interface programmatique exposée par un logiciel pour permettre à d'autres systèmes de lire et d'écrire des données.
Avantages
- Contrôle total sur le moment de l'échange
- Accès à l'ensemble des données exposées
- Possibilité de filtrer et paginer
Limites
- Nécessite une interrogation régulière pour détecter les changements
- Charge sur le système interrogé si le rythme est élevé
- Quota et limites de débit fréquents
Cas d'usage typiques
- Synchronisation de référentiels (contacts, produits)
- Requêtes ponctuelles (vérification d'un statut)
- Import initial de données historiques
Webhook (notification sortante)
Notification envoyée par un logiciel vers une URL externe lorsqu'un événement se produit. Le logiciel pousse l'information au lieu d'attendre qu'on la lui demande.
Avantages
- Temps réel : la notification part dès que l'événement se produit
- Aucune interrogation inutile
- Charge minimale sur le système source
Limites
- Données limitées à ce que l'éditeur choisit d'envoyer
- Pas de garantie de livraison sans mécanisme de reprise
- Configuration parfois liée au niveau de licence
Cas d'usage typiques
- Synchronisation en temps réel (nouvelle commande, modification)
- Déclenchement de workflows automatisés
- Alertes métier
Fichier (CSV, XML, JSON)
Export de données dans un fichier déposé sur un serveur, récupéré par le système destinataire. Mode historique, encore très répandu dans l'industrie et les logiciels anciens.
Avantages
- Fonctionne même sans API
- Traitement par lot, efficace pour les gros volumes
- Facile à auditer et à rejouer
Limites
- Latence incompatible avec le temps réel
- Format strict, sensible aux erreurs d'encodage
- Infrastructure de stockage (FTP, SFTP) à maintenir
Cas d'usage typiques
- Échange avec des ERP anciens ou on-premise
- Reprise d'historique
- Flux comptables réglementés
Comparaison synthétique
| Critère | API | Webhook | Fichier |
|---|---|---|---|
| Latence | 1-60 min | Secondes | Heures |
| Charge sur la source | Élevée si fréquent | Faible | Nulle entre exports |
| Détection des changements | À implémenter | Native | Comparaison de fichiers |
| Reprise sur erreur | Simple (redemander) | À implémenter | Rejouer le fichier |
| Volume maximal | Limité par quotas | Limité par payload | Illimité |
| Infrastructure requise | Connecteur | Endpoint public | Serveur de fichiers |
Comment choisir
Le choix du mode d'échange découle de trois questions :
- Quelle latence est acceptable ? Si un délai de plusieurs heures est tolérable, le mode fichier reste pertinent. Si l'information doit arriver en quelques minutes, l'API programmée suffit. Si elle doit arriver en quelques secondes, seul le webhook convient — à condition que l'éditeur l'expose.
- Quel volume est traité ? Les webhooks sont conçus pour des événements unitaires, pas pour des transferts de masse. Un import initial de cent mille enregistrements se fait via API paginée ou via fichier, jamais via webhook.
- Qui doit être notifié de quoi ? Le webhook permet de déclencher une action dès qu'un événement se produit. L'API permet de récupérer l'état complet à un instant donné. Les deux usages sont complémentaires, pas exclusifs.
Dans la plupart des projets, la réponse n'est pas « API ou webhook ou fichier » mais « API et webhook », chacun pour ce qu'il fait le mieux : le webhook déclenche, l'API complète.
Besoin de cadrer un projet d'intégration ?
Répondons ensemble aux questions clés pour choisir le bon mode d'échange.