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. Et les données de terrain sur les calculatrices disent quelque chose de précis qui s'applique directement ici : le bénéfice apparaissait quand l'outil était tissé dans un enseignement conçu autour de lui, tandis que le mettre entre les mains des enfants trop tôt, sans structure, pouvait en réalité freiner leurs compétences. L'outil n'a jamais été l'essentiel. Quand et comment tu l'introduis, si.

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. Je dois être honnête : ceci relève de l'expérience vécue plus que de la science établie — la recherche montre que ce type de transfert est fort vers les problèmes proches et seulement modeste vers les lointains. Mais le transfert proche, porter la base d'un langage au suivant, c'est exactement ce qu'est une fondation.

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.

Si l'un d'eux ne te dit rien, voici à quoi chacun ressemble vraiment — aucun n'est compliqué, et c'est précisément là tout l'intérêt :

Un organigramme : l’ovale démarre et termine le processus, un rectangle est une étape, et un losange est une décision qui fait bifurquer le chemin.

Un diagramme entité-association : chaque boîte est ce sur quoi tu stockes des données (une entité), le losange est la manière dont elles sont liées, et « plusieurs-à-plusieurs » signifie qu’un élève suit plusieurs cours et qu’un cours a plusieurs élèves.

Un diagramme objet-relation (de classes) : chaque boîte est un type d’objet avec ses données (en haut) et ses actions (en bas). Les flèches montrent comment les objets se relient — une Voiture « est un » Véhicule et « a un » Moteur.

↓ requêtes données ↑

Présentation

ce que voit l’utilisateur — écrans, boutons

Logique métier

les règles — ce que l’app décide et fait

Accès aux données

lire et écrire les données

Base de données

là où vivent les données

Architecture en couches : chaque couche ne parle qu’à celle qui est juste en dessous. Séparer les responsabilités évite qu’un système devienne une masse emmêlée.

Le même processus en BPMN, désormais avec des couloirs (swim lanes). Chaque couloir est un rôle, et le flux qui traverse les couloirs montre exactement qui fait quoi et où a lieu un passage de relais. Ce relais entre rôles est ce qu’un organigramme ne peut pas montrer — et c’est la caractéristique la plus distinctive du BPMN.

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.

De la théorie à la pratique : par où une école K-12 peut commencer

Pour que cela ne reste pas de la théorie — et parce que je sais que la plupart d'entre nous lisent en cherchant une réponse claire, pas seulement un cadre — laisse-moi être concret pour les écoles K-12. Si tu n'as pas encore de programme de code, ou si tu cherches à transformer celui que tu as, alors, au-delà de Scratch, il y a quelques programmes que je te recommanderais directement. Ils sont entièrement gratuits, pensés pour le K-12, validés par des enseignant·es et approuvés pour un usage scolaire ; tu peux les adopter ou les adapter sans aucun coût, avec les ressources d'accompagnement dont un·e enseignant·e a réellement besoin — guides pédagogiques, plans de cours, exemples travaillés, vidéos. Ils sont disponibles en plusieurs langues. Et chacun donne aux élèves une fondation suffisante pour saisir la logique et les éléments essentiels de l'informatique tout en s'amusant et en construisant de vraies choses.

Code.org — désormais CodeAI. La légendaire initiative Code.org s'est rebaptisée en juin 2026 CodeAI, déplaçant son accent de l'informatique vers ce qu'elle appelle la fluidité numérique (digital fluency) — qui continue de contenir l'informatique en son sein, aux côtés des sciences de l'IA et des données. Et je dois le dire — fluidité numérique est le terme que beaucoup d'entre nous cherchaient. Il n'est même pas nouveau : Mitchel Resnick, l'esprit derrière Scratch, l'emploie depuis deux décennies pour dire concevoir, créer et remixer — pas seulement naviguer et bavarder. Il est parlant, et il exprime exactement ce dont parle cet essai : la fluidité, et la préparation à ce qui vient.
Experience CS, de la Raspberry Pi Foundation avec le soutien de Google.org — un excellent programme pour l'école primaire et le collège, avec plans de cours, grilles d'évaluation et guides pédagogiques. experience-cs.org
Code Club. Si tu veux rendre les choses plus ludiques et vivantes, tu peux candidater pour créer un Code Club et rejoindre un réseau de clubs partout dans le monde — également issu de la Raspberry Pi Foundation.

Commence par là. Remarque que tout ce que ces programmes construisent, c'est la fondation que je défends depuis le début : la logique, la structure, la joie de fabriquer quelque chose de réel — la part que l'IA ne peut pas construire à la place de l'élève, aussi bien qu'elle tape le code.

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.

Les affirmations de cet essai s'appuient sur les sources réunies ci-dessous. Pour l'histoire de la vérification de ces sources — et l'infographie faite par IA que j'ai décidé de ne pas publier — vois la pièce compagnon, L'infographie que je n'ai pas publiée. — Carlos Miranda Levy

Les quatre perspectives

La version la plus forte de cet argument est l'affirmation du transfert : que ce que l'enseignement de la programmation construit est une capacité générale de raisonnement structuré qui survit à n'importe quel langage. Cette affirmation est plausible, et c'est aussi exactement le genre de chose que la littérature de recherche traite avec prudence, parce que le transfert est notoirement difficile à démontrer. Le cadrage honnête est donc celui que Carlos utilise — garder la fabrication, parce que c'est là que les preuves sont les plus solides — plutôt que de faire reposer tout l'argument sur une large affirmation de transfert qu'il faudrait nuancer. Quand la révision sourcée arrivera, c'est dans la littérature sur la pensée computationnelle et le constructionnisme que je l'ancrerais.

Ma préoccupation, c'est l'équité, et elle coupe dans une direction inconfortable. « Laissez l'IA écrire le code » sonne libérateur, mais les élèves qui apprendront encore la fondation sont ceux des écoles dont les enseignants comprennent la différence entre concevoir et viber. Les élèves des écoles sous-dotées sont ceux à qui l'on remettra l'outil en leur disant que cela suffit. Si nous ne sommes pas délibérés, « l'IA écrit le code » devient un mécanisme d'élargissement du fossé qui a l'apparence de l'accès. Le vocabulaire de modélisation que Carlos énumère — organigrammes, diagrammes entité-relation, BPMN — est peu coûteux à enseigner et difficile à simuler. C'est exactement pourquoi il a sa place dans chaque école, pas seulement dans les écoles innovantes.

Concrètement : garde Scratch pour les plus jeunes, ajoute les diagrammes à mesure qu'ils grandissent, et oui — fais-leur absolument livrer des choses réelles avec l'IA. L'erreur que feront certaines écoles, c'est d'interdire l'outil par peur. L'autre erreur, c'est de le remettre sans structure. Fais les deux à la fois : fais-leur d'abord concevoir sur papier ou en diagramme, puis laisse-les construire avec l'IA, puis fais-leur expliquer pourquoi ça marche. L'étape de l'explication est tout le jeu. S'ils peuvent expliquer pourquoi ça marche, ils ont appris quelque chose. S'ils ne peuvent pas, ils l'ont vibé, et tu l'as repéré.

Je me suis enseigné le code à neuf ans et j'ai suivi mon dernier cours de programmation à quatorze, et je construis encore aujourd'hui sur cette fondation. Ce n'est pas de la nostalgie — c'est une preuve. Ce qui a perduré n'a jamais été le langage ; c'était la structure. Alors, quand une école me demande s'il faut continuer à enseigner la programmation, j'entends une autre question en dessous : allons-nous continuer à apprendre aux enfants à penser en structures, à spécifier avec précision, à imaginer puis à organiser ce qu'ils ont imaginé ? La réponse à cette question doit être oui, et elle devient plus vraie, pas moins, à mesure que les machines tapent mieux. Change le programme. Simplement, en le changeant, ne jette pas la seule chose qui vaille d'être gardée.

Sources et lectures complémentaires

Cet essai est un argument personnel. Les références ci-dessous sont les sources primaires vérifiées derrière ses affirmations factuelles — réunies par une recherche approfondie et contrôlées. Là où les données sont réellement partagées (notamment jusqu’où les compétences de la pensée computationnelle se transfèrent, et les études encore préliminaires sur l’IA et l’apprentissage), les sources le disent.

Le vibe coding et le débat sur l’apprentissage du code

Andrej Karpathy, the “vibe coding” post, X, 2 February 2025. x.com/karpathy
Simon Willison, “Not vibe coding” (on the term’s precise meaning), simonwillison.net, 1 May 2025.
Matt Welsh, “The End of Programming,” Communications of the ACM, January 2023. doi:10.1145/3570220
Jensen Huang, remarks at the World Governments Summit, Dubai, February 2024.
TeachAI & CSTA, “Computer Science Education More Important than Ever in an Age of AI” (joint guidance), 2024.
Mark Guzdial, “Learning to Program Matters … in the Age of AI,” Medium, 2024.

Pensée computationnelle et constructionnisme

Jeannette M. Wing, “Computational Thinking,” Communications of the ACM 49(3), 2006. doi:10.1145/1118178.1118215
Seymour Papert, Mindstorms: Children, Computers, and Powerful Ideas, Basic Books, 1980.
Mitchel Resnick et al., “Scratch: Programming for All,” Communications of the ACM 52(11), 2009. doi:10.1145/1592761.1592779
Scherer, Siddiq & Sánchez Viveros, “The cognitive benefits of learning computer programming: A meta-analysis of transfer effects,” Journal of Educational Psychology, 2019. (Near transfer strong; far transfer modest — the caveat behind the essay’s “foundation” claim.)

La science cognitive de l’apprentissage vs. la délégation

Slamecka & Graf, “The generation effect: Delineation of a phenomenon,” Journal of Experimental Psychology, 1978. doi:10.1037/0278-7393.4.6.592
Robert A. Bjork & Elizabeth L. Bjork, “Desirable difficulties in theory and practice,” Journal of Applied Research in Memory and Cognition 9(4), 2020.
John Sweller, “Cognitive load during problem solving: Effects on learning,” Cognitive Science 12(2), 1988.
Kosmyna et al., “Your Brain on ChatGPT,” arXiv:2506.08872, 2025. (Preprint, not peer-reviewed — suggestive, not conclusive.)
Lee et al., “The Impact of Generative AI on Critical Thinking,” CHI 2025. doi:10.1145/3706598.3713778 (Self-reported, correlational.)

La boîte à outils de modélisation

Peter Pin-Shan Chen, “The Entity-Relationship Model — Toward a Unified View of Data,” ACM Transactions on Database Systems 1(1), 1976. doi:10.1145/320434.320440
Grady Booch, James Rumbaugh & Ivar Jacobson, the Unified Modeling Language (UML), adopted by the Object Management Group, 1997.
Object Management Group, Business Process Model and Notation (BPMN) — v1.0 (2004), OMG-maintained since 2005; also ISO/IEC 19510.
Frank & Lillian Gilbreth, “Process Charts” (the flow-process chart), ASME, 1921.

L’histoire comme analogie : le débat de la calculatrice

Hembree & Dessart, “Effects of Hand-Held Calculators in Precollege Mathematics Education: A Meta-Analysis,” Journal for Research in Mathematics Education 17(2), 1986. (Benefits when integrated into instruction; early unstructured use could hinder — outcomes depend on how and when, not on the tool alone.)
Ellington, “A Meta-Analysis of the Effects of Calculators on Students’ Achievement and Attitude Levels,” JRME 34(5), 2003.
National Council of Teachers of Mathematics, Principles and Standards for School Mathematics, 2000.

Programmes K-12 gratuits et « fluidité numérique »

Code.org, “Code.org is now CodeAI,” 2 June 2026 (code.org); reported by GeekWire, 2 June 2026. (CodeAI retains computer science within “digital fluency,” alongside AI science and data science.)
Mitchel Resnick, on “digital fluency” — designing, creating, and remixing, not just browsing and chatting (MIT Media Lab, 2002; restated in the 2009 Scratch paper).
Raspberry Pi Foundation, Experience CS — free CS curriculum for ages 8–14, with Google.org (experience-cs.org), 2025.
Raspberry Pi Foundation, Code Club — global network of free coding clubs (codeclub.org), since 2012.
Plan Ceibal, Uruguay — national one-laptop-per-child program, launched 2007.