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 programme et son étape de candidature, son consentement marketing, et son historique d'échanges. Il n'a pas besoin d'accéder au détail du dossier académique, aux décisions d'admission ou aux renseignements 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 renseignements personnels 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 au Québec.

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 programme est devenu candidat inscrit — que ce prospect vienne d'un cégep ou directement d'une admission universitaire.

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 un renseignement 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 programme relève de l'agent ; écrire dans Application Decision relève d'une personne habilitée.

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 de l'agent conversationnel : c'est un choix que les équipes TI de l'établissement arbitrent au moment de créer la connexion, indépendamment de l'outil connecté.

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

Au Québec, la Loi 25 (loi modernisant des dispositions législatives en matière de protection des renseignements personnels) encadre la collecte et l'usage des renseignements personnels depuis son entrée en vigueur complète le 22 septembre 2023, et exige que la collecte se limite à ce qui est nécessaire à la finalité poursuivie. La Commission d'accès à l'information (CAI) rappelle ce principe pour les organismes publics, catégorie qui couvre la plupart des cégeps et universités québécoises au sens de la Loi sur l'accès aux documents des organismes publics. 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 cette 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 comité compétent. Les données qui servent à établir une cote R ou à documenter un dossier auprès du Bureau de coopération interuniversitaire (BCI) relèvent d'un processus documenté par l'établissement, pas d'une écriture automatisée par un agent de premier contact.

La Loi 25 va plus loin que le simple principe de minimisation : elle impose de détruire ou d'anonymiser les renseignements personnels une fois la finalité de leur collecte atteinte. 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 ; la durée de conservation des données conversationnelles doit être alignée sur celle du cycle de vie du dossier dans Education Cloud, avec une purge documentée.

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

Le Québec n'a pas d'équivalent de Parcoursup, mais il a sa propre logique en deux temps. Pour l'admission au collégial (cégep), la demande transite par un service régional — SRAM pour la grande région de Montréal, SRACQ pour la région de Québec, SRASL pour le Saguenay-Lac-Saint-Jean. Pour l'université, la candidature se dépose directement auprès de chaque établissement, sans plateforme commune.

Un agent IA bien paramétré sait reconnaître, dans le champ Application Stage Definition, le moment où un prospect devient candidat au sens strict — dossier déposé au SRAM/SRACQ pour un DEC, ou directement à l'université pour un baccalauréat — 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 bureau des admissions et du comité de sélection.

Comment cela s'articule avec un chatbot comme Skolbot

Skolbot est conçu comme une couche IA au-dessus du CRM existant de l'établissement, 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 comité d'admission.

Pour approfondir le choix d'un CRM adapté à l'enseignement supérieur, notre comparatif des CRM pour établissements d'enseignement supérieur détaille les options du marché et leurs critères d'intégration. Sur la priorisation des prospects une fois les renseignements qualifiés, consultez notre guide du pointage des prospects étudiants.