Plateforme interne de rapprochement : une étude de cas d'automatisation de processus
La plupart des projets de nos études de cas commencent par le problème d'un client. Celui-ci a commencé par le nôtre.
Le système en un coup d’œil
Le problème
Chaque semaine, quelqu'un dans notre équipe devait rapprocher à la main les paiements fournisseurs, les factures d'énergie et les factures avec les bons de commande, sur cinq sources de paiement distinctes : deux banques traditionnelles, deux néobanques et PayPal. Chaque source avait son propre format de relevé, son propre accès et ses propres bizarreries d'export. Aucune ne communiquait avec les autres.
Le processus tournait sur des tableurs. Un paiement arrivait sur l'un des cinq comptes, quelqu'un recopiait les détails dans une feuille de suivi, puis partait chercher le bon de commande correspondant pour confirmer que le montant, le fournisseur et la date concordaient. Quand ce n'était pas le cas, il fallait comprendre pourquoi : un paiement partiel, une conversion de devise, un débit en double, un bon de commande jamais émis.
La plupart du temps, ce travail ne demandait aucun jugement. Il demandait de l'attention, et l'attention est exactement ce qu'un rapprochement manuel à cinq sources dévore le plus vite. Des lignes étaient escamotées. Des correspondances passaient à la trappe jusqu'à la clôture mensuelle. Le tableur finissait par tomber juste, mais ce « au bout du compte » coûtait de vraies heures chaque semaine, prises sur une fonction finance qui avait autre chose à faire.
Le développement
Nous avons construit une plateforme interne qui récupère les données de paiement des cinq sources (comptes bancaires fournisseurs et énergie, comptes néobanque et PayPal) et rapproche automatiquement chaque transaction de son bon de commande. Cela relève de la même catégorie de travail que celle décrite sur notre page outils internes et IT : un logiciel construit pour un flux de travail qui existe déjà dans une entreprise, et non un produit vendu sur le marché.
La plateforme fait le rapprochement que le tableur faisait à la main. Elle récupère la transaction, trouve le bon de commande correspondant, vérifie le montant et le fournisseur, et signale tout ce qui ne se rapproche pas proprement. Une correspondance nette ne demande aucun humain. Une exception (paiement partiel, écart, bon de commande manquant) remonte pour qu'une personne l'examine, au lieu de rester enfouie dans une ligne que personne ne vérifiera peut-être avant la relecture de la feuille.
Nous l'avons construite comme nous construisons chaque projet : une exigence cadrée, un développement assisté par IA, une relecture humaine sur chaque modification avant qu'elle ne touche de l'argent réel. Un logiciel de finance ne tolère aucun bug d'apparence plausible, alors la discipline de relecture a été ici plus stricte encore que d'habitude.
Comment un paiement est rapproché
Collecte
Les transactions arrivent des cinq sources de paiement.
Rapprochement
La plateforme retrouve le bon de commande et vérifie le montant et le fournisseur.
Signalement
Tout ce qui ne concorde pas nettement est signalé à une personne.
Validation
Une correspondance nette n’a besoin d’aucune intervention humaine.
Ce qui est signalé à une personne
Ce sont les cas qui se cachaient autrefois dans une ligne de tableur.
Paiement partiel
Un montant inférieur au total de la facture est arrivé.
Conversion de devise
Le montant diffère parce que le paiement a changé de devise.
Débit en double
Le même paiement apparaît deux fois.
Bon de commande manquant
Un paiement n’a aucun bon de commande à rapprocher.
Le résultat
La plateforme fait gagner environ 10 heures de rapprochement manuel par semaine. Ce temps servait auparavant à recopier des chiffres entre un relevé bancaire et un tableur. Il est désormais consacré aux exceptions qui demandent réellement une décision, et au reste du travail de la finance.
Nous n'avons pas construit cet outil une fois pour ensuite passer à autre chose. Il est toujours en production, il rapproche encore les paiements en direct sur les cinq sources, chaque semaine, à l'instant même.
Ce que ce projet prouve et qu'aucune étude de cas client ne peut prouver
Une étude de cas client vous dit ce que nous avons construit pour quelqu'un d'autre. Notre propre plateforme vous dit à quoi nous confions notre argent.
Nous sommes notre premier client, et le plus exigeant. Personne n'accorde à un outil financier le bénéfice du doute comme le ferait un client extérieur : si la logique de rapprochement rate un écart, c'est nous qui l'apprenons à nos dépens, sur nos propres comptes. Le niveau d'exigence n'a rien à voir avec celui d'une fonctionnalité livrée avant de passer au contrat suivant.
Exploiter cette plateforme nous-mêmes signifie que chacune de nos affirmations sur le développement assisté par IA (l'approche à périmètre fixe, la discipline de relecture, la vitesse de livraison) a déjà été mise à l'épreuve d'un cas d'usage où aucun haussement d'épaules ni correctif au sprint suivant n'est possible. C'est la même raison pour laquelle notre page à propos de Globaprom commence par les outils que nous avons construits pour notre propre activité de traduction avant même l'existence de Globaprom : nous ne demandons pas à un client de faire confiance à une approche que nous n'avons pas déjà éprouvée nous-mêmes, sur quelque chose qui compte pour nous.
Obtenez le même type de développement
Si le rapprochement, le lettrage ou tout autre processus financier manuel dévore encore des heures de votre semaine, décrivez-nous son fonctionnement actuel. Nous reviendrons avec un périmètre fixe, un prix fixe et une date de livraison mesurée en semaines, exactement la méthode qui nous a servi à construire la plateforme que nous exploitons encore nous-mêmes.