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…

Carnaval numérique au Forum des Sciences de la Villette : Micro:bit, macro-possibilités

Crédit : Wikipédia

Cela fait déjà quelques temps que je m’amuse régulièrement avec le Micro:bit, un mini-ordinateur développé par la BBC et à destination de l’apprentissage du code. Le prétexte particulièrement justifié d’organiser lors du Carnaval Numérique de l’AN@É un atelier consacré à cette petite merveille de l’électronique.

Lancé en 2015, le Micro:bit est destiné à être distribué dans l’ensemble des écoles de Grande Bretagne et la BBC prévoyait un minimum d’un million d’exemplaires. Le projet fait écho au BBC Micro, un ordinateur distribué dans un objectif pédagogique à hauteur d’1,5 millions d’exemplaires au début des années 80, et plus récemment au projet de la fondation américaine OLPC (One Laptop Per Child) qui a distribué plusieurs millions d’ordinateurs XO aux enfants de pays en voie de développement.

Le Micro:bit connaît un franc succès et ne devrait pas tarder à envahir nos contrées. Il faut reconnaître qu’il possède un certain nombre d’atouts non négligeables. Sa modularité et les différentes approches possibles en font un dispositif incontournable pour des projets pédagogiques qu’ils soient à orientation technique, artistique ou scientifique.

Ne cherchez pas d’écran. Le Micro:bit tient dans la main et se contente d’un affichage de 5 leds sur 5. Cela paraît réduit de prime abord mais convient tout à fait aux projets dédiés au Microbit et force à penser à la manière des anciens jeux vidéos et du graphisme 8 bits.

Le Micro:bit peut être alimenté via un câble USB connecté à l’ordinateur mais aussi par deux piles 1,5 volts, le rendant ainsi portable. Il s’intègre alors dans des dispositifs divers : boîte en carton, support imprimé en 3D, porte-bagde, tissu…

La liste du matériel électronique embarqué par le Micro:bit est impressionnante pour un si petit dispositif : accéléromètre, gyroscope, compas, capteur de température. Deux boutons peuvent être programmés à souhait et 5 connecteurs permettent de piloter des composants, d’utiliser le corps comme interrupteur comme pour une Makey Makey ou d’ajouter une sortie sonore tel un buzzer par exemple car le Micro:bit peut produire du son, de la musique et possède même des fonctions de synthèse vocale.

Coté code, le Micro:bit peut se programmer en ligne via le site officiel au travers de deux interfaces : l’une orientée programmation graphique façon Blockly et reprenant la syntaxe du Javascript, l’autre en code « texte » avec le langage Python. D’autres modalités sont disponibles, notamment au travers de Scratch et des extensions ScratchX http://scratchx.org/ Un éditeur hors-ligne, MU, est aussi disponible. Il est aussi possible d’utiliser des applications Android et iOs pour communiquer avec le Micro:bit et le programmer. De nombreuses autres extensions tant logicielles qu’électroniques sont disponibles et il me tarde d’y plonger.

Pour les premiers pas, j’ai tendance à utiliser la version Blockly en ligne car, outre sa similitude avec Scratch, elle dispose d’un émulateur. Cela permet de faire découvrir le Micro:bit même si l’on ne dispose pas du précieux artefact.

L’accueil des enfants fut enthousiaste. Envie d’explorer, de bidouiller, de bricoder… Tant avec la petite machine qu’en utilisant le simulateur. Cela promet de belles perspectives d’atelier auxquelles il ne reste plus qu’à ajouter un scénario, un univers au-delà des simples aspects techniques.

Scratch : comment analyser une chaîne de caractères et la valider

Scratch n’offre pas de manière naturelle des commandes permettant de travailler avec des chaînes de caractères ni ce que l’on appelle des « regex » ou expressions régulières permettant de rechercher des motifs particuliers dans un texte. L’opération n’est cependant pas impossible. En effet, travaillant depuis peu à la création d’un interpréteur Logo sous Scratch, tout simplement un petit programme permettant de jouer et dessiner avec la tortue comme dans le bon vieux Logo ou des logiciels comme Géotortue, j’ai été confronté au problème de la gestion des erreurs de frappe. Faire un interpréteur est en soi assez simple. Gérer les possibles erreurs faites par l’utilisateur relève par contre un peu plus du parcours du combattant.

Ainsi, par exemple, j’ai créé une fonction nommée « tn » pour « turn » qui est suivie d’un nombre de degrés. Celle-ci fait tourner la tortue à gauche ou à droite en fonction du nombre de degrés entrés, le sens naturel choisi étant celui des aiguilles d’une montre.

Sont considérées comme correctes les syntaxes suivantes :

• tn 9 -> tourne de 9 degrés ; de même que tn -9 (cette fois, dans le sens inverse des aiguilles d’une montre)
• tn 25 -> tourne de 25 degrés ; de même que tn -25
• tn 132 -> tourne de 132 degrés ; de même que tn -132

Il nous faut donc vérifier que les commandes entrées par l’utilisateur correspondent bien à ce schéma.

Première étape avant de vérifier le reste de la séquence, s’assurer que la commande entrée est bien « tn ». Pour cela, on analyse les deux premières lettres de la réponse.

Une fois « tn » validée, nous pouvons vérifier la longueur de la séquence. L’exemple « tn 9 » nous montre que la taille minimum est 4 caractères et avec l’exemple « tn -132 » le maximum 7 caractères. Imbriquons un nouveau test dans la commande « si … sinon … ». Je choisis de les imbriquer pour faire au plus simple. C’est un peu moche mais nous verrons par la suite une méthode permmetant de d’obtenir quelque chose de plus cohérent et simple à lire.

Rien cependant ne m’empêche de taper « tnhkdj » et de recevoir le message « OK ! ». Nous savons que le troisième caractère doit obligatoirement être un espace. Ajoutons donc un nouveau test en dessous du premier.

Une fois ces tests passés, nous savons que notre commande est valide. Reste à savoir si l’utilisateur n’a fait aucune erreur dans la saisie du paramètre. Nous allons vérifier caractère par caractère. Les caractères acceptés sont « 0123456789-« . En dehors, point de salut. La commande sera automatiquement rejetée. Pour ne pas trop alourdir le code, il vaut mieux créer une fonction à part et l’utiliser dans le code principal.

C’est là que cela se complique un peu. Il me faut d’abord créer 5 variables. Petit rappel sur les noms variables : une variable peut porter n’importe quel nom mais il convient de lui donner un nom explicite de manière à pouvoir se souvenir facilement de son rôle. Personnellement j’ai tendance à reprendre sans cesse les mêmes noms de projet en projet afin de ne pas me perdre. Voici mes variables pour analyser la réponse de l’utilisateur :

• string : la chaîne de caractères à analyser, correspondant à tout ce que l’utilisateur va entrer après « tn « 
• count1 : un premier compteur utilisable dans une boucle
• count2 : un second compteur
• chars : la liste des caractères acceptés, soit « 0123456789-« 
• verify : un compteur permettant de comptabiliser le nombre de tests validés ; si le paramètre entré est par exemple « -123 », soit 4 caractères, et que « verify » est égal à 4, on sait que les 4 caractères ont été validés ; si « verify » est égal à 3, un caractère est faux et invalide complètement le paramètre tapé par l’utilisateur (par exemple « -12a »)

Première étape : éliminer « tn  » de la chaîne de caractères à analyser, soit ne s’intéresser qu’au reste de la chaîne à partir du caractère n°3.

Après utilisation de cette commande, ma variable « string » est bien égale à « -123 » si je tape « tn -123 ». Il s’agit maintenant de vérifier si chaque caractère de cette variable est bien compris dans l’ensemble « chars », soit « 0123456789-« .

On commence par réinitialiser le premier compteur. Le code suivant comporte deux boucles.

La première passe en argument les caractères un à un de la chaîne, soit dans le cas de « -123 » : « -« , « 1 », « 2 », « 3 ». La seconde compare chacun de ces caractères aux caractères contenus dans la variable « chars ». Si l’un des tests est ok, c’est-à-dire que le caractère examiné est trouvé dans la variable « chars », on augmente la variable verify de 1.

Comme vous l’avez compris, un test validé = 1 point. Pour que le test soit complet, il faut que le nombre de points corresponde à la longueur de la chaîne de caractères. On vérifie cela avec une nouvelle condition « si … alors … sinon … ».

Petit conseil au passage: il vaut mieux avant intégration du script dans le programme utiliser des messages d’erreur personnalisés, chaque erreur générant un message particulier. Cela facilite la vie au moment de débuguer. On évite aussi de masquer l’affichage des variables tant que le script n’est pas fini.

Avons-nous d’ailleurs terminé ? Presque. Il reste un détail à régler : corriger la variable en cas de mauvaise valeur. Par exemple, dans notre cas, tourner de 360 degrés ou plus serait stupide car cela revient à faire un tour complet et plus. Pour revenir à une valeur plus raisonnable, il suffit de faire une division par 360 ou -360 en cas de valeur négative et de conserver le reste.

Pour éviter d’imbriquer des « si … alors … sinon … » à répétition, il suffit de s’inspirer de la méthode utilisée avec la variable « verify ». Si l’on attribue un point à chaque test validé, le score obtenu à la fin permettra de déterminer si le texte entré apr l’utilisateur est valide (par exemple, 10 tests effectués et score = 10 -> texte valide ; 10 tests effectués et score = 7 -> texte non valide).

Lien pour télécharger le script.