Enseigner la programmation : deux métiers, une vraie différence

Pourquoi c'est un problème de confondre les deux

Quand j'ai commencé à enseigner le développement web à MediaSchool Angoulême et à la CCI Charente, je pensais vraiment que mes annees d'experience en developpement suffiraient. Grosse erreur. Construire un site vitrine pour un plombier chauffagiste qui a besoin que ça performe, c'est tout simplement pas la même chose que d'expliquer à 20 étudiants en BTS NDRC pourquoi on utilise une boucle plutôt qu'une autre.

La confusion vient de là : on se dit que si on sait bien coder, on sait bien enseigner. C'est comme croire qu'un excellent pilote de F1 sera forcément un bon instructeur de conduite. Oui, les compétences se chevauchent, mais les objectifs? Ils sont radicalement différents.

J'ai découvert au fil du temps qu'il fallait développer deux mentalités complètement distinctes pour exceller dans chaque rôle. Les meilleurs développeurs ne sont pas toujours les meilleurs formateurs. Et inversement.

des developpeurs qui essaient de former sans preparation pedagogique ont du mal a transmettre

2 sur 3

des developpeurs qui essaient de former sans preparation pedagogique ont du mal a transmettre

plus de temps pour corriger du code d'étudiant que du code en production

3x

plus de temps pour corriger du code d'étudiant que du code en production

etudiants formes en dev web a MediaSchool et CCI Charente depuis 2024

50+

etudiants formes en dev web a MediaSchool et CCI Charente depuis 2024

• Les étudiants ont besoin de comprendre le pourquoi; les clients s'en fichent, ils veulent juste que ça marche.
• Enseigner demande de ralentir et de répéter; coder pour un client demande d'optimiser et d'innover.
• Un bug en formation est une opportunité pédagogique; un bug en production est une urgence.
• Les étudiants oublient 40% de ce qu'on leur enseigne; les clients veulent un résultat durable.

Ce que les gens font mal

J'ai vu beaucoup de développeurs se lancer dans la formation en pensant qu'il suffisait de partager ce qu'ils savaient. Ils arrivent en cours avec leur dernière stack, leurs raccourcis mentaux, et s'attendent à ce que des débutants les suivent sans problème. Résultat : confusion totale, frustration de part et d'autre, et souvent des abandons.

Il y a deux ans, j'ai discuté avec un développeur senior qui formait en React avancé à des gens en reconversion. Il leur parlait de hooks complexes, de memoization, de context API, alors qu'ils ne comprenaient pas encore les bases de JavaScript. Il était frustré que ses étudiants ne progressent pas. Je lui ai dit simplement : 'Tu codes pour toi, pas pour eux.' Ça l'a marqué.

De l'autre côté, j'ai aussi rencontré des formateurs qui construisaient des sites clients en mettant en avant la pédagogie : du code hyper commenté, des noms de variables ultra explicites, une structure parfaite. Mais lent, peu scalable, et difficile à maintenir. Ils optimisaient pour l'apprentissage, pas pour la vraie performance.

• Penser que enseigner = partager son expertise brute, sans l'adapter au niveau réel
• Coder pour un client comme si on était en formation : trop de commentaires, trop de complexité 'pédagogique'
• Ignorer que les étudiants oublient : il faut répéter, consolider, vraiment tester
• Confondre vitesse de développement et clarté pédagogique
• Croire qu'une bonne expérience client = une bonne expérience d'apprentissage

La bonne approche : enseigner la programmation avec rigueur

Après quelques années à jongler entre les deux casquettes, j'ai compris que chacun demande une discipline spécifique. Et c'est là que le truc devient intéressant : cette discipline rend l'autre meilleure.

Quand je forme mes étudiants en BTS SIO, je dois d'abord identifier leur niveau réel. Pas leur niveau supposé, leur niveau réel. Ça veut dire écouter, poser des questions, observer comment ils déboguent. Un étudiant qui dit 'je comprends' ne comprend pas forcément. Je dois vérifier. Ensuite, je construis une progression logique : HTML et CSS d'abord, puis JavaScript vanille, puis les frameworks. Pas de raccourcis. Pas de 'on verra plus tard'. Chaque brique s'appuie sur la précédente.

Quand je code pour un client, c'est l'inverse. Je sais où je vais. Je sais quels outils vont résoudre le problème le plus vite. Je ne réinvente pas la roue. Je préfère Next.js ou WordPress selon le contexte, j'utilise des composants éprouvés, je vise la performance dès le départ. Pas de temps pour les détours pédagogiques.

Mais voilà ce qui est cool : ma pratique de formateur rend mon code plus lisible et plus maintenable. Quand je construis un site pour un artisan en Charente, je sais que quelqu'un d'autre devra peut-être le reprendre un jour. Donc j'écris du code clair, bien structuré, facile à comprendre. Et ma pratique de développeur rend mes cours plus concrets. Quand j'enseigne, je peux dire à mes étudiants : 'Regarde, sur un vrai projet client, voilà comment on fait.' Pas de théorie vide. Du vrai code, des vrais enjeux.

La clé, c'est cette séparation mentale : en formation, j'optimise pour la compréhension et la progression; en freelance, j'optimise pour la performance et la durabilité. Les deux demandent de la rigueur, mais pas de la même rigueur.

• En formation : adapter votre langage au niveau de l'audience, pas l'inverse
• En freelance : préférer la clarté à la complexité, même pour du code 'simple'
• En formation : répéter, consolider, tester la compréhension réelle
• En freelance : anticiper les problèmes de maintenance et de scalabilité
• En formation : expliquer le pourquoi, pas juste le comment
• En freelance : livrer du code qui fonctionne, se charge vite, et se positionne bien (comme avec mes clients : PageSpeed 35 > 98)

Cas concret : le plombier chauffagiste de Charente

Il y a un an, j'ai travaillé sur la refonte complète du site d'un plombier chauffagiste en Charente. Son ancien site était lent, mal structuré, et ne convertissait presque pas. En tant que développeur, ma priorité était cristalline : performance, SEO, conversion. J'ai construit un site en Next.js, optimisé chaque image, structuré les données pour Google, et créé une page de devis qui convertissait vraiment.

Mais pendant que je développais, je pensais aussi comme un formateur. Je me suis demandé : 'Si je dois expliquer ce choix technique à quelqu'un, est-ce que je peux le faire simplement ?' Ça m'a poussé à faire des choix plus robustes. Au lieu d'une structure de composants complexe, j'ai gardé quelque chose de lisible et maintenable. Pas pour l'étudiant, mais pour le prochain développeur qui reprendrait le projet.

Le résultat ? Le site charge maintenant en moins de 2 secondes, se positionne sur 15 mots-clés environ, et le client a triplé ses demandes de devis. Si un jour il veut faire évoluer le site, un autre développeur peut reprendre le code sans crise de nerfs.

PageSpeed avant et après (score Lighthouse)

35 > 98

PageSpeed avant et après (score Lighthouse)

augmentation des demandes de devis en 6 mois

x3

augmentation des demandes de devis en 6 mois

temps de chargement cible atteint

2s

temps de chargement cible atteint

Par où commencer si vous êtes dans les deux mondes

Si vous êtes développeur et que vous songez à former, commencez par observer comment les gens apprennent vraiment. Pas comment vous aimeriez qu'ils apprennent. Regardez vos étudiants, écoutez leurs questions, notez où ils se perdent. Vous découvrirez que ce qui vous semble évident ne l'est vraiment pas.

Si vous êtes formateur et que vous développez pour des clients, laissez votre pédagogie de côté pendant le développement. Mais gardez-la pour la maintenabilité. Écrivez du code clair, bien structuré, facile à reprendre. C'est votre responsabilité envers le client et envers le prochain développeur.

• Séparez mentalement les deux rôles : formation = clarté et progression; freelance = performance et durabilité
• En formation, testez la compréhension réelle, pas juste la mémorisation
• En freelance, documentez vos choix techniques pour que quelqu'un d'autre puisse reprendre
• Utilisez votre expérience de formateur pour rendre votre code plus lisible; utilisez votre expérience de développeur pour rendre vos cours plus concrets