Une intégration avec le système d'information étudiant est ce qui permet à un site web universitaire d'afficher les catalogues de cours, les emplois du temps et les prérequis des programmes sans que personne n'ait à les ressaisir. Les données résident dans Banner, PeopleSoft, Workday ou un système interne ; Drupal les lit, les met en forme et les publie. Dans cet article, nous présentons les trois modèles que peut suivre une telle intégration, la façon dont chacune des principales plateformes expose ses données, quel système devrait posséder quoi, et les points de rupture à anticiper avant le premier changement de semestre.

La plupart des descriptions de ce sujet se limitent à une seule phrase : Drupal s'intègre avec les systèmes d'information étudiant. C'est vrai, mais peu utile. Les questions auxquelles une équipe web est réellement confrontée sont différentes. Les données de cours sont-elles copiées dans Drupal ou lues en direct ? Que se passe-t-il lorsque le service de la scolarité supprime une section en cours de semestre ? Où vit le texte marketing d'un programme si la description officielle se trouve dans le SIS ? Lequel des deux systèmes fait foi lorsqu'ils divergent ? Ci-dessous, nous examinons ces questions avec les plateformes utilisées par la plupart des universités.

Ce que fait réellement une intégration avec le système d'information étudiant sur un site web universitaire

Le système d'information étudiant est le système de référence de l'établissement pour les données académiques. Il contient le catalogue de cours, l'emploi du temps, les prérequis de programmes et de diplômes, les inscriptions, les notes, les relevés de notes et le calendrier académique. Rien sur le site web public ne devrait le contredire.

Le site web, quant à lui, est l'endroit où la plupart de ces données sont réellement consultées. Les futurs étudiants lisent les pages de programmes. Les étudiants actuels vérifient l'horaire d'une section. Les conseillers pédagogiques consultent les prérequis. Lorsque le site web et le SIS divergent, c'est le site web qui a tort, et les personnes qui s'en aperçoivent sont précisément celles que l'université souhaite le moins décevoir.

Une intégration supprime la double saisie entre les deux systèmes. En pratique, elle couvre une liste assez courte de types de données, et il est utile de les nommer car chacune se comporte différemment :

  • Catalogue de cours : codes de cours, titres, valeurs de crédits, descriptions et prérequis. Change quelques fois par an, lié à une année de catalogue.
  • Emploi du temps : sections, horaires, salles, enseignants et nombre de places disponibles. Change quotidiennement pendant la période d'inscription.
  • Programmes et prérequis : diplômes, spécialisations et règles qui les relient aux cours. Change rarement, mais avec une validation formelle.
  • Calendrier académique et semestres : codes de semestre, dates limites d'inscription et de désinscription, jours fériés. Petit ensemble stable, référencé par tout le reste.
  • Données propres à l'étudiant : l'emploi du temps d'un étudiant donné, ses blocages administratifs, sa progression vers le diplôme. Données personnelles, montrées uniquement à cet étudiant après authentification.

Les quatre premiers types sont des données institutionnelles et peuvent apparaître sur des pages publiques. Le dernier relève des données personnelles et suit des règles différentes, sur lesquelles nous revenons plus bas.

Trois modèles d'intégration et quand chacun s'applique

Presque toute intégration SIS sur un site Drupal correspond à l'un de trois modèles, et choisir le mauvais est la source la plus fréquente de problèmes ultérieurs. Les facteurs déterminants sont la fréquence de changement des données, le nombre de personnes qui les consultent, et le fait qu'elles appartiennent ou non à un individu.

Import planifié pour les pages de catalogue et de programme

Le SIS exporte les données de cours et de programmes selon un calendrier, généralement chaque nuit, et Drupal les importe sous forme de contenu ordinaire : un type de contenu « cours », un type de contenu « programme », des termes de taxonomie pour les matières et les semestres. L'API Migrate du noyau de Drupal s'en charge, les modules contribués Migrate Plus et Migrate Tools ajoutant des sources JSON, XML et CSV ainsi que les outils pour exécuter et annuler les imports. Le module Feeds constitue l'alternative low-code pour des flux plus simples.

Une fois importées, les données se comportent comme n'importe quel autre contenu Drupal. Elles sont indexables, mises en cache, traduisibles et référençables depuis d'autres pages. Les éditeurs peuvent y attacher des champs que le SIS ne possède pas, comme un résumé marketing, une image de mise en avant ou des témoignages, sans toucher au dossier officiel. L'University of Dundee a construit ses pages de cours de cette manière, sous forme d'entités personnalisées, les a indexées avec Search API aux côtés des personnes et des facultés, et a lancé la section des cours de premier cycle comme première version en juillet 2019.

Ce modèle convient à des données qui changent selon un cycle connu et sont lues par de nombreuses personnes. Il ne convient pas à ce qui change toutes les heures, car un import nocturne aura toujours du retard.

Lecture en direct pour la disponibilité et les emplois du temps

Ici, rien n'est copié. Drupal interroge l'API du SIS au moment où une page est demandée et affiche le résultat. Le module External Entities est conçu exactement pour cela : il définit un type d'entité dont le stockage est un point de terminaison REST distant plutôt que la base de données Drupal, de sorte que les données distantes restent utilisables avec Views, les modes d'affichage et les formateurs de champs. Views Remote Data offre une voie plus légère lorsqu'un simple listing suffit.

La lecture en direct est la bonne réponse pour le nombre de places, le statut d'une section, et tout ce pour quoi une valeur obsolète induirait en erreur. Elle a deux coûts. Chaque affichage de page devient un appel API à moins de mettre en cache soigneusement, et la disponibilité du site web dépend désormais de celle de l'API du SIS. Un cache court avec une durée de vie définie, ainsi qu'un message de repli élégant lorsque l'API est injoignable, ne sont pas des options facultatives. Sans eux, le premier jour d'inscription met le site web hors service en même temps que le SIS.

Requêtes authentifiées pour les données propres à l'étudiant

Le troisième modèle couvre le portail étudiant : mon emploi du temps, mes blocages, le suivi de mon diplôme. Les données sont récupérées à la demande pour la personne connectée, affichées une fois, et jamais stockées dans Drupal. L'identité provient de l'authentification unique du campus ; l'identifiant de l'étudiant issu de cette session est la clé sur laquelle repose la requête vers le SIS.

Ce modèle suppose que la question de l'identité soit résolue en premier, car un identifiant erroné renvoie le dossier d'un autre étudiant. Nous avons abordé les options dans l'intégration SSO avec SAML, Shibboleth, LDAP et CAS. Une fois cela en place, l'appel au SIS lui-même est généralement une seule requête vers un point de terminaison « personne » ou « étudiant », effectuée côté serveur avec les identifiants API de l'établissement, jamais exposée dans le navigateur.

Certaines universités décident que cette couche relève plutôt du produit de self-service propre à l'éditeur du SIS que du site Drupal, et se contentent d'y renvoyer par un lien. C'est un choix légitime, et souvent le moins coûteux. Drupal mérite sa place dans le portail lorsque l'établissement souhaite combiner les données du SIS avec du contenu, des actualités, des événements et des services que le SIS ignore totalement.

Connecter Drupal aux principales plateformes

Chaque éditeur expose ses données différemment, et ces différences déterminent quel modèle est réalisable.

Ellucian Banner et Colleague via Ethos

La voie recommandée par Ellucian pour l'intégration avec des tiers est Ethos, une couche REST et JSON unifiée qui se place au-dessus de Banner comme de Colleague. Ethos présente un modèle de données commun, de sorte qu'un cours, une section ou une personne ont la même structure quel que soit le produit sous-jacent, et chaque enregistrement porte un GUID plutôt qu'un identifiant propre au produit. Ethos est hébergé régionalement, avec des points de terminaison distincts pour les États-Unis, le Canada, l'Europe et l'Asie-Pacifique, ce qui compte pour les établissements ayant des exigences de résidence des données.

Pour Drupal, cela signifie qu'un seul jeu de définitions de ressources fonctionne aussi bien pour les campus sous Banner que sous Colleague, et le module External Entities peut faire correspondre le JSON d'Ethos à des champs grâce à son mappeur JSONPath. L'accès est accordé par ressource et par champ du côté d'Ellucian, si bien que la première tâche du projet consiste généralement à s'accorder avec le service de la scolarité sur les ressources dont le site web a besoin, plutôt qu'à écrire du code. Les anciens campus sous Banner sans Ethos exposent encore des API directes et des vues de base de données ; cela fonctionne, mais chaque intégration devient spécifique à ce campus.

PeopleSoft Campus Solutions

Campus Solutions d'Oracle expose les données via Integration Broker, sa couche de messagerie et de services web, en REST ou en SOAP. Les données de catalogue de cours et d'emploi du temps proviennent du module Student Records, et le concept qui piège la plupart des personnes en charge de l'intégration est la datation effective (effective dating) : un cours n'a pas une seule description, mais un historique de descriptions, chacune valable à partir d'une date donnée, et la requête doit demander la bonne pour l'année de catalogue affichée.

C'est pourquoi l'import planifié convient bien aux données de catalogue de PeopleSoft. L'import peut résoudre une fois, chaque nuit, les lignes à date effective et stocker la version en vigueur. Effectuer cette résolution à chaque requête en direct serait un gaspillage. La lecture en direct reste le bon modèle pour la disponibilité des sections, où la valeur est un simple nombre actuel.

Workday Student

Workday expose des services web REST et SOAP et, pour les extractions de type reporting, des rapports personnalisés pouvant être publiés sous forme de flux de données. En pratique, de nombreuses intégrations Workday Student reposent sur ces flux de rapports : le service de la scolarité définit un rapport contenant exactement les champs de cours et de sections que le site web peut voir, et Drupal le consomme selon un calendrier. Cette approche garde le contrat de données explicite et confie le contrôle de ce qui sort du SIS aux personnes qui en sont propriétaires.

Le modèle de semestres et de périodes académiques de Workday diffère de ceux de Banner et de PeopleSoft, si bien que le mappage des champs mérite une session de conception à part entière plutôt que d'être repris d'un projet précédent.

Systèmes internes et régionaux

De nombreuses universités exploitent leur propre système, une plateforme nationale ou le produit d'un éditeur régional. Le modèle ne change pas ; seul le mode de transport change. Si le système dispose d'une API, External Entities ou un plugin de source Migrate personnalisé peut la consommer. S'il ne peut produire que des fichiers, un dépôt planifié de CSV ou XML sur un emplacement SFTP suivi d'un import via Migrate constitue une intégration tout à fait respectable, et souvent plus fiable qu'une API fragile. L'essentiel est de s'accorder sur le contrat de données et le calendrier, puis de maintenir les deux stables.

Quel système détient les données

La décision la plus importante du projet n'est pas technique. C'est un énoncé de qui possède quels champs.

Le SIS possède tout ce qui est académique et officiel : codes de cours, titres, crédits, prérequis, exigences, horaires, dates de semestre. Drupal ne modifie jamais ces données ; il les affiche seulement. Si une description de cours est erronée sur le site web, la correction se fait dans le SIS et se répercute au prochain import.

Drupal possède tout ce pour quoi le SIS n'a jamais été conçu : le récit marketing du programme, les citations du corps enseignant, les débouchés professionnels, l'imagerie, les appels à l'action, les traductions et les métadonnées pour les moteurs de recherche. Ces champs vivent du côté de Drupal, rattachés au dossier importé mais stockés séparément, de sorte qu'un import n'écrase jamais le travail d'un éditeur.

Consigner cela dans un tableau champ par champ, validé par le service de la scolarité et l'équipe web avant toute construction, évite les deux désaccords les plus fréquents par la suite : un éditeur qui a modifié une valeur de crédits sur le site web et l'a vue écrasée du jour au lendemain, et un service de la scolarité qui ne comprend pas pourquoi un cours qu'il a supprimé apparaît toujours sur une page d'atterrissage construite à la main.

L'écriture inverse de Drupal vers le SIS, où un formulaire web crée ou modifie un enregistrement du SIS, est possible via Ethos et Integration Broker, mais elle relève d'une catégorie de risque différente. La plupart des établissements font transiter les actions de candidature et d'inscription par les propres produits de l'éditeur du SIS ou par un CRM d'admission, et maintiennent le site web en lecture seule vis-à-vis du SIS. C'est le choix par défaut raisonnable.

Confidentialité des étudiants dans la couche d'intégration : FERPA et RGPD

Dès qu'une intégration touche des données propres à un étudiant, elle traite des données réglementées. Aux États-Unis, le FERPA distingue les dossiers éducatifs, dont la divulgation nécessite un consentement, des informations d'annuaire comme le nom et le programme, qu'un établissement peut diffuser sauf opposition de l'étudiant. Dans l'Union européenne et au Royaume-Uni, le RGPD s'applique à toute donnée personnelle, et les principes de limitation des finalités et de minimisation des données encadrent la quantité que le site web peut récupérer.

Trois règles maintiennent une intégration Drupal conforme aux deux régimes :

  • Données institutionnelles sur les pages publiques, données personnelles uniquement derrière authentification. Les catalogues et emplois du temps sont institutionnels. L'emploi du temps propre à un étudiant est personnel.
  • Récupérer les données personnelles à la demande et ne pas les stocker. Le modèle de requête authentifiée existe pour cette raison précise. Aucun dossier d'étudiant ne devrait se trouver dans une table Drupal ou dans un cache de page auquel un autre utilisateur pourrait accéder.
  • Ne demander que les champs utilisés par la page. Ethos comme les flux de rapports Workday permettent à l'établissement de restreindre l'accès champ par champ. Une restriction étroite est le contrôle de conformité le moins coûteux disponible.

Consigner quel compte système a récupéré quoi, et quand, referme la boucle pour l'audit. Nous avons traité les obligations plus larges dans atteindre la conformité RGPD avec Drupal ; la couche d'intégration est l'endroit où beaucoup d'entre elles deviennent concrètes.

Ce qui pose problème en pratique et comment l'anticiper

Les intégrations échouent rarement le jour du lancement. Elles échouent au premier événement que la conception n'avait pas anticipé. Voici ceux qui reviennent le plus souvent.

  • Changement de semestre. Le SIS ouvre un nouveau semestre alors que le site web affiche encore l'ancien comme étant en cours. Modélisez les semestres explicitement dans Drupal et faites dépendre la notion de « semestre en cours » du calendrier du SIS, pas d'une date codée en dur.
  • Cours supprimés et fusionnés. Un cours disparaît de l'export, mais sa page Drupal, avec ses liens entrants et son classement dans les moteurs de recherche, reste active. Décidez à l'avance si l'import la dépublie, l'archive avec une mention, ou la redirige vers un successeur.
  • Changements à date effective. Une description valable à partir de l'année de catalogue suivante apparaît sur la page de l'année en cours parce que la requête n'a pas filtré par date. C'est un cas classique chez PeopleSoft, mais le concept existe partout.
  • Invalidation du cache. Les données lues en direct sont mises en cache pour la performance, puis un nombre de places reste à zéro pendant une heure après leur libération. Définissez la durée de vie par type de donnée, et réduisez-la pendant les fenêtres d'inscription.
  • Limites et pannes d'API. Un bloc de la page d'accueil qui appelle le SIS à chaque requête épuisera une limite de débit dès la première matinée chargée. Mettez en cache de façon agressive, dégradez avec élégance, et ne laissez jamais une panne du SIS produire une page blanche.
  • Incohérences d'identifiants. L'identité SSO utilise un identifiant et le SIS un autre. Mettez-vous d'accord sur la correspondance avant de construire le portail, et testez-la avec de vrais comptes, y compris des cas limites comme le personnel qui est également étudiant.

Rien de tout cela n'est exotique. Un runbook d'une page couvrant ces cas, rédigé avant le lancement, vaut plus que la majeure partie du code.

Jusqu'où l'intégration doit-elle aller ?

Toutes les universités n'ont pas besoin des trois modèles, et construire des fonctionnalités de portail que personne n'utilise est une façon courante de dépenser plus que nécessaire.

Un site de niveau brochure n'a besoin que de pages de programme, et celles-ci peuvent être maintenues manuellement si la liste des programmes est courte et stable. Un site de niveau catalogue a besoin de l'import planifié ; c'est là que réside l'essentiel de la valeur pour la plupart des établissements, car cela supprime la ressaisie sur des centaines de pages. Un site de niveau portail ajoute des requêtes authentifiées et n'en vaut la peine que lorsque l'établissement souhaite une porte d'entrée unique combinant les données du SIS avec tout ce que le campus publie par ailleurs. La différence de coût entre ces niveaux est substantielle, et notre analyse du coût total de possession des systèmes open source par rapport aux systèmes sous licence explique comment mettre en balance l'effort d'implémentation et les économies de licence.

Il est également utile de préciser ce que n'est pas l'intégration SIS. Ce n'est pas l'intégration du système de gestion de l'apprentissage (LMS). Le SIS enregistre qu'un étudiant est inscrit à une section ; le LMS livre cette section. Les deux intégrations déplacent des données différentes, généralement via des API différentes, et il est préférable de les scoper comme des chantiers distincts, même lorsqu'ils tombent sur le même semestre.

Planifier votre première intégration

Le travail technique d'une intégration SIS est plus modeste qu'il n'y paraît. La partie la plus importante est l'accord : quels champs le site web peut lire, quel système possède chacun d'eux, à quelle fréquence chaque type se rafraîchit, et ce qui se passe au changement de semestre. Les universités qui règlent d'abord ces questions avec le service de la scolarité ont tendance à ne construire l'intégration qu'une seule fois. Celles qui partent de la documentation de l'API ont tendance à la construire deux fois.

Les plateformes Drupal que l'équipe Drupal4edu chez Drupart a construites pour des établissements comme l'Université Sabancı, la METU et l'Université technique Yıldız sont conçues précisément autour de ce type de couche d'intégration, où le site web lit les systèmes de référence de l'établissement plutôt que de les dupliquer. Vous pouvez en savoir plus sur notre approche sur la page Drupal pour l'éducation.

Questions fréquentes sur l'intégration Drupal-SIS

Drupal peut-il s'intégrer avec Ellucian Banner ?

Oui. La voie actuelle est Ellucian Ethos, une couche REST et JSON qui présente les données de Banner et Colleague dans un modèle commun avec des identifiants GUID. Drupal lit les ressources d'Ethos soit de façon planifiée, en utilisant l'API Migrate pour importer les cours et programmes comme contenu, soit en direct, en utilisant le module External Entities pour afficher les enregistrements distants sans les stocker. L'accès est délimité par ressource et par champ du côté d'Ellucian, si bien que le service de la scolarité contrôle précisément quelles données le site web peut voir. Les installations Banner plus anciennes sans Ethos peuvent encore être intégrées via des API directes ou des vues de base de données, mais chaque intégration de ce type est propre à ce campus.

Drupal stocke-t-il les données des étudiants lorsqu'il s'intègre à un SIS ?

Seulement si l'intégration est conçue ainsi, et pour les données personnelles, ce ne devrait pas être le cas. Les données institutionnelles, comme les catalogues de cours et les emplois du temps, sont normalement importées dans Drupal afin de pouvoir être indexées, mises en cache et enrichies de contenu marketing. Les données propres à un étudiant, comme son emploi du temps individuel ou ses blocages administratifs, devraient être récupérées à la demande pour l'étudiant authentifié, affichées, puis abandonnées. Aucun dossier d'étudiant n'a besoin de se trouver dans une table Drupal ou dans un cache de page partagé, et le tenir à l'écart des deux est le moyen le plus simple de satisfaire à la fois le FERPA et le RGPD.

À quelle fréquence les données de cours doivent-elles se synchroniser entre le SIS et le site web ?

Cela dépend du type de donnée. Les données de catalogue de cours et de programmes changent quelques fois par an, et un import nocturne suffit largement ; certains établissements l'exécutent même chaque semaine. Les données d'emploi du temps changent quotidiennement pendant l'inscription, ce qui nécessite soit un import plus fréquent, soit une lecture en direct avec un cache court. Le nombre de places et le statut des sections devraient être lus en direct pendant les fenêtres d'inscription. Promettre une synchronisation en temps réel pour tout est une erreur : cela coûte en performance et en fiabilité, et n'apporte rien pour des données qui ne changent qu'avec le calendrier académique.

Quelle est la différence entre l'intégration SIS et l'intégration LMS ?

Elles déplacent des données différentes. Le système d'information étudiant est le système de référence pour les inscriptions, les cours et l'historique académique. Le système de gestion de l'apprentissage (LMS), comme Moodle ou Canvas, est l'endroit où se déroule l'enseignement : supports de cours, devoirs et notes en cours d'attribution. Une intégration SIS apporte au site web les données de catalogue, d'emploi du temps et d'inscription. Une intégration LMS concerne généralement l'authentification unique et le lien entre les étudiants du site web et leur espace de cours. Nous décrivons le volet LMS dans l'intégration Moodle et Drupal. Il est préférable de scoper les deux projets séparément, même lorsqu'ils partagent une date de lancement.

Une intégration Drupal-SIS est-elle conforme au FERPA ?

La conformité est une propriété de l'ensemble de la conception, pas d'un logiciel en particulier. Une intégration Drupal peut être construite pour répondre aux obligations du FERPA en gardant les dossiers éducatifs derrière une authentification, en les récupérant à la demande plutôt qu'en les stockant, en ne demandant que les champs utilisés par une page, et en consignant quel compte système a accédé à quoi. Les informations d'annuaire, comme les listes de cours et les noms des enseignants, peuvent apparaître publiquement sauf indication contraire de la politique de l'établissement ou d'une opposition de l'étudiant. C'est le service de la scolarité, et non l'équipe web, qui décide quels champs relèvent de quelle catégorie, et cette décision devrait être documentée avant la construction de l'intégration.

Dernière mise à jour: 15.09.2026 14:25