Skip to main content
Un ERP de production n’est jamais seul : les commandes arrivent d’une boutique en ligne ou de l’EDI d’un client, et la comptabilité vit dans un autre outil. Chaque ressaisie entre ces systèmes est du temps perdu et une source d’écarts. Les intégrations existent pour que la donnée ne soit saisie qu’une fois. Cette documentation couvre plusieurs familles d’outils : e-commerce, ERP, comptabilité, EDI, facturation électronique et outils no-code. Quatre principes sont communs à toutes, quel que soit l’outil branché.

1. L’origine de chaque donnée est tracée

Pour chaque enregistrement synchronisé, Bonx retient de quelle intégration il vient et sous quelle référence il y est connu. Ce lien est conservé à part, ce qui permet à une même fiche d’être connue de plusieurs outils avec une référence différente dans chacun. C’est ce qui rend les synchronisations idempotentes : rejouer un import ne crée pas de doublon, il retrouve et met à jour la fiche existante. C’est aussi ce qui permet, depuis une fiche Bonx, de savoir d’où elle vient.

2. Qui est maître de la donnée

C’est le point le plus délicat d’une intégration, et celui qui fait le plus de dégâts quand il reste implicite : si deux systèmes peuvent modifier le même article, lequel gagne ? Bonx tranche par un réglage explicite, par intégration et par type d’entité. Pour chaque couple, vous désignez le propriétaire : Le réglage étant par type d’entité et non global, vous pouvez laisser l’ERP maître des articles tout en restant maître des commandes et des factures. C’est ce qui rend tenable le cas difficile, une base articles partagée entre plusieurs systèmes, sans que deux outils se disputent la même fiche. Deux conséquences pratiques :
  • Rien ne se synchronise par défaut. Une intégration qui vient d’être créée ne touche à aucune donnée avant qu’un administrateur ait désigné un propriétaire, type d’entité par type d’entité.
  • La poussée manuelle passe outre. Pousser une fiche à la main fonctionne même sur un type dont l’outil connecté est maître, pour débloquer un cas particulier. C’est la seule entorse à la règle, et elle est journalisée.

3. Sécurité et secrets

Bonx se connecte avec la méthode la plus sûre offerte par l’outil cible : OAuth quand il existe, sinon clé d’API, identifiants dédiés ou dépôt de fichiers. Le détail est sur la page méthodes d’authentification. Les jetons, clés et identifiants sont chiffrés au repos avec une clé de chiffrement dédiée à votre instance, gérée par un service de gestion de clés et renouvelée périodiquement. Ils ne sont jamais relisibles une fois enregistrés, y compris par l’API : ils se remplacent, ils ne se consultent pas.

4. Quand la synchronisation se déclenche

Selon ce que l’outil connecté permet :
  • Périodiquement. C’est le mode de base. Les connecteurs les plus récents laissent régler l’intervalle par intégration, de quelques minutes à une fois par jour ; les autres tournent une fois par jour.
  • À la demande, en déclenchant une synchronisation depuis Bonx.
  • À l’étape d’un processus, quand un document atteint une étape qui doit être poussée vers l’outil, par exemple une facture validée. C’est la façon de synchroniser une fiche seule, sans attendre le prochain cycle.
Chaque exécution est journalisée : ce qui a été traité, ce qui a été rejeté et pourquoi. Un enregistrement rejeté est conservé avec son motif, pour être corrigé puis rejoué, plutôt que perdu en silence.
Toutes les intégrations supportées par Bonx ne sont pas encore documentées ici. Si l’outil que vous cherchez n’apparaît pas, demandez-nous : le connecteur existe peut-être déjà.