Message d'erreur

Deprecated function : The each() function is deprecated. This message will be suppressed on further calls dans menu_set_active_trail() (ligne 2405 dans /home/venusmilfn/drupal/includes/menu.inc).

Examens numériques à l'université : sécurité, technique et organisation (JRES 2015)

La préparation de l’Examen Classant National informatisé (ECNi, en 6e année de médecine) par les universités n’est pas qu’une évolution logique de l’évaluation des apprenants. C’est un projet hors-normes pour leurs Directions du Système d’Information : les éventuels dysfonctionnements observés sur un site auraient des conséquences sur l’ensemble de l’examen (jusqu’à l’annulation). 

La haute disponibilité des équipements est réellement très critique, situation peu habituelle en milieu universitaire (sauf en milieu hospitalier). Par ailleurs, s’agissant d’un projet innovant, il focalise d’autant l’attention des gouvernances des universités, naturellement soucieuses de l’image de leur établissement : on ne parle jamais des trains qui arrivent à l’heure, mais les problèmes survenus dans quelques établissements ces derniers mois ont immédiatement trouvé un écho dans la presse nationale. Dès lors, l’ensemble des processus doit être parfaitement maîtrisé : la sensibilisation des personnels et des étudiants, la préparation des tablettes et des infrastructures, … 

Cet article montre comment le projet SIDES (Système Informatisé et Distribué d’Évaluation en Santé) a été mené à l’université de Rennes 1 depuis septembre 2013. Nous indiquons notamment quels doivent être le rôle et la place de chacun des acteurs du projet, focalisons sur les aspects SSI du projet (appréciation, traitement et acceptation du risque), et montrons comment l’évolution technique de l’architecture du réseau de Rennes 1 pour l’ECNi a bénéficié à l’ensemble de l’université. La dernière partie de la présentation focalise sur l'échecs des tests ECNi de décembre 2015.

Pascal AUBRY, JRES 2015, 10 décembre 2015, Montpellier


Ajout 18 décembre 2015

A l'issue de la présentation à Montpellier, plusieurs questions du public concernant la suite du projet étaient restées sans réponse, par manque d'information. Les informations transmises par le CNG lors de la réunion du 18 décembre 2015 à Paris ont permis de mieux cerner la nature des dysfonctionnements observés.

Comme l'a indiqué Laurent GYDÉ (Renater) après la présentation (39:42), la raison du crash observé n'est pas un sous-dimensionnement des serveurs, ce qui explique que les ressources supplémentatires mises en place pour les épreuves du mardi n'ont fait qu'augmenter le temps pendant lequel l'application a répondu. Il ne s'agit pas non plus d'un « bug » comme cela a été annoncé dans la presse. Il s'agit d'une erreur de conception de l'application, qui aurait du être sinon relevée lors des spécifications au moins mise en évidence par des tests de montée en charge préalables, sans que l'on monopolise plusieurs jours 8000 cobayes.

Les points les plus intéressant à retenir sur le plan de l'analyse de risques sont les suivants :

  • Ce n'est pas parce que des éléments d'un système sont a priori mieux maîtrisés que d'autres qu'ils ne doivent pas faire l'objet de la même attention. Une attention toute particulière a été portée aux infrastructures des établissements, à l'aide du cabinet Solucom, pour assurer la disponibilité de l'ensemble du dispositif. Alors que la résilience de bout en bout des réseaux semblait un idéal difficile à atteindre, ce sont les serveurs qui ont été mis en défaut, c'est-à-dire la partie considérée par les informaticiens comme la plus facile à mettre en oeuvre, car la mieux maîtrisée. 
  • Une analyse de risques n'est valable qu'à l'instant où elle est réalisée : les risques évoluent. Comme indiqué lors de la présentation, il n'est pas concevable que le CNG n'obtienne pas du prestataire chargé du développement (GFI) une application fonctionnelle en mars après l'échec de décembre. Dès lors, les risques techniques se déplaceront à nouveaux sur les centres d'examens.
  • Une prise en compte globale des risques est nécessaire, elle doit concerner les risques techniques et non techniques. Pour un tel projet, porté par une volonté forte et partagée de tous les acteurs (gouvernance, organisateurs, enseignants et étudiants), les menaces techniques ont souvent été considérées comme les plus probables. Les menaces non techniques à caractère sociologique (par exemple celles liées au refus de nouvelles solutions) peuvent s'avérer finalement plus probables (par exemple suite à une mauvaise conduite du changement).