Je m’appelle Élise Laurent et, comme beaucoup d’étudiants et jeunes diplômés, j’ai découvert très tôt que Github n’est pas seulement un outil pour stocker du code : c’est une vitrine professionnelle. Dans cet article, je vais vous expliquer comment j’utilise Github pour valoriser mes projets d’études auprès des recruteurs, et surtout vous donner une méthode pratique pour transformer vos travaux en preuves concrètes de compétences.
Pourquoi Github intéresse les recruteurs
Quand j’ai commencé à postuler pour des stages, j’ai vite compris que les recruteurs cherchent des preuves visibles : est-ce que vous savez réellement coder ? Comment structurez-vous un projet ? Travaillez-vous en équipe ? Github répond à toutes ces questions en un coup d’œil lorsqu’il est utilisé correctement. Un profil actif, des commits réguliers, des README clairs et des démos accessibles peuvent faire la différence entre une candidature lambda et une candidature mémorable.
Commencez par soigner votre profil
Avant même de regarder vos dépôts, un recruteur va souvent jeter un œil à votre profil. Voici ce que je fais et que je vous recommande :
Ajouter une photo professionnelle et une bio courte qui indique votre spécialité (ex : « Étudiant en 3A — spécialité robotique / IA »).Personnaliser le README de profil (fichier README.md dans un repo nommé comme votre pseudo) : une courte présentation, vos compétences clés, les technologies que vous utilisez, et un lien vers votre CV ou portfolio sur https://www.nouvelingenieur.fr.Épingler 4–6 dépôts représentatifs pour orienter immédiatement le regard du lecteur.Structure d’un dépôt attractif
Un bon dépôt, c’est une expérience utilisateur : il doit être facile à lire, à cloner et à lancer. Voilà ma checklist pour chaque projet :
README clair et complet : contexte du projet, objectif, capture d’écran ou GIF, instructions d’installation, exemples d’utilisation, technologies utilisées et comment contribuer.Fichiers essentiels : LICENSE, .gitignore, et un CONTRIBUTING.md si vous souhaitez des contributions.Organisation logique : dossiers src, docs, tests, data quand c’est pertinent.Badges en tête du README : build (GitHub Actions), couverture de tests, version, licence — ils donnent immédiatement une image professionnelle.Raconter le projet, pas seulement montrer le code
Le code est important mais le récit l’est tout autant. Dans le README, je raconte :
Le problème que j’ai résolu et pourquoi il est utile.Les choix techniques et les alternatives envisagées (même brièvement).Les limitations connues et les pistes d’évolution.Cela montre que vous savez prendre du recul et que vous maîtrisez la démarche d’ingénieur.
Faites parler votre activité
Les recruteurs regardent souvent l’historique des commits et l’activité du profil. Voici comment je rends mon activité lisible et convaincante :
Commits atomiques et messages explicites : « add sorting function » est moins bon que « implement quicksort for event timestamps — O(n log n) ».Utiliser des branches pour les fonctionnalités et des Pull Requests (PR) pour les fusionner — même si vous êtes seul·e : les PRs montrent une démarche professionnelle.Garder un historique propre : rebase interactif pour regrouper des commits quand il s’agit de nettoyage avant une démonstration publique.Tests, CI et qualité
Rien n’est plus rassurant pour un recruteur qu’un projet qui se construit automatiquement. J’intègre toujours :
Un pipeline CI (GitHub Actions) qui lance les tests et les lintings.Des tests unitaires basiques pour les fonctions critiques.Un rapport de couverture (via coveralls ou codecov) si possible.Même de simples tests montrent que vous maîtrisez les bonnes pratiques.
Offrez une démo accessible
Rien ne remplace une démo. Selon le type de projet, j’utilise :
Github Pages pour héberger une démo front-end ou un site de présentation.Un lien vers une vidéo courte (hostée sur YouTube ou Vimeo) montrant le projet en action.Des releases et des binaires (ou Docker images) pour permettre au recruteur de tester sans effort.Montrez votre travail d’équipe
Si votre projet a été réalisé en groupe, documentez-le :
Décrivez le rôle de chacun dans le README.Conservez les issues, PRs et discussions : ils témoignent de votre manière de collaborer.Utilisez les commits signés et les conventions de commit (ex : Conventional Commits) pour plus de lisibilité.Utilisez les fonctionnalités de Github pour être trouvé·e
Quelques petites choses qui améliorent la découvrabilité :
Ajouter des topics (mots-clés) au dépôt : "machine-learning", "embedded", "robotics".Publier une release avec notes claires — cela montre que le projet est mature.Utiliser des templates d’issue et de PR pour structurer les contributions futures.Ce que j’évite et ce que je recommande
Avec le temps, j’ai appris à éviter certains faux-pas :
Ne pas pousser des secrets (clés API, mots de passe) — utiliser .env et instructions pour configurer localement.Ne pas laisser un README vide ou minimaliste.Ne pas multiplier de petits dépôts sans intérêt ; privilégier des projets complets ou des collections bien organisées.À l’inverse, je recommande :
Publier régulièrement, même de petites améliorations : la constance compte.Faire relire votre README par un pair pour vérifier la clarté.Ajouter une section "Comment me contacter / lien vers CV" dans le README ou le profil.Exemple de structure minimaliste d’un README
| Section | Contenu |
| Titre | Nom du projet + courte description |
| Contexte | Problème résolu et objectifs |
| Installation | Commandes pour cloner et lancer |
| Usage | Exemples d’utilisation et screenshots |
| Tests | Comment lancer la suite de tests |
| Technos | Liste des frameworks / libs |
| Contact | Lien vers profil, CV, LinkedIn |
Si vous voulez, je peux vous fournir un modèle de README prêt à l’emploi à coller dans vos projets. Dites-moi le langage/stack et je l’adapte à votre cas.
