Quatre voies vers le même objectif
La décision est prise : fini la ressaisie manuelle des commandes entre les systèmes. Et c'est là que commence le second problème, dont on parle plus rarement. Un prestataire propose une intégration par API. Un autre assure qu'un export nocturne de fichiers CSV suffira. Une connaissance du secteur vante les robots RPA qui cliquent à l'écran à la place de l'humain, et comme une partie des documents arrive de toute façon en PDF, l'OCR est tentant lui aussi. Chacune de ces voies peut être la bonne. Aucune ne l'est partout.
Combien coûte la ressaisie elle-même et comment en mesurer l'ampleur, nous l'avons décrit dans l'article sur le nombre d'heures que votre équipe perd chaque semaine à transférer des données. Ici, nous partons du principe que ce calcul est déjà fait. Il est temps de choisir le mode de connexion.
L'API, ou la liaison directe
Les systèmes dialoguent entre eux par programme : une commande enregistrée dans l'ERP se retrouve dans le CRM quelques instants plus tard, sans intervention humaine. C'est la forme d'intégration la plus durable, car l'éditeur du système traite l'API comme un contrat officiel. Il annonce les changements, les documente et assure la rétrocompatibilité.
Une fourchette honnête pour un connecteur unique se situe généralement entre 2 et 6 semaines, et le coût dépend surtout du nombre de flux et de la qualité de la documentation des deux côtés. Disons-le franchement : au départ, l'API coûte plus cher qu'un dépôt de fichier, car elle exige du travail de développement et des tests. En contrepartie, sa maintenance est ensuite la moins chère des quatre voies.
L'export de fichiers, ou la simplicité à horaire fixe
Un système enregistre chaque nuit un fichier CSV ou XML, l'autre le charge au matin. Cela semble archaïque, et c'est parfois le choix le plus raisonnable : la mise en place prend de quelques jours à deux semaines et coûte le moins cher. Le prix de cette simplicité, c'est le délai. Les données circulent une fois par jour, et généralement dans un seul sens. Pour transmettre les factures à la comptabilité, cela suffit ; pour les niveaux de stock d'une boutique en ligne, non.
L'OCR, quand les données arrivent sous forme d'image
Des factures de centaines de fournisseurs, des procès-verbaux scannés, du papier. Un OCR doté d'une couche d'IA extrait les champs du document et les enregistre dans le système. Cette voie a du sens lorsqu'il n'y a rien à intégrer de l'autre côté, parce que les expéditeurs se comptent par dizaines et qu'on ne peut pas leur imposer un format. Le taux de réussite n'atteint jamais 100 %, la vérification des exceptions par un humain fait donc obligatoirement partie du déploiement. Délai réaliste : 3 à 8 semaines, selon la diversité des documents.
Le RPA, ou le robot qui clique comme un humain
Un script se connecte à l'application et reproduit dans l'interface les gestes qu'effectuait le collaborateur. L'avantage est évident : pas besoin d'API ni de l'accord de l'éditeur, et une démo fonctionnelle voit le jour en quelques jours. L'inconvénient aussi : le robot est soudé à l'apparence de l'écran. Une mise à jour du système déplace un bouton de 20 pixels et le flux s'arrête, souvent sans un bruit. À notre avis, le RPA devrait être la dernière option, pas la première, car le faible coût de départ se paie ensuite chaque mois en maintenance et en sueurs froides après chaque mise à jour.
Tableau comparatif
| Critère | API | Export de fichiers | OCR | RPA |
|---|---|---|---|---|
| Quand c'est pertinent | les deux systèmes disposent d'une API | données nécessaires une fois par jour | documents provenant de nombreux expéditeurs | système fermé, pas d'API |
| Délai de mise en œuvre | 2-6 semaines | de quelques jours à 2 semaines | 3-8 semaines | jours (démo), semaines (en production) |
| Coût de départ | moyen | faible | moyen à élevé | faible |
| Coût de maintenance | faible | faible, mais exige un responsable | moyen (vérification des exceptions) | élevé |
| Fragilité | faible | faible | moyenne | élevée |
| Fraîcheur des données | secondes | une journée | de quelques minutes à quelques heures | minutes |
Les trois pièges que nous voyons le plus souvent
Premier piège : le RPA sur une interface qui change. Si l'éditeur du système publie des mises à jour chaque trimestre, le robot tombera en panne chaque trimestre. Le budget consacré à sa surveillance peut dépasser le coût d'un connecteur API digne de ce nom.
Deuxième piège : l'export CSV sans responsable. Le fichier cesse de se générer, personne ne reçoit d'alerte et, pendant deux semaines, l'entreprise travaille sur des données périmées. Un export de fichiers doit avoir un responsable nommément désigné et une alarme automatique qui se déclenche quand le fichier n'arrive pas.
Troisième piège : l'OCR sur des documents qui pourraient arriver au format numérique. Si le partenaire émet ses factures dans un système doté d'une API ou via KSeF, lire ses PDF à la machine revient à payer pour un problème artificiel. Convenir d'un format d'échange coûte moins cher.
Un arbre de décision en quatre étapes
- Les deux systèmes disposent d'une API documentée ? Choisissez l'API. Le coût de départ plus élevé sera rentabilisé à la maintenance.
- Pas d'API, mais des données une fois par jour suffisent ? Export de fichiers, avec un responsable et une alarme.
- Les données arrivent sous forme de documents envoyés par de nombreux expéditeurs externes ? OCR, avec un processus de vérification des exceptions.
- Système fermé, éditeur non coopératif et données nécessaires en temps réel ? Alors seulement le RPA, avec un budget de maintenance et un plan de bascule vers l'API dès qu'elle sera disponible.
En pratique, les déploiements d'envergure combinent les voies : API entre l'ERP et le CRM, OCR pour les factures fournisseurs, export de fichiers vers l'entrepôt de données. C'est normal. L'essentiel est que chaque flux reçoive l'outil adapté à ses caractéristiques, et non l'outil favori du prestataire.
Comment nous procédons chez ESKOM AI
Chez ESKOM AI, le choix de la voie d'intégration fait partie de l'analyse, ce n'est pas un présupposé. Nous examinons les interfaces de vos systèmes, puis une équipe d'agents IA spécialisés effectue l'essentiel du travail d'ingénierie pour construire le connecteur, et l'ensemble passe une gamme complète de tests : unitaires, d'intégration, E2E, d'interface, de sécurité et de performance. Grâce à un processus de développement automatisé, nous parlons en semaines, pas en trimestres. Nous avons décrit le déroulement d'un tel projet, étape par étape, dans l'article sur la façon de connecter un ERP, un CRM et une application maison en quelques semaines.
Si vous hésitez entre l'une de ces quatre voies, réservez une consultation gratuite via le formulaire sur eskom.ai/pl/kontakt. Décrivez les systèmes que vous voulez connecter et la vitesse à laquelle les données doivent circuler — nous reviendrons vers vous avec la recommandation d'une voie précise et un devis honnête.