Re: Nouveau programme de mathématiques en 2de. Rentrée 2019

Simeon a écrit:Par contre sur les listes en seconde le programme n'est absolument pas respecté, et j'ai aussi vu des tests d'égalités sur des flottants.. (ce qui est équivalent voire pire qu'une division par 0)

Pas forcément, mais il faut garder en tête qu'il y a beaucoup de nombres et de calculs qui ne « tombent pas juste », et que le code compilé pour du Intel 32 bits n'est pas fiable de ce point de vue.
Exemple de nombre ne tombant pas juste, en Python:

Code:: $ python Python 3.7.3 (default, Mar 26 2019, 21:43:19) [GCC 8.2.1 20181127] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from decimal import Decimal >>> Decimal(0.1) Decimal('0.1000000000000000055511151231257827021181583404541015625')

Mathador a écrit:

Simeon a écrit:Par contre sur les listes en seconde le programme n'est absolument pas respecté, et j'ai aussi vu des tests d'égalités sur des flottants.. (ce qui est équivalent voire pire qu'une division par 0)

Pas forcément, mais il faut garder en tête qu'il y a beaucoup de nombres et de calculs qui ne « tombent pas juste », et que le code compilé pour du Intel 32 bits n'est pas fiable de ce point de vue.
Exemple de nombre ne tombant pas juste, en Python:

Code:

$ python Python 3.7.3 (default, Mar 26 2019, 21:43:19) [GCC 8.2.1 20181127] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from decimal import Decimal >>> Decimal(0.1) Decimal('0.1000000000000000055511151231257827021181583404541015625')

Oui, il faut garder en tête que cela donne des résultats faux, que ça n'a pas de sens et qu'il ne faut pas le faire, c'est pour ça que je dis que c'est comme la division par 0.
Pourquoi en Intel 32 bits ?

Je dis voire pire, parce qu'il y a très vite des conséquences:

https://web.archive.org/web/20100702180720/http://mate.uprh.edu/~pnm/notas4061/patriot.htm

Simeon a écrit:Oui, il faut garder en tête que cela donne des résultats faux, que ça n'a pas de sens et qu'il ne faut pas le faire, c'est pour ça que je dis que c'est comme la division par 0.

Ce ne sont pas des résultats faux, mais des résultats conformes aux opérations effectives des opérations sur les flottants, avec tous les travers qu'elles ont (par exemple, l'addition n'est pas associative).

Simeon a écrit:Pourquoi en Intel 32 bits ?

Dans les processeurs modernes d'architecture Intel (ce qui inclut les processeurs AMD), il y a deux jeux d'instructions pour le calcul flottant:
-le plus ancien (x87), qui se base sur une « pile de registres » et qui est très riche en fonctionnalités (notamment en termes du nombre de fonctions transcendantes implémentées), et qui permet des calculs en 3 précisions (32 bits, 64 bits et 80 bits, respectivement float, double et long double en C);
-le nouveau (SSE et SSE2), apparu avec le Pentium III, qui ne fait que les 5 opérations de base (+,-,×,÷, racine carrée), en précisions float et en double uniquement, mais permet de calculer sur plusieurs nombres à la fois (calcul vectoriel, au sens de l'informatique).
Le jeu d'instruction x87, contrairement à SSE et SSE2, ne permet pas de préciser la précision avec laquelle on fait les opérations; cette précision est un réglage global*. Par défaut, sous Windows et Linux, c'est la précision long double. Cela rend le résultat des calculs en float et en double tributaire** des choix de l'allocateur de registres du compilateur.
Exemple: sur le code suivant

Code:: double a = pow(2.,1000.); double b = a*a; if (a*a != b) { puts ("boum"); }

b vaut +inf (car 2¹⁰⁰⁰ n'est pas représentable dans la précision double). Par contre pour la comparaison du if, le compilateur peut calculer a*a dans les registres (ce qui donne 2²⁰⁰⁰, qui est représentable en long double), le comparer avec b qui vient d'être chargé dans un autre registre (ce qui donne +inf en long double); le code du if est alors exécuté. Par contre si le résultat intermédiaire de a*a (qui est, selon le standard du C, un double) est stocké en mémoire (ce que l'on peut imposer avec l'option -ffloat-store de GCC), il sera arrondi à +inf donc le code du if ne sera pas exécuté.
En SSE, ces complications disparaissent: le compilateur émettra l'instruction mulsd qui opère directement sur la précision double, donc le code du if ne sera pas exécuté.
Sous Windows et Linux, par défaut, les programmes 32 bits utilisent x87 et les programmes 64 bits utilisent SSE et SSE2.
On trouvera davantage de détails dans l'article suivant de David Monniaux: The pitfalls of verifying floating-point computations.

*et qui ne permet de restreindre à la précision float ou double que la mantisse, pas l'exposant.
**en principe c'est réglé avec C99, mais il faut déjà que le compilateur gère cet aspect du standard…

Simeon a écrit:Je dis voire pire, parce qu'il y a très vite des conséquences:

https://web.archive.org/web/20100702180720/http://mate.uprh.edu/~pnm/notas4061/patriot.htm

Comme cela peut être le cas pour tout programme que l'on a pas prouvé. La seule différence avec l'arithmétique flottante c'est que le comportement effectif est plus éloigné de l'objet mathématique modélisé que dans le cas de l'arithmétique entière (où l'addition, la soustraction et la multiplication se comportent comme dans Z/2ⁿZ, où n est le nombre de bits de la représentation).

Badiste75 a écrit: Le tout en demie classe.

Et quand on a toutes nos heures en classe entière, et sans salle info, on fait comment ?

On commence par faire lire le programme au CDE puis on contacte les IPR qui, s’ils font leur boulot prendront contact avec le CDE. Si ça n’est toujours pas suffisant, on fait intervenir les syndicats, les parents, on fait pression. Si vraiment rien ne suffit, on laisse tomber. Je n’ai pas un CDE pro maths (il laisse passer en S des élèves à 6 en maths avec moi en Seconde). Ils ont 5 au bac maximum en général. Mais il n’est pas non plus dans une optique de démolir les maths et les profs de maths.

Mathador a écrit:

Simeon a écrit:Oui, il faut garder en tête que cela donne des résultats faux, que ça n'a pas de sens et qu'il ne faut pas le faire, c'est pour ça que je dis que c'est comme la division par 0.

Ce ne sont pas des résultats faux, mais des résultats conformes aux opérations effectives des opérations sur les flottants, avec tous les travers qu'elles ont (par exemple, l'addition n'est pas associative).

Je ne dis pas que l'égalité entre flottant est une opération non définie. L'analogie est plutôt au niveau de l'ordre d'importance des erreurs, par exemple avec une division par 0 dans une suite d'équivalence, et un test d'égalité entre flottant non contrôlé dans un programme qui vont faire apparaitre/disparaitre des solutions.
Ici, on parle de programme en Python qui par exemple: sont sensés déterminer si 3 points sont alignés en testant l'égalité entre flottants issus d'une division sans aucun contrôle. Il n'y a pas besoin d'aller chercher bien loin des exemples où le résultat sera faux...

Mathador a écrit:

Simeon a écrit:Pourquoi en Intel 32 bits ?

Dans les processeurs modernes d'architecture Intel (ce qui inclut les processeurs AMD), il y a deux jeux d'instructions pour le calcul flottant:
-le plus ancien (x87), qui se base sur une « pile de registres » et qui est très riche en fonctionnalités (notamment en termes du nombre de fonctions transcendantes implémentées), et qui permet des calculs en 3 précisions (32 bits, 64 bits et 80 bits, respectivement float, double et long double en C);
-le nouveau (SSE et SSE2), apparu avec le Pentium III, qui ne fait que les 5 opérations de base (+,-,×,÷, racine carrée), en précisions float et en double uniquement, mais permet de calculer sur plusieurs nombres à la fois (calcul vectoriel, au sens de l'informatique).
Le jeu d'instruction x87, contrairement à SSE et SSE2, ne permet pas de préciser la précision avec laquelle on fait les opérations; cette précision est un réglage global*. Par défaut, sous Windows et Linux, c'est la précision long double. Cela rend le résultat des calculs en float et en double tributaire** des choix de l'allocateur de registres du compilateur.
Exemple: sur le code suivant

Code:

double a = pow(2.,1000.); double b = a*a; if (a*a != b) { puts ("boum"); }

b vaut +inf (car 2¹⁰⁰⁰ n'est pas représentable dans la précision double). Par contre pour la comparaison du if, le compilateur peut calculer a*a dans les registres (ce qui donne 2²⁰⁰⁰, qui est représentable en long double), le comparer avec b qui vient d'être chargé dans un autre registre (ce qui donne +inf en long double); le code du if est alors exécuté. Par contre si le résultat intermédiaire de a*a (qui est, selon le standard du C, un double) est stocké en mémoire (ce que l'on peut imposer avec l'option -ffloat-store de GCC), il sera arrondi à +inf donc le code du if ne sera pas exécuté.
En SSE, ces complications disparaissent: le compilateur émettra l'instruction mulsd qui opère directement sur la précision double, donc le code du if ne sera pas exécuté.
Sous Windows et Linux, par défaut, les programmes 32 bits utilisent x87 et les programmes 64 bits utilisent SSE et SSE2.
On trouvera davantage de détails dans l'article suivant de David Monniaux: The pitfalls of verifying floating-point computations.

*et qui ne permet de restreindre à la précision float ou double que la mantisse, pas l'exposant.
**en principe c'est réglé avec C99, mais il faut déjà que le compilateur gère cet aspect du standard…

Ce n'était pas la question que je sous entendais, ma question était plutôt: est-ce que Python te donnera un résultat différent selon le processeur que tu utilises ? Et sinon pourquoi mentionner le type de processeur ?
Car à ma connaissance toute implémentation correcte de Python est sensé respecter la norme IEEE 754 et cela indépendamment du processeur.

La norme IEEE754 n'est pas déterministe, c'est le sujet principal de l'article de David Monniaux dont j'ai donné le lien.
Je ne parle d'ailleurs pas du type de processeur en lui-même mais de l'architecture de l'exécutable: un programme compilé pour Intel 32 bits posera les même problèmes qu'on l'exécute sous Windows 32 bits, Windows 64 bits, Linux 32 bits ou Linux 64 bits.
A priori le problème d'allocation de registres dont je parle ne devrait pas se poser avec Python qui est interprété, mais il peut tout de même y avoir des blagues avec numpy ou avec PyPy. Et il y a d'autres sources de différences possibles, même pour les langages interprétés, notamment lorsque l'on sort des 5 opérations (qui sont les seules pour lesquelles IEEE 754 demande un arrondi correct): dans le passé j'ai déjà observé des valeurs différentes pour des calculs du type sin(1) ou log(2) selon que je le faisais sous OCaml 32 bits ou OCaml 64 bits (l'interpréteur interactif, pas la version compilée); en refaisant le test maintenant, avec des versions plus récentes, j'obtiens désormais le même résultat.

Prezbo a écrit:Première idée de thème niveau seconde : Déterminer par balayage un encadrement de √2 d’amplitude inférieure ou égale à 10−n.

Code:

def balayage(n): a=1 b=2 h=10**(-n) x=a while x**2<2: x=x+h return (round(x-h,n),round(x,n))

Quelques remarque sur le code :

Le code n'est pas commenté : quels sont les paramètres de la fonction ? Quel est le résultat de la fonction ?
La variable b ne sert à rien dans le code. Pourquoi apparaît elle ?
La variable a a un rôle anecdotique. On pourrait écrire directement x=1 au lieu de définir a puis x
Pourquoi l'auteur du script prend-il le soin d'arrondir la valeur de x et x-h, alors que x est de façon évidente un nombre décimal ?
Si vous connaissez la réponse à la réponse précédente, vous pourrez facilement conclure que la boucle while est une boucle infinie lorsque n=16 (ou toute autre valeur supérieure à 16)

On pourrait corriger le code en :

Code:: def balayage(n): """ Paramètre --------- n : entier naturel Résultat -------- x-h,x : réel Nombres décimaux encadrant racine(2) à 10**(-n) près """ h=10**(-n) k=0 x=1 while x**2<2: k=k+1 x=1+k*h return x-h,x

et tant pis si balayage(3) donne un résultat bizarre. Ou plutôt tant mieux, cela permet de mettre en évidence les subtilités des nombres réels à virgule flottante.

Sur le lien que j'ai donné, l'auteur de l'algorithme évoque le problème de la boucle infinie pour n ≥ 16. Il propose une deuxième version, plus rapide, mais qui ne règle toujours pas le problème.

Sur l'histoire des fonctions, je suis dubitatif.
Créer des fonctions qui ne seront utilisées qu'une fois ou deux, faire des contorsions pour éviter des entrées-sorties comme si c'était le mal absolu (la plupart des cours de programmation commencent pourtant par print("hello world") …), ne pas les documenter, ne pas se poser la question de la portée des variables, n'est-ce pas mettre en place de mauvaises habitudes ?

Et les collègues qui — faute de formation suffisante ou d'intérêt pour la chose — ne sont pas conscients de ces problèmes (représentation des flottants ou autre), et qui se retrouveront confrontés à des situations où la seule réponse qu'ils pourront donner aux élèves est « bah, je sais pas pourquoi ça marche pas », on y pense ? Le programme de première (générale et techno) parle de manipulation de listes. Enfin zut, c'est pas une structure facile, les listes, ça n'a rien de « naturel », ça ne s'improvise pas au débotté, au détour d'un exercice sur les suites ou les stats … Selon moi, l'introduction de la programmation (python ou autre) pendant les cours de maths, toute contingence matérielle mise à part, ne peut être que vouée à l'échec.

Absolument. Parfois le plus simple est d'attendre, le soufflet va retomber tout seul.

Mathador a écrit:La norme IEEE754 n'est pas déterministe, c'est le sujet principal de l'article de David Monniaux dont j'ai donné le lien.
Je ne parle d'ailleurs pas du type de processeur en lui-même mais de l'architecture de l'exécutable: un programme compilé pour Intel 32 bits posera les même problèmes qu'on l'exécute sous Windows 32 bits, Windows 64 bits, Linux 32 bits ou Linux 64 bits.
A priori le problème d'allocation de registres dont je parle ne devrait pas se poser avec Python qui est interprété, mais il peut tout de même y avoir des blagues avec numpy ou avec PyPy. Et il y a d'autres sources de différences possibles, même pour les langages interprétés, notamment lorsque l'on sort des 5 opérations (qui sont les seules pour lesquelles IEEE 754 demande un arrondi correct): dans le passé j'ai déjà observé des valeurs différentes pour des calculs du type sin(1) ou log(2) selon que je le faisais sous OCaml 32 bits ou OCaml 64 bits (l'interpréteur interactif, pas la version compilée); en refaisant le test maintenant, avec des versions plus récentes, j'obtiens désormais le même résultat.

Le coup du log(2) m'a donné des cheveux blancs quand j'étais en maîtrise. J'ai mis du temps à comprendre que c'était l'origine du dysfonctionnement de mon programme... Ahhhh souvenirs souvenirs

Anaxagore a écrit:Absolument. Parfois le plus simple est d'attendre, le soufflet va retomber tout seul.

Sur la joue de qui ?

VinZT a écrit:
Sur l'histoire des fonctions, je suis dubitatif.
Créer des fonctions qui ne seront utilisées qu'une fois ou deux, faire des contorsions pour éviter des entrées-sorties comme si c'était le mal absolu (la plupart des cours de programmation commencent pourtant par print("hello world") …), ne pas les documenter, ne pas se poser la question de la portée des variables, n'est-ce pas mettre en place de mauvaises habitudes ?

J'y suis plutôt favorable pour plusieurs raisons:
- tel que c'était fait avant, on ne voyait que des programmes/algo qui ne pouvaient communiquer qu'avec un utilisateur direct, cela donnait pour moi une représentation très fausse des choses, et ne laissait pas vraiment envisager comment ces algos/prog permettent d'arriver à des constructions complexes
- afficher/etc ne sont pas des notions algorithmiques contrairement aux fonctions
- print/input/etc sont des formes d'interfaces graphiques, il est important de séparer la partie logique de la partie interface graphique
- la question de la portée des variables me semble vraiment trop complexe pour être traitée en math en lycée, mais dans une approche fonctionnelle il n'y a pas à se poser cette question dans un premier temps, on ne considère que ce qui entre et sort des fonctions en évitant les effets de bord (ok, ça demande une bonne formation du côté prof..)
- le découpage en fonction est quand même le premier pas vers du code propre et documenté, je préfère lire du code avec un bon découpage en fonction et sans commentaire, qu'un code avec de bons commentaires mais pas de fonction. Après, rien empêche de documenter les fonctions, ça peut même être un bon outil pédagogique.
- tout les cours de programmation ne commencent pas par print("Hello world !"), il y a énormément de cours qui commencent directement avec une approche fonctionnelle, c'est rarement le cas des cours en ligne, mais c'est très souvent ce qu'on trouve dans les cours des universités d'informatique. (je dirais que c'est le cas dans les cours d'info de première année du MIT, de Paris 6, d'une majorité de cours d'option info en MP, etc.)
- il est possible de réutiliser plus qu'une ou deux fois une fonction, je pense que ça vaut le coup d'organiser la construction d'une bibliothèque au fur et a mesure de l'année

Absolument. Parfois le plus simple est d'attendre, le soufflet va retomber tout seul.

L'algorithmique est là depuis 10 ans, non ? Je dirais que Python est là pour 10 ans... Ça peut faire long 20 ans à attendre qu'un soufflet retombe.

Jusqu'à présent on ne peut pas dire que l'enthousiasme des foules ait dû être contenu.

BR a écrit:

Prezbo a écrit:Première idée de thème niveau seconde : Déterminer par balayage un encadrement de √2 d’amplitude inférieure ou égale à 10−n.

Code:

def balayage(n): a=1 b=2 h=10**(-n) x=a while x**2<2: x=x+h return (round(x-h,n),round(x,n))

Quelques remarque sur le code :

Le code n'est pas commenté : quels sont les paramètres de la fonction ? Quel est le résultat de la fonction ?
La variable b ne sert à rien dans le code. Pourquoi apparaît elle ?
La variable a a un rôle anecdotique. On pourrait écrire directement x=1 au lieu de définir a puis x
Pourquoi l'auteur du script prend-il le soin d'arrondir la valeur de x et x-h, alors que x est de façon évidente un nombre décimal ?
Si vous connaissez la réponse à la réponse précédente, vous pourrez facilement conclure que la boucle while est une boucle infinie lorsque n=16 (ou toute autre valeur supérieure à 16)

On pourrait corriger le code en :

Code:

def balayage(n): """ Paramètre --------- n : entier naturel Résultat -------- x-h,x : réel Nombres décimaux encadrant racine(2) à 10**(-n) près """ h=10**(-n) k=0 x=1 while x**2<2: k=k+1 x=1+k*h return x-h,x

et tant pis si balayage(3) donne un résultat bizarre. Ou plutôt tant mieux, cela permet de mettre en évidence les subtilités des nombres réels à virgule flottante.

Bon, j'ai depuis longtemps enfoncé mon seuil d'incompétence, mais pourquoi le second code évite-t-il le problème de la boucle infinie ? Je ne vois pas ce qu'amène le remplacement du x=x+h par x=1+k*h. (Pas très naturel, un produit étant a priori plus coûteux à effectuer.)

Pas grave, les élèves et 90 % des profs n'y verront que du feu, un peu comme les intervalles de fluctuation qui mergiturent.

Je ne suis pas prête d'enseigner ça ... je ne comprends rien à ce que vous racontez ! C'est grave, docteur ?

Non, mais tu devrais « interroger ton professionnalisme » (parole d'ipéhère, vue sur un autre fil) Razz

VinZT a écrit:Non, mais tu devrais « interroger ton professionnalisme » (parole d'ipéhère, vue sur un autre fil)

Et en plus, on veut m'imposer d'enseigner les SNT et je refuse ...

VinZT a écrit:Non, mais tu devrais « interroger ton professionnalisme » (parole d'ipéhère, vue sur un autre fil)

Je crois que le terme exact est "professionnalité".

Ah merdre ! De toutes façons, je retiens jamais ce qu'ils disent, c'est ballot, hein ?

Anaxagore a écrit:Absolument. Parfois le plus simple est d'attendre, le soufflet va retomber tout seul.

Moi je serai encore plus radical et je répète ce que j'ai déjà écrit il y a quelques temps : il ne suffit pas d'attendre, il faudrait boycotter activement la partie programmation.

Comme le disait VinZT, l'introduction de la programmation (python ou autre) pendant les cours de maths, toute contingence matérielle mise à part, ne peut être que vouée à l'échec et j'ajouterai que cela aura inévitablement un impact négatif sur l'enseignement des maths car, en plus de brouiller notre discours avec des incursions dans un autre domaine voisin mais distinct, le temps passé à faire de la programmation - pour un bénéfice quasi nul - sera autant de temps perdu pour les notions de base des maths sur lesquelles les élèves sont souvent déjà en difficulté.

Je sais bien que certains collègues de maths ont une formation plus poussée en informatique (qu'ils aient un diplôme ou qu'ils aient appris en autodidactes), sont passionnés par le sujet et auront du mal à se retenir de se faire plaisir en exécutant de magnifiques tours de prestidigitation avec du code Python devant des élèves médusés. J'ai conscience aussi que d'autres, soucieux de respecter les textes, vont considérer qu'il faut vaille que vaille essayer de traiter toutes les parties du programme officiel. Mais, dans tous les cas, il faut être réaliste : en dehors des secteurs géographiques qui sont classés comme des "parcs naturels" de l'élite, ces programmes (seconde et première) ne peuvent tout simplement pas être correctement traités dans le temps imparti avec les élèves qui sortent actuellement du collège. Il faut faire des choix entre traiter certaines parties trop superficiellement pour qu'il en reste quelque chose ou faire de franches impasses ; même sans la partie relative à l'informatique les programmes sont déjà impossibles à boucler.

Devant ces programmes trop chargés, nous allons concrètement être obligés de faire le travail qu'aurait dû faire faire le groupe d'experts qui les a rédigés, à savoir les élaguer pour les rendre compatibles avec la réalité des classes tout en essayant de préserver une certaine cohérence. La charge et la responsabilité de ce travail d'élagage vont inévitablement retomber sur les enseignants de lycée en fonction et il est probable que les choix seront en définitive effectués localement selon le profil du lycée et la dynamique entre collègues, avec toutes les tensions que cela présage. Dans un tel contexte, un mouvement de boycott organisé à grande échelle permettrait non seulement de marquer notre opposition à la réforme mais aussi d'alléger le poids de la responsabilité des choix locaux ; si une partie du programme n'est massivement pas traitée à échelle nationale, les inspecteurs devront en tenir compte lors de la conception des sujets ou devront alors assumer un rapport de force à un moment où les retours de formation que j'ai pu avoir semblent suggérer qu'ils ont perdu une grande partie de l'assurance qu'ils pouvaient manifester devant les enseignants.

D'un point de vue pédagogique, pour les raisons évoquées plus haut, l'impasse sur la partie programmation me paraît être le choix d'élagage le plus évident et aussi le plus rentable en terme horaire : il conviendrait de ne pas aller plus loin que ce qui se fait actuellement avec de l'algorithmique en langage pseudo-naturel, et c'est sans doute déjà trop pour un résultat plus que médiocre. Une fois que les programmes de terminale seront divulgués, il apparaîtra sans doute d'autres allégements possibles à la marge dans les programmes de seconde et de première.

Je sais que le mouvement des "Stylos Rouges" n'a eu qu'une efficacité limitée, que ses revendications se sont beaucoup trop dispersées dans des détails et diluées dans des débats sans fin pour rester audibles et réussir à créer une dynamique, mais en s'inspirant de la forme et en se concentrant sur un objectif ciblé d'un mouvement de protestation des profs de maths contre la réforme du lycée avec boycott organisé de certaines parties précises du programme (dont la programmation), il est peut-être possible d'obtenir des résultats. D'ailleurs, quand je discute avec les collègues des autres matières, tous me confirment que leurs futurs programmes sont aussi trop chargés pour être réalistes ; sans doute serait-il pertinent de lancer une vague de boycotts similaires discipline par discipline pour faire un front commun.

Moonchild a écrit:

Anaxagore a écrit:Absolument. Parfois le plus simple est d'attendre, le soufflet va retomber tout seul.

Moi je serai encore plus radical et je répète ce que j'ai déjà écrit il y a quelques temps : il ne suffit pas d'attendre, il faudrait boycotter activement la partie programmation.

Comme le disait VinZT, l'introduction de la programmation (python ou autre) pendant les cours de maths, toute contingence matérielle mise à part, ne peut être que vouée à l'échec et j'ajouterai que cela aura inévitablement un impact négatif sur l'enseignement des maths car, en plus de brouiller notre discours avec des incursions dans un autre domaine voisin mais distinct, le temps passé à faire de la programmation - pour un bénéfice quasi nul - sera autant de temps perdu pour les notions de base des maths sur lesquelles les élèves sont souvent déjà en difficulté.

Je sais bien que certains collègues de maths ont une formation plus poussée en informatique (qu'ils aient un diplôme ou qu'ils aient appris en autodidactes), sont passionnés par le sujet et auront du mal à se retenir de se faire plaisir en exécutant de magnifiques tours de prestidigitation avec du code Python devant des élèves médusés. J'ai conscience aussi que d'autres, soucieux de respecter les textes, vont considérer qu'il faut vaille que vaille essayer de traiter toutes les parties du programme officiel. Mais, dans tous les cas, il faut être réaliste : en dehors des secteurs géographiques qui sont classés comme des "parcs naturels" de l'élite, ces programmes (seconde et première) ne peuvent tout simplement pas être correctement traités dans le temps imparti avec les élèves qui sortent actuellement du collège. Il faut faire des choix entre traiter certaines parties trop superficiellement pour qu'il en reste quelque chose ou faire de franches impasses ; même sans la partie relative à l'informatique les programmes sont déjà impossibles à boucler.

Devant ces programmes trop chargés, nous allons concrètement être obligés de faire le travail qu'aurait dû faire faire le groupe d'experts qui les a rédigés, à savoir les élaguer pour les rendre compatibles avec la réalité des classes tout en essayant de préserver une certaine cohérence. La charge et la responsabilité de ce travail d'élagage vont inévitablement retomber sur les enseignants de lycée en fonction et il est probable que les choix seront en définitive effectués localement selon le profil du lycée et la dynamique entre collègues, avec toutes les tensions que cela présage. Dans un tel contexte, un mouvement de boycott organisé à grande échelle permettrait non seulement de marquer notre opposition à la réforme mais aussi d'alléger le poids de la responsabilité des choix locaux ; si une partie du programme n'est massivement pas traitée à échelle nationale, les inspecteurs devront en tenir compte lors de la conception des sujets ou devront alors assumer un rapport de force à un moment où les retours de formation que j'ai pu avoir semblent suggérer qu'ils ont perdu une grande partie de l'assurance qu'ils pouvaient manifester devant les enseignants.

D'un point de vue pédagogique, pour les raisons évoquées plus haut, l'impasse sur la partie programmation me paraît être le choix d'élagage le plus évident et aussi le plus rentable en terme horaire : il conviendrait de ne pas aller plus loin que ce qui se fait actuellement avec de l'algorithmique en langage pseudo-naturel, et c'est sans doute déjà trop pour un résultat plus que médiocre. Une fois que les programmes de terminale seront divulgués, il apparaîtra sans doute d'autres allégements possibles à la marge dans les programmes de seconde et de première.

Je sais que le mouvement des "Stylos Rouges" n'a eu qu'une efficacité limitée, que ses revendications se sont beaucoup trop dispersées dans des détails et diluées dans des débats sans fin pour rester audibles et réussir à créer une dynamique, mais en s'inspirant de la forme et en se concentrant sur un objectif ciblé d'un mouvement de protestation des profs de maths contre la réforme du lycée avec boycott organisé de certaines parties précises du programme (dont la programmation), il est peut-être possible d'obtenir des résultats. D'ailleurs, quand je discute avec les collègues des autres matières, tous me confirment que leurs futurs programmes sont aussi trop chargés pour être réalistes ; sans doute serait-il pertinent de lancer une vague de boycotts similaires discipline par discipline pour faire un front commun.

Merci beaucoup Moonchild de l'avoir si bien exprimé.

Las, les retours que j'ai de mes collègues, en établissement et en formation, me semblent plutôt montrer une certaine passivité...Il y a ceux qui ne voient pas les problèmes, et ceux qui les voient et les considèrent avec une sorte de fatalisme.

Je suis inquiet pour l'année prochaine. J'ai peur que les profs se séparent entre les malins qui tiendront un discours ferme en se vantant de tout traiter, sans s'appesantir sur le fait que certaines notions auront été vues disons vraiment vite, et ceux qui tenteront par conscience professionnelle de tout faire de ces programme, et qui risquent d'exploser en vol...