Dans la plupart des métiers, ce que l’on fait le soir et le week-end n’a pas sa place sur un CV, ou alors en une ligne dans les centres d’intérêt. Dans la tech, c’est différent : un projet personnel peut peser autant qu’une expérience professionnelle, surtout en début de carrière ou après une reconversion. Mais tous les projets ne se valent pas. Un outil réellement utilisé, une bibliothèque maintenue depuis deux ans ou un projet techniquement ambitieux attirent l’attention d’un lead ; un tutoriel recopié ou une application inachevée peuvent au contraire affaiblir une candidature. Cet article aide à trier, à décrire un projet en trois lignes et à le placer au bon endroit selon votre niveau.
Pourquoi les projets personnels comptent dans la tech
Trois raisons expliquent le poids particulier des projets personnels pour un développeur.
Ils sont vérifiables. Un recruteur ne peut pas ouvrir le code que vous avez écrit pour votre employeur. Il peut, en revanche, ouvrir un dépôt public, installer une application, essayer une démonstration en ligne. C’est une preuve rare dans un processus de recrutement.
Ils montrent ce que vous choisissez de faire. Un projet personnel révèle vos centres d’intérêt techniques, votre façon d’aborder un problème sans cahier des charges imposé et votre capacité à mener quelque chose à terme seul.
Ils comblent un manque d’expérience. Pour un étudiant, un jeune diplômé ou une personne en reconversion, un projet personnel bien construit remplace en partie l’expérience professionnelle qui manque encore. Il donne un sujet concret de discussion en entretien.
Pour un profil confirmé, leur rôle change : ils deviennent un signal de curiosité et de veille, ou la preuve d’une compétence que le poste actuel ne permet pas d’exercer.
Trier : ce qui mérite une place
Avant d’ajouter un projet, posez-vous quatre questions.
- Est-il utilisé ? Par vous au quotidien, par des proches, par une association, par des inconnus qui l’ont téléchargé. Un projet qui sert à quelqu’un a une histoire à raconter : des retours, des corrections, des évolutions.
- Est-il maintenu ? Un projet mis à jour récemment, avec des dépendances à jour et des corrections régulières, montre une pratique dans la durée. Un projet abandonné depuis longtemps dit l’inverse.
- Est-il techniquement intéressant ? Il ne s’agit pas d’être spectaculaire, mais de comporter au moins une difficulté réelle : un problème de performance, une synchronisation hors ligne, une intégration complexe, un traitement de données volumineux, un algorithme non trivial.
- Est-il en lien avec le poste visé ? Un projet mobile pour un poste mobile, une API pour un poste backend, un pipeline de données pour un poste data. Un projet sans lien peut rester, mais il passe après.
Un projet qui répond « oui » à au moins deux de ces questions mérite une place. Un projet qui ne répond oui à aucune doit sortir du CV, même s’il vous a beaucoup appris.
En pratique, deux ou trois projets suffisent. Au-delà, la rubrique devient une liste que personne ne lit.
Décrire un projet en trois lignes
Un projet se décrit comme une expérience, en plus court. Trois éléments suffisent : ce que fait le projet et pour qui, la stack et la difficulté technique, un résultat ou un usage.
Avant : « Application de gestion de tâches en React. »
Après : « Application de suivi des entraînements pour un club d’athlétisme (React Native, Supabase), utilisée chaque semaine par les entraîneurs et une cinquantaine d’athlètes ; synchronisation hors ligne pour les stades sans réseau ; publiée sur les deux stores. »
Avant : « Contribution open source. »
Après : « Contributions à une bibliothèque Python de validation de données : correction de deux anomalies de gestion des fuseaux horaires et ajout d’un validateur, acceptés par les mainteneurs après revue. »
Avant : « Bot Discord. »
Après : « Bot de notification des mises en production pour une communauté de développeurs (TypeScript, API Discord, webhooks GitHub) : architecture à base de files de messages, tests d’intégration, déployé sur un service managé depuis un an. »
Chaque version réécrite donne au lecteur une raison de s’arrêter : un usage réel, une difficulté nommée, une durée. Ajoutez un lien vers le code ou la démonstration, et vérifiez qu’il mène à un dépôt propre, comme l’explique notre article sur le lien GitHub dans un CV.
Où placer la rubrique selon son niveau
La place de la rubrique projets dépend de ce que vous avez à montrer par ailleurs.
- Étudiant ou jeune diplômé : la rubrique projets se place juste après la formation, voire avant si vos projets sont plus convaincants que vos stages. Elle peut contenir le projet de fin d’études, un projet de groupe marquant et un projet personnel.
- Après une reconversion ou un bootcamp : les projets se placent en haut de page, après l’accroche et la formation, car ils portent la preuve de vos compétences. Notre article sur le CV après un bootcamp détaille l’importance du projet poursuivi après la formation.
- Développeur confirmé : les projets passent en fin de CV, dans une rubrique « Projets et open source » ou « Autres activités », en une ou deux lignes. Ils complètent le profil sans concurrencer les expériences.
- Profil senior : un projet personnel ne figure que s’il est significatif (une bibliothèque utilisée par d’autres, une contribution notable à un projet connu) ou s’il prouve une compétence absente du parcours professionnel.
Le modèle de CV de développeur mobile montre un développeur confirmé qui garde, en rubrique dédiée, une application personnelle publiée et maintenue à chaque version du système : une ligne, mais une preuve forte pour un poste mobile.
Les projets qui font plus de mal que de bien
Certains projets affaiblissent une candidature au lieu de la renforcer.
- Les tutoriels recopiés à l’identique : liste de tâches, clone d’un réseau social, application météo suivant un cours en ligne. Un lead les reconnaît immédiatement et en conclut que vous n’avez pas encore construit quelque chose de vous-même.
- Les projets inachevés sans mention de leur état : une application qui ne démarre pas, un lien de démonstration cassé, un README vide.
- Les projets qui contredisent le CV : une rubrique compétences qui annonce TypeScript et des tests, et un projet en JavaScript sans aucun test.
- Les projets à risque : outils qui contournent les conditions d’utilisation d’un service, collecte de données personnelles sans précaution, code d’un employeur réutilisé. Ils posent une question de jugement.
- Les projets trop nombreux : une liste de dix projets dilue les deux qui comptent.
Un projet inachevé n’est pas forcément à supprimer : il peut rester si vous indiquez honnêtement où il en est et ce que vous en avez appris. C’est la promesse non tenue qui gêne, pas l’inachèvement.
Pour un premier poste, ces projets font souvent la différence entre deux candidatures, comme le rappelle notre article sur le premier emploi de développeur.
Une rubrique projets bien triée doit encore être lisible : liens visibles en toutes lettres, technologies en texte et non en logos, mise en page sans colonnes. L’éditeur de TechCV s’en charge et produit un PDF dont les logiciels de recrutement extraient correctement chaque projet. Vous pouvez ajouter vos projets à votre CV en quelques minutes.
Questions fréquentes
Combien de projets personnels mettre sur un CV ?
Deux ou trois, rarement plus. Choisissez ceux qui sont utilisés, maintenus, techniquement intéressants ou en lien direct avec le poste. Les autres peuvent rester visibles sur votre GitHub sans figurer sur le CV.
Un projet de cours peut-il figurer dans la rubrique projets ?
Oui, s’il est significatif (projet de fin d’études, projet de groupe ambitieux) et que vous précisez votre rôle. Les exercices identiques pour toute une promotion ont moins d’intérêt.
Faut-il un projet personnel quand on a déjà de l’expérience ?
Ce n’est pas indispensable. Pour un développeur confirmé, l’expérience professionnelle porte l’essentiel de la preuve. Un projet personnel reste utile pour montrer une compétence que vous ne pratiquez pas au travail, ou pour accompagner une réorientation.
Comment présenter un projet qui a des utilisateurs mais peu de code public ?
Décrivez l’usage, la stack et la difficulté technique, puis proposez une démonstration ou un échange en entretien. Si le code est privé, un schéma d’architecture dans un document public peut remplacer le dépôt.