R&D / Produit Hivelin
PipeIt — Industrialisez vos intégrations clients
Un modèle d’intégration versionné, des instances isolées par client, des secrets séparés : pour déployer et maintenir le même type de liaison chez plusieurs clients sans recopier des scénarios fragiles.
Le problème
Vous devez connecter les mêmes systèmes chez plusieurs clients (ERP ↔ transporteur, CRM ↔ outil métier, catalogue ↔ commandes…). Recopier un scénario Make/Zapier ou un script par client devient vite ingérable : corrections à répéter, versions divergentes, secrets mélangés, pas de rollback propre.
Pour qui
Éditeurs, intégrateurs et équipes plateforme qui vendent ou opèrent des intégrations B2B récurrentes — pas un usage ponctuel « automatiser mon inbox ».
Quand c’est pertinent
- Le même type d’intégration revient chez plusieurs clients ou sites
- Vous devez faire évoluer le modèle sans forcer tout le monde le même jour
- Les identifiants et mappings doivent rester isolés par client
- Vous voulez un suivi d’exécutions et un portail client limité
Comment c’est vendu
PipeIt peut être proposé seul (licence / hébergement), ou en PipeIt + intégration + exploitation : conception du modèle, branchement API, mise en production et suivi. Un seul interlocuteur côté Hivelin.
Ce n’est pas « copier un workflow par client ». C’est un modèle central versionné, des instances épinglées à une version, et des upgrades / rollbacks maîtrisés.
- Modèle versionné
- Instance épinglée
- Secrets client
- Exécution isolée
- Upgrade / rollback
Modèle vs instance : version épinglée, pas une copie
On définit un modèle de workflow versionné (v1, v2, v3…) — par exemple « commande → transporteur → tracking ERP ». Ensuite, on crée une instance par client, chacune épinglée à une version précise du modèle, avec ses propres identifiants et mappings. Quand le modèle évolue, on choisit quelles instances montent en version (upgrade contrôlé) et lesquelles restent sur l'ancienne — avec possibilité de retour en arrière (rollback) si besoin.
-
Modèle (versionné)
Commande → transporteur → ERP Une source de vérité versionnée (v1, v2…), pas une copie par client. -
Instance client A
Épinglée modèle v2 Credentials + mappings A. Espace isolé, secrets chiffrés, exécutions journalisées pour ce client uniquement. -
Instance client B
Épinglée modèle v1 Même modèle, autre version. Upgrade vers v2 quand prêt — rollback possible.
Fonctionnalités
- Éditeur visuel de workflows Les scénarios se construisent en graphe, à l’écran, nœud par nœud.
- Appels API, conditions, transformations HTTP / API, branches, traitements parallèles, e-mail, SFTP et SQL — sur les API de vos systèmes.
- Isolation des clients Chaque client a son espace. Les secrets sont chiffrés et gérés à part.
- Déclenchement souple Manuel, webhook entrant, ou planification automatique (cron).
- Portail client Un accès limité pour suivre les exécutions et piloter ce qui a été autorisé.
- Suivi et journalisation Historique des exécutions, statuts, traces.
- Droits et authentification Comptes opérateurs, rôles, accès renforcés.
- Modèles versionnés Instances épinglées à une version du modèle ; mises à niveau et retours en arrière contrôlés.
Exemple de graphe — commande → tracking ERP
Exemples d’utilisation
Des cas métier typiques pour une PME, un intégrateur ou une équipe plateforme qui veut industrialiser ses intégrations en s’appuyant sur les API des outils déjà en place.
-
Logistique
Connectez les API de votre ERP et de votre transporteur
Une commande validée déclenche, via leurs API, la création d’expédition chez le transporteur. Le tracking remonte ensuite dans l’ERP. Même modèle pour plusieurs dépôts ou filiales, avec des comptes et paramètres isolés par instance.
Pourquoi ça se paie : moins de saisie manuelle, moins d’erreurs d’expédition, un suivi homogène sans reconstruire l’intégration à chaque site.
-
Commercial & admin
Orchestrez les API de votre CRM et de votre outil métier
Un client validé dans le CRM déclenche, via API, l’ouverture d’un dossier, une facturation ou une notification dans l’outil métier. Les règles restent dans le modèle ; chaque entité garde ses identifiants et ses destinataires.
Pourquoi ça se paie : le passage « gagné » dans le CRM ne reste plus bloqué sur un e-mail ou une saisie double — le process avance sans intervention.
-
Éditeur / intégrateur B2B
Un modèle d’intégration, des instances clients versionnées
Un même workflow (catalogue fournisseur, sync commandes, stock…) orchestre les API fournisseur et client. Chaque instance a ses credentials et ses mappings ; le modèle évolue au centre, chaque déploiement reste épinglé à une version avec upgrade / rollback contrôlés.
Pourquoi ça se paie : on industrialise une intégration récurrente, au lieu de recopier des scénarios fragiles client par client.
Architecture technique
Architecture séparant API, workers et interface web, avec PostgreSQL et Redis / BullMQ pour le traitement asynchrone. Déploiement conteneurisé (Docker, Kubernetes), CI automatisée, tests. Conception, tests, recette et hébergement : je m'en occupe aussi.