Construire une plateforme de données étudiante : données first-party de la demande à l'obtention du diplôme

Une université gérant 20 000 étudiants dispose généralement des données de cette population étudiante fragmentées dans 8 à 15 systèmes différents : un CRM d’admissions, un système d’information étudiant (SIS), un LMS, une plateforme de gestion financière, un outil de gestion des cas de bien-être, un système de bibliothèque, une plateforme carrières, un système de gestion des résidences et plusieurs tableurs au niveau des départements.

Chaque système connaît une chose sur l’étudiant. Aucun ne connaît tout. Le CRM d’admissions sait comment l’étudiant a été recruté. Le système d’information étudiant connaît ses notes. Le LMS connaît son engagement envers l’apprentissage en ligne. Le système de bien-être sait qu’il a assisté à trois séances de conseil en octobre. Le système de bibliothèque sait qu’il n’y a pas accédé depuis novembre. Aucun de ces systèmes ne communique avec les autres.

Le résultat : l’étudiant confronté au risque d’abandon le plus élevé dans l’établissement est invisible pour le système de rétention car aucun système unique n’a la vision complète. L’étudiant le plus susceptible de répondre à un appel à bourse est invisible pour l’équipe de développement car le système d’aide financière et le système de communication alumni ne sont pas connectés.

Une plateforme de données étudiante résout ce problème en créant un profil unifié qui agrège toutes les sources de données dans un seul enregistrement de contact — accessible en temps réel, mis à jour automatiquement et actionnable via des canaux de communication connectés.

Les sources de données à unifier

Données de pré-inscription :

• Source de la demande (quel canal, quelle campagne, quel événement)
• Date de la demande et délai de réponse
• Présence aux journées portes ouvertes
• Délai de complétion de la candidature
• Demandes de bourse
• Décision d’acceptation et réponse

Données d’inscription :

• Programme, année d’entrée, cohorte d’admission
• Type et lieu de logement
• Statut et montant de l’aide financière
• Classification international/national
• Qualifications d’entrée

Données d’engagement académique :

• Inscription et complétion de modules
• Notes et trajectoire des évaluations
• Relevés de présence (cours magistraux, séminaires, travaux dirigés)
• Fréquence de connexion et activité sur le LMS
• Accès à la bibliothèque et utilisation des ressources

Données de vie sur le campus :

• Activités sportives et extrascolaires
• Adhésion au syndicat étudiant
• Utilisation des équipements du campus (salle de sport, cafétéria, espaces communs)
• Indicateurs du réseau de pairs (lorsque disponibles)

Données financières :

• Statut de paiement des frais
• Demandes au fonds d’aide sociale
• Versement des bourses et allocations
• Statut d’emploi à temps partiel (si déclaré)

Données de communication :

• Historique des messages WhatsApp et taux de réponse
• Taux d’ouverture et de clics des e-mails
• Historique de réception et de réponse aux SMS
• Journal des interactions avec l’équipe de soutien

L’architecture technique

Une plateforme de données étudiante ne nécessite pas de remplacer les systèmes existants. Elle se positionne comme une couche d’intégration au-dessus d’eux :

Connecteurs de données : Des API reliant chaque système existant à la plateforme centrale. Le CRM d’admissions, le SIS, le LMS et la plateforme financière transmettent tous des mises à jour à la plateforme de données étudiante via webhook ou synchronisation planifiée.

Résolution d’identité : Lorsque le même étudiant apparaît dans plusieurs systèmes (souvent avec des orthographes légèrement différentes du nom, des adresses e-mail différentes ou des identifiants étudiants différents), la plateforme les résout en un seul profil canonique en utilisant la correspondance nom + date de naissance + numéro d’étudiant.

Streaming d’événements en temps réel : Les signaux à haute priorité (un étudiant échoue à une évaluation, un paiement de frais est refusé, un étudiant signale une préoccupation de bien-être) se transmettent en temps réel au profil unifié et peuvent déclencher des flux de travail de communication immédiats.

Couche de communication : Le profil unifié se connecte à l’API WhatsApp Business, à la plateforme e-mail et à la passerelle SMS — permettant à tous les canaux de communication d’accéder au même profil étudiant complet.

GDPR et gouvernance des données

Une plateforme de données étudiante agrège des données personnelles sensibles — performance académique, situation financière, informations de santé et de bien-être. Cela nécessite un cadre clair de gouvernance des données :

• Une base légale pour chaque activité de traitement des données (généralement la nécessité contractuelle pour les dossiers académiques, l’intérêt légitime pour les analyses d’engagement, le consentement explicite pour les communications marketing)
• Une politique de conservation des données spécifiant combien de temps chaque catégorie de données est conservée après le départ d’un étudiant
• Des contrôles d’accès limitant quels membres du personnel peuvent voir quelles catégories de données (le personnel académique ne doit pas voir les données de difficultés financières ; le personnel des admissions ne doit pas voir les dossiers de conseil)
• Un avis de confidentialité destiné aux étudiants qui explique clairement quelles données sont conservées et pourquoi

La charge de conformité GDPR d’une plateforme de données étudiante est gérable — la plupart des universités sont déjà des responsables de traitement de ces informations. La plateforme modifie la façon dont les données sont stockées et consultées, pas le fait que l’établissement les détient.

Pour la capture par QR code qui alimente les données de l’étape de demande, voir Pourquoi les écoles passent de Google Forms à la capture de données par QR code. Pour la stratégie de données alumni qui étend la plateforme au-delà de l’obtention du diplôme, voir Programmes d’engagement des anciens élèves qui génèrent réellement des dons et des recommandations.