Education Cloud : quelles données pour un agent IA admissions ?

Un agent IA n'a pas besoin de tout le schéma Education Cloud

Un agent IA de recrutement doit lire quatre catégories de données : l'identité du prospect, son intérêt de filière et son étape de candidature, son consentement marketing, et son historique d'échanges. Il n'a pas besoin d'accéder au détail des notes, aux décisions d'admission ou aux dossiers d'aide financière. Cette distinction paraît évidente une fois posée, mais elle ne l'est pas au moment de brancher un agent conversationnel sur un CRM Salesforce Education Cloud : la tentation technique est de lui donner un accès large « pour qu'il réponde à tout », ce qui pose un problème de minimisation des données avant même de poser un problème de sécurité.

Cet article détaille ce que contient réellement le modèle de données Education Cloud, quelle tranche un agent IA devrait lire et écrire, et pourquoi certains objets doivent rester hors de portée par défaut — avec les repères propres à la Fédération Wallonie-Bruxelles (FWB).

Ce que contient le modèle de données Education Cloud

Education Cloud n'est pas une table unique « étudiant » : c'est une architecture de données ouverte, l'Education Data Architecture (EDA), qui étend les objets standards Salesforce (Account, Contact) avec des objets propres à l'enseignement supérieur. Le code de référence est public sur GitHub et documenté par Salesforce.

L'EDA ajoute notamment les objets Affiliation (lien entre un contact et un établissement ou un programme), Program Enrollment (inscription à un programme), Course Connection, Academic Certification, Address, Attendance Event, Case, Course, Credential et Education History. Salesforce documente le détail de chaque objet dans son guide EDA.

Deux de ces objets sont automatiquement synchronisés : quand une fiche Program Enrollment est enregistrée pour un contact, Salesforce crée (si elle n'existe pas déjà) une Affiliation entre ce contact et le programme académique concerné, et maintient les deux en cohérence par la suite (documentation Program Enrollment). C'est ce mécanisme qui permet à un CRM de savoir, sans ressaisie, qu'un prospect intéressé par un bachelier ou un master est devenu candidat inscrit.

Au-dessus de l'EDA, le module Recruitment and Admissions d'Education Cloud ajoute une couche spécifique au recrutement : Applicant, Application Decision, Application Review, Application Stage Definition, Application Timeline. Ce sont ces objets qui tracent où en est un dossier dans le pipeline d'admission, et qui portent la décision finale (documentation Recruitment and Admissions).

Les quatre catégories de données qu'un agent IA doit lire

Un agent IA n'a besoin de circuler que dans une tranche verticale de ce modèle : les objets qui décrivent qui est le prospect, où il en est, et ce qu'il a déjà dit — pas les objets qui portent une décision ou une donnée sensible.

Cette répartition suit un principe simple : un agent qui répond à des prospects doit connaître le contexte du dossier, pas trancher le dossier. Écrire dans Program Enrollment pour signaler un changement d'intérêt de filière relève de l'agent ; écrire dans Application Decision relève d'un humain habilité.

Comment traduire cette lecture en permissions Salesforce

Cette répartition entre lecture, écriture et accès interdit n'est pas qu'une politique interne : elle se configure avec les mécanismes standards de la plateforme. Salesforce recommande d'utiliser des permission sets plutôt que des profils larges pour accorder des droits granulaires, objet par objet et champ par champ, à l'utilisateur d'intégration par lequel un agent externe s'authentifie (documentation sur les permissions de champ).

Concrètement, l'utilisateur d'intégration associé à l'agent IA reçoit un permission set limité aux objets Contact, Program Enrollment et Case en lecture-écriture, sans aucun accès — ni en lecture, ni en écriture — aux objets Application Decision, Application Review et aux objets d'aide financière. Ce paramétrage ne dépend pas du fournisseur du chatbot : c'est un choix que la direction informatique de l'établissement arbitre au moment de créer la connexion, indépendamment de l'outil connecté.

Pourquoi limiter l'accès : le principe de minimisation

La Belgique est membre de l'UE, et le RGPD s'y applique en tant que tel : il impose que les données traitées soient adéquates, pertinentes et limitées à ce qui est nécessaire au regard des finalités poursuivies. L'Autorité de protection des données (APD) a publié des repères spécifiques au contexte scolaire, et rappelle que cette minimisation vaut aussi pour les systèmes automatisés : donner à un agent conversationnel un accès en lecture-écriture à l'ensemble du schéma Education Cloud, alors que sa mission se limite à qualifier un prospect et répondre à ses questions, ne se justifie pas au regard de sa finalité.

Le risque n'est pas seulement réglementaire. Un agent capable d'écrire dans Application Decision pourrait, par erreur de configuration, communiquer une décision d'admission avant qu'elle ait été validée par le jury compétent. Les données qui alimentent l'évaluation de la qualité d'un programme — celles que consulte l'AEQES (Agence pour l'évaluation de la qualité de l'enseignement supérieur) — relèvent d'un processus documenté par l'établissement, pas d'une écriture automatisée par un agent de premier contact.

La même logique de proportionnalité s'applique à la durée de conservation. Un agent IA qui accumule indéfiniment l'historique d'échanges d'un prospect devenu candidat, puis étudiant, dépasse la finalité de qualification pour laquelle il a été connecté au CRM. L'APD recommande d'aligner la durée de conservation des données conversationnelles sur celle du cycle de vie du dossier dans Education Cloud, avec une purge documentée plutôt qu'une accumulation par défaut.

Prospect ou candidat : une distinction que l'agent doit respecter

La Fédération Wallonie-Bruxelles n'a pas de plateforme centrale d'admission comparable à Parcoursup : chaque université, chaque haute école organise sa propre inscription directe. Une exception notable concerne les filières contingentées (médecine, dentisterie, kinésithérapie), pour lesquelles l'examen d'entrée est coordonné par l'ARES (Académie de recherche et d'enseignement supérieur), qui fédère les établissements de la FWB.

Cette absence de plateforme unique change la nature du CRM : le modèle Education Cloud d'une haute école belge ou d'une université reçoit ses candidatures directement, sans étape intermédiaire nationale. Un agent IA bien paramétré sait reconnaître, dans le champ Application Stage Definition, le moment où un prospect devient candidat inscrit — et adapte son discours en conséquence : il continue à informer, mais cesse de se comporter comme un canal officiel de décision, rôle qui reste celui du secrétariat des admissions et du jury.

Comment cela s'articule avec un chatbot comme Skolbot

Skolbot est conçu comme une couche IA au-dessus du CRM existant de l'école, pas comme un remplacement de Salesforce ou de sa configuration Education Cloud. Via des connecteurs natifs, dont Salesforce, chaque conversation avec un prospect est enrichie dans le CRM : profil, questions posées, programme d'intérêt, score de maturité. Le principe reste le même que celui détaillé plus haut : l'agent alimente les objets d'engagement et d'intérêt, il ne se substitue pas au jury d'admission.

Pour approfondir le choix d'un CRM adapté à l'enseignement supérieur, notre comparatif des CRM pour écoles supérieures détaille les options du marché et leurs critères d'intégration. Sur la priorisation des prospects une fois les données qualifiées, consultez notre guide du scoring lead étudiant.