Audit du code source de Parcoursup par la Cour des comptes

Posté par (page perso) . Édité par Davy Defaud. Modéré par Ysabeau. Licence CC by-sa.
58
19
mai
2020
Éducation

La Cour des comptes a publié il y a quelques semaines un rapport de deux cents pages consacré à « l’accès à l’enseignement supérieur », et notamment à son application emblématique, Parcoursup.

Le rapport contient notamment de longs passages consacrés à la qualité du code publié.

On peut retenir à ce sujet deux points cruciaux et plutôt désolants :

  • seul environ 1 % du code source de l’application a été publié (en 2018), contrairement à la décision des pouvoirs publics annoncée en 2017 de « permettre une totale transparence sur l’affectation des candidats » ;
  • la qualité du code audité est qualifiée par la Cour des comptes de « médiocre », avec « un niveau de risque élevé et de nombreuses violations critiques identifiées », la Cour évoque un code qui « n’a pas été produit selon les standards professionnels » et d’un « processus de développement [qui n’a pas été] mené dans les règles de l’art ».

D’un point de vue technique, on apprend dans le rapport que l’application est constituée de 858 752 lignes de SQL (!) et 11 331 de Java.

Plus d’extraits du rapport en cliquant sur « lire la suite ».

Plus d’extraits du rapports (c’est nous qui soulignons) :

En dépit des actions de mise en transparence du ministère, le code source de Parcoursup reste à 99 % fermé. La partie publiée demeure d’un intérêt limité pour comprendre, expertiser, et évaluer le processus d’affectation des candidats dans les formations. Les données de Parcoursup, particulièrement riches, ne font pas l’objet d’une valorisation à la hauteur des enjeux, non seulement par les acteurs de la recherche et de l’innovation, mais aussi par l’administration elle‑même, tant les moyens matériels et humains pour permettre leur exploitation sont insuffisants.

Les résultats ainsi produits suggèrent que l’application Parcoursup présente une qualité médiocre, avec un niveau de risque élevé et de nombreuses violations critiques identifiées. Parcoursup se situe à un niveau de qualité plus faible que d’autres logiciels d’ancienneté similaire. Plus précisément, les indices d’efficience et de sécurité ainsi évalués montrent que le risque de rupture du fonctionnement normal de Parcoursup est élevé.

Parcoursup est composé d’un code source public et d’un code source fermé. Malgré sa petite taille, le code source qui a été rendu public et qui est récent présente un niveau de risque comparable au code non public. À titre de comparaison, les applications de moins de deux ans devraient présenter un risque plus faible. Par ailleurs, le code ouvert présente une densité de violations critiques bien plus importante que le code fermé. D’après le ministère, le code Java public, qui « n’a pas été produit selon les standards professionnels », ne peut être analysé avec les métriques de l’audit car elles ne sont pas adaptées à ce mode de production artisanal.

Le dispositif présente ainsi un risque de rupture de service. Il n’est pas non plus à l’abri d’une intrusion comme en témoigne un autre audit de sécurité du code source, réalisé en juillet 2018 à la demande du ministère, et qui souligne un risque de sécurité « très élevé » pour l’application. Cette situation doit être corrigée rapidement. À la fin 2019, le ministère souligne qu’une « démarche de certification du code Parcoursup a été initiée avec les équipes de recherche du laboratoire de recherche en informatique de Saclay ainsi que du laboratoire bordelais de recherche en informatique ».

[…] d’autant que l’échantillonnage n’a pas permis de trouver les traces d’un processus de développement mené dans les règles de l’art. Le code actuel est en effet d’une facture plus artisanale. Il serait souhaitable d’introduire un processus de développement moderne et éprouvé afin d’assurer une évolution fiable et maîtrisée de l’application.

Le code de Parcoursup présente un niveau de complexité anormalement élevé. Les composantes complexes représentent 27 % du volume de code, ce qui est bien plus élevé que le plafond de 5 à 7 % recommandé par les standards des professionnels du secteur. Avec un tel niveau de complexité, la mise en œuvre d’évolutions fonctionnelles risque d’introduire des erreurs. Le ministère ne partage pas cet avis et invoque la complexité du système d’enseignement français et la variété des parcours proposés. Pour la Cour, le code source devrait être restructuré afin de réduire le nombre de ses composantes complexes.

En 2017, la mission Etalab, appuyée par l’ANSSI, recommandait, en pleine convergence avec le rapport de la Cour de la même année, « de publier […] le code source de la dernière version d’APB et les données non réidentifiantes associées ». Par décision des pouvoirs publics, le code informatique de Parcoursup est réputé avoir été rendu public afin de permettre une totale transparence sur l’affectation des candidats. La Cour a réalisé un audit du code source de Parcoursup sur un volume de lignes de code cent fois plus important que le code publié par le ministère.

À ce jour, une très faible partie du code de Parcoursup a été rendue publique. Le code publié par le MESRI le 21 mai 2018 représente au plus 1 % du nombre de lignes de code et moins de 2 % des fichiers produits dans le cadre de l’exercice des missions dévolues à l’opérateur de la plate‑forme.

Dans le cadre de cet audit, 1 582 violations critiques ont été identifiées. Il s’agit de failles dans le code qui doivent être corrigées rapidement.

Aller plus loin

  • # Analyse statique

    Posté par . Évalué à 10 (+13/-0). Dernière modification le 19/05/20 à 16:35.

    Malgré tout le mal que je pense de Parcoursup, on dirait qu'il ont juste lancé un outil de mesure de qualité du code sur tout le code et regardé les stats en sortie. J'aurais bien aimé voir les détails de cette partie de l'audit, parce que même les annexes sont particulièrement vagues.
    Certes c'est un indicateur intéressant, surtout dans le cadre de pratiques de dev moderne, mais ça reste une vision parcellaire.

    • [^] # Re: Analyse statique

      Posté par (page perso) . Évalué à 10 (+9/-0).

      Faut pas trop en demander à 'Orange Cyberdéfense', pour un audit à moins de 200 millions d'euros (enfin j’espère ;) )
      Plus sérieusement, quand un audit se termine par un tableau de notes de 1 à 4… on sait qu'il est raccord avec la qualité du code.

      • [^] # Re: Analyse statique

        Posté par . Évalué à 3 (+2/-0).

        La question c'est qui a développé Parcoursup ?
        Certainement pas le ministère de l'éducation. Au mieux a-t-il supervisé les développements, sans connaître rien aux techniques de dev fiable.
        Il s'agit certainement d'un travail de commande. A partir de là, une développement sur commande est généralement très mauvais.
        J'ai vu chez des clients des trucs sortir de boîtes de service prestigieuses, absolument immondes.
        S'il y a beaucoup de lignes SQL, c'est qu'il y a eu un nombre conséquent de développeurs qui ne se sont absolument pas concertés, car il y a eu du travail vraisemblablement fait en double ou en triple. On a voulu faire rapidement, parce que le gouvernement est critiqué quoi qu'il arrive, il a fallu faire vite. En plus cela a dû coûter très cher.

        • [^] # Re: Analyse statique

          Posté par (page perso) . Évalué à 10 (+11/-0).

          Le développement de Parcoursup est totalement interne aux ministères de l'éducation nationale et de l'enseignement supérieur. L'État a créé un service dédié. On peut voir passer de temps en temps des offres d'emploi pour le « Service à compétence nationale Parcoursup ».

          Le développement a débuté il y a plus de 10 ans : c'est toujours le même code depuis APB, modifié d'année en année pour suivre les évolutions politiques/réglementaires. Parcoursup n'est qu'un nouveau nom donné quand le gouvernement a décidé que les candidats répondraient au fil de l'eau au lieu de classer à priori leurs vœux.

          De ce que j'avais compris de la demande de publication du code source d'APB il y a quelques années : j'ai l'impression que Java servait surtout à l'interface web et que tous les calculs d'affectations étaient en fait en SQL. Vu l'efficacité de SQL pour programmer, ce n'est pas tellement étonnant qu'il y ait un tel volume. Ces dernières années, avec Parcoursup, j'ai l'impression (en lisant le code source publié) que tout finit par être codé en Java et doublé en SQL, avec comparaison des deux résultats.

          • [^] # Re: Analyse statique

            Posté par . Évalué à 8 (+9/-2).

            Merci pour ces précisions.
            Ce n'est donc pas étonnant que cela soit d'aussi mauvaise qualité. Il est ancien et la succession des personnes dessus n'a pas dû aider.
            Maintenant, si vous voulez mon expérience "pré-parcoursup", c'était largement pire avant, quand il n'y avait aucun système.
            Mon expérience d'inscription à la fac en 84 quand j'ai eu mon bac, c'est une énorme bousculade un lundi matin sur le parvis de Jussieu, juste après les résultats du bac, à l'entrée de l'amphi ouvert pour le retrait des dossiers.
            Le même jour, plusieurs facs ouvraient leurs inscriptions, il fallait aller sur place retirer un dossier vierge. Je suis arrivé vers 8h pour une ouverture à 10h, c'était déjà fort tard, il y avait un monde fou. Au fur et à mesure que les gens rentraient dans l'amphi, l'entrée se transformait en énorme entonnoir où il fallait jouer des coudes, pire qu'un jour de greve, dur pour les moins costauds. Ensuite, on passait en file indienne devant les bureaux de l'amphi et on demandait à la personne le dossier d'inscription de la formation qu'on voulait suivre. La seule vérification que l'employé faisait, c'était de vérifier que tu avais le bac. S'il restait des dossiers vierges de ta formation dans le carton, tant mieux, s'il n'y en avait plus, tant pis ! Il fallait tenter sa chance dans une autre fac, mais alors très vite, car les inscriptions se déroulaient le même jour !
            Une expérience assez traumatisante, un taux d'échec des étudiants très important à l'arrivée, car certains suivaient des formations qui ne leurs convenaient pas ou pour lesquelles ils n'avaient pas d'aptitudes.
            Autant dire le système de sélection le plus débile qui soit, mais on ne savait pas faire mieux à l'époque, pour ceux qui ne faisaient pas les classes prépa.

            • [^] # Re: Analyse statique

              Posté par (page perso) . Évalué à 7 (+7/-1).

              Ça ne correspond pas franchement à mon vécu pré-pércoursup plus récent (2006). On faisait aussi la queue dans les chaînes d'inscription, certes, mais c'était encore possible de s'inscrire jusqu'en septembre et octobre. Hors filières sélectives (justement), je n'ai jamais entendu parler dans ma fac de personnes refusées par manque de dossiers (et j'ai été syndiquée, élue, etc, je pense que j'aurai été au courant si ça avait été le cas).

              Par contre, ça voulait dire des amphis bondés, car tout le monde était accepté avec le niveau n-1, et que les moyens financiers pour assurer le service public de l'enseignement supérieurs ne suivaient pas…

              Bon, maintenant, ils ne suivent toujours pas, il y a juste moins d'étudiant·es qui peuvent faire leurs études…

              C'était à l'Université Paul Sabatier, à Toulouse.

              • [^] # Re: Analyse statique

                Posté par . Évalué à 5 (+4/-0). Dernière modification le 20/05/20 à 11:35.

                Entre 84 à 2006, et bien ça a changé. En région parisienne, il y avait une certaine pression sur les filières scientifiques, surtout celles qui pouvaient mener à l'informatique.

                C'est pas tout, en 84 on se débrouillait aussi pour aller chercher des dossiers à droite et à gauche, par nos propres moyens. Je suis parti en voiture à Orsay avec un copain avec la voiture de son père chercher un dossier, à la fac d'Orsay qui faisait des pré-inscriptions sur dossier.
                Je me suis adressé aussi au secrétariat de mon lycée pour une demande d'inscription en classe prépa, ce qui m'a valu la remarque de mon prof de maths de terminale "vous voulez vraiment tenter la prépa, avec vos résultats ??". ça m'a dégouté, je n'y ai pas postulé du coup.
                C'était pas parcoursup, mais parcours du combattant.
                Parcoursup, cela me parait bien mieux.

                Cela étant, je suis très content de mes études de fac. Certains profs passionnants, une bonne variété des enseignements. Il n'y a que pour les langues, où c 'était assez nul.

                • [^] # Re: Analyse statique

                  Posté par . Évalué à 5 (+3/-0).

                  yapake la fac dans la vie, lors de mes inscription en bts entre 1991 et 93 je sais plus, suffisait d'envoyer les dossier dans les lycées possédant la spécialité demandé. dossier reçu par courrier sur simple demande

                  prévoyant j'en ai envoyé à 5 lycées dans le departement, finalement fin juin tous sur liste d'attente, certain en 140 eme position :).

                  par contre ca va très vite, debut juillet l'ensemble des etablissements m'avaient appelés sur le fixe ou envoyés des courriers, j'était pris \o/ j'ai pu choisir tranquillement du coup.

                  L'avantage de parcours sup c'est les voeux qui sont plus facile à faire au niveau national, une ecole à brest, l'autre à toulon etc …

                  le systéme actuelle s'apparente plus à ce que j'ai vécu, possibilité de choix sauf les dates limites et un manque de souplesse flagrant. J'avais appelé par téléphone les etablissement pour connaitre l'avancement, et ils donnaient les info que je demandais, ca ne doit etre plus possible maintenant.

                  actuellement lorsqu'un lycée te donne une réponse tu as un delai très court pour te decider, meme si par la suite un autre voeux se valide tu ne peux plus changer d'avis. De ce que j'ai enttendu dans ma famille

            • [^] # Re: Analyse statique

              Posté par (page perso) . Évalué à 10 (+18/-0).

              Franchement, je ne sais pas si on peut qualifier de « mauvais » un code qui a toujours fait que l'on lui a demandé depuis sa création.

              Je râle beaucoup sur Parcoursup quand je dois travailler avec, le code sent la naphtaline et les choix d'informatique de grand-père (API REST embryonnaire mais qui commence enfin à exister, exports XLS, validation côté client, petits bugs persistants). Le site public est mieux fichu que le site de gestion privé.

              Mais le résultat correspond parfaitement à la spéc jusqu'à présent. Ce que la presse a régulièrement présenté comme des bugs du système n'étaient que les conséquences de choix et/ou d'erreurs de vrais humains.

              • [^] # Re: Analyse statique

                Posté par . Évalué à 4 (+3/-0). Dernière modification le 20/05/20 à 12:56.

                Je suis assez d'accord avec ce point de vue.
                Le développement informatique "dans la vraie vie" en somme. Merci pour cet éclairage.

          • [^] # Re: Analyse statique

            Posté par . Évalué à 10 (+9/-0). Dernière modification le 20/05/20 à 23:22.

            Le développement de Parcoursup est totalement interne aux ministères de l'éducation nationale et de l'enseignement supérieur. L'État a créé un service dédié.

            Alors, pour être précis, au départ, en 2002, APB était destiné aux classes préparatoires, dans une seule académie. Et après, ça a été utilisé par d'autres académies, puis ça a été utilisé par autre chose que des classes préparatoires. En 2009, le système a été généralisé à toutes les formations.

            Si je ne dis pas de bêtise, pendant longtemps (jusqu'au changement de nom en Parcoursup), il me semble que tout était développé à l'ENSEEIHT à Toulouse (et les serveurs étaient également là bas). Ce n'est que plus tard que le ministère a mis la main dessus.

            Pour finir, le code d'APB avait au moins le mérite d'être basé sur un algorithme connu et efficace pour apparier les candidats et les universités, et qui donnait certaines garanties (les mariages stables). Le ministère a voulu «remettre de l'humain dans la procédure» mais au final, on a introduit la sélection et le bouzin met des plombes à converger et les critères sont devenus totalement opaques et on n'a plus aucune garantie que l'affectation est optimale.

            • [^] # Re: Analyse statique

              Posté par . Évalué à 6 (+5/-1).

              Le ministère a voulu «remettre de l'humain dans la procédure» mais au final, on a introduit la sélection et le bouzin met des plombes à converger et les critères sont devenus totalement opaques et on n'a plus aucune garantie que l'affectation est optimale.

              Pas que le ministère c'est aussi une pression publique. De ne pas vouloir de gouvernance par les algorithmes sans distinguer (ce qui est véritablement complexe pour le non initié) des algo de mariage stable d'un réseau de neurones profond.

              • [^] # Re: Analyse statique

                Posté par . Évalué à 4 (+1/-0).

                Pas que le ministère c'est aussi une pression publique. De ne pas vouloir de gouvernance par les algorithmes sans distinguer (ce qui est véritablement complexe pour le non initié) des algo de mariage stable d'un réseau de neurones profond.

                Pour le coup, l'algorithme précédent permettait de maximiser la satisfaction globale. Il n'agissait pas au hasard mais en prenant en compte les classements des étudiants et des formations. Maintenant, c'est un peu le règne de l'arbitraire, c'est pas un algorithme mais je ne suis pas sûr qu'on puisse dire que c'est mieux.

                • [^] # Re: Analyse statique

                  Posté par . Évalué à 3 (+1/-0).

                  Je ne dis pas le contraire (c'est je trouve très bien expliqué dans le lien que je donne dans un autre commentaire), je dis que la distinction entre un algorithme classique et un algorithme d'apprentissage est totalement ignoré par le béotien. On médiatise beaucoup sur les dangers des algorithmes et de la gouvernance par les algorithmes. C'est normal de faire le cheminement pour parcourtsup. Il aurait était probablement mieux d'expliquer plutôt que d'acquiescer.

              • [^] # Re: Analyse statique

                Posté par . Évalué à 1 (+1/-0).

                J'arrive un peu après la bataille, mais sans me prononcer sur la pertinence de l'algorithme employé, parcoursup reste une variante de l'algorithme de Gale-Shapley pour les mariages stables. J'avais assisté dans mon labo à une conférence de Claire Mathieu sur l'algorithme en question ; conférence non filmée, désolé de ne pas pouvoir fournir cette source… Mais il existe cette vidéo de science étonnante (youtube, désolé…). On peut aussi lire la présentation officielle de l'algorithme (en particulier la section 2.5) et comparer avec l'algorithme de Gale-Shapley pour voir que les idées de l'algorithme sont les mêmes, sauf que les candidats doivent manuellement répondre à chaque étape, et qu'il y a des complications dues aux quotas de boursiers et de locaux.

                • [^] # Re: Analyse statique

                  Posté par . Évalué à 3 (+0/-0).

                  Claire Mathieu est une femme très intelligente et qui connaît très bien ces problèmes. J'ai été très déçu qu'elle participe à la caution de l'algorithme de Parcoursup. Parce que l'algorithme de Parcoursup ressemble de loin dans le brouillard à l'algorithme de Gale-Shapley, sauf que pas du tout. Il manque en effet une hypothèse extrêmement forte qui est que l'information des classements de part et d'autre est connue. C'était le cas dans APB, ce qui fait que dès le premier tour, la quasi totalité des étudiants avait une affectation. Ce n'est plus le cas avec Parcoursup puisque les candidats ne font plus de classement des formations (ce classement est uniquement dans leur tête) et on peut se retrouver avec des interblocages.

                  Par exemple, si un étudiant A a dans l'idée d'aller à X puis Y, et qu'un étudiant B veut aller à Y puis X, et que X a classé B avant A, et que Y a classé A avant B, on se retrouve avec un blocage. Parce que l'algo va proposer à A d'aller à Y et à B d'aller à X. Ils vont tous les deux dire "OK mais j'attends mieux" et ça ne libère pas une place et donc, l'autre ne peut pas avoir cette place. Au final, ils ont les deux leur deuxième choix alors qu'ils attendaient leur premier choix. Avec APB, et la connaissance complète, ils auraient eu leur premier choix.

                  • [^] # Re: Analyse statique

                    Posté par . Évalué à 1 (+1/-0).

                    Malheureusement, le gouvernement avait décidé d'avance qu'il devait y avoir intervention humaine, Claire Mathieu et Hugo Gimbert ont dus faire avec cette donnée ; je ne faisais que rapporter les propos de Claire Mathieu.

                    Je me plante sans doute, mais avec l'exemple que tu proposes, la différence de résultat entre parcoursup et APB ne serait pas due à la version "les écoles proposent et les étudiants disposent" de parcoursup vs "les étudiants proposent et les écoles disposent" de APB ? (En reprenant la formulation de science étonnante ; je ne sais pas quel est le vrai terme technique).

            • [^] # Re: Analyse statique

              Posté par . Évalué à 1 (+0/-0).

              Et avant APB, de 1987 à 2008 il y avait RAVEL en Ile de France.
              Les bacheliers étaient si nombreux en région parisienne qu'il y a avait déjà un système informatisé de gestion des vœux.

              Par contre pour les filières sélectives on faisait d'abord une demande de dossier et on renvoyait le dossier aux établissements demandés. Ils répondaient oui / non / liste d'attente. Ca évitait de demander un vœu sélectif pour un établissement qui nous aurait refusé.

              Avec Parcoursup il semble que les critères de sélection sont inconnus des postulants. Un article du Canard Enchaîné expliquait ainsi que des étudiants avec de très bonne notes habitant dans les communes limitrophes de Paris étaient refusés dans une filière et des élèves moins bons étaient acceptés mais habitaient… à Paris. Et j'avais lu que certaines universités pouvaient décider de leur propre critères.

        • [^] # Re: Analyse statique

          Posté par . Évalué à 2 (+0/-0). Dernière modification le 20/05/20 à 13:31.

          d'après cet article, il y a eu ~750000 candidats au bac en 2019. Comme d'autres commentaires le soulignent, il est possible que les données de chaque candidats soient insérées à coup d'insert. Ce qui réduit le code SQL significatif à ~100k lignes. C'est toujours beaucoup, mais c'est beaucoup moins impressionnant.

          Edit: Évidemment, si c'est bien le cas, ce "code" contenant les données des bacheliers ne pourrait pas être ouvert.

          • [^] # Re: Analyse statique

            Posté par (page perso) . Évalué à 1 (+0/-0).

            Si c'est le cas, intégrer ces données directement dans le dépôt de code est un gros soucis d'architecture. Ça veut aussi dire que les tests sont uniquement réalisés à partir des données réelles… Mais :
            - il serait je pense très facile de remplacer ces 100k inserts par quelques inserts à la main histoire de livrer un jeu de données bateau qui permettrait de faire fonctionner toute la machine ;
            - ces données ne sont pas tombées du ciel directement en SQL, elles doivent provenir d'un export XLS, CSV ou autre, donc il y a forcément une procédure de conversion qui pourrait être fournie.

            • [^] # Re: Analyse statique

              Posté par . Évalué à 3 (+1/-0).

              là, on arrive aux limites de l'exercice sans aller voir le code (et je ne l'ai pas fait). Je trouve juste que 850k lignes de SQL, c'est délirant, et j'imagine une hypothèse plausible qui pourrait expliquer ce chiffre.
              C'est p-e juste une typo et il y a que 8500 lignes de SQL pour autant que je sache.

          • [^] # Re: Analyse statique

            Posté par . Évalué à 0 (+0/-0).

            Ce qui réduit le code SQL significatif à ~100k lignes.

            Moins que ça, si on intègre les étudiants de première année en réorientation qui doivent aussi passer par Parcoursup.

  • # Usine à gaz

    Posté par . Évalué à 10 (+14/-1).

    858 752 lignes de SQL

    Ouais bin bon courage pour la maintenance les gars. Mais je dois être mauvaise langue, je ne doute pas que la doc est nickel.

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Usine à gaz

      Posté par . Évalué à 2 (+1/-0).

      Je serais curieux d'avoir une comparaison de ce volume de SQL avec un outil commercial quelconque, gros ERP ou autre, si quelqu'un a ça sous la main.

      • [^] # Re: Usine à gaz

        Posté par . Évalué à 10 (+11/-0). Dernière modification le 19/05/20 à 17:50.

        Ça ne veut rien dire comme métrique. Ça peut être des tonnes d'INSERT pour les données de référence utilisées par l'appli, ou des données de démo/test/exemple. C'est une info trop macro pour être interprétable.

        • [^] # Re: Usine à gaz

          Posté par (page perso) . Évalué à 10 (+11/-1).

          Une ligne de SQL par élève de terminale, ça semble raisonnable non ?

          • [^] # Re: Usine à gaz

            Posté par . Évalué à 0 (+2/-4).

            xD

            Sérieusement pour les néophytes qui auraient peut être pas les notions et qui liraient ce fil gérer un import avec des INSERT en dur comme ça pue vraiment du cul.

            1. On structure les données.
            2. On utilise un programme qui va lire les données structurées qui va gérer l'import en base de données en générant les requêtes adéquates.

            Le jour ou tu dois ajouter un champs ou gérer une liaison supplémentaire tu comprends très vite que d'avoir des INSERT en dur c'est une très grosse connerie.

            • [^] # Re: Usine à gaz

              Posté par . Évalué à 1 (+0/-1).

              Le jour ou tu dois ajouter un champs ou gérer une liaison supplémentaire tu comprends très vite que d'avoir des INSERT en dur c'est une très grosse connerie.

              Tu peut avoir des problèmes similaire avec des données structurée. Si ta modification est simple et qu'il s'agit d'ajouter une colonne ou une liaison sur du SQL correctement formaté ça n'est pas très compliqué à faire. C'est moins souple, moins performant, etc

              En plus ça peut être tout à fait être ce que tu dis sauf qu'ils n'ont pas intégré l'outil à leur build pour de bonnes ou de mauvaises raisons même si c'est une bonne pratique qu'il soit intégré.

              • [^] # Re: Usine à gaz

                Posté par . Évalué à 3 (+1/-0).

                Le SQL à parser pour faire ça rapidement et en étant sur de son coup par rapport à des données structurées et un script faudra vous lever tôt pour me justifier une telle pratique car vous comptez justement sur une bonne structuration de quelque chose qui est très souple à ce niveau dans sa normalisation.

                Au final vous me dites qu'il ont peut être fait ça proprement mais qu'ils ont pas mis l'outil… Alors qu'est ce que cela vient faire dans le code source ? C'est là dessus qu'est faite l'analyse pas sur une build.

                Bref je sens que j'ai visiblement touché une corde sensible vu les réactions mais bon posez vous les bonnes question si cela fait partie de vos pratiques.

      • [^] # Re: Usine à gaz

        Posté par (page perso) . Évalué à 6 (+4/-0).

        Un ERP utilise généralement un ORM ou un framework pour ne pas à avoir à maintenir du SQL.

        • [^] # Re: Usine à gaz

          Posté par . Évalué à 2 (+0/-0).

          Les ERP utilisent pas mal de requêtes complexes comme les requêtes OLAP. Je n'ai pas rencontré d'ORM qui savaient en faire.

          • [^] # Re: Usine à gaz

            Posté par (page perso) . Évalué à 3 (+1/-0).

            De ce que je peux en dire, de la fenêtre OpenConcerto, c'est que l'ORM gère la vie de données manipulées (création, modification et archivage) ainsi que les "listes".
            OLAP ne servant qu'à faire du reporting dynamnique, cad à travers une interface graphique qui va créer une requête MDX qui sera exécutée par le moteur OLAP, nul besoin de passer par l'ORM.
            Donc, au final, pas de SQL ou MDX "en dur".

      • [^] # Re: Usine à gaz

        Posté par . Évalué à 3 (+2/-1). Dernière modification le 20/05/20 à 07:59.

        comparaison de ce volume de SQL avec un outil commercial quelconque, gros ERP ou autre

        Après la question est : est-ce comparable ? La fonction de ParcourSup est-elle finalement plus ou moins complexe qu'un gros ERP ? Le pb c'est que quand on nous explique les règles de ParcourSup, ça va vite, tu te dis qu'en 1000 lignes c'est codé.

        Mais ce qui me fait peur, c'est que 800k lignes de code, c'est pour un outil qui est tout neuf. Si on va comparer avec un gros ERP, on va tomber sur un outil qui a 20 ans (et donc qui fatalement est tombé dans l'usine à gaz).

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: Usine à gaz

          Posté par . Évalué à 0 (+3/-4).

          C'est de la m… parce que cela a été développé à l'arrache (par une boîte qui a mis 50 développeurs dessus et qui n'a pas livré le code histoire de pouvoir se faire payer pour la maintenance, pourquoi aller chercher plus loin ? le code est peut être même perdu.

          La plupart des développements commerciaux sont comme ça. Si ça fait fantasmer de croire encore dans une cabale du gouvernement, "qui est méchant, qui fait tout mal et qui ne veut que du mal aux administrés", c'est triste.

          • [^] # Re: Usine à gaz

            Posté par . Évalué à 3 (+2/-0).

            Au temps pour moi, quelqu'un a répondu plus haut. ça a été développé par le ministère.

          • [^] # Re: Usine à gaz

            Posté par . Évalué à 7 (+5/-0).

            je ne leur jete pas trop la pierre, si c'est une boite privée qui l'avais pondu, ca aurait couté plus chère ET ca ne fonctionnerais pas. Avec la liste des excuses bidon que le gouvernement ou la boite aurait pondu, c'est pas nous, les cahier des charges etait insuffisant, c'est l'autre ministre qui la choisi, Edouard à validé la solution, le marché public était honnête etc …

            peut etre faire un logiciel libre sur gitlab avec des domaines attribué au université informatique/ministère + les contributeurs bénévole, un peu comme linux.

            • [^] # Re: Usine à gaz

              Posté par (page perso) . Évalué à -1 (+1/-4).

              « le marché public était honnête »

              Mort de rire ! Évidemment, ça excuserai tout si une telle ignominie était avérée. Sur le fond, quand on compare avec le logiciel de paye des armées récemment … je ne trouve pas le mot parce que ça a été mis au rébus sans avoir jamais fonctionné, disons quand même développé … par un grand groupe, on se dit que parcoursup/APB c’est tout de même excellent.

              En revanche, l’idée de faire auditer un code par la cour des comptes, a un petit côté république bananière néolibérale un peu incongru.

              « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

              • [^] # Re: Usine à gaz

                Posté par . Évalué à 3 (+2/-0).

                En revanche, l’idée de faire auditer un code par la cour des comptes, a un petit côté république bananière néolibérale un peu incongru.

                La cour des comptes est une autorité administrative indépendante

            • [^] # Re: Usine à gaz

              Posté par . Évalué à 5 (+3/-0).

              je ne leur jete pas trop la pierre, si c'est une boite privée qui l'avais pondu, ca aurait couté plus chère ET ca ne fonctionnerais pas.

              Bien sûr on montre les exemples qui marchent le moins, mais les logiciels de l'état ne se limite pas à quelques exemples comme louvois. service-public.fr et ces prédécesseurs fonctionnent bien par exemple.

              peut etre faire un logiciel libre sur gitlab avec des domaines attribué au université informatique/ministère + les contributeurs bénévole, un peu comme linux.

              1. ce serait bien de rétribuer les développeurs seul l'état en a un intérêt donc ça se rapprocherait beaucoup de l'existant
              2. c'est quoi le modèle de gouvernance du projet ? il peut y avoir des pressions fortes de la part de contributeurs pour pousser des idées dans le code (ça existe potentiellement déjà, mais c'est exacerbé en acceptant des contributions extérieures)
        • [^] # Re: Usine à gaz

          Posté par (page perso) . Évalué à 3 (+1/-0).

          Le pb c'est que quand on nous explique les règles de ParcourSup, ça va vite, tu te dis qu'en 1000 lignes c'est codé.

          Yakafocon (ctmetcsdc).

    • [^] # Re: Usine à gaz

      Posté par (page perso) . Évalué à 10 (+10/-0).

      Le SQL en soi n'est pas forcément une mauvaise chose. Il faut garder à l'esprit que pour tout ce qui est opérations ensemblistes, il est tout à fait adapté !

      Par contre, utiliser du SQL pour faire du pure procédural, la c'est déjà plus que moyen.

      Bon, après, je suis allé jeté un oeil, et dans ce cas précis, ça pique les yeux. Entre l'usage intensif de curseurs (donc du procédural !), des boucles WHILE (encore du procédural !), des variables aux noms abscons (on remarque malgré tout l'usage d'une convention, mais elle ne coule pas de source et il faut donc la doc à côté pour la comprendre, enfin, s'il y en a une !).

      Mes yeux pleurent. Je vais les changer…

      • [^] # Re: Usine à gaz

        Posté par . Évalué à 8 (+6/-0). Dernière modification le 20/05/20 à 11:23.

        J’ai pas regardé le code, mais c’est peut-être pas totalement débile d’utiliser un moteur SQL pour le problème de parcousup. C’est un problème qui s’apparente au problème des mariages stables qui s’attaque relativement bien vu comme un problème de satisfaction de contraintes, donc dans un cadre ensembliste.

        Les algorithmes qui résolvent ce genre de problème utilisent souvent des méthodes de Propagation de contraintes, avec en interne des machins qui peuvent s’apparenter à des curseurs SQL … d’ou peut être l’idée d’implémenter ça en utilisant le moteur SQL. Mais faudrait savoir s’il a été envisagé d’utiliser un vrai solveur de contraintes et si ça n’a pas été fait pourquoi. Peut-être que les moteurs SQL sont plus adaptés pour les volumes de données en jeu.

        • [^] # Re: Usine à gaz

          Posté par . Évalué à 6 (+4/-0). Dernière modification le 20/05/20 à 11:50.

          C’est un problème qui s’apparente au problème des mariages stables qui s’attaque relativement bien vu comme un problème de satisfaction de contraintes, donc dans un cadre ensembliste.

          Pour ceux qui préfèrent une vidéo explicative il y en a une sympa sur la chaine de ScienceEtonnante (j'ai découvert en recherchant cette vidéo, qu'il y a un mouvement de vidéos « réaction aux résultats ParcourtSup' »)

    • [^] # Incompréhensible

      Posté par . Évalué à 0 (+0/-1).

      858 752 lignes de SQL

      Ce chiffre me laisse sans voix.

      Je n'arrive pas à comprendre. Supposons que l'on ait deux bases de données, en SQL classique (mySQL ou PosgreSQL par exemple) :

      • une base des élèves avec leur adresse, leur voeux, leur résultats scolaires
      • une base des établissements avec leur adresse, les enseignements proposés et le nombre de places disponibles.

      Ça ne parait pas insurmontable de trouver une formule qui attribue une note à chaque élève, sous forme vectorielle (comme des coordonnées, mais à plusieurs dimensions), puis de calculer la distance avec le vecteur-établissement.

      Le programme, qui pourrait être réalisé dans n'importe quel langage classique (C, python), ferait :

      for each éleve
          lire les données (avec des SELECT)
          calculer sa note
          rechercher l'établissement dont le vecteur est le plus proche
          affecter l'élève
      

      Quelques centaines de lignes de code devraient suffire.

      Qu'en pensez vous ?

      • [^] # Re: Incompréhensible

        Posté par . Évalué à 3 (+1/-0).

        Les commentaires juste au dessus du tiens pointent des algos de mariages stables et décrivent les propriétés des résultats.

        Comme indiqué par rewind, ils ne peuvent plus être utilisés par choix politique.

      • [^] # Re: Incompréhensible

        Posté par (page perso) . Évalué à 5 (+4/-0).

        L'affectation des candidats doit respecter l'ordre d'admission déterminé par les formations d'accueil. Le résultat produit par Parcoursup est un couplage entre les formations et les candidats. Des couplages, il en existe un paquet pour un même jeu de données. On en cherche un qui possède certaines propriétés intéressantes (et même avec cela, il n'est pas unique).

        Voici trois propriétés typiques :

        • couplage maximum : on affecte le plus grand nombre de candidats pour laisser le moins de gens sans rien à la rentrée (algo polynomial dans le graphe biparti des formations/candidats). Cela cherche juste à exhausser le maximum de vœux, peu importe les préférences des candidats ;
        • couplage de poids maximum : on donne un score à chaque affectation (1 si c'est le vœu préféré du candidat, 0 si c'est son pire vœu). On cherche un couplage qui maximise tous la somme des scores en se disant que ça satisfera les candidats. Effets pervers : l'algo peut préférer refuser un couplage de score 1 pour permettre deux autres couplages de scores 0.7 ;
        • couplage stable : on garantit que, pour chaque candidat, il est impossible de lui proposer un meilleur vœu de son point de vue que celui qu'il a déjà. (Un couplage non stable, c'est lorsque Alice et Bob sont mariés, Dave et Charlie aussi, mais qu'en fait les premiers des deux couples se préfèrent ainsi que les seconds.)

        L'algorithme que tu donnes est un algorithme glouton qui produit un couplage qui n'est ni stable ni maximum.

        Parcoursup produit un couplage stable. Ce n'est à priori pas un couplage maximum mais vu le nombre de formations et de candidats, et vu le fait que le graphe des vœux n'est pas très connexe, ça ne tombe pas très loin.

        Quant aux morceaux de SQL, j'ai déjà dit plus loin qu'il y a, historiquement d'après ce qui avait été publié d'APB, de nombreux morceaux qui ont été codés en PL/SQL plutôt que dans un langage plus courant. Il faut aussi voir que les modèles de données sont gigantesques (état civil, liste des vœux, description de toutes les formations avec de nombreux paramètres pour chacune, réponse aux vœux, classements des candidats, résultats scolaires, dossier scolaire complet). J'aurais tellement aimé avoir accès au code pour en avoir le cœur net, mais ça fait un paquet de tables et dans chacune un paquet de colonnes pour tout décrire.

        • [^] # Re: Incompréhensible

          Posté par . Évalué à 1 (+1/-0). Dernière modification le 29/05/20 à 00:12.

          Une différence entre le problème Parcoursup et le cadre classique des problèmes de couplage: chaque jour il y a des candidats qui partent de la plateforme soit parce qu'ils ne répondent pas aux propositions qui leur sont faites, soit parce qu'ils échouent au bac, choisissent une formation hors parcoursup, en apprentissage, etc…

          Donc un couplage stable à l'instant t ne l'est plus à l'instant t+1

          Comme APB, Parcoursup respecte les préférences des candidats: les formations classent les candidatures puis appellent les candidats dans l'ordre de ce classement, et la plateforme transmet toutes les propositions aux candidats, c'est à eux de choisir selon leurs préférences. Il n'y pas d'algorithme d'apprentissage ni d'optimisation globale mis à part dans le cas particulier de l'attribution des places d'internat en prépa.

          Les algos sont décrits dans ce document:
          https://framagit.org/parcoursup/algorithmes-de-parcoursup/-/blob/master/doc/presentation_algorithmes_parcoursup_2020.pdf

          et le code sur ce dépôt:
          https://framagit.org/parcoursup/algorithmes-de-parcoursup

  • # Jean Pepu

    Posté par (page perso) . Évalué à 9 (+11/-5). Dernière modification le 19/05/20 à 18:07.

    L'État au dessus des lois et au dessous de la sincérité, j'en peux plus.

  • # Tiens, puisqu'on en parle...

    Posté par . Évalué à 3 (+4/-2).

    … Ça tombe bien :-)

    Fuite de 6500 dossiers confidentiels parcoursSup

    Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.

    • [^] # Re: Tiens, puisqu'on en parle...

      Posté par (page perso) . Évalué à 8 (+7/-0).

      Cette divulgation de dossiers n'est pas une faille de Parcoursup.

      Lorsque les candidats ont validé leurs dossiers, Parcoursup fournit les données aux formations afin qu'elles examinent les dossiers et qu'elles choisissent leur classement. Cela prend la forme d'un tableur (récapitulatif de tous les candidats) et de documents PDF (dossiers individuels) à télécharger.

      Chaque établissement doit partager ces données avec les membres de la commission qui examine les vœux. À ce moment-là, Parcoursup n'intervient plus. Le responsable du traitement des données est le chef d'établissement. L'exemple montre que, dans un grand nombre de formations, le traitement est plus ou moins artisanal.

      Les fichiers sont souvent manipulés directement par les professeurs, qui peuvent n'avoir aucune compétence particulière devant un ordinateur et ne pas comprendre exactement tout ce qu'ils font (notamment du point de vue sécurisation des données). Dans les lycées, il n'y a absolument aucun informaticien dédié ou même joignable pour des demandes ponctuelles. Tout est souvent bricolé à grands coups d'échanges de fichiers par e-mail ou clé USB.

      Cette année, les commissions ont dû entièrement travailler à distance. Je suis presque étonné que cela ne soit arrivé qu'à une seule formation. Ils ont laissé filer leur lien Dropbox, ce qui est fort malheureux. Cela arrivera à d'autres tant que l'on n'affectera personne pour les aider à faire leur travail tout en implémentant un peu de sécurité.

      • [^] # Re: Tiens, puisqu'on en parle...

        Posté par . Évalué à 7 (+6/-0).

        Dans mon établissement, certains collègues voulaient faire les commissions de recrutement à distance. Je suis passé pour un emmerdeur parce que je leur ai dit qu'il était hors de question de manipuler des données personnelles n'importe comment (les stocker sur des machines personnelles, les faire transiter par mail… ou par un cloud quelconque!).

        Le proviseur nous a bien fait déplacer ; et certains qui avaient effectivement des proches fragiles ne sont pas venus… l'organisation a été adaptée (masque, gel, gants, distances…).

  • # Des mesures seront prises

    Posté par . Évalué à 10 (+10/-3).

    Et croyez-moi, ça va barder. On ne fait pas n'importe quoi avec l'argent du contribuable.
    Le prestataire a déjà annoncé être en contact avec les universités pour retrouver les stagiaires coupables!

    -----> [ ]

  • # fr.gouv.education.Nein

    Posté par (page perso) . Évalué à 7 (+6/-2). Dernière modification le 21/05/20 à 09:05.

    Le plus important est à la page 95 du bilan

    Des créations de places décorrélées des besoins effectifs

    On peut mettre en place un super système de sélection avec de l'apprentissage profond et de la blockchain ou bien un simple concours de qui pisse le plus loin, si le nombre de place reste stable et que le nombre d'élèves augmente, tout algo de sélection tends vers celui-ci:

        package fr.gouv.education {
    
            public class Nein implements Selection {
                @Overrides
                public boolean accepte(Candidat c) {
                    return false;
                } 
            }
    
        }
    
    

    Incubez l'excellence sur https://linuxfr.org/board/

  • # A propos de transparence

    Posté par . Évalué à 2 (+2/-0).

    La cour a des exigences de transparence qu'elle ne s'applique pas à elle-même: où est le rapport d'audit? quel a été son coût? Quelles sont ces 1 582 violations critiques? Sont-ce des bugs et ont-ils perturbé le fonctionnement de la plateforme? A ce jour les bugs connus étaient non pas dans le code mais dans les données d'entrées (notamment classements erronés des IFSI et paramétrages surcapacitaires).

    Pour info voici le code source public:

    https://framagit.org/parcoursup/algorithmes-de-parcoursup

    et le travail de vérification du LRI évoqué dans le rapport

    https://hal.inria.fr/hal-02447409

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.