Quelqu'un s'inscrit et paie, tout le reste se fait sans vous

Deux structures d'un même réseau associatif organisent des rencontres payantes : une place à réserver, parfois un don ajouté par l'inscrit, et pour certaines une participation à distance. Je ne publie ni leur nom, ni le titre des rencontres.

Cette fiche raconte trois étapes, pas une. La vérification à la main, puis un montage avec des outils du commerce, puis seulement un outil sur mesure. Je le précise parce que c'est ma façon de travailler : je ne pars pas du sur-mesure, j'y vais quand l'étape d'avant ne suffit plus.

La situation de départ

Une des deux structures allait vérifier ses inscriptions directement dans l'interface de son prestataire de paiement. Le problème n'était pas d'y accéder, il était de s'y retrouver : le fichier qu'on pouvait en extraire ne disait pas à quelle rencontre se rattachait chaque paiement.

Autrement dit, la question la plus simple que puisse poser un organisateur, combien de personnes sont inscrites à telle rencontre, n'avait pas de réponse directe. Il fallait recouper à la main.

C'est moi qui tenais ce recoupement. Je vérifiais régulièrement dans le prestataire de paiement qu'aucun règlement n'était passé à la trappe, et je reportais. Personne ne me l'avait demandé, mais sans ça les chiffres n'étaient pas fiables.

Ce qu'il fallait respecter

• Une personne qui a payé doit recevoir une confirmation. Sans elle, elle croit son inscription perdue, et c'est l'organisateur qui reçoit le mécontentement.
• Un paiement ne doit jamais être perdu en route, et surtout jamais perdu en silence.
• Une annulation remboursée doit libérer la place. Sinon le compte des places disponibles ment.
• Les données des inscrits ne sortent pas : pas de liste nominative qui circule, pas d'export sauvage.
• Aucune manipulation à faire côté structure. Si l'organisateur doit lancer quelque chose à la main, on n'a rien automatisé, on a juste déplacé le travail.

Ce que j'ai fait, précisément

Premier temps, les outils du commerce. Pour la structure qui vérifiait à la main, j'ai monté un tableur en ligne qui se remplissait tout seul, alimenté depuis le prestataire de paiement par un outil d'automatisation sans code. Plus de recopie, un tableau consultable, et surtout le rattachement d'un paiement à sa rencontre, qui manquait au départ.

Ce montage a tenu, et il a servi. Mais il restait fragile : un tableur reste un tableur, il ne gère ni les confirmations, ni les liens de connexion, ni les remboursements.

Second temps, l'outil sur mesure. L'autre structure a servi de pilote pour un vrai écran de gestion des événements, et la première a suivi. Voici ce qui tourne aujourd'hui, sans que personne ne lance quoi que ce soit :

• Le paiement en ligne crée l'inscription et la rattache automatiquement à la bonne rencontre et au bon type de billet, place seule ou place accompagnée d'un don. Deux passages par jour, à 6h et à 18h.
• Le mail de confirmation part de lui-même, toutes les quatre heures.
• Le lien de visioconférence est envoyé quarante-huit heures avant la rencontre, dans un passage quotidien à 9h.
• Les remboursements sont répercutés deux fois par jour, à 7h30 et à 19h30, pour qu'une annulation ne laisse pas une place fantôme dans les compteurs.
• Un contrôle de bout en bout relit trente points sur chaque rencontre trois jours avant, tous les matins à 8h.
• Côté écran : la liste des inscrits, les places restantes, les montants collectés et un export comptable réservé au trésorier.
• Une procédure écrite, pas à pas, pour créer une rencontre de A à Z sans rien oublier.

Ce que ça a changé

Six rencontres sont passées par cette chaîne, dont une annulée. L'organisateur ne recoupe plus rien : il ouvre son écran et voit qui est inscrit, combien de places restent, et ce qui a été encaissé.

Je ne donnerai pas de chiffre de temps gagné, parce que je ne l'ai pas mesuré. Ce que je peux dire, c'est que la vérification régulière que je faisais depuis le prestataire de paiement n'a plus lieu d'être : c'est le contrôle automatique du matin qui la fait, sur trente points au lieu d'un coup d'œil.

Ce qui a failli passer à la trappe

Le 14 mai, j'ai découvert un défaut sérieux. Quand on crée un lien de paiement qui permet d'ajouter un don à sa place, le prestataire fabrique parfois un second produit, sans le signaler. Si ce second produit n'est pas déclaré dans la chaîne, les paiements faits dessus sont ignorés purement et simplement : pas d'inscription, pas de confirmation, pas de lien de visioconférence. La personne a payé, et croit qu'on l'ignore. Rien ne s'affichait nulle part, aucune erreur, aucune alerte.

J'en ai tiré deux choses, écrites le jour même. Une règle, dans la procédure : après création des liens de paiement, toujours aller compter les produits chez le prestataire, et tous les déclarer. Et un garde-fou dans le code : un paiement que la chaîne ne reconnaît pas ne disparaît plus en silence, il déclenche un mail qui me dit combien de paiements sont concernés et quoi corriger. C'est le genre de défaut qu'on ne voit pas venir, et c'est exactement pour ça que je préfère le raconter.

Trois autres projets réels