Synchronisation Ecampus, problèmes connus

Plusieurs problèmes peuvent exister concernant les automatismes qui synchronisent les données d'Ecampus avec le reste du système d'information. Ils peuvent affecter la bonne mise à jour des données, conduisant ainsi à des soucis d'inscriptions ou autres sur Ecampus.

Les chapitres suivants décrivent les problèmes identifiés à ce jour.

Le premier chapitre, sous forme de FAQ, propose une entrée par “symptôme”, le deuxième, par type de situation potentiellement génératrice de problèmes.

En complément de la présente page, plusieurs dispositions ont été prises, notamment :

une formation Ecampus pour le personnel administratif, dont le support est accessible en ligne sur Ecampus dans l'Atelier Moodle niveau 1
(source support_ecampus_pour_les_administratifs.odp accès réservé) ;

une formation interne destinée aux ingénieurs technopédagogiques du CEMU support_ecampus_pour_cemu.pdf (source : support_ecampus_pour_cemu.odp)

un fascicule d'aide à la résolution de problème Notice ecampus.pdf
(source notice_ecampus.odp accès réservé) ;

un message dans la lettre d'info du CEMU envoyant vers une page dédiée http://cemu.unicaen.fr/le-cemu/problemes-d-acces-a-ecampus-1088766.kjsp.

Si malgré tous ces éléments préventifs, un problème demeurait, il est possible de créer un ticket d'assistance en envoyant la description du problème par mail à cemu.assistance@unicaen.frMerci de préciser, si possible et si c'est pertinent : le code APOGÉE d'au moins un des cours concernés (il y a plus de 14 000 espaces de cours sur la plateforme) ; le numéro étudiant d'au moins une des personnes ayant rencontré le problème (il y a presque 30 000 étudiants ayant accès à la plateforme, dont beaucoup d'homonymes) ; une description détaillée des symptômes observés (les copies d'écran sont les bienvenues). Le traitement de votre ticket s'en trouvera accéléré.

Foire Aux Questions

Ce chapitre liste les questions couramment posées, potentiellement en lien avec des problèmes de synchronisation d'Ecampus avec le reste du système d'information (SI).

La difficulté ici est qu'une même question peut avoir des origines multiples. Aussi, pour essayer de ne rien oublier, chaque question renvoie vers une liste de situations pouvant être à l'origine du problème en question.

Mon nom et/ou mon prénom est erroné sur Ecampus

Les identifiant, nom, prénom et adresse mail sont synchronisés avec votre compte numérique.

Il n'est pas possible de les modifier directement dans Ecampus.

Il faut donc le signaler au service administratif de votre composante pour qu'il procèdent aux corrections de votre compte numérique. Une fois la modification faite, elle apparait dans Ecampus le lendemain (synchronisation nocturne).

Je n'arrive pas à me connecter sur Ecampus

Pour se connecter à Ecampus, il est nécessaire de disposer d'un compte numérique valide et de se connecter via l'onglet CAS ( voir Accéder à la plateforme Ecampus ).

Cas particulier: je suis bloqué sur ma page de profil, dés ma première connexion. Cette page m'indique que je n'ai pas d'adresse email, alors que je ne peux pas le modifier .

Si vous avez un compte invité ou enseignant vacataire, la composante vous a créé un compte spécifique. Toutefois lors de la création de ce compte, votre adresse mail personnelle n'a pas été mentionnée. Cette adresse est nécessaire pour accéder à Ecampus. Nous devons donc demander à votre composante de modifier votre compte. Une fois modifié, vous pourrez accéder normalement à Ecampus, dès le lendemain.

Pourquoi mon cours a été déplacé et renommé sur Ecampus ?

Voir :

Cours archivé ;

Pourquoi mon cours n'existe pas sur Ecampus ?

Voir :

Manque d'inscription jusqu'au groupe ;

Relation porteur porté.

Pourquoi je ne vois pas mon cours sur mon tableau de bord ?

Voir :

Configuration du tableau de bord (voir explications ci-après) ;

Défaut d'inscription dans l'espace cours :

si vous êtes enseignant, voir je_suis_l_enseignant_d_un_cours_pourtant_je_n_y_suis_pas_inscrit_pourquoi ;

si vous êtes étudiant, voir pourquoi_les_etudiants_ne_sont_pas_inscrits_dans_mon_cours.

Configuration du tableau de bord

La liste des cours affichés sur le tableau de bord varie en fonction de la configuration du filtrage dans le bloc “Vue d'ensemble des cours”. Attention également à la pagination ; votre cours se trouve peut-être sur une deuxième page ou plus.

Les cours passés peuvent ainsi disparaître du tableau de bord : si un espace cours possède une date de fin active (ce qui n'est pas le cas par défaut) et que cette date est échue, Ecampus considère que ce cours est passé.

Par exemple :

Si dans le même temps, un des étudiants inscrits a un filtre réglé sur “en cours”, alors ce cours passé ne sera pas affiché.

Pourquoi les étudiants ne voient pas mon cours ?

Si vous êtes enseignant et correctement inscrit dans votre cours, mais que tous ou certains des étudiants attendus ne voient pas votre cours :

voir : cours cachés (impacte tous les étudiants) ;

parce qu'ils n'y sont pas inscrits (voir pourquoi_les_etudiants_ne_sont_pas_inscrits_dans_mon_cours).

Si des étudiants ne voient pas votre cours, mais qu'ils ne sont pas inscrits dans le cours, la question est différente. Voir : la question sur les inscriptions d'étudiants.

Pourquoi les étudiants ne sont pas inscrits dans mon cours ?

Voir :

manque d'inscription jusqu'au groupe ;

problèmes de gestion du statut à distance ;

relation porteur/porté ;

élément suspendu dans Apogee ;

IA annulée, puis remplacée ;

etudiant_erasmus ;

désynchronisation temporaire ;

id number modifié.

Puis-je me dépanner en synchronisant une cohorte (basée sur les IA) dans le cours ?Il faut l'éviter autant que possible. En effet, les synchronisations de cohortes posent des problèmes de gestion d'obsolescence (contrairement aux inscriptions automatiques par base de données). Malheureusement, il n'est pas possible de configurer une date de fin de synchronisation de cohorte, aussi c'est manuellement qu'on ajoute une synchronisation de cohorte, mais c'est aussi manuellement qu'il faut penser à la retirer du cours quand les inscriptions automatiques sont corrigées. C'est malheureusement souvent oublié, ce qui provoque des inscriptions inappropriées plus tard et peut maintenir une activité “artificielle” y compris dans des cours obsolètes, qui ne sont plus modélisés (plusieurs centaines de cours d'ores et déjà concernés). Par ailleurs, notons que les cohortes s'appuient sur les IA, donc ne prennent pas en compte le fait que certains étudiants ne font pas toutes les UEs d'un parcours. Puis-je me dépanner en inscrivant manuellement des étudiants ou en ajoutant une méthode d'auto-inscription ? Oui, mais là encore, ces méthodes n'apportent pas les garanties nécessaires en matière de gestion de l’obsolescence. A contrario, la méthode d'inscription par base de données (que nous recommandons et qui est active par défaut) garantie que les étudiants qui doivent avoir accès à un espace cours y ont bien accès, mais aussi et surtout, que ceux, qui pour une raison ou une autre (expulsion, changement de filière, changement d'année universitaire…) ne le doivent plus, vont bien perdre cet accès (puisque la méthode par base de données s'appuie sur les inscriptions pédagogiques. Donc pour gérer au mieux ces problématiques de bonne gestion de l'obsolescence avec les méthodes d'inscriptions manuelles ou d'auto-inscription, il est impératif de limiter ces inscriptions dans le temps : Comment savoir qui est incrit et surtout comment ? Dans Ecampus, on peut voir la source d'une inscription en allant voir les participants et en survolant avec sa souris l'icône rouge d'information : On peut aussi regarder la liste des méthodes d'inscription actives et voir combien d'inscriptions dépendent de chaque :

Je suis l'enseignant d'un cours, pourtant je n'y suis pas inscrit, pourquoi ?

Voir :

Planification dans ADE non compatible

Pourquoi le bloc "Participants" ne s'affiche plus ?

Depuis la mise à jour de ecampus de septembre 2020, le bloc “Participants” auparavant affiché à droite de l'écran dans un espace cours n'est plus affiché. En effet, il aurait fait doublon avec le lien vers la liste des participants affiché désormais dans le menu contextuel, à gauche de l'écran.

Pour afficher/cacher le menu contextuel, cliquer sur le bouton “hamburger/menu” en haut à gauche de la page.

Je ne suis pas affecté dans le bon groupe dans le cours, pourquoi ?

Voir :

Certains problème de gestion du status à distance.

Si le problème s'accompagne d'une absence d'inscription dans le cours, c'est une autre question. Voir : la question sur les inscriptions d'étudiants.

Je parviens à m'authentifier au CAS, mais celui-ci me dit qu'il ne connaît pas ma destination finale

Le CAS est un mécanisme d'authentification, auquel est délégué l'authentification à nombre de services de l'université. Habituellement l'utilisateur visite le service et s'il n'est pas authentifié sur ce service, celui-ci redirige l'utilisateur vers le CAS pour qu'il s'authentifie, mais en indiquant où diriger l'utilisateur ensuite.

Certains utilisateurs trouve l'adresse de leur service, en l'occurrence Ecampus, dans un moteur de recherche. Si celui-ci n'a conservé que l'adresse du CAS (cas.unicaen.fr), l'utilisateur va essayer de se connecter directement et *exclusivement* au CAS et probablement y parvenir. En revanche, le service désiré (Ecampus) n'étant pas spécifié, aucune redirection vers Ecampus n'intervient ensuite.

Voir Mauvaise URL

Situations particulières

Ce chapitre, issu de l'expérience accumulée lors du traitement des nombreux tickets adressés à cemu.assistance@unicaen.fr, recense toutes les situations aujourd'hui connues à l'origine des questions présentées au chapitre précédent.

La plupart de ces situations découlent d'un renseignement problématique ou incomplet du système d'information (APOGÉE, ADE…).

Cours archivé

Depuis la rentrée 2020/2021, lmsjonction gère l'obsolescence des catégories et espaces cours.

Si un cours est en archive, c'est que son code n'existe plus en l'état dans Apogee.

Plusieurs explications sont possibles :

le cours, obsolète, a été supprimé de la modélisation : il est donc normal qu'il n'existe plus non plus sur ecampus

le code Apogee du cours a changé : le cours qui était associé dans ecampus a été archivé, mais un nouvel espace cours a été créé en correspondance avec le nouveau code Apogee. L'enseignant doit copier le contenu de l'ancien espace de cours vers le nouveau

le cours a été supprimé accidentellement de la modélisation : le problème doit être corrigé à la source (dans Apogee) pour que l'espace correspondant dans ecampus soit désarchivé (la nuit suivante)

Autrement dit si un espace cours est archivé, c'est qu'il était associé à un code Apogee qui a disparu de la base REFER administrée par la DSI. Les questions, dès lors, sont “pourquoi a-t-il disparu ?”, “Etait-ce intentionnel ou non ?”. Seules les personnes qui maîtrisent l'offre de formation et son évolution peuvent répondre à ces questions.

Si c'était voulu, à charge pour l'UFR en question de gérer la communication avec les gens impactés, notamment les enseignants pour que ces derniers puissent le prendre en compte.

Si, au contraire, c'est accidentel, à charge pour les services scolarités concernés d'en rechercher les raisons en particulier dans Apogee. Au besoin, de se faire aider par la DEVE, qui elle-même pourra solliciter la DSI si rien n'est trouvé.

Dans tous les cas, les enseignants qui rencontrent cette situation, doivent se rapprocher de leur service de scolarité.

Au CEMU nous ne sommes ni qualifié, ni en responsabilité sur Apogee. D'ailleurs aucun désarchivage manuel dans ecampus n'est prévu, ni souhaitable.

Malgré les désagréments attachés à ces situations, il faut rappeler que cette gestion de l'obsolescence, mise en place à la rentrée 2020-21, a permis un grand nettoyage de la plateforme, favorable à ses performances (620 cours archivés et 3524 cours supprimés). C'est aussi une opération nécessaire pour maintenir une proximité entre les modélisations dans Apogee et dans ecampus.

Cours cachés

Les espaces de cours crées automatiquement sont cachés et vides par défaut.

C'est à l'équipe enseignante de décider du moment où l'espace cours doit être visible et de signifier cette décision en allant configurer le cours pour le rendre visible (dans les paramètres du cours) :

Si un espace cours est caché, certains rôles (enseignant par exemple) le voient grisé, d’autres (étudiant en particulier) ne le voient pas.

Depuis le passage à la version 3.7 de Moodle (été 2019), une notification prévient les enseignants du statut caché du cours :

Manque inscription jusqu'au groupe

Quand il existe des groupes dans APOGÉE, l'inscription pédagogique doit être faite jusqu'au groupe. Sinon l'inscription des étudiants à un espace de cours dans Ecampus n'a pas lieu.

S'il n'y a pas lieu de créer des groupes coté APOGÉE, compte tenu des caractéristiques de l'élément pédagogique, et qu'ainsi aucun n'existe, alors un pseudo-groupe (préfixé ELP_) est créé automatiquement à condition qu'il y ait bien des charges d'enseignement définies.Ce pseudo-groupe est suffisant pour générer les inscriptions correspondantes dans les espaces cours.

Mauvaise gestion statut à distance

Symptôme : un étudiant n'est pas inscrit dans l'espace de cours ou bien dans le mauvais groupe.

Ces problèmes découlent d'incohérences dans le renseignement d'APOGÉE.

Dans APOGÉE, il doit y avoir une cohérence dans les déclarations de statut “à distance” pour :

l'étudiant

les éléments pédagogiques (ELP) auxquels il est inscrit

les groupes dont il est membre (qui doivent être, au moins partiellement, libellés “cemu” pour les étudiants à distance)

Dans l'exemple ci-dessus, on vérifie :

que l'étudiante “21609846” est bien inscrite administrativement à son code étape dans le cadre d'un enseignement à distance ;

que, par exemple, l'élément pédagogique auquel elle est inscrite, “IRAN-15”, se fait bien à distance ;

et, enfin, que le groupe dans lequel elle est intégrée pour ce cours est bien un groupe partiellement libellé “CEMU”.

Règles de gestion des cours en FOAD

Voir Synchronisation d'Ecampus avec le SI

Synthèse des conséquences

Ci-dessous une synthèse des conséquences en fonction des situations :

(source)

Dans l'exemple de la situation “a”, l'étudiant n'est pas dans un groupe “CEMU”, l'élément pédagogique considéré n'est pas déclaré faisable en “Enseignement à distance”, son inscription administrative a été déclarée en “Télé-enseignement”.

Cette situation ne génère aucune erreur ni aucun warning lors de l'exécution de l'update de l'offre de formation. Par contre, cela génère une erreur au moment de la synchronisation des inscriptions par base de données et un warning (de type w9) lors de l'exécution de la mise à jour des groupes.

La conséquence finale est une absence d'inscription pour l'étudiant dans l'espace de cours lié à cet élément pédagogique, et, à fortiori, son absence dans le groupe ad hoc dans ce cours.

Cas impactant les inscriptions :

ELP non “enseignement à distance” mais IA en “téléenseignement” ⇒ ni inscription, ni groupe

Donc, si IA en “téléenseignement”, toutes les ELP doivent être “enseignement à distance”

Cas n'impactant que les groupes :

groupe “CEMU”, mais IA non “téléenseignement”

ou

tout en téléenseignement, mais groupe non “CEMU” (ou automatique ELP_…)

Cas transparents (sans conséquences) :

les 3 données sont cohérentes

ou

les données toutes en non FOAD, sauf l'ELP qui peut être en “enseignement à distance”.

Depuis la mise en place de pseudo-groupes automatiques (préfixés ELP_) pour les éléments pédagogiques APOGÉE sans groupe, mais avec charges d'enseignement, les étudiants inscrits pédagogiquement à cet élément pédagogique sont automatiquement affectés à ce pseudo-groupe. Or ce dernier n'est pas partiellement libellé “CEMU”, donc est réputé groupe présentiel. Si les étudiants ont une IA en télé-enseignement et que l'élément pédagogique est déclaré faisable à distance, alors nous sommes artificiellement dans la situation c du tableau précédant. Il y aura un défaut d'affectation des étudiants concernés dans le bon groupe sur Ecampus.
Requêtes dans REFER pour avoir les données renseignées dans Apogée : Exemple avec COD_ELP = 'RCAED334' IA SELECT taae.distant FROM T_ADE_ACTIVITES_ETUDIANTS taae WHERE taae.COD_ELP = 'RCAED334' Résultat : O ELP SELECT taa.A_DISTANCE FROM T_ADE_ACTIVITES taa WHERE taa.COD_ELP = 'RCAED334' Résultat : N Groupe GROUPE (FOAD libellé CEMU) SELECT taae.idgroupe FROM T_ADE_ACTIVITES_ETUDIANTS taae WHERE taae.COD_ELP = 'RCAED334' GROUP BY taae.idgroupe Résultat : ELP_RCAED334_CM (groupe non étiqueté CEMU) Ici nous sommes donc dans la situation a : groupe pas FOAD, ELP pas FOAD mais IA FOAD

Mauvaise gestion de la relation porteur/porté

Symptôme : les inscriptions à un cours disparaissent, le cours lui-même disparaît de REFER, ou lmsjonction génère une alerte indiquant qu'il n'arrive pas à créer un groupe car celui-ci existe déjà (dans un autre espace de cours)…

Quand un élément pédagogique est mutualisé avec un autre, et que l'un est déclaré “porteur” et l'autre “porté”, l'élément “porté” disparaît de REFER, ainsi que de l'espace de cours correspondant dans Ecampus. C'est alors l'espace de cours de l'élément porteur qui a vocation à accueillir tous les étudiants (qu'ils soient inscrits pédagogiquement au porteur ou aux portés). Cet espace de cours devient mutualisé.

Pour que les inscriptions pédagogiques des étudiants dans cet élément porté, dans APOGÉE, soient créées dans l'espace de cours Ecampus (donc dans l'espace de cours correspondant à l'élément porteur), il faut :

que ces étudiants soient inscrits dans un groupe ;

que ce ou ces groupes soi(en)t dans une collection de groupe ;

que la collection en question soit associée à tous les éléments pédagogiques concernés, porteur et portés (la collection doit donc être mutualisée).

Exemple : l'élément '2HR5C' est déclaré comme étant maintenant “porté” par l'élément 'M.1HRP9C'. On peut le voir dans APOGÉE :

Partant de l'élément porteur, on peut ensuite vérifier que la collection de groupe du porteur est bien partagé avec l'élément porté :

Sur la dernière copie d'écran ci-dessus, on voit que la collection de groupes 'M.1HRP9CTD' (qui contient les groupes 'M.1HRP9CEM' et 'M.1HRP9CTD') est bien associée aux 2 éléments pédagogiques :

le porteur 'M.1HRP9C' ;

et le porté '2HR5C'.

Planification ADE non compatible

Planification faite d'une façon incompatible avec la synchronisation d'Ecampus.

Symptôme : un enseignant n'est pas inscrit comme enseignant dans un espace de cours.

Cette situation est attendue pour les enseignants de cours intégralement à distance (généralement sans planification dans ADE), en revanche ce n'est pas normal pour les autres.

L'inscription automatique d'un enseignant dans un espace de cours Ecampus se produit lorsqu'une planification ADE valide existe.

3 conditions sont nécessaires :

de planifier les cours avec les enseignants (une simple association d'enseignant ne suffit pas)
;

concerner une fiche ADE relative à un élément issu d'APOGÉE (les fiches créées uniquement dans ADE n'ont pas d'impact sur Ecampus)
;

l'élément issu d'APOGÉE doit être actuel (certaines fiches ADE concernent des éléments obsolètes dans APOGÉE).

Il existe un concours de circonstances très improbable, mais néanmoins déjà observé qui peut produire des défauts d'inscription d'enseignant : un élément pédagogique APOGÉE sans groupe défini a bénéficié de la création automatique d'un pseudo-groupe (préfixé ELP_) ; des planifications ont été faites dans ADE pour ce pseudo-groupe ; plus tard, un groupe est volontairement créé dans APOGÉE, qui vient s'ajouter au pseudo-groupe déjà existant ; le nouveau groupe ne fait l'objet d'aucune planification dans ADE. C'est ce nouveau groupe qui sera considéré prioritairement lors de la synchronisation avec Ecampus, or comme il n'a pas de planification, il ne générera aucune inscription automatique d'enseignant. Ce nouveau groupe vient en quelques sortes masquer les planifications faites précédemment sur le pseudo-groupe.

Trop d'enseignants inscrits dans un espace de cours

Il peut arriver que trop d'enseignants soient inscrits dans un espace de cours. Si ces enseignants sont inscrits manuellement, vous pouvez les désinscrire vous-même. S'ils sont inscrits par base de données, voyer avec la scolarité pour rectifier la planification ADE.

Il est déjà arrivé que des enseignants soient inscrits dans des espaces de cours alors qu'il n'y a pas de planification ADE. En période de début d'année universitaire, cela provient du tuilage avec l'année précédente qui est active jusqu'à fin septembre. Si aucune planification n'est trouvée dans ADE, il est possible que des groupes soient associées ce qui génère cette inscription. Pour le CEMU, voir https://assistance.unicaen.fr/front/ticket.form.php?id=317804

Élément suspendu

Un espace de cours peut voir ses inscriptions par base de données suspendues, suite à la suspension de l'élément pédagogique associé dans APOGÉE.

IA annulée et remplacée

Ce problème n'est aujourd'hui qu'une hypothèse en cours d'analyse.

Il semblerait que la construction des tables intermédiaires qui fournissent les données d'APOGÉE à Ecampus ne prenne pas en charge le fait qu'une IA est annulée au profit d'une nouvelle, en cours d'année.

Étudiant Erasmus

Quand un étudiant Unicaen est dans un dispositif Erasmus, cela signifie qu'il est officiellement dans un autre établissement (à l'étranger). Il a été décidé qu'il ne soit pas inscrit dans Ecampus car il n'est plus censé accéder aux ressources de Caen. Cela évite aussi qu'ils reçoivent les notifications de la plateforme et que les planifications des cours remontent dans leurs calendriers Zimbra, ce qui n'aurait aucun sens pour eux vu qu’ils suivent leur cours dans l’université étrangère.

Rappeler aux scolarités et aux étudiants que si ils sont en Erasmus, ils n'ont pas accès aux cours auxquels ils sont inscrits car ils suivent des cours considérés comme équivalents dans une université étrangère.

S'il y a vraiment un besoin d’accéder aux cours, on explique et on propose aux étudiants ou scolarité de demander aux enseignants de les inscrire manuellement et uniquement dans les cours nécessaires. On recommande vivement de les inscrire avec une durée limitée pour qu'ils ne restent pas inscrits au delà du besoin.

Il arrive que des étudiants lors de leur IA s'inscrivent par erreur dans un programme d'échange international alors qu'ils sont bien présents en cours. Dans ce cas alerter le bureau des inscriptions (ou la SI-Scol deve.cellule-siscol@unicaen.fr ) pour supprimer l'information erronée.

Un étudiant qui ne part à l'étranger que sur un semestre peut l'indiquer en sélectionnant le bon “programme” (pour le semestre 1 ou le semestre 2). Sinon la modalité annuelle a été cochée par erreur, alerter le bureau des inscriptions (ou la SI-Scol deve.cellule-siscol@unicaen.fr ) pour supprimer l'information erronée.

Pour savoir si un étudiant est en erasmus : aller dans Apollo et vérifier la dernière ligne de son IA, il doit y a voir la mention “Programme d'échange : Erasmus+ (Depart a l'annee)”.

Désynchronisation temporaire

Un exemple de ce problème s'est déjà produit.

Rappel des faits :

Une étudiante n'est plus inscrite dans des groupes depuis plusieurs jours et a donc perdu son inscription dans les cours.

Elle signale le problème en créant un ticket.

Le même jour, coïncidence ou pas mais qu'importe, son service de scolarité la réinscrite où il faut, donc corrige le problème.

Toujours le même jour, pour répondre au ticket, le CEMU mène l'enquête et en arrive aux conclusions suivantes :

les inscriptions dans APOGÉE sont correctes à tous points de vue ;

elle n'est effectivement inscrite nulle part dans Ecampus.

Cette incohérence constatée n'était que temporaire. En effet, la nuit suivante, les corrections étaient propagées sur Ecampus et l'incohérence disparue.

Donc, quand une incohérence de ce type est détectée, il faudrait prendre en compte la datation des données et vérifier qu'on ne se trouve pas dans un intervalle d'incohérence temporaire. Ce qui se produit tous les jours entre le moment où une donnée est modifiée dans APOGÉE ou ADE et le lendemain où la modification est propagée sur Ecampus.

idnumber modifié

Maintenant ce champs n'est plus modifiable, sauf à avoir des droits spécifiques sur la plateforme. Ce problème devrait donc être rare.

Parmi les paramètres d'un espace cours sur Ecampus, se trouve une référence au code APOGÉE lié à cet espace cours. Ce paramètre est intitulé numéro d'identification du cours.

Ce paramètre est renseigné automatiquement au moment de la création de l'espace cours et ne doit jamais être modifié manuellement sous peine de détruire le lien avec APOGÉE pour ce cours et donc de compromettre toute synchronisation le concernant.

Erreur database connexion failed

<HTML> <div> <div style=“margin-top: 6em; margin-left: auto; margin-right: auto; color: #990000; text-align: center; font-size: large; background-color: #ffffee; border-radius: 20px; border-collapse: collapse; width: 80%; -moz-border-radius: 20px; padding: 15px; border: 1px solid black;”> <p style=“margin: 0px;”>Error: Database connection failed</p> <p style=“margin: 0px;”>It is possible that the database is overloaded or otherwise not running properly.</p> <p style=“margin: 0px;”>The site administrator should also check that the database details have been correctly specified in config.php</p> </div> </HTML>

Bonjour,

Une optimisation de la base de données a lieu tous les dimanche matin ( entre 9h et 11 h) et l'opération est, selon les périodes plus ou moins longue. Lors de cette optimisation, la base de données peut être inaccessible ( database) .Cela ne dure jamais longtemps ( -d'une heure). Toutefois en période de forte activité , cela peut durer un peu plus. Nous somme désolés de la gêne occasionnée.

Bien cordialement

PS : cette optimisation ne peut se faire qu’après une sauvegarde nocturne d’où l'horaire. Le dimanche matin étant le moment ou il y a le moins de monde sur la plateforme.

Mauvaise URL

Pour que l'accès à nos plateformes soit rapide et correct, il vaut mieux saisir leur adresse dans le navigateur directement, plutôt que de passer par un moteur de recherche et d'arriver au mauvais endroit (sur le serveur CAS et ne pas pouvoir aller plus loin, sur une sous-page de la plateforme inaccessible pour l'utilisateur et devoir faire des clics supplémentaires pour atteindre la page d'accueil, etc).

Du point de vue écologique, notons que saisir l'URL de la plateforme directement, génère une circulation courte des données sur le réseau, tandis que passer par un moteur de recherche (généralement américain) génère une circulation de données outre-atlantique aller et retour, à laquelle s'ajoute des requêtages énergivores et inutiles dans les bases de données du moteur de recherche.