Définition de payment factory
Une Payment Factory est une solution dédiée aux cadres des métiers financiers, et plus précisément des équipes Trésorerie. Ce type de logiciel a pour objectif de réaliser la centralisation de tous les paiements d’une entreprise et s’est particulièrement imposé avec l’avènement de SEPA. On peut également employer l’expression Plateforme de paiement ou de centralisation de paiement le concernant.
Cette typologie de progiciels séduit essentiellement les trésoriers des grands groupes. En effet, ces progiciels sont souvent trop sophistiqués pour les petites entreprises, dans la mesure où elles ne gèrent pas une multitude de flux et de paiements au quotidien, ce pour quoi est designé en premier lieu l’outil.
Avez-vous vu cela : Le décollage de votre carrière avec la formation de création de site internet financée par le CPF
Les grands comptes sont en effet composés de nombreuses sociétés basées dans de multiples pays et ont pour objectif de rationnaliser le travail et les flux émanant de leur département trésorerie. Pour y parvenir, ils adoptent le plus souvent l’une des stratégies suivantes :
- flux de travail local : import ou saisie manuelle des écritures via la société fille et la communication bancaire
- flux de travail à 2 niveaux : importation ou saisie des entrées via la société fille suivi de la transmission à la centrale de trésorerie qui approuve/refuse le paquet|homologue/rejette|approuve/refuse le lot de passer à la communication bancaire
- workflow central : toutes les étapes se situent au niveau de la trésorerie centrale, depuis la création du paiement à son envoi aux banques
A voir aussi : Qu’est-ce qu’un logiciel de prospection téléphonique ?
Payment factories et logiciels mixtes
La payment factory peut être incluse dans des suites logicielles regroupant un panel de progiciels dédiés aux trésoriers, voire aux DAF et aux comptables.
Les différents métiers étant complexes et les connexions entre les différentes responsabilités des trésoriers étant souvent peu manifestes, ces suites de logiciels sont rares. Le logiciel chargé de grouper les paiements est alors accolé à d’autres solutions dédiées :
- le TMS, aussi appelé smart TMS (Treasury Management System) ou TRM (Treasury and Risk Management) qui permet, selon son approche, de manager toutes les tâches de trading groupe, en commençant par de la décision de constitution de l’opération financière (Front Office) à sa comptabilisation (Back Office) en passant par le contrôle (Middle Office) et le management des risques financiers qui en découlent
- le rapprochement banque-comptabilité (matching automatique des extraits bancaires et des écritures)
- le logiciel de trésorerie « basique » (fiches en valeur, trésorerie quotidienne, réconciliation réalisations-prévisions, gestion des SICAV, netting, prévisions court / moyen /long terme de trésorerie…)
Payment factory ou Collection factory ?
L’expression « payment factory » est limitative, ne couvrant que la moitié des activités de cette catégorie de logiciels professionnels. Effectivement, l’application se doit de traiter et de centraliser dans le même temps les paiements de la société, et aussi ses encaissements. On devrait donc plutôt employer le terme de « payment et collection factory » ou « module de paiement et encaissement ».
De fait, les flux financiers et paiements traités dans les payment factories incluent une forte diversité de moyens de paiement et de types comptables, dépendant du marché du groupe, de ses clients et de ses options stratégiques :
- virements (de masse, RH et payes, approvisionneurs, divers…)
- prélèvements (TIP, prélèvements SEPA, c’est-à-dire les SDD – SEPA Direct Debit, ou non SEPA, en particulier pour les prélèvements non européens) et opérations entrantes (usagers, clients…)
- opérations de netting, de trading, comptable
- opérations de pooling
- LCR
Les Payment Factories aujourd’hui
Certains progiciels de paiements ont encore recours à des technologies client-serveurs et nécessitent ainsi des installations sur chaque machine utilisateurs, outre le logiciel serveur et la DB (VB, SQL Server pour les PC).
Lourdes et dépassées depuis plusieurs années, ces méthodes de développement ont été troquées au fur et à mesure par les développeurs de progiciels par les langages Web (Java, PHP, Python…) et combinées aux serveurs d’application (Borland, WebSphere, Oracle Application Server…) et aux SGBDR : DB2, MySQL, Oracle…) les plus robustes et les plus connues du domaine.
Les progiciels fondés sur les techniques Web présentent l’intérêt de pouvoir être mis an place rapidement et de ne requérir aucun déploiement sur les PC users.
Ainsi, un browser Web (Microsoft Edge, Chrome, Mozilla Firefox, Apple Safari…) est suffisant pour accéder à sa payment factory.
Types d’offre et pricing
On trouve 3 grandes typologies d’offres de payment factory, qui valent aussi pour toute la gamme d’applications orientées Trésoreries groupes :
- PaaS (Platform as a Service) : proposition la plus moderne, qui permet d’accéder au progiciel de paiement installé sur un serveur mutualisé, géré par le distributeur. Le paiement est mensuel ou trimestriel le plus souvent, et son montant est calculé sur la taille de la database et la quantité d’users
- licences + maintenance
- hébergement simple
Si le PaaS (variante avancée du SaaS basée sur l’informatique en nuage) est désormais le type d’offre la plus choisie dans de nombreux secteurs, les décideurs des Trésoreries demeurent souvent hésitants à l’idée de faire héberger des données confidentielles (transactions et datas utilisateurs) hors de leur structure et de leur direction informatique.
Après que le choix de l’offre a été fait, la décision d’achat effectuée et la mise en place effectuée, la payment factory sera amenée à évoluer, et des versions ultérieures du progiciel seront proposées sous forme de mises à jour aux décisionnaires par les développeurs du logiciel.
2e partie : Pré-requis fonctionnels d’une payment factory