VJOURNAL

DesignRubrique mondiale16 septembre 2026

Portfolio sans clients : trois études de cas à construire honnêtement

Un bon portfolio sans clients s'appuie sur des contraintes réelles et des statuts de projet transparents. Trois exercices montrent quoi construire, quelles preuves garder et quoi ne jamais affirmer.

Couverture VJOURNAL pour « Portfolio sans clients : trois études de cas à construire honnêtement »

Réponse en bref

Un portfolio solide sans clients se construit autour de contraintes réelles, avec le statut de chaque projet indiqué honnêtement : apprentissage, bénévolat ou concept de redesign non officiel.

8 sources
Les projets d'apprentissage fonctionnent quand les contraintes sont réelles : NN/g avertit que des utilisateurs et des personas inventés dévalorisent un cas, et recommande au moins de le déclarer honnêtement dans la description.
Un projet hypothétique construit sur un service existant et le bénévolat auprès d'organisations à but non lucratif sont deux stratégies valables pour un portfolio sans clients ; IxDF elle-même considère malgré tout les projets réels souvent plus précieux que les hypothétiques.
Un cas doit montrer le processus — contexte, rôle de l'auteur, alternatives rejetées et réflexion — pas seulement la maquette finale.

Pourquoi les seuls projets scolaires peuvent être une preuve fragile

Nielsen Norman Group avertit qu'un portfolio convaincant est plus difficile à construire quand tout ce qu'un candidat peut montrer, ce sont des travaux d'étudiant, parce que ces projets comportent souvent des contraintes, des utilisateurs et des personas inventés, ce qui les rend moins probants pour démontrer un travail en conditions réelles. NN/g recommande d'obtenir au moins un vrai projet via un stage et, pour les travaux scolaires déjà terminés, de signaler ouvertement les éléments peu réalistes dans la description du cas, pour que le lecteur comprenne les limites de ce que cela prouve.

Interaction Design Foundation présente une pratique voisine autrement : un « projet hypothétique » peut s'appuyer sur l'analyse d'un produit existant ou être entièrement inventé — IxDF qualifie les deux d'excellente stratégie, justement pour les débutants. Cela ne recoupe pas entièrement l'avertissement de NN/g : IxDF précise par ailleurs que les projets réels — bénévoles, scolaires, communautaires ou de hackathon — sont souvent plus précieux que les hypothétiques, sans pour autant interdire d'inventer le produit lui-même. L'écart ici ne porte pas sur les faits mais sur l'accent : NN/g conseille d'abord de chercher un vrai projet et, seulement à défaut, des contraintes réalistes avec une mention honnête de leur caractère fictif ; IxDF admet aussi un produit entièrement inventé, tout en jugeant les projets réels souvent plus précieux. La rédaction en tire le principe de travail pour les trois exercices ci-dessous : non pas « inventez une marque de toutes pièces », mais « prenez un produit réel et une contrainte réelle et vérifiable » — une décision éditoriale qui s'appuie sur l'avertissement de NN/g et sur le fait qu'IxDF elle-même place les projets réels au-dessus des hypothétiques, et non une position commune formulée telle quelle par les deux sources.

Trois exercices plutôt qu'une marque inventée de toutes pièces

Chacun des trois exercices s'organise autour d'une contrainte réelle et vérifiable — un service existant, une demande de bénévolat authentique ou le produit d'une autre entreprise —, et non autour d'une marque fictive avec des indicateurs inventés. Chaque exercice a son propre type de contrainte : une plateforme technique et une navigation déjà existantes dans le premier, un budget de temps et l'absence de rémunération dans le deuxième, un système visuel déjà établi par une autre entreprise dans le troisième. Le critère d'évaluation change lui aussi d'un exercice à l'autre et ne se réduit jamais à la question de savoir si l'image finale plaît.

La règle commune aux trois : le résultat n'est ni un avis de client ni un chiffre de ventes qui n'existent pas, mais un artefact vérifiable (maquette, prototype, concept de redesign) assorti d'un statut de projet indiqué ouvertement. Trois formulations pour les trois exercices : « projet d'apprentissage, pas une commande client », « projet bénévole pour (type d'organisation), non rémunéré » et « concept de redesign : travail non officiel sur le produit d'une autre entreprise, ni commandé ni approuvé par son propriétaire ». Les sources ne comparent pas le poids de ces mentions à celui d'une commande réellement honorée en entretien : NN/g qualifie le projet d'apprentissage de preuve peu convaincante de la capacité à travailler en conditions réelles, et IxDF place les projets réels, y compris bénévoles, au-dessus des hypothétiques (voir plus haut) — autrement dit, le seul statut d'apprentissage pèse moins qu'une commande menée à bien. Le principe pratique qui suit relève déjà de la rédaction : pour ne pas donner une fausse impression de travail client, mieux vaut nommer le statut dans le cas avant de décrire le résultat, plutôt que de le laisser flou jusqu'à l'entretien.

Exercice un : auditer un service existant et justifier un changement

Choisissez un service ou une interface que vous utilisez vous-même — pas une « start-up » abstraite, mais une application, un site ou un formulaire concrets, avec de vrais écrans que vous pouvez ouvrir et capturer. Formulez une question précise : quelle étape de cette interface crée le plus de friction, et pourquoi. La contrainte est ici technique et réelle : vous travaillez à l'intérieur d'une navigation, d'une typographie et de tailles d'écran déjà existantes, pas dans le vide, et il faut l'expliquer avant de proposer des changements. Nielsen Norman Group recommande de figer l'état initial — par des captures ou d'autres données — avant tout redesign, pour avoir de quoi comparer la décision finale.

Interaction Design Foundation qualifie ce format — analyser un produit existant et proposer une amélioration — de stratégie recommandée justement pour les débutants. Structurez le cas selon le schéma « contexte et rôle de l'auteur → processus → résultat et réflexion » que décrit un autre article méthodologique de la même ressource : d'abord la question posée et pourquoi, puis les options envisagées et écartées et pourquoi, enfin ce que vous feriez différemment si vous repreniez la tâche aujourd'hui.

Livrable : un prototype d'une étape et au moins une option rejetée

Le livrable vérifiable de cet exercice n'est pas un redesign complet du service, mais une maquette ou un prototype d'une étape précise, une capture ou un enregistrement de l'état « avant » de cette étape, et une courte description d'au moins une option envisagée puis rejetée, avec sa raison. Un délai d'une à deux semaines n'est pas une règle des sources mais un repère éditorial : suffisant pour parcourir le trajet « question → options → décision » sans étirer un exercice d'apprentissage sur des mois.

Contrôle : peut-on raconter le problème sans la maquette ?

Le critère d'auto-évaluation est simple : le lecteur du cas peut-il redire quel problème précis vous résolviez, sans regarder la maquette. Le statut de cet exercice est « projet d'apprentissage, pas une commande client » ; indiquez-le directement dans la description du cas, pas en petits caractères en bas de page — dans le même esprit que le conseil de NN/g de déclarer ouvertement les éléments peu réalistes des projets d'apprentissage.

Exercice deux : un projet bénévole avec une vraie demande non rémunérée

Le deuxième type de contrainte réelle n'est pas une hypothèse, mais une demande vivante d'une organisation qui a besoin de travail de design sans budget pour le payer. Interaction Design Foundation cite directement les associations caritatives et les organisations à but non lucratif, les projets étudiants et communautaires, les hackathons, comme sources de ce type de contraintes non inventées — et avertit par ailleurs qu'échanger du travail contre de « l'expérience » tourne souvent à l'exploitation de jeunes designers ; mieux vaut donc choisir précisément ces options éthiques de la liste, et non n'importe quelle commande gratuite venant de n'importe qui.

Ce qui distingue cet exercice du premier, c'est le volume de retour : une demande bénévole implique un représentant de l'organisation capable de valider ou de rejeter la solution, même sans rémunération. Il faut formuler la contrainte à l'avance et par écrit, sous forme de brief : ce qu'il faut faire, pour quand, dans quel format. C'est la même compétence que travailler sur le brief d'une commande payante — la différence est qu'ici vous rédigez le brief vous-même avec le représentant de l'organisation, au lieu de le recevoir tout fait d'un client d'agence.

Livrable : un brief, une solution et la réaction du représentant

Le livrable vérifiable est un brief écrit avec la tâche et l'échéance, la maquette ou le prototype lui-même, et une courte réaction documentée du représentant de l'organisation à la solution proposée — même s'il s'agit d'un rejet partiel : ce qui compte, c'est le fait même d'un retour d'une personne réelle, pas seulement votre propre évaluation. Un délai de plusieurs semaines est un repère éditorial, pas une règle de la source.

Contrôle : la solution tient-elle compte des limites de cette organisation ?

Le critère d'évaluation du cas : voit-on que la solution a été pensée en tenant compte des contraintes propres à cette organisation — son public, ses ressources pour maintenir la maquette après livraison —, plutôt que reprise d'un modèle abstrait ? Le statut du projet est « projet bénévole pour (type d'organisation), non rémunéré », en précisant pour qui il a été fait, sans inventer de résultat que l'organisation n'a jamais confirmé.

Exercice trois : un concept de redesign d'un produit tiers, statut affiché

Le troisième format est le plus risqué sur le plan éthique : il consiste à prendre le produit réel d'une autre entreprise et à le retravailler visuellement, et c'est là qu'il est le plus facile de présenter le résultat comme une commande honorée de cette entreprise. Aucune des sources examinées ne formule d'interdiction directe à ce sujet ; il s'agit d'une position méthodologique éditoriale qui s'appuie sur le conseil de NN/g de déclarer ouvertement les éléments peu réalistes des projets d'apprentissage dans la description : la rédaction étend le même principe au travail sur le produit d'une autre entreprise — le statut doit être visible immédiatement, et non deviné par le recruteur.

Du point de vue de la transparence éditoriale, ce type de cas ne peut pas être présenté comme une commande de l'entreprise : le produit ou l'interface est traité comme objet d'une analyse indépendante, et la toute première phrase doit indiquer clairement que le travail est non officiel et n'a été ni commandé ni approuvé par son propriétaire. Mais une mention honnête ne règle pas à elle seule la question juridique. Selon l'article 1270 du Code civil russe, la traduction ou toute autre adaptation d'une œuvre protégée, ainsi que la mise à disposition du public d'une œuvre, comptent parmi les usages couverts par le droit exclusif. Ce sont des règles de droit russe : hors de Russie, le régime de protection du droit d'auteur et des marques peut différer, et il faut le vérifier séparément. Que cela s'applique à une interface, un logo ou des éléments précis, et qu'une exception légale existe, dépend de l'objet et des circonstances. Les droits de marque relèvent d'un régime distinct et ne sont pas pleinement traités dans cet article. Ce texte ne donne donc aucune autorisation universelle de publier le logo d'une autre entreprise ou son redesign ; le minimum pratique est de ne pas créer une fausse impression de commande ou d'approbation, et de vérifier séparément les droits sur les éléments utilisés avant publication.

Livrable : un concept de redesign avec le statut affiché

Le livrable vérifiable est le concept de redesign lui-même (maquette, prototype ou système) et une explication dans le premier paragraphe de la description : ce qui a exactement été retravaillé, le fait qu'il s'agisse d'un travail non officiel, et que l'entreprise ne l'a ni commandé ni approuvé. Mentionner l'entreprise dans la description est à distinguer de l'utilisation de son logo ou d'un autre signe : la légalité de cet usage dépend du contexte précis et des droits sur cet élément, et cet article ne remplace pas une vérification juridique.

Contrôle : le texte laisse-t-il croire à l'accord de l'entreprise ?

Autocontrôle avant publication : relisez la description du cas et repérez chaque endroit où un lecteur ordinaire pourrait croire que l'entreprise est au courant de ce travail ou l'a approuvé, puis réécrivez ces passages sans ambiguïté. Le même principe vaut pour le logo, séparément de l'interface : le droit de montrer dans un portfolio un logo réalisé sur une vraie commande et le droit de montrer le redesign d'un logo déjà existant appartenant à autrui sont deux choses différentes, aux conséquences juridiques différentes, et il vaut mieux clarifier cette différence avant publication, pas après une question en entretien.

Comment construire un cas qui montre le raisonnement, pas seulement l'image

Pour les trois cas, il est utile de garder le même jeu de questions — contexte, rôle de l'auteur, processus, alternatives, résultat et réflexion —, sans forcer des projets différents dans un même gabarit visuel. Interaction Design Foundation décrit, dans un autre article méthodologique de la même ressource, une séquence de base « début — processus — conclusion » : d'abord le contexte de la tâche et le rôle de l'auteur, puis le chemin vers la solution et les alternatives, enfin le résultat et la réflexion sur ce qu'il faudrait faire autrement. La maquette finale, dans cette logique, montre l'aboutissement du processus, mais le format du cas lui-même peut s'adapter à la matière.

Un accent similaire apparaît dans une sélection vidéo d'Interaction Design Foundation réunissant plusieurs responsables du design et du recrutement, parmi lesquels la page nomme, avec leur titre, le responsable créatif (Creative Lead) de Smashing Magazine, Vitaly Friedman, et le responsable design produit de Netflix, Nival Sheikh ; la transcription de la vidéo n'est pas lisible sur la page, donc cet article ne leur attribue aucune parole précise. La conclusion textuelle qu'en tire IxDF est de montrer dans le portfolio le raisonnement et d'être précis plutôt que vague. La comparaison avec une image finale léchée est formulée directement par d'autres articles méthodologiques de la même ressource — celui qui décrit la structure du cas et celui qui liste les erreurs courantes de portfolio. La conclusion pratique pour un cas : écrivez non seulement « ce qui en est sorti », mais aussi quelles options vous avez rejetées et pourquoi — cette partie de la structure du cas mérite de l'attention dans tous les formats, pas seulement dans l'apprentissage.

Comment indiquer le statut d'un projet sans le faire passer pour une commande

Les trois statuts utilisés plus haut servent avant tout la transparence : le lecteur du cas comprend immédiatement où il y avait un projet d'apprentissage, où il y avait du bénévolat, et où se trouvait un concept de redesign indépendant. Nielsen Norman Group recommande de faire exactement cela pour les projets d'apprentissage déjà terminés — déclarer ouvertement dans la description leurs éléments peu réalistes, pour que le recruteur n'ait pas l'impression que l'auteur ne voit tout simplement pas la différence avec un vrai projet. La recommandation éditoriale est de révéler le statut dès la première phrase de la description du cas, pour que la présentation visuelle ne donne pas l'impression d'une vraie commande avant que la précision n'apparaîsse.

La formulation doit être aussi concrète que le cas lui-même : pas « un projet d'entraînement », mais « projet d'apprentissage, pas une commande client, réalisé pour travailler une solution d'interface précise » ; pas « j'ai aidé une organisation », mais « projet bénévole pour une initiative associative locale, non rémunéré, sur plusieurs semaines » ; pas « redesign de marque », mais « concept de redesign pour (entreprise) : initiative de l'auteur, ni commandé ni approuvé par le propriétaire ». Ces formulations exactes sont une proposition éditoriale et non une citation d'une source : aucun des documents consultés ne fournit de formule toute faite pour ce type d'étiquetage, même si NN/g formule bien la nécessité de révéler le caractère fictif d'un projet d'apprentissage.

Que retirer d'un portfolio déjà constitué

Si plusieurs projets d'apprentissage figurent déjà dans un portfolio, il existe pour eux un ensemble de vérifications distinct. Interaction Design Foundation énumère des erreurs courantes qui dévalorisent même un travail solide : du temps passé sur des détails secondaires comme un logo personnel plutôt que sur les cas eux-mêmes ; l'absence de sélection, quand tout entre dans le portfolio au lieu d'une sélection organisée des meilleurs travaux ; l'usage d'un gabarit tout fait sans l'adapter au contenu ; une documentation faible du processus de décision ; et des défauts techniques ordinaires comme un affichage responsive défaillant, des problèmes d'accessibilité ou des fautes dans le texte du cas.

Nielsen Norman Group et Interaction Design Foundation s'accordent sur un conseil voisin, utile dès le travail sur le projet et pas seulement au moment de nettoyer un portfolio terminé : documenter le processus au fil de l'eau, avant d'oublier les détails. IxDF en fait un principe à part — documenter le plus possible et inclure dans le cas brouillons, croquis, photos et notes vocales ; NN/g recommande séparément de conserver tout artefact de travail pour de futurs cas. Cela dit, les cas ne gagnent rien à une prose étendue : les recruteurs parcourent un portfolio rapidement, ils ne le lisent pas d'un bout à l'autre. Pour les exercices bâtis sur une contrainte réelle, documenter au fil de l'eau sert aussi de preuve : un brouillon montre que la solution n'était pas la seule option évidente dès le départ.

Comment présenter les projets d'apprentissage dans le CV, à part du portfolio

Le CV et le portfolio répondent à des besoins différents. Nielsen Norman Group recommande de ne pas créer, dans le CV, de rubriques propres à des projets individuels : le programme ou les cours suivis peuvent y être décrits en deux ou trois phrases, dans le langage des compétences — quels sujets ont été étudiés, quels outils ont été appris —, tandis que les projets eux-mêmes, avec tous leurs détails, alternatives et statut, se déploient dans un portfolio adapté à un lecteur non académique, pas dans un rapport interne de formation.

Cette règle vaut aussi pour les trois exercices de cet article : dans le CV, une ligne générale sur le programme suivi ou la pratique indépendante et les compétences clés, et non une entrée séparée pour un cas précis lié à un service, un logo ou une organisation. La version complète — avec la recherche, les alternatives, le statut du projet et la réflexion — reste dans le portfolio ; le recruteur qui veut des détails l'ouvrira lui-même.

Checklist pratique

  • Le statut du projet figure dans la première phrase de chaque description de cas, pas caché à la fin du texte.
  • La contrainte est formulée de façon concrète : la navigation et la mise en page déjà existantes d'un service, le budget de temps d'un projet bénévole ou le système visuel d'une autre entreprise — pas une liberté abstraite.
  • Le texte du cas comporte un paragraphe sur au moins une option rejetée et sa raison.
  • L'état initial du service ou du produit est fixé par une capture ou d'autres données avant que la solution finale n'apparaîsse dans le cas.
  • Aucun cas ne comporte d'avis de client, de chiffre de ventes ou de mention d'une relation commerciale avec une entreprise qui n'a jamais existé.
  • Si le cas est un concept de redesign d'un produit ou d'un logo tiers, le statut est décrit honnêtement dans la première phrase, et aucune formulation ne laisse entendre que l'entreprise l'a commandé ou approuvé ; le risque juridique de publier le redesign d'un signe tiers ne disparaît pas avec une seule mention.
  • Dans le CV, le programme de formation et les cours sont décrits en deux ou trois phrases dans le langage des compétences ; il n'y a pas de rubrique propre à un projet précis — les détails restent dans le portfolio.

Questions et réponses

Puis-je montrer dans mon portfolio le concept de redesign du logo d'une entreprise réelle sans qu'elle le sache ?

Il n'y a pas de « oui » univoque ici. L'article 1270 du Code civil russe range l'adaptation d'une œuvre protégée et la mise à disposition du public parmi les usages relevant du droit exclusif. Publier un redesign précis peut donc nécessiter l'autorisation du titulaire des droits ou s'appuyer sur une exception légale applicable ; cela dépend de ce qui a exactement été retravaillé et si l'élément concerné est protégé. Les droits de marque, à part, ne sont pas analysés ici. Ce sont des règles de droit russe : dans d'autres pays, les règles de protection du droit d'auteur et des marques peuvent différer, et il faut les vérifier séparément. Dans tous les cas, on ne peut pas présenter le travail comme si l'entreprise l'avait commandé ou approuvé alors que ce n'est pas arrivé.

Combien de cas faut-il pour envoyer un portfolio à une première candidature ?

Les sources donnent des fourchettes différentes mais proches : Nielsen Norman Group recommande de choisir 3 à 5 projets pour des cas détaillés et souligne que le nombre compte moins que la variété des compétences montrées ; Interaction Design Foundation avance une fourchette d'environ trois à six cas. Il n'existe aucune donnée sur un nombre qui garantirait un entretien, ni du côté de la rédaction ni dans les sources consultées.

Faut-il préciser dans le CV qu'un projet était non rémunéré ou scolaire ?

Selon le conseil de Nielsen Norman Group, mieux vaut ne pas créer de rubriques de CV pour des projets précis : les cours et le programme suivi peuvent y être décrits en deux ou trois phrases dans le langage des compétences, tandis que les projets, avec leur statut, leurs détails et leur réflexion, se déploient dans le portfolio. Le statut — « apprentissage », « bénévolat », « concept de redesign » — s'indique là, pas dans le CV.

Que faire si le seul projet bénévole disponible n'est pas dans la spécialité que l'on veut viser ensuite ?

Interaction Design Foundation recommande de choisir méthodes et types de cas en fonction du poste visé et de combiner différents formats dans un même portfolio, plutôt que de dépendre d'un seul projet. Si le projet bénévole ne correspond pas au profil, la piste éditoriale est de ne l'utiliser que s'il montre des méthodes utiles pour le poste visé, et de renforcer le profil du portfolio avec le premier ou le troisième exercice, plus faciles à choisir près de la spécialisation souhaitée.

Vaut-il mieux faire un seul cas détaillé ou trois cas courts ?

Les sources penchent pour la sélection plutôt que le volume : NN/g note que les cas ne gagnent rien à une prose étendue, puisqu'ils sont de toute façon parcourus rapidement, et recommande de se concentrer sur un ou deux projets quand le temps manque, plutôt que de se disperser. Les trois exercices de cet article couvrent trois types de contraintes différents et visent des compétences différentes, pas la dispersion ; si le temps manque vraiment, il est plus sensé de finir un ou deux exercices que d'en commencer trois superficiellement.