# Antipatterns des modules de don associatifs : ce qu’on voit trop souvent

> Montants figés dans le code, aucun reçu généré, pas de rapprochement bancaire possible : le module de don d'agence cumule souvent les mêmes erreurs.

- Auteur : WordPress Développement
- Publié le : 2023-05-06
- Mis à jour le : 2023-05-06
- Catégorie : Extensions
- URL : https://www.wpmoderne.fr/extensions/antipatterns-modules-don-associatifs/

## L’essentiel

- Des montants en dur dans le template interdisent toute campagne de fin d'année flexible
- L'absence de reçu fiscal automatique reporte une charge manuelle invisible sur l'association
- Sans identifiant de rapprochement, chaque don doit être recherché à la main dans la banque

« Le montant à 50 € ne correspond plus à notre campagne, il faut changer le code » — ce ticket de support, une trésorière bénévole ne devrait jamais avoir à l'écrire. Il révèle pourtant l'un des antipatterns les plus fréquents des modules de don développés pour des associations : des montants suggérés codés en dur dans le template PHP, modifiables uniquement par un développeur.

Cet article recense les erreurs récurrentes observées sur des modules de don d'agence, à l'exclusion du tutoriel d'intégration de Stripe Checkout lui-même, déjà traité séparément. L'objectif n'est pas de blâmer les développeurs qui les ont écrits — souvent sous contrainte de budget serré — mais d'identifier les points qui coûtent le plus cher à l'association une fois le module en production.

## Montants en dur dans le template

Ce qu'on voit : une liste de boutons avec des valeurs codées directement dans le fichier de template, du type `<button data-montant="20">20 €</button>`, répétée pour chaque montant proposé.

Pourquoi c'est un problème : chaque campagne (Téléthon, appel de fin d'année, urgence humanitaire) a ses propres montants suggérés, et une association qui doit rouvrir un ticket de développement à chaque campagne perd en réactivité et en budget.

Quoi faire : exposer les montants suggérés comme un réglage de l'extension, stocké en option WordPress et modifiable depuis l'administration, avec une valeur par défaut raisonnable en cas d'oubli de configuration.

```
$montants = get_option( 'wpm_don_montants_suggeres', array( 10, 20, 50, 100 ) );

foreach ( $montants as $montant ) {
    printf(
        '<button type="button" data-montant="%d">%d €</button>',
        (int) $montant,
        (int) $montant
    );
}
```

## Absence de reçu fiscal automatique

Ce qu'on voit : un module qui encaisse le don via Stripe ou PayPal, envoie un e-mail de remerciement générique, et s'arrête là — libre à la trésorière de générer les reçus fiscaux (Cerfa 11580) manuellement, un par un, en fin d'année.

Pourquoi c'est un problème : pour une association qui reçoit plusieurs centaines de dons annuels, cette tâche manuelle représente des dizaines d'heures de travail bénévole, avec un risque d'erreur ou d'oubli qui prive le donateur de sa réduction d'impôt.

> L'essentiel à retenir : Des montants en dur dans le template interdisent toute campagne de fin d'année flexible ; L'absence de reçu fiscal automatique reporte une charge manuelle invisible sur l'association ; Sans identifiant de rapprochement, chaque don doit être recherché à la main dans la banque

Quoi faire : générer le reçu au format PDF automatiquement à la confirmation du paiement, avec les mentions obligatoires (identité de l'association, numéro d'agrément le cas échéant, montant, date, mention du régime fiscal applicable), et l'envoyer par e-mail immédiatement.

## Pas de rapprochement bancaire possible

Ce qu'on voit : le don est enregistré côté WordPress avec un identifiant interne, mais aucun lien explicite n'est conservé avec l'identifiant de transaction du prestataire de paiement (Stripe, PayPal, HelloAsso).

Pourquoi c'est un problème : au moment du rapprochement comptable mensuel, la trésorière doit rechercher manuellement chaque virement reçu et le faire correspondre à un don enregistré sur le site, en croisant des montants et des dates approximatifs.

Quoi faire : stocker systématiquement l'identifiant de transaction du prestataire (`payment_intent` Stripe, par exemple) comme métadonnée du don, et exposer un export CSV incluant cet identifiant pour faciliter le rapprochement dans le logiciel comptable de l'association.

## Autres erreurs récurrentes, plus discrètes

- Le don récurrent (prélèvement mensuel) n'a aucun moyen d'être résilié par le donateur lui-même, qui doit contacter l'association par e-mail pour l'arrêter.
- Aucune distinction n'est faite entre un don ponctuel et une cotisation d'adhésion, alors que leur traitement fiscal et comptable diffère.
- Le tableau de bord ne montre aucun total consolidé par campagne, obligeant l'association à recompter manuellement dans un tableur.

> Le conseil qu'on donne systématiquement avant de livrer un module de don : demander à la trésorière bénévole, pas seulement au président de l'association, de valider le flux de bout en bout. C'est souvent elle qui découvre les manques que le cahier des charges initial n'avait pas anticipés.

## En résumé

Un module de don techniquement fonctionnel — qui encaisse correctement le paiement — peut malgré tout devenir un fardeau opérationnel pour une association si trois éléments manquent : la flexibilité des montants, l'automatisation du reçu fiscal et la traçabilité pour le rapprochement bancaire. Ces trois points, faciles à anticiper en amont, sont coûteux à ajouter après coup une fois que des centaines de dons ont déjà été collectés sans eux.