Faire écrire du code à ses apprenants sans rien installer

Le quart d'heure perdu au début de chaque séance

Sur une journée de formation, l'installation d'un environnement de développement coûte rarement moins de vingt minutes. Elle coûte surtout de l'attention : pendant que vous aidez trois personnes, les autres attendent, et le groupe se disperse avant même d'avoir écrit une ligne.

Le problème se répète à chaque session, et il s'aggrave dans trois situations très courantes :

• Les postes verrouillés. En centre de formation ou en entreprise, l'apprenant n'est pas administrateur de sa machine. Aucune installation n'est possible sans passer par un service informatique.
• Le matériel hétérogène. Trois versions de Windows, deux Mac, un portable sous Linux : la même procédure ne marche jamais partout.
• Les formations courtes. Sur une demi-journée, vingt minutes d'installation représentent près d'un dixième du temps total.

Un éditeur qui vit dans le navigateur supprime cette étape : l'apprenant ouvre un lien, ou scanne un code, et il écrit.

Ce qui tourne dans un navigateur, et ce qui n'y tourne pas

Il faut être clair sur le périmètre, parce que c'est là que les déceptions naissent. Un navigateur exécute très bien les bases d'un langage, et pas du tout ce qui touche au système.

Ce qui fonctionne couvre l'essentiel d'une initiation : affichage, saisie au clavier, conditions, boucles, fonctions, listes et dictionnaires, gestion des erreurs, et les premières notions d'objet. En pratique, tout le programme des trois ou quatre premiers jours d'une formation Python.

Ce qui ne fonctionne pas se résume à ce qui sort du bac à sable : les interfaces graphiques, la lecture et l'écriture de fichiers, les appels réseau, et les bibliothèques externes qu'il faudrait installer. Un programme qui dessine une fenêtre ou qui lit un fichier CSV a besoin d'un environnement installé.

Cette limite n'est pas un défaut de l'outil : c'est ce qui garantit que le programme d'un apprenant ne touche à rien d'autre que sa propre page.

Montrer, puis laisser faire

Une séance de code réussie alterne deux temps, et le second arrive plus tôt qu'on ne le pense. Tant que le formateur tape seul, le groupe décroche : les apprenants recopient sans réfléchir, ou attendent la fin pour commencer.

La disposition qui fonctionne le mieux donne les deux à la fois : chacun dispose de son propre éditeur et travaille dedans, tout en voyant le vôtre à côté, en direct. Vous écrivez un exemple, il apparaît chez eux ; ils s'en inspirent, l'adaptent, se trompent, recommencent — sans avoir à choisir entre regarder et faire.

Trois habitudes rendent ce dispositif plus efficace :

• Écrivez l'exemple devant eux, y compris vos erreurs de frappe. Voir un formateur corriger une faute d'indentation vaut mieux qu'un code parfait apparu d'un coup.
• Laissez-les masquer votre écran quand ils veulent se concentrer. Le but n'est pas qu'ils vous regardent, c'est qu'ils écrivent.
• Reprenez la main pour les moments clés. Un bouton qui remet tout le monde en lecture seule vaut mieux que de demander trois fois le silence.

La boucle sans fin, et les autres pièges du débutant

La première while mal écrite arrive toujours, souvent dans le premier quart d'heure. Sur un poste classique, elle fige la machine, l'apprenant panique, et vous perdez le fil de la séance pour trois minutes.

Un environnement prévu pour l'apprentissage interrompt ces programmes tout seul, au bout de quelques secondes, avec un message qui explique ce qui s'est passé. Dites-le à vos apprenants dès le début : savoir qu'ils ne peuvent rien casser les rend nettement plus audacieux, et l'audace est exactement ce qu'on cherche à ce stade.

Les autres pièges classiques se traitent par la pédagogie plus que par l'outil :

• Le message d'erreur qu'on ne lit pas. Prenez le temps de lire une erreur à voix haute, en entier, la première fois. Le réflexe se prend vite.
• La confusion entre afficher et retourner. Elle mérite un exercice à elle seule, tôt dans la progression.
• Le copier-coller sans compréhension. C'est l'argument le plus fort pour donner à chacun son propre éditeur : on copie moins facilement quand on doit faire tourner son propre programme.

Récupérer le travail de chacun

Une séance de code ne produit rien de durable si le travail disparaît à la fermeture de l'onglet. C'est pourtant ce qui arrive avec la plupart des bacs à sable en ligne, où le code vit dans le navigateur et nulle part ailleurs.

Deux usages justifient à eux seuls de récupérer les fichiers. D'abord la correction différée : relire à tête reposée ce que chacun a produit en dit plus long sur les acquis du groupe qu'un tour de salle. Ensuite la continuité : reprendre la semaine suivante là où l'apprenant s'est arrêté, plutôt que de tout recommencer.

Concrètement, chaque participant doit pouvoir télécharger son fichier avec la bonne extension, et le formateur récupérer l'ensemble du groupe d'un coup. C'est un détail d'usage qui change le rapport au travail produit : ce qui s'emporte compte.

Ce que cette approche ne remplace pas

Un éditeur en ligne est un outil de séance, pas un environnement de travail. Il serait malhonnête de laisser croire qu'il suffit à former un développeur.

Dès que la formation avance, vos apprenants doivent apprendre à installer un environnement, à utiliser un terminal, à gérer des dépendances et un gestionnaire de versions. Ces compétences font partie du métier, et les repousser trop loin rend la transition brutale.

La bonne place de l'éditeur en ligne se situe donc au début et sur les moments collectifs : les premières séances, les démonstrations, les exercices courts, les groupes sur postes verrouillés. Le reste du temps, l'installation devient elle-même un objet d'apprentissage — mais à un moment choisi, pas subi un lundi matin à 9 h 15.