Tu postules comme développeur ? Voici comment montrer sur GitHub ce que tu sais faire : choisir un projet utile, expliquer ton code, montrer une démo et répondre aux questions d’un recruteur.
Les points clés de l’analyse, vérifiés par la rédaction.
Un dépôt utile permet de comprendre le problème, lancer le projet et vérifier une partie de son comportement.
Un projet pédagogique doit être présenté comme tel ; les résultats professionnels et les métriques doivent rester vérifiables.
L’usage d’une IA n’enlève pas la responsabilité de comprendre, tester et expliquer le code livré.
« Une promesse ouvre la porte ; une preuve donne envie de te confier les clés. »
Imagine une candidature qui annonce Python, React, cloud et automatisation. Le lien GitHub est bien là, mais derrière, les dépôts portent encore les noms des tutoriels suivis, les installations échouent et personne ne comprend ce qui a réellement été construit. Le problème ne vient pas de la longueur du CV : le lecteur manque de preuves pour relier les compétences annoncées à un travail observable.
Chez nous, où beaucoup de jeunes développeurs apprennent aussi en dehors des cursus, le portfolio peut rendre cet apprentissage visible. Il faut cependant lui donner une fonction précise : permettre à quelqu’un d’évaluer une contribution, pas simplement montrer qu’on a passé du temps devant un éditeur.
Le marché des compétences bouge ; ton dossier doit rester lisible
Dans sa synthèse du Future of Jobs Report 2025, le Forum économique mondial rapporte que 85 % des employeurs interrogés envisagent de former leurs équipes et 70 % de recruter des personnes disposant de nouvelles compétences d’ici 2030. Ce sont des intentions mondiales, pas une prévision de ton prochain entretien à Douala.
Ce que les employeurs interrogés prévoient pour leurs compétences
Intentions mondiales pour 2025–2030 : ces deux réponses peuvent se recouper et ne doivent pas être additionnées. Elles ne mesurent ni les chances d’embauche d’un candidat ni le marché camerounais.
L’enseignement que nous en tirons est pratique : annoncer une compétence récente devient plus utile quand on peut montrer comment on l’applique. Cela ne garantit aucun recrutement, car le diplôme, l’expérience, les critères du poste et les conditions d’embauche continuent de compter.
Choisis un problème que quelqu’un peut comprendre
Prenons un exemple fictif : un petit atelier veut suivre ses interventions. Il reçoit des demandes, attribue des tâches et cherche ce qui reste à terminer. Une application de suivi peut servir de projet pédagogique, à condition d’expliquer ce que la démonstration couvre réellement.
Le lecteur doit pouvoir identifier l’utilisateur, la difficulté rencontrée et le résultat attendu. Ajouter vingt fonctionnalités avant de clarifier ce point rend surtout le projet plus difficile à évaluer. Une fonction modeste, correctement menée jusqu’au bout, révèle déjà beaucoup : comment tu modèles les données, comment tu traites une erreur et comment tu empêches une action incohérente.
Si tu as réalisé ce projet pour un vrai utilisateur, précise ton rôle. Si c’est une simulation, dis-le. Un projet de formation bien expliqué a une valeur ; lui inventer un client ou un impact mesuré détruit la confiance que tu cherches à construire.
Fais du dépôt un passage de relais
La documentation de GitHub consacrée au CV recommande de sélectionner quelques projets et de les rendre faciles à explorer. Dans notre exemple, cela commence par une explication qui répond aux questions d’un autre développeur.
Quelles versions faut-il installer ? Comment configurer les variables sans partager de secret ? Comment initialiser des données de démonstration ? Quel scénario permet de vérifier que l’application répond au problème annoncé ? Le README doit aider quelqu’un à franchir ces étapes avec des instructions reproductibles.
Ajoute une capture représentative ou une courte démonstration, puis indique les limites actuelles. Si l’envoi de SMS est simulé, écris-le. Si l’application ne gère pas encore deux modifications simultanées, explique ce que cela implique. La transparence permet au lecteur de distinguer ce qui fonctionne de ce qui reste à construire.
Montre une décision, puis son coût
Un framework connu ne raconte pas, à lui seul, ton raisonnement. Une courte note peut expliquer pourquoi tu as choisi une base relationnelle, ce que le modèle empêche ou comment tu distingues une erreur utilisateur d’une panne du serveur.
Tu peux aussi montrer un changement précis : une ancienne requête chargeait toutes les interventions, la nouvelle récupère une page à la fois. Décris le scénario et la méthode de vérification. Si tu annonces un gain de performance, garde le protocole, les conditions et les mesures ; sans cela, le chiffre ressemble davantage à une décoration qu’à une preuve.
Les tests intéressants protègent un comportement qui compte pour l’utilisateur. Par exemple, une intervention terminée ne doit pas redevenir active par une action non autorisée. Choisis quelques cas qui révèlent le fonctionnement du système, au lieu de multiplier les tests qui répètent simplement le code.
L’IA peut accélérer le travail ; elle ne passe pas l’entretien à ta place
Tu peux utiliser une IA pour explorer une solution, écrire un premier jet ou chercher une erreur. La question professionnelle reste ce que tu as vérifié et ce que tu sais expliquer. Un dépôt qui fonctionne uniquement tant que l’assistant fournit la prochaine instruction laisse une dépendance visible.
Garde une trace de tes décisions et vérifie les morceaux sensibles : droits d’accès, entrées invalides, dépendances et exposition des secrets. Si un outil t’a aidé, présenter cet usage avec honnêteté peut ouvrir une discussion utile sur ta méthode. La contribution doit rester identifiable : ce que tu as demandé, compris, corrigé et validé.
Protéger le travail professionnel fait aussi partie de la preuve
Le code de ton employeur, ses données et ses accès ne deviennent pas publics parce qu’ils enrichiraient ton portfolio. Demande les autorisations nécessaires. À défaut, construis une démonstration indépendante avec des données fictives et décris ton rôle sans reproduire des éléments confidentiels.
Cette contrainte peut améliorer la présentation : elle t’oblige à montrer la compétence transférable, plutôt qu’à exposer un système auquel tu as simplement eu accès.
Prépare une visite, pas une exposition de badges
À la prochaine candidature, choisis un projet adapté au poste et prépare un parcours court : le problème, une démonstration, une décision et une limite. Vérifie les instructions sur un environnement propre avant de partager le lien.
Ton portfolio n’a pas besoin de raconter une carrière que tu n’as pas encore. Il doit permettre à une personne de voir comment tu travailles aujourd’hui et ce qu’elle pourrait raisonnablement te confier demain.
Visuel de couverture : illustration générée par IA. L’exemple de l’atelier est fictif ; les conseils de méthode relèvent de l’analyse éditoriale de Trigenys Insight.
Questions fréquentes
Faut-il beaucoup de projets sur GitHub ?
La sélection compte davantage que l’accumulation. Quelques projets compréhensibles et pertinents pour le poste permettent de montrer un travail plus précis.
Peut-on montrer un projet réalisé au travail ?
Seulement avec les autorisations nécessaires. Sinon, créer une démonstration distincte avec des données fictives et décrire sa contribution sans exposer le code ou les informations de l’employeur.
Sources et méthode
Les faits susceptibles d'évoluer ont été revérifiés dans les sources ci-dessous. Les observations et interprétations sont présentées comme telles dans l'article.
