Automatiser la chaîne mensuelle de l’ERP à la consolidation pour un groupe multi-entités

Contexte

Un groupe de concessionnaires comptant plusieurs entités légales consolide ses comptes dans CCH Tagetik. Chaque mois, la balance de vérification de chaque entité doit sortir de l’ERP infonuagique, être retravaillée selon les règles comptables du groupe et atterrir sur le serveur SFTP de la plateforme de consolidation sous forme de fichier plat. Avant FinSync, cette chaîne vivait dans un ensemble de flux d’automatisation infonuagiques : un jeton d’API conservé dans un fichier, rafraîchi par un autre flux, et un CSV assemblé étape par étape — fonctionnel, mais opaque, difficile à modifier et dépendant de la personne qui l’avait bâti. J’ai proposé de le remplacer par une application dédiée que l’équipe des finances pourrait exploiter elle-même : connecter l’ERP, tenir les entités, planifier les exécutions, lire les journaux et renvoyer un fichier sans appeler un développeur.

Défi

Reproduire exactement le flux existant — son résultat, validé par l’équipe des finances, ne devait pas changer — tout en supprimant ses fragilités. L’API de l’ERP émet des jetons de rafraîchissement à usage unique : une rotation perdue et toute la chaîne s’arrête. La plateforme de consolidation n’accepte les connexions SFTP que d’adresses autorisées, ce qu’une architecture sans serveur ne possède pas. Les règles comptables ne sont pas triviales : soldes de clôture pour certaines classes de comptes, mouvements de la période pour d’autres, comptes de taxes listés, et un calcul des bénéfices non répartis dont le compte diffère d’une entité à l’autre, notamment pour les entités acquises après une migration de l’ERP vers le nuage. Et le tout devait tourner sans surveillance, sur planification, dans le fuseau et le calendrier fiscal du groupe, avec un compte rendu par courriel.

Mon rôle

Fondateur et architecte du produit : j’ai défini la portée, conçu l’architecture d’intégration et le modèle de données, spécifié les règles comptables avec l’équipe des finances et dirigé les travaux techniques, réalisés par mon équipe chez SOFT M POWER CANADA avec une plateforme de développement assistée par l’IA. Je rédige aussi les plans de changement pour les ajustements en production — profils en parallèle, exécution de comparaison, bascule réversible, nettoyage différé — et je reste l’interlocuteur technique de l’équipe des finances du groupe. La plateforme est exploitée par mon équipe.

Architecture / approche

Prendre en charge toute la chaîne dans une seule application plutôt que d’assembler des services. Un module de connecteur regroupe OAuth, rotation des jetons et appels d’API. Une exécution est un objet de premier ordre : elle enregistre ses paramètres, le statut de chaque entité et trois niveaux de données — réponse brute de l’API, lignes normalisées, lignes finales après les règles —, pour que tout fichier se retrace et se recalcule. Les règles de transformation sont du code déterministe, versionné avec l’application, et non des réglages modifiables sans trace. La livraison est un objet de transfert distinct avec son propre statut : un dépôt échoué se renvoie sans réextraire. Le planificateur évalue les expressions cron par fuseau horaire et déclenche les exécutions sans les attendre; chacune se termine par un compte rendu courriel par entité.

Technologie

Interface React et TypeScript; Postgres géré avec une table de rôles dédiée vérifiée par des politiques au niveau des lignes et par une fonction à privilèges définis; douze fonctions sans serveur en TypeScript sur Deno pour l’extraction, le rafraîchissement des jetons, la planification, le dépôt SFTP, les notifications et l’administration des utilisateurs; stockage objet privé pour les fichiers générés; un planificateur côté base de données qui réveille l’orchestrateur chaque minute; SFTP sur SSH avec tunnel SOCKS5 optionnel vers une adresse de sortie fixe; courriel transactionnel par l’API d’un fournisseur; OAuth 2.0 auprès de l’API Sage Business Cloud Accounting. Vingt-huit migrations, dix-neuf tables et sept types énumérés décrivent le modèle; un wiki intégré documente pour les administrateurs l’architecture, la procédure OAuth, la configuration SFTP et le format de fichier.

Exécution

L’essentiel de la plateforme a été bâti en mars et avril 2026 — plus de 430 commits —, en commençant par le connecteur ERP, où le jeton à usage unique a coûté une trentaine de commits en quatre jours. Le pipeline CSV a reproduit l’ancien flux étape par étape; le calcul des bénéfices non répartis a ensuite été corrigé six fois en une semaine avec l’équipe des finances. Le SFTP est passé par trois conceptions avant le tunnel à adresse fixe, et la récupération de mot de passe a été rebâtie autour d’un code à usage unique. En juillet, une deuxième phase a resserré les permissions de planification et corrigé deux défauts du planificateur : des exécutions restées en file parce que le processus attendait l’extraction, et un calcul du prochain passage qui dépassait le budget CPU de la fonction.

Contraintes

Un résultat identique au fichier validé, jusqu’à l’ordre des colonnes et à l’encodage. Aucune adresse fixe côté sans serveur, et une cible SFTP qui en exige une. Des jetons de rafraîchissement à usage unique sans tolérance pour une rotation manquée. Des fonctions limitées en temps d’exécution et en CPU, ce qui a façonné à la fois le déclenchement sans attente et l’algorithme du prochain passage. Un calendrier fiscal qui ne suit pas l’année civile. Une instance dédiée par organisation : le déploiement est mono-organisation, en français, et les règles comptables sont versionnées dans le code plutôt qu’exposées comme réglages — un compromis délibéré entre souplesse et auditabilité. Aucun volume, délai ou montant de production n’est publié ici.

Leçons clés

1. Quand on remplace une automatisation qui fonctionne, on reproduit d’abord son résultat et on améliore ensuite son architecture — la confiance de l’équipe des finances est dans le fichier, pas dans le code.
2. Les jetons à usage unique font de chaque rotation une transaction : stocker, faire tourner et réessayer au même endroit, et donner aux opérateurs un chemin de reprise.
3. Le sans serveur n’a pas d’adresse fixe; un tunnel de sortie à adresse fixe coûte moins cher qu’un serveur.
4. Conserver les données brutes, normalisées et finales de chaque exécution — c’est la traçabilité qui rend un pipeline déterministe auditable.
5. Un planificateur qui attend la tâche qu’il déclenche finira par être tué par la plateforme : déclencher, ne pas attendre, et enregistrer.