Discussion :

[f-leb]

quels sont les critères de sélection ou qualification des personnes qui conçoivent les programmes scolaires publiés au B.O. vu que c'est lui qui mène malgré tout la danse quand bien même une marge de manœuvre est laissée à l'enseignant ?

https://www.education.gouv.fr/recher...des-programmes

[Access_to_folder]

Merci pour ce document confirmant qu'il y a bien une réunion débat amenant à rédaction.

[Access_to_folder]

Est-ce que la possession par l'élève, de collège, de lycée, d'un micro-ordinateur à son domicile est devenue une fourniture scolaire obligatoire ?

[marco056]

Est-ce que la possession par l'élève, de collège, de lycée, d'un micro-ordinateur à son domicile est devenue une fourniture scolaire obligatoire ?

Non, et même dans les collèges (pas à la maison), ils disparaissent au profit de la tablette. Et on n'est pas le premier avril.

[popo]

Le contexte est l'apprentissage des bases de la programmation.

Remarque non justifiée, vu que je avais déjà mentionné que le contexte était l'apprentissage de la programmation.

Vous êtes déjà dans la finalité du choix d'un langage alors que vous ne savez même pas encore programmer.
L'algorithmique est à l'informatique, ce que sont les gammes à la musique. Et donc, on ne commence pas par apprendre un langage, quel qu'il soit. On commence par le b-a-ba.

C'est en forgeant qu'on devient forgeron.

J'ai été des deux côté : élève et également enseignant.
Et je sais d'expérience que faire de l'algo sur un papier pendant des heures, ce n'est pas très motivant.
Lorsque j'enseigne, je fais de la théorie avec de l'algo sur papier pour ensuite le mettre en pratique avec un langage simple.
C'est également comme cela qu'on me l'a enseigné.

D'ailleurs, vos propos ne tiennent pas.
Car pour faire des gammes, on utilise l'instrument.
C'est d'ailleurs ce que j'ai illustré avec la phrase que j'ai écrit et que vous avez détourné.
"Lorsqu'on apprend le piano, on commence par faire des gammes avant de s'attaquer à Bach ou même JJG."

Je dirais même que n'importe quel langage fait le job, sauf que la question n'est pas là. Quand on commence à conduire, voire même à passer son permis de conduire, on ne va pas vous mettre entre des mains inexpérimentés une formule 1. On commence par une voiture citadine !

Cela n'est pas différent de ce que j'ai écrit.
"Lorsqu'on apprend à lire, on commence par Oui Oui, pas par Balzac et encore moins par Shakespeare.
Lorsqu'on apprend le piano, on commence par faire des gammes avant de s'attaquer à Bach ou même JJG.
Lorsqu'on apprend les rudiment de la programmation, on choisi un langage réputé pour être plus simple à appréhender."

Mais c'est une erreur de penser, selon moi de penser que n'importe quel langage convient.
Lorsqu'on débute, il faut un langage où on n'a pas a se soucier, DANS UN PREMIER TEMPS, de la gestion des pointeurs et de la mémoire, donc pas de C, par exemple, car il peut décourager.

Le problème est que nous n'avons plus de simples langages comme le BASIC à notre disposition pour apprendre la programmation. On entre dans un langage qui est déjà de haut niveau et toutes les fonctions possibles sont à notre disposition. Je me demande même si l'on étudie encore les tris ou comment gérer de la mémoire quand on en a très peu à notre disposition pour faire tourner un programme.

Ce n'est pas parce qu'un langage dispose nativement de fonctions de tri, qu'on ne peux pas demander à un élève d'en écrire une avec des instructions plus basiques.

[Artemus24]

C'est en forgeant qu'on devient forgeron.

Je suis d'accord mais il faut d'une part avoir les bons instruments et d'autre part posséder la technique.
Et cela s'apprend avant de commencer à forger ! Je ne suis pas partisan de l'auto apprentissage.
Le but de l'apprentissage est justement d'être guidé par quelqu'un de plus expérimenté que vous, et qui vous montre comment bien faire.

Et je sais d'expérience que faire de l'algo sur un papier pendant des heures, ce n'est pas très motivant.

Oui, mais il faut bien commencer par quelque chose, non ?
Introduire les notions de l'algorithmique, donner des exemples, expliquer ce qu'il ne faut surtout pas faire ...
C'est contraignant pour bien apprendre les bonnes techniques et c'est justement à cause de ces techniques mal comprises que l'on a créé des cercles de qualités pour valider le développement en entreprise.

Lorsque j'enseigne, je fais de la théorie avec de l'algo sur papier pour ensuite le mettre en pratique avec un langage simple.
C'est également comme cela qu'on me l'a enseigné.

On passe de la théorie à la pratique et je ne dis surtout pas le contraire. Mais je tiens à souligner qu'apprendre à conduire, cela se fait sur une petite voiture citadine et non sur une formule 1. Il faut y aller progressivement, étape par étape.

D'ailleurs, vos propos ne tiennent pas. Car pour faire des gammes, on utilise l'instrument.

Mais avant d'utiliser l'instrument, vous devez commencer par apprendre le solfège, histoire de déchiffrer par la suite les partitions musicale. J'ai appris le solfège en commençant par une flute. Je tiens à souligner qu'il faut y aller progressivement.

C'est d'ailleurs ce que j'ai illustré avec la phrase que j'ai écrit et que vous avez détourné.
"Lorsqu'on apprend le piano, on commence par faire des gammes avant de s'attaquer à Bach ou même JJG."

C'est cela que vous ne comprenez pas. Quelqu'un qui n'y connait rien ne va pas débuter l'apprentissage de la musique en faisant ces gammes sur un Stradivarius, et s'attaquer à la cinquième symphonie de Beethoven.

Il faut commencer par le b-a-ba, genre "au clair de la lune" ou je ne sais quoi d'autre. C'est de cette base dont je vous parle, et encore dont mon cas, j'ai commencé par faire des organigrammes, donc avec un crayon, du papier et une règle spéciale que notre professeur à l'IUT nous avait demandé de nous procurer. Je reconnais que c'était contraignant de passer son temps à dessiner ces organigrammes, mais c'état formateur ! Je rappelle aussi qu'à mon époque, la saisie ce faisait sur des perforatrices de cartes, et non avec un clavier d'ordinateur comme maintenant. L'algorithmique est venu plus tard, en école d'ingénieur.

Vous trouvez tous que l'apprentissage de l'algorithmique est rébarbatif et inutile car vous croyez tous savoir programmer, ce qui n'est pas le cas. J'ai déjà vu de ces âneries dans la programmation, soi-disant par des ingénieurs expérimentés de plusieurs années, qui ne connaissent même pas quelques techniques de base.

Mais c'est une erreur de penser, selon moi de penser que n'importe quel langage convient.
Lorsqu'on débute, il faut un langage où on n'a pas a se soucier, DANS UN PREMIER TEMPS, de la gestion des pointeurs et de la mémoire, donc pas de C, par exemple, car il peut décourager.

Je suis d'accord avec vous. Je recommande le pascal qui est très bien.

A l'IUT, mon premier langage fut le basic Applesoft (sur des ITT2020), qui est très rudimentaire, mais largement suffisant pour mettre en pratique les notions algorithmiques apprises en cours.

Ce n'est pas parce qu'un langage dispose nativement de fonctions de tri, qu'on ne peux pas demander à un élève d'en écrire une avec des instructions plus basiques.

Mais qui enseigne encore les tris, la gestion de la mémoire, ou ce que sont des ruptures de séquences en programmation ?

[marco056]

En prépa, les tris sont au programme.

[f-leb]

Est-ce que la possession par l'élève, de collège, de lycée, d'un micro-ordinateur à son domicile est devenue une fourniture scolaire obligatoire ?

Non, et même dans les collèges (pas à la maison), ils disparaissent au profit de la tablette. Et on n'est pas le premier avril.

Il y a le dispositif Mon ordi au lycée, et ce n'est pas un poisson d'avril

La Région Pays de la Loire offre un ordinateur portable à tous les lycéens entrant en classe de Seconde et élèves de première année de CAP dans les établissements publics comme privés.

Cela s'organise au niveau de la région, et il y a des dispositifs similaires dans d'autres régions (toutes les régions ? Je ne sais pas...)

[f-leb]

En prépa, les tris sont au programme.

En 1ère générale avec la spécialité NSI (Numérique&Sciences Informatiques), les tris par sélection et par insertion sont au programme.

[Artemus24]

En 1ère générale avec la spécialité NSI (Numérique & Sciences Informatiques), les tris par sélection et par insertion sont au programme.

Et le reste ?
--> Les piles et les files.
--> Les listes chaînées.
--> L'organisation des données (SAM, ISAM, DAM, VSAM, BDAM, QSAM) pour les fichiers.
--> Celles pour les bases de données.
--> les arbres et les graphes.
--> les algorithmes de recherches dichotomique, arborescente ...
--> la récursivité
--> gestion de la mémoire (algorithme glouton).

Et je dois oublier plein de chose.

[f-leb]

Et le reste ?
--> Les piles et les files.
--> Les listes chaînées.
--> L'organisation des données (SAM, ISAM, DAM, VSAM, BDAM, QSAM) pour les fichiers.
--> Celles pour les bases de données.
--> les arbres et les graphes.
--> les algorithmes de recherches dichotomique, arborescente ...
--> la récursivité
--> gestion de la mémoire (algorithme glouton).

Et je dois oublier plein de chose.

Oui, on retrouve beaucoup de ces chapitres en NSI, surtout en Terminale, voir Programmes et ressources en numérique et sciences informatiques

[popo]

Je suis d'accord mais il faut d'une part avoir les bons instruments et d'autre part posséder la technique.
Et cela s'apprend avant de commencer à forger ! Je ne suis pas partisan de l'auto apprentissage.
Le but de l'apprentissage est justement d'être guidé par quelqu'un de plus expérimenté que vous, et qui vous montre comment bien faire.

J'ai clairement écrit que "Lorsque j'enseigne, je fais de la théorie avec de l'algo sur papier pour ensuite le mettre en pratique avec un langage simple."
Ce n'est pas de l'auto apprentissage, mais bien un guide.
J'explique comment bien faire sur papier avant de passer à la pratique.

Oui, mais il faut bien commencer par quelque chose, non ?
Introduire les notions de l'algorithmique, donner des exemples, expliquer ce qu'il ne faut surtout pas faire ...
C'est contraignant pour bien apprendre les bonnes techniques et c'est justement à cause de ces techniques mal comprises que l'on a créé des cercles de qualités pour valider le développement en entreprise.

Idem.
J'ai clairement écrit que "Lorsque j'enseigne, je fais de la théorie avec de l'algo sur papier pour ensuite le mettre en pratique avec un langage simple."
C'est fou comme vous prenez une phrase pour la sortir de son contexte et lui donner un autre sens.

Et même le plus doué des programmeurs, qui connait les bonnes technique, et qui est rigoureux n'est pas à l'abri d'erreurs.
C'est pour cela qu'on crée des processus pour valider le développement.

On passe de la théorie à la pratique et je ne dis surtout pas le contraire. Mais je tiens à souligner qu'apprendre à conduire, cela se fait sur une petite voiture citadine et non sur une formule 1. Il faut y aller progressivement, étape par étape.

.
Et c'est pourquoi j'ai écrit que python était adapté à cette mise en pratique.
une commande python peut être facilement testée seule dans IDLE.
IDLE est la petite voiture citadine.

Mais avant d'utiliser l'instrument, vous devez commencer par apprendre le solfège, histoire de déchiffrer par la suite les partitions musicale. J'ai appris le solfège en commençant par une flute. Je tiens à souligner qu'il faut y aller progressivement.

Vous vous contredisez vous même.
La flûte avec laquelle vous avez appris le solfège est un instrument.
Et IDLE est un outil qui permet de tester simplement des routines simples avant de les intégrer dans du code plus complexe.
C'est l'outil idéal pour y aller progressivement.

C'est cela que vous ne comprenez pas. Quelqu'un qui n'y connait rien ne va pas débuter l'apprentissage de la musique en faisant ces gammes sur un Stradivarius, et s'attaquer à la cinquième symphonie de Beethoven.

Même réponse.
IDLE ce n'est pas un Stradivarius et je n'ai jamais dis qu'il fallait directement s'attaquer directement à Beethoven (ou à Bach, en l'occurrence), c'est tout le contraire .
Là, ce n'est même plus du contresens c'est carrément de la mauvaise foi.

Il faut commencer par le b-a-ba, genre "au clair de la lune" ou je ne sais quoi d'autre. C'est de cette base dont je vous parle, et encore dont mon cas, j'ai commencé par faire des organigrammes, donc avec un crayon, du papier et une règle spéciale que notre professeur à l'IUT nous avait demandé de nous procurer. Je reconnais que c'était contraignant de passer son temps à dessiner ces organigrammes, mais c'état formateur ! Je rappelle aussi qu'à mon époque, la saisie ce faisait sur des perforatrices de cartes, et non avec un clavier d'ordinateur comme maintenant. L'algorithmique est venu plus tard, en école d'ingénieur.

Je ne vois pas ce qu'il y a de compliqué à comprendre que faire un petit script avec IDLE, c'est l'équivalent de jouer "au clair de la lune" à la flûte.
Les organigrammes dont vous parlez s'appellent aujourd'hui des diagrammes et sont toujours enseignés.
Et l'informatique a évoluée depuis l'époque des cartes perforée !
Aujourd'hui, on ne demande pas à un étudiant d'aller percer des trous dans un bout de carton pour la donner à une machine qui prend la moitié de la pièce et qui a besoin de plusieurs minutes pour donner un résultat.

Vous trouvez tous que l'apprentissage de l'algorithmique est rébarbatif et inutile car vous croyez tous savoir programmer, ce qui n'est pas le cas. J'ai déjà vu de ces âneries dans la programmation, soi-disant par des ingénieurs expérimentés de plusieurs années, qui ne connaissent même pas quelques techniques de base.

Ne peut être plus aveugle, celui qui ne veut pas voir.
Je n'a jamais dit que l'algo était inutile.
Ce que j'ai dis, c'est qui fallait alterner entre l'algo sur papier et son expérimentation avec un langage sur un ordi.
Autrement, on prend le risque de décourager l'apprenant.

Aussi, de quel droit te permet tu de nous insulter ?
Ce n'est pas parce que tu as une mauvaise expérience avec un "soit disant ingénieur" que tu peux te permettre de tous nous mettre dans le même panier et affirmer qu'aucun de nous ne sais programmer.

Je suis d'accord avec vous. Je recommande le pascal qui est très bien.
A l'IUT, mon premier langage fut le basic Applesoft (sur des ITT2020), qui est très rudimentaire, mais largement suffisant pour mettre en pratique les notions algorithmiques apprises en cours.

Comme, je l'ai déjà dis :
"Mise à part quelques essais en VB sur mon vieil AMSTRAD avant de choisir ma voie, j'ai également commencé avec Turbo Pascal.
J'ai adoré développer avec Turbo Pascal.
Mais il a été prévu pour fonctionner sur un système DOS !!!

Aujourd'hui, il y a son héritier : Delphi (ou encore Lazarus).
Mais il vient avec un IDE lourd et complexe.
Python est léger et n'a pas besoin d'une usine à gaz."

Oui, Pascal est très bien.
Mais, Python est une alternative encore plus simple pour débuter.

Mais qui enseigne encore les tris, la gestion de la mémoire, ou ce que sont des ruptures de séquences en programmation ?

D'autres ont déjà répondu à cette question.

[fred1599]

Ce n'est pas parce que tu as une mauvaise expérience avec un "soit disant ingénieur" que tu peux te permettre de tous nous mettre dans le même panier et affirmer qu'aucun de nous ne sais programmer.

Le débat sur le sujet du "niveau" n'est pas objectif... mais un conflit profond sur la définition même de la compétence en informatique. Il s'agit d'un conflit de valeurs.

La Valeur "Ancienne" (c. 1990) : La Maîtrise Verticale. Le bon développeur est celui qui connaît toute la pile technique, de l'Assembleur au C. La valeur cardinale est l'Efficacité. Dans cette philosophie, "ne pas réinventer la roue" est une forme de paresse intellectuelle.

La Valeur "Moderne" (c. 2024) : La Maîtrise Horizontale. Le bon développeur est celui qui connaît l'écosystème, qui sait quelle API, quel framework ou quelle bibliothèque utiliser pour résoudre un problème rapidement. La valeur cardinale est la Productivité (vitesse de mise sur le marché). Dans cette philosophie, "ne pas réinventer la roue" est le principe même de l'ingénierie moderne.

Les nouveaux venus maîtrisent objectivement moins les couches basses. Mais cette critique est devenue économiquement non pertinente dans un marché qui valorise et rémunère massivement l'abstraction.

Concernant le niveau, a-t-il baissé ? Non, il s'est déplacé et stratifié.

La compétence informatique a quitté la maîtrise de la rareté de la machine (gestion manuelle de la mémoire, optimisation en Assembleur) pour aller vers la maîtrise de la complexité de l'abstraction. Gérer un projet moderne avec des microservices, des conteneurs et des bases de données multiples est cognitivement tout aussi exigeant, sinon plus, que d'optimiser une boucle en C.

La plainte de "l'ancien" est souvent une erreur de catégorie. Il compare sa compétence senior – une compétence acquise sur 30 ans, faite de "recul" et d'expériences multiples – à la compétence junior d'un nouvel arrivant. Or, un junior, par définition, ne peut pas avoir ce recul, quel que soit son potentiel.

Le véritable risque de "baisse de niveau" ne vient pas des frameworks, mais des LLM. En générant "l'illusion de maîtrise" , ils permettent à un développeur de devenir ce "relieur de composants" à un niveau d'abstraction jamais vu, sans comprendre ni les composants, ni la manière de les relier.

Cette dernière évolution crée un paradoxe pédagogique final. Les outils (LLM) rendent la production de code triviale, mais la validation de ce code exige une compréhension des fondamentaux (algorithmique, architecture, sécurité) plus profonde que jamais. La "baisse de niveau" que les anciens craignaient de voir arriver avec les bibliothèques pourrait devenir une réalité tangible si l'enseignement ne parvient pas à former des esprits capables de penser de manière critique l'outil , et pas seulement de l'utiliser.

[Artemus24]

J'explique comment bien faire sur papier avant de passer à la pratique.

En fait, vous n'expliquez rien, vous donnez votre opinion comme si elle était la seule valable.

C'est fou comme vous prenez une phrase pour la sortir de son contexte et lui donner un autre sens.

Je lui donne le sens que je comprends. Est-ce que vous vous prenez pour le centre du monde ? D'autre que vous ont aussi une expérience professionnel en informatique.

C'est pour cela qu'on crée des processus pour valider le développement.

Le processus de validation d'un développement n'est pas fait pour corriger des erreurs de programmation mais pour vérifier que la solution proposée répond réellement au besoin identifié et qu’elle fonctionne conformément aux critères de qualité définis par l'entreprise. C'est parler un langage que tout utilisateur dans l'entreprise est censé comprendre et suivre à la lettre.

Aussi, de quel droit te permet tu de nous insulter ?

Ou voyez vous que je vous insulte ? J'ai surtout compris par votre remarque que j'ai touché une corde sensible.

Ce n'est pas parce que tu as une mauvaise expérience avec un "soit disant ingénieur" que tu peux te permettre de tous nous mettre dans le même panier et affirmer qu'aucun de nous ne sais programmer.

Désolé de vous contredire mais j'ai suffisamment d'expérience en bancaire et en assurance pour savoir de quoi je parle. Le niveau des développeurs dans ces deux branches est moyen, voire médiocre et en plus, cela ne les intéresse pas de rester dans ce genre de poste. D'où une sous-traitance qui bâcle les développements en explosant les durées de livraisons et qui ne répondent pas à la demande du cahier des charges. D'où une perte de temps pour signaler les erreurs et de recommencer tout le circuit de validation. C'est la triste réalité du niveau des développeurs et du peu d'intérêt que ceux-ci portent à leur compétence.

@ Fred1599 : merci car ton analyse est très pertinente.

Je tiens à souligner qu'à mon époque, le développeur avait la double compétence, celle de son métier en tant qu'informaticien, mais celle aussi de son client (bancaire, assurance) pour pouvoir comprendre les demandes faites. sans cela, il n'était pas possible de travailler chez le client en tant que prestataire de service.

On demandait en premier lieu de répondre au respect du cahier des charges (la fonctionnelle) en suivant scrupuleusement tout le processus de validation de l'application, mais aussi de le faire dans les temps imparties qui pouvaient être assez court, en lisibilités des sources, en ergonomies et en performance. Nous étions plus rigoureux jadis que maintenant.

[popo]

En fait, vous n'expliquez rien, vous donnez votre opinion comme si elle était la seule valable.

Encore une fois, vous sortez la phrase de son contexte pour lui donner un autre sens.
Cette phrase était liée aux deux phrases qui la précédaient.
Cette phrase avait simplement pour but de montrer la manière dont j'enseigne à des débutant.
Je n'ai jamais affirmé que c'était la seule manière valable.
Ce que j'ai affirmé, c'est que j'avais constaté que ceux à qui j'ai enseigné avait moins tendance à se décourage en alternant algo papier et pratique sur ordi, plutôt de que passer des semaines à se taper des algo avant de voir concrètement ce que a donne. Mais puisque vous semblez lire uniquement ce qui vous arrange, c'est peine perdue d'argumenter.

Je lui donne le sens que je comprends. Est-ce que vous vous prenez pour le centre du monde ? D'autre que vous ont aussi une expérience professionnel en informatique.

Vous m'avez reproché de ne pas donner de l'importance aux notions d'algo alors que ma phrase indiquait clairement que l'alternais entre algo et pratique.
Donc, ne vous en déplaise mais vous avez clairement donné un autre sens à ma phrase.
Et comme vous ne voulez pas l'admettre, vous me reprocher maintenant d'être narcissique.
Moi je vous reproche d'être de mauvaise foi.

Message du 12/11/2025 :

c'est justement à cause de ces techniques mal comprises que l'on a créé des cercles de qualités pour valider le développement en entreprise

Message du 13/11/2025

Le processus de validation d'un développement n'est pas fait pour corriger des erreurs de programmation

Vos deux affirmations sont en totale contradiction.

Ou voyez vous que je vous insulte ? J'ai surtout compris par votre remarque que j'ai touché une corde sensible.

Vous avez clairement affirmé, je cite, que nos croyons "tous savoir programmer, ce qui n'est pas le cas".
Désolé de vous décevoir mais non, ça ne m'atteints pas plus que ça.
C'est la raison pour laquelle j'ai utilisé le "nous" car le "tous" que vous avez utilisé implique pas mal de monde, pas seulement moi.
Mais comme apparemment je suis le centre du monde, j'ai dû traduire "tous" en "moi".

Désolé de vous contredire mais j'ai suffisamment d'expérience en bancaire et en assurance pour savoir de quoi je parle. Le niveau des développeurs dans ces deux branches est moyen, voire médiocre et en plus, cela ne les intéresse pas de rester dans ce genre de poste. D'où une sous-traitance qui bâcle les développements en explosant les durées de livraisons et qui ne répondent pas à la demande du cahier des charges. D'où une perte de temps pour signaler les erreurs et de recommencer tout le circuit de validation. C'est la triste réalité du niveau des développeurs et du peu d'intérêt que ceux-ci portent à leur compétence.

Je vous trouve bien présomptueux d'affirmer que tous les dev de votre secteurs sont médiocres et que vous êtes au dessus du lot.
Pour reprendre vos propre mots : d'autres que vous ont des compétences en informatiques (y compris dans le bancaire et l'assurance).
Et votre remarque, à elle seule, montre que votre égo démesuré ne vous permet pas de vous apercevoir que vous insultez tout vos collègues.

Nous étions plus rigoureux jadis que maintenant.

Là aussi, c'est sympa pour vos collègues plus jeunes.
Il n'y a aucune raison qu'il se sentent offensés.

[fred1599]

Je tiens à souligner qu'à mon époque, le développeur avait la double compétence, celle de son métier en tant qu'informaticien, mais celle aussi de son client (bancaire, assurance) pour pouvoir comprendre les demandes faites. sans cela, il n'était pas possible de travailler chez le client en tant que prestataire de service.

On demandait en premier lieu de répondre au respect du cahier des charges (la fonctionnelle) en suivant scrupuleusement tout le processus de validation de l'application, mais aussi de le faire dans les temps imparties qui pouvaient être assez court, en lisibilités des sources, en ergonomies et en performance. Nous étions plus rigoureux jadis que maintenant.

Votre témoignage est, à mon sens, l'incarnation parfaite du "conflit de valeurs" et du "déplacement" des compétences décrits plus haut dans ma précédente réponse...

Votre premier point sur la "double compétence" (informatique + métier du client) est fondamental. Il ajoute une dimension qui n'est que brièvement effleurée dans l'analyse de la "maîtrise verticale" (technique) et "horizontale" (écosystème).

Vous décrivez une époque où le développeur, en tant que prestataire, devait être un traducteur, un véritable analyste fonctionnel. Cette double compétence était une nécessité absolue pour "comprendre les demandes" et respecter le cahier des charges.

Ceci renforce l'idée d'un changement de paradigme. Aujourd'hui, dans de nombreuses structures (notamment agiles), cette "maîtrise fonctionnelle" est souvent déléguée à des rôles très spécialisés (Product Owner, Business Analyst, Scrum Master). Le développeur "moderne" est alors parfois critiqué, comme vous le faites implicitement, parce qu'il se concentre sur la solution technique (le framework ) sans toujours posséder cette maîtrise métier (bancaire, assurance) que vous jugiez essentielle.

Votre second point sur la "rigueur" (respect des temps, performance, lisibilité, ergonomie) est au cœur même de la "fracture générationnelle". *

La critique que vous formulez – "Nous étions plus rigoureux jadis que maintenant" – est l'écho direct des critiques formulées par d'autres développeurs "à l'ancienne". Ils reprochent aux approches modernes, basées sur "une multitude de bibliothèques externes" , d'aboutir à des applications "complexes", "peu performantes" et "difficiles à maintenir".

Aujourd'hui, le marché valorise avant tout la productivité (la vitesse de mise sur le marché). L'industrie a privilégié des outils (langages de haut niveau comme Python, frameworks comme Symfony ou React) qui favorisent cette productivité , parfois au détriment de la performance pure ou de la rigueur de validation que vous décrivez.

Votre sentiment d'une perte de rigueur est donc logiquement et historiquement fondé : vous ne parlez tout simplement plus du même métier.

[Artemus24]

@ Popo : de toute évidence, je ne suis pas de la même génération que vous, et je ne possède pas du tout la même expérience professionnel que vous. En tant que professeur, vous avez du mal à vous mettre à la place des autres, à admettre qu'il y a une autre façon d'exercer un métier qui a changé en cinquante ans. Cela fait longtemps maintenant que je suis à la retraite et je ne me sens pas pour autant perdu.

Donc, ne vous en déplaise mais vous avez clairement donné un autre sens à ma phrase.

Encore une fois, je donne le sens de ce que je comprends. Et je comprends que vous ramenez tout à vous.

Vos deux affirmations sont en totale contradiction.

Vous ne savez pas ce qu'est un cercle de qualité et encore moins le processus de validation en entreprise et de sa mise en production. Cela va devenir compliquer de bien se faire comprendre.

Vous devriez descendre de votre piédestal et arrêter de croire que le monde tourne autour de vous.

@ Fred1599 : je crois surtout que l'expérience de Popo est bien différente de la mienne. Donc oui, il y a bien une incompréhension générationnel sur le métier de l'informatique.

Vous décrivez une époque où le développeur, en tant que prestataire, devait être un traducteur, un véritable analyste fonctionnel. Cette double compétence était une nécessité absolue pour "comprendre les demandes" et respecter le cahier des charges.

Si en tant que prestataire, on vous parle de crédit, de bilan ou de prévision, calcul de taux, voire même de fiscalité, d'instruments financiers et que vous ne savez pas de quoi il est question, je peux vous assurer que le client ne va pas perdre son temps à vous former. Le prestataire est là pour répondre à un besoin qui manque justement chez le client, sinon pourquoi aurait-il besoin de faire appel à un intervenant extérieur ?

Ceci renforce l'idée d'un changement de paradigme. Aujourd'hui, dans de nombreuses structures (notamment agiles), cette "maîtrise fonctionnelle" est souvent déléguée à des rôles très spécialisés (Product Owner, Business Analyst, Scrum Master). Le développeur "moderne" est alors parfois critiqué, comme vous le faites implicitement, parce qu'il se concentre sur la solution technique (le framework ) sans toujours posséder cette maîtrise métier (bancaire, assurance) que vous jugiez essentielle.

L'analyste-programmeur dans les années 1970-1980 était celui qui faisait l'analyse et aussi la programmation. La méthode que j'ai apprise à l'école était la méthode Warnier. La méthode Merise n'existait pas encore et est apparu après 1990.

Aujourd'hui, comme tout est devenu compliqué, on a scindé en différents métiers dit spécialisés, pour répondre à la demande du client. Les termes anglais que vous citez, je ne les ai jamais entendu quand j'exerçais, c'est-à-dire jusqu'en 2000.

Votre second point sur la "rigueur" (respect des temps, performance, lisibilité, ergonomie) est au cœur même de la "fracture générationnelle".

J'ai souvenir de programmes qui mettaient des heures à s'exécuter par méconnaissance de ce qu'est une recherche dichotomique en mémoire alors que le programmeur faisait un accès fichier, dans la boucle la plus interne, pour récupérer le résultat d'une recherche. C'est la réalité sur laquelle j'ai été confrontée. L'optimisation étaient au cœur de nos traitements. Ce n'était pas du snobisme de procéder ainsi, mais je rappelle que les PDP-11 dans les années 1970 possédaient à peine 64kb. Mais qui s'en soucis aujourd'hui ?

La critique que vous formulez – "Nous étions plus rigoureux jadis que maintenant" – est l'écho direct des critiques formulées par d'autres développeurs "à l'ancienne". Ils reprochent aux approches modernes, basées sur "une multitude de bibliothèques externes" , d'aboutir à des applications "complexes", "peu performantes" et "difficiles à maintenir".

Vous me confirmez que je suis bien un développeur à l'ancienne. Cela me rassure.
Je me demande ce que ferait un développeur moderne sur un PDP-11 ou un solar-1640 ou encore un iris-80.

Aujourd'hui, le marché valorise avant tout la productivité (la vitesse de mise sur le marché). L'industrie a privilégié des outils (langages de haut niveau comme Python, frameworks comme Symfony ou React) qui favorisent cette productivité , parfois au détriment de la performance pure ou de la rigueur de validation que vous décrivez.

Dans le domaine bancaire, il y a des programmes écrits en assembleur et en cobol datant des années 1960. Et ceux-ci continuent de répondre aux besoin des métiers de la banque. Le gros problème est que plus personne ne sait ce qu'ils font car il n'existe plus la compétence pour les maintenir. Aujourd'hui, on fait de la programmation jetable et c'est bien triste.

Votre sentiment d'une perte de rigueur est donc logiquement et historiquement fondé : vous ne parlez tout simplement plus du même métier.

C'est tout à fait vrai, ce n'est plus le même métier. Mais ce changement est dû à des impératifs financiers et de temps. Et je n'aborde pas le problème de l'IA dans les futurs années.

Je me sens plus en conformité avec vos propos, Fred1599, qu'avec Popo.

P.S.: si les échanges sont du gabarie de Popo, je risque de ne pas continuer les échanges dans ce sujet.

[marco056]

J'avoue ne plus trop comprendre le sens de ce fil, un peu à l'image de la société ou chacun ramène tout à soi (moi, y compris) et cherche à mettre l'autre en difficulté, en discutant, souvent de façon biaisée, les différents arguments.
Pour information, le programme d'informatique en cpge scientifique (tronc commun, car il y a des compléments, pour certaines filières : https://sti.eduscol.education.fr/sit...tique-xxsi.pdf
Je confirme mon avis que Python est bien adapté à l'enseignement : facile à installer, multi-plateforme, convivial, évolutif et utilisé dans l'industrie.
Pour ces raisons, je ne vois aucun autre langage qui permettrait d'attirer davantage nos jeunes dans cette voie, même si j'ai assez peu de connaissances en informatique.
Je crois que je n'interviendrai plus sur ce fil qui me paraît un brin toxique.

[fred1599]

Je me sens plus en conformité avec vos propos, Fred1599, qu'avec Popo.

Je pense que je vous rejoins tous les deux, enfin je pensais avoir été suffisamment clair dans mes précédentes interventions.

Prenez vos compétences de vos premières années, pensez-vous que vous trouverez facilement du travail dans ce métier ? Je peux vous affirmer que non !

Quand j'ai été embauché, on m'a bien fait comprendre qu'être pointilleux et rigoureux dans les extrêmes ralentissaient la productivité. Je peux vous dire que mes revues de code ne sont plus celles d'il y a dix ans, et c'est un bien, car il y avait trop d'abus.

Il faut vivre avec son temps, se sont les entreprises qui imposent le type de développement souhaité, et les développeurs s'adaptent à leurs besoins...

Si en tant que prestataire, on vous parle de crédit, de bilan ou de prévision, calcul de taux, voire même de fiscalité, d'instruments financiers et que vous ne savez pas de quoi il est question, je peux vous assurer que le client ne va pas perdre son temps à vous former.

Oui mais le client ne vous demandera plus tout cela, relisez mon précédent post, se sont les "product owner, les scrum master, ..." qui vont contrôler que les objectifs sont atteints sur la partie métier.
Par contre il vous demandera de développer plus vite, et maintenir l'application afin d'éviter le plus possible les retours des adhérents.

J'ai souvenir de programmes qui mettaient des heures à s'exécuter par méconnaissance de ce qu'est une recherche dichotomique en mémoire alors que le programmeur faisait un accès fichier, dans la boucle la plus interne, pour récupérer le résultat d'une recherche. C'est la réalité sur laquelle j'ai été confrontée. L'optimisation étaient au cœur de nos traitements. Ce n'était pas du snobisme de procéder ainsi, mais je rappelle que les PDP-11 dans les années 1970 possédaient à peine 64kb. Mais qui s'en soucis aujourd'hui ?

Regardez le matériel à notre disposition (cloud, augmentation de la RAM, CPU, SSD, ...), a-t-on selon vous besoin "d'optimiser" ?

Vous me confirmez que je suis bien un développeur à l'ancienne. Cela me rassure.
Je me demande ce que ferait un développeur moderne sur un PDP-11 ou un solar-1640 ou encore un iris-80.

Là même chose que vous... c'est cela que vous ne comprenez pas ! Le niveau n'a pas baissé, pour les développeurs d'avant (avant les LLM) et normalement si un bon enseignement, ne devrait pas non plus changé pendant. Actuellement les LLM rendent meilleurs encore les développeurs expérimentés comme moi, car on développe vite, on lit vite et on teste vite, tout ce dont à besoin une entreprise pour avoir une productivité optimale. Le danger, c'est quand on disparaîtra (retraite), est-ce que l'enseignement se sera adapté suffisamment rapidement pour utiliser le LLM comme un outil et pas comme un développeur qui travaille à sa place.

À l'heure actuelle, je peux vous dire qu'un développeur comme moi qui n'était pas né en 1970 et qui connaît pas le MACRO-11 pourrait écrire directement sur le port série du terminal (TTY) en quelques minutes. Et je n'ai pas réellement besoin d'en savoir des masses sur cet ordinateur.

L'enseignement doit s'adapter et préparer nos jeunes à évoluer avec les LLM et ne surtout pas en être esclaves. Le bon sens du jeune développeur doit prédominer sur la confiance aveugle du LLM.

[popo]

@Artemus24
C'est justement parce que je mets à la place de l'apprenant que j'alterne entre algo et pratique.
Parce que l'expérience m'a montré qu'il est plus facile de comprendre un concept quand on travaille sur du concret.
Avant de critiquer, commencez par vous mettre dans la peau d'un enseignant.

Vous me reprochez de me prendre pour le centre du monde, de tout ramener à moi..
Mais vous n'arrêtez pas de répéter 'A mon époque, on faisait comme ci ou comme ça" ou encore "moi je suis dans le bancaire alors que je sais mieux que vous de quoi je parle".
Bref, vous parlez de votre expérience personnelle, je parle aussi de mon expérience personnelle.
Avant de critiquer, analyser votre propre comportement car vous faites bien pire.
Je n'ai aucune leçon à recevoir d'un type avec melon tel qu'il ne s'aperçoit pas de la médisance des propos qu'il tient sur ces propres collègues.

Le plus fou, c'est que cette médisance et votre égo vous empêchent de vous rendre compte qu'on est d'accord sur l'importance des algos et sur la rigueur.
Votre expérience et la mienne ne sont pas si différentes que ça.
J'ai appris le développement et également le métier de la compta.

La différence c'est qu'au lieu de rester bloqué dans les années 70, je me suis adapté.
Et puisque que mon métier c'est l'informatique et non la compta et que la compta évolue aussi, j'ai préféré suivre les évolutions de l'informatique au détriment de celles de la compta.
Au lieu de penser que mes collègues sont médiocres et ne connaissent par leur métiers comme tu le fait, j'ai appris à ne pas me reposer uniquement sur mes connaissances vieillissantes en compta mais sur l'expérience du Product Owner.


A tous les autres.
Je tiens à m'excuser après de tout ceux qui lisent ce fil et qui le voit pollué par un débat puéril.
Face à tant de médisance, je n'ai pas réussi à contenir mon émotion.


Pour en revenir au sujet initial.
Python, comme beaucoup de langages modernes, masque la complexité de certains concepts (concepts que l'on aborde lorsqu'on fait des algorithmes) en proposant des outils prêts à l'emploi qu'il fallait autrefois coder à la main.
Mais rien n'empêche à un enseignant d'aborder ces concepts,
Certains ont apporté la preuve qu'on les abordent toujours.
Et si python propose des mécaniques de tri ou des outils pour construire des arbres simplement, il n'interdit pas de les refaire soi même en appliquant les algorithmes appris en cours.

Et puisque python bénéficie d'une large communauté, qu'on l'utilise dans beaucoup de domaines, qu'il est intégré dans nos calculettes scientifique et même dans Excel (faudra que je retrouve l'article qui en parle), etc., cela fait pas mal de raisons pour s'en servir comme support dans la formation d'un développeur.