Ajouter un lien GitHub en haut d’un CV de développeur est devenu un réflexe. Mais un lien n’est utile que si ce qu’il ouvre confirme ce que le CV annonce. Un profil vide, une série de forks jamais modifiés ou un projet sans README peut coûter plus cher que l’absence de lien. Cet article décrit qui clique, à quel moment, ce que regarde un lead technique en quelques minutes, et comment préparer son profil avant de le montrer, y compris quand l’essentiel de son code est privé.
Qui ouvre le lien et quand
Le lien GitHub n’est pas ouvert par tout le monde, ni au même moment du processus.
Le recruteur ou le chargé de recrutement l’ouvre rarement en détail. S’il clique, c’est pour vérifier qu’il existe, que le profil semble actif et qu’il correspond à la stack de l’offre. Un regard sur la page d’accueil du profil lui suffit : nom, photo ou avatar, quelques dépôts épinglés avec leur langage principal.
Le lead technique ou le manager l’ouvre plus souvent, généralement juste avant le premier entretien technique, pour préparer ses questions. Il passe quelques minutes sur deux ou trois dépôts, rarement plus. Il ne lit pas tout le code : il cherche des indices sur votre façon de travailler.
L’équipe, enfin, peut ouvrir un dépôt précis si vous en parlez pendant l’entretien ou si vous le proposez comme base de discussion à la place d’un exercice technique.
Il en découle une règle simple : votre profil doit être lisible en trente secondes par un non-spécialiste, et convaincant en cinq minutes pour un lead.
Les dépôts épinglés et le README de profil
Épingler ce qui vous représente
GitHub permet d’épingler jusqu’à six dépôts 🔗 en tête de profil. Ce sont presque toujours les seuls que l’on regarde. Choisissez-en deux à quatre, avec ces critères :
- un projet qui correspond à la stack du poste visé ;
- un projet abouti, qui fonctionne, avec une démonstration ou une procédure de lancement ;
- un projet récent, qui montre que vous codez encore ;
- éventuellement une contribution à un projet open source que vous avez réellement modifié.
Évitez d’épingler les exercices de cours, les tutoriels suivis à l’identique et les forks sans commit de votre part. Un lead les reconnaît très vite.
Soigner le README de chaque dépôt
Le README 🔗 est la première chose qu’un lead lit dans un dépôt. Il doit répondre en quelques lignes à cinq questions : ce que fait le projet, pourquoi vous l’avez construit, avec quelle stack, comment le lancer en local et où le voir fonctionner. Ajoutez une capture d’écran ou un schéma d’architecture si le projet s’y prête, et une section sur les choix techniques et les limites connues.
Cette dernière section est souvent la plus convaincante. « Les paiements sont simulés ; une vraie intégration demanderait une gestion des webhooks idempotente » montre que vous savez où s’arrête votre projet, ce qu’un lead apprécie beaucoup.
Le README de profil
GitHub permet aussi d’afficher un README de profil 🔗, en créant un dépôt portant votre nom d’utilisateur. Il est utile s’il reste sobre : deux ou trois lignes sur votre profil, votre stack principale, les projets à regarder en premier et un moyen de vous contacter. Les bannières animées, les compteurs de visites et les longues listes de logos de technologies n’apportent rien et donnent une impression d’amateurisme.
Ce que l’historique de commits laisse voir
Un lead qui ouvre un dépôt regarde presque toujours l’historique des commits, parce qu’il en dit long sur votre façon de travailler.
Ce qu’il cherche :
- des messages clairs qui décrivent le changement (« Ajoute la pagination à l’API des réservations ») plutôt que « fix », « update » ou « wip » répétés ;
- des commits de taille raisonnable, qui correspondent chacun à une intention, plutôt qu’un seul commit géant contenant tout le projet ;
- une progression dans le temps, qui montre que le projet a été construit et amélioré, et non déposé en une fois ;
- l’usage de branches et de pull requests, même seul, si vous voulez montrer votre pratique de la revue de code.
Ce qu’il remarque aussi, et que vous devez corriger avant d’ajouter le lien :
- des secrets versionnés : clés d’API, mots de passe, fichiers d’environnement. C’est rédhibitoire. GitHub propose une détection des secrets 🔗, mais le plus sûr est de ne jamais en committer et de révoquer immédiatement toute clé exposée ;
- des dossiers de dépendances ou des fichiers générés dans le dépôt, signe qu’aucun fichier d’exclusion n’a été configuré ;
- du code commenté en grande quantité et des fichiers inutilisés.
Le graphe de contributions, la grille verte du profil, a moins d’importance qu’on ne le croit. Un lead sait qu’un développeur en poste code surtout dans des dépôts privés. Ne cherchez pas à le remplir artificiellement.
Quand son code est privé
La plupart des développeurs confirmés ont un GitHub presque vide : leur travail appartient à leur employeur et vit dans des dépôts privés, parfois sur GitLab ou Bitbucket. Ce n’est pas un handicap, à condition de le traiter correctement.
Plusieurs options :
- ne pas mettre de lien si le profil ne montre rien. Le CV doit alors porter seul la preuve, par des expériences précises et chiffrées ;
- afficher les contributions privées dans le graphe de votre profil, une option de paramétrage 🔗 qui montre votre activité sans révéler le code ;
- publier un petit projet représentatif, construit sur votre temps personnel, qui reprend les pratiques de votre poste (tests, intégration continue, architecture) sans rien emprunter au code de votre employeur ;
- proposer en entretien de parler d’un projet en détail, schéma à l’appui, à la place de montrer le code.
N’envoyez jamais de code appartenant à un employeur actuel ou passé, même anonymisé. Un recruteur y verrait un manque de discernement sur la confidentialité.
Où placer le lien sur le CV
Le lien GitHub se place dans l’en-tête, à côté de LinkedIn et de vos coordonnées. Quelques règles pratiques :
- écrivez une URL courte et lisible, du type github.com/votre-nom, plutôt qu’un lien raccourci par un service tiers ;
- rendez-le cliquable dans le PDF, car de nombreux recruteurs lisent le CV à l’écran ;
- ajoutez des liens directs vers les dépôts dans la rubrique projets si vous en citez un en particulier ;
- vérifiez le lien juste avant l’envoi, surtout si vous avez renommé votre compte.
Le CV et le profil doivent se répondre. Si vous citez un projet personnel dans la rubrique projets, il doit être épinglé ; si vous mentionnez une technologie dans vos compétences, au moins un dépôt visible doit l’utiliser. Le modèle de CV de développeur front-end montre comment une contribution open source s’intègre en une ligne, avec un résultat vérifiable. Pour la présentation de vos technologies, voyez notre article sur la rubrique compétences d’un CV de développeur, et si vous sortez d’une formation courte, celui sur le CV après un bootcamp.
Un lien n’a de valeur que s’il est cliquable et que le reste du document est lisible. L’éditeur de TechCV conserve les liens actifs dans le PDF et produit une mise en page que les logiciels de recrutement savent lire, pour que votre lien GitHub arrive bien jusqu’au lead. Vous pouvez mettre à jour votre CV avec votre profil fraîchement nettoyé.
Questions fréquentes
Un GitHub vide peut-il nuire à ma candidature ?
Un profil vide n’est pas pénalisant en soi, surtout pour un développeur en poste dont le code est privé. Ce qui nuit, c’est un lien qui promet quelque chose et ne montre rien. Dans ce cas, mieux vaut ne pas mettre de lien et laisser le CV porter la preuve.
Faut-il un GitHub pour un poste de développeur junior ?
Ce n’est pas obligatoire, mais c’est fortement recommandé quand on a peu d’expérience professionnelle. Deux dépôts soignés, avec un README clair et des tests, remplacent en partie l’expérience que vous n’avez pas encore.
GitLab ou un portfolio personnel conviennent-ils aussi ?
Oui. Le recruteur cherche des preuves, pas une plateforme précise. Un profil GitLab public ou un portfolio qui renvoie vers le code joue le même rôle, avec les mêmes exigences de lisibilité et de README.
Combien de temps un lead passe-t-il sur un profil GitHub ?
Rarement plus de quelques minutes. C’est pourquoi les dépôts épinglés, les README et les premiers commits visibles comptent beaucoup plus que le volume total de code.