RÉPONSE RAPIDE

Un rapport de paiements indique quel argent est arrivé. Il ne peut pas, à lui seul, dire qui est membre ni qui peut voter. HelloAsso enregistre séparément les commandes, les articles et les paiements ; une commande peut même être gratuite. Ce sont les règles de votre association qui déterminent l'adhésion et le droit de vote. Avant la prochaine assemblée générale, constituez un registre unique qui relie ces règles à de vraies personnes et à de vraies commandes. Si ce registre exige chaque année un travail d'enquête sur tableur, c'est le système qu'il faut corriger.

Imaginez la personne chargée du secrétariat d'une association française, la semaine précédant son assemblée générale. Le trésorier exporte les paiements. Le responsable des adhésions exporte les inscriptions. Les deux fichiers semblent complets. Une personne a payé pour deux places. Une autre s'est inscrite par une catégorie gratuite. Une troisième a payé en plusieurs fois. Quels noms doivent figurer sur la liste des votants ?

La réponse ne se trouve dans aucun des deux exports pris isolément. Ce n'est pas un défaut de HelloAsso. C'est un décalage entre ce qu'un système de paiement enregistre et ce dont une association a besoin pour décider.

Un paiement prouve que de l'argent a circulé, pas qu'il y a adhésion

La documentation de l'API HelloAsso distingue une commande, les articles qu'elle contient et les paiements qui lui sont rattachés. Une commande peut être gratuite ou réglée en plusieurs échéances. Un seul paiement peut couvrir plusieurs articles. Une campagne peut vendre des billets d'événement, collecter des dons ou collecter des adhésions.

Une ligne dans un export de paiements prouve donc qu'une transaction a été enregistrée. Elle ne dit pas si l'article était une adhésion, à qui cette adhésion appartient, si elle est à jour, ni si cette personne a le droit de vote. La même personne peut apparaître dans plusieurs commandes, alors qu'une même commande peut concerner plusieurs personnes ou plusieurs finalités.

Figure 1Preuves d'adhésion

L'argent reçu n'est pas une liste de votants.

Chaque système répond à une question différente. C'est à l'association d'écrire la règle qui les relie.

Figure 1Un paiement est un événement. L'adhésion et le vote sont des décisions.Documentation de l'API HelloAsso et Informations officielles sur les cotisations. Modèle explicatif, et non données mesurées sur des associations.

Vos statuts déterminent qui est membre et qui vote

C'est l'association qui décide. Le portail officiel des associations indique que la cotisation n'est pas systématique. Elle peut s'appliquer à tous les membres ou seulement à certaines catégories, et ce sont les règles de l'association qui en fixent le montant et la période de paiement. Son guide de rédaction des statuts précise que les statuts peuvent fixer l'admission, la radiation, la gouvernance et les pouvoirs des membres.

Cela donne une séquence claire : lire les statuts et le règlement intérieur éventuel, identifier les catégories de membres et leurs conditions, puis décider quelle preuve, dans la plateforme, établit chaque condition. Le paiement peut être l'une de ces conditions. Il n'est pas une définition universelle de l'adhésion. Le droit de vote exige sa propre règle.

C'est la distinction qui compte avant une assemblée. Un export de paiements est une vue comptable. Une liste de votants est une décision de gouvernance. Les traiter comme un seul et même fichier peut donner un décompte bien net, sans que la décision de fond ait été examinée.

Les commandes gratuites et les paiements échelonnés mettent en défaut une liste fondée sur les seuls paiements

La liste peut échouer au point où une personne, un article d'adhésion et un paiement sont rapprochés. Une adhésion gratuite peut être absente d'un export de paiements. Un paiement échelonné peut créer plusieurs enregistrements de paiement pour une seule commande. Un billet d'événement ou un don peut être pris pour une cotisation si le rapport est filtré par montant plutôt que par type d'article. Une personne qui a payé peut aussi relever d'une catégorie sans droit de vote selon les règles de l'association.

Ce sont des modes de défaillance possibles, et non l'affirmation que HelloAsso aurait mal classé qui que ce soit ni que le registre de votre association serait erroné. Vous pouvez tester votre propre processus sur une poignée de commandes réelles avant de tirer cette conclusion.

Une page de remerciement ne peut pas vérifier une commande

Non. Pour une intégration HelloAsso Checkout, HelloAsso met en garde contre le fait de considérer l'URL de retour du navigateur comme une validation du paiement. Le visiteur peut fermer la page, perdre sa connexion ou modifier le code renvoyé. HelloAsso recommande de s'appuyer sur les notifications côté serveur ou sur une vérification de l'intention de paiement, et envoie des notifications distinctes pour la commande et pour le paiement.

Ce point technique a une conséquence humaine. Si un site web donne un accès réservé aux membres dès que le navigateur atterrit sur une page de remerciement, il peut prendre une décision d'adhésion avant d'avoir vérifié la commande et le paiement. Les droits à accorder dépendent toujours des règles de l'association, mais le système devrait au moins savoir ce qui s'est réellement passé.

Le registre doit montrer pourquoi chaque personne remplit les conditions

Une fiche par personne, la catégorie d'adhésion, l'article de commande concerné, les dates qui rendent l'adhésion à jour, l'état du paiement si le paiement compte, et une raison claire pour tout droit de vote. Un humain doit pouvoir corriger une exception sans modifier plusieurs listes déconnectées. Le trésorier doit néanmoins conserver un rapport de paiements, car l'argent et l'adhésion répondent à des questions différentes.

Cette raison doit être lisible par le bureau. « Actif parce que l'article d'adhésion annuelle appartient à cette personne et que les statuts en vigueur donnent une voix à cette catégorie » est une explication utile. « Actif parce qu'une ligne correspondait par e-mail » n'est qu'une supposition technique. Les gens changent d'adresse e-mail, et une personne peut payer pour le compte d'une autre. La fiche d'adhésion doit reposer sur une identité de personne stable et offrir au secrétariat un moyen de lever l'ambiguïté.

L'intégration doit signaler les exceptions plutôt que deviner

Une intégration peut rattacher une personne à une commande, classer un article d'adhésion, vérifier ses dates et y associer l'état du paiement. Elle doit aussi laisser une file visible pour les cas que les règles ne permettent pas de trancher automatiquement : un nom qui apparaît deux fois, une commande passée pour une autre personne, une admission manuelle, un remboursement, ou une catégorie d'adhésion que le système n'a jamais vue. Attribuer silencieusement une voix est la mauvaise façon de rendre le tableau de bord présentable.

Le secrétariat doit pouvoir examiner les éléments de preuve, consigner la décision et voir qui l'a prise. Le prochain bureau dispose alors d'un processus reproductible plutôt que d'une exception non documentée dans le tableur d'une seule personne. Les catégories et les droits exacts doivent venir des règles propres à l'association ; ce n'est pas à un éditeur de logiciel de les inventer.

Commencez gratuitement. Prenez vos statuts, le dernier export des adhésions et l'export des paiements. Choisissez plusieurs cas limites : un membre à adhésion gratuite, une personne qui paie en plusieurs fois, une commande comportant plusieurs articles, un adhérent dont l'adhésion a expiré et un don sans adhésion. Si vous pouvez expliquer l'adhésion et le vote de chaque personne à partir de ces enregistrements, le processus est peut-être sain. Écrivez cette règle pour que la personne qui reprendra le secrétariat puisse la reproduire.

Un tableur échoue quand la règle vit dans la tête d'un seul bénévole

Quand la réponse dépend d'un bénévole qui se souvient des colonnes à fusionner, du doublon à ignorer et de l'exception à forcer. C'est un processus d'assemblée fragile, même si le tableur final est correct. Le bénévole qui a fait le rapprochement devient le système non documenté.

Elevates peut faire correspondre les règles d'adhésion de l'association aux données réelles de commandes et d'articles HelloAsso, vérifier les événements de paiement lorsqu'il existe une intégration sur mesure, et construire un registre avec des exceptions explicites et une passation prévue. Le livrable n'est pas un énième tableau de bord de paiements. C'est une vue des adhésions que le bureau peut expliquer et que le bureau suivant peut faire fonctionner.

Si votre rapport de paiements et votre liste de votants concordent déjà parfaitement, gardez-les. Si personne ne peut montrer la règle qui les relie, travaillez avec Elevates pour rendre cette règle visible avant votre prochaine assemblée.

Nous Contacter