Archives de
Catégorie : Apprentissage du code

Et si apprendre à coder à l’école était fait par des professeurs d’arts plastiques ?

Et si apprendre à coder à l’école était fait par des professeurs d’arts plastiques ?

Depuis quelques années, je vois bien la volonté d’apprendre à coder à l’école exprimée par le ministère de l’éducation nationale. J’ai lu pas mal d’articles qui débattent de la pertinence ou non d’apprendre à coder aux enfants directement dans les programmes scolaires. Généralement, je retrouve deux positions entre ceux qui estiment qu’il faut se concentrer sur les « fondamentaux » comme apprendre à lire, écrire et compter ; et ceux qui pensent qu’il faut que les enfants découvrent le plus de choses. Par contre, je vois assez rarement de discussions sur la place du code à l’école.

 

Une volonté d’apprendre à coder à l’école depuis la rentrée 2016

 

Depuis la rentrée 2016, apprendre à coder à l’école est une réalité qui a intégré les programmes de primaire et collège. De mon point de vue, c’est déjà une belle évolution puisque l’on passe d’un apprentissage du numérique orienté sur les usages, sur savoir comment utiliser un ordinateur (et donc être consommateur), à un apprentissage fondé sur la compréhension et la construction du monde numérique (et donc être acteur, constructeur).

Concrètement, l’initiation à la programmation à l’école va commencer à l’âge de 6 ans du CP au CM1. C’est au collège qu’apprendre à coder entre dans les programmes de mathématiques. Au brevet 2017, l’épreuve de mathématiques et sciences comportera des exercices de programmation et d’algorithmique.

« Nous avons fait le choix de nous appuyer sur la mobilisation des enseignants de mathématiques et de technologie » Michel Lussault, président du Conseil supérieur des programmes.

Une approche plus globale pour apprendre à coder à l’école que le cloisonnement dans les mathématiques

 

Le parti-pris est donc d’intégrer l’apprentissage du code à l’école dans les mathématiques. Je ne vais pas insister sur la formation des professeurs de mathématiques pour remplir correctement cette mission ou sur le débat pour savoir si on devrait créer une matière « informatique » à l’école. Je pense que je pourrais en faire un billet de blog dédié 😉

Personnellement, je pense que c’est assez réducteur que de cantonner le code aux mathématiques (même si les mathématiques peuvent être créatives). En faisant ce choix, on accentue les préjugés que la programmation informatique est uniquement une science sans mettre en avant que c’est une façon de penser différemment.

En réalité, apprendre à coder à l’école devrait être possible dans de nombreuses matières. Coder, c’est aussi savoir organiser sa pensée et mieux comprendre le monde. La logique du code permet d’être bien plus créatif que ce que l’on nous présente à travers cette intégration dans les programmes scolaires.

Pourquoi apprendre à coder à l’école ne serait pas plus créatif ?

 

Lorsque j’étais encore à l’école, j’ai adoré mes cours d’arts plastiques. Je n’ai pourtant pas poursuivi mes études dans ce domaine (j’ai été en Fac de Droit) mais ça a été une formidable expérience. En arts plastiques, je n’ai pas appris à dessiner. Ce n’était pas l’objet. C’est une façon de penser que l’on enseigne et les méthodes ne sont que secondaires.

En fait, je suis persuadé que les professeurs d’arts plastiques devraient également apprendre à coder. Avec le code informatique, on peut construire de nombreuses choses et la seule limite est sa propre imagination. La logique du code est assez rapide à assimiler ainsi que les bases. Par contre, développer sa créativité est bien plus complexe.

Faire de la programmation, ce n’est pas une matière purement technique. En fait, ce sont des outils numériques que l’on peut utiliser pour construire le monde de demain et s’épanouir personnellement. L’objectif de l’apprentissage du code n’est pas de faire des ingénieurs.

En réalité, mon interrogation est plutôt de savoir comment nous voulons former nos enfants. Je suis convaincu que le rôle de l’école est de former des gens à penser et à être autonome. Apprendre à coder à l’école n’est donc pas une chose anecdotique puisque cela permet d’ouvrir des perspectives au-delà des sciences.

 Alexandre Amigouet

Pilier Rails 5 – La beauté du code tu célèbreras

Pilier Rails 5 – La beauté du code tu célèbreras

On écrit du code non seulement pour être compris de l’ordinateur ou d’autres programmeurs, mais aussi avec une intention esthétique. Un code qui plaît à l’œil a de la valeur en tant que tel et doit être encouragé au maximum. Cela ne veut pas dire que l’aspect esthétique est l’unique priorité, mais il a sa place aussi bien que les autres dans les critères de choix du programmeur

Mais qu’est-ce exactement qu’un beau code ? Quand on parle de Ruby, un beau code se situe souvent au croisement entre un assemblage d’idiomes Ruby et d’un langage customisé et spécifique à un domaine.

Voyons un exemple simple issu d’Active Record :

  class Project < ApplicationRecord

     belongs_to :account

     has_many :participants, class_name: ‘Person’

     validates_presence_of :name

   end

Cela ressemble à du DSL mais c’est une définition de classe avec trois appels de méthodes de classe qui prennent en paramètre des symboles et options. Il n’y a rien de sophistiqué, mais ces quelques lignes, aussi simples que jolies, offrent autant de pouvoir en plus que de flexibilité.

Une partie de la beauté de ces lignes de code vient de ce qu’elles honorent les principes mentionnés ci-avant, dont celui de Convention plutôt que Configuration.

Lorsqu’on crée une association avec un belongs_to :account, par convention on référence un modèle « Account » stocké dans la table nommée « accounts » via la clé « account_id ».

Un autre exemple du système de migrations de base de données :
   class CreateAccounts < ActiveRecord::Migration
     def change
       create_table :accounts do |t|
         t.integer :queenbee_id
         t.timestamps
       end
     end
   end

Le programmeur déclare une classe de façon conventionnelle, comme la sous classe ActiveRecord::Migration qui implémente #change, et le framework peut faire toute la plomberie autour, et sait que c’est cette méthode qu’il doit appeler. Dans le cas de ces migrations, cela va non seulement permettre d’appeler rails db:migrate pour mettre à jour la base de données avec cette nouvelle table mais aussi de la supprimer avec un autre appel.

Mais parfois, un beau code peut être plus subtil, et plutôt que de le rendre aussi bref que puissant, le challenge pourra être d’avoir une écriture fluide et bien rythmée.

Prenons ces deux lignes :

if people.include? person

if person.in? people

Même si le résultat est le même, le style et le focus sont légèrement différents. La première ligne se focalise sur la collection, tandis que la seconde se concentre sur la personne. Même si les deux lignes ont quasiment la même longueur, la deuxième semble beaucoup plus belle et peut susciter un réel plaisir esthétique pour le programmeur lorsqu’elle est utilisée dans un cas où la condition concerne la personne. 

Pilier Rails 4 – Un paradigme unique tu refuseras

Pilier Rails 4 – Un paradigme unique tu refuseras

Il est toujours tentant de choisir une seule idée centrale pour sous-tendre votre architecture et de la suivre jusqu’à sa conclusion logique. Cette méthode séduit plus d’un programmeur. Rails est à l’opposé de ce principe.

Rails n’est pas un tissu uni et lisse, mais plutôt un patchwork, composé d’une variété d’idées et de paradigmes, dont certains qui pourraient sembler incompatibles s’ils étaient combinés deux à deux. Mais Rails n’est pas un championnat de la meilleure idée où un seul vainqueur serait choisi.

Prenez les templates qu’on utilise pour construire le view dans notre graphe Rails MVC.  Par défaut, tous les assistants qui nous permettent d’extraire du code de ces templates sont juste une bouillabaisse de fonctions, très semblable à une soupe PHP. Mais cette bouillabaisse fonctionne parfaitement lorsqu’on doit présenter des fonctions individuelles qui n’ont que rarement besoin d’interagir.

Cela ne veut pas dire qu’on n’a pas besoin de temps en temps d’avoir recours à quelque chose d’orienté objet lorsqu’on construit des views. Le concept de Presenters, dans lequel on emballe de nombreuses méthodes interdépendantes les unes des autres et les données en-dessous, s’avère parfois un antidote parfait à la bouillabaisse de fonctions. Mais cela arrive rarement.

La flexibilité idéologique de Rails lui permet de résoudre une large gamme de problèmes. La plupart des paradigmes individuels conviennent parfaitement pour résoudre un certain type de problèmes mais sont inadaptés et trop rigides dès qu’ils sont sortis de leur zone de confort. Appliquer des paradigmes en couches superposées permet de couvrir toutes les zones à problème et rendent le framework final plus puissant et bien plus flexible que tout autre paradigme individuel.

Mais cette flexibilité a un coût : elle requiert de maîtriser non seulement la programmation orientée objet mais également d’avoir pas mal d’expérience en programmation procédurale et fonctionnelle.  Cette contrainte concerne également les sous-langages de Rails : il est ainsi fort utile de maîtriser Javascript pour les views ou SQL pour résoudre quelques queries un peu plus complexes, du moins pour pouvoir profiter au mieux de toutes possibilités qui s’offrent à vous.

La seule façon de gérer cette contrainte est d’adopter la technique de la tortue plutôt que celle du lièvre pour apprendre en chemin, patiemment. Ce qui veut dire qu’au départ vous ne comprendrez pas forcément chaque aspect du framework mais cela ne vous empêchera pas de faire quelque chose de simple qui aura une réelle valeur.

Pilier Rails 3 – Un menu omakase tu utiliseras

Pilier Rails 3 – Un menu omakase tu utiliseras

Comment savoir quel plat commander dans un restaurant quand on ne sait pas ce qui est bon ? Si vous laissez le chef choisir pour vous, vous avez de fortes chances de déguster un bon repas. Tel est le principe de l’omakase.

En matière de programmation, ce principe consistant à laisser des experts choisir pour vous est proche du principe de Convention plutôt que Configuration mais à un niveau plus macro. Alors que le premier se concentre sur la meilleure façon d’utiliser des frameworks individuels, omakase se focalise sur le choix des frameworks et comment les assembler les uns avec les autres. Ce principe contraste donc avec la tradition forte en programmation de présenter les différents outils disponibles comme des choix individuels et de laisser au programmeur le privilège (et le fardeau) de décider le(s)quels il va utiliser.

Vous avez probablement entendu souvent ce conseil : « Utilisez le meilleur outil pour accomplir la tâche », mais la question de quel est le « meilleur outil » est souvent plus difficile à trancher qu’il n’y paraît au premier abord. Ruby a fait le choix de réduire le privilège du programmeur individuel, celui de choisir chacun de ses outils, au profit d’un plus grand bien : une boîte à outil plus performante pour tous.

Les bénéfices sont légion !

  • La force du nombre : l’expérience partagée par le nombre d’utilisateurs de Rails offre une base saine pour partager, débattre, et apprendre les uns des autres,
  • Les utilisateurs travaillent tous à améliorer la même boîte à outil : en tant que framework complet (Full Stack Framework), Rails inclut une variété de parties mobiles qu’il est important de savoir assembler. La plupart des difficultés rencontrées dans les logiciels provient non pas des composants individuels mais des interactions. Le travail commun de l’ensemble de la communauté Rails permet  de mieux comprendre et maîtriser ces interactions,
  • Des substitutions possibles mais pas obligatoires : si Rails est une pile de composants fonctionnant selon le principe omakase, il est toutefois possible de remplacer certains de ses frameworks et librairies par d’autres composants, mais ce n’est pas une obligation. Ce qui signifie que vous pouvez prendre le temps de développer une palette que vous maîtrisez bien avant de penser à remplacer certains de ses composants.
Histoire pour apprendre à coder – La programmation

Histoire pour apprendre à coder – La programmation

Ce billet de blog est la suite de celui sur le boulier qui évoquait la mécanisation des opérations de calcul. Comme indiqué dans l’article sur le boulier, je souhaite reprendre trois innovations importantes (qui ont des conséquences lorsque l’on veut apprendre à coder) à travers une série de trois billets de blog qui sont :

Qu’est-ce la programmation ?

Les débuts de la programmation remontent au Moyen-Âge avec les  premiers automates. A l’époque, c’était des objets mécaniques qui avaient des mouvements automatiques (d’où leur nom) sans intervention humaine pour effectuer les mouvements. Les humains se contentaient de les … programmer !

Ces automates avaient donc une mémoire limitée à l’aspect mécanique qui pouvait se concrétiser par l’utilisation de poulies, d’engrenages, de courroies, etc.

A la fin du XVIIIème siècle, la programmation a connu une étape importante avec l’industrialisation. On avait besoin de machines capables de répéter des gestes programmés à l’avance par l’homme. Les machines industrielles ont permis dépasser les limites physiques du corps humain.

De nombreuses initiatives sont alors réalisées pour développer la programmation. On peut, notamment, évoquer les recherches du britannique Charles Babbage (1792-1871) sur les « calculateurs ».

BabbageDifferenceEngine

Charles Babbage est considéré comme un des précurseurs de l’informatique. Il est le premier à avoir réalisé une machine qui combine une mémoire et un calculateur programmable. 

« You will be able to appreciate the influence of such an Engine on the future progress of science. I live in a country which is incapable of estimating it. »
— Charles Babbage

Il a commencé à réfléchir à la programmation lorsqu’il était chargé de contrôler des calculs. Comme son travail était légèrement ennuyant, il a réfléchi à des méthodes pour automatiser ces calculs et éviter les erreurs.  Après différents essais, il a commencé à réaliser une machine intitulée le Analytical Engine qui était programmable à l’aide de cartes perforées qui permettaient d’obtenir les résultats (sur une feuille de cuivre) lorsqu’elles étaient insérées dans la machine.

Malheureusement, Charles Babbage n’a jamais réussi à construire une machine complète faute de financement. Cependant, le Science Museum de Londres à construit une de ses machines en 1990 en suivant ses plans et la machine fonctionnait bien comme il l’avait prévu.

La programmation est importante lorsque l’on veut apprendre à coder et son histoire n’est pas aussi récente que l’on pourrait le penser. Aujourd’hui, la programmation est essentiellement numérique mais elle puise ses origines dans ses recherches.

 

5 bonnes raisons de participer à la Code Week 2015

5 bonnes raisons de participer à la Code Week 2015

L’heure de la Code Week 2015 a sonné ! Ce samedi 10 Octobre marque le début d’une  semaine dédiée au code et à la programmation numérique dans toute l’Europe. Toxicode s’est mobilisé pour vous proposer tout au long de la semaine des événements en Région Parisienne et à Rennes et vous donne 5 raisons imparables de ne pas rater ce rendez-vous à échelle européenne.

Parce que c’est hyper tendance

La Code Week, c’est avant tout des opportunités de rencontres et d’échanges dans toute l’Europe. Et d’année en année, les événements organisés se font plus nombreux, et visent un public plus large. Il faut dire que la question de l’apprentissage du code est désormais devenue centrale et mobilise de plus en plus le gouvernement comme les acteurs sociaux. En 2014, on a compté environ 300 événements organisés rien que dans la France ! Cette année, Toxicode a mis les petits plats dans les grands et s’est associés à différents partenaires pour vous proposer des ateliers ludiques et innovants autour de l’apprentissage de la programmation (voir programme ci-dessous).

Parce qu’il y aura de l’action

La Code Week, c’est des ateliers ludiques pour les enfants (ateliers Scratch), des activités manuelles pour mettre les mains dans le cambouis (Makey Makey), de la création de jeux vidéo y compris la programmation de comportements d’un héros et de monstres (ateliers Toxicode – Code N Slash )…  Tout est fait pour que les participants de tous âges puissent vraiment avoir une expérience concrète de la programmation et de ses nombreuses applications au quotidien.

Parce qu’il y aura des robots et des IA (Intelligences Artificielles)

La Code Week, c’est des rencontres du 3ème type garanties ! Et oui, fini les heures assis devant un écran à écrire des lignes de code incompréhensibles. Désormais, la programmation permet de coder des intelligences artificielles (atelier Toxicode – Coder une intelligence artificielle à Rennes), le comportement d’un robot constructeur (ateliers Toxicode – Codecraft) ou de robots en chair et en os, enfin vous voyez ce que je veux dire… (ateliers robotiques avec de vrais robots pour devenir l’ami de Wall-e)         

Parce qu’il y aura de la compèt

La Code Week, c’est aussi l’occasion de participer à des challenges quel que soit votre niveau, passionné de programmation ou débutant. De nombreuses game jams sont prévues, permettant de se mesurer aux autres participants pour créer un niveau de jeu vidéo (ateliers Toxicode – Code N Slash ) ce qui obligera à sortir de votre zone de confort et à repousser vos propres limites !   

Parce qu’il y aura des filles (et des garçons)

Désormais, le code n’est plus seulement réservé à la gent masculine ! Les filles ont investi la place et ne comptent pas en partir. Les assoc de promotion de la programmation et des nouvelles technologies destinées aux filles type Girls in Tech ou Rails Girls fleurissent un peu partout et on ne va pas s’en plaindre… Lors des ateliers Toxicode organisés cet été, on comptait certes encore une majorité de mâles, mais les filles sont de plus en plus nombreuses ! Donc n’hésitez plus et venez apprendre à coder ou vous perfectionner au code, partout en France et en Europe !

Programme des ateliers Toxicode pour la Codeweek 2015 (10 au 18 octobre 2015) :

  • 10 octobre 2015 de 15h00 à 16h30 – “Atelier Codecraft” à la Médiathèque Hélène BERR, Paris 12ème, le cadre de NUMOK, festival numérique des Bibliothèques de la Ville de Paris.
  • 10 octobre 2015 de 14h30 à 17h30 – “Atelier Code N’ Slash” à la Médiathèque Françoise SAGAN, Paris 10ème.
  • 13 octobre 2015 de 19h à 23h – “Atelier Code N’ Slash” à l’ISART DIGITAL, Paris 11ème.
  • 17 octobre 2015 de 10h00 à 13h00 – “Atelier Bot Arena pour coder une Intelligence Artificielle” dans le cadre du Festival MAINTENANT à Rennes.
  • 17 octobre 2015 de 11h00 à 12h30 – “Atelier Codecraft” au Cube à Issy-les-Moulineaux.
  • 17 octobre 2015 de 14h30 à 17h30 – “Atelier Code N’ Slash” au Cube à Issy-lesMoulineaux.

Nos interventions :

  • Le 17 octobre 2015 de 15h15 à 16h30 – Échanges autour de l’apprentissage du code et des jeux vidéo : outils numériques de réappropriation du monde dans le cadre du Festival MAINTENANT à Rennes.
  • Le 23 octobre 2015 – Participation à la soirée de clôture de la Codeweek, organisée dans les locaux de Mozilla à Paris autour du thème : « Code, Créativité et Pédagogie ».

Exemple d’outils : http://silentteacher.toxicode.fr/

Démonstration de Bot Arena : https://www.youtube.com/watch?v=faS7zrRijAg

Démonstration de Code N’ Slash : https://www.youtube.com/watch?v=ZYv90pAvGe8

Nos formations en ligne : http://www.toxicode.fr/events

Pour plus d’informations sur ces événements  Code Week 2015, vous pouvez consultez la page www.codeweek.eu/

 

 

Mark Zuckerberg pense que l’on peut apprendre à coder grâce aux jeux vidéo

Mark Zuckerberg pense que l’on peut apprendre à coder grâce aux jeux vidéo

On ne présente plus Mark Zuckerberg, le célèbre fondateur de Facebook. Le 15 mai dernier, lors d’une séance de questions/réponses publiée sur Facebook, il a incité les parents à laisser leurs enfants jouer aux jeux vidéos pour favoriser leur développement intellectuel. Pour Mark Zuckerberg, on peut apprendre à coder grâce aux jeux vidéo et il se base sur son expérience personnelle pour en parler.

« Je ne serais assurément jamais devenu programmeur si je n’avais pas joué aux jeux vidéo étant enfant. » – Mark Zuckerberg

Il y a souvent un débat sur les effets des jeux vidéo sur les enfants. Par exemple, dès qu’il y a une tuerie aux Etats-Unis ou un acte de violence dans la société, on voit se développer des arguments autour du « c’est la faute aux jeux vidéo« .

Cette fois, Mark Zuckerberg explique que c’est grâce aux jeux vidéo que l’on peut devenir développeur. Dans son enfance, son goût des jeux vidéo lui a donné envie de faire des choses pour lui. Il a donc commencé par faire ses propres jeux vidéo seulement pour lui et « ils étaient horribles« . Ce n’était pas grave. Le jeu vidéo a donc été sa porte d’entrée pour apprendre à coder.

Néanmoins, il admet que certaines craintes des parents sont légitimes sur les jeux vidéos mais cela reste la solution la plus simple pour faire aimer les nouvelles technologies aux enfants.

Chez Toxicode, nous apprenons justement à des enfants à découvrir la programmation tout en développant leur propre niveau d’un jeu vidéo. Nos ateliers sont accessibles et on remarque qu’ils sont passionnés par l’exercice. Lors de nos différents ateliers pour apprendre à coder, je suis toujours assez étonné par le silence qui règne dans la salle. Les enfants sont vraiment concentrés.

Je partage donc cette approche pédagogique avec Mark Zuckerberg et je vous invite, si vous avez des enfants, à développer leur curiosité de la programmation que ce soit via des jeux vidéo ou tout autre support.

Bienvenue chez Toxicode – Première Game Jam dans nos nouveaux locaux !

Bienvenue chez Toxicode – Première Game Jam dans nos nouveaux locaux !

Ambiance conviviale et cacahuètes… Tels étaient les mots d’ordre du premier atelier Toxicode organisé dans nos nouveaux locaux parisiens. Après le succès de notre collaboration avec le réseau des Bibliothèques de la Ville de Paris cet hiver, nous venons de lancer une série d’ateliers et de formations Toxicode… pour fêter l’arrivée des beaux jours !

Notre premier event : une Game Jam organisée lundi 4 Mai, qui a rassemblé une trentaine de personnes de tous niveaux. Le concept : apprendre à coder en utilisant des outils ludiques conçus et développés par Toxicode.

Ca s’est passé comment?

Tout d’abord, nous avons commencé avec Silent Teacher, un de nous outils qui permet de s’initier en douceur aux concepts sous-tendant la programmation (formules, algorithmes) sans même avoir l’impression d’être en cours.

Ensuite, on est passé aux choses sérieuses avec Code N’Slash, une autre de nos créations, permettant d’apprendre à coder en construisant soi-même ou en petits groupes, des niveaux de jeu vidéo de difficultés variables. Le héros, un petit mais preux chevalier en armure, doit affronter des monstres et franchir des murs et des abysses pour rejoinder la sortie de chaque niveau.

Notre public, très motivé, a posé des tas de questions à notre équipe de sept formateurs Toxicode. Pierre Lancien, l’un de nos organisateurs Toxicode, explique : “Les gens ont entendu parler de l’événement par bouche à oreille, et ceux qui sont venus étaient donc souvent des groupes de potes, dont toute une troupe venue de Simplon, d’ou l’ambiance chaleureuse. Les gens se levaient pour aller faire des pauses et grignoter, et en profitaient aussi pour discuter avec certains membres de notre équipe à l’extérieur de la salle.”

Verdict ?

Au vu des retours très positifs des participants, pari réussi pour ce premier atelier chez Toxicode !

Vous aussi, vous voulez participer ?

Vous aussi, vous aimeriez apprendre à coder ? Vous voulez en savoir plus sur la liste des prochains ateliers et programmes de formations Toxicode prévus sur Paris ?  Visitez notre page Toxicode Events.

La nouvelle réforme des programmes scolaires prévoit d’apprendre à coder à l’école

La nouvelle réforme des programmes scolaires prévoit d’apprendre à coder à l’école

Le 13 avril 2015, le ministère de l’Education nationale a publié les projets de programmes pour les élèves du CP à la troisième qui doivent entrer en vigueur pour la rentrée de 2016. Outre la nouveauté de l’élaboration de programmes par cycles de trois ans avec des objectifs de formations, il est question d’apprendre à coder à l’école.

Ce n’est pas une grande surprise puisque l’apprentissage de la programmation à l’école est une préoccupation du gouvernement depuis quelques années maintenant. L’Académie des Sciences, le Conseil National du Numériques et des hommes politiques sont favorables à l’apprentissage du code à l’école. Au contraire, certaines personnalités comme Linus Torvalds estiment qu’apprendre à coder à l’école devrait être une spécialité en dehors du tronc commun.

Ce projet de programme tranche la question puisque ce serait les professeurs de mathématiques qui auraient la charge d’apprendre à coder aux élèves à partir du CE1.

Le projet prévoir que « dès le CE1, les élèves peuvent coder des déplacements à l’aide d’un logiciel de programmation adapté, ce qui les amènera en fin de CE2 à la compréhension, et la production d’algorithmes simples ».

L’idée est de préparer progressivement les élèves à apprendre à coder à l’école dès le cycle 2 (CP, CE1, CE2). Le cycle 3 (CM1, CM2, 6ème) doit permettre au professeur de mathématiques d’apprendre aux élèves à utiliser des logiciels de calculs et d’initiation à la programmation.

En réalité, ce n’est qu’à compter du cycle 4 (5ème, 4ème, 3ème) que le code serait enseigné aux élèves. Les enseignants devront réaliser une introduction de l’algorithmique et de la programmation.

Durant ce cycle 4, l’objectif de l’Education nationale est de développer « l’enseignement du raisonnement, éclairer l’introduction du calcul algébrique et fournir un nouveau langage pour penser et communiquer.  » A la fin de la 3ème, les élèves devront être capable « d’analyser un problème complexe, définir des sous-problèmes, des étapes de résolution ainsi que de traduire un algorithme dans un langage de programmation. »

Concrètement, le projet de programme prévoit que les élèves pourront réaliser des exercices consistants à développer des petites applications ludiques comme une bataille navale, un pong, un tic tac toe, etc. Dans tous les cas, il est précisé que « la maîtrise d’un langage de programmation n’est toutefois pas un objectif du programme. » Il est avant tout question d’une ouverture d’esprit afin d’enseigner une méthode et une réflexion.

C’est un défi que je trouve intéressant et assez cohérent, maintenant il reste un travail de formation des professeurs de mathématiques à réaliser. Je pense que de nombreux professeurs seront heureux de cette évolution des programmes vers l’apprentissage du code. Pour le moment, ce ne sont que des projets de programmes et il va falloir attendre quelques mois pour voir les versions définitives. Néanmoins, on peut observer une tendance qui est récurrente comme l’a démontré l’appel « Culture de l’innovation et de l’entrepreneuriat » favorisant, notamment, l’émergence de solutions pour permettre l’apprentissage du code à l’école.

Illustrations Lou Pine

Entre programmation et créativité : Bret Victor, le visionnaire décalé

Entre programmation et créativité : Bret Victor, le visionnaire décalé

A première vue, Bret Victor semble être un type plutôt banal. Il n’a ni la gouaille ou l’assurance d’un Mark Zuckerberg, ni le côté businessman génial d’un Steve Jobs. Il passerait presque inaperçu. Lorsqu’on commence à regarder une de ses présentations d’une heure sur Youtube, on se dit qu’on risque de s’ennuyer un peu, même si on est intéressé par la programmation.

Et en une minute, tout est retourné… On se prend une claque conceptuelle en pleine figure, on est sonné et surtout on n’a pas envie d’en perdre une miette. Car Bret Victor est avant tout un visionnaire… et un visionnaire de la meilleure trempe… un visionnaire décalé.

Bret Victor, ancien interface designer chez Apple, considère tout ce qui l’entoure et l’intéresse, notamment ses domaines d’expertise – programmation et créativité – et les triture, les retourne dans tous les sens pour mieux s’interroger et ouvrir de nouvelles portes… et c’est totalement prenant de le voir entreprendre ce questionnement philosophique des choses.

J’en veux pour preuve deux vidéos fort inspirantes que je vous conseille de regarder au plus vite.

« Les créateurs ont besoin d’une connexion immédiate avec ce qu’ils sont en train de créer. »

Dans “Inventing on Pinciples” (Inventer selon des Principes), Bret Victor traite du sujet de la créativité en s’appuyant sur des exemples liés à la programmation mais pas que. Et sur un précepte essentiel : quel que soit votre domaine d’expertise, technicien, ingénieur, vous pouvez (même vous devez) avoir le sentiment de travailler pour une cause qui vous semble juste, de défendre un principe éthique auquel vous croyez. En gros, il y a de la morale dans tout ce que l’on fait, même quand on met les mains dans le cambouis.

Bret Victor illustre ce principe en citant son exemple personnel. Le principe auquel il croit fermement ? Lorsqu’on crée quelque chose, on devrait pouvoir voir immédiatement, sans délai, le résultat ou l’impact de ce que l’on a crée. Il prend d’abord pour exemple une page de code classique d’une image. Si l’on souhaite modifier un détail de l’image, il faut aller dans le code, modifier, sauvegarder, relancer avant de confirmer que le résultat est bien celui qu’on espérait. Et Bret Victor de demander : pourquoi ne pas pouvoir voir immédiatement le résultat de toute modification dans notre code? Je vous laisse regarder la vidéo pour découvrir ses idées qui permettraient de coder efficacement, en ayant un lien direct avec ce que l’on veut créer.

Il n’utilise pas que des exemples issus de la programmation, également des algorithmes mathématiques, des circuits électriques… Mais le principe fondateur reste le même, et franchement, plus il parle et plus on en est convaincu. Bret Victor se place constamment en porte-à-faux par rapport à ceux qui croient déjà “savoir ce qu’ils font” et qui à force de ne rien questionner, finissent par simplement stagner plutôt que créer.

“La pensée la plus dangereuse pour un créatif, c’est d’avoir la certitude qu’il sait ce qu’il fait. »

Dans “The Future of Programming” (L’Avenir de la Programmation), Bret Victor est également dans le décalage, mais cette fois temporel. Il utilise une pirouette élégante : arrivant sur la scène avec un vieux rétroprojecteur, il fera mine pendant toute sa présentation d’être en 1973 et de présenter les idées révolutionnaires des années 60 et 70 qui à coup sûr, seront totalement acquises d’ici 40 ans, c’est à dire … en 2013.

Pourquoi ? Pour mettre la « nouvelle génération » qui constitue son public devant ce qu’il nomme une « tragédie » : que de toutes les idées visionnaires nées dans les années 60, à l’époque ou la programmation n’était pas encore clairement définie, nombreuses ont été totalement oubliées. Et le futur qu’on imaginait serait le nôtre en 2014 n’a pas pris en compte les idées géniales du passé. Du coup, on code encore comme il y a 40 ans… on a stagné. Et pire encore : la nouvelle génération tient pour acquis que tout a été déjà réfléchi, que la programmation ça doit être comme ça. Ils ne sont pas bridés, ils sont juste aveugles…

Pour remédier à cela une bonne solution : écoutez ce que dit Bret Victor, essayez d’être inspirés par ce que vous faites et ne prenez jamais pour acquis les systèmes dans lesquels vous évoluez.

Si vous faites partie de la nouvelle génération de développeurs, concepteurs de jeux vidéos, ou autres experts IT, si vous manquez d’inspiration lorsque vous vous levez le matin, regardez ces deux vidéos… elles changeront peut être votre façon de travailler ou même votre vie !