Bonjour à toutes et tous,

Je pose la question d'un choix pédagogique devenu quasi standard dans l’enseignement secondaire : l’usage de Python comme langage d’initiation à la programmation, dès le collège (via Scratch puis Python) et surtout au lycée (SNT, NSI, mathématiques, physique…).

Ce choix est-il le fruit d’une réflexion approfondie de l’Éducation nationale sur les paradigmes d’apprentissage ? Ou bien s’agit-il d’un glissement opportuniste, dicté par des considérations pratiques (abondance de ressources, compatibilité matérielle, popularité académique, logiciel libre) ?




Une architecture non-objet… pour un langage objet ?


L’ordinateur, dans son architecture fondamentale (CPU, mémoire, jeu d’instructions), n’est pas orienté objet. Le paradigme natif est impératif, séquentiel, typé. Les instructions machine ne connaissent ni classes, ni méthodes, ni héritage.

Or Python, bien qu’il permette une programmation impérative, est un langage orienté objet. Même les types de base (`int`, `str`, `list`) sont des objets. Cela pose une question pédagogique :
Est-il pertinent d’initier les élèves à la programmation via un langage qui repose sur une abstraction non native à la machine ?


Jadis, des langages non-objet ont historiquement suffi



- BASIC (Plan Informatique pour Tous, initiation dès le primaire) : langage textuel accessible dès le primaire, avec une syntaxe directe et impérative.
- Pascal : langage structuré, typé, conçu pour l’enseignement, utilisé au lycée dans les années 1990–2000.
- Logo, Caml, Ada : autres langages pédagogiques, chacun avec ses forces, souvent non-objets.

Ces langages disposaient déjà de bibliothèques scientifiques abondantes, notamment en mathématiques et physique. L’argument souvent avancé pour Python — “il y a plein de bibliothèques” — semble donc anachronique : ce n’est pas une nouveauté propre à Python.

La pré initiation aux concepts algorithmiques pouvaient se faire dès le primaire hors cadre de l'activité informatique, par exemple la capacité à exécuter une recette de cuisine :
- Recette = algorithme narratif :
- Ingrédients → variables initialisées
- Étapes → instructions séquentielles
- Conditions → “jusqu’à ce que ce soit doré” = boucle avec condition d’arrêt
- Répétitions → “remuer pendant 5 minutes” = boucle bornée
Cette analogie, très utilisée dans les années 1980-90, permettait une acculturation implicite à la logique algorithmique, bien avant l’introduction de langages formels.


Risques pédagogiques d’un glissement trop rapide


- Effet boîte noire : les élèves manipulent des objets sans comprendre leur structure interne ni leur traduction en instructions machine.
- Perte de rigueur algorithmique : typage faible, syntaxe permissive, absence de compilation explicite.
- Dépendance à des abstractions : on appelle des méthodes (`.append()`, `.sort()`) sans comprendre les algorithmes sous-jacents.



Que dit l’Éducation nationale ?


Le document officiel sur éduscol ( https://eduscol.education.fr/document/16078/download ) présente Python comme un langage procédural, adapté à l’enseignement scientifique. Il met en avant :
- Sa syntaxe simple
- Son interprétation directe
- Son intégration dans les calculatrices
- Et surtout… l’abondance de bibliothèques scientifiques

Mais ce dernier point mérite débat : les langages non-objets disposaient eux aussi de bibliothèques riches, et l’argument semble davantage relever de l’écosystème que du paradigme pédagogique.


- Le choix de Python a-t-il été pensé en termes de paradigme d’apprentissage, ou dicté par des considérations pratiques ?
- Ne faudrait-il réintroduire une étape intermédiaire, avec un langage impératif pur, pour mieux comprendre la machine ?
- Comment éviter que les élèves deviennent des “utilisateurs de bibliothèques” plutôt que des “concepteurs d’algorithmes” ?

Je serais curieux d’avoir vos retours, notamment si vous êtes enseignants.
Ce n’est pas une critique dogmatique, mais une invitation à réfléchir collectivement à ce que nous transmettons quand nous enseignons un langage.