D'outil interne à SaaS : automatiser le téléchargement des relevés bancaires
Nous avons créé un script pour télécharger automatiquement nos relevés bancaires Wise. C'est une tâche d'un après-midi. La question plus intéressante — celle qui a pris beaucoup plus de temps à résoudre — était de savoir si le même outil pouvait servir d'autres entreprises confrontées au même problème, et ce qu'il faudrait pour réaliser cette transition de manière responsable. Le passage d'un script CLI tournant sur l'ordinateur portable d'un développeur à un service conteneurisé avec notifications par e-mail a mis en lumière un ensemble de décisions qui méritent d'être documentées, en particulier pour les équipes qui évaluent si une automatisation interne vaut la peine d'être transformée en produit.
Le problème initial
Wise fournit une API pour accéder aux données de compte, mais le flux de travail standard pour la plupart des équipes financières consiste à se connecter à l'interface web et à télécharger manuellement un CSV de relevé à la fin de chaque mois. Pour un seul compte avec une seule devise, cela prend deux minutes. Pour des opérations gérant plusieurs devises sur plusieurs comptes Wise — un modèle courant pour les entreprises avec des flux de paiement régionaux — cela devient une charge récurrente que quelqu'un doit mémoriser, exécuter de manière cohérente et archiver correctement.
L'API Wise expose les points de terminaison nécessaires. Vous pouvez récupérer une liste de profils, obtenir les soldes par devise, et demander des exports de relevés en CSV ou PDF pour n'importe quelle plage de dates. L'authentification se fait via un jeton d'accès personnel que vous générez dans le tableau de bord développeur de Wise. Le jeton a un accès en lecture seule aux données du compte lorsqu'il est correctement limité, ce qui signifie qu'il peut être stocké et utilisé sans le profil de risque d'un jeton qui pourrait initier des transferts.
Notre première implémentation comportait environ 80 lignes de Python. Elle lisait les credentials dans les variables d'environnement, itérait sur les profils et les soldes par devise, construisait des demandes de relevé pour le mois précédent, et écrivait les fichiers de sortie dans un répertoire local. Elle s'exécutait manuellement. C'était suffisant pour nos besoins à l'époque.
Du script au service planifié
Le passage de “s'exécute manuellement” à “s'exécute automatiquement” introduit une catégorie différente de préoccupations. Un script qui échoue silencieusement lorsqu'il est exécuté manuellement est remarqué immédiatement. Un script planifié qui échoue silencieusement le premier de chaque mois peut passer inaperçu pendant plusieurs mois, laissant une lacune dans vos archives de relevés que vous découvrez lors d'un audit.
Nous avons déplacé le script dans un conteneur Docker avec un point d'entrée simple et ajouté un wrapper qui envoie une notification par e-mail à la fin — succès ou échec. L'e-mail comprend un résumé des comptes et devises traités, du nombre de fichiers téléchargés et des tailles de fichiers. En cas d'échec, il inclut la sortie d'erreur. C'est un investissement minimal en observabilité mais il change le contrat opérationnel : l'automatisation est désormais supervisée même si elle s'exécute sans surveillance.
La planification est gérée par GitHub Actions, pas par cron à l'intérieur du conteneur. Nous utilisons un déclencheur schedule sur un workflow qui s'exécute le premier jour ouvrable de chaque mois. Le workflow extrait le dépôt, construit l'image Docker si elle a changé, exécute le conteneur avec les secrets injectés depuis GitHub Secrets, et télécharge les fichiers de sortie en tant qu'artefacts de workflow. Les artefacts sont conservés pendant 90 jours, fournissant une archive récupérable indépendante de tout stockage de fichiers local.
L'approche GitHub Actions présente un avantage pratique sur une tâche cron sur un serveur : elle est visible. L'historique des exécutions de workflow montre chaque exécution, sa durée, son code de sortie et les artefacts produits. Une tâche cron sur un serveur produit une sortie de journal facile à manquer et dépend de la disponibilité du serveur. Pour une tâche mensuelle, avoir un historique d'exécution auditable dans une définition de workflow versionnée vaut la petite charge supplémentaire de la configuration du workflow.
Ce que “multi-tenant” nécessite vraiment
Après que la version conteneurisée eut fonctionné de manière fiable pendant plusieurs mois, des collègues d'autres entreprises ont demandé s'ils pouvaient l'utiliser. La question semble simple : d'autres personnes peuvent-elles exécuter votre outil ? Mais en réalité, “d'autres personnes exécutent votre outil” couvre une large gamme de modèles opérationnels avec des implications très différentes.
Le modèle le plus simple : vous partagez le dépôt et la documentation, les autres l'exécutent eux-mêmes dans leur propre environnement GitHub Actions ou Docker, et vous ne fournissez aucun support. C'est la distribution open source. Ce n'est pas un produit SaaS. La charge opérationnelle est entièrement sur l'utilisateur.
L'étape suivante : vous hébergez l'outil et les utilisateurs fournissent leurs propres jetons API Wise via une interface de configuration. Vous détenez maintenant des credentials. Cela crée immédiatement des obligations de sécurité et de conformité qualitativement différentes de l'exécution d'une automatisation personnelle. Vous devez répondre : comment les credentials sont-ils stockés, qui y a accès, que se passe-t-il si le stockage est compromis, et quelle est votre responsabilité si le compte Wise d'un utilisateur est accédé via votre plateforme ?
L'étape suivante implique la facturation, le support, les engagements de niveau de service et la charge opérationnelle de l'exploitation d'une infrastructure pour plusieurs utilisateurs. Aucun de ces points n'est insurmontable, mais chacun nécessite une décision sur la quantité d'investissement en ingénierie que vous êtes prêt à faire et le coût opérationnel récurrent que vous êtes disposé à supporter.
L'évaluation SaaS
Nous avons conduit l'évaluation en listant les exigences d'une version multi-tenant minimale et en chiffrant chacune honnêtement. La gestion des credentials seule — stocker les jetons API Wise en sécurité, fournir une interface pour les gérer, et implémenter les contrôles d'accès pour prévenir l'accès inter-tenants — représente une semaine de travail d'ingénierie avant même de toucher à la fonctionnalité réelle de téléchargement de relevés. Ajoutez l'authentification des utilisateurs, la facturation, un service de livraison d'e-mails avec gestion des désabonnements, et la surveillance des échecs de tâches par tenant, et vous avez un produit qui nécessite un investissement soutenu pour être maintenu en toute sécurité.
Le marché de cet outil spécifique est aussi limité. Les entreprises suffisamment grandes pour se soucier d'automatiser les téléchargements de relevés sont souvent suffisamment grandes pour avoir un logiciel de comptabilité qui s'intègre directement avec Wise, ou des équipes financières qui ont déjà résolu le problème par leurs propres moyens. Le marché adressable est celui du milieu — les entreprises suffisamment grandes pour ressentir la douleur mais n'utilisant pas encore de systèmes comptables intégrés.
Nous avons conclu que l'outil n'était pas un bon candidat SaaS pour notre équipe à ce stade. Le potentiel de revenus par rapport à l'investissement en ingénierie et opérationnel ne le justifiait pas. Le modèle de distribution open source répond au besoin réel sans créer d'obligations que nous ne pouvons pas soutenir.
Ce que nous avons conservé et ce que nous avons changé
L'outil interne fonctionne toujours. Nous l'avons étendu au fil du temps pour prendre en charge la sortie PDF en plus du CSV, pour envoyer les fichiers de relevés directement à une adresse e-mail plutôt que de s'appuyer sur la récupération d'artefacts de workflow, et pour prendre en charge des plages de dates configurables afin qu'il puisse être déclenché manuellement pour des demandes de relevés ponctuelles sans modifier l'exécution mensuelle planifiée.
Le workflow GitHub Actions est devenu le mécanisme de déploiement canonique. Nous le documentons dans le README du dépôt avec suffisamment de détails pour que quelqu'un qui n'a pas touché à l'outil depuis six mois puisse comprendre ce qu'il fait et comment l'exploiter. C'est une discipline qui vaut la peine d'être appliquée à toute automatisation interne : traitez vos outils internes comme si vous deviez les transmettre à quelqu'un d'autre, car c'est éventuellement ce qui arrivera.
La leçon la plus durable de ce projet concerne l'écart entre “cela fonctionne pour nous” et “cela fonctionne pour les autres.” Les outils internes sont adaptés à vos contraintes spécifiques : vos pratiques de gestion des credentials, vos conventions de stockage de fichiers, votre infrastructure e-mail. Les rendre suffisamment génériques pour que d'autres puissent les utiliser n'est pas seulement une question d'ajout d'un fichier de configuration. Cela nécessite d'abstraire des hypothèses que vous ne saviez même pas être des hypothèses jusqu'à ce que quelqu'un d'autre essaie d'utiliser l'outil et les rencontre.