Priorité aux candidats de l’académie

[jferard]

Le document explicatif (https://github.com/arnaudriegert/comprendre-apb/blob/master/apb/static/algorithme-apb-menesr.pdf) précise que

Ce classement donne priorité aux candidats de l’académie du siège de l’établissement proposant la formation non sélective dont les capacités d’accueil sont insuffisantes pour retenir l’ensemble des candidatures puis puis tient compte des tient compte des préférences exprimées par le candidat.

Est qu'il est possible de dire précisément où cette priorité est mise en oeuvre dans le script abp.sql (ou bien si elle est mise en oeuvre avant l'appel ou simplement dans le paramétrage de l'appel) ?

(Cf. question dans le message initial de @GuillaumeTara dans https://github.com/jeantil/admission_post_bac/issues/17)

[GuillaumeTara]

Après relecture de l'algo, il semblerait que cette priorité académique ne soit pas mise en oeuvre dans l'algo actuel. Seule possibilité : que cette priorité soit faite dans la fonction six_voeu_L1 qui est manquante et qui renvoie sans doute un booléen (ou alors un numéro) qui est le premier à classer les candidats. Le problème de cette théorie c'est que six_voeu_L1 semble plutôt vérifier que les candidats IDF ont bien inscrit 6 voeux de licence (c'est une obligation sinon ils passent en dernier). Surtout qu'a priori l_six_voe, le critère utilisé pour savoir si on passe dans six_voeu_L1 semble n'être initialisé que pour les candidats de certains groupes en IDF (voir le cas X:='01'). En bref 2 options : (i). Il ne s'agit que d'un algorithme qui traite les formations en IDF. Question => qu'en est-il des formations dans d'autres académies (ii). Il s'agit d'un algorithme qui au début s'occupait des formations en IDF et qui a été étendu (sans qu'il n'y ait pour autant changement du nom des variables).

=>Dans tous les cas des éléments de réponse se trouveront, certainement, dans la fonction six_voeux_L1... Il faut donc que le Ministère communique - entre autres - cette partie de l'algorithme.

[jferard]

@GuillaumeTara ça me rassure, parce que je me demandais s'il y avait une chose évidente qui me passait sous le nez. Je ne pense pas que ce soit dans la fonction six_voeu_L1 car, comme tu dis, elle n'est activée que sous conditions. Pour que ça se passe dans cette fonction, il faudrait que le code fourni mette toujours l_six_voe à 1. Difficile à imaginer.

D'après le modèle, le seul moyen d'arriver à l'académie serait depuis les tables a_rec ou g_tri_ins (signification ?) (la première contient une référence vers la seconde), g_tri_ins ayant elle-même une référence à l'établissement (g_eta) puis au département (g_dep) puis à l'académie (b_aa_cod ?). Or le code ne suit pas du tout ce chemin.

L'hypothèse (i) est la plus probable, mais on peut toujours avoir des surprises.

[Sboulahia]

Attention, rien ne confirme que le flag g_ti_flg_rec_idf indique que la formation se trouve en Île-de-France. Ce qu'il semble, c'est que ce flag désigne les licences en tension qui au début se trouvaient toutes en IDF et qui n'existaient pas encore dans les autres régions à l'époque de la conception de cet algorithme.

Quoi qu'il en soit, le code source montre ce flag n'a pour effet que d'appliquer des conditions supplémentaires pour trier les candidats.

[jferard]

@Sboulahia Mais la priorité académique devrait s'appliquer à tous les cas (hors EFE), hors la condition supplémentaire six_voeu_L1 n'est apparemment mise en oeuvre que sous certaines conditions. Ca reste très obscur pour moi.

[Sboulahia]

@jferard Ce qui est sûr c'est que hors de ces conditions seul l'ordre du vœu dans la liste est pris en compte dans le classement. Le code le confirme bien.