Bonnes pratiques

De l'Excel à la plateforme alumni : migration propre en 4 phases

Vous avez hérité d'un fichier Excel alumni de 12 onglets, 8000 lignes, et probablement un quart de doublons. La question n'est pas "faut-il migrer vers une plateforme" — c'est "comment le faire sans perdre les données utiles, sans cramer 6 mois de travail, et sans que votre nouvelle plateforme meure à peine lancée". Voici la méthode en 4 phases pratiquée sur des bases de 500 à 25 000 alumni, testée dans des contextes école d'ingénieur, business school régionale, et asso indépendante.

22 avril 2026 Lecture ~8 min Par Thibault Sabathier
TL;DR

Un Excel alumni meurt en 18 mois : doublons, RGPD ingérable, pas de self-service. Méthode de migration en 4 phases sur 6 semaines : audit des données, schéma cible, import dédoublonné, lancement par staged release. Erreurs classiques à éviter : migrer avec les bounces, lancer en juin-juillet, oublier le DPO en amont.

Pourquoi un Excel alumni meurt en 18 mois

Un fichier Excel peut gérer 500 alumni pendant 2 ans. Au-delà, trois signaux apparaissent, toujours dans le même ordre.

Signal 1 : les doublons. Après 3 ans d'existence, un fichier alumni contient typiquement 10 à 25 % de doublons — même personne, email pro puis email perso, nom de famille qui change, promo qui hésite entre l'année d'entrée et l'année de sortie. Vous ne savez plus à qui envoyer quoi. Un appel à cotisation part deux fois au même alumni : il râle, il se désabonne, il raconte.

Signal 2 : le RGPD devient ingérable. Un alumni demande "supprimez-moi de votre base". Vous ouvrez l'Excel, vous cherchez dans 12 onglets, vous trouvez 4 lignes qui le concernent, vous en oubliez une, il revient 6 mois plus tard en copiant la CNIL. De même, impossible d'attester qui a consenti à quoi, quand, pour quel usage.

Signal 3 : pas d'onboarding self-service. Un jeune diplômé ne peut pas créer son compte, mettre à jour son email, changer son adresse. Tout passe par vous. À 2 000 alumni, vous recevez ~15 modifications par semaine — soit 6 heures par mois de travail sans valeur ajoutée.

L'Excel est un outil de transition, pas un outil de gestion long terme. Quand la directrice alumni reçoit une première demande RGPD formelle et doit chercher dans 12 onglets, le signal est limpide : il faut migrer maintenant.

Phase 1 : Audit des données (1 semaine)

Migrer sans auditer, c'est importer le désordre dans une plateforme propre. Résultat : la plateforme devient sale en 6 mois. L'audit prend une semaine, pas davantage.

Étape 1 : compter ce qui compte. Cinq chiffres à produire, avec des formules Excel simples :

  • Nb lignes totales vs nb lignes uniques (clé = email + nom + promo). Écart = taux de doublons.
  • Taux de bounces : emails qui ont rebondi dans vos 3 dernières campagnes. Typiquement 8-15 % sur une base non maintenue.
  • Distribution par promo : combien d'alumni par année de diplôme. Révèle les trous historiques (souvent les promos < 2000).
  • Distribution pays : utile si la migration concerne une communauté diaspora.
  • Taux de champs vides sur les champs critiques (email, promo, consentement).

Étape 2 : classer les champs. Trois catégories. Les critiques : nom, prénom, email, promo, consentement RGPD. Sans eux, l'alumni n'existe pas dans la nouvelle base. Les utiles : ville, téléphone, LinkedIn, situation pro, secteur. Les optionnels : date de naissance, surnom, centres d'intérêt. Toute migration doit sauver 100 % des critiques et 80 % des utiles.

Étape 3 : repérer les risques RGPD. Trois à vérifier : consentement manquant (alumni jamais opt-in explicitement), emails désactivés sans désinscription formelle, données sensibles stockées sans base légale (religion, santé, opinions politiques — ça arrive plus souvent qu'on ne croit dans les fichiers asso).

Livrable de la phase 1 : un rapport d'audit de 2-3 pages avec ces chiffres et une cartographie des risques. Il servira de référence pour le DPO et justifiera le budget plateforme.

Phase 2 : Schéma cible (1 semaine)

Une fois l'audit fait, vous savez ce que vous avez. Reste à définir ce que vous voulez.

Champs obligatoires (toujours) : nom, prénom, email principal, promo (année de diplôme), diplôme (si école multi-cursus), statut du consentement RGPD avec horodatage. Cinq champs, pas plus. Si un alumni n'a pas ces cinq-là, il ne passe pas — ou il passe en "à compléter" avec un email de relance self-service.

Champs optionnels utiles : email secondaire, téléphone, ville, pays, LinkedIn, entreprise actuelle, poste actuel, secteur. Ces champs sont soit renseignés à la migration, soit complétés par l'alumni lui-même via son espace personnel — ce qui est toujours plus propre et plus légal.

Enrichissement automatique. Deux sources légales et efficaces : LinkedIn (via scraping maîtrisé conforme CGU, ou via des API agréées) pour le poste / entreprise / secteur, et la base SIRENE pour les entreprises françaises (code NAF, effectif, localisation). Un enrichissement bien fait remplit 60-70 % des champs optionnels sans intervention alumni.

Choix structurel : pré-structuré ou custom ? Une plateforme pré-structurée (Terrilink, AlumnForce, Hivebrite) impose un modèle de données mais garantit la maintenabilité. Un custom (développement Django + PostgreSQL) offre toute la souplesse du monde et coûte 40-80 k€ à construire, puis 15 k€/an à maintenir. Recommandation : pré-structuré sauf cas extrême (fédération de 15 associations avec règles hétérogènes). Pour arbitrer en détail, notre guide de choix de logiciel alumni liste 10 critères de décision.

Phase 3 : Import et dédoublonnage (2 semaines)

C'est la phase la plus technique, et celle où se joue la qualité finale de la base.

Format d'import. CSV UTF-8, séparateur virgule, première ligne = headers en snake_case (email, first_name, last_name, promotion_year, etc.). Évitez XLSX comme format d'import : Excel réinterprète les dates, écrase les zéros en tête de codes postaux, et transforme certains emails en hyperliens. CSV propre, toujours.

Règles de dédoublonnage. La clé primaire de facto d'un alumni n'est pas son email (qui change) ni son nom (qui peut changer) : c'est la combinaison email_normalisé + nom_normalisé + promo. Deux lignes avec cette clé identique = fusion. Normalisation : minuscules, accents supprimés, espaces trimés. Une règle secondaire pour les cas ambigus : si deux lignes ont même nom + même promo mais emails différents, marquer comme "candidat fusion" et traiter manuellement. Comptez ~2 heures pour 1000 lignes en fusion manuelle.

Préservation de l'historique cotisations. Si votre Excel contient un historique de cotisations, mapper ces colonnes vers la nouvelle plateforme est critique. Un alumni qui cotise depuis 2015 doit voir son statut "fidèle 10 ans" apparaître dans son profil — sinon il se sent dépossédé. Colonnes à mapper : année cotisation, montant, moyen de paiement, statut. Idéalement en table séparée (une ligne = une cotisation).

Test d'import sur 10 %. Jamais, jamais importer l'ensemble du premier coup. Toujours : un échantillon de 10 % incluant les cas limites (alumni avec 2 promos, alumni avec 3 emails, alumni décédés, alumni internationaux). Vérifier manuellement les 100 premières lignes importées. Corriger le script ou le mapping. Puis lancer le full.

Cas limites à anticiper : emails multiples (pro + perso) — garder les deux mais en hiérarchiser un comme principal. Changements de nom (mariage) — garder "nom de naissance" en champ secondaire pour retrouvabilité. Alumni décédés — statut "archivé", pas supprimé (mémoire historique + conformité). Et surtout : ne jamais importer les bounces. Un email qui bounce 3 fois doit être purgé avant import. Sinon vous polluez la réputation de votre nouveau domaine d'envoi dès la première campagne.

Phase 4 : Lancement sans le syndrome "plateforme morte"

Vous avez une base propre, importée, structurée. Si vous envoyez un mass-mail "voici votre nouvelle plateforme", vous aurez ~8 % d'adoption et une plateforme qui paraît vide pendant 6 mois. Voici comment éviter ce piège.

Staged launch : 20-50 bêta-testeurs. Pré-sélection manuelle : anciens présidents d'asso, mentors actifs, cotisants historiques, administrateurs passionnés. Vous les contactez individuellement (pas de mass-mail), vous leur demandez 2 semaines de test, vous corrigez les bugs qu'ils remontent. Ces 20-50 alumni deviennent les ambassadeurs du lancement officiel.

Premier événement exclusif dans les 30 jours. Rien de pire qu'une plateforme dont la page d'accueil affiche "Aucun événement prévu". Programmer un événement (présentiel ou webinar) dont l'inscription passe exclusivement par la plateforme. Les alumni doivent se connecter pour exister à cet événement. Adoption observée : ~40 % en 4 semaines contre 8 % en mass-mail.

Intégrer la plateforme au parcours critique. Deux flux à brancher en priorité : la cotisation annuelle (plus d'autre moyen de cotiser que via la plateforme) et, si vous êtes CGE/CTI, l'enquête d'insertion annuelle. Une fois la plateforme positionnée sur ces deux flux, elle devient indispensable — voir notre analyse sur les taux de réponse à l'enquête CGE.

Communication progressive. Semaine 1 : bêta-testeurs. Semaine 3 : anciens présidents, bureau des promos. Semaine 5 : mass-mail avec témoignages des bêta-testeurs. Semaine 8 : premier événement exclusif. La patience sur 8 semaines vaut mieux qu'un lancement raté en 2 jours.

Préparer la mécanique de bascule étudiant → alumni avant la première promo. C'est l'étape que la plupart des écoles découvrent 18 mois après la migration, quand la promo n+1 se retrouve toujours en statut « student ». Voir notre analyse dédiée : transition étudiant → alumni : pourquoi votre annuaire est probablement obsolète (et comment l'automatiser).

Erreurs classiques qui plombent la migration

Cinq erreurs reviennent dans 80 % des migrations ratées. Aucune n'est fatale, toutes coûtent 3 à 6 mois de rattrapage.

  • Migrer sans purger les bounces. Les emails morts empoisonnent votre réputation d'expéditeur dès la première campagne. +5 % de churn dès la première semaine. Purger avant import, toujours.
  • Ne pas archiver l'ancien Excel. Conservez une copie figée 12 mois minimum, avec date et responsable. Un litige RGPD, un audit comptable, une question sur un vieux cotisant : sans archive, vous êtes aveugle.
  • Lancer en juin-juillet. Les alumni partent en vacances, la plateforme reste déserte jusqu'en septembre. Lancez en mars, en septembre, ou en janvier. Jamais l'été.
  • Oublier les permissions admin. Qui voit les cotisations ? Qui peut modifier les profils ? Qui exporte la base ? Définir ces 3 rôles avant le lancement. Sinon vous aurez un président d'asso qui télécharge la base entière "pour vérifier" et crée un risque RGPD majeur.
  • Ne pas briefer le DPO en amont. La migration d'une base alumni est un traitement de données au sens RGPD. Le DPO (école ou externe) doit valider le processus, les finalités, les durées de conservation. Sans sa validation, vous pouvez être bloqué au moment du lancement. Notre check-list RGPD annuaire alumni liste les 12 points à couvrir avec le DPO.

Une migration bien menée prend 6 à 10 semaines, mobilise 0,3 ETP côté équipe alumni, et produit une base exploitable pendant 5 à 10 ans. Pour une association alumni structurée, c'est le meilleur investissement de la décennie.

Migrer votre base alumni sans casse

Terrilink inclut import CSV assisté, déduplication automatique et accompagnement de migration. 14 jours d'essai pour tester sur votre propre base.