--- title: "Education Cloud : quelles données pour un agent IA admissions ?" description: "Salesforce Education Cloud sépare identité, candidature et dossier académique en objets distincts : ce qu'un agent IA de recrutement doit lire, écrire ou ignorer au Québec." url: "https://www.skolbot.ai/fr-CA/blog/education-cloud-donnees-admission-agent-ia" language: "fr" dateModified: "2026-09-25" --- # Education Cloud : quelles données pour un agent IA admissions ? Mis à jour le 25 septembre 2026 Salesforce Education Cloud sépare identité, candidature et dossier académique en objets distincts : ce qu'un agent IA de recrutement doit lire, écrire ou ignorer au Québec. ## 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](https://github.com/SalesforceFoundation/EDA). 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](https://help.salesforce.com/s/articleView?id=sfdo.eda_explained.htm). 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](https://help.salesforce.com/s/articleView?id=sfdo.EDA_Program_Enrollment.htm)). 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](https://www.salesforce.com/agentforce/use-cases/education/recruitment-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. | Catégorie de donnée | Objet Education Cloud concerné | Lecture agent IA | Écriture agent IA | Pourquoi | |---|---|---|---|---| | Identité et coordonnées | Contact | Oui | Oui (mise à jour) | Éviter de redemander une information déjà connue | | Intérêt de programme / étape de candidature | Program Enrollment, Applicant, Application Stage Definition | Oui | Proposition, validée par un conseiller | Répondre précisément à « où en est mon dossier » | | Consentement marketing et préférence de contact | Contact (champs de consentement) | Oui | Oui (enregistrement du consentement donné en conversation) | Condition légale du traitement | | Historique d'engagement (questions posées, échanges) | Case / journal d'interactions | Oui | Oui (ajout) | Éviter les questions répétées, affiner la réponse | | Dossier académique détaillé (cote R, décision d'admission) | Academic Certification, Application Decision, Application Review | Non par défaut | Non | Décision humaine, risque de discrimination perçue | | Détail de l'aide financière | Objets d'aide financière | Non par défaut | Non | Renseignement financier sensible, hors périmètre d'un agent de premier niveau | 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](https://help.salesforce.com/s/articleView?language=en_US&id=platform.users_profiles_field_perms.htm&type=5)). 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)](https://www.cai.gouv.qc.ca/protection-renseignements-personnels/sujets-et-domaines-dinteret/principaux-changements-loi-25) 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)](https://www.bci-qc.ca) 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](https://www.sram.qc.ca) 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 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](https://www.skolbot.ai/fr-CA/blog/crm-ecole-superieure-comparatif) 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](https://www.skolbot.ai/fr-CA/blog/scoring-lead-etudiant-ecole). --- Testez Skolbot sur votre école en 30 secondes ## FAQ ### Un agent IA doit-il avoir un accès en écriture à Salesforce Education Cloud ? Oui, mais limité. Un agent IA peut écrire dans les objets qui décrivent l'engagement et l'intérêt d'un prospect (mise à jour de coordonnées, enregistrement d'un consentement, note sur un programme visé). Il ne doit pas écrire dans les objets de décision d'admission ou de dossier académique détaillé, qui relèvent d'une validation humaine. ### Quelle est la différence entre l'EDA et le module Recruitment and Admissions ? L'EDA (Education Data Architecture) est le socle : elle ajoute à Salesforce les objets génériques d'un établissement d'enseignement (Affiliation, Program Enrollment, Course Connection). Le module Recruitment and Admissions vient au-dessus et ajoute les objets spécifiques au recrutement (Applicant, Application Decision, Application Stage Definition), disponibles dans le [modèle de données Education Cloud](https://www.salesforce.com/agentforce/use-cases/education/recruitment-admissions/). ### Un agent IA peut-il annoncer une décision d'admission à un candidat ? Non, pas par défaut. La décision d'admission (Application Decision) doit rester une donnée en lecture seule pour l'agent, voire hors de son périmètre de lecture, tant que le comité d'admission ne l'a pas validée et communiquée par le canal officiel de l'établissement. ### La Loi 25 change-t-elle la manière de configurer un agent IA sur Education Cloud ? Oui, indirectement. La Loi 25 n'impose pas de configuration technique précise, mais son exigence de minimisation et de transparence sur les finalités du traitement pousse à documenter, dès la mise en place de l'agent, quels objets Education Cloud il consulte et modifie, et pourquoi. ### Salesforce propose-t-il des agents IA préconfigurés pour l'admission ? Oui. Sous la marque Agentforce for Education, Salesforce propose des compétences d'agent préconfigurées couvrant le recrutement, les admissions, la réussite étudiante et les relations avec les diplômés, construites sur les données du modèle Education Cloud ([page Agentforce Recruitment & Admissions](https://www.salesforce.com/agentforce/use-cases/education/recruitment-admissions/)). Cela ne dispense pas l'établissement de définir lui-même quels renseignements cet agent peut lire et écrire.