En bref. Une API permet à deux logiciels d’échanger des données sans intervention humaine. Le sujet n’est pas technique mais organisationnel : quelles données circulent, dans quel sens, à quelle fréquence, et qui traite les erreurs.
Les éditeurs présentent leurs connecteurs comme des interrupteurs : on active, tout circule. La réalité est moins simple, et l’écart se paie en écritures fantômes, en doublons et en heures de rapprochement.
Ce qu’une API permet concrètement
- Faire remonter les ventes d’une caisse ou d’une boutique en ligne vers la comptabilité.
- Envoyer les factures d’achat depuis un outil de capture vers le logiciel comptable.
- Synchroniser un référentiel tiers entre un CRM et un outil de facturation.
- Récupérer des relevés bancaires pour alimenter le rapprochement.
- Transmettre des éléments variables de paie depuis un outil de gestion des temps.
Dans chacun de ces cas, l’intérêt n’est pas seulement le temps gagné : c’est la suppression d’une ressaisie, donc d’une source d’erreurs — sujet développé dans notre article sur l’automatisation comptable.
Les questions à trancher avant de connecter
- Quelles données circulent exactement ? Les écritures agrégées ou le détail ligne à ligne ?
- Dans quel sens ? Une synchronisation bidirectionnelle demande une règle d’arbitrage en cas de divergence.
- À quelle fréquence ? Temps réel, horaire, quotidien : le choix a un coût et un intérêt variables.
- Qui fait autorité sur chaque donnée ? Un tiers modifié des deux côtés crée immanquablement un conflit.
- Que se passe-t-il en cas d’échec ? Reprise automatique, alerte, file d’attente ?
La question 4 est la plus structurante. Décider qu’un seul outil fait référence pour le fichier clients, et que les autres le reçoivent, évite l’essentiel des incohérences.
Les modes d’échange
| Mode | Principe | Quand l’utiliser |
|---|---|---|
| Appel programmé | Le système interroge l’autre à intervalle régulier | Volumes modérés, tolérance au délai |
| Notification par événement | Le système émetteur prévient dès qu’un fait survient | Réactivité nécessaire, volumes importants |
| Fichier déposé | Export et import périodiques | Absence d’API, flux simples |
| Base partagée | Un seul référentiel commun | Outils d’un même éditeur |
La troisième ligne reste très répandue et n’a rien de honteux : un export quotidien fiable vaut mieux qu’une API instable. Ce qui compte est la fiabilité du flux, pas sa modernité.
La gestion des erreurs
C’est le point que les démonstrations ignorent et que la production impose. Quatre règles :
- Aucun échec silencieux : toute erreur doit générer une alerte identifiée.
- Idempotence : rejouer un flux ne doit jamais créer de doublon.
- File de reprise : les éléments en échec sont conservés et retraitables.
- Réconciliation périodique : comparer les compteurs des deux côtés, au moins mensuellement.
La deuxième règle est celle dont l’absence coûte le plus cher : un flux rejoué sans protection produit des écritures en double, découvertes des semaines plus tard lors du rapprochement bancaire.
La sécurité
- Les jetons d’accès sont des identifiants : ils se stockent comme des mots de passe, jamais dans un fichier partagé.
- Le principe du moindre privilège s’applique : un connecteur qui lit n’a pas besoin d’un droit d’écriture.
- La rotation des accès doit être prévue, notamment au départ d’un prestataire.
- Les journaux d’accès doivent être conservés et consultables.
Ces exigences prolongent celles décrites dans notre article sur la sécurité des données comptables. Un connecteur mal configuré expose l’intégralité d’un référentiel client.
Ce qu’il faut vérifier chez un éditeur
- L’existence d’une documentation publique de l’API, signe de maturité.
- Les limites d’appel et leur compatibilité avec les volumes attendus.
- La politique de version : combien de temps une version reste-t-elle supportée ?
- Les connecteurs déjà existants vers les outils utilisés.
- La possibilité d’export complet des données, indépendamment de l’API.
Le dernier point relève de la réversibilité, traitée dans notre article sur le SaaS comptable et sa clause de réversibilité. Une API ne remplace jamais un export exhaustif.
Le projet, en pratique
- Cartographier les flux réels, y compris les fichiers échangés par courriel.
- Prioriser le flux le plus volumineux et le plus manuel : c’est là que le retour est immédiat.
- Nettoyer les référentiels avant de connecter — c’est l’étape la plus longue et la plus rentable.
- Tester sur un périmètre réduit, avec double contrôle pendant un mois.
- Documenter le flux : nature, fréquence, responsable, procédure en cas d’erreur.
L’étape 3 est systématiquement sous-estimée. Connecter deux référentiels sales revient à propager les doublons plus vite — sujet développé dans notre article sur la qualité des données comptables.
Ce que cela change pour le comptable
Le travail se déplace de la saisie vers le contrôle : vérifier les flux, traiter les exceptions, arbitrer les cas ambigus. C’est une évolution de fond, décrite dans notre article sur le métier de comptable à l’ère du numérique, et elle suppose des compétences différentes.
Des ressources sur la transformation numérique des TPE et PME sont publiées par France Num.
Questions fréquentes
Faut-il un développeur ?
Pas pour utiliser un connecteur existant. Un développement est nécessaire lorsque les outils ne se parlent pas nativement ou que les règles de gestion sont spécifiques.
Temps réel ou quotidien ?
Le quotidien suffit dans la plupart des cas comptables. Le temps réel se justifie pour la trésorerie et les stocks, où la fraîcheur de l’information change une décision.
Que faire si l’éditeur change son API ?
Anticiper : vérifier la politique de version avant de s’engager, et prévoir dans le contrat un délai de préavis avant l’arrêt d’une version.
Peut-on connecter deux outils de comptabilité ?
Techniquement oui, mais c’est rarement souhaitable : deux référentiels comptables divergent inévitablement. Mieux vaut désigner un système de référence.
Conclusion
Trois décisions font la réussite d’une intégration : désigner l’outil qui fait autorité sur chaque donnée, nettoyer les référentiels avant de connecter, et prévoir le traitement des erreurs. La technique, elle, est rarement le problème.