Python au collège et au lycée : choix réfléchi ou effet de mode ?

Version imprimable

Voir 40 message(s) de cette discussion en une page

11/11/2025, 18h05
f-leb

1 pièce(s) jointe(s)

Citation:

Envoyé par Access_to_folder

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 ?

Pièce jointe 671668
https://www.education.gouv.fr/recher...des-programmes
12/11/2025, 06h40
Access_to_folder

Merci pour ce document confirmant qu'il y a bien une réunion débat amenant à rédaction.
12/11/2025, 08h06
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 ?
12/11/2025, 11h22
marco056

Citation:

Envoyé par 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 ?

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.
12/11/2025, 11h40
popo

Citation:

Envoyé par Artemus24

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.

Citation:

Envoyé par Artemus24

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."

Citation:

Envoyé par Artemus24

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.

Citation:

Envoyé par Artemus24

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.
12/11/2025, 17h45
Artemus24

Citation:

Envoyé par Popo

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.

Citation:

Envoyé par Popo

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.

Citation:

Envoyé par Popo

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.

Citation:

Envoyé par Popo

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.

Citation:

Envoyé par Popo

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.

Citation:

Envoyé par Popo

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.

Citation:

Envoyé par Popo

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 ?
12/11/2025, 17h55
marco056

En prépa, les tris sont au programme.
12/11/2025, 18h51
f-leb

Citation:

Envoyé par marco056

Citation:

Envoyé par 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 ?

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:aie:

Citation:

Envoyé par Mon ordi au lycée

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...)
12/11/2025, 18h54
f-leb

Citation:

Envoyé par marco056

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.
12/11/2025, 21h31
Artemus24

Citation:

Envoyé par F-leb

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.
12/11/2025, 21h40
f-leb

Citation:

Envoyé par Artemus24

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
13/11/2025, 11h09
popo

Citation:

Envoyé par Artemus24

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.

Citation:

Envoyé par Artemus24

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.

Citation:

Envoyé par Artemus24

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.

Citation:

Envoyé par Artemus24

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.

Citation:

Envoyé par Artemus24

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.

Citation:

Envoyé par Artemus24

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.

Citation:

Envoyé par Artemus24

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.

Citation:

Envoyé par Artemus24

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.

Citation:

Envoyé par Artemus24

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.
13/11/2025, 12h41
fred1599

Citation:

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.
13/11/2025, 17h44
Artemus24

Citation:

Envoyé par Popo

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.

Citation:

Envoyé par Popo

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.

Citation:

Envoyé par Popo

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.

Citation:

Envoyé par Popo

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.

Citation:

Envoyé par Popo

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.
13/11/2025, 19h53
popo

Citation:

Envoyé par Artemus24

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.

Citation:

Envoyé par Artemus24

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 :

Citation:

Envoyé par Artemus24

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

Citation:

Envoyé par Artemus24

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.

Citation:

Envoyé par Artemus24

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".

Citation:

Envoyé par Artemus24

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.

Citation:

Envoyé par Artemus24

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.
13/11/2025, 21h26
fred1599

Citation:

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.
14/11/2025, 00h32
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.

Citation:

Envoyé par popo

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.

Citation:

Envoyé par popo

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.

Citation:

Envoyé par Fred1599

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 ?

Citation:

Envoyé par Fred1599

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.

Citation:

Envoyé par Fred1599

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 ?

Citation:

Envoyé par Fred1599

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.

Citation:

Envoyé par Fred1599

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.

Citation:

Envoyé par Fred1599

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.
14/11/2025, 01h25
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.

Voir 40 message(s) de cette discussion en une page