Moi ou l'équipe ? Comment décrire honnêtement sa contribution dans un portfolio

La plupart des produits, campagnes, déploiements et processus de valeur sont réalisés en équipe.

Montrer uniquement le résultat final ne permet pas encore de savoir quel rôle précis a joué un spécialiste donné.

Pour une personne qui évalue un portfolio, la différence est considérable :

"J'ai travaillé sur la refonte du processus de finalisation d'achat"

n'a pas le même sens que :

"J'ai dirigé la recherche, conçu le nouveau parcours de finalisation d'achat, préparé le prototype et mené les tests d'utilisabilité. Une équipe de développement front distincte s'est chargée de l'implémentation."

La seconde formulation permet d'évaluer les compétences réelles sans minimiser le travail des autres.

Le problème ne concerne pas uniquement les portfolios professionnels.

Dans l'édition scientifique, on trouve notamment CRediT - Contributor Role Taxonomy. Ce standard décrit 14 types de contribution et a été créé pour rendre plus transparent le fait de savoir qui était réellement responsable des différentes parties d'un travail. CRediT permet d'attribuer plusieurs rôles à une personne et un même rôle à plusieurs personnes. Il recommande également que les contributeurs puissent vérifier et confirmer les rôles qui leur sont attribués. [1]

CRediT concerne avant tout la recherche et les publications scientifiques. Ce n'est pas un standard de portfolio professionnel. Il illustre toutefois un principe utile plus largement : au lieu de s'appuyer sur l'affirmation vague "j'ai participé au projet", il vaut mieux préciser clairement la nature de sa contribution réelle.

Une bonne description de projet d'équipe peut s'articuler autour de six informations :

1. Contexte du projet
2. Composition et périmètre de l'équipe
3. Responsabilité personnelle
4. Actions et décisions concrètes
5. Livrables ou preuves du travail
6. Résultat et manière de l'attribuer

L'objectif n'est pas de produire un long rapport. Il s'agit de lever les principales ambiguïtés.

Expliquez d'abord sur quoi l'équipe travaillait réellement.

Une courte description suffit :

• le problème ou l'objectif,
• le type de produit ou de service,
• l'échelle approximative,
• les contraintes importantes,
• la période de réalisation si elle est pertinente.

Exemple :

L'objectif du projet était de raccourcir le processus d'achat dans une application B2B. Le produit fonctionnait sur plusieurs marchés européens et servait des clients professionnels.

Le lecteur comprend ainsi le contexte avant d'évaluer la contribution individuelle.

Il n'est pas nécessaire de citer chaque personne par son nom.

Dans de nombreux cas, une structure simple suffit :

Équipe : chef de produit, concepteur de l'expérience utilisateur, 2 développeurs front, 2 développeurs back et un spécialiste qualité.

Cette seule information change la manière d'interpréter toute la description du projet.

Le lecteur voit que le résultat n'est pas apparu isolément et que le spécialiste travaillait dans une répartition précise des responsabilités.

C'est la partie la plus importante.

Au lieu de l'affirmation générale :

"j'ai travaillé sur la partie front"

écrivez précisément :

"j'étais responsable de l'architecture du module de paiement, de l'implémentation du processus de finalisation d'achat, de l'intégration avec l'API de paiement et de la revue du code pour les changements dans ce périmètre."

Il peut aussi être utile de préciser ce que vous n'avez pas fait lorsque cela pourrait être ambigu :

"la partie serveur et l'intégration avec le prestataire de paiement côté serveur ont été réalisées par une équipe distincte."

Cela n'affaiblit pas le portfolio. Cela le rend plus crédible.

Un intitulé de poste n'est pas encore une description de contribution.

Un concepteur senior de l'expérience utilisateur peut conduire toute la recherche dans un projet et ne préparer que les écrans finaux dans un autre.

Montrez donc les actions reliées à des compétences concrètes :

• j'ai conçu l'architecture de la solution,
• j'ai mené la recherche,
• j'ai conçu le déroulement du processus,
• j'ai analysé les données,
• j'ai écrit une partie essentielle de l'implémentation,
• j'ai préparé la stratégie de campagne,
• j'ai conduit les négociations,
• j'ai coordonné les dépendances entre les équipes,
• j'ai vérifié la solution avant le déploiement.

Les exemples les plus utiles sont ceux où vous pouvez expliquer pourquoi une décision précise a été prise.

Si le projet peut être montré, un livrable aide à relier la contribution déclarée au travail réel.

Par exemple :

• un écran du produit,
• une partie de l'interface,
• un prototype,
• un extrait de code,
• un dépôt public,
• un rapport,
• un diagramme,
• une publication,
• un support de campagne,
• une photographie,
• un document ou un extrait pouvant être montré sans risque.

Le livrable n'a pas à tout prouver. Il doit aider le lecteur à comprendre ce qui a réellement été produit et comment cela se rattache à la contribution décrite.

Le plus grand risque d'exagérer sa contribution apparaît lorsqu'on décrit les résultats.

Si le taux de conversion d'une entreprise augmente de 25% après un projet, cela ne signifie pas automatiquement qu'une personne a augmenté la conversion de 25%.

Durant la même période, d'autres facteurs ont pu changer :

• les prix,
• l'offre,
• le marketing,
• l'expérience utilisateur,
• l'infrastructure,
• la saisonnalité,
• les sources de trafic,
• le travail des autres membres de l'équipe.

Décrivez le résultat uniquement avec le degré de certitude que vous pouvez réellement justifier.

1. Responsabilité directe
"J'ai réduit la durée de ce processus de 12 à 4 minutes en automatisant les étapes dont j'étais responsable."

Utilisez cette formulation lorsque le lien entre votre action et le résultat est direct et justifiable.

2. Résultat collectif
"Avec l'équipe, nous avons repensé le processus d'intégration des utilisateurs. Après le déploiement, le taux d'achèvement a augmenté de 18%."

Utilisez cette formulation lorsque le résultat provient du travail de plusieurs personnes.

3. Contribution à un changement plus large
"J'étais responsable de la refonte du processus de finalisation d'achat dans le cadre d'une optimisation plus large du parcours d'achat. Après le déploiement de l'ensemble du programme, l'entreprise a enregistré une hausse de la conversion."

Utilisez cette formulation lorsque votre domaine n'était qu'un facteur parmi plusieurs.

4. Résultat comme contexte du projet
"Le projet s'est conclu par une hausse des ventes de 40%. Mon périmètre couvrait l'architecture côté client et l'implémentation du processus de finalisation d'achat."

Utilisez cette formulation lorsque vous connaissez le résultat global du projet mais ne pouvez pas déterminer de façon fiable quelle part provient de votre travail.

Lorsqu'un projet met en avant plusieurs personnes, la meilleure description doit répondre simultanément à deux questions :

Qu'a livré l'équipe ?

et

De quoi chaque personne était-elle responsable ?

Exemple :

Projet : première version d'une application logistique
Équipe : concepteur de l'expérience utilisateur, développeur front, développeur back
Résultat collectif : première version fonctionnelle du produit prête pour un pilote
Concepteur de l'expérience utilisateur : recherche, parcours utilisateur, prototype, conception de l'interface
Développeur front : architecture côté client, implémentation de l'application web
Développeur back : API, modèle de données, intégrations

Une telle description renforce à la fois l'équipe et les spécialistes individuels.

Dans certains projets, des termes simples peuvent aider à exprimer le niveau d'implication :

Rôle principal - j'ai piloté le domaine et pris en charge les décisions clés.
Responsabilité partagée - j'ai partagé la responsabilité avec une ou plusieurs autres personnes.
Rôle de soutien - j'ai soutenu le domaine sans en être le responsable principal.

CRediT utilise une distinction similaire pour les rôles de contributeurs. [1]

Le principe essentiel est simple : le niveau de responsabilité doit être compréhensible.

Pour les projets communs importants, il est utile de vérifier que la description de votre propre contribution n'entre pas manifestement en contradiction avec la manière dont les autres participants comprennent les rôles.

CRediT recommande que les contributeurs puissent consulter et confirmer les rôles qui leur sont attribués. [1]

Dans un portfolio professionnel, cela ne signifie pas qu'il faut instaurer une procédure formelle de validation de chaque phrase. La règle pratique est plus simple : ne vous attribuez pas une responsabilité qui était en réalité pilotée par quelqu'un d'autre.

Décrire sa propre contribution ne doit pas être confondu avec la détermination des droits d'auteur.

Selon le droit polonais d'auteur, les droits appartiennent en principe à l'auteur et sont détenus conjointement par les coauteurs. Pour les oeuvres créées dans le cadre d'un emploi, l'employeur peut acquérir les droits patrimoniaux dans la mesure prévue par la loi et la relation de travail. [2]

En pratique, trois questions doivent être traitées séparément :

Ai-je participé à la création du projet ?
Suis-je l'auteur ou le coauteur d'un élément précis ?
Ai-je le droit de publier le contenu dans mon portfolio ?

Une réponse "oui" à la première question ne détermine pas automatiquement les deux autres.

Tous les projets ne peuvent pas être montrés ou décrits en détail.

Le droit polonais relatif à la concurrence déloyale protège les informations constituant un secret d'affaires, notamment certaines informations techniques, technologiques, organisationnelles et autres ayant une valeur économique et maintenues confidentielles. [3]

Dans un projet confidentiel, supprimer uniquement le nom du client peut donc être insuffisant. Les autres détails peuvent encore révéler des informations protégées.

Une règle plus sûre consiste à :

ne décrire que ce que vous êtes réellement autorisé à divulguer au regard du droit applicable, des contrats, des consentements et des autres droits dont vous disposez.

Une description de projet n'a généralement pas besoin des données privées de toute l'équipe.

Le RGPD impose notamment la licéité, la limitation des finalités et la minimisation des données, c'est-à-dire que les données personnelles doivent être limitées à ce qui est nécessaire pour la finalité concernée. [4]

S'il suffit de décrire l'équipe ainsi :

1 concepteur de l'expérience utilisateur, 2 développeurs front, un développeur back et un spécialiste qualité

il n'est pas nécessaire de publier automatiquement les noms, photos, adresses e-mail ou autres données personnelles des collègues.

Si vous souhaitez publier un témoignage, une déclaration, une image ou d'autres données concernant une personne précise, vérifiez la base juridique appropriée et l'étendue d'utilisation autorisée.

Si les conditions de collaboration autorisent une description générale de l'expérience, vous pouvez envisager de présenter :

• le type de problème sans identifier le client,
• votre rôle,
• les catégories de compétences utilisées,
• le type de responsabilité,
• le processus de décision à un niveau suffisamment général,
• le résultat uniquement dans la mesure où il peut être divulgué.

N'inventez pas de captures d'écran, de données ou de résultats pour remplacer des éléments confidentiels.

Si vous ne savez pas si une information précise peut être divulguée, il est plus prudent de ne pas la publier avant d'avoir clarifié la question.

De petites différences de formulation peuvent très bien exprimer le niveau de responsabilité.

J'étais responsable de... - attribue clairement votre propre périmètre.
J'ai piloté... - indique une responsabilité sur la direction ou la réalisation d'un périmètre donné.
J'ai co-créé... - montre que le résultat avait plusieurs auteurs.
J'ai contribué à... - décrit honnêtement un rôle de soutien.
Je faisais partie de l'équipe qui... - sépare la participation individuelle du résultat global de l'équipe.
Après le déploiement du projet, l'entreprise a constaté... - présente le résultat comme contexte sans s'attribuer automatiquement tout l'effet.

Évitez de dire automatiquement "je l'ai fait" lorsque le périmètre réel était partagé.

1. Vous utilisez le singulier pour un projet réalisé par de nombreuses personnes.

2. Vous montrez un résultat commercial sans expliquer votre propre périmètre.

3. Vous présentez les technologies de l'ensemble du produit comme vos propres compétences alors que vous n'avez pas travaillé avec chacune d'elles.

4. Vous montrez la conception visuelle finale, du code ou une stratégie sans préciser quelles parties vous avez réellement créées.

5. Vous omettez des contributeurs clés alors que leur participation est nécessaire pour comprendre le projet.

6. Vous suggérez un lien de causalité entre votre travail et un résultat que vous ne pouvez pas justifier.

Projet
Qu'est-ce qui était créé et quel problème devait être résolu ?

Équipe
Quels rôles ont participé au projet ?

Ma responsabilité
De quel domaine étais-je personnellement responsable ?

Mes actions et décisions
Qu'ai-je concrètement réalisé ou piloté ?

Collaboration
Quels éléments ont été créés avec d'autres personnes ?

Livrables
Qu'ai-je légalement le droit de montrer ?

Résultat
Qu'a obtenu le projet et comment ma contribution se rattache-t-elle à ce résultat ?

Contraintes
Y a-t-il des éléments que je ne peux pas divulguer en raison de la confidentialité ou des droits d'autres personnes ?

Posez-vous sept questions :

1. Le lecteur sait-il quelle était la taille de l'équipe ?

2. Est-il clair de quoi j'étais exactement responsable ?

3. Ai-je évité de m'attribuer le travail réalisé par d'autres ?

4. Le résultat est-il décrit avec un niveau de prudence approprié ?

5. Ai-je légalement le droit de publier les éléments utilisés ?

6. Est-ce que j'évite de divulguer inutilement des données personnelles ou des informations confidentielles ?

7. Une personne extérieure pourrait-elle dire, à partir de cette description, quelles compétences j'ai réellement utilisées ?

Si les réponses sont claires, la description du projet devient une preuve de compétence plutôt qu'une simple histoire séduisante.

La meilleure description de projet n'a pas à choisir entre :

"c'est moi qui l'ai fait"

et

"c'est l'équipe qui l'a fait."

Elle peut montrer les deux réalités en même temps :

l'équipe a livré un résultat précis et j'étais responsable d'une partie déterminée, de décisions et de leur exécution.

Ce niveau de précision permet d'évaluer un spécialiste sans retirer le mérite aux autres participants.

Un portfolio ne devrait pas être un concours de la formulation la plus impressionnante possible.

Sa valeur augmente lorsque la personne qui le consulte peut comprendre :

ce qui a été créé, qui y a travaillé, de quoi vous étiez responsable, ce que vous avez fait personnellement et quel résultat peut raisonnablement être relié à votre contribution.

Une description précise n'affaiblit pas une réalisation.

Au contraire. Elle montre que vous comprenez vos responsabilités, savez travailler avec les autres et présentez honnêtement les résultats de votre travail.

[1] CRediT - Contributor Role Taxonomy, NISO
Consulter la source

[2] Loi polonaise sur le droit d'auteur et les droits voisins - art. 8-12, ELI
Consulter la source

[3] Loi polonaise sur la lutte contre la concurrence déloyale - art. 11, texte consolidé publié en 2026
Consulter la source

[4] Règlement (UE) 2016/679 - RGPD, art. 5, EUR-Lex
Consulter la source

Note méthodologique : CRediT est un standard relatif aux rôles des contributeurs dans la recherche et les publications scientifiques. Cet article l'utilise comme exemple d'attribution transparente des contributions, mais ne le présente pas comme un standard de portfolio professionnel. Les six éléments de description d'un projet et les quatre manières de décrire le lien avec les résultats constituent un modèle éditorial proposé dans ce document.