Passerelle : relier ses logiciels sans les exposer
Passerelle reçoit un message sur une adresse sécurisée, le transforme comme on le souhaite, puis le renvoie vers un ou plusieurs services : Slack, CRM, support, tableur, serveur de fichiers ou API sur mesure.
État : version 0.22.0, développée et validée en interne. Le service n’est pas encore ouvert au public : aucun lien d’accès n’est donc proposé.
Contexte et problème résolu
Les outils d’une entreprise ne se parlent pas toujours : un avis négatif devrait alerter l’équipe, une demande de contact créer une fiche dans le CRM, un export arriver chez un partenaire. Chaque liaison demande un développement, un serveur à surveiller et des secrets à protéger, puis elle peut casser sans bruit.
Passerelle prend en charge cette plomberie : réception sécurisée, transformation, livraison avec reprises automatiques, historique et alertes. Elle vise les équipes marketing, support, produit et techniques de PME qui veulent automatiser sans maintenir de serveur, et les intégrateurs qui gèrent plusieurs clients (une organisation par client).
Comment ça fonctionne
- Un flux = une adresse d’entrée sécurisée + des étapes de transformation + des destinations. L’entrée est protégée par un jeton (deux au plus, avec rotation sans coupure), une signature facultative et une liste d’adresses autorisées.
- Des étapes : filtre (abandonner un message), champs (ajouter ou modifier), correspondance (reformater) et script Python libre, exécuté dans un bac à sable. Les formats JSON, XML, SOAP, formulaire et CSV sont gérés en entrée comme en sortie.
- Des connecteurs prêts à l’emploi : Slack, Discord, Microsoft Teams, Google Chat, WhatsApp, e-mail, Airtable, HubSpot, Intercom, Zendesk, Pipedrive, Google Sheets, SFTP et requête HTTP générique, plus des connecteurs personnalisés avec brouillon, trois versions antérieures et retour arrière.
- Fiabilité : reprises automatiques espacées jusqu’à environ 12 heures, relance manuelle, explication de chaque erreur en français, essai à blanc, essai réel confirmé et environnements de test des services qui en proposent.
- Alertes, surveillance et pilotage : condition d’envoi par destination, surveillance de sites (port, réponse HTTP interprétée, certificat), écran de supervision classé par gravité et rapports exportables en CSV.
- Facturation à la consommation : des lots de crédits plutôt qu’un abonnement ; les filtres et les champs sont gratuits, un échec ne coûte rien.
Choix techniques et architecture
- Stack : la même base que Boussole (API Python avec FastAPI, PostgreSQL, tâches Celery et Redis, interface Next.js 16). Le moteur de transformation (chemins, gabarits, conditions, signatures) n’utilise que la bibliothèque standard, sans exécuter de code pour les gabarits.
- Exécuter le code d’autrui : le script d’un client tourne dans un processus enfant à environnement vide, aux limites de temps et de mémoire strictes, au code analysé et aux modules importables en liste fermée. En production, il est confié à un service dédié : conteneur sans réseau, en lecture seule, sans privilèges. Un script qui s’échapperait de Python se retrouverait dans un conteneur vide.
- Isolation et secrets : chaque organisation est un espace isolé ; les secrets (clés d’API, mots de passe) sont chiffrés et jamais réaffichés ; les appels sortants sont verrouillés sur le domaine du service et protégés contre les requêtes serveur détournées.
- Données minimales : le contenu d’un message est effacé après traitement (conservé chiffré sept jours seulement en cas d’échec, pour permettre la relance) ; l’historique, sans contenu, dure 30 jours.
- Déploiement par conteneurs : Docker Compose avec reverse proxy ; métriques d’exploitation (format Prometheus) sans aucune donnée client, et alerte à l’exploitant en cas de retard de traitement.
- Tests : tests unitaires, d’intégration sur PostgreSQL et serveur SFTP réels, tests d’interface et parcours navigateur.
Difficultés et enseignements
- Autoriser du Python libre sans risque : la sécurité repose sur plusieurs couches successives plutôt que sur une seule protection, avec une hypothèse de travail claire : le script est un code étranger.
- Le débit : sur un poste de développement, avec un flux à trois étapes dont un script, 100 messages et un seul worker, le débit de traitement est passé de 4,5 à 14,7 messages par seconde, et le délai médian de 10,2 s à 1,6 s. Deux corrections ont suffi : traiter la file tant qu’elle n’est pas vide, et charger les modules du script à la demande.
- Lire du XML en sécurité : la bibliothèque standard est vulnérable aux entités externes et aux bombes d’expansion ; la lecture passe par une petite bibliothèque dédiée qui les refuse.
- Changer de modèle de facturation : l’abonnement a été remplacé par des crédits ; la migration de données associée est volontairement non réversible.
- Des adresses IP falsifiables : les en-têtes de transfert ne sont acceptés que du réseau du proxy, sans quoi la liste d’adresses autorisées d’un flux pourrait être contournée.
- Limites assumées : pas d’éditeur visuel pour les champs d’un connecteur personnalisé (saisie en JSON), rapports limités à 30 jours, « ping » réalisé comme un test de port TCP.
État d’avancement honnête
À ce jour, la feuille de route 0.10 à 0.17 est terminée et les versions se sont poursuivies jusqu’à la 0.22.0 (supervision, filtres et exports de rapports, métriques d’exploitation, alertes, formats XML et CSV, connexions et lectures d’API planifiées).
Ce qui reste à faire avant une ouverture : renseigner les comptes de services tiers (messagerie transactionnelle, paiement), faire valider le texte de confidentialité et fixer les montants des lots, aujourd’hui provisoires. Les contrôles de qualité tournent en local ; aucune date d’ouverture n’est annoncée.
Ce que ça montre de mon travail
- Concevoir une plateforme d’intégration qui manipule des données et des secrets de tiers, avec la sécurité comme point de départ.
- Mesurer avant d’optimiser, et documenter les gains obtenus.
- Réutiliser une base éprouvée (celle de Boussole) tout en vérifiant la cohérence des parties copiées entre projets.
- Rédiger des documents pour chaque public : présentation commerciale, guide d’utilisation, documentation fonctionnelle, notes de version, exploitation.
Pour relier vos propres logiciels sur mesure, voir aussi l’automatisation de flux.
Des logiciels à relier ?
Décrivez vos outils et le flux souhaité : je vous dis comment je peux vous aider.