ParcourSup et algorithmes : le principe de diabolisation

Crédit : Viewminder (Flickr)

Dire que ParcourSup rencontre quelques petits problèmes est un euphémisme… Cela semble malheureusement être le plantage total. Et, comme de coutume, je vois fleurir les commentaires façon « c’était mieux avant ». La technologie a bon dos.

Pourtant une machine ne fait que ce qu’on lui demande de faire. Elle ne va pas plus loin. Quand un programme est codé avec des moufles, il y a bien une paire de mains dans ces dernières.

Se planter n’est pas grave mais il y a un moment pour se planter. Comme pour les artistes, ce n’est pas sur scène qu’il faut se planter mais lors des répétitions. C’est à ce moment que le plantage est salvateur car il révèle des failles et des erreurs de conception que l’on peut alors corriger.

On peut appliquer ce que j’appelle le principe de diabolisation. Concevoir, coder un algorithme est plus ou moins complexe et, dans la majorité des cas, on l’imagine dans des conditions idéales. C’est le moteur de base qui est loin d’être fini et qui ne fonctionnerait tel quel que dans un paradis comme la planète Beatituda que les Simpson sont censés atteindre un jour dans un épisode consacré aux sectes. Mais je m’égare… Les conditions idéales n’existent pas et on va alors viser des conditions de M… Je vous laisse compléter.

Se faire l’avocat du diable, c’est en effet se poser la question de savoir qu’est-ce qui va bien pouvoir « merder » dans la solution que l’on a mise en place. Passez moi le terme car c’est celui qui convient. C’est un principe « hacker » que de chercher la petite bête, que d’imaginer des conditions diverses parfois complètement folles dans lesquelles la solution va planter lamentablement. Un développeur qui a pour adage « bon, ça ira comme ça » est soit un incompétent, soit un inconscient tout droit sorti des Télétubbies, soit enfin un adepte des mises à jour plus que fréquentes. Diaboliser, c’est prévoir et prévoir, c’est jouer la carte de la sécurité pour laquelle il ne faut pas hésiter à aller très loin dans le délire.

Par exemple :

« Affluence record : on n’a pas assez de serveurs pour répondre. » -> « Ok, mise en place d’une autre série de serveurs en cas de débordement. »

« Le circuit électrique tombe en panne. » -> « Ok, on prévoit des générateurs indépendants. »

« Batman ne trouve pas sa voie. » -> « Ok, on ouvre une section supplémentaire. »

« La Russie, la Corée du Nord et les États-Unis prévoient une attaque de grande ampleur pour déstabiliser le site . -> « Ok, on a une équipe sur le coup et un bon rempart en place. »

« Une météorite menace de s’écraser sur le data center ou un peu plus loin dans l’océan. » -> « Ok, on reporte à la semaine prochaine et, en attendant, on va boire un coup. »

« Rien ne va. C’est l’apocalypse. » -> « Ok, on a une belle page 404 avec les indications à suivre et des messages rassurants. »

Je plaisante avec ces exemples. Le problème est qu’aujourd’hui nous sommes face à un enjeu extrêmement important et un fiasco qui risque de mettre sur le carreau nombre de jeunes étudiants. On ne sait déjà pas trop ce que l’on veut faire à 18 ans alors si en plus on nous met des bâtons dans les roues… Personnellement je bénis le fait de n’avoir pas connu ce casse-tête. Je ne sais pas dans quelle section je me serais retrouvé. Je n’aurais en tous cas sûrement jamais pu faire les études que j’ai effectuées.

Alors, innovons aujourd’hui, innovons demain mais testons, testons encore, testons encore plus loin, cassons la machine, une fois, deux fois, trois fois mais, j’insiste : comme au théâtre, lors des répétitions pas lors de la première…