Bonjour,

je trouve ton propos très intéressant, tu donnes ton avis en le justifiant, en l'expliquant, bravo !

Par contre, sans vouloir aller contre ce que tu as dis, je voulais tout de même donner aussi mon point de vue qui n'est pas le même.

Pour le choix du logiciel d'apprentissage de l'algorithmie, je précise tout d'abord que je n'en ai pas utilisé, mais j'ai quand même quelques avis.
Pour Scratch, je trouve que l'interface est trop enfantine, sans doute peu efficace si l'algo devient important.
Mais d'un autre côté, certains profs de primaire utilisent Scratch avec des élèves ! Et de plus, les algos sur lesquels les élèves de lycée ne sont jamais très gros ... donc pourquoi pas !
C'est à cause de ce côté trop enfantin que je privilégierait plutôt Algobox, plus proche d'un vrai langage.

Ensuite, passons aux langages de programmation.
J'ai d'ailleurs déjà abordé ce point dans le forum, et je m'étais dis que tant qu'à faire, pourquoi ne pas directement utiliser un langage de programmation !

Ah oui, je voulais aussi dire que tu sembles un élève plutôt intéressé par ce domaine, et que tu regrettes qu'on n'utilise pas des choses plus évoluées.
Mais attention, n'oublie pas que pour un élève comme toi, on en a 20 qui ne sont pas forcément doués, et pour qui le langage algorithmique ou un langage de programmation est du chinois, que c'est rébarbatif et inutile !

Je me pose souvent la question : pourquoi tant de langages de programmation ?
Beaucoup se ressemblent énormément, et même si certains ont des avantages et des inconvénients, j'ai quand même la sérieuse impression qu'il y en a trop !
Lequel serait idéal pour commencer ? Je ne sais pas, je n'ai pas la réponse, et je ne pense pas qu'elle existe.
Aujourd'hui, je connais plusieurs langages de programmation, et si demain je devais en apprendre un nouveau, cela ne serait pas difficile du tout.

En conclusion, ce que je voulais dire, c'est que préférer telle approche ou telle autre, c'est surtout une affaire de gout. Un langage va plaire et correspondre à une personne, mais pas à une autre.

Bonjour,

Je partage totalement l'avis de jamo. Je suis sûr qu'il y a moins de 1% d'élèves qui s'intéressent à l'algorithmique et à la programmation.
Pour l'élève lambda de seconde, il faut commencer par des choses ultra simples, mais indispensables :
1) l'affectation (je ne partage pas ton point de vue concernant l'utilisation du signe égal pour l'affectation, mais je n'aime pas non plus la lourdeur d'algobox ...)
2) les structures conditionnelles (Si ... alors ... finsi et si ... alors ... sinon...finsi). Dans un premier temps on peut éviter les structures conditionnelles plus complexes.
3) les itérations (tant que...fin tant que ; répéter ... jusqu'à et pour...

Ensuite il faut donner des algorithmes tout faits et demander aux élèves de les décortiquer (en les faisant tourner à la main)

Ensuite, il faut leur donner des algorithmes à trous qu'ils doivent compléter

Ensuite il faut leur donner des algorithmes entiers à faire.

Parallèlement, il faut évidemment programmer ces algorithmes systématiquement dans un langage quelconque (ce n'est pas le plus important). Au début le professeur rédige entièrement le programme, puis peu à peu, les élèves deviennent de plus en plus autonomes. Le plus difficile n'étant pas de programmer mais de construire l'algorithme.

Voila, si on s'en tient aux programmes des classes de lycée, à quoi se limite l'apprentissage de l'algorithmique.

Maintenant, à partir de la rentrée prochaine, les élèves motivés de terminale S vont pouvoir faire de la vraie programmation en choisissant la spécialité ISN : informatique et sciences du numérique. L'objectif est d'aller beaucoup plus loin puisque le programme comporte 4 parties :

1) représentation de l'information (représentation binaire, opérations booléennes, numérisation, formats, compression ...)
2) algorithmique (au-delà du programme de math : tri, chemins de parcours d'un graphe, récursivité ...)
3) langages et programmation : programmation classique (le choix du langage est laissé libre mais beaucoup d'enseignants vont choisir Python ou Java) et programmation web (HTML, php, css )
4) architectures matérielles (éléments d'architecture, jeux d'instructions, transmission point à point, adressage sur un réseau,routage, programmation d'un mini robot...)

Le programme ne mentionne pas la notion d'objets, mais je ne vois pas comment on pourrait s'en passer ...

Au départ, cette nouvelle matière (car ce n'est pas de mathématique dont il s'agit) devait commencer dès la seoncde, mais pour des raisons budgétaires sans doute, elle n'est introduite qu'en terminale (et encore pas dans tous les lycées) : c'est mieux que rien !

Tu es plein de certitudes (normal quand on est jeune) et ton jugement devrait être plus nuancé, mais bravo pour ton enthousiasme !

salut

j'adhère aux propos

Jamo,

tête à fou d'accord avec J-P ....

c'est aussi ce que j'attendais, entre les progrès technologique et l'amélioration/simplification/une meilleure ergonomie j'attendais autre chose que ces machines débiles que nous avons maintenant et qui nous abrutissent .... ainsi que tous ces langages pour attirer la clientele

Bonjour,

C'est marrant que tu cites Prologin, je connais le président de l'année 2011-2012 (puisqu'il collait dans ma classe, et il faisait... souvent de l'info).

J'ai eu l'occasion de voir un peu comment était Algobox. Et, comment dire... C'est vraiment décevant de voir qu'on enseigne l'algorithmique de cette façon. Je ne sais pas comment dire, ce n'est absolument pas naturel... Je comprends très bien qu'on n'enseigne pas de langage en tronc commun (en ISN, c'est différent). Les premiers programmes que j'ai fait sont des programmes type factorielle, puissance... En pseudo-code. C'est pas difficile de dérouler un tant_que ou un pour, et j'ai l'impression que c'est bien plus naturel. Quant au Python, je ne sais pas, je ne connais que très peu ce langage.

Bref, vive le pseudo-code pour débuter !

bonsoir,

je suis depuis 2 ans la formation pour enseigner en l'option ISN, cette formation étant assurée par des profs d'info à la fac. Ben la réponse est claire : pour eux l'algo, c'est papier/crayon.

En pratique, avec mes élèves de seconde, j'utilise AlgoBox qui est certes très lourd, mais qui a l'avantage de cette lourdeur : par exemple, si on loupe l'initialisation, ça plante (à condition de choisir une variable qui doit être initialisée à autre chose que 0). Et puis le déroulement "pas à pas" avec le contenu des variables qu'on voit au fur et à mesure, ça parle à la grande majorité qui panique encore plus au mot "algorithme" qu'au mot "factorisation".
Sinon, je suis passée par LARP aussi (découvert grâce à jamo, merci encore !), visuel, qui passe bien, mais que je trouve (un peu) plus délicat à manipuler pour les élèves.

Je trouve les commentaires d'Algue-rythme très frais.

La transcription en langage de programmation, et ses tests, ne devrait
être que l'ultime étape du processus.. histoire de valider pour le plaisir
l'analyse qui a été faite préalablement.

L'algo c'est papier crayon ! en effet.
Et c'est comme ça qu'on l'enseignait déjà il y a 40 ans.
L'algo, c'est : analyse du problème, organigramme (organisation du traitement et/ou
organisation des données), et éventuellement pseudo code. Et normalement tout
est dit.

Je ne comprends d'ailleurs pas la difficulté que cela représente.

Un algo ce n'est jamais :
- qu'une déclaration/initialisation de variables;
- du traitement comme on sait le faire en maths;
- et une procédure, structurée de préférence, dans laquelle on retrouve
2 instructions essentielles (et seulement 2) le IF et le WHILE.

Enseignons le IF, enseignons le WHILE, apprenons à faire une représentation graphique
des traitements sous forme d'organigramme, et on aura appris aux
élèves de lycée à faire de l'algorithmie.

tcpc :: j'approuve les propos de pgeod :: nous sommes au lycée et on s'adresse à des jeunes qui débutent et non pas à bac + vingt-douze ....

pgeod a juste oublié la boucle inconditionnelle For à côté de la boucle conditionnelle While ....

ben pourquoi ?

Je dirais qu'il manque quand même les instructions d'entrée/sortie (lire/écrire), parce que le but ultime d'un algorithme c'est de traiter les données (qu'elles soient saisies au clavier ou sur un capteur quelconque) et d'afficher les résultats (à l'écran, sur l'imprimante ou via un haut-parleur ou ...)
Sinon, fondamentalement, je ne vois pas ce qu'il manque ...

@carpediem.
Une boucle FOR i de 1 à 10 ... NEXT .. sans FOR

i = 0
While (i < 11)
  {instructions}
  i = i + 1
End while

@tcpc ben oui pourquoi ?

Aussi complexe que soit ton algorithme, ce sont toujours une succession
de IF et de WHILE. Le reste c'est un problème d'optimisation.

dsl.  l'initilisation c'est i = 1

pgeod,

Oui, comme un roman de Sheakespeare n'est jamais qu'une succession de mots qu'on trouve dans le dictionnaire.
Mais de là à ce que n'importe quel quidam puisse écrire ce type de roman ... avec cette qualité.

Certes, les algos du secondaires sont réduits à leur plus simple expression, mais essaie d'écrire un algorithme pour la "vraie vie", sans faille ou niche à cas particuliers, rapide et rigoureux dans un problème un poil complexe et tu verras que la difficulté n'est pas au degré où tu le penses.

Un des mots clé dans ce que j'ai écrit est "rapide"...

J'ai été confronté à des problèmes bien costauds à cause de cette rapidité parfois indispensable pour la réalisation de l'algo.

Algo parfois simple en apparence, où on pense s'en tirer avec quelques pages d'instructions basiques et quelques boucles imbriquées ... et tout est dans la poche.

Oui, sauf que le programme une fois compilé ...et enfin lancé, il met 0,2 seconde à s'exécuter (sur processeur performant). Le hic est que cet algo est sensé controler un processus dont la durée peut être 10 fois plus courte que le temps de déroulement de l'algo...

Et alors, c'est parti, il ne reste plus qu'à trouver les astuces pour que cela puisse quand même foncionner... et c'est là qu'on commence à transpirer.

Certes, en secondaire, il n'est pas question de se préoccuper de ce genre de détail et de plein d'autres non effleurés ici. Mais l'algothmie c'est vraiment autre chose que d'aligner 3 boucles que ce soit un for, un while ou autre case of ou ...

Remarque, que la vitesse d'exécution d'un algo étant parfois (souvent ?) une exigence du cahier des charges imposée par des contraintes souvent incontournablas, a terrassé plus qu'un analyste ...

@J-P Tout ceci est juste... mais à réserver pour les "pros" ou les "fans".
La question de départ est tout de même : Enseignement de l'algorithmique au lycée.

Et c'est justement parce que j'ai un peu de recul sur l'algorithmie dans la "vraie vie",
que je dis qu'il ne convient pas, pour l'apprentissage de la matière au lycée,
faire état de tous ces problèmes d'optimisation, ni de tous ces problèmes de
langage et de syntaxe, alors que les élèves sont déjà perturbés quand il leur
faut trouver 10 lignes d'un enchainement logique de programme.

Et si tu as également un peu de recul dans la "vraie vie" sur l'algorithmie,
je pense que tu dois pouvoir en convenir, compte tenu des difficultés que
réprésente, apparemment  au vue des topic ouverts sur la sujet sur l'île,
la compréhension de la matière en secondaire.

A quoi bon parler de relativité à un élève, s'il ne sait déjà pas ce qu'est
une vitesse.

pgeod : certe oui ... on peut toujours remplacer un for par un while ....

mais bon comme on l'a dit et que tu répètes dans ton dernier msg on s'adresse à des élèves "qui découvrent" et la structure itéraive sans conditionnement (qui est un des objectifs du programme du lycée) peut être présentée aux élèves ...

quelle que soient toutes considérations d'optimisation ou de performance ou de cahier des charges qui s'adressent aux professionnels ....

ainsi si f est une fonction et que l'on définit une suite par u_n+1 = f(u_n) et la donnée du premier terme

et que je demande à mes élèves d'écrire un algorithme qui me donne le k-ième terme de la suite après avoir entrer le terme initial et k je me moque de savoir si l'élève utilise un for, un while ou même une fonction récursive l'important c'est qu'il sache modéliser le processus avec un algo qui tourne ...

@carpediem

Je suis d'accord.
Un algo qui tourne.. c'est déjà une première grande étape et une grande satisfaction,
pour le prof comme pour l'élève, dans l'apprentissage du savoir.

C'est comme résoudre un problème de maths, trouver UNE solution c'est déjà
très satisfaisant, même si on n'a pas trouvé LA solution la plus élégante.

@pgeod :

Regardes ces problèmes pour t'en convaincre :

http://www.france-ioi.org/algo/chapter.php?idChapter=58
http://www.france-ioi.org/algo/chapter.php?idChapter=96

En principe ça peut se faire avec Algobox (quelques tarés sur Prologin se sont amusés à coder un DFS [http://en.wikipedia.org/wiki/Depth-first_search si tu ne connais pas] avec, ça doit donc être possible... ).

Les algorithmes requis pour résoudre ces problème dépassent très largement le stade du secondaire, c'est certain, mais ils sont considérés comme des algorithmes "classiques" que tout les spécialistes du domaine sont censés connaître (ça serait aussi aberrant qu'un prof de math qui ne connait pas le théorème de Pythagore).

Car, et c'est là l'un des défis majeur de l'algorithmique, il ne s'agit pas seulement de trouver un algo qui donne la réponse au problème, mais un algo qui la donne rapidement (comme souligné par J.P).

>> Sinon, fondamentalement, je ne vois pas ce qu'il manque ..

Les tableaux. Sans tableau la quasi-totalité des problèmes te sont inaccessibles. Sauf si tu considères ça comme une variable évidemment...

Mais quoi qu'il en soi l'algorithmique ne se limite pas à ça. C'est un domaine vaste et complexe en perpétuelle évolution (reconnaissance vocale, cryptographie, simulations diverses) qui atteint parfois des niveaux de complexité si élevé qu'il faut considérer des méthodologie pour décrire un algorithme, des façons de procéder, car le considérer comme un enchaînement de IF et de WHILE ne suffit plus (algorithmes génétiques, algorithmes gloutons, programmation dynamique, récursivité, etc... ).

Voici 2 fonctions en C++ qui calculent le n-ième nombre de la suite de fibbonacci :

// Fonction renvoyant un entier positif et prenant en paramètre un entier positif
unsigned int fibo(unsigned int n)
{
     if (n <= 2)
          return 1; // Renvoie 1 si n inférieur ou égal à 2
     else
          return fibo(n-1) + fibo(n-2); // Sinon renvoie la somme des deux nombres précédents de la suite
}

La complexité de cette fonction est énorme : elle vaut grosso-modo le nombre d'or élevé à la puissance N. Autrement dit elle croit exponentiellement en temps. Avec ça tu es très vite bloqué en terme de temps d'exécution.

Voici maintenant une version de cette fonction en complexité linéaire :

// Fonction renvoyant un entier positif et prenant en paramètre un entier positif
unsigned int fibo(unsigned int n)
{
     // 3 entiers positifs initialisés (n3 est le résultat)

     unsigned int n1 = 0;
     unsigned int n2 = 1;
     unsigned int n3 = 0;

    for (unsigned int i=1; i<=n; ++i) // Pour i de 1 à n avec un pas de 1 en 1
    {
        // On calcule le résultat...
        n3 = n1 + n2;

        // ... et on décale les positions dans la suite !
        n1 = n2;
        n2 = n3;
    }

    return n3; // On renvoie le résultat !
}

Deux fonctions calculant le même résultat (une exception pour n = 0 cependant), mais la seconde plus rapide que la première.

Et ce n'est qu'un exemple classique !

Au faite, tu remarqueras que la première fonction ne fait pas emploi du WHILE, mais utilise la récursivité... aussi certains algorithmes qui peuvent paraître complexes peuvent se passer de son utilisation !

D'ailleurs, certains langage (comme Haskell et la plupart des langage fonctionnels pur), ne connaissent ni la boucle while ni la boucle for ! A la place ils utilisent la récursivité !

encore une fois on sort du cadre de ce topic qui est l'initiation à l'algo ....

@Algue-rythme

Et tout ça pour dire quoi ? Que tu t'intéresses au sujet ?
Ca on l'avait compris dès ton premier post.

Que tu connais la récursivité et des algorithmes pour résoudre
des problème qui dépassent très largement le stade du secondaire.
C'est bien.

Que l'un des défis majeur de l'algorithmique, n'est pas seulement de
trouver un algo qui donne la réponse au problème...
Peur-être.. suivant les domaines.

Mais ça ne répond pas à la question : Par quoi on commence pour
enseigner l'algorithmique et avec quels outils ? C'est ça la question.

Bonjour,

Je me suis inscrit sur ce forum uniquement pour répondre à ce topic, car j'ai été surpris par une partie des choses qui s'y disent.

Pour moi l'intérêt de l'enseignement de l'informatique au lycée est de donner aux élèves des notions de programmation. Pas seulement de l'algorithmique comme sous-domaine spécialisé, mais du fait d'écrire un programme pour faire quelque chose de précis et qui marche bien.

Par ailleurs, il me semble que ce qui distingue fondamentalement la programmation et les mathématiques (telles qu'elles sont pratiquées aujourd'hui), c'est la possibilité d'un retour direct provenant d'un ordinateur. Un programme on l'écrit, on le teste, on sait dans la minute s'il est complètement faux ou pas (par contre on ne sait pas s'il est complètement juste). C'est une grande force qu'il me semblerait aberrant de ne pas utiliser pendant son apprentissage : je suis choqué qu'on puisse dire à de futurs enseignants que l'algorithme "c'est papier/crayon". Présenter le sujet ainsi est certainement une bonne manière de faire paraître le sujet anecdotique, inutile et sans grand intérêt: si c'est pour tout faire dans la tête, autant faire de belles mathématiques.

Je n'aime pas le concept de pseudo-code car il va dans la direction du "papier/crayon" justement. Un programme en pseudo-code qu'on ne peut pas tester n'a pas grand intérêt. Et si on se met à définir précisément un pseudo-code pour pouvoir l'implémenter, ce n'est plus un pseudo-code mais un langage de programmation (mais fabriqué de façon ad-hoc par une personne qui n'est pas spécialiste du sujet et donc sans doute de qualité discutable). Quitte à enseigner et utiliser un langage de programmation, autant en prendre un qui existe déjà, dont les défauts et les qualités sont bien connus et compris, et qui permettra aux élèves intéressés de faire autre chose que ce qui est couvert par le programme s'ils en ont envie (de la programmation graphique, des programmes utilisant un générateur de nombres aléatoires, des entrées/sorties de fichier, ou n'importe quelle autre fonctionnalité que vous avez oublié d'inclure dans votre pseudo-pseudo-langage).

Utiliser un vrai langage (par exemple Python ou OCaml) ne veut pas dire qu'on se met tout de suite à coder avant de réfléchir. Il y a une place pour la conception de l'algorithme et sa description informelle, non complète mais permettant de se fixer les idées. Mais cela peut très bien se faire simplement en langue naturelle (dans un contexte de classe, parfois à l'oral), avec éventuellement une structure qui ressort dans la représentation textuelle. C'est ça le "pseudo-code", fait comme ça c'est naturel, et il n'y a pas besoin à mon avis de concentrer son enseignement dessus -- tout comme on n'enseigne pas la rigueur aux élèves en leur faisant uniquement étudier les plans de preuve informels que font les mathématiciens qui attaquent un théorème difficile.

Enfin, pour moi le vrai problème de l'enseignement de l'informatique en terminale ce n'est pas un problème d'outils. On n'a jamais trop su quel était le meilleur langage à utiliser pour débuter la programmation, plein de gens ont commencé avec un BASIC horrible, et au final tout le monde s'en sort plutôt bien, comme si l'outil n'était pas si déterminant. C'est un problème de compétences : on demande aux professeurs de mathématiques (ou SI, ou...) d'enseigner la programmation, quand ce n'est pas leur domaine de compétences. Excepté quelques bonnes surprises (il y a toujours des professeurs doués en programmation par ailleurs, mais malheureusement ilemaths n'est pas représentatif du corps enseignant), l'expérience pratique ne sera pas au rendez-vous, et l'enseignement sera sans doute décevant. Pour enseigner la programmation on a besoin de professeurs qui programment pour de vrai, et je ne vois pas comment l'éducation nationale peut en inventer en l'espace de quelques années. Ça pourrait se faire sur le long terme mais il faudrait regarder le problème en face au lieu de faire comme s'il n'existait pas -- et par ailleurs la création d'une agrégation d'informatique serait peut-être aussi une bonne idée dans cette optique.

pour faire de "la bonne programmation" il faudrait de "bons langages" ...

ce qu'il y avait dans les années 80 mais modernisé sans que cela ne devienne par trop complexe ni rigide mais pas ces pseudo-langages (style algobox où l'on remplit des cadres par des instructions ...médiocrité intellectuelle, reflet de la médiocrité de notre éducation....)

j'ai commencé par un basic "horrible", du moins sans souplesse, peu rapide, peu de mémoire ....
puis il y a eu ces horribles machines "qui font tout" (contre lesquelles je me bats) et pris par d'autres centres d'intéret je l'avoue j'ai laché prise

et maintenant il y a un saut ...
j'ai regardé Python qui me semble vraiment bien ... mais je l'avoue c'est dur de s'y remettre ....

il serait temps que nos inspecteurs prennent leur responsablité, ce qu'ils n'ont pas fait depuis des années :: je précise que dans mon livre de 1e donc il y a .... un certain temps se trouvaient des algoritmes ... cela n'a pas duré longtemps ...et ça date ...

maintenant il faut que nos élèves en bouffent à tous les cours alors qu'ils ne savent même plus lire ....

> Mais ça ne répond pas à la question : Par quoi on commence pour
enseigner l'algorithmique et avec quels outils ? C'est ça la question.

On commence avec un vrai langage, déjà. Si possible disposant d'un interpréteur toplevel car c'est bon pour la pédagogie et que les élèves peuvent suivrent en live ce que leur dit de faire le ou la prof, puis voir les résultats directement.

À bien-sûr, cela suppose d'utiliser un ordinateur*. Donc pour enseigner l'algorithmique, ça sera bien de la faire au CDI par exemple. N'oubliez pas que dans computer science il  y a computer, c'est pas pour rien et un papier/crayon ne servira à rien si non en complément d'une machine.

En plus, les élèves pourront essayer de faire des ptits trucs chez eux pour s'amuser, ils auront juste à se procurer l'implémentation du langage choisi.

* : sous GNU/Linux naturellement.

La question ne portait pas sur l'informatique à l'école mais sur l'introduction à l'algorithmie en Secondaire, c'est fondamentalement différent.

Le but est, je suppose, de développer l'esprit logique et de réflexion des élèves.

Pour cela l'algorithmie (à faible difficulté pour le Secondaire) peut être un bon outil.

Normalement, pour atteindre ce but, il n'y a pas vraiment besoin d'un ordi ou de l'apprentissage d'un langage informatique.

Il faut bien entendu comprendre l'esprit de quelques notions de base, comme des instructions conditionnelles (Si ... alors ... sinon) et les notions de boucles et quelques autres.

Papier, crayon, réflexion et ... flow-chart (comme on dit en anglais), qui est infiniment plus visuel que n'importe quel autre moyen.

Cela devrait suffire ...

Mais cela impliquerait, que le prof soit capable de comprendre la logique de chacun des élèves (et ce n'est pas forcément gagné pour certains) et cela implique aussi que les élèves arrivent à comprendre et à admettre que leur travail ne répond pas toujours au problème posé. (et cela c'est loin aussi d'être gagné).

Pour éviter ces problèmes, il faut alors traduire la réflexion (flow-chart) en un "langage" assimilable par un quelconque logiciel et le faire "tourner", on vérifie ainsi que le résultat est ou non celui attendu et coupe les ailes aux discussions prof-élèves sur la validité de la solution (bien que ...)

Cela ne répond pas à la question de savoir quel logiciel, ni quel support choisir ... d'autant plus qu'il en existe une inutile multitude, tous ayant leurs qualités et leur défauts.

> Normalement, pour atteindre ce but, il n'y a pas vraiment besoin d'un ordi ou de l'apprentissage d'un langage informatique.

Si clairement. Sauf si c'est uniquement de l'analyse des algorithmes mais à tous vous écoutez, ce n'est pas du niveau du secondaire donc on oublie.

> Il faut bien entendu comprendre l'esprit de quelques notions de base, comme des instructions conditionnelles (Si ... alors ... sinon) et les notions de boucles et quelques autres.

Non, on peut définir les algorithmes autrement. Certains langage n'ont même pas de structure de boucle ou de si..alors..sinon et il est pourtant possible d'implémenter un algorithme avec. Donc un algorithme ne s'exprime pas forcément avec ça. Par exemple en assembleur, je n'ai pas ces structures. Puis encore, un algorithme peut être décrit en terme de fonctions ou de machine abstraite. Rien à voir avec des boucles ou des structure conditionnelles classiques. Cette vision des algorithmes est trop restreinte.

Le problème qui vent de l'argument du prof qui doit comprendre la logique de l'élève n'est pas fondamentalement grave. Ils sont débutants et ils n'iront pas a priori vous sortir des bouts de codes super astucieux et idiomatique. Personne n'ira coder une fonction récursive, ou s'amuser à faire des fonctions d'ordre supérieur pour mapper ou zipper ou ces trucs là. À moins d'avoir un élève qui a déjà beaucoup d'expérience, on comprendra toujours la logique naïve supposée du débutant.


Moi je dis ça pour vous les profs. En septembre ça sera Python chez moi car je suis sûr qu'au moins les élèves ne trouveront pas ça barbant. Avec un truc comme AlgoBox, je suis sûr de perdre la grosse moitié au cours de l'année, quoi que je les connais pas encore.

pompompom,

Tu tégares et pas qu'un peu.

On parle bien d'une approche de l'algorithmie dans le secondaire et pas d'autre chose.

On n'essaie pas d'enseigner la rélavité générale en secondaire pour approcher les problèmes de la gravitation.

Papier - crayon - flow chart.
Tout le reste (au niveau Secondaire) ne devrait pas exister sauf pour les motifs que j'ai évoqués.

Mais libre à qui veut de penser autrement.

L'interactivité permise par l'utilisation d'un ordinateur est une chance extraordinaire. Ça rend la matière vivante et plus facile à enseigner -- tant que les élèves sont motivés. Pour moi c'est un atout principal à mettre en valeur dans l'enseignement, et pas le petit détail qui facilite les corrections comme tu sembles le penser. Utiliser "papier, crayon et flow-chart", c'est passer à côté de cet avantage.

L'informatique est un domaine rempli d'autodidactes. J'ai appris à programmer "tout seul" au lycée et je connais beaucoup de gens qui sont dans ce cas. À mon avis la raison pour laquelle ce phénomène est si répandu est justement cette interactivité qui facilite l'apprentissage, et la perspective de résultats concrets (un de mes premiers programmes a été un générateur de phrases aléatoires, pas très difficile à programmer et très amusant).

Par ailleurs j'ai aussi des doutes sur les flowchart comme outil ultime pour l'écriture de programmes. Ça marche très bien dans certains domaines (le traitement du signal (Max/MSP, PureData...) ou l'électronique de bas niveau), mais c'est nettement moins convaincant dans d'autres. Les langages à flowchart utilisent souvent des conventions graphiques (les ronds c'est pour ça, les carrés pour ça) qui ne sont au final ni plus simples ni plus faciles à retenir qu'une syntaxe textuelle équivalente. En tant qu'outil de brouillon pour décrire certaines idées pourquoi pas, mais si on veut en faire la syntaxe d'un langage implémenté ça me paraît entrer dans le cadre des outils fait maison qui ne sont au final pas terribles.

Utiliser "papier, crayon et flow-chart", c'est passer à côté de cet avantage.

C'est dans cette partie "papier, crayon et flow-chart", qu'on a besoin d'esprit logique et de réflexion.

> J'ai quelques bonnes bases sur l'écriture des programmes
> (entre autre dans le domaine de l'imagerie médicale où il
> vaut mieux ne pas se planter) ... et il ne m'est jamais
> venu à l'idée de mal travailler ... c'est à dire programmer
> sans d'abord analyser le problème par flow-charts...

Il y a une différence entre utiliser une représentation diagrammatique pour concevoir et réfléchir (pratique très répandue dans l'industrie : diagrammes de bases de données, diagrammes de hiérarchies de classes, ou même en entreprise les diagrammes de description de processus, etc.) et vouloir donner à cette représentation le niveau de détail nécessaire pour en faire un programme exécutable.

Des scientifiques russes sont allés au bout de cette démarche en concevant un langage à base de diagrammes prévus pour pouvoir représenter la structure de programmes écrits dans des langages existants (C, Oberon, Python...), chaque case pouvant contenir une quantité arbitraire de code dans le langage sous-jacent. Il s'agit de DRAKON qui t'intéressera peut-être : http://en.wikipedia.org/wiki/DRAKON

Je veux bien croire qu'on puisse utiliser des techniques de ce genre en milieu scolaire, mais il reste à prouver que ça marche mieux qu'utiliser le langage sous-jacent directement (quitte à utiliser des diagrammes dans la phase de conception de certains algorithmes). Je m'attends à ce qu'au final ça ne fasse pas de grande différences, mais il faudrait des études empirique sur le sujet pour avoir les idées claires.

Je plussoie à la proposition de J-P et je trouve la remarque de Tiwaz
sur l'algorithme d'Euclide et la recette de cuisine très à-propos.  

Je pense effectivement que l'enseignement de l'algorithmie en secondaire
doit se concentrer, en premier lieu, sur l'apprentissage des seuls outils logiques
en rapport avec les objectifs qui sont ceux du programme du lycée, permettant de
concevoir un processus de traitement des données.

Dire, comme le rapporte Mariette que les profs d'info à la fac considèrent que pour eux
"l'algo, c'est papier/crayon" est sans doute caricatural pour plus d'un des intervenants
précédents, mais cela fixe bien les idées.

ET ce n'est pas parce que certains passionnés sont passés directement au langage de
programmation avec succès que la démarche intellectuelle ou méthodologique est la meilleure.
Dans les écoles d'informatique justement, on insiste sur l'analyse et la modélisation
du problème sous forme logique, avant même de passer à écriture du programme en langage machine,
avant même d'évoquer les problèmes physiques ou matériels ou les problèmes d'optimisation.

Qu'on veuille ensuite, pour la beauté ou pour l'intérêt du sujet, transcrire cette modélisation
des traitements (et des données pour ceux qui font de l'informatique de gestion) en langage
informatique, n'est pas antinomique; c'est une prolongation du geste qui peut avoir
valeur pédagogique.

Mais il faut savoir reconnaître les priorités. Savoir modéliser, même sommairement,
même un problème simple, est un apprentissage qui peut être utile dans d'autres domaines
d'activité que l'informatique. L'algorithmie n'est pas un domaine réservé à l'informatique.



  

@gasche Oui, je suis certainement allé trop loin en conjecture, désolé. Je réagissait sur le terme "langage sous-jacent" et le fait de toujours détailler plus les algorithmes pour se rapprocher de l'implémentation réelle du programme. Alors effectivement j'en convient, dans le cadre du développement d'un logiciel il faut tenir compte des moyens à disposition lors de la conception pour pas se retrouver coincé ou avec des solutions peu adaptées aux outils employés. Mais au lycée pour des élèves qui pour la majorité n'auront aucune connaissance de la programmation, l'algorithmique doit dans un premier temps rester à un degré d'abstraction plus élevé et ne pas se soucier des spécificités techniques lié à tel ou tel langage de programmation.

Le problème dans ce raisonnement ("c'est plus facile de ne pas apprendre à programmer") est que je ne vois pas quel serait l'intérêt des élèves pour l'algorithmique. Après les langues mortes (qui ont auprès des élèves les succès que l'on sait), on invente les langages informatique morts, qui ne permettent pas de parler avec un ordinateur. Vous allez faire comment pour intéresser les gens ? Leur expliquer qu'Euclide, c'était un vrai dur, et il faisait avec calame/parchemin ? Leur vanter les mérites des recettes de cuisine (.. enseignées par un prof de maths) ? Leur expliquer que la capacité à "modéliser des problèmes" leur sauvera la vie plus tard ?

Je ne veux pas dire qu'il faut tomber dans l'excès inverse en appâtant les élèves avec des "vous saurez écrire des jeux vidéos". Mais faire tourner un petit programme qu'on a écrit c'est quand même quelque chose d'unique qui fait la différence entre une matière rébarbative enseignée par des incompétents et quelque chose de nouveau, créatif et intéressant. À mon avis cette différence remplace à elle seule tous les hypothétiques avantages pédagogiques du "pseudo-code", et je suis désolé de voir que vous n'êtes pas d'accord.

Je connais pas mal de gens qui ont fait de l'algorithmique au lycée, aucun qui se soit contenté du pseudo-code ou même qui ait mis l'accent sur cette aspect de son apprentissage. J'ai passé beaucoup de temps à aider des collégiens et lycéens à apprendre à programmer en autodidactes par forums web interposés, et je n'ai jamais eu l'impression qu'après "if" et "while" ils n'avaient plus d'espace de cerveau disponible. J'ai donné des notions de complexité algorithmique à une partie de ces gens-là, et il me paraît évident qu'ils n'y auraient pas attaché d'importance s'ils n'avaient pas, simultanément, l'expérience pratique de la programmation.

(Plus technique: je pense que l'argumentation sur "même en école d'ingénieur on insiste sur les prérequis et la modélisation du problème" fait une confusion entre la conception de systèmes logiciels complexes, qui demande effectivement des efforts de modélisation préalable, et l'écriture de petits programmes jouets pour se familiariser avec la programmation, où l'effort de modélisation est moindre et on peut souvent se passer d'une version écrite formalisée. Tout comme en histoire, en français ou en biologique, on apprend à faire des plans détaillés pour des dissertations, mais ça vient seulement après qu'on a appris à écrire des réponses d'un ou deux paragraphes à une question plus simple.)

gasche,

Le but, en Secondaire, n'est pas ou ne devrait pas être de "se familiariser avec la programmation, où l'effort de modélisation est moindre et on peut souvent se passer d'une version écrite formalisée." mais bien de développer l'esprit logique et de réflexion par l'analyse de problèmes simples (puisque en Secondaire).

Le but, à mon sens, dans le Secondaire est de tenter d'améliorer l'analyse et pas celle de parfaire la programmation.

On a trop tendance à confondre Analyse et Programmation (à cause du fait que certains sont analyste-programmeur), mais ce sont deux "métiers" bien différents.

Dans le Secondaire, sans prétention d'apprendre un "métier", loin s'en faut, c'est bien l'approche analyse qui devrait primer.

Malheureusement, pour les raisons évoquées dans mes messages précédent, il est bien difficile de ne faire que cette partie utile qu'est l'analyse et on est presque obligé de passer à l'écriture du programme pour le faire "tourner".

Ceci, ne concerne évidemment pas les études Secondaires dans des filières dédiées à l'informatique, cela c'est une autre histoire.

Je comprends J-P, mais regardons l'exemple suivant :

pseudo-code :

Tant que (x > y)
    Faire:
        x = x + 42
        Afficher x
    Fin
Fin

Python :

while x > y:
    x += 42
    print(x)

Mise à part une syntaxe différente, il n'y a pas de changement fondamental (ni avec un autre langage aussi classique) vous remarquerez.
Donc tant qu'à faire autant utiliser ce vrai langage qui existe et qui permettra aux élèves de s'amuser un peu avec durant leur temps libre si l'envie leur en prend. Pourquoi s'en priver puisqu'au final on atteindra le même but et sans que les élèves aient plus à apprendre ? (enfin on considère que les mots anglais "while" et "print" sont acquis en terminale, quand même).
C'est vraiment dommage !

Personnellement, si j'étais en terminale je n'irais certainement pas prendre cette spécialité informatique si je savais qu'on n'y faisait que écrire du faux code sur des feuilles, vraiment.

C'est aussi une question d'interactivité. J'aime savoir que les élèves apprécient mes cours, mais hélas en maths c'est pas le cas souvent. Je vois dans cet enseignement la possibilité d'enfin donner un cours pas comme les autres, un cours qui va enfin me permettre d'enseigner des choses que les élèves trouveront sympa,* grâce à l'utilisation d'un véritable langage qu'il pourront expérimenter à la maison.

Second avantage : je ne veux pas être harcelé par tout le monde pour savoir comment on écrit du pseudo code. Grâce à un vrai langage, je dis aux élèves de lire la doc et me voilà tranquille ! (je plaisante un peu bien-sûr).

je suis d'accord avec pour le "vrai langage" informatique plutôt que ces simulacres de langages...



et quelques mots d'anglais ne sont pas insurmontables et l'occasion de faire le lien avec les disciplines linguistiques ...

c'est de plus l'ocasion d'apprendre/travailler la méthode, la structure et l'ordre et l'organisation et l'occasion de voir qu'écrire proprement à un intéret en particulier lorsque le programme bugue....

Je vous propose de regarder  ce livre

http://macros.edebal.fr/

Il  apprend à programmer en utilisant le JavaScript
On utilise l'environnement de développent de Google dans le Cloud
Rien à installer il faut juste se créer un compte chez Google
Des tutoriaux nous prennent la main dés le début et les chapitres sont illustrés de nombreux exemples