Dossier de consultation / DAF et DSI
Connecteur ERP : choisir entre API et EDI
Comparez API, EDI et connecteur natif pour raccorder votre ERP à une plateforme agréée, avec responsabilités et tests à demander au devis.
Mis à jour le .
Partir des interfaces réellement disponibles
Une API présente dans une brochure ne prouve pas que votre installation peut exporter une facture validée et recevoir ses événements. Relevez la version de l’ERP, les modules activés, les extensions et les interfaces autorisées par votre contrat. Demandez un exemple de message issu de votre environnement de test. L’objet à exporter doit correspondre à la facture comptabilisée, avec ses lignes et ses références, plutôt qu’à un écran de saisie encore modifiable.
Un export de fichiers peut convenir si la fréquence des traitements et le retour des erreurs correspondent à vos besoins. Une API peut faciliter les échanges plus fréquents, mais son exploitation demande une gestion des droits et des appels. Le choix doit être expliqué au regard du processus comptable. Un connecteur natif mérite les mêmes vérifications qu’une intégration tierce : version supportée, flux couverts, limites et maintenance.
Comparer les architectures sur un même scénario
Soumettez aux candidats une facture de vente, une facture fournisseur et un avoir représentatifs. Demandez où sont effectués le mapping, la validation et la conversion de format. Un middleware peut centraliser ces fonctions entre plusieurs applications ; il introduit aussi un composant à exploiter. Une connexion directe limite le nombre d’intermédiaires, mais peut multiplier les adaptations si plusieurs ERP utilisent des règles différentes.
Pour un échange de fichiers, précisez la convention de nommage, le dépôt sécurisé, les accusés et la distinction entre fichier reçu et facture acceptée. Pour une API, demandez la pagination, les limites d’appels, l’authentification et le comportement en cas de réponse tardive. Une documentation datée et un environnement de recette valent davantage qu’une simple déclaration de compatibilité.
Attribuer les responsabilités de bout en bout
L’intégrateur intervient sur le raccordement, tandis que la plateforme assure son propre service de transmission. L’entreprise reste responsable de son processus et de la qualité des données qu’elle produit. Faites décrire contractuellement la frontière entre chaque composant.
Une facture bloquée à la sortie de l’ERP et une facture rejetée après transmission ne relèvent pas nécessairement du même support. Le tableau d’exploitation doit indiquer qui reçoit l’alerte, qui corrige la donnée et qui autorise la reprise. Désignez aussi le responsable de la consultation des journaux. Sans cette répartition, un ticket peut circuler entre fournisseurs alors que la comptabilité ne sait toujours pas si le client a reçu le document.
Tester les reprises sans créer de doublons
La perte d’une réponse réseau est un cas essentiel. Le système peut avoir transmis la facture sans avoir reçu l’accusé. Exigez un mécanisme de rapprochement avant toute nouvelle émission. La clé de corrélation doit permettre de retrouver le document dans l’ERP, le connecteur et la plateforme. Une relance technique ne doit pas être assimilée à une nouvelle facture commerciale.
Testez également une expiration de droit, un fichier incomplet et une interruption pendant un lot. La recette doit montrer comment les documents déjà traités sont distingués de ceux qui restent à reprendre. Gardez les preuves de chaque scénario avec l’état final comptable.
Préparer les questions de consultation
Demandez le coût de chaque interface, celui des environnements et celui des changements de version. Vérifiez si le devis inclut les flux entrants, les statuts et les données de reporting, ou uniquement l’émission d’un fichier. Décrivez les périodes de forte activité et les contraintes de clôture, sans annoncer un volume que vous n’avez pas mesuré.
Une démonstration doit être reproductible par votre équipe. Faites remettre la configuration, le dictionnaire de champs et la procédure de support. La possibilité de changer de plateforme dépendra aussi de ces livrables. Ne validez pas le raccordement sur la seule présence d’un bouton « envoyer » dans l’ERP.
Grille à joindre à la consultation
| Point | Preuve à demander |
|---|---|
| ERP | Identifie la facture validée et fournit les références métier ; le traitement d’une correction reste documenté. |
| Connecteur | Transforme le message, conserve la corrélation et sépare erreur technique et anomalie de données. |
| Plateforme | Retourne les réponses utiles au suivi ; ses interfaces et formats supportés sont identifiés dans le contrat. |
| Comptabilité | Décide de la correction commerciale et contrôle l’état du document avant une reprise autorisée. |
| DSI | Gère les accès, l’environnement de test et les alertes, avec un interlocuteur désigné chez chaque fournisseur. |
Livrable attendu
Le dossier de choix comporte un schéma des composants, un exemple de facture exportée et une preuve de reprise après interruption. Joignez la matrice des responsabilités et la liste des flux exclus. Faites répondre chaque candidat à ces mêmes pièces pour comparer les offres sur un périmètre identique. Si une fonction dépend d’un module à acquérir ou d’une montée de version, elle doit apparaître comme une dépendance explicite plutôt que comme un acquis de la solution.