Todo list, calculatrice, application météo, générateur de mèmes. Les listes de projets pour débuter en frontend proposent les mêmes exercices d'un site à l'autre, et les recueils les plus repris ne font pas exception. Les titres changent, le sommaire reste identique d'une ressource à la suivante.
Un recruteur qui ouvre plusieurs portfolios de juniors dans la même journée tombe donc plusieurs fois sur les mêmes écrans. Un projet sorti du même tutoriel que celui du candidat précédent ne lui apprend rien sur la personne en face.
Ces projets partagent un défaut : leur difficulté est invisible. Une todo list soignée et une todo list bâclée se ressemblent à l'écran, et il faut ouvrir le code pour les départager. Cette lecture arrive après la première sélection, quand elle arrive.
Voici vingt projets frontend dont la difficulté se voit, qui se construisent sans serveur et sans compte à créer, avec pour chacun ce qu'il fait travailler.
Le portfolio qui ressemble à celui d'à côté
La section projets pèse lourd quand il n'y a pas encore d'expérience professionnelle à mettre en face, et c'est le sujet de l'article sur le premier projet à mettre sur un CV de développeur junior. Elle pèse d'autant plus qu'elle est souvent la seule partie que le recruteur peut évaluer par lui-même.
Depuis que les assistants de code écrivent une interface complète en quelques minutes, les projets standards se produisent à un coût presque nul. Un exercice qui demandait une semaine de travail il y a trois ans sort aujourd'hui d'une seule requête, propre et déployé. Ce qui distinguait un candidat sérieux d'un candidat pressé ne le distingue plus.
Le choix du projet devient donc la première décision technique visible. Un projet bien choisi raconte une prise de décision avant même qu'on ouvre le dépôt. Un projet mal choisi oblige à expliquer, en entretien, pourquoi il était plus difficile qu'il n'en a l'air, et cette explication arrive rarement au bon moment.
L'autre point qui joue contre les listes classiques tient à leur diffusion. Le dépôt app-ideas de Florin Pop, l'une des références les plus reprises sur le sujet, dépasse 96 000 étoiles sur GitHub au moment où ces lignes sont écrites. Une ressource à ce niveau de notoriété produit mécaniquement des milliers de portfolios comparables.
Deux critères pour choisir un projet qui tient
Premier critère : le projet se comprend sans explication. Quelqu'un qui l'ouvre voit en quelques secondes ce qu'il fait et perçoit où était la difficulté. Un ascenseur qui dessert des étages dans le désordre montre sa logique en fonctionnant. Une gestion de bibliothèque demande un paragraphe d'introduction avant de devenir intéressante.
Deuxième critère : la difficulté est logique, pas cosmétique. Une animation soignée se copie depuis un article de blog. Un algorithme de rendu de monnaie qui doit composer avec le stock réel de pièces ne se copie pas, parce qu'il dépend des règles que tu as posées.
Un test simple permet de trancher : décris le projet à quelqu'un qui ne code pas. Si la description tient en une phrase et que la personne comprend où était le travail, le critère est rempli. Si la phrase commence par une justification du type ce qui est difficile là-dedans, c'est que la difficulté ne se voit pas.
Le niveau visé ici se situe entre les deux extrêmes habituels : au-dessus de l'exercice de syntaxe, en dessous du projet fullstack avec authentification et base de données. Chacun de ces vingt projets tient dans un navigateur, sans serveur ni compte à créer, et se termine en un week-end ou deux selon le soin apporté.
Vingt projets, cinq familles
Simulations et machines à états
Ces quatre projets reposent sur un objet qui change d'état au fil du temps et des actions. La logique paraît évidente tant qu'on ne l'écrit pas.
- Un ascenseur. Une cabine, plusieurs étages, des appels qui arrivent dans le désordre. File d'attente, direction courante, ouverture des portes, et le cas de l'appel émis à l'étage qu'on vient de quitter.
- Un carrefour à feux. Deux axes, un bouton piéton, des minuteurs qui s'enchaînent. La partie délicate commence quand le piéton appuie une seconde avant le passage au vert.
- Un distributeur de boissons. Sélection, paiement en pièces, rendu de monnaie avec le stock disponible. L'approche gloutonne échoue sur certains jeux de pièces, et montrer ce cas vaut mieux que le masquer.
- Une machine à laver. Programmes, cycles enchaînés, pause en cours de route, temps restant recalculé après chaque interruption.
Interfaces à forte interaction
Ici, la difficulté vient de la manipulation directe : glisser, sélectionner, jouer en rythme. Le navigateur laisse peu de place à l'approximation.
- Un plan de table. Des invités à glisser sur des tables rondes, avec des incompatibilités déclarées qui s'allument quand deux personnes se retrouvent côte à côte.
- Un sélecteur de créneaux. Une grille horaire sur laquelle on sélectionne au glissé, avec fusion automatique des plages qui se touchent.
- Un comparateur de textes. Deux zones de saisie, les différences surlignées ligne par ligne. L'algorithme de plus longue sous-séquence commune tient en peu de lignes et se comprend en l'écrivant.
- Un séquenceur de rythme. Une grille de seize pas, quelques sons, une lecture en boucle. Le timing audio du navigateur dérive avec un simple minuteur JavaScript, et découvrir pourquoi occupe une bonne soirée.
- Une roue de tirage au sort. Rotation, décélération, arrêt sur un secteur. Facile à démarrer, exigeante sur l'animation et sur l'équité du tirage.
Données rendues lisibles
Quatre projets qui prennent un fichier en entrée et en sortent quelque chose de compréhensible. Aucun serveur, tout se passe dans le navigateur avec l'API de lecture de fichiers.
- Un lecteur de fichier GPX. Une trace de randonnée ou de vélo importée, affichée sur une carte, avec le profil altimétrique en dessous.
- Un explorateur de JSON. Une arborescence pliable construite par rendu récursif, qui reste utilisable sur un fichier de plusieurs milliers de lignes.
- Un lecteur de CSV qui devine. Le fichier est importé, chaque colonne est typée par heuristique, et le graphique proposé dépend du type détecté.
- Un classement par duels. L'utilisateur tranche entre deux options à répétition, et un score de type Elo en déduit un classement complet. Peu de code, résultat inattendu.
Algorithmes visibles à l'écran
Ces quatre-là servent à travailler l'algorithmique sans passer par une plateforme d'exercices. Le résultat se regarde, ce qui aide autant à apprendre qu'à montrer.
- Un démineur. La propagation des cases vides quand on clique sur une zone dégagée est un exercice de récursivité déguisé en jeu.
- Un solveur de Sudoku qui montre son travail. Le retour sur trace devient lisible quand on le voit poser une valeur, revenir en arrière, repartir.
- Un jeu de la vie. Une grille, quatre règles, des motifs préchargés. La difficulté se déplace vers la boucle de rendu dès que la grille grandit.
- Un quiz devine le langage. Un extrait de code coloré, quatre réponses possibles, un minuteur. Coloration syntaxique et gestion du score.
Outils que tu réutiliseras
Les trois derniers ont un avantage sur les autres : une fois terminés, ils servent. Un outil qu'on utilise soi-même finit par être maintenu, et un dépôt maintenu se remarque.
- Un testeur d'expressions régulières. Saisie du motif, surlignage en direct des correspondances et des groupes capturés.
- Un vérificateur de contrastes. Une palette en entrée, le ratio calculé selon la formule de luminance des WCAG, et une correction proposée quand une paire échoue.
- Une fiche santé de paquet npm. Le registre npm expose une API publique : date de dernière publication, dépendances, signes d'abandon.
Chacun de ces énoncés supporte une variation personnelle, et c'est souvent elle qui rend le projet mémorable. Un plan de table devient un plan de salle de classe, une roue de tirage devient un répartiteur d'astreintes, un lecteur de GPX devient un comparateur de deux sorties sur le même parcours. Cette variation coûte peu à mettre en place et donne au dépôt une raison d'exister au-delà de l'exercice.
Les pièges qui annulent le bénéfice
Un projet bien choisi peut quand même finir sans effet. Les cas les plus fréquents :
- Partir d'un corrigé. Un projet original recopié depuis le dépôt d'un autre redevient un projet standard, avec le désavantage supplémentaire de ne pas pouvoir en parler en entretien.
- En commencer huit, n'en finir aucun. Deux projets terminés et déployés valent mieux qu'une série de dépôts arrêtés au bout de trois commits.
- Soigner l'apparence avant la logique. Une interface léchée par-dessus une logique fausse se repère à la première manipulation inattendue.
- Laisser le projet en local. Un projet non déployé demande au recruteur de cloner et d'installer, ce qui n'arrive presque jamais.
- Sauter le README. Deux paragraphes sur les décisions prises et sur ce qui a coincé transforment un dépôt en preuve de raisonnement.
- Générer la totalité du code sans le relire. Un assistant écrit le squelette en quelques minutes, et la question qui suit en entretien porte toujours sur une ligne précise.
Le bug qui bloque une soirée fait partie de l'exercice, et savoir le traquer méthodiquement compte davantage que le projet lui-même. C'est le sujet de l'article sur apprendre à débugger.
Par lequel commencer
Pour un premier projet de cette liste, l'ascenseur et le démineur demandent le moins de mise en place : une grille, quelques règles, aucune dépendance externe. Le lecteur de GPX et la fiche npm supposent d'être à l'aise avec les appels réseau et les formats de données, donc plutôt en deuxième position.
Tous fonctionnent en JavaScript sans bibliothèque. Les reprendre ensuite avec un framework, une fois la logique en place, fait apparaître ce que le framework apporte et ce qu'il coûte. C'est l'ordre proposé dans la roadmap React, et l'ordre suivi en formation sur JavaScript avancé puis sur React.
Côté serveur, la logique de sélection reste la même, et les vingt propositions équivalentes se trouvent dans l'article sur les projets backend pour débutants.
Une fois le projet terminé, trois éléments suffisent à le rendre visible : une démonstration en ligne accessible en un clic, une capture animée de quelques secondes placée en haut du README, et un paragraphe qui nomme la partie difficile et la façon dont elle a été traitée. Ce paragraphe sert deux fois, sur le dépôt et à l'oral, parce qu'il oblige à formuler une décision technique en langage courant.
Un de ces vingt projets mérite un article à lui seul, avec les décisions de conception et les pièges rencontrés. Indique en commentaire le numéro que tu veux voir décortiqué, le plus demandé passera en premier.
