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 — avec les repères propres à la Suisse, un marché non-UE où le cadre légal diffère du RGPD.

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 Bachelor 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'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 du chatbot : c'est un choix que les équipes informatiques 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 proportionnalité

La Suisse n'est pas membre de l'UE, et le RGPD ne s'y applique pas directement : c'est la nouvelle Loi fédérale sur la protection des données (nLPD, en vigueur depuis le 1er septembre 2023) qui encadre le traitement des données personnelles, sous la surveillance du Préposé fédéral à la protection des données et à la transparence (PFPDT). Le principe qui s'y substitue à la minimisation du RGPD est celui de proportionnalité : seules les données appropriées et nécessaires à la finalité du traitement peuvent être collectées et utilisées.

Concrètement, ce principe conduit à la même conclusion pour un agent IA branché sur Education Cloud : donner à un agent conversationnel un accès en lecture-écriture à l'ensemble du schéma, alors que sa mission se limite à qualifier un prospect et répondre à ses questions, dépasse ce qui est nécessaire à 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 la commission compétente de l'établissement.

Les données qui alimentent l'accréditation d'un programme relèvent d'un processus documenté et audité par l'AAQ (Agence suisse d'accréditation et d'assurance qualité) ou par swissuniversities pour l'accréditation institutionnelle — 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. Le principe de proportionnalité de la nLPD invite à 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 Suisse n'a pas de plateforme d'admission centralisée comparable à Parcoursup : chaque université cantonale, chaque EPF et chaque haute école spécialisée (HES) organise sa propre procédure d'admission, avec ses délais propres. Pour les HES, swissuniversities coordonne les grandes lignes de la procédure sans se substituer à l'inscription directe auprès de l'établissement.

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é directement auprès de l'établissement, avec ses propres pièces (maturité gymnasiale, maturité professionnelle ou titre équivalent) — 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.

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, filière 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.