Contribuer à un projet open source sur GitHub, c’est bien. Savoir en parler en entretien technique pour en faire une preuve concrète de compétences, c’est mieux. Dans cet article, je vous explique comment transformer votre travail sur GitHub en éléments concrets et impactants pendant un entretien : ce qu’il faut mettre en avant, comment structurer votre récit, et quels artefacts préparer pour convaincre un recruteur technique.

Choisir le bon projet (et la bonne contribution)

Tout d’abord, choisissez des contributions qui parlent à l’emploi visé. Si vous postulez comme développeur backend, mettez en avant des PR qui touchent à l’architecture, à la performance, à la conception API ou aux tests. Pour un poste en data, priorisez des notebooks, des preprocessing pipelines ou des optimisations d’algorithme.

Ne vous focalisez pas uniquement sur la taille du commit : une petite correction de bug bien choisie peut démontrer plusieurs compétences (lecture de code, tests, communication avec les mainteneurs). De mon côté, j’ai souvent préféré expliquer une série de petites PRs qui montrent constance et apprentissage progressif plutôt qu’une seule grosse PR ligne de code.

Soigner le repo et le README

Avant l’entretien, optimisez le repository que vous allez présenter. Pensez comme un recruteur qui n’a que quelques minutes :

  • README clair et orienté usage : objectif du projet, quick start, composants clés.
  • Fournir un exemple minimal pour lancer le code (docker-compose, script d’installation, ou un lien vers un démo hébergée).
  • Ajouter des badges utiles : CI (GitHub Actions), coverage, build passing, licence — ça rassure.
  • Documenter les choix techniques importants (architecture, trade-offs).

Préparer des artefacts à montrer en entretien

Il faut rendre votre travail tangible. Voici les éléments que je prépare systématiquement avant un entretien :

  • Un lien direct vers la PR la plus pertinente, avec un court résumé (1-2 phrases) de ce que j’ai fait.
  • Un diff clair à présenter (capturé en PNG si nécessaire), montrant les changements les plus significatifs.
  • Des captures d’écran de la CI verte ou des tests unitaires passant, pour prouver que le code est maintenable.
  • Si possible, une démo locale ou hébergée (Heroku, Netlify, GitHub Pages).
  • Un diagramme simple (PNG ou slide) expliquant l’impact architectural de votre contribution.

Raconter une histoire : le format que j’utilise

En entretien, j’adopte un format narratif clair et court. Voici le schéma que je recommande (et que j’utilise) :

  • Contexte : de quel projet s’agit-il ? quelle était la problématique ?
  • Rôle : qu’avez-vous fait précisément (design, implémentation, tests, doc, review) ?
  • Défi technique : quel obstacle avez-vous rencontré ? pourquoi c’était difficile ?
  • Action : quelles décisions avez-vous prises, quelles techniques/méthodes avez-vous utilisées ?
  • Résultat : métriques, temps gagné, bugs résolus, acceptation par la communauté.

Exemple condensé : “Sur le projet X (bibliothèque HTTP), j’ai corrigé une fuite mémoire causée par la réutilisation incorrecte d’un buffer. J’ai ajouté des tests de charge, isolé la cause, proposé une refactorisation et mis en place un job GitHub Actions pour surveiller la mémoire. Résultat : la consommation mémoire a été divisée par 3 sur notre benchmark, la PR a été mergeée après review.”

Quantifier l’impact (métriques et preuves)

Les chiffres parlent. Si vous pouvez fournir des métriques, faites-le :

  • Réduction du temps de build ou du temps de réponse (en % ou en ms).
  • Diminution du nombre de bugs ouverts ou du temps moyen pour merger une PR.
  • Amélioration de la couverture de tests (de X% à Y%).
  • Nombre d’utilisateurs touchés si le projet est public (téléchargements, forks, stars).

Même des mesures approximatives (avant/après local) sont mieux que rien. J’ai souvent créé un petit benchmark local et l’ai inclus dans le README pour appuyer mes dires.

Anticiper les questions techniques (et s’entraîner)

Préparez-vous aux questions de fond : pourquoi ce choix d’algorithme, pourquoi ce pattern, quelles alternatives ? J’énonce toujours les options que j’ai évaluées et pourquoi je les ai écartées — ça montre ma capacité à peser des compromis.

Entraînez-vous à expliquer un morceau de code en 2 minutes, puis en 10 minutes. Les recruteurs peuvent vouloir un pitch court ou une explication détaillée. Si vous avez utilisé des outils comme GitHub Actions, Docker, Sentry, Snyk ou Terraform, attendez-vous à des questions d’intégration ou de sécurité.

Montrer la collaboration et la communication

L’open source, c’est aussi parler aux gens. Mettez en avant :

  • Les échanges dans les issues et PR (comment vous avez reçu le feedback et amélioré la PR).
  • Les revues de code que vous avez faites pour d’autres (montre l’esprit d’équipe).
  • La gestion des conflits ou le rôle de médiation si vous en avez eu.

Je n’hésite pas à partager un extrait de conversation (anonymisé si nécessaire) qui montre que je sais défendre une solution tout en restant ouvert aux corrections.

Intégrer le projet dans votre portfolio et CV

Ne laissez pas ces contributions uniquement sur GitHub. Intégrez-les :

  • Dans votre CV : une ligne par projet avec rôle et impact chiffré.
  • Sur votre site ou portfolio : une page dédiée avec la démo, le code, le diagramme et le récit (contexte/action/résultat).
  • Sur LinkedIn : poste bref et lien vers la PR ou l’article de blog expliquant votre contribution.

Pitch court prêt à l’emploi

Voici un pitch de 30-45 secondes que j’utilise comme modèle :

“J’ai contribué au projet X, une bibliothèque de [fonctionnalité]. Mon intervention a consisté à corriger une fuite mémoire détectée en production, en ajoutant des tests et en implémentant une refactorisation du module Y. La PR a été mergeée, la consommation mémoire a baissé d’environ 60% sur nos tests, et j’ai ajouté une job CI pour éviter les régressions. Si vous voulez, je peux vous montrer la PR et le benchmark.”

Aspects pratiques : liens et préparation avant l’entretien

Avant l’entretien, envoyez — si possible — un court e-mail ou message au recruteur avec :

  • Un lien direct vers la PR principale et le README du repo.
  • 2-3 bullets expliquant votre rôle et l’impact (pratique pour le recruteur).
  • Indiquez si vous souhaitez partager votre écran pour une démo.

Enfin, testez tout : clone du repo, démarrage local, captures d’écran des commandes clés. Rien de pire que de perdre du temps pendant l’entretien à lancer un build que vous n’avez pas vérifié.