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 de bourse. 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.

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.

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 DSI de l'école arbitre au moment de créer la connexion, indépendamment de l'outil connecté.

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

Le RGPD (Règlement 2016/679) 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. La CNIL 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 la commission compétente. Les données qui alimentent l'accréditation d'un programme — celles que consulte la CTI pour un titre d'ingénieur, ou le département enseignement supérieur privé de l'Hcéres pour un diplôme visé de gestion, qui a repris mi-2026 les missions de l'ex-CEFDG — relèvent d'un processus documenté, 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. La CNIL 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

Le modèle de données Education Cloud distingue nettement le prospect (un visiteur qui manifeste un intérêt) du candidat (une personne qui a déposé un dossier). En France, cette frontière recoupe largement celle de Parcoursup pour les formations concernées : avant le vœu, un lycéen est un prospect qui échange librement avec l'école ; après le dépôt du dossier dans Parcoursup ou directement auprès d'une école membre de la Conférence des Grandes Écoles, il devient candidat, et certaines informations de son dossier (rang de vœu, réponses officielles) ne transitent plus par un agent conversationnel mais par la plateforme nationale elle-même.

Un agent IA bien paramétré sait reconnaître ce changement de statut dans le champ Application Stage Definition et adapter son discours : il continue à informer, mais il cesse de se comporter comme un canal officiel de décision — ce rôle reste celui de la plateforme et de la commission d'admission.

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 à la commission 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. Et pour les écoles qui engagent leurs prospects sur WhatsApp en parallèle du site, notre article sur Salesforce et les rappels WhatsApp en admissions détaille une autre brique de cette même logique de synchronisation CRM.