Les 14 douleurs de la création d’un système de paiement en interne

 (arnon.dk)
1 points par GN⁺ 2024-02-27 | 1 commentaires | Partager sur WhatsApp
  • Les systèmes de paiement et de revenus sont indispensables à la monétisation, mais comme il s’agit de systèmes centraux complexes impliquant la finance, le produit, le support client, le juridique, la conformité et les ventes, la moindre panne peut se transformer en problème opérationnel majeur
  • Les jeunes entreprises ou les équipes lançant un nouveau produit ont tendance à voir le paiement comme un simple problème d’ingénierie et à le construire elles-mêmes, mais en pratique les choix se répartissent entre construction interne, tiers et hybride
  • Un véritable système de paiement doit gérer en même temps l’idempotence, les dates, la mesure de l’usage, la fiscalité, les remboursements, les hiérarchies clients, les contrats sur mesure, les changements de prix et la reconnaissance du revenu
  • Certains problèmes, une fois résolus, restent stables, mais les règles fiscales, les erreurs des clients, les corrections manuelles et les exigences de facturation propres à chaque pays continuent de croître avec la croissance de l’entreprise et son expansion mondiale
  • Il est plus sûr de se concentrer sur les mises à jour d’usage propres au produit et les événements du cycle de vie client, et de confier autant que possible l’abonnement, la facturation, la comptabilité et la reconnaissance du revenu à des systèmes de paiement et ERP du marché

Pourquoi le paiement n’est pas une simple fonctionnalité

  • Les systèmes de paiement et de revenus sont indispensables pour qu’une entreprise génère du chiffre d’affaires
  • Quand tout fonctionne normalement, ils passent inaperçus, mais en réalité il s’agit d’un système tentaculaire qui touche simultanément de nombreuses équipes et fonctions
    • finance
    • produit
    • expérience utilisateur
    • support client
    • clients
    • juridique
    • conformité
    • ventes
  • Si une partie se casse, les problèmes peuvent rapidement se propager aux domaines connectés, et cela arrive souvent en pratique
  • Si l’entreprise ne peut pas encaisser son revenu de manière légale et correcte, la charge qui retombe sur les équipes opérationnelles augmente fortement

Trois modèles de mise en place

  • On distingue généralement trois approches pour un système de paiement
    • construction interne
    • système tiers complet
    • hybride mêlant construction interne et tiers
  • Les jeunes entreprises ou les équipes qui lancent un nouveau produit ont tendance à vouloir le faire elles-mêmes parce qu’elles ont des ingénieurs et veulent garder les choses simples
  • Si l’on voit le paiement comme un simple problème où « il suffit de déposer un fichier de facturation sur S3, puis un job CRON le récupère et encaisse le paiement », on le réduit à tort à un problème purement d’ingénierie
  • De la même manière qu’on n’implémente pas soi-même la sécurité ou la gestion des dates, il vaut mieux éviter de tout construire soi-même dès le départ pour le paiement
  • Le meilleur système de paiement est celui qu’il n’a pas été nécessaire de construire entièrement soi-même

Les 14 douleurs d’un système de paiement interne

  • Idempotence

    • Toute demande de facturation et d’encaissement doit être unique et idempotente
    • Le problème apparaît lors des tentatives après une limitation d’API ou lorsqu’on augmente le nombre d’instances du système de paiement
    • Si c’est mal géré, on risque la double facturation

  • Gestion des dates

    • Il faut décider s’il faut facturer tous les 30 jours ou chaque mois à la date d’inscription
    • Il faut aussi gérer des cas comme les années bissextiles et les fuseaux horaires

  • Prorata et reliquats

    • Il faut décider si le prorata s’applique uniquement aux upgrades ou aussi aux downgrades
    • Les options incluent remboursement, crédit, ignorance du reliquat, ou blocage des upgrades et downgrades

  • Mesure de l’usage

    • La manière de calculer l’usage peut prendre des dizaines de formes
    • Elle peut varier selon le type de client ou changer fréquemment

  • Format des factures

    • Cela peut sembler simple quand on n’opère que dans un seul pays
    • Mais avec l’expansion, il faut gérer non seulement la sales tax, mais aussi la TVA, la GST et d’autres prélèvements propres à chaque pays
    • Des modèles distincts peuvent devenir nécessaires selon le marché

Une complexité qui grandit avec le B2B et l’expansion internationale

  • Hiérarchies clients complexes

    • Les clients B2B en particulier peuvent vouloir gérer des relations de facturation entre filiales et partenaires
    • Il faut alors un moyen d’agréger l’usage vers l’entité réellement payeuse
    • Ces besoins n’apparaissent souvent qu’après la croissance et l’expansion
    • Les taxes peuvent varier selon l’entité légale du client ou le lieu d’usage
    • Il peut être nécessaire, légalement, de distinguer facture et invoice
    • Les règles associées peuvent changer tous les quelques mois

  • Encaissement et prévention du churn

    • Il faut décider quand cesser de retenter un paiement
    • En cas de chargeback, il faut décider s’il faut fermer le compte, le suspendre ou rembourser

  • Mise en pause et reprise

    • Lorsqu’un client met son abonnement en pause, il faut décider quel niveau d’accès lui reste accordé

  • Crédits et remboursements

    • Si l’on ne fait que des remboursements complets, cela reste relativement simple
    • En cas d’erreur partielle, il peut falloir choisir entre remboursement partiel et crédit boutique
    • Il faut aussi décider si les crédits expirent ou non

Fiscalité, contrats et erreurs humaines

  • Gestion fiscale

    • Le simple fait d’avoir des taux différents selon les éléments facturés suffit déjà à compliquer les choses
    • À l’échelle mondiale, les taux et règles fiscales changent fréquemment

  • Contrats sur mesure

    • Ce n’est pas forcément un problème si l’on ne fait que du PLG
    • Mais dès qu’on commence à signer des contrats, les exceptions et conditions particulières qui ne rentrent pas dans les hypothèses initiales apparaissent rapidement

  • Erreurs humaines

    • Les clients font des erreurs, qui nécessitent ensuite des corrections
    • En interne aussi, la configuration d’un client peut être mal faite et devoir être corrigée plus tard
    • Émettre des crédits et réémettre des factures sont des tâches très chronophages
    • Les changements d’informations légales du client doivent aussi être pris en charge
      • adresse
      • identifiant TVA, etc.

  • Changements de prix sélectifs

    • Les changements de prix ne s’appliquent souvent pas à tous les clients
    • S’ils ne concernent que les nouveaux clients, il faut maintenir plusieurs versions tarifaires pour respecter les contrats existants

  • Reconnaissance du revenu et revenu constaté

    • Les règles de reconnaissance du revenu selon IFRS-15 font l’objet d’une spécification PDF de 64 pages
    • Si l’on ajoute en plus une intégration ERP sur mesure, la complexité augmente encore

Les problèmes qu’on règle une fois et ceux qui continuent à grossir

  • Certains problèmes changent bien plus souvent que prévu, tandis que d’autres, une fois traités, ne demandent presque plus d’intervention
  • L’idempotence est un exemple de problème d’ingénierie qu’on résout une fois puis qu’on retouche rarement
  • Les règles fiscales changent fréquemment dans le monde entier
    • Plus on s’étend dans de pays, plus le nombre de législations à suivre augmente
  • Les erreurs des clients surviennent de manière relativement constante
    • Leur ampleur augmente avec la croissance
    • Elles exigent davantage de support client et de corrections manuelles
  • Au départ, le paiement ressemble à un problème d’ingénierie, mais en réalité il s’enracine dans un espace de problèmes complexe difficile à appréhender même pour des professionnels du secteur

Les domaines qu’il n’est pas nécessaire de construire soi-même

  • Il vaut mieux confier autant de problèmes de paiement que possible à des systèmes externes
  • L’approche recommandée consiste à acheter autant que possible des solutions existantes
  • Une grande partie de l’abonnement et de la facturation peut être gérée par un système de paiement
  • Il vaut mieux confier la reconnaissance du revenu et la comptabilité aux fonctionnalités déjà intégrées dans l’ERP ou d’autres systèmes déjà utilisés
  • Les équipes produit devraient se concentrer uniquement sur les éléments propres au produit, comme les mises à jour d’usage et les événements de base du cycle de vie client

À lire aussi

1 commentaires

 
GN⁺ 2024-02-27
Commentaires Hacker News

  • C’est un bon article pour quelqu’un qui doit prendre des décisions de facturation sans avoir beaucoup d’expérience, et il reste utile comme référence même pour les personnes expérimentées
    Cela dit, la phrase « pourquoi ne pas simplement dumper les fichiers à facturer dans S3 et laisser une tâche CRON récupérer les paiements ? » m’a bien fait rire. Avec un cerveau d’ingénieur, ce n’est une bonne idée dans aucune situation
    La décision d’architecture de facturation que je préfère consiste à séparer autant que possible la facturation et les droits dans le système. Pour un abonnement prépayé, il vaut mieux que les droits eux-mêmes ne stockent que la date d’expiration et les détails des autorisations accordées pendant la période active, tandis que le système de facturation stocke l’abonnement puis synchronise vers la partie droits quand c’est nécessaire. Cela facilite ensuite la facturation manuelle, le débogage et les correctifs temporaires, ou encore l’intégration avec Stripe
    Bien sûr, il faut garder de la place pour les extensions futures, mais ce choix en lui-même ne limite généralement pas beaucoup le système. Ce n’est pas une idée originale de ma part, mais je l’apprécie particulièrement après avoir essayé d’autres approches avec moins de succès

    • D’après mon expérience, les ingénieurs se divisent généralement en deux catégories : ceux qui ont déjà travaillé sur un système de facturation et les autres
      Beaucoup de problèmes viennent de la différence entre paiement et facturation https://www.wingback.com/blog/saas-payment-vs-saas-billing. Au début, quand on accueille ses premiers clients, il suffit de gérer quelques paiements récurrents, donc on peut facilement démarrer avec Stripe ou des factures manuelles
      Mais avec le temps, arrivent de plus en plus de clients enterprise qui demandent des droits plus complexes, plusieurs plans tarifaires, la protection des clients existants, ainsi que des cycles, conditions et règles d’octroi personnalisés. Comme la facturation devient rarement une priorité technique, on accumule de petits hacks et des fonctionnalités supplémentaires, et cela finit par devenir un chaos qui siphonne les ressources produit, ralentit les ventes ou limite ce qu’on peut vendre
      La complexité de la facturation est pleine de pièges cachés et d’exceptions, et aujourd’hui elle s’est encore accrue parce que la plupart des plans incluent plusieurs limites et des composantes basées sur l’usage, tandis que les produits SaaS se vendent dans le monde entier. Dans les entreprises à un stade avancé, il existe même des équipes de plus de 15 ingénieurs dédiées uniquement à la facturation. Si ce n’est pas le cœur du produit, je suis d’accord qu’il ne faut pas construire son propre système de facturation. Pour référence, je suis le CTO de la plateforme de facturation SaaS Wingback
    • Si le modèle d’ingénieur sous-entendu par le slogan « ne le construisez pas vous-même » est vraiment celui-là, alors cet article a eu l’effet inverse sur moi
      Maintenant j’ai envie de construire un tel système, et j’ai l’impression d’être bien plus qualifié que je ne le pensais
    • Arnon a aussi écrit un bon article précisément sur cette séparation entre facturation et droits
      https://arnon.dk/why-you-should-separate-your-billing-from-e...
    • Ces dernières années, en travaillant avec des entreprises SaaS qui utilisent Warrant comme solution de droits client, nous en sommes arrivés à la même approche
      Les clients stockent les droits dans notre système et les vérifient quand nécessaire, tandis que des règles et des droits sont ajoutés lorsque l’abonnement est renouvelé ou supprimé côté fournisseur de paiement. Cela facilite le travail avec un ou plusieurs fournisseurs de paiement et clarifie aussi la séparation des responsabilités. Je partage également des articles plus pertinents dans ce contexte : https://warrant.dev/use-cases/pricing-tiers-and-entitlements..., https://arnon.dk/why-you-should-separate-your-billing-from-e...
      Un système de droits idéal doit être dynamique, c’est-à-dire que les règles doivent être stockées dans la base de données, pouvoir gérer des scénarios ponctuels comme les clients enterprise, et avoir une couche de politiques au-dessus. Par exemple, il devrait pouvoir couvrir presque tous les cas : plan Pro limité à 5 sièges, plan Growth autorisant une fonctionnalité jusqu’à N fois par jour, etc.
      Une interface permettant à des personnes non techniques d’effectuer des changements client par client sans intervention de l’ingénierie est aussi un énorme avantage. Dans mes précédents postes d’ingénieur, ce genre de demande bloquait toujours l’équipe de développement
    • Nous avons abouti à quelque chose de similaire. La facturation n’est qu’un mécanisme de calcul des factures, et elle gère les créances clients en accumulant dans un grand livre les factures émises, les paiements reçus et les ajustements
      Il existe aussi un ensemble de droits, mais avec au milieu un mécanisme de politique qui décide quand appliquer ou ne pas appliquer ces droits. Le point essentiel, c’est que les droits ne relèvent pas uniquement de la facturation. Le mécanisme de politique est la colle qui relie les droits à tout le reste, ce qui permet par exemple d’accorder des droits à un dirigeant du plus gros client sans les lier à la facturation

  • J’ai autrefois construit un système de facturation et de créances clients pour une petite chaîne de pharmacies, et les assureurs nous envoyaient parfois de gros chèques sans aucun préavis
    Nous recevions par courrier des chèques de 150 000 dollars sans avoir rien facturé, puis ils se rendaient compte de l’erreur des mois plus tard et demandaient qu’on les renvoie. Nous avions un compte spécial appelé magic money pour y mettre ce type d’argent. Le monde de la facturation est vraiment dingue

    • Cela ressemble à un compte d’attente, en particulier ici rattaché à l’émetteur du virement. En gros : « on a reçu de l’argent de cette entité, mais on ne sait pas encore pourquoi »
    • Je me demande s’il existe un moment où cette “magic money” devient légalement la propriété de l’entreprise après un certain délai
    • Je me demande si cela n’avait pas été facturé à une autre entité, par exemple à un particulier, puis si le paiement avait fini par venir de l’assureur sans que personne ne remonte la piste, laissant ainsi une dette sur les comptes de ces personnes
      En gros, vous appeliez juste ça magic money tout en laissant la dette sur les comptes individuels
    • Je me demande pourquoi vous avez encaissé ou déposé ces chèques

  • Je ne pense pas qu’il soit pertinent d’aborder ce sujet uniquement sous l’angle de la souffrance que représente la création d’un système de facturation en interne. Si beaucoup d’entreprises veulent suivre cette voie, qu’on les laisse faire
    J’admets qu’un système de facturation est extrêmement complexe. Mais si Chargebee, Solvimon, Stripe, Recurly, Orb, Metronome, Lago, Togai et d’autres détiennent ce savoir, on peut aussi rassembler ce savoir en un seul endroit
    Au final, la bonne réponse est l’approche qui vous convient. Pour un SaaS par abonnement, il existe des solutions adaptées, et pour une API à l’usage, il existe des solutions de facturation correspondantes
    Au lieu de décourager cette pratique, on peut centraliser les connaissances, les approches, les paradigmes, les patterns de programmation, les bonnes pratiques et les meilleures pratiques. Il existe aussi des exceptions pour les entreprises hors des États-Unis ou d’Europe qui ne peuvent pas utiliser une solution de facturation comme Stripe. Par exemple, si vous êtes une entreprise vénézuélienne et ne pouvez pas créer de compte Stripe, vous finirez par devoir construire votre propre solution de facturation et la connecter à l’API SOAP-XML ésotérique d’une passerelle de paiement locale
    À part ça, « construire son propre système de facturation » me fait penser à « construire son propre SIEM » avec une stack Elastic + Grafana. Je ne le recommande pas, mais je comprends pourquoi tant d’équipes sécurité IT choisissent cette voie

    • Cet article traite les systèmes de facturation d’une manière intéressante. Certains des sujets présentés comme des problèmes semblent déjà relever d’un comptable ou d’un autre spécialiste que l’on a probablement embauché
      Les systèmes de facturation sont moins complexes que ce que les développeurs ont l’habitude de gérer. L’article présente les exigences juridiques difficiles comme une complication, mais cela signifie aussi, en pratique, que les spécifications sont faciles à trouver et bien documentées. Certaines parties changent souvent, mais elles sont généralement bien étiquetées et bien expliquées
      Je suis d’accord sur le fait qu’il existe une méthode de facturation adaptée à chaque SaaS par abonnement et à chaque API à l’usage. La vraie question, en revanche, est de savoir si l’on veut permettre au client de transférer la charge de responsabilité, si le chiffre d’affaires est suffisamment important pour justifier une vérification, et si l’on peut absorber les frais ou les pertes

  • L’un des points que cet article n’aborde pas est la vente par affiliation, qui peut représenter beaucoup de travail selon le niveau de profondeur de l’implémentation
    C’est un système qui permet à d’autres personnes de recevoir une rémunération à la commission pour des ventes réalisées sur la plateforme
    Il faut suivre les codes d’affiliation jusqu’aux ventes et aux utilisateurs, envoyer les paiements via le prestataire de paiement choisi par l’affilié, et, si on veut bien faire les choses, fournir aussi une UI permettant de consulter les métriques de visite, les taux de conversion et l’historique des paiements
    Heureusement, l’essentiel peut être construit de manière progressive. Il suffit de relier un code unique à un utilisateur, puis ce code à des ventes avec un taux de commission donné, et le reste peut être géré manuellement ou ignoré. Par exemple, je paie mes affiliés une fois par mois via Zelle ou PayPal et cela me prend moins de 10 minutes. Il n’y a pas de frontend de suivi des conversions, et personne n’a renoncé au programme d’affiliation à cause de cela

  • Ce qui m’a vraiment marqué, c’est la nécessité de pouvoir faire tourner à l’envers toute cette machine de Rube Goldberg
    On veut garder la « commande » aussi statique que possible, et la « facture » porte même des obligations légales
    Par exemple, imaginons que quelqu’un achète 5 articles et bénéficie d’une remise, mais n’en veut finalement que 3, tout en ayant fait une faute dans son nom et son adresse. Pas de problème : on annule la facture, on en crée une nouvelle du même montant avec le nom et l’adresse corrigés, puis on attend que le retour arrive et soit inspecté avant d’émettre un avoir et de créer encore une nouvelle facture
    Entre-temps, le retour reste un moment dans un état ambigu, le client commande 5 articles de plus, l’un arrive cassé et il veut un remboursement plutôt qu’un remplacement. Les dates d’expédition sont réparties en deux envois, donc le système n’applique pas la remise à partir de 5 articles. Ce qui semblait au départ n’être que deux commandes simples se transforme instantanément en une multitude de transactions et de documents. Le client a aussi oublié son mot de passe et créé un nouveau compte avec une autre adresse e-mail. Un an plus tard, en regardant les logs, il devient difficile de comprendre pourquoi il n’a acheté que 3 articles tout en bénéficiant d’une remise

  • Je ne suis pas vraiment convaincu par ce conseil. La moitié des fonctionnalités évoquées dans l’article ne sont peut-être pas nécessaires, et on peut très bien les construire progressivement à mesure que l’activité grandit
    Il faut comprendre des notions comme les factures, les crédits, les périodes fiscales ou les changements de prorata. Mais cette connaissance n’est pas en soi une raison de sous-traiter ou d’acheter quoi que ce soit à tout prix : c’est surtout de la matière pour mieux arbitrer entre construire et acheter
    Pour un SaaS, la seule API externe nécessaire est un processeur de cartes bancaires, ou deux si l’on veut faire les choses avec un peu plus d’élégance. Bien sûr, après la première année, il y aura beaucoup de travail manuel, le comptable signalera des erreurs idiotes, et on apprendra beaucoup de choses en comptabilité
    Malgré tout, si je lançais une nouvelle activité aujourd’hui, je comparerais plusieurs solutions, mais je resterais convaincu que le faire soi-même n’a rien d’aussi effrayant

    • En tant que personne ayant déjà construit et intégré des systèmes de facturation, ça ressemble à un propos né d’une ignorance heureuse
      Construire un système a toujours l’air facile, et le premier jour ça l’est même vraiment. Mais très vite, on passe beaucoup de temps à expliquer au directeur financier pourquoi les rapports sont complètement en vrac, et à l’équipe support pourquoi une facture a échoué, pourquoi le mauvais prix d’abonnement a été facturé, et toute une série de cas limites dont on ignorait jusqu’à l’existence
      Ensuite, il faut se mettre en conformité avec une réglementation qui a changé, ou découvrir que la gateway choisie ne prend pas en charge une région où l’on est en train de se développer
      Avant de dire « il suffit de mieux le construire », il faut se rappeler que cela aussi, c’est du temps. Du temps qui n’est pas consacré au produit, ni à l’amélioration du modèle tarifaire, et qui sert à faire du sur-place au lieu de faire croître l’entreprise
    • Quelle que soit la voie choisie, il faut d’abord parler avec un comptable pour vérifier quelles informations doivent légalement figurer dans les paiements
      Tout le reste peut être ignoré, mais si plus tard vous vous retrouvez incapable de calculer les taxes ou en infraction avec la loi sur le KYC, cela deviendra vraiment pénible
      Il faut aussi garder à l’esprit que certains systèmes coûtent plus cher que prévu, et que le fait que beaucoup d’entreprises qui ont l’air intelligentes les utilisent ne veut pas dire qu’ils sont adaptés à votre objectif. Encore moins au vôtre en particulier. Acheter ne dispense pas de faire ses recherches
    • Le cœur du B2B SaaS, c’est que l’argent vient de ventes à forte valeur, très gourmandes en intervention humaine, et que ce sont ces ventes qui génèrent les exigences
      L’objectif de la personne qui gère ce type de facturation est simple : fournir les bonnes options pour que l’équipe commerciale puisse conclure des contrats. Il faut collaborer avec les commerciaux pour trouver la zone « suffisamment facile à implémenter et suffisante pour signer le contrat »
      On n’insistera jamais assez là-dessus. C’est l’équipe commerciale qui génère réellement le chiffre d’affaires. Il ne faut pas geindre parce que le système de facturation n’est pas parfait. Aussi choquant que cela puisse paraître, quand une relation commerciale est en jeu, il faut parfois retrousser ses manches et le faire à la main
      Il faut procéder de la manière la plus simple possible, mais avec un système que les autres équipes de l’entreprise peuvent lire et comprendre, et qui reste facile à ajuster manuellement même quand l’automatisation tourne. C’est 80 % de la raison pour laquelle Stripe paraît agréable à utiliser. Les ajustements manuels font partie de la vie, et même s’ils sont rares dans certaines entreprises, ils finissent par être nécessaires
    • Dès qu’on s’étend à plusieurs pays et devises, on sous-estime à quel point la simple gestion des prix des bundles d’abonnement devient difficile
      Prorata, calendriers de facturation différents, essais gratuits, tests de nouveaux prix, tarification par région, taxes locales, affichage des bundles dans plusieurs devises, et le déploiement d’un nouveau prix devient soudain une combinaison de 6 devises × X régions × Y produits × Z calendriers de facturation × L langues
      Ajoutez à cela de nouveaux abonnements, la fusion de plans tarifaires, l’arrêt d’anciens plans tout en faisant migrer en douceur les clients vers de nouvelles offres, et la nécessité de bien communiquer avec eux. Pour un SaaS, presque tout cela doit être bien automatisé, self-service et bien testé ; sinon, on se fait submerger par le support client et le churn
    • Cela suppose qu’on ait le temps de le construire soi-même. Nous sommes 35 employés, avec 300 000 clients sur un SaaS B2C low cost, et nous sommes tellement occupés à développer le produit et corriger des bugs que nous avons en pratique zéro minute à consacrer à l’extension du système de facturation ou à l’implémentation de contrats personnalisés
      Le déploiement d’un changement de prix peut prendre de 3 jours à 2 mois, et gérer les traces des anciens contrats personnalisés est un cauchemar. Si cela ne s’automatise pas facilement, on ne peut tout simplement pas le faire. Cela prend beaucoup trop de temps
      Si nous avions basé la facturation sur un produit comme ceux mentionnés ici, nous aurions probablement été bien meilleurs sur les contrats personnalisés par segment de clientèle et le déploiement des changements de prix

  • Il y a 2 problèmes que j’ai traités moi-même et qui ne sont pas abordés ici
    Le premier, c’est la clôture de fin de mois et de trimestre. L’article parle du grand livre comptable, mais dès qu’on commence à traiter avec des sociétés cotées qui doivent publier leurs chiffres, il y a des échéances de clôture strictes et tout doit se dérouler sans accroc
    Le second, c’est la comptabilité de trésorerie en mouvement. Cet article part du principe que le processeur de paiement est exact à 100 % et qu’il n’y a jamais le moindre problème. Lorsqu’on atteint une certaine taille, il faut pouvoir rapprocher tout l’argent arrivé sur le compte bancaire d’une facture ou d’une ligne de facturation précise. Il faut aussi retrouver les factures qui n’ont pas de ligne correspondante sur le relevé bancaire, et inversement gérer les cas où de l’argent arrive sans être relié à une ligne de facture. La capacité à traiter des crédits sur le compte bancaire non reliés à une facture de facturation est également importante
    On peut dire que tout cela relève entièrement du service comptable, mais c’est tellement étroitement couplé au système que les deux équipes doivent travailler ensemble pour éviter toute incohérence entre les livres

    • Toute personne ayant eu le moindre contact avec la comptabilité autour d’une grande entreprise cotée a probablement eu un petit frisson rien qu’en lisant clôture de fin de mois et de trimestre
      Les vrais comptables doivent régulièrement rester jusqu’à minuit à cause des clôtures, et les équipes tech ou business vivent la situation où elles ont besoin de quelque chose de la compta, mais où, pendant la période de clôture, la compta semble avoir disparu de la surface de la Terre. Même quand on le vit par procuration dans sa famille, c’est pareil
    • Si l’on ne rapproche pas dès le départ les virements bancaires et les lignes de facturation, il n’y a aucun espoir de calculer correctement les taxes
      La comptabilité interne et le compte bancaire dérivent peu à peu l’un par rapport à l’autre, et le comptable finit par ne plus savoir par où commencer pour trouver le problème

  • Je suis curieux de savoir ce que les autres utilisent pour la gestion des droits. Un système de feature flags, un SaaS séparé comme Stigg, ou bien un système interne dédié ?
    Si c’est arrivé sur HN ce matin, c’est parce que j’ai écrit un billet sur l’usage des feature flags pour gérer les droits : https://prefab.cloud/blog/modeling-product-entitlements-with.... J’ai aussi été inspiré par le billet d’Arnon sur les formats de SKU
    Les feature flags ne semblent pas être l’outil parfait pour la gestion des droits, mais d’après mon expérience, c’est souvent le meilleur outil qu’on ait déjà sous la main pour ce type de problème. J’aimerais bien entendre d’autres avis

    • Nous, on combine des limites numériques, par exemple le nombre d’appels API par jour, avec des product flags sous forme de tableau de tags
      Ces limites et ces flags sont attachés à des « forfaits », et ces forfaits peuvent être associés à des comptes. Si on combine plusieurs forfaits, on prend la valeur numérique la plus élevée et on fusionne les tags par union. On peut aussi écraser ou ajouter des valeurs au niveau du compte ; ainsi, si un client a besoin de PlanX mais avec un quota API personnalisé, il suffit d’écraser directement cette seule valeur sur le compte
      Appelez ça old school si vous voulez, mais je ne vois pas pourquoi il faudrait sous-traiter ça à un tiers
    • Je suis justement en train de construire une solution pour une fonctionnalité proche des droits liés aux forfaits
      Une approche de base est possible avec des feature flags, mais dès qu’on parle de droits liés à la facturation et à la tarification, par exemple l’organisation et l’évolution des forfaits et des éditions, les exigences périphériques s’accumulent avec le temps et la complexité grimpe. Il suffit de penser aux différentes combinaisons de fonctionnalités, de sièges, de stratégies basées sur l’usage et la mesure, aux abonnements d’équipe, aux changements de forfait, aux forfaits enterprise ponctuels, aux clients avec plusieurs abonnements, aux périodes promotionnelles et abonnements à paliers, à l’agrégation d’usage, à l’upsell automatique, etc.
      Comme on le voit dans l’article, on peut exprimer des limites avec des flags portant des valeurs numériques, mais l’infrastructure de suivi de l’usage doit toujours être implémentée par l’entreprise elle-même. À la place, on peut imaginer exposer cet usage à un service de droits, avec une mise à jour en temps réel des droits basés sur l’usage, même entre équipes. D’autres droits qui dépendent de ceux-là peuvent aussi être mis à jour. On peut choisir des limites souples, qui laissent l’utilisateur continuer tout en alertant l’équipe commerciale lorsqu’il approche ou dépasse la limite, ou des limites dures, qui affichent une invite à passer à une offre supérieure
      Comme l’idée de l’article d’origine, nous travaillons avec des solutions de facturation existantes au lieu de refaire toute la facturation. Nous sommes financés en bootstrap grâce à un précédent exit réussi et nous travaillons avec nos premiers clients, donc même si quelqu’un veut simplement échanger sur le sujet, il peut écrire à trent at planship.io
    • Les feature flags font partie de ces beaux systèmes qui ont juste assez de pouvoir d’expression pour donner envie de les forcer partout
      On peut tout faire avec : déploiements bêta, authentification basée sur les rôles, droits liés à la facturation, jusqu’aux demandes ponctuelles de clients. Les meilleurs systèmes de feature flags permettent même d’attacher des valeurs optionnelles, donc les limites de forfait API peuvent aussi devenir des feature flags
      Est-ce la meilleure solution ? Probablement pas pour chaque cas d’usage pris séparément. Mais une fois qu’on l’a mise en place, la tentation est grande de l’utiliser partout
    • Je pense que des « droits via feature flags » peuvent bien fonctionner s’ils sont clairement distingués des feature flags tels que les ingénieurs les utilisent habituellement, c’est-à-dire pour de petits changements incrémentaux, des tests, des déploiements, de l’A/B testing
      Les droits doivent être clairement reliés aux fonctionnalités visibles par le client, et conceptuellement ce sont des blocs fonctionnels bien plus larges. La difficulté de cette approche, c’est qu’il faut quand même prendre en compte beaucoup d’aspects liés à la facturation. La gestion des clients en retard de paiement, la surfacturation au-delà de certains seuils, plusieurs modèles tarifaires pour une même fonctionnalité, la réinitialisation ou le report des compteurs d’usage lors d’un changement de forfait ou d’un upgrade, tout cela ajoute une grande complexité avec le temps
      C’est pourquoi, chez Wingback, nous avons choisi de proposer des droits fonctionnels séparés, étroitement couplés à la chaîne de facturation et à la mesure. Pour référence, j’en suis le CTO. Au final, je pense que les deux approches peuvent bien fonctionner selon la complexité des forfaits et le niveau d’investissement déjà fait dans les feature flags. Quand on a du feature gating côté client, le provisioning des comptes clients et la fourniture de packages sur mesure deviennent beaucoup plus simples

  • J’ai globalement du mal avec la logique du type « le système X est très complexe, donc il ne faut pas le faire soi-même mais utiliser une solution du marché »
    La solution générale à X peut être extrêmement difficile et complexe, mais mon cas d’usage n’a besoin que d’une partie bien précise de cette complexité. Je peux donc construire une solution maison qui ne traite que la complexité dont j’ai besoin, et elle peut être beaucoup plus simple qu’un outil prêt à l’emploi
    J’applique totalement cette position aux dates et heures. Pour moi, mon approche des dates et heures se résume à deux appels de fonction dans une bibliothèque : une fonction qui transforme un temps epoch en chaîne horaire au format ISO dans un fuseau donné, et l’inverse. Je ne touche à aucun autre code de la bibliothèque, et tout le reste des manipulations temporelles se fait dans mon propre code à partir de ces deux fonctions

    • En facturation, quand de l’argent circule, la marge d’erreur acceptable est extrêmement faible, et il y a aussi de la réglementation
      Dès le départ, il faut comprendre ce qu’il faut faire ou ne pas faire avec les données personnelles, les cycles et la durée de vie des différentes options de facturation, les plafonds de remboursement, le support de l’idempotence, une gestion des transactions en base de données adaptée au problème avec un modèle approprié, l’émission des factures et leur exposition aux clients, etc.
      On n’a pas besoin de tout d’un coup, mais même pour une première implémentation réellement utilisable, il en faut au moins la moitié

  • Ça donne un peu une impression de « Les 14 douleurs de traverser la rue, et pourquoi vous devriez acheter mon livre »
    Beaucoup de gens pensent qu’il vaut mieux fermer les yeux et commencer à marcher, ce qui leur vaut parfois une blessure prématurée ou la mort
    Les règles pour traverser la rue changent selon les pays, voire selon les villes. Vous ne le savez peut-être pas encore, mais il faut regarder des deux côtés. Beaucoup de gens meurent ou se blessent parce qu’ils ne savent pas qu’ils sont daltoniens et ne distinguent pas le rouge du vert. Vous avez regardé des deux côtés, mais avez-vous regardé en haut aussi ? En ville, des objets tombent des fenêtres ; à la campagne, des oiseaux peuvent voler au-dessus de votre tête ; et les débris spatiaux retombent de plus en plus sur Terre. Les objets peuvent venir de plusieurs directions
    Je ne dis pas que cet article est à ce point mauvais, mais il aurait été meilleur s’il avait été construit comme un article méthodologique. J’ai bien plus envie de lire ce genre de texte qu’un article structuré de manière négative

    • Je travaille actuellement dans une équipe de facturation. Je n’ai pas passé l’essentiel de ma carrière dans la facturation, mais cet article est juste
      C’est l’archétype du projet-blague « à quel point ça peut être difficile ? », sauf que le problème, c’est que tout est vrai
      Les exemples sont innombrables, mais si on aborde mal le problème, on se retrouve très vite face à la question « combien le client doit-il payer ? », puis juste après « pourquoi lui avons-nous facturé ce montant plutôt qu’un autre ? ». Si ce genre de situation arrive trop souvent, l’équipe finance finit par venir demander ce que vous avez fait pour rendre peu fiables les rapports de pilotage de l’entreprise, voire les rapports qui servent à décider des licenciements