Choisir ses projets, soigner les README, structurer un portfolio : comment montrer votre travail aux recruteurs, même en début de carrière.
Un CV affirme, un projet montre. Quand un recruteur hésite entre deux profils proches, ou quand un responsable technique prépare un entretien, un lien vers du code ou une démonstration qui fonctionne apporte une information qu'aucune ligne de CV ne remplace : votre façon de structurer un projet, de nommer les choses, de documenter et de terminer ce que vous commencez. Encore faut-il que ce que l'on découvre en cliquant soit présentable.
Ce que regarde vraiment la personne qui ouvre votre lien
Ne comptez pas sur une lecture ligne à ligne de vos dépôts. Le parcours ressemble plutôt à ceci : la page de profil, les projets mis en avant, le README du projet le plus prometteur, puis un ou deux fichiers de code ouverts presque au hasard. Un responsable technique ira plus loin, mais en général après un premier tri. Ce qui compte, c'est donc :
- un profil qui dit en une phrase qui vous êtes et ce que vous faites ;
- quelques projets mis en avant, choisis plutôt que subis ;
- des README qui expliquent le projet sans qu'il faille lire le code ;
- un code propre là où l'on clique en premier.
Choisir ses projets : moins, mais mieux
GitHub permet d'épingler jusqu'à six dépôts en haut de votre profil. Utilisez cet espace comme une vitrine composée avec soin, et non comme un reflet automatique de votre activité récente. Un bon ensemble comprend :
- un projet principal abouti, proche du poste visé : une application web complète avec authentification et base de données pour un poste full stack, une application mobile installable pour un poste mobile, un pipeline de données documenté pour un poste data ;
- un ou deux projets plus courts qui démontrent une compétence précise : une API bien testée, un script d'automatisation utile, un tableau de bord ;
- une contribution à un projet existant si vous en avez une, même modeste : une correction de documentation ou un petit correctif accepté par les mainteneurs.
Les exercices de cours copiés d'un tutoriel, les dépôts vides et les forks jamais modifiés n'ont pas à être mis en avant. Vous pouvez les archiver ou les passer en privé.
Un projet n'a pas besoin d'être spectaculaire pour intéresser. Une application de réservation pour le club de sport de votre quartier, un outil qui compare des horaires de transport, un petit service qui récupère et résume des données publiques : un vrai problème, même modeste, retient davantage l'attention qu'une énième copie d'une application célèbre sans rien de personnel.
Le README, porte d'entrée de chaque projet
Un bon README répond aux questions du visiteur avant qu'il ne les pose. Voici une trame que vous pouvez reprendre pour chacun de vos projets :
- Titre et phrase de description : ce que fait le projet, et pour qui.
- Capture d'écran ou lien de démonstration : le moyen le plus rapide de montrer le résultat.
- Fonctionnalités principales : quelques puces, pas davantage.
- Stack technique : langages, frameworks, base de données, hébergement.
- Installation et lancement : les commandes exactes, vérifiées sur une machine où le projet n'a jamais tourné.
- Choix techniques et limites : pourquoi telle architecture, ce que vous amélioreriez avec plus de temps.
- Votre rôle : indispensable pour un projet de groupe, un projet de fin d'études ou un hackathon.
La rubrique « choix techniques et limites » est souvent la plus convaincante. Une phrase comme « La recherche est pour l'instant filtrée côté client ; avec un catalogue plus important, il faudrait la déplacer côté serveur et paginer les résultats » montre du recul. Elle prépare aussi une excellente discussion pour l'entretien technique.
Un code qui donne envie d'aller plus loin
Personne n'attend un code parfait. On cherche en revanche quelques signaux de sérieux :
- des noms de variables et de fonctions explicites, en anglais de préférence ;
- une organisation des dossiers logique et conforme aux habitudes du framework utilisé ;
- aucun mot de passe, aucune clé d'API ni aucun fichier .env poussé dans le dépôt, même supprimé ensuite, car il reste dans l'historique ;
- un fichier .gitignore qui exclut les dépendances et les fichiers générés ;
- quelques tests, même peu nombreux, et si possible une intégration continue qui les exécute ;
- des messages de commit qui décrivent le changement, comme « Ajoute la pagination à la liste des produits », plutôt que « fix » ou « update ».
Le point sur les secrets mérite d'insister : une clé exposée dans un dépôt public est un signal très négatif, en particulier si vous visez un poste en DevOps ou en cybersécurité.
Soigner la page de profil GitHub
Renseignez votre nom, une photo, une ligne de présentation et votre ville. GitHub permet aussi d'afficher un README de profil en haut de votre page : quelques lignes sur votre métier, vos technologies et un lien vers votre portfolio ou votre LinkedIn suffisent. Évitez d'y empiler badges et statistiques générées automatiquement, qui prennent de la place sans rien dire de votre travail.
Quant au calendrier des contributions, ne vous en inquiétez pas outre mesure. Beaucoup de très bons développeurs ont un calendrier presque vide parce que leur travail se fait sur des dépôts privés d'entreprise, et un recruteur averti le sait.
Portfolio : pour qui, et sous quelle forme ?
Un site portfolio n'est pas indispensable pour tous les profils. Selon votre métier, il prend des formes différentes :
- Design UX/UI : c'est le support principal de votre candidature. Présentez quelques études de cas complètes : le problème, la recherche utilisateur, les itérations, la solution retenue, ce que vous avez appris. Le processus compte autant que les écrans finaux.
- Développement front-end et mobile : le site lui-même devient une démonstration. Il doit être rapide, accessible et irréprochable sur téléphone.
- Data et intelligence artificielle : des notebooks propres et commentés, un tableau de bord publié, ou une analyse expliquée de bout en bout, des données brutes jusqu'aux conclusions.
- DevOps, systèmes et cybersécurité : le code applicatif compte moins que des dépôts d'infrastructure (scripts, configurations, pipelines), des comptes rendus de laboratoire ou des rapports de challenges de sécurité rédigés après coup, toujours dans un cadre légal.
Si vous visez le design, parcourez les offres en design UX/UI : les outils et méthodes qu'elles citent vous aideront à choisir les études de cas à mettre en avant.
Quand votre meilleur travail est confidentiel
C'est le cas de nombreux développeurs en société de services ou en centre offshore : le code appartient au client. Ne publiez jamais un code d'entreprise sans autorisation écrite. À la place :
- décrivez ces projets dans votre CV ou votre portfolio, sans aucune donnée sensible : contexte, problème, approche, résultat ;
- recréez un petit projet personnel qui reproduit une technique maîtrisée au travail, comme une architecture, un mécanisme de cache ou une chaîne de déploiement ;
- préparez-vous à en parler en entretien, schéma à l'appui si besoin.
Prenez quelques heures ce week-end pour faire le tri : choisissez les projets à épingler, réécrivez leurs README selon la trame ci-dessus et vérifiez qu'aucun secret ne traîne dans l'historique. Ajoutez ensuite le lien vers votre GitHub ou votre portfolio en haut de votre CV, puis parcourez les offres d'emploi IT pour repérer les compétences que vos projets doivent mettre en valeur.