Dans son manuel de cycle 4, Sésamath a illustré le chapitre consacré au codage avec un langage visuel (Scratch) et un langage textuel (Python). Mais, comme c’est souvent le cas quand on parle de codage dans l’enseignement secondaire, les modalités de la transition entre programmation visuelle et programmation textuelle ne sont pas évoquées, ce qui laisse à penser qu’elle est uniquement de nature chronologique : on initie d’abord les collégiens de façon ludique avec Scratch, puis on passe à autre chose au lycée (ou en fin de collège) avec la programmation textuelle. La continuité pédagogique est alors réduite à peau de chagrin : il y a certes des boucles (des instructions conditionnelles…) dans les deux cas, mais ça s’arrête là.

Il est à craindre qu’une telle approche n’entraîne une attitude de rejet de la part de nombreux élèves lorsqu’ils aborderont la programmation textuelle : non seulement la programmation textuelle demande plus d’efforts, mais les applications développées sont moins valorisantes dans un premier temps car elle requiert plus de compétences. En d’autres termes, l’avancée pédagogique que constitue la programmation visuelle risque d’être anéantie si on ne fait pas l’effort de rendre plus attractif l’enseignement des langages textuels.

Pour y parvenir, une piste à privilégier est l’existence d’une passerelle entre Blockly et Python : les élèves commencent à faire de la programmation visuelle avec Blockly, puis obtiennent une traduction en Python en évitant ainsi les écueils syntaxiques d’un langage textuel. L’apport est également d’ordre sémantique : faut-il par exemple vraiment s’étonner que des élèves ne trouvent pas naturel de traduire un « pour k allant de 1 à 4 » en « for k in range(1,5) » ?

Dans un second temps, il faut affiner cette approche : en effet, la programmation visuelle n’est pas très pratique lorsqu’il faut saisir une expression mathématique telle que b*b-4*a*c, et devient même totalement inadaptée dès qu’un programme atteint une taille critique. Par exemple, pour résoudre une équation du second degré avec Python, je suggère de commencer à écrire avec Blockly le squelette de programme ci-dessous, puis d’en obtenir la traduction en Python et de la compléter :

Il est probable que la plupart des élèves arrivant du collège ne connaîtront pas Blockly. Mais, formés à Scratch et donc à la programmation par blocs, ils s’adapteront sans peine. D’ailleurs, avec mes étudiants d’IUT certes un peu plus âgés mais non formés à la programmation par blocs, j’ai constaté qu’ils ne mettaient que quelques minutes pour devenir opérationnels.

SofusPy reprend plusieurs caractéristiques fondamentales de Sofus (voir article) : des blocs pour transformer des variables (augmenter/diminuer, augmenter/diminuer d’une proportion...), des blocs pour manipuler une ou plusieurs tortues... Sa nouveauté est l’ajout d’un traducteur vers Python, ainsi que d’un interpréteur Python.

Pour plus d’informations, je renvoie les lecteurs vers « SofusPy, une passerelle entre programmation visuelle et Python », un article co-écrit avec Alain Busser et publié par l’IREM de la Réunion. Il est conçu pour un public d’enseignants « non spécialistes » et détaille plusieurs exemples adaptés à l’enseignement des mathématiques : c’est donc le document introductif que je recommande aux lecteurs envisageant d’enseigner Python via la programmation par blocs.

Pour expliquer l’évolution de PluriAlgo et son apport pédagogique, je vais repartir d’une copie d’écran de la version antérieure, présentée dans le N°44 (voir « Version en ligne du logiciel d’algorithmique PluriAlgo ») :

La solution naturelle est a priori d’ajouter un onglet « Blockly », avec des liens vers les diverses extensions mathématiques de Blockly, dont SofusPy. Un utilisateur de Python aurait donc quatre éditeurs à sa disposition :

• les éditeurs « Editeur 1 » et « Editeur 2 », répondant à l’objectif initial de PluriAlgo qui a été conçu pour engendrer ou transformer des programmes (onglets « Principal », « Si » et « Boucles ») stockés dans un ou deux éditeurs (« Editeur 1 » ou « Editeur 2 »).
• l’éditeur Python de l’onglet « Exécution », onglet non prévu au départ et qui a été ajouté pour permettre l’exécution en ligne de programmes Python ou AlgoBox.
• l’éditeur interne de SofusPy dans l’onglet « Blockly ».

Qu’il y ait quatre éditeurs directement disponibles risque de perturber les utilisateurs. C’est pourquoi la nouvelle version de PluriAlgo leur donne l’illusion qu’il n’y en a que deux :

• l’éditeur par défaut de l’onglet « Editeur 1 » peut, grâce à un lien interne, être remplacé par un éditeur Python doté d’un environnement d’exécution.
• l’éditeur par défaut de l’onglet « Editeur 2 / Blockly » peut , grâce à un lien interne, être remplacé par l’éditeur de blocs de SofusPy ou par son éditeur textuel.

Dans la section suivante, je vais expliquer quel intérêt pratique il peut y avoir pour un utilisateur de Python d’utiliser conjointement les deux onglets.

Pour écrire en Python un programme résolvant une équation du second degré, j’ai suggéré dans la section B de commencer par écrire un squelette de programme par blocs, ce qui nécessite de savoir comment faire apparaître une branche « sinonsi » dans un bloc « si » :

En cliquant sur le bouton Editeur (dans l’onglet « Blockly / Editeur 2 »), le programme Blockly est masqué et la traduction Python apparaît alors dans l’éditeur interne de SofusPy :

Il reste à compléter le programme directement, ce qui n’est pas difficile, mais :

• on peut gagner du temps pour la saisie des données (a, b et c) grâce à l’onglet « Principal » de PluriAlgo (indications).
• si on a un trou de mémoire pour la fonction racine carrée en Python, on souhaitera rebasculer vers l’éditeur Blockly pour ajouter un bloc « racine carrée » afin d’en obtenir la traduction : or, quand on rebascule vers l’éditeur Blockly de SofusPy (bouton « Blockly » de l’onglet « Blockly / Editeur 2 »), on perd les modifications déjà apportées au programme Python, d’où l’intérêt de disposer d’un second éditeur (celui de l’onglet « Editeur 1 »).

Une autre possibilité est de commencer à gérer les entrées-sorties dans l’onglet « Editeur 1 » (indications), puis d’utiliser l’onglet « Si » de PluriAlgo (indications), puis d’utiliser Blockly pour obtenir le nom la fonction racine carrée en Python.

Dans l’article de présentation de SofusPy co-écrit avec Alain Busser (voir lien), le troisième exemple montre comment procéder pour calculer une approximation de Π avec la méthode des rectangles appliquée à l’intégrale suivante :

Dans un premier temps, l’article explique comment définir une fonction nommée f avec Blockly (indications), ce qui permet donc d’obtenir l’équivalent Python suivant :

Dans un second temps, l’article utilise la fonction f pour calculer l’intégrale avec la méthode des rectangles :

Comme ce programme par blocs, dont le bouton « Editeur » de SofusPy fournit la traduction, est quelque peu fastidieux à réaliser, je propose ici une alternative à SofusPy en utilisant l’onglet « Boucles » de PluriAlgo :

Avant de cliquer sur le bouton Créer, il faut sélectionner l’onglet « Editeur 1 » pour que le code suivant y soit ajouté par PluriAlgo :

Il ne reste plus qu’à faire un copier coller du code définissant la fonction f (éditeur 2) pour compléter le code de l’éditeur 1. Par acquis de conscience, je teste alors le programme et obtiens ... 0 ! J’avais en effet oublié que l’interpréteur Python implémente Python 2 et non Python 3, et que k/n est évalué comme une division entière et non une division réelle : donc, il faut remplacer f(k/n) par f(k/(float(n)) pour obtenir le résultat attendu, à moins que vous n’utilisiez une installation locale de Python pour l’exécution.

Python devenant le langage central au lycée, je vais en profiter pour illustrer en Python deux fonctionnalités avancées de PluriAlgo :

• la création de formulaires de saisie, qui peut être utile dans les options informatiques (ISN, ICN).
• la programmation objet, à mon avis prématurée au lycée, mais parfois abordée [1] à ma grande surprise car elle est délicate à enseigner, requiert une finesse d’analyse de la part des élèves et nécessite un volume horaire conséquent.

Comme je suppose que de nombreux lecteurs seront tentés de ne pas lire cette section par peur d’une trop grande technicité, je vais pimenter l’article avec un « numéro de cirque » : avec l’aide de PluriAlgo, vous allez écrire des programmes Python valides … sans que cela ne nécessite de connaissances en Python ni de connaissances en programmation objet !

Je ne prétends nullement donner ainsi une culture générale en programmation objet [2] aux lecteurs qui la découvriraient. Je ne prétends pas non plus que PluriAlgo soit un logiciel adapté à l’enseignement de la programmation objet : il facilite juste la transition entre programmation « classique » (plus savamment appelée programmation impérative) et programmation objet, grâce à un outil de reformulation de code que je vais présenter.

L’exemple 3 de l’aide interne de PluriAlgo explique comment obtenir un programme créant le formulaire ci-dessus, à partir de renseignements entrés dans l’onglet Principal (indications). A l’arrivée, il reste à compléter le code Python en calculant l’IMC (indice de masse corporelle) à partir de la taille et du poids :

Le code Python (télécharger) ne peut pas être exécuté en ligne car l’interpréteur Python de PluriAlgo n’implémente pas le module « tkinter ». Il reste donc à le transférer dans une installation locale de Python, où il y aura un petit problème d’exécution si elle implémente Python 3 et non Python 2 : l’instruction d’affichage engendrée par PluriAlgo (print ...) est en effet adaptée à Python 2.

PluriAlgo permet la création de formulaires de saisie dans plusieurs langages dont Php, langage parfois utilisé en ICN ou en ISN. Pour Php, le code créé est réparti dans les deux éditeurs de PluriAlgo : l’un contient le code Html du formulaire, l’autre contient le code Php permettant de récupérer les données saisies par l’utilisateur.

L’exemple 4 de l’aide interne de PluriAlgo décrit un outil de reformulation de code, facilitant la transition entre programmation « classique » et programmation objet :

• on entre dans un des deux éditeurs un programme non objet : en l’occurrence, il s’agit ici d’un programme sur le saut à skis où, à partir des notes de 5 juges, on calcule une note finale obtenue en éliminant la note la plus haute et la note la plus basse.
• on précise dans l’onglet Principal quelle classe d’objets on veut construire : en l’occurrence, on veut créer ici une classe Skieur regroupant plusieurs informations du programme initial (les 5 notes, le nom du skieur) et que cette classe possède un sous-programme (appelé méthode en programmation objet) calculant la note finale.
• on clique sur le bouton Reformuler de l’onglet Principal, ce qui crée dans le second éditeur un programme objet qu’il faut adapter ensuite.

Comme j’ai promis en introduction de vous faire écrire, avec l’aide de PluriAlgo, un programme Python valide sans connaissances préalables en programmation objet, je vais ici partir d’un programme très simple, à entrer dans l’éditeur 1 : imc = poids/(taille*taille)

Ensuite, il faut entrer les informations suivantes dans l’onglet Principal :

On obtient alors un programme objet opérationnel (télécharger), qui peut être testé avec l’interpréteur Python de PluriAlgo. Je vais commencer par commenter le programme principal, dont il est aisé de comprendre le sens à défaut d’en percevoir toutes les subtilités :

Ce programme crée un objet de classe Personne, puis lit les caractéristiques de la personne, puis calcule l’indice de masse corporelle de cette personne. La notation pointée montre que les deux méthodes utilisées (saisir et calculer_imc) s’appliquent à la personne désignée par la variable nommée « objet », nom à changer ensuite pour rendre le code plus clair.

La simplicité des notations dans le programme principal peut aider les lecteurs néophytes à percevoir un intérêt majeur de la programmation objet : grâce à elle, les développeurs d’applications peuvent facilement réutiliser des bibliothèques de classes écrites par d’autres programmeurs.

La programmation objet devient complexe lorsqu’on se place du côté des concepteurs de bibliothèques. Le code définissant une classe aussi simple que la classe Personne en fournit un début de « preuve » :

Ce code illustre aussi en partie pourquoi la programmation objet est difficile à enseigner : par exemple, il est délicat d’expliquer pourquoi l’objet doit s’appeler self (ou this dans d’autres langages) lors de la définition des méthodes et pourquoi self est un paramètre quand on définit les méthodes alors que ce paramètre disparaît quand on utilise les méthodes dans le programme principal.

La programmation objet est encore plus délicate à enseigner quand plusieurs objets interviennent dans une méthode, ce qui est le cas quand on fait découvrir la programmation objet à ses élèves en l’illustrant avec le cas des fractions (voir article du N°26). En effet les objets ont un rôle dissymétrique lorsque par exemple on veut additionner deux objets de classe Fraction avec une méthode nommée « plus » :

• dans le programme principal, on n’écrira pas « plus(objet1, objet2) », mais « objet1.plus(objet2) ».
• dans la définition de la méthode « plus », un des deux objets additionnés devra obligatoirement s’appeler self.

Pour les lecteurs curieux, je fournis le code légèrement amélioré (télécharger) obtenu avec PluriAlgo en appliquant une reformulation (indications) après avoir entré les formules suivantes dans l’éditeur 1 :