Connector
J’ai construit Connector à la suite de demandes de clients : migrer les données d’un site vers un autre, à l’occasion d’une mise à jour. Le besoin revenait assez souvent pour mériter un outil plutôt qu’un script de plus à chaque fois.
Mon expérience des CMS m’a donné la connaissance approfondie qu’il fallait pour le rendre simple des deux côtés : simple pour les développeurs grâce à des diagrammes, où le flux se lit d’un coup d’œil, et simple pour les clients grâce à un assistant de configuration qui crée une configuration de base à partir de leurs besoins.
Le programme sait aussi bien migrer les données en une fois que les synchroniser dans la durée, entre deux applications : gestion commerciale, CRM, boutique en ligne, marketplace ou site vitrine. Chaque application connectée est déclarée avec ses accès, ses identifiants et ses réglages d’envoi : WordPress, PrestaShop, Shopify, Wix, Magento, WooCommerce, Sage, Divalto, Zoho, ou toute application exposant une API. Un profil de transfert lie ensuite deux connexions et regroupe tous les échanges qui les font vivre.
J’ai mis les flux sur un canvas : on positionne les nœuds source et destination, on les relie, on organise des groupes de règles en glisser-déposer. Les règles de modification transforment les champs en transit, sans écrire de code : ajouter, modifier, remplacer, opérations mathématiques, mise en forme de date.
Un transfert se lance à la main, se programme en tâche récurrente ou se déclenche à distance par webhook. Connector interroge le Swagger/OpenAPI des connecteurs pour vérifier leur disponibilité et alerter dès qu’un schéma distant change, journalise chaque exécution avec son statut (réussi, échec, partiellement réussi, arrêté) et trace exécutions, modifications et suppressions dans un historique d’audit conforme au RGPD, dont les détails sensibles demandent une reconfirmation du mot de passe.
Aujourd’hui, tous les échanges passent par des liaisons API. L’outil a été construit pour qu’en ajouter d’autres soit l’affaire de peu de temps.
D’une migration de site à un outil
Les premières demandes étaient des migrations : reprendre les données d’un site pour les verser dans un autre, au moment d’une mise à jour.
Plutôt que de réécrire un script à chaque fois, j’ai fait de ce besoin un outil, capable de migrer en une fois comme de synchroniser en continu.
Simple pour le développeur, simple pour le client
Côté développeur, tout se lit en diagrammes : la source, la destination, les règles qui les séparent.
Côté client, un assistant de configuration pose les questions utiles, sans compétences techniques : choix de l’application, connexion, authentification, version d’API. Il en sort une configuration de base correspondant au besoin.
L’éditeur visuel de flux
Le flux se compose en trois temps : choisir la source et les champs à synchroniser, appliquer les règles de transformation, puis associer chaque champ à son homologue dans la plateforme de destination.
Tout se fait au glisser-déposer sur un canvas, nœuds et groupes de règles compris.
Le déclenchement et la surveillance
Un transfert se lance manuellement, se programme en tâche planifiée récurrente ou se déclenche à distance depuis un webhook.
La détection de schéma interroge le Swagger/OpenAPI des connecteurs et alerte dès qu’une plateforme distante change son API, avant que les synchronisations n’en pâtissent.
Les journaux et l’audit
Chaque exécution est journalisée avec son statut précis (réussi, échec, partiellement réussi, arrêté) et filtrable par période.
L’historique d’audit conserve exécutions, modifications et suppressions ; l’accès aux détails sensibles demande une reconfirmation du mot de passe, dans une application hébergée en France.
Des liaisons API, et de la place pour les suivantes
Toutes les liaisons en service aujourd’hui sont des liaisons API.
L’architecture a été pensée dès le départ pour en ajouter d’autres rapidement, sans reprendre ce qui existe.
