Deux cent mille fiches donateurs, chacune avec un historique de dons, des préférences de communication et une appartenance à plusieurs campagnes : c’est le volume que doit absorber l’écran d’administration d’une association nationale sans que l’équipe de gestion des dons n’attende dix secondes à chaque clic sur un filtre. L’extension d’origine, construite pour une association plus modeste, stockait chaque donateur comme un utilisateur WordPress avec des métadonnées de segmentation calculées à la volée à chaque affichage de liste.
Cet article détaille l’architecture retenue pour que les écrans d’administration restent réactifs à cette échelle. Il ne traite pas la génération du reçu fiscal Cerfa, déjà couverte par ailleurs : l’accent est mis ici sur l’indexation et la segmentation, pas sur la conformité documentaire.
Le problème : des filtres recalculés à chaque affichage
L’écran de liste des donateurs permettait de filtrer par montant cumulé de dons, par dernière date de don et par appartenance à une campagne. Chacun de ces filtres, sous l’architecture d’origine, déclenchait une agrégation sur la table des dons à chaque chargement de page, ce qui multipliait les jointures dès que plusieurs filtres étaient combinés. Au-delà de quelques dizaines de milliers de donateurs, ce calcul à la volée devenait la première cause de lenteur perçue par les équipes.
Architecture retenue
extension-dons/
├── tables/
│ ├── dons (transactionnelle, un don = une ligne)
│ ├── donateurs_segments (dénormalisée, un donateur = une ligne)
│ └── campagnes_appartenance (relation donateur ↔ campagne)
├── taches/
│ └── recalcul_segments.php (Action Scheduler, recalcul par lot)
└── recherche/
└── index_recherche.php (nom, e-mail, indexés séparément)
La table donateurs_segments est dénormalisée à dessein : elle conserve, par donateur, le montant cumulé déjà calculé, la date du dernier don et un statut de segment (« grand donateur », « récurrent », « inactif depuis douze mois »). Les filtres de l’écran d’administration interrogent uniquement cette table, jamais la table transactionnelle des dons.
Recalcul asynchrone plutôt qu’à la volée
Chaque nouveau don déclenche une mise à jour de la ligne correspondante dans donateurs_segments, mais ce recalcul complet des segments — en particulier ceux qui dépendent d’une comparaison entre donateurs, comme le classement des cent plus gros contributeurs — s’exécute par lot planifié via Action Scheduler, toutes les nuits, plutôt qu’en temps réel à chaque don.
as_schedule_recurring_action(
strtotime( '03:00:00' ),
DAY_IN_SECONDS,
'assoc_recalculer_segments_donateurs',
[],
'gestion-dons'
);
Ce choix accepte un léger différé — un segment mis à jour au plus tard le lendemain matin — contre un gain de réactivité constant sur les écrans consultés en journée par les équipes.
La recherche, un index à part
Rechercher un donateur par nom ou e-mail parmi deux cent mille fiches ne doit pas dépendre des mêmes tables que la segmentation. Une table d’index de recherche dédiée, avec une colonne FULLTEXT sur le nom et l’e-mail normalisés, répond à cette recherche indépendamment du reste de l’architecture :
ALTER TABLE {$wpdb->prefix}assoc_index_recherche
ADD FULLTEXT KEY recherche_nom_email (nom_normalise, email_normalise);
Ce que cette architecture évite
- Des jointures multiples sur la table transactionnelle des dons à chaque affichage de liste.
- Un ralentissement de la saisie d’un nouveau don le temps que tous les segments dépendants se recalculent.
- Une recherche par nom qui devient plus lente à mesure que la base de dons grossit, puisqu’elle interroge un index dédié plutôt que la table de dons elle-même.
Séparer la table qui reçoit les écritures fréquentes de la table qui répond aux filtres de lecture reste la décision la plus rentable qu’on puisse prendre sur ce type de projet, bien avant d’optimiser la moindre requête individuelle.
En résumé
À deux cent mille donateurs, calculer les segments à la volée à chaque affichage devient intenable. Une table dénormalisée dédiée aux segments, recalculée par lot planifié, associée à un index de recherche séparé de la table transactionnelle des dons, permet de garder des écrans d’administration réactifs sans complexifier la logique métier d’enregistrement d’un don.
