Discussion :

[nwaeffler]

Bonjour

De ce que l'on m'a expliqué (source venant d'un directeur d'établissement), la nouvelle réforme du bac prévoit un socle commun jusqu'en terminale. L'élève devra définir dès la seconde ses options et les choisira définitivement pour le bac en terminale. De mon point de vue, c'est un bac "à la carte".
Du coup, si le littéraire veut faire de la programmation, et bien, il choisit l'option dès la seconde et voit si cela lui plait.

@++

En fait, le cours de seconde est obligatoire, je le répète, et pour tout le monde. Par la suite, seuls quelques établissement auront le droit d'ouvrir la spécialité qui au vu du programme et dans l'esprit de la réforme sera destinée à des élèves qui veulent en faire leur métier. Quelle que soit la branche exacte par la suite. Mais honnêtement, qui peut faire de l'informatique sans différencier un entier d'une chaîne de caractère?

[Bktero]

Mais honnêtement, qui peut faire de l'informatique sans différencier un entier d'une chaîne de caractère?

Personne. Mais est-ce à toi de savoir comment stocker l'un ou l'autre ?

Si tu prends un langage statiquement fortement typé comme C++, tout est fait depuis des années (au fur et à mesure des versions du langage) pour écrire de moins en moins souvent explicitement les types. Le C++ moderne se base beaucoup sur le motto "almost always auto". En tant que tel, les services rendus par un objet sont plus importants que son type exact. Pas qu'on se fiche du type, mais on se fiche de le nommer explicitement soi-même. Il n'y a même des types que seul le compilateur connait et que tu récupères uniquement via des auto. Exemple :

Code cpp :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#include <iostream>
 
std::string get_name()
{
    return "marcel";
}
 
int main() {
    auto say_my_name = []() // type? too complicated, only compiler knows...
    {
        auto name = get_name(); // type? std::string but who really cares?
        std::cout << "My Name ? " << name << '\n';
    };
 
    say_my_name();
}

Parti de là... Le fait de ne pas avoir à donner les types en Python ne parait pas si délirant si même en C++ on évite de le faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
def get_name():
    return "Marcel"
 
say_my_name = lambda name: print("My Name?", name)
 
name = get_name()
say_my_name(name)

[wiztricks]

Mais honnêtement, qui peut faire de l'informatique sans différencier un entier d'une chaîne de caractère?

Python ne vous le permet pas plus: essayez d'ajouter/concaténer une chaîne de caractère à un nombre, çà va râler.
Mais si cela vous semble indispensable, les annotations permettent de typer variables et paramètres de fonctions. Et vous avez des outils qui vont vérifier que votre code est cohérent.
Techniquement, le typage des variables est utile lorsqu'on compile (çà simplifie l'écriture des compilos) et çà permettra de détecter des erreurs dans un projet avant la mise en production.
Mais avec Python entiers, chaînes de caractères, nombre flottants sont des objets différents (dont on peut faire de l'informatique) et si on peut appeler une fonction avec des entiers ou des flottants sans soucis, c'est ce qu'on appelle "polymorphisme" en programmation orientée objets.

- W

[marco056]

Ceux qui rédigent les textes officiels deviennent de moins en moins crédibles, imposer un langage de programmation, c'est exactement comme si on imposait de n'utiliser que des voitures Renault dans le Code de la route. Un texte officiel doit être plus large et évidemment dans notre cas le langage commun à tous les langage de programmation, c'est l'algorithme. Sans compter qu'il faudra acheter du matériel adapté pour faire de l'informatique embarquée et autres alors que ce matériel est déjà présent dans beaucoup établissements mais n'utilise pas python. Donc ça va encore être un gros gaspillage écologique et financier. N'oublions pas c'est nous qui payons tout ça.

Pour avoir enseigné Pytrhon qqs années en classe prépa, je trouve ce langage parfait : accès facile, indentation qui structure le bazar, coloration syntaxique suivant l'éditeur, bibliothèques utilisables en physique, chimie, ...
Je commence par quelques séances d'algorithme, mais très vite, les élèves ont envie de voir ce que cela donne et c'est là qu'on peut les accrocher (ou pas).
Une boucle infinie sur papier, bof bof alors que sur un PC, cela parle plus.
De la crypto ou du traitement d'images sur pc, c'est nettement plus intéressant que sur papier (ou sur Scratch).

Concernant les calculatrices, je suis plus que mitigé : en Terminale, j'avais à l'époque une HP28S avec un pavé alphabétique à gauche et un pavé numérique à droite. Je ne comprends pas qu'on n'ait pas la même chose aujourd'hui. Je possède les 3 calculatrice (Casio, TI et Numworks), c'est compliqué de passer des lettres aux chiffres. Du coup, je passe sur PC systématiquement.

[alex_ps]

Histoire de faire "sync(all)" , je résume ici le "parcours" de l'élève.

En seconde,
Enseignement obligatoire (pour tout le monde): Sciences Numériques et Technologie.
Enseignement optionnel: Création et Innovation Technologique & Sciences de l'Ingénieur

• Puis, dans l'enseignement en voie Générale,

En Première,
Enseignement obligatoire: /vide/
Enseignement de spécialité : Sciences de l'Ingénieur, Numérique et Sciences Informatiques

En Terminale (les programmes ne sont pas disponibles, mais on sait qu'ils seront dans la continuité)
Enseignement obligatoire: /vide/
Enseignement de spécialité : Sciences de l'Ingénieur, Numérique et Sciences Informatiques

• Dans l'enseignement technologique,

En première STI2D: Innovation Technologique & Ingénierie et Développement Durable
En Terminale STI2D: Ingénierie, Innovation et Développement Durable


Tous les (projets de) programmes sont ici.

Avec ces parcours, on voit bien que tout le monde aura droit à de la programmation et de l'algorithmique. Cela prolonge l'enseignement du collège et correspond à l'orientation prise depuis quelques années.
Ensuite, en première, c'est au choix de chacun : soit on approfondi, soit on laisse tomber.
Pour approfondir, on le fait de 2 manières: voie Générale (la spécialité NSI) ou voie Technologique (je réduis volontairement à STI2D, ce que je connais, mais il me semble qu'en STMG il y a de l'info aussi...)

De fait, dans toutes ces matières, Python est cité:
Pour l'enseignement de SNT, en seconde (commun à tous), le paragraphe qui définit le langage de programmation est le suivant :

Un langage de programmation est nécessaire pour l’écriture des programmes : un langage simple d’usage, interprété, concis, libre et gratuit, multiplateforme, largement répandu, riche de bibliothèques adaptées aux thématiques étudiées et bénéficiant d’une vaste communauté d’auteurs dans le monde éducatif est nécessaire. Au moment de la conception de ce programme, le langage choisi est Python version 3 (ou supérieure).

Pour la spécialité NSI (1e/Tle), le paragraphe qui définit le langage est le suivant:

Un langage de programmation est nécessaire pour l’écriture des programmes : un langage simple d’usage, interprété, concis, libre et gratuit, multiplateforme, largement répandu, riche de bibliothèques adaptées et bénéficiant d’une vaste communauté d’auteurs dans le monde éducatif est à privilégier. Au moment de la conception de ce programme, le langage choisi est Python version 3 (ou supérieure). L’expertise dans tel ou tel langage de programmation n’est cependant pas un objectif de formation.

Vous remarquerez que la différence entre les 2 tient sur l'ajout concernant "l'expertise" du langage. (Rem: normal, puisque c'est le même groupe qui a élaboré les programmes)

En STI2D, le paragraphe commentaire qui définit le langage est le suivant :

Les langages Python et C++ sont à utiliser.

Voilà.
Je précise donc que mes interventions dans ce fil concernent en premier lieu la spécialité NSI, sachant que j'ai le "tampon" pour intervenir dans toutes les matières citées ci-dessus...

J'en profite pour rebondir sur ce qui a été dit/évoqué par plusieurs, marco056 étant le plus récent: quid de l'algorithmique sur informatique ? Serait-il pertinent d'avoir un outil informatique qui permette de tester ses algorithmes ? Mais bon, c'est une question un peu HS

Si tu prends un langage statiquement fortement typé comme C++, tout est fait depuis des années (au fur et à mesure des versions du langage) pour écrire de moins en moins souvent explicitement les types.

Ça, ça m'interpelle par contre... d'un coté, on a une volonté de typer (depuis Python 3.6, c'est possible) et de l'autre une volonté de ne pas typer... faudra que je potasse

[Pyramidev]

Si tu prends un langage statiquement fortement typé comme C++, tout est fait depuis des années (au fur et à mesure des versions du langage) pour écrire de moins en moins souvent explicitement les types.

Ça, ça m'interpelle par contre... d'un coté, on a une volonté de typer (depuis Python 3.6, c'est possible) et de l'autre une volonté de ne pas typer... faudra que je potasse

Non, ce n'est pas le fait de ne pas typer, mais le fait de ne pas écrire explicitement le type.
Ce dont Bktero vient de parler est l'inférence de type : on n'écrit pas explicitement le type, mais le type est quand même connu lors de la compilation ou de l'analyse statique du code.

En Python, avec mypy, on a aussi de l'inférence de type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
def foo() -> None:
	x = 1
	y = '2'
	z = x + y # Erreur selon mypy, car on ne peut pas additionner un entier et une chaîne.
	print(z)

Dans cet exemple, je n'ai pas annoté x et y, mais mypy a pu deviner comme un grand que x était de type int et y de type str.
Cela dit, mypy ne fait cet effort que pour les fonctions dont on a annoté au moins un paramètre ou le type de retour. En effet, dans cet exemple, si je retire -> None, alors mypy ne vérifie rien. Cela permet de mettre en place une vérification progressive du typage dans un code qui n'utilisait pas encore les annotations de type.

[Invité]

C'est quand même incroyable de voir à quel point le terme "inférence de type" a été détourné. A l'origine, il s'agissait d'une vraie fonctionnalité consistant à calculer l'ensemble maximal des types d'une expression ou d'un programme, dans un langage à typage polymorphe (https://en.wikipedia.org/wiki/Hindle...er_type_system). Aujourd'hui, on utilise ce terme à tord et à travers dès qu'un langage propose un sucre syntaxique pour déduire bêtement un type à partir d'une valeur de retour. Le C++ a au moins l'honnêteté de parler de déduction de type et non d'inférence (https://isocpp.org/wiki/faq/cpp11-language#auto).

[tgen1]

Hmmm... pas facile de vous expliquer mais...
Prenons le français, c'est notre langue maternelle (pour la plupart). La maîtriser, c'est avoir acquis du vocabulaire et les construction grammaticale qui vont nous permettre d'exprimer de façon intelligible ce qui passe dans leur tête (idées, sentiments, émotions, ...).
Lançons nous dans l'apprentissage d'une langue étrangère... Dans un premier temps, nous ne saurons pas penser dans cette langue là mais on se contentera de traduire une mise en forme "en français"... Et avoir la frustration de ne pas trouver nos mots pour exprimer/partager ce qu'on ressent.
Cette frustration sera peut être le moteur pour qu'on s'améliore (où qu'on abandonne).
Mais pour avoir cette frustration, il faut quand avoir des choses à dire et savoir qu'on peut les dire.

En langage de programmation, c'est un peu pareil: si vous avez la patience d'apprendre effectivement à programmer dans un langage et qu'un jour vous devez en apprendre un autre, vous allez vouloir exprimer dans ce nouveau langage ce que vous pouviez faire dans le premier.

La différence est que les langages de programmations sont assez frustres pour que ce ne soit pas aussi compliqué que pour les langages humains. Mais partir de quelque chose qu'on maîtrise va nous permettre d'être exigeant lorsque nous allons devoir changer de langage. Ce qui est assez courant dans la vie d'un programmeur.

Je fais partie d'une génération qui a appris à programmer en Pascal (alors que dans les universités américaines, on formait plutôt avec des dialectes LISP).
Quand on s'est retrouvé à bosser sur des projets, on codait alors en assembleur et en C. Au début, on traduisait ce qu'on pensait correctement en LISP ou en Pascal en C ou en assembleur... mais cette frustration n'a duré que quelques jours/semaines.

- W

L'image est intéressante cependant, je ne vois pas la chose sous le même angle.
Pour un langage de programmation, il faut connaître environ 150 mots et quelques règles de syntaxe.
Par contre pour parler ou lire une langue étrangère sans être un expert, il faut connaître au moins 3000 mots, sans compter les synonymes, les homonymes, les règles de grammaire, la conjugaison. Ce n'est pas du tout le même temps d'apprentissage, la même difficulté et le même effort à fournir.
C'est du même ordre que de dire c'est aussi difficile de monter la tour Eiffel à pied que de monter sur le perron de l'Elysée. La méthode est la même et pourtant le temps, la difficulté et l'effort ne sont pas les mêmes et la réussite est différente.
La frustration n'est pas d'apprendre 150 mots dans un langage même si on est novice mais plutôt de ne pas savoir comment les agencer pour faire une tache bien définie et oui on revient à algorithme. Ainsi, un peu de souplesse dans les langages imposés par ces BO ne doit pas déranger.

[Madmac]

Non, non, c'est clairement la version 3. C'est dit dans le message #1 et ça se confirme ici :

J'en faisais la remarque parce qu'au niveau des librairies, c'est assez bordéliques. Certaines sont disponibles en 2 et pas en 3. Et visé-versa. Et en plus, il y a des profs d'université qui vont devoir se mettre à jour.

Les calculatrices programmables sont des atouts pour l'apprentissage de la programmation et de l'algorithmique. Plusieurs calculatrices compatibles Python existent aujourd'hui:

• Numworks: https://www.numworks.com/fr/
• Casio FX90+E à flasher: https://www.casio-education.fr/artic...20GRAPH%2090+E
• TI83 Premium CE dès 2019: https://education.ti.com/fr/products...-83-premium-ce

Imposer Python comme langage dans le programme du lycée forcera les fabricants à migrer vers un langage commun.

Le langage le plus logique pour une calculatrice reste le LISP. Attend-toi à la payer plus chère cette calculatrice avec python.

Ça, ça m'interpelle par contre... d'un coté, on a une volonté de typer (depuis Python 3.6, c'est possible) et de l'autre une volonté de ne pas typer... faudra que je potasse

Réponse courte: Non !

Non avons ce débat au sujet du noyau de Ruby. Et nous somme arrivé à une solution qui permet de s'en passer: Des fonctions de validations pour tester les primitives. Et c'est quelque chose qui est redondant si le langage possède Regexp. En plus dans un langage pure-objet, les classes sont un substituts pour les types. Et pour un langage comme le C++, les déclarations de types pour les variables sont redondantes, des fonctions avec des paramètres typées sont suffisant.

À moins d'être un programmeur bouillon, il n'y que les entrées qui méritent une vérification. Comme j'ai l'habitude de dire: Si on a des pommes à l'entrée, les chances d'avoir du jus de tomates à la sortie sont nul.

Pour apprendre la programmation, le Pascal et le Lisp était la meilleure école.

[Bktero]

J'en faisais la remarque parce qu'au niveau des librairies, c'est assez bordéliques. Certaines sont disponibles en 2 et pas en 3. Et visé-versa. Et en plus, il y a des profs d'université qui vont devoir se mettre à jour

Ca commence franchement à se normaliser
Voir par exemple : http://py3readiness.org/
Ou même l'ancien Wall of Shame qui était majoritairement rouge quand j'ai commencé Python en 2012 : https://python3wos.appspot.com/

C'est quand même incroyable de voir à quel point le terme "inférence de type" a été détourné. A l'origine, il s'agissait d'une vraie fonctionnalité consistant à calculer l'ensemble maximal des types d'une expression ou d'un programme, dans un langage à typage polymorphe (https://en.wikipedia.org/wiki/Hindle...er_type_system). Aujourd'hui, on utilise ce terme à tord et à travers dès qu'un langage propose un sucre syntaxique pour déduire bêtement un type à partir d'une valeur de retour. Le C++ a au moins l'honnêteté de parler de déduction de type et non d'inférence (https://isocpp.org/wiki/faq/cpp11-language#auto).

En même temps quand tu lis Wikipédia :

Type inference refers to the automatic detection of the data type of an expression in a programming language.

Il faut peut-être admettre que cet terme évolue avec le temps

[Pyramidev]

Et pour un langage comme le C++, les déclarations de types pour les variables sont redondantes, des fonctions avec des paramètres typées sont suffisant.

Faux. Exemple :

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
// Déclarations :
int foo();
ClasseDerivee& bar();
 
// Utilisation :
void baz() {
    auto          var1 = foo(); // var1 est de type int.
    const auto    var2 = foo(); // var2 est de type const int. On a besoin d'écrire const.
    auto&         var3 = bar(); // var3 est de type ClasseDerivee&.
    ClasseDeBase& var4 = bar(); // var4 est de type ClasseDeBase&. On a besoin d'écrire le type tout entier.
    ...
}

[Invité]

En même temps quand tu lis Wikipédia :

Type inference refers to the automatic detection of the data type of an expression in a programming language.

Il faut peut-être admettre que cet terme évolue avec le temps

En même temps, quand tu lis 2 phrases plus loin :

The majority of them use a simple form of type inference, while especially those ones who use the Hindley-Milner type system provide a more complete type inference

Il faut peut-être admettre que ce terme évolue avec le marketing à 2 balles

[pboulanger]

Entièrement d'accord avec toi!

Python est voulu pour les programmes du lycée et est déjà présent, avec scilab et SQL, au programme des classes préparatoires (où il remplace Pascal).
Python est simple à apprendre avec une syntaxe plus facile et plus proche des écritures mathématiques que les autres langages, permettant ainsi aux étudiants de se concentrer sur la logique algorithmique plutôt que sur la syntaxe. Le C est un langage complexe et vu les erreurs dans les codes que l'on trouve sur les pointeurs en entreprise, je ne suis pas sûr que ce soit une bonne idée de l'enseigner à des gens qui n'ont pas vocation à devenir informaticien. Sinon, mieux vaut enseigner ADA qui est bien plus exigeant que C...

Aujourd'hui 2 calculatrices proposent la programmation python et une troisième arrivera sur le marché en 2019. Lors des épreuves (BAC, ou concours) les élèves pourront ainsi tester les algorithmes demandés avant de les écrire sur leur copie. Casio avait bien essayé une calculatrice programmable en C mais ça n'avait pas eu de gros succès...

[alex_ps]

Python est simple à apprendre avec une syntaxe plus facile et plus proche des écritures mathématiques que les autres langages, permettant ainsi aux étudiants de se concentrer sur la logique algorithmique plutôt que sur la syntaxe.

Bah, je vais chipoter là...
Lorsque je passe la casquette "technique", même si je fais des "ponts" avec les maths, j'essaie aussi de m'en éloigner pour justement me concentrer sur les aspects pratiques étudiés.
De fait à expliquer le in de "for i in range(start,stop)", j'aurai préféré la syntaxe "classique" d'un bon vieux basic (ou la version algorithme)

[tgen1]

Bonjour Marco
Quand je parle d'algorithme, je ne dit pas qu'il faut faire que du papier.
En effet, il est indispensable que les élèves programment dans un langage. Python n'est pas un problème il est bien comme les autres langages. Le problème est qu'en 1ère NSI, on fera des projets dont la VR avec nos htc vive et malheureusement Unity ne fonctionne pas en python et on aura d'autres matériels qui ne fonctionneront pas en python. Ainsi imposer un langage, si on fait que des maths je dis oui, mais ce n'est pas le cas, il y a le côté technologique. Donc il faut soit élargir le nombre de langages imposés pour ne pas défavoriser les élèves à l'examen ou bien être moins pointilleux sur le langage de programmation qui n'est pas fondamental.

Sinon pour les calculatrices, ils n'auront pas cet environnement dans l'industrie, donc je trouve ça absurde.

[marco056]

Je n'ai pas tout compris (VR, htc) mais Python fonctionne sur tous les OS et est gratuit.
Par ailleurs, toujours avec mes étudiants, on était à un moment donné sur Scilab et Python. Sans un nombre d'heures important en informatique, c'est impossible à gérer. Même pour le prof, difficile de ne pas tout mélanger (à l'époque, j'avais Maple en plus dans la tête).
A mon avis, c'est mieux de se concentrer sur un seul langage, quitte à traduire ensuite si besoin. Comme tu le disais, c'est la base algorithmique qui est importante et on l'acquiert avec Python.
Sinon, je pense que tous les types de matériel peuvent à mon avis fonctionner avec Python (sous Linux, non) : je ne vois pas de contre-indication. Au pire, on exporte en csv et on traite ensuite avec python.

[Madmac]

Faux. Exemple :

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
// Déclarations :
int foo();
ClasseDerivee& bar();
 
// Utilisation :
void baz() {
    auto          var1 = foo(); // var1 est de type int.
    const auto    var2 = foo(); // var2 est de type const int. On a besoin d'écrire const.
    auto&         var3 = bar(); // var3 est de type ClasseDerivee&.
    ClasseDeBase& var4 = bar(); // var4 est de type ClasseDeBase&. On a besoin d'écrire le type tout entier.
    ...
}

Bien tu es arrivé avec le pire contre-argument possible. Les valeurs de tes variables sont systématiquement du même type que la valeurs de retour de la fonction. Donc la déclaration est totalement inutile puisque tu n'as qu'à identifier ce que donne ces fonctions. Et dans tous les cas, tu obtiens un pointeur sur une adresse mémoire.

C'est assez culotté de dire que c'est impossible, quand les programmeurs de LISP, Prolog, Scheme arrivent à le faire depuis au moins depuis 4 décennies.

[Pyramidev]

• Dans mon exemple en C++, var1 et var2 ne sont pas de même type. int, ce n'est pas le même type que const int. int permet d'utiliser des opérations qui modifient la variable, contrairement à const int.
• Dans mon exemple en C++, var3 et var4 ne sont pas de même type. ClasseDerivee&, ce n'est pas le même type que ClasseDeBase&. ClasseDeBase& n'offre que les opérations de la classe de base, pas celles qui sont spécifiques à la classe dérivée.
• Je répondais à la phrase « Et pour un langage comme le C++, les déclarations de types pour les variables sont redondantes, des fonctions avec des paramètres typées sont suffisant. » Du coup, ma réponse se centrait donc sur le C++. Sinon, pour rester dans le sujet du fil, j'aurais répondu par un code en Python :
  

  Code python :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  def foo() -> MutableMapping[str, int]:
      ...
   
  def bar() -> ClasseDerivee:
      ...
   
  def baz() -> None:
      var1                    = foo() # Pour mypy, var1 est de type MutableMapping[str, int].
      var2: Mapping[str, int] = foo() # Pour mypy, var2 est de type Mapping[str, int].
      var3                    = bar() # Pour mypy, var3 est de type ClasseDerivee.
      var4: ClasseDeBase      = bar() # Pour mypy, var4 est de type ClasseDeBase.
      ...

• Prolog et la plupart des dialectes du Lisp, dont Scheme, sont dynamiquement typés, donc je ne vois pas le rapport avec mon message.

[tgen1]

Je n'ai pas tout compris (VR, htc) mais Python fonctionne sur tous les OS et est gratuit.
Par ailleurs, toujours avec mes étudiants, on était à un moment donné sur Scilab et Python. Sans un nombre d'heures important en informatique, c'est impossible à gérer. Même pour le prof, difficile de ne pas tout mélanger (à l'époque, j'avais Maple en plus dans la tête).
A mon avis, c'est mieux de se concentrer sur un seul langage, quitte à traduire ensuite si besoin. Comme tu le disais, c'est la base algorithmique qui est importante et on l'acquiert avec Python.
Sinon, je pense que tous les types de matériel peuvent à mon avis fonctionner avec Python (sous Linux, non) : je ne vois pas de contre-indication. Au pire, on exporte en csv et on traite ensuite avec python.

Effectivement Python fonctionne sur tous les OS, ce n'est pas un problème pour moi, mais en NSI, il n'y a pas que des maths. Là, c'est pour la partie projet du BO qui propose de faire de la réalité virtuelle (VR, htc), piloter un robot, réaliser des applications connectées ou autres. Nous et plusieurs lycées avons déjà le matériel qui est assez onéreux par contre il ne fonctionne pas sous Python. A ma connaissance, il n'est pas prévu que Unity fonctionne sous Python. Donc pour ne pas pénaliser les élèves au bac, principe d'égalité, un assouplissement au niveau du langage imposé est indispensable ou bien imposer plusieurs langages, ce qui est déjà fait en STI2D, et qui ne pose pas de problème.