Stages, freelance ou open source : que mettre en avant

Mettez en avant le stage, la mission freelance ou la contribution open source qui démontre le mieux le travail attendu dans le poste visé, quel que soit le libellé qui semble le plus impressionnant. Un stage peut montrer votre capacité à travailler selon les processus d'une équipe, le travail freelance peut montrer votre autonomie dans la livraison à un client, et l'open source peut montrer une contribution vérifiable dans un projet partagé. Décrivez la tâche, votre action personnelle, le livrable et le contexte. Ne présentez pas une mission proposée, une pull request non fusionnée ou un exercice non rémunéré comme un travail client ou de production terminé.

Comparez les preuves, pas le prestige

Il n'existe pas de classement universel dans lequel chaque stage vaut mieux que chaque projet freelance, ou chaque contribution open source vaut mieux qu'un devoir de cours. Un court stage composé principalement d'observation peut fournir moins de preuves pertinentes qu'un livrable client finalisé. Une contribution de code importante et acceptée peut être plus forte qu'une tâche freelance sans lien avec le poste. Le poste ciblé détermine quel exemple mérite votre attention.

Posez-vous quatre questions pour chaque expérience : à quel point le travail correspondait-il à la tâche visée ? Qu'avez-vous personnellement décidé ou livré ? Quelqu'un peut-il vérifier ou examiner le résultat ? Quel contexte ou quelles contraintes rendaient ce travail significatif ? Utilisez ces réponses pour choisir l'ordre des rubriques et l'espace accordé à chaque puce.

Le glossaire de l'expérience professionnelle explique que l'emploi n'est pas la seule source de travail pertinent. Le libellé reste important, car les employeurs doivent comprendre si le travail était encadré, en contact avec un client, public, rémunéré ou autonome.

Étape 1 : Décrivez ce que chaque contexte peut démontrer

Les stages peuvent démontrer votre capacité à travailler au sein d'une organisation : répondre à un responsable, utiliser les outils de l'équipe, suivre des procédures et contribuer à de vraies échéances. Leur valeur dépend du travail réalisé, pas seulement du titre. Si votre stage comprenait des notes de recherche et une recommandation, décrivez ces livrables. S'il s'agissait surtout d'observation, indiquez ce que vous avez réellement appris ou aidé à faire plutôt que d'inventer des responsabilités.

Le travail freelance peut démontrer la définition du périmètre, la communication avec les clients, la livraison et les révisions. Il peut aussi révéler votre capacité à travailler avec des ressources limitées. Un contrat rémunéré reste soumis à la confidentialité et aux autorisations. Si vous avez créé un exemple pour un client potentiel qui n'a jamais été commandé, présentez-le comme une proposition ou un projet indépendant, et non comme une mission client.

Le travail open source peut démontrer votre capacité à travailler dans une base de code partagée, à répondre aux revues, à rédiger de la documentation, à créer des tests ou à assurer la maintenance. Une contribution fusionnée est facile à lier, mais un rapport de bug utile, une modification de documentation ou une proposition examinée peuvent également démontrer votre jugement. Indiquez précisément le statut. Une pull request non fusionnée est un travail que vous avez tenté, pas une fonctionnalité de production.

Étape 2 : Choisissez l'exemple le plus fort pour cette candidature

Lisez les principales responsabilités du poste. Un poste junior en développement logiciel qui met l'accent sur la collaboration et la revue de code peut valoriser une petite correction fusionnée avec un fil de discussion clair. Un poste en design impliquant la découverte des besoins clients peut valoriser un projet freelance avec un brief réel, des révisions et un livrable que vous avez l'autorisation de montrer. Un poste d'assistant de recherche peut valoriser un stage où vous avez suivi un protocole et documenté les données avec soin.

Créez une note de preuve en trois lignes pour chaque exemple potentiel : exigence du poste visé, mon action, preuve disponible. Si vous ne pouvez pas expliquer votre action ou montrer une quelconque preuve, demandez-vous si un autre exemple serait plus solide. N'utilisez pas un classement numérique qui prétend que différents employeurs accordent exactement la même valeur aux mêmes signaux.

Exemple : candidature en ingénierie logicielle. Un étudiant a effectué un stage durant lequel il a assisté aux réunions de planification, mais n'a pas modifié la base de code. Il a également soumis une correction de documentation à une bibliothèque open source, qu'un mainteneur a examinée et fusionnée. Pour un poste qui valorise une rédaction technique claire et la collaboration, la contribution fusionnée peut mériter une puce visible et un lien. Le stage peut toujours montrer une exposition aux routines d'équipe, mais le candidat ne doit pas prétendre y avoir livré du code.

Exemple : candidature au poste de coordinateur marketing. Un étudiant a réalisé une mission freelance de newsletter pour une association locale, avec un brief, deux cycles de révision et une newsletter finale qu'il est autorisé à montrer. Il a également participé à un court stage avec peu de rédaction directe. Pour un poste exigeant de la rédaction d'e-mails et des retours de parties prenantes, la mission freelance peut être l'exemple principal le plus fort. Le candidat doit décrire le client réel et le périmètre réel sans laisser entendre que la newsletter a, à elle seule, produit un résultat de collecte de fonds non mesuré.

Étape 3 : Donnez à chaque expérience un libellé exact sur votre CV

Utilisez le vrai nom de l'employeur ou du projet, votre rôle, les dates et le contexte. Un stage doit figurer sous Expérience avec « Stagiaire » dans le titre si c'est ainsi que l'employeur l'appelait. Le travail freelance peut être indiqué sous Expérience ou Projets selon le périmètre, en précisant clairement « Freelance » ou « Contrat ». Le travail open source peut trouver sa place sous Projets ou Contributions, en particulier lorsque plusieurs petites modifications concernent un même projet.

Ne masquez pas la différence en donnant à chaque entrée un titre au ton corporate. « Contributeur indépendant » peut être exact pour l'open source, mais le lecteur doit tout de même savoir que le projet était maintenu par la communauté. De même, un site web freelance pour un seul client n'est pas un poste de « Head of Web Strategy », à moins que cela corresponde réellement au périmètre contractuel.

Soyez précis sur les résultats de groupe. Si trois stagiaires ont travaillé sur un rapport, décrivez la section que vous avez étudiée ou l'analyse que vous avez réalisée. Si un mainteneur a modifié votre solution proposée pendant la revue, mentionnez le processus de revue et indiquez ce qui a été fusionné. Si un client a fourni le design et que vous l'avez implémenté, ne présentez pas ce design comme le vôtre.

Vous pouvez regrouper plusieurs petites missions sous une seule entrée freelance clairement nommée, mais donnez à une tâche client représentative sa propre puce lorsqu'elle démontre la compétence visée. Pour l'open source, une entrée Contributions ou Projets peut regrouper documentation, triage d'issues et code au sein du même projet. Ne rassemblez pas des statuts différents dans une seule affirmation telle que « livré des fonctionnalités » si l'un des éléments n'a été que proposé. Un lecteur doit pouvoir relier chaque affirmation à un artefact réel ou à une explication.

Si un stage et une mission freelance ont eu lieu pendant la même période, conservez leurs dates réelles. Les chevauchements sont normaux pour les étudiants. Il n'est pas nécessaire de les dissimuler avec une chronologie vague. Lorsqu'un rôle était à temps partiel ou occasionnel, dites-le si le périmètre pourrait autrement laisser croire à un emploi à temps plein. Des libellés exacts rendent les parties les plus solides de votre travail plus crédibles.

Étape 4 : Rédigez des puces montrant la tâche, la contribution et le résultat

Un employeur a besoin de plus que du contexte. Commencez par votre action, indiquez la méthode ou l'outil lorsque c'est pertinent, puis identifiez le livrable ou le résultat observable. Un résultat peut être un document finalisé, une modification acceptée, une page fonctionnelle, une transmission claire ou l'approbation du client. Utilisez une métrique uniquement si vous en connaissez la source et ce qu'elle mesure.

Puces de stage : « Documenté les questions récurrentes du support et rédigé des mises à jour du centre d'aide pour validation par le responsable. » Cette formulation distingue la rédaction de l'approbation finale et montre un livrable réel.

Puces freelance : « Créé une newsletter à partir d'un brief client, révisé le texte après deux cycles de revue et livré la version approuvée. » Utilisez le nombre uniquement si c'est bien ce qui s'est produit ; sinon, dites « après les retours du client ».

Puces open source : « Mis à jour les instructions d'installation d'une bibliothèque communautaire et intégré les retours du mainteneur avant la fusion de la modification. » Si elle n'a pas été fusionnée, remplacez la dernière partie par le statut réel. Le guide des puces de CV percutantes traite plus en détail de l'action, du contexte et des preuves.

Étape 5 : Fournissez des preuves sans exposer de contenu privé

Une pull request publique ou un lien vers de la documentation peut étayer des affirmations sur l'open source. Un exemple freelance peut nécessiter l'autorisation du client. Un livrable de stage peut être confidentiel même si vous l'avez rédigé. Ne mettez pas en ligne de données, de code, de designs ou de documents internes privés simplement pour renforcer votre portfolio. Une brève explication du travail, dont les détails sensibles ont été supprimés, peut tout de même démontrer votre méthode.

Le guide des preuves de travail est destiné aux personnes en reconversion, mais ses principes de libellé des projets et de confidentialité s'appliquent aussi ici. Si vous avez besoin d'un site partageable pour des exemples approuvés, les modèles de site personnel Democruit offrent un espace pour présenter des travaux sélectionnés. Le site ne doit pas servir à laisser entendre une approbation client que vous n'avez pas reçue.

Pour un rapport de stage privé, vous pouvez décrire le problème, votre méthode et votre section spécifique sans copier le rapport ni nommer l'organisation. Pour un design client, demandez si vous pouvez montrer une image finale, un résumé anonymisé du processus, ou ni l'un ni l'autre. Pour une pull request open source, vérifiez le fil public avant de créer un lien : les commentaires de revue peuvent constituer une preuve utile de votre façon de répondre, tandis qu'une proposition abandonnée peut exiger une courte explication de ce qui s'est passé. N'utilisez jamais un lien public comme substitut à l'explication de votre contribution dans le CV lui-même.

Pour les candidatures à un stage, le guide du CV de stage montre comment les cours et les éléments liés au campus peuvent côtoyer l'expérience professionnelle. Si une lettre est demandée, le scénario de lettre de motivation pour un stage peut vous aider à expliquer pourquoi un projet particulier correspond à la tâche de l'employeur sans répéter votre CV.

Lorsqu'aucun des trois exemples ne correspond exactement

Une offre de débutant peut demander un travail que vous n'avez réalisé dans aucun contexte. Choisissez la tâche la plus proche que vous pouvez expliquer et nommez la différence. Si le poste implique la revue de code de production, un dépôt de cours revu peut montrer votre réaction aux retours, mais il ne prouve pas la maintenance en production. Si le poste implique la gestion de comptes clients, une révision de design freelance peut montrer votre communication client, mais elle ne prouve pas que vous avez assuré le suivi continu d'un compte. Cette limite aide l'employeur à évaluer la formation dont vous auriez besoin.

Vous pouvez aussi combiner des preuves issues de différents contextes sans obliger un seul exemple à couvrir toutes les exigences. Un stage peut montrer les routines d'équipe, un projet freelance peut montrer un livrable finalisé et une contribution open source peut montrer une revue publique. Dans une lettre de motivation ou un entretien, reliez-les au poste en une courte explication. Sur le CV, laissez chaque entrée remplir son propre rôle : titre factuel, tâche précise, votre contribution et statut. Trop de puces répétées sur la « collaboration » font paraître identiques trois expériences pourtant variées.

Si l'opportunité était brève, indiquez ce qui a été réalisé pendant cette période. Une contribution d'une journée n'a pas besoin d'un titre grandiloquent, mais une correction soigneusement documentée peut rester pertinente. Si le travail s'est terminé sans livrable, un compte rendu concis de la recherche, de la proposition ou de la transmission peut constituer une preuve honnête. Omettez-le si vous ne pouvez pas identifier une contribution ou répondre à une question de suivi sur le processus.

Erreurs fréquentes et comment les corriger

1. Commencer par le libellé le plus prestigieux. Cela peut cacher un livrable plus pertinent. Commencez par l'exemple qui répond le mieux aux exigences du poste.
2. Revendiquer l'intégralité du résultat de l'équipe de stage. Distinguez votre action du travail de l'équipe et de toute approbation du responsable.
3. Présenter une proposition comme un contrat freelance. Indiquez que le travail non commandé est une proposition ou un exemple indépendant.
4. Appeler une modification non fusionnée une fonctionnalité livrée. Précisez si elle a été proposée, examinée, acceptée ou fusionnée.
5. Publier du contenu privé. Obtenez une autorisation ou utilisez une description sûre et un exemple approuvé.
6. Lister des outils sans décrire la tâche. Le nom d'un outil seul en dit peu. Montrez ce que vous avez livré grâce à lui.

Bonnes pratiques

Conservez un dossier privé sur le périmètre de chaque expérience, votre contribution, les retours reçus et le statut actuel. Vérifiez que les liens fonctionnent toujours avant d'envoyer une candidature. Mettez à jour une puce open source lorsque le statut de la contribution change. Si votre meilleur exemple est modeste, expliquez-le bien plutôt que d'en exagérer l'ampleur. Une contribution claire et modeste peut être plus facile à croire qu'une affirmation large sans travail vérifiable.

Liste de vérification finale

• J’ai sélectionné l’exemple principal en fonction du poste visé, et non du seul prestige.
• Chaque entrée indique son contexte réel, son rôle et ses dates.
• Mes puces distinguent mes actions du travail de l’équipe ou des mainteneurs.
• Le statut du travail freelance et open source est décrit avec exactitude.
• Tout exemple public peut être partagé sans risque et avec autorisation.
• Chaque affirmation importante repose sur un livrable ou une explication que je peux fournir.

Questions fréquentes

Un projet freelance est-il meilleur qu'un stage ?

Aucun des deux n'est automatiquement meilleur. Comparez ce que vous avez fait avec les tâches du poste visé et la clarté avec laquelle vous pouvez montrer le résultat. Un petit projet client finalisé peut être plus pertinent qu'un stage surtout observationnel pour certains postes.

Le travail open source compte-t-il s'il n'était pas rémunéré ?

Oui, il peut démontrer un travail pertinent. Indiquez le projet, votre contribution, le statut de la revue ou de la fusion, ainsi que tout lien que le lecteur peut examiner. Ne le présentez pas comme un emploi rémunéré.

Puis-je inclure une pull request qui n'a pas été fusionnée ?

Vous le pouvez si le travail et la discussion sont pertinents. Indiquez qu'elle a été proposée ou examinée, expliquez ce que vous avez appris ou modifié, et ne laissez pas entendre qu'elle a atteint la production. Une modification fusionnée n'est pas la seule preuve utile, mais le statut est important.

Comment lister plusieurs petites missions freelance ?

Regroupez-les sous une entrée freelance clairement libellée lorsque cela rend la chronologie plus facile à lire, puis choisissez des projets représentatifs. Ne conservez les noms des clients et les exemples que lorsque vous avez l'autorisation, et décrivez le périmètre réel de chaque exemple.