Vos capteurs voient beaucoup de choses. Un débitmètre relève la consommation chaque minute. Un contact de porte sait quand un congélateur a été ouvert. Un moteur signale des vibrations qui sortent de la plage normale avant la panne. Tout cela est réel, et la plupart n’atteint jamais les systèmes qui font réellement tourner votre activité. La facturation se fait dans un ERP. L’historique client vit dans un CRM. Le ticket de service est ouvert par une personne qui a entendu parler du problème des heures après que l’appareil le savait déjà.
Le travail consiste à refermer cette boucle. Quand un capteur détecte quelque chose, l’entreprise doit pouvoir agir : un relevé de consommation devient une ligne de facture, un défaut devient un ticket, un relevé d’équipement met à jour la fiche que votre équipe commerciale consulte. Cet article présente les schémas de connexion des données d’appareils aux systèmes ERP et CRM, les détails qui vous piègent si vous les ignorez, et la manière de procéder sur TagoIO avec la REST API, les scripts Analysis et les actions webhook.
Pourquoi relier les données d’appareils aux systèmes métier
Les données d’appareils seules, c’est de la supervision. Reliées à un système métier, elles deviennent de l’action.
Quelques exemples rendent la valeur concrète :
- Un compteur d’eau remonte sa consommation cumulée. Injectée dans l’ERP au moment du cycle de facturation, elle se transforme en une facture exacte, sans relevé manuel.
- Une machine émet un code de défaut. Transmis au CRM ou à un module de service terrain, il ouvre un ticket et affecte un technicien avant que le client n’appelle.
- Les heures de fonctionnement d’un équipement franchissent un seuil. La fiche de l’équipement se met à jour et un contrat de maintenance se déclenche au bon moment.
- Une installation à forte valeur cesse d’émettre. Le commercial qui gère ce compte reçoit une notification au lieu de l’apprendre lors de la prochaine revue trimestrielle.
Dans chaque cas, l’appareil savait déjà. Le manque, c’était de faire remonter ce signal jusqu’au système où quelqu’un pouvait agir.
Les schémas d’intégration
Il existe une poignée de schémas auxquels vous aurez recours, et la plupart des intégrations réelles en combinent deux ou trois.
Webhooks. La plateforme d’appareils pousse les données vers une URL quand un événement se produit. C’est le choix par défaut pour les événements : un défaut, un franchissement de seuil, un changement d’état. Le système destinataire reçoit la charge utile au moment où elle compte, et vous n’avez pas à interroger en continu.
REST API. Le versant “pull” de la même logique. Votre ERP ou CRM, ou un script intermédiaire, appelle un endpoint pour lire les données d’appareils à la demande ou selon un planning. Pratique pour la synchronisation par lots, comme récupérer une journée de relevés de compteurs à minuit, et pour tout système qui préfère demander plutôt que recevoir.
Middleware et iPaaS. Des outils comme n8n, Make ou un moteur de workflow s’intercalent entre la plateforme et le système métier. Ils gèrent les réessais, la transformation et le mapping délicat où les noms de champs d’un système ne correspondent pas à ceux de l’autre. Dès que vous avez plusieurs systèmes cibles ou que la logique se ramifie, le middleware garde cette complexité hors des deux extrémités.
Déclencheurs événementiels. Une logique qui s’exécute quand une condition est remplie plutôt qu’à intervalle régulier. Un relevé arrive, une règle l’évalue, et une action ne se déclenche que si la condition tient. Cela vous évite de bombarder le CRM à chaque relevé alors que seuls ceux qui franchissent une limite vous intéressent.
Mapping des données et points de synchronisation
C’est là que les intégrations cassent en silence. Le transport est la partie facile. Maintenir deux systèmes d’accord sur les mêmes faits, c’est la partie difficile.
Identifiants. Chaque appareil a besoin d’un mapping stable vers son homologue dans le système métier : un appareil vers une fiche d’équipement, un compteur vers un compte client, une machine vers un contrat de service. Décidez où vit ce mapping et faites-en la référence. Étiquetez l’appareil avec l’ID d’équipement de l’ERP, ou tenez à jour une table de correspondance que l’intégration consulte. Ce que vous ne voulez surtout pas, c’est faire correspondre sur des noms que quelqu’un renommera le trimestre prochain.
Fréquence. Adaptez la cadence de synchronisation au cas d’usage. Les relevés de facturation peuvent tourner une fois par jour. Les tickets de défaut doivent partir en quelques secondes. Les mises à jour d’heures de fonctionnement peuvent être horaires. Tout envoyer en temps réel est un gaspillage et vous fera atteindre les limites de débit du système cible. Envoyer trop lentement, c’est des fiches obsolètes.
Idempotence. Les réseaux réessaient. Si une livraison de webhook expire puis repart, vous ne voulez pas deux factures ni deux tickets en double. Donnez à chaque événement une clé unique sur laquelle le système destinataire peut dédupliquer, et concevez l’opération cible de sorte que la rejouer deux fois avec la même clé ne change rien la seconde fois.
Authentification et sécurité
Vous reliez une plateforme opérationnelle à des systèmes qui détiennent de l’argent et des données clients : les identifiants comptent donc.
Utilisez des jetons à portée limitée, pas des clés valables sur tout le compte. Le jeton qu’une intégration emploie pour pousser un relevé de compteur dans l’ERP doit pouvoir faire cela, et rien d’autre. S’il fuite, le rayon d’impact se limite à une opération, pas à tout votre compte.
Appliquez le moindre privilège des deux côtés. Côté TagoIO, ne lisez que les appareils dont l’intégration a besoin. Côté ERP ou CRM, n’acceptez les écritures que sur les objets concernés. Faites tourner les clés selon un planning et stockez-les là où elles ne traînent pas en clair dans un script. TagoIO est certifié ISO 27001 et aligné sur le GDPR, mais cette posture ne tient que si les identifiants que vous émettez suivent la même discipline.
Comment TagoIO se connecte aux systèmes ERP et CRM
TagoIO ne propose pas de bouton SAP ou Salesforce en un clic, et vous devriez vous méfier de toute plateforme qui prétend offrir un connecteur préconstruit pour chaque système d’entreprise. Ce que TagoIO vous donne, ce sont les briques pour câbler l’intégration vous-même, avec la logique là où vous pouvez la voir et la modifier.
La REST API. Chaque appareil, variable et donnée stockée est accessible via l’API. Un système externe, ou un iPaaS comme n8n, peut récupérer des relevés selon un planning et les pousser vers la destination. Votre intégration NetSuite peut appeler l’API TagoIO chaque nuit, lire la consommation du jour par compteur et créer les lignes de facture.
Les scripts Analysis. Ce sont des scripts serverless qui s’exécutent au sein de TagoIO, en Node.js ou Python. C’est généralement là que le vrai travail se passe. Un Analysis peut se déclencher à l’arrivée de données, évaluer une condition, transformer la charge utile dans la forme attendue par le système cible, et appeler directement l’API de l’ERP ou du CRM. Se connecter à HubSpot ou Salesforce se réduit à un appel HTTP depuis votre script vers leur API avec un jeton à portée limitée, plus la logique de mapping entre les deux. Comme il s’exécute dans la plateforme, vous n’avez pas à déployer de serveur pour l’héberger.
Les actions webhook. Les Actions TagoIO peuvent déclencher un webhook quand une condition est remplie. Une variable de défaut franchit un seuil, l’Action poste vers l’endpoint de votre service de support, et un ticket s’ouvre. Pour le travail événementiel où vous voulez un push à l’instant où quelque chose se produit, c’est le chemin le plus court. Associez-le à un Analysis quand la charge utile doit être remise en forme avant d’atteindre SAP ou votre CRM.
Une forme courante d’intégration réelle : une Action détecte l’événement, un script Analysis remet en forme et enrichit les données et gère l’idempotence, puis le script appelle la REST API du système d’entreprise avec un jeton à portée limitée. Cela couvre le cas défaut-vers-ticket, le cas consommation-vers-facture et le cas mise-à-jour-d’équipement, avec les mêmes trois briques disposées différemment.
Par où commencer
Choisissez une boucle aujourd’hui manuelle et refermez-la. Consommation-vers-facture et défaut-vers-ticket sont les deux qui rapportent le plus vite, parce qu’elles retirent une personne d’une tâche répétitive. Mappez d’abord les identifiants, décidez la fréquence de synchronisation, construisez l’Analysis qui fait la transformation, et testez l’idempotence en déclenchant volontairement le même événement deux fois. Une fois qu’une boucle fonctionne de bout en bout, le reste suit le même schéma.
