Faut-il encore enseigner la programmation ? La question d'une directrice d'école à l'ère du vibe coding

Laisse-moi commencer là où je commence toujours, parce que le cadre importe plus que la réponse. C'est le même défi que celui que nous affrontons avec l'éducation dans son ensemble. Tu sais déjà qu'il faut la changer. Tout le monde le sait. La difficulté n'a jamais été de savoir s'il fallait la changer — c'est de la changer bien. Les réformes échouent non pas parce que les gens résistent au changement, mais parce qu'elles changent la mauvaise chose, abandonnent ce qui était porteur et conservent ce qui était décoratif. Alors, avant de décider de retirer la programmation du programme scolaire, nous devrions être très au clair sur ce que la programmation enseignait réellement. Parce qu'elle n'a jamais vraiment enseigné « la programmation ».

La programmation, ce sont les nouvelles mathématiques

La pertinence de la programmation aujourd'hui est comme la pertinence des mathématiques. Et je dis mathématiques délibérément — pour contourner le débat plus difficile et plus bruyant sur la pertinence de la chimie ou des autres sciences — parce qu'avec les maths, presque tout le monde accepte déjà l'argument. Nous n'enseignons pas l'arithmétique aux enfants parce que nous nous attendons à ce qu'ils passent leur vie adulte à poser des divisions à la main. Nous avons des calculatrices depuis cinquante ans. Nous l'enseignons parce qu'elle construit quelque chose en dessous : le sens du nombre, le raisonnement structuré, la capacité de passer d'une situation réelle désordonnée à un modèle abstrait, et retour.

La programmation, c'est pareil. La valeur n'a jamais été la syntaxe. C'était la fondation — la pensée structurée et la pensée en processus. C'est apprendre à décomposer un problème en étapes, à nommer et suivre des états, à raisonner sur ce qui se passe dans quelle condition, à construire quelque chose au comportement prévisible à partir de pièces qui, prises une à une, font très peu. Ce n'est pas une compétence de programmation. C'est une compétence de pensée, que la programmation se trouve enseigner exceptionnellement bien.

Alors, quand on me demande « l'IA rendra-t-elle la programmation obsolète comme les calculatrices ont rendu l'arithmétique obsolète ? », ma réponse est : remarque que les calculatrices n'ont pas rendu l'arithmétique obsolète. Elles ont rendu le calcul manuel optionnel et la compréhension sous-jacente plus importante, pas moins — parce que désormais, c'est la personne qui comprend le modèle, et pas seulement le bouton, qui peut dire quand la réponse est fausse.

Ce qui perdure vraiment

Si la syntaxe n'est pas l'essentiel, qu'est-ce qui l'est ? Quand je réduis tout à l'os, ce qui perdure repose sur trois axes :

• Techniquement — la capacité de générer des spécifications. Dire précisément ce qu'une chose doit faire : ses entrées, ses sorties, ses états, ses règles, ses cas limites. Une IA construira presque tout ce que tu sais bien spécifier. Elle construira du non-sens, magnifiquement, à partir d'une spécification vague.
• Créativement — la capacité de visualiser et d'imaginer. Voir la chose qui n'existe pas encore, la tenir dans sa tête, se représenter son comportement avant qu'une seule ligne ne soit écrite.
• Productivement — la capacité de structurer, d'articuler et d'interconnecter. Prendre des idées, des concepts et des fonctionnalités, et les organiser en quelque chose de cohérent — voir comment les pièces se relient et où elles se connectent.

Regarde à nouveau cette liste et remarque quelque chose : aucune de ces trois capacités n'est une compétence de programmation, et toutes les trois sont exactement ce que tu ne peux pas déléguer à une IA. La machine est désormais extraordinaire pour produire le code. Elle reste entièrement dépendante d'un humain capable de spécifier, d'imaginer et de structurer. C'est la partie qui vaut la peine d'être enseignée. C'est la partie qui vaut la peine d'être protégée.

Une preuve personnelle à laquelle je reviens sans cesse

Laisse-moi rendre cela concret avec ma propre vie, parce que c'est la preuve la plus claire que je possède. Aujourd'hui encore, je me surprends moi-même et je livre des choses réelles avec les compétences en programmation que je me suis enseignées à neuf ans sur un Texas Instruments TI-99/4A, puis que j'ai approfondies à quatorze ans dans deux ou trois cours chez IBM — COBOL et bases de données sur un System/34. Ces deux expériences ont marqué ma vie. Je n'ai jamais suivi un autre cours de programmation. Pas un seul. Et j'ai livré des systèmes critiques et des plateformes ouvertes au public, et supervisé leur développement.

Il y a donc clairement quelque chose là-dedans que nous ne devrions pas négliger. Quand je me demande ce que c'était, la réponse est toujours la même : c'était la structure. La base — variables, routines, processus. Tout ce que j'ai construit ensuite a été bâti sur cette fondation, posée avant mes quinze ans et jamais formellement revisitée.

Voici l'indice révélateur. Au fil des décennies, j'ai vu la programmation évoluer à travers des techniques et des paradigmes que je n'ai jamais formellement appris. Mais parce que j'ai la base, je peux lire et comprendre presque n'importe quel code, dans presque n'importe quel langage. Je ne sais pas programmer en Python — je ne l'ai jamais appris — mais je peux lire du Python et comprendre exactement ce qu'il fait. Les fonctions changent, les structures changent ; la logique sous-jacente est lisible pour quiconque possède la fondation. Cette lisibilité, cette transférabilité à travers les langages et à travers quarante ans, c'est la chose que l'école devrait chercher à installer. Elle survit à chaque technologie particulière à travers laquelle on l'a enseignée.

Ce que j'enseignerais concrètement

Donc, concrètement : si les enfants apprennent à créer des choses dans Scratch, cela couvre probablement les fondamentaux — ils y rencontrent les procédures, les structures de données, les variables, les boucles, les conditions, le séquençage. C'est une vraie fondation. Ensuite, selon l'âge, j'ajouterais le vocabulaire de modélisation et de structuration qui transforme une intention vague en quelque chose de constructible :

• Les organigrammes — que la plupart des programmes scolaires introduisent déjà — pour raisonner sur les processus et le flux de contrôle.
• Les diagrammes Entité-Relation et Objet-Relation — pour penser clairement les données et la manière dont les choses se relient.
• L'architecture logicielle en couches — pour comprendre comment un système sépare les préoccupations au lieu de devenir une masse indifférenciée.
• Et pour les élèves plus âgés, un passage des organigrammes au BPMN (Business Process Model and Notation) — le même instinct, à l'échelle de processus et d'organisations réels.

Et ensuite — c'est la partie qui répond à la vraie question de mon amie — je leur apprendrais à exécuter ce qu'ils ont conçu avec le vibe coding. Laisse l'IA taper. Laisse l'élève faire la réflexion qui dit à l'IA quoi taper. Ce n'est pas un compromis ; c'est la juste division du travail pour l'époque dans laquelle nous vivons réellement. La conception appartient à l'humain. L'exécution est augmentée. Le jugement sur la justesse du résultat reste, toujours, à la personne qui comprend la structure sous-jacente.

Le piège : deux vibes et personne qui n'apprend

Mais je garderais Scratch — et je veux être précis sur le pourquoi, parce que c'est le nœud de toute la question. Je le garderais pour la raison constructionniste de Seymour Papert : les enfants apprennent le plus durablement en fabriquant — en construisant une chose extérieure qu'ils peuvent regarder, tester, casser et réparer. Et je le garderais pour une seconde raison que les gens oublient : la main, l'œil et l'esprit engagés ensemble dans le travail. L'engagement physique et mental n'est pas accessoire à l'apprentissage — dans les premières années, il se peut qu'il soit l'apprentissage.

Parce que voici le mode d'échec vers lequel nous marchons tout droit. Si nous ne faisons pas attention, l'élève va « viber » la conceptualisation — désigner vaguement ce qu'il veut — et l'IA va « viber » le code, et un artefact fini apparaîtra à l'écran. Et cela ressemblera à un succès. Et personne n'aura rien appris. Deux vibes, un artefact, zéro fondation. Ce n'est pas de l'éducation ; c'est de l'externalisation avec des étapes en plus. Tout l'intérêt de construire la fondation, c'est qu'elle est la seule chose qui ne peut pas être « vibée » : elle doit être construite, par l'apprenant, à travers la difficulté productive de fabriquer réellement quelque chose.

Change-la — mais change-la bien

Alors, ma réponse à mon amie, et à chaque école, université et parent qui pose la même question cette année, n'est pas « gardez la programmation » et n'est pas « supprimez la programmation ». C'est : comprends ce que la programmation enseignait vraiment, garde cela de toutes tes forces, et change la livraison autour. Garde la fabrication. Garde la structure. Garde le vocabulaire de modélisation. Ajoute l'IA comme exécutrice d'une intention humaine bien spécifiée, bien imaginée, bien structurée. Et ne laisse jamais l'outil faire la seule partie — la fondation — que seul l'apprenant peut construire pour lui-même.

Tu sais que tu dois la changer. Toute la tâche, c'est de la changer bien.

Un brouillon de travail. Cet essai expose ma position ; une révision à venir y tissera la recherche sourcée — la littérature du constructionnisme, les travaux sur la pensée computationnelle, les origines du « vibe coding » et les preuves actuelles des sciences cognitives sur l'apprentissage et l'IA — avec citations complètes. Si tu as des travaux que je devrais lire d'ici là, dis-le-moi. — Carlos Miranda Levy

Les quatre perspectives