Intervention de Hugo Gimbert

Réunion du jeudi 22 novembre 2018 à 10h00
Office parlementaire d'évaluation des choix scientifiques et technologiques

Hugo Gimbert, chercheur en informatique au CNRS :

- Claire Mathieu a évoqué la vitesse de convergence ; je vais commencer par vous présenter quelques éléments statistiques au sujet de la campagne 2018, comparant les résultats de la campagne telle qu'elle s'est déroulée et telle que nous l'avions préalablement simulée.

Parcoursup se fonde sur un fonctionnement au fil de l'eau du 22 mai à début septembre, et quotidiennement des propositions sont envoyées aux candidats et des réponses sont faites par les candidats. Dans le cas de la mission auprès du ministère, Claire Mathieu et moi avons été chargés de réaliser des simulations de la campagne 2018 à partir des données disponibles des campagnes APB 2016 et 2017. Ce n'était pas une tâche facile puisqu'il y avait ce changement de fonctionnement, mais on ne partait pas de zéro.

En amont de la campagne 2018, ces simulations ont contribué à calibrer les paramètres cruciaux de la campagne tels que le nombre maximal de voeux par candidat ou encore le délai de réponse accordé aux candidats pour réfléchir avant de répondre, de manière à garantir le bon déroulement de la procédure, et en particulier qu'elle ne soit pas trop lente, ce qui était une inquiétude dont la presse s'était fait l'écho.

Diverses simulations ont été réalisées selon des scénarios plus ou moins optimistes ou pessimistes. Dès le premier jour de la procédure, plus d'un candidat sur deux a reçu une proposition. Ensuite, ce nombre a évolué. À partir de la fin juillet, on voit apparaître un plateau. Presque tous les candidats avaient en fait déjà reçu leur proposition finale. En août, Parcoursup était devenu principalement un outil de gestion des démissions. Il y a de nombreuses démissions dans Parcoursup, 180 000 au total sur 800 000 candidats, soit près d'un candidat sur quatre. En août, la plateforme récupérait la liste des démissions et envoyait les propositions correspondantes à d'autres candidats. Ce plateau en août a donné le sentiment que la procédure était bloquée et que l'algorithme ne fonctionnait pas. En fait, le calcul était terminé et on se contentait de gérer les démissions résiduelles.

Je voudrais maintenant parler du deuxième aspect de la mission qui nous a été confiée à Claire Mathieu et à moi-même, qui est la traduction de certains textes de la loi ORE en algorithme tout d'abord, en code informatique ensuite.

« C'est la loi qui fait le code, et non pas le code qui fait la loi » est le principe de base qui nous a guidés. Pour éclairer la suite de mon propos, je ferai un rapide distinguo entre la notion d'algorithme et celle de code informatique. Un algorithme est le principe même du traitement du calcul à réaliser, il s'agit d'une suite d'instructions à exécuter de manière minutieuse pour aboutir au résultat désiré.

Un algorithme peut être exécuté avec un papier et un crayon, une craie et un tableau, ou un ordinateur. C'est le principe du calcul lui-même. Le code informatique est un texte écrit en langage machine, exécuté par l'ordinateur pour permettre le traitement automatisé de gros volumes de données complexes avec une intervention humaine minimale.

Comme l'a dit Claire Mathieu, dans la traduction du texte législatif en algorithmes, nous nous sommes efforcés, par une traduction directe et simple de la loi, d'obtenir un algorithme simple, compréhensible par les citoyens concernés voire par tous les citoyens eux-mêmes. Cela a nécessité le vote de la loi au préalable, ensuite un dialogue avec les équipes du ministère, en particulier avec les juristes pour s'assurer que l'interprétation algorithmique que l'on faisait des textes correspondait bien à l'esprit du législateur.

Une fois cet algorithme et ce code produits, ils ont été publiés en s'efforçant de suivre les meilleures pratiques possibles sachant que, à ma connaissance, c'est une des premières fois qu'il y a une publication d'un code informatique de l'administration de cette importance.

En premier lieu, nous avons publié le code une semaine avant sa mise en service pour informer a priori et non pas a posteriori.

Le code a été publié comme un logiciel libre sous une licence dite Open source et le choix de la licence s'est réalisé en lien avec Etalab et la DINSIC (direction interministérielle des systèmes d'information).

Ensuite, le code est hébergé en France. Le point d'entrée pour tout un chacun est une page web gérée par une association qui promeut le logiciel libre, et le dépôt a été effectué sur la plateforme Framagit.

Un réel effort pédagogique a été consenti dans le sens où la publication du code source s'est accompagnée de celle d'un document qui présente les algorithmes, explique leur fonctionnement, fournit des exemples d'exécution qui sont compréhensibles par le grand public afin que le code ne soit pas seulement un langage abscons. Le code lui-même est abondamment commenté en français. Il est livré avec des tests, ce qui permet à des programmeurs enthousiastes de faire « tourner » chez eux le code de Parcoursup sans avoir pour autant bien sûr accès aux données de Parcoursup.

Un autre aspect important : la publication sur cette plateforme a également donné lieu à la création d'un espace de discussion et même de contribution autour du code. Des suggestions ont parfois même été faites pour améliorer les commentaires, améliorer la présentation du code, dont certaines ont été mises en oeuvre. L'application du code est ainsi un espace vivant de dialogue où les citoyens peuvent échanger directement avec les concepteurs du code.

Enfin, le troisième volet qui doit faire partie des bonnes pratiques est le fait que dès le début, on a considéré ce code comme du code « critique », c'est-à-dire un code informatique dont la défaillance peut avoir des conséquences dramatiques en termes de coûts. Cela peut être par exemple le code qui gère la sécurité dans les trains, dans les voitures, etc. Le code de Parcoursup fait partie de cette catégorie puisque si on s'était aperçu qu'il y avait un dysfonctionnement à mi-parcours de la campagne, cela aurait été un problème considérable. Cela n'a pas été le cas.

Que faut-il faire face à un code critique ? Il faut dans un premier temps spécifier très précisément ce que l'on attend de l'exécution de l'algorithme, ses propriétés de sorte que l'algorithme garantisse l'équité entre candidats ou l'application des taux fixés par les rectorats ou encore qu'il ne puisse pas arriver à devoir effectuer de division par zéro, ce qui provoquerait immédiatement un arrêt machine.

Deux démarches ont été prévues pour obtenir ces garanties. La première, c'est qu'à l'issue de chaque calcul, on compare les données d'entrée et les données de sortie et on contrôle que les propriétés fixées sont bien vérifiées par le résultat du calcul. Comme le disait Claire Mathieu, on vérifie par exemple qu'un boursier n'a pas été « doublé » par un non-boursier. Une vérification des résultats est faite systématiquement chaque jour par un module de code spécifique.

La deuxième démarche, en cours, est la certification du code, c'est-à-dire l'établissement d'une preuve mathématique que le code est bien le reflet exact de l'algorithme. Ce travail est en cours avec des équipes spécialisées.

Aucun commentaire n'a encore été formulé sur cette intervention.

Cette législature étant désormais achevée, les commentaires sont désactivés.
Vous pouvez commenter les travaux des nouveaux députés sur le NosDéputés.fr de la législature en cours.