La question revient à chaque dîner de famille, posée à moitié gênée : « Et sinon, apprendre le développement web, ça sert encore à quelque chose avec l'IA qui code à ma place ? » Honnêtement, j'ai longtemps esquivé. Puis j'ai regardé ce qui se passe vraiment dans les équipes avec lesquelles je travaille, et la réponse est devenue évidente. Oui. Plus que jamais. Mais pas de la façon dont on vous le vend.
Parce que le vrai problème n'est pas d'apprendre. C'est de savoir dans quel ordre, pendant combien de temps, et avec quels projets pour que quelqu'un accepte un jour de vous payer pour ça.
Points clés à retenir
- Le socle HTML / CSS / JavaScript reste la base, mais il se traverse en 8 à 10 semaines, pas en un an.
- Un calendrier réaliste à raison de 10-12 h par semaine vous amène à un premier projet publiable en environ 4 mois.
- Le portfolio compte plus que le diplôme dans la majorité des recrutements que j'ai observés.
- Les ressources gratuites suffisent pour démarrer ; elles ne suffisent pas pour finir seul.
- Apprendre le développement web ne veut plus dire « écrire tout le code » mais « savoir ce qu'on demande à la machine et vérifier qu'elle ne raconte pas n'importe quoi ».
Un parcours pour débutant en développement web, sans le vernis des promesses
Il y a une scène que je vois se répéter. Quelqu'un s'inscrit sur trois plateformes le même week-end. Il regarde 40 vidéos. Au bout de trois semaines, il sait ce qu'est une balise <div> et il a abandonné.
Le souci n'est presque jamais la motivation. C'est l'ordre.
La plupart des débutants commencent par JavaScript parce que « c'est le langage des vrais ». Erreur classique. On se retrouve à manipuler des variables sans jamais avoir vu à quoi ressemble une page réelle dans un navigateur. Résultat : zéro feedback visuel, zéro satisfaction, abandon.
Commencez par ce qui se voit
HTML et CSS d'abord, pas parce que c'est « facile », mais parce que vous obtenez un résultat à l'écran en quelques heures. C'est bête, mais le cerveau a besoin de ça. Quand j'accompagne quelqu'un, je lui fais construire une page de profil bancale dès le jour 2. Elle est moche. Elle tient debout. Il la montre à sa sœur.
Cette petite fierté idiote, c'est le carburant des trois premiers mois.
Quand arrive JavaScript
Après 3-4 semaines de HTML/CSS seulement. À ce moment-là, vous savez déjà ce qu'est un événement sur une page, un bouton, un formulaire. Le JavaScript devient la réponse à un problème concret que vous avez déjà rencontré, pas une abstraction posée dans le vide.
Franchement, j'ai vu plus de gens réussir avec cet ordre-là qu'avec n'importe quelle « roadmap » affichée sur un forum. Ce n'est pas que la roadmap soit fausse. C'est qu'elle est trop dense pour être suivie par quelqu'un qui travaille à côté.
Un calendrier réaliste, semaine par semaine
Voici ce que je donne à quelqu'un qui a 10 à 12 heures par semaine, ce qui correspond à un salarié qui bricole le soir et une partie du week-end. C'est le rythme que je considère tenable. En dessous, ça traîne. Au-dessus, ça brûle.
| Période | Contenu | Objectif concret |
|---|---|---|
| Semaines 1-4 | HTML sémantique, CSS (flexbox, grid), responsive | Reproduire une page d'accueil simple au pixel près |
| Semaines 5-8 | JavaScript : DOM, événements, fetch, gestion d'erreurs | Une todo-list qui sauvegarde dans le navigateur |
| Semaines 9-12 | Un framework front (React ou Vue), Git, déploiement | Un projet en ligne avec une vraie URL |
| Semaines 13-20 | Back-end (Node ou PHP), bases de données, API | Une app qui lit et écrit de vraies données |
| Ensuite | Projet autonome + candidatures | Portfolio de 3 projets, CV envoyé |
Ce qu'on ne vous dit pas assez : la phase 13-20 est celle où la majorité s'arrête. Le front, c'est gratifiant. Le back, c'est là qu'on découvre les authentifications, les migrations, les variables d'environnement, et qu'on comprend que « ça marche chez moi » n'est pas une phrase anodine.
Personnellement, j'ai mis deux mois de plus que prévu sur cette phase. Je passais des soirées entières sur un problème de connexion à une base de données, à cause d'un port mal configuré. Deux mois. Un port. Aujourd'hui j'en ris, sur le moment j'ai failli tout arrêter.
Faut-il tout apprendre en gratuit ?
C'est la question qu'on me pose le plus, et j'ai une réponse qui ne va pas plaire à tout le monde.
Le gratuit fonctionne, au début
Vous pouvez apprendre HTML, CSS et les bases de JavaScript avec des ressources entièrement gratuites. La documentation MDN est excellente, vraiment. Elle est à jour, précise, sobre. Les chaînes YouTube francophones qui font des tutoriels de qualité existent aussi, et c'est un luxe qu'on n'avait pas il y a dix ans.
Le piège du gratuit n'est pas la qualité. C'est l'absence de cadre. Personne ne vous dit que vous avez sauté une étape. Personne ne vous corrige quand vous prenez une mauvaise habitude qui vous coûtera six mois plus tard.
Ce que les formations payantes apportent vraiment
- Une progression décidée par quelqu'un d'autre — indispensable quand on ne sait pas quoi apprendre ensuite.
- Des retours sur votre code. C'est le point le plus important selon moi.
- Un rythme. C'est bête mais une deadline fait plus qu'un planning théorique.
- Un réseau, qui sert surtout pour le premier poste.
Attention : notre sujet n'est pas de comparer les écoles entre elles. Ce qui compte, c'est de comprendre que le gratuit et le payant ne remplacent pas la même chose. Le premier fournit le contenu. Le second fournit le cadre et la correction.
Ma recommandation, et je l'assume : commencez en gratuit pendant un mois ou deux. Si vous tenez le rythme sans qu'on vous pousse, vous n'avez peut-être pas besoin de payer. Si vous abandonnez au bout de dix jours, le problème n'était pas le contenu — et aucune école ne réglera ça à votre place.
Quel premier projet mettre dans votre portfolio
Personne n'en parle assez, et c'est le chaînon manquant entre « j'ai appris » et « on m'embauche ».
Oubliez le clone de Netflix. C'est vu, revu, et ça montre surtout que vous savez suivre un tutoriel. Ce que les recruteurs regardent, c'est un projet qui résout un problème réel, même minuscule.
Trois exemples de projets qui fonctionnent
- Un outil de suivi de dépenses pour votre foyer, avec un formulaire d'ajout et une vue par mois. Simple dans l'idée, riche en pratique : gestion d'état, tri, persistance des données.
- Un site de recettes qui interroge une API publique (typiquement de cuisine ou météo) et gère le cas où l'API ne répond pas. Ce dernier point impressionne plus que vous ne le pensez.
- Une petite appli de prise de notes partagée, avec comptes utilisateurs. C'est le premier vrai projet « fullstack », et il montre que vous savez gérer des données sensibles.
Un détail que je vois trop souvent ignoré : écrivez une vraie page de présentation pour chaque projet. Ce que vous avez appris, ce que vous feriez différemment, pourquoi vous avez choisi telle bibliothèque. Une ligne de code sans explication, ça ne raconte rien.
Et honnêtement, un projet modeste fini vaut mieux que trois projets abandonnés à 60 %. J'ai vu des candidats refusés avec dix dépôts Git à moitié vides.
Quels langages pour quel objectif
Il faut trancher, sinon on tourne en rond.
Front, back, WordPress : trois portes d'entrée différentes
- Front-end : HTML, CSS, JavaScript, puis un framework (React ou Vue). C'est le parcours le plus direct pour quelqu'un qui aime le visuel et l'immédiat.
- Back-end : JavaScript côté serveur (Node), ou PHP, ou Python. Un peu plus lent à démarrer, plus stable à l'arrivée, et moins de concurrence sur les postes juniors.
- WordPress et l'écosystème des CMS : c'est un raccourci légitime pour entrer sur le marché. On y apprend HTML, CSS, un peu de PHP, et beaucoup de débogage. Beaucoup de freelances vivent très bien de ça, sans jamais toucher à React.
Le piège, c'est de vouloir tout faire. J'ai rencontré des profils qui se présentaient « développeur fullstack » après six mois, avec trois langages effleurés. Ils passaient moins bien en entretien que quelqu'un qui maîtrisait vraiment une seule pile.
Le développement web et mobile suit la même logique de choix : une techno, on la creuse, on livre, et on empile ensuite. Pas l'inverse.
Trois questions qu'on me pose souvent
Faut-il un diplôme pour travailler dans le développement web ?
Non, pas dans les structures que je côtoie. Ce qui est regardé, dans l'ordre : les projets concrets, la capacité à expliquer ses choix techniques, et seulement ensuite le parcours scolaire. Cela dit, un diplôme ou une certification reste utile pour passer les filtres automatiques des grandes entreprises. Dans une petite structure, personne ne vous demandera votre relevé de notes. Dans un grand groupe, le robot le fera à votre place.
Quel langage faut-il apprendre en premier ?
JavaScript si vous voulez être employable vite, parce qu'il sert à la fois dans le navigateur et côté serveur. HTML et CSS avant, évidemment, mais ils ne sont pas des langages de programmation au sens strict. Python est un excellent choix si vous visez le back ou la data, mais il n'a pas la polyvalence immédiate de JavaScript pour quelqu'un qui veut voir des résultats à l'écran.
Y a-t-il un âge pour commencer ?
Aucun, dans les deux sens. J'ai vu des reconversions à 45 ans très bien se passer, et des jeunes de 20 ans abandonner au premier blocage. Ce qui discrimine, ce n'est ni l'âge ni le diplôme : c'est la régularité. Une heure cinq jours par semaine bat trois heures un dimanche, systématiquement.
Ce que l'IA change à tout ça
Je reviens à la question du départ, parce qu'elle mérite mieux qu'une esquive.
Oui, un assistant peut générer une fonction, un composant, parfois une page entière. Ce qu'il ne fait pas : décider si la solution écrite est la bonne pour votre contexte, comprendre pourquoi votre déploiement échoue, corriger un bug qui dépend de trois lignes écrites six mois plus tôt par quelqu'un d'autre.
Le métier se déplace. Il est moins dans la frappe, plus dans la lecture, la vérification et l'arbitrage. Et ça, ça s'apprend en écrivant du code soi-même, pas en le commandant.
J'ai un ami qui a fait le raccourci inverse pendant deux ans. Son premier projet professionnel a tenu trois semaines. Pas parce qu'il ne savait pas coder — parce qu'il ne savait pas lire ce que l'IA lui avait donné.
Voilà ce que je dirais à quelqu'un qui hésite aujourd'hui : ne cherchez pas la bonne formation, cherchez le bon rythme. Le reste suit.