Au fil de mes années en développement logiciel, il y a un scénario que j’ai vu se répéter trop souvent : des équipes talentueuses et déterminées qui se retrouvent systématiquement à manquer tous leurs livrables. Et généralement, les mêmes raisons reviennent : les tâches sont tellement grosses qu’elles mettent à rude épreuve le travail du développement. Règles non découvertes, cas d’usage oubliés, ou encore bogues imprévus liés à des variantes spécifiques du besoin utilisateur. Quand ça se produit, c’est tout le projet qui vacille : retards, frustrations, et parfois, une remise en question du processus de travail.
Ces situations ne sont pas rares, mais elles amènent toujours les mêmes questions : comment minimiser ces risques? Comment adapter notre façon de travailler pour anticiper ces imprévus et, surtout, maintenir une livraison constante de valeur? Dans les projets qui ont ces problèmes, beaucoup de désagréments peuvent être facilement réglés à l’aide d’une bonne stratégie de découpage.
Diviser les récits utilisateur en petites tranches présente plusieurs avantages majeurs pour les équipes de développement. Cela permet de fournir de la valeur et de recevoir des retours des utilisateurs plus régulièrement, favorisant une amélioration continue. Les modifications plus petites au sein du code contribuent aussi à un design organique et évolutif, tout en réduisant le temps des cycles de développement. De plus, réduire la taille des récits utilisateur diminue les risques de régressions et réduit les coûts potentiels liés aux reprises, rendant le processus global plus efficace et fluide.
Si le découpage de tâches est si important, qu’est-ce qui définit une tâche bien découpée? Bill Wake a proposé en 2003 un acronyme qui représente un bon récit utilisateur : INVEST.
Independent : Les récits utilisateurs sont plus faciles à gérer lorsqu'ils sont indépendants. En d'autres termes, ils ne doivent pas se chevaucher au niveau des concepts et doivent pouvoir être planifiés et implémentés dans n'importe quel ordre.
Negotiable : Un bon récit utilisateur est négociable. Il ne constitue pas un contrat rigide concernant des fonctionnalités, mais sert de point de départ, dont les détails seront cocréés par le client et le développeur au cours du processus de développement. Un récit utilisateur de qualité capture l'essence de l'idée, sans s'attarder sur des détails trop précis.
Value : Un récit utilisateur doit apporter de la valeur. Cette valeur ne doit pas être simplement utile, mais spécifiquement bénéfique pour le client. Les préoccupations des développeurs peuvent être légitimes, mais elles doivent être formulées de manière à ce que le client les perçoive comme importantes et pertinentes.
Estimable : Un bon récit utilisateur doit être estimable. Il n'est pas nécessaire d'avoir une estimation parfaitement précise, mais une estimation approximative est suffisante pour permettre au client de prioriser et de planifier son implémentation.
Small : Dire « cela me prendrait plus d’un mois » implique souvent, de manière sous-jacente, « car je ne comprends pas tout ce que cela impliquerait ». Les récits utilisateur plus petits permettent généralement des estimations plus précises et une exécution plus rapide.
Testable : Un bon récit utilisateur doit être testable. La rédaction d'un récit utilisateur constitue une promesse implicite : « Je comprends suffisamment ce que je veux pour pouvoir rédiger un test à ce sujet. » Si un client ne sait pas comment tester une fonctionnalité, cela peut indiquer que le récit manque de clarté, qu’il ne reflète pas une réelle valeur pour le client ou que celui-ci a simplement besoin d’aide pour définir les tests.
Un second acronyme représentant les bonnes caractéristiques d’un récit utilisateur serait SMART, que mon collègue Dylan utilise plutôt dans le cadre de ses rétrospectives :
Specific : Les critères d’acceptation doivent être directement liés au besoin utilisateur à satisfaire. Un second mot pouvant faire partie de l’acronyme SMART est Simple. Un récit utilisateur doit être simple à comprendre : clair, précis et sans ambiguïté.
Measurable : Un bon récit utilisateur doit être quantifiable et qualifiable. Si ce dernier est vague ou sujet à interprétation, il risque d’échapper au contrôle et de nécessiter bien plus de temps que prévu pour être complété.
Achievable : L’objectif d’une tâche doit être raisonnable, afin de favoriser l’adhésion des participants. Une tâche qui décourage les développeurs avant même qu’ils ne commencent est un fort indicateur d’un récit utilisateur mal défini.
Relevant : Le récit utilisateur doit apporter une réelle valeur au produit. Une tâche qui se limite à satisfaire un «plaisir technologique» d’un développeur sans apporter de bénéfice concret au produit n’est pas pertinente.
Time-Boxed : Une tâche SMART doit inclure une estimation de temps clair. Bien qu’elle n’ait pas besoin d’être précise à la minute près, l’équipe doit s’entendre sur une durée approximative. Plus une tâche est grande, plus il devient difficile de l’estimer en temps, augmentant ainsi le risque de dépassements. Ces risques, comme mentionné précédemment, compromettent cette caractéristique essentielle d’un bon récit utilisateur.
Bien que ces acronymes offrent une ligne directrice sur la qualité des récits utilisateurs, il peut être difficile de bien séparer les tâches si cela est fait de manière anarchique. Examinons un ensemble de méthodes pour diviser le travail en respectant nos critères, tout en veillant à constamment livrer de la valeur à nos utilisateurs.
Mike Cohn, coach Agile et cofondateur de la Scrum Alliance, propose un nouvel acronyme (les acronymes sont décidément très populaires en informatique!) pour présenter cinq méthodes de séparation des tâches : l’approche SPIDR. Cette stratégie vise à livrer constamment de la valeur à l’utilisateur, quelle que soit la taille de la tâche.
Afin d’explorer les différentes méthodes associées à cette approche, prenons comme exemple une application de bibliothèque. Dans cette application, l’utilisateur peut effectuer une recherche dans la liste de livres. Votre prochaine tâche consiste à créer la page de détail du livre sélectionné dans la liste. Voici à quoi ressemble le récit utilisateur :
En tant qu’utilisateur, lorsque je clique sur un livre dans la liste, je veux voir son détail.
Critères d’acceptation :
Lorsque je clique sur un livre dans la liste, je souhaite voir une animation où le livre apparaît au centre de l'écran, s’ouvre, et affiche les détails du livre.
Je veux un indicateur de chargement sous forme de livre dont les pages tournent pendant que les détails sont en cours de chargement.
Je souhaite voir les informations suivantes sur le livre :
Couverture du livre
Titre
Auteur
Synopsis
Note moyenne des lecteurs (sur 5 étoiles)
Je veux avoir la possibilité de laisser une note sur le livre.
Lorsqu’on lit un récit utilisateur pour la première fois, il est important de se poser quelques questions :
À première vue, que pensez-vous de ce récit utilisateur?
Comment l’estimeriez-vous et combien de temps pensez-vous qu’il prendra à être complété?
Quel degré de certitude pouvez-vous offrir à vos parties prenantes (ou stakeholders)?
Si vous avez du mal à répondre à certaines de ces questions ou si les réponses semblent négatives, c’est le moment idéal pour appliquer l’une des méthodes de SPIDR.
Les "spikes" sont de petites implémentations de prototypes utilisées pour évaluer de nouvelles technologies. Elles impliquent la recherche et la création de nouvelles connaissances, permettant de mieux comprendre et de décomposer les récits utilisateurs.
Bien qu’abstraits, les spikes peuvent être efficaces lorsque les autres méthodes de SPIDR n’ont pas donné les résultats escomptés. Dans notre exemple de bibliothèque, il est possible que l’équipe de développement n’ait jamais réalisé de telles animations, comme celle demandée pour l’ouverture des détails lorsqu’un utilisateur clique sur un livre. L’équipe pourrait donc créer un spike pour explorer les manières de répondre à ce besoin et acquérir les connaissances nécessaires. Ce type de tâche aide l’équipe à mieux cerner l’ampleur du récit utilisateur.
Cependant, un des principaux risques avec les spikes, notamment pour les équipes débutantes, est leur durée. Certaines personnes ont tendance à creuser trop profondément dans leurs recherches, allant jusqu’à se perdre ou chercher des éléments inutiles par rapport à la tâche initiale. Bien que la méthode spike soit la seule des cinq méthodes à ne pas ajouter directement de valeur à l’utilisateur final, il reste essentiel d’appliquer les principes SMART à cette tâche.
Ainsi, un spike doit être spécifique et limité dans le temps. Lors de la création de cette tâche, il est crucial de définir clairement les connaissances que l’on souhaite acquérir et de fixer une durée maximale (par exemple, 2 heures).
Lorsqu’un récit utilisateur contient plusieurs chemins (“paths”) alternatifs possibles, il peut être utile de créer des récits distincts pour certains de ces chemins. En décomposant les récits, ceux-ci deviennent plus petits et plus faciles à estimer.
Un type courant de récit utilisateur dans les applications concerne le chargement d’informations provenant d’un serveur. Dans notre exemple de bibliothèque, il s’agit du chargement des détails du livre. Ce type de fonctionnalité comprend toujours deux chemins possibles : un chemin en cas de succès et un chemin en cas d’erreur. Plusieurs raisons peuvent mener à une erreur : le serveur ne répond pas, le livre n’est pas trouvé, l’utilisateur perd sa connexion Internet, etc. Malheureusement, c’est un chemin souvent oublié lors de la définition des critères d’acceptation.
Bien qu’il ne soit pas toujours indispensable de supporter les chemins d’échec dans une application, il ajoute de la valeur pour l’utilisateur d’être informé lorsqu’un problème survient. C’est pourquoi il peut être pertinent de créer un récit utilisateur distinct pour couvrir ces erreurs. Chaque chemin apporte une valeur ajoutée spécifique au produit et peut donc être traité séparément du chemin principal.
Astuce : Selon l’acronyme INVEST, chaque récit utilisateur devrait être indépendant des autres. Dans la plupart des cas, cette règle peut être respectée. Cependant, il arrive que certains récits nécessitent une base commune pour être implémentés. C’est un principe similaire à la construction d’une maison : il faut d’abord construire la fondation avant de poser les murs, puis les murs avant d’ajouter les fenêtres, l’électricité, l’isolation ou le toit. Tous ces éléments sont des fonctionnalités supplémentaires (ou "chemins" supplémentaires) qui nécessitent une base pour être réalisables.
Dans l’exemple des détails de livre, il faut au minimum avoir la page du livre et un système fonctionnel de chargement pour pouvoir gérer les erreurs. Malgré cela, certains récits utilisateurs liés à d’autres chemins peuvent être réalisés en parallèle, même pendant qu’on travaille sur la gestion des erreurs.
Au tout début du Web, les sites étaient constitués uniquement de documents et de pages HTML. Avec le temps, la stylisation et les animations ont fait leur apparition, rendant les sites plus attrayants visuellement. Le défi avec l’implémentation d’interfaces, c’est qu’il n’existe pas de limite claire quant à jusqu’où cela peut aller. L’ingéniosité et l’imagination humaine permettent de créer des interfaces très complexes.
Pour les interfaces, voici quelques questions à vous poser pour déterminer si un élément devrait être extrait dans sa propre tâche :
Prenons l’exemple de notre application de bibliothèque : est-ce que l’animation du livre qui s’ouvre pour afficher ses détails est indispensable pour l’utilisateur? Pas vraiment. Effectuer une simple navigation vers une nouvelle page serait plus simple, plus rapide à implémenter et répondrait au besoin. Cependant, il serait plus attrayant visuellement d’avoir l’animation, ce qui pourrait être considéré comme une valeur supplémentaire. On pourrait donc retirer l’animation du récit utilisateur initial et en faire un récit distinct dédié à l’interface.
De plus, dans les critères d’acceptation, on mentionne un indicateur de chargement animé lorsque l’application demande des informations au serveur. Cet indicateur est-il crucial pour le bon fonctionnement de la fonctionnalité? Pas nécessairement. Si le serveur répond extrêmement rapidement, l’indicateur pourrait être inutile, l’utilisateur n’ayant pas le temps de le voir. Alors, pourquoi investir du temps sur cette fonctionnalité? Avec la méthode interface, des éléments visuels comme l’indicateur de chargement pourraient être traités plus tard dans un récit distinct. Voici un exemple d’itération potentielle :
Pas d’indicateur de chargement.
Ajouter un simple texte "Chargement…"
Ajouter une icône animée.
Chaque étape produit une version fonctionnelle et valide de l’application Web. Avec les interfaces, il est toujours important de se demander jusqu’où aller et à quel moment le faire.
Astuce : Lorsque vous êtes limité dans le temps ou pensez ne pas pouvoir livrer tout ce qui est demandé, cette façon de diviser les récits offre une meilleure visibilité sur le travail à accomplir. Cela vous pousse également à réfléchir à ce qui apporte réellement de la valeur à l’utilisateur. Dans notre exemple, il est probable que des fonctionnalités utilitaires aient plus de valeur que des éléments purement visuels, comme des animations. En scindant les récits en plusieurs tâches, vous pouvez ensuite prioriser plus facilement, en minimisant le risque d’un retard de livraison en dépriorisant ce qui est moins essentiel pour l’utilisateur.
Un autre exemple de séparation par interface est de le faire selon les navigateurs (Chrome vs Firefox), les appareils (Android vs iOS) ou les résolutions (desktop vs mobile). Chacun de ces cas peut nécessiter un travail supplémentaire. Cependant, si vos utilisateurs sont en grande majorité sur une plateforme spécifique, il pourrait être inutile de consacrer des efforts sur les autres plateformes dès le départ. En créant des récits distincts liés à l’interface, vous gagnez en flexibilité pour prioriser le travail et vous pouvez déprioriser les interfaces moins utilisées.
Les récits utilisateurs peuvent être décomposés en se concentrant sur des sous-ensembles de données (“data”) pertinentes. Parfois, une entité du domaine de l’application est composée de plusieurs données qui, conceptuellement, représentent des informations différentes. Prenons comme exemple les détails d’un livre dans notre application de bibliothèque. La tâche demande d’afficher la couverture du livre, le titre, l’auteur, le synopsis et la note moyenne du livre. Nous pourrions ici diviser l’information en trois catégories :
Image numérique : Couverture du livre.
Données statiques : Titre, auteur et synopsis.
Données calculées : La note moyenne.
Chacune de ces trois catégories apporte une certaine valeur à l’utilisateur en fournissant des informations supplémentaires de manière spécifique. Nous pourrions donc créer trois récits utilisateurs distincts pour chacune de ces catégories.
Il est même possible d’aller plus loin en créant un récit par donnée statique, car l’obtention de certaines données peut être plus complexe que d’autres. L’essentiel est de se poser les mêmes questions que pour la méthode interface de SPIDR :
Cet élément de l’interface est-il nécessaire pour le fonctionnement de base du récit utilisateur?
Cet élément de l’interface ajoute-t-il une valeur supplémentaire à l’utilisateur?
Dans tous les projets, il existe toujours des fonctionnalités qui s’avèrent être de véritables boîtes de Pandore. Elles peuvent sembler simples à première vue, mais de nombreuses règles et conditions (“rules”) émergent au cours du développement. Lorsque cela se produit, la méthode rules de SPIDR propose d’extraire ces règles dans un nouveau récit utilisateur.
Bien que la fonctionnalité ne puisse pas être livrée aux utilisateurs sans ces règles, la livrer immédiatement n’est pas toujours nécessaire. Séparer les besoins en plusieurs récits permet de paralléliser les tâches et de progresser de manière itérative, tout en offrant une meilleure visibilité sur l’ampleur du travail. Il est possible que certaines règles ne soient pertinentes que dans 1 % des cas utilisateurs. En extrayant ces règles dans un récit distinct, on peut décider de les prioriser ou non dans le cadre du développement.
Mike Cohn donne l’exemple du développement d’une plateforme concurrente à YouTube. Les utilisateurs souhaitent pouvoir téléverser des vidéos sur leur chaîne. Cette fonctionnalité semble relativement simple, mais elle cache des règles métier complexes. Par exemple, les vidéos ne doivent pas contenir de musique protégée par des droits d’auteur. Inclure cette règle dès le départ rendrait la tâche massive et bien plus complexe qu’elle ne le paraît. C’est pourquoi Mike Cohn recommande de faire une première itération sans cette règle, puis de revenir dessus ultérieurement dans un récit utilisateur distinct.
Pour notre exemple de bibliothèque, ce principe peut également s’appliquer à l’ajout de notes sur un livre :
En appliquant les autres méthodes de SPIDR sur cette fonctionnalité, il serait même possible que le récit utilisateur initial ne fasse aucune mention du concept de note! Séparer ces règles complexes en récits distincts permet de mieux les prioriser et d’éviter de surcharger la tâche initiale.
Un des avantages sous-estimés de l’approche SPIDR est le sentiment de progression qu’elle procure aux développeurs. Cela vous est-il déjà arrivé de vous sentir démotivé lorsque, après plusieurs semaines, vous êtes toujours sur la même tâche et que, chaque jour en réunion quotidienne, vous voyez votre carte rester au même endroit, incapable d’avancer? Et, à l’inverse, avez-vous déjà ressenti un immense soulagement une fois cette tâche enfin terminée, comme si un énorme poids venait de disparaître de vos épaules?
Ces sentiments ne devraient pas avoir lieu. Ils n’apportent rien d’utile à la réalisation de votre travail. Bien que Frodon ait réussi à détruire l’Anneau, il n’aurait pas dû le porter seul jusqu’au bout de la Terre du Milieu. En tant que développeur, vous ne devriez pas vous retrouver dans cet état mental.
En divisant vos fonctionnalités en plusieurs petites tâches, vous ressentirez un véritable sentiment de progression chaque jour. Votre tableau de tâches bougera constamment vers la droite, et vous serez donc toujours en train de livrer de la valeur.
Ce sont les petits actes quotidiens des gens ordinaires qui maintiennent les ténèbres à distance. Des petits actes de gentillesse et d'amour.
— Gandalf le Blanc
(OK, j’arrête avec les références au Seigneur des Anneaux!)
En lien avec le point précédent, la division en petites tâches offre une meilleure visibilité aux responsables du projet. Que ce soit votre gestionnaire de projet, Scrum Master ou votre client (si vous travaillez en prestation de service), ils auront une meilleure compréhension de ce que vous faites. Il m’est déjà arrivé que mon gestionnaire me demande combien de temps il restait avant qu’une tâche soit terminée. Une tâche qui stagne dans la colonne "en développement" pendant plusieurs semaines ne fournit pas beaucoup d'informations.
À l’inverse, un travail divisé en plusieurs petits récits apporte une excellente visibilité sur l’ampleur du travail restant. Au lieu d’un récit qui s'étirerait sur trois semaines, le tableau pourrait afficher une dizaine de récits plus petits. La "grosseur" d’une tâche est une mesure subjective et sujette à interprétation, tandis que la quantité est une donnée objective et mesurable. Elle repose sur des unités standards, indépendantes des perspectives ou des opinions de chacun.
Cette approche rend plus évident, visuellement, l'avancement du travail pour vos gestionnaires ou vos clients. En d’autres mots, cela réduit le besoin de justifications. Le progrès devient visible pour tout le monde.
Qui dit plus de visibilité dit aussi plus de flexibilité. En effet, un seul récit utilisateur peut être représenté par un simple booléen : soit la fonctionnalité est livrée, soit elle ne l’est pas. Ce point reste vrai, peu importe la taille du récit. En revanche, une séparation détaillée du travail transforme ce modèle booléen en une liste de booléen. Cette liste peut ensuite être priorisée selon l’importance et la valeur ajoutée pour vos utilisateurs.
Ce bénéfice est l’un de mes préférés dans cette approche, car il me permet d’éviter de prendre des décisions qui ne me reviennent pas. Lorsque le projet a une date de livraison fixe et que l’équipe sait qu’il sera impossible de tout livrer, ce niveau de visibilité change complètement la dynamique. Je peux alors aller voir le gestionnaire et l’amener à prendre les décisions importantes. Plutôt que de recevoir la question typique "Comment faire pour que tout soit livré?", je peux inverser la conversation et demander directement : "Qu’est-ce que tu serais prêt à laisser de côté pour respecter la date de livraison?".
Avoir un ensemble de récits petits et bien définis offre davantage de contrôle au gestionnaire pour prioriser ce qui est crucial et ce qui l’est moins. Cette approche est particulièrement précieuse dans les projets de start-ups, où les budgets sont souvent restreints. Elle introduit une réflexion essentielle pour le client : "Il te reste X dollars de budget, préfères-tu que je travaille sur la fonctionnalité Y, ou que je peaufine la fonctionnalité Z?".
Un client qui a un meilleur contrôle sur son produit sera toujours plus satisfait du travail réalisé que s’il est laissé dans un vide d’information.
Avec le temps, j’ai remarqué que d'effectuer une séparation exhaustive des tâches aide les équipes à identifier rapidement des points bloquants ou à "lever des drapeaux" plus tôt dans le processus. Que ce soit pour des règles moins évidentes ou des interfaces encore non définies par l’équipe de design, l’approche SPIDR permet de lancer les réflexions et discussions nécessaires en amont du développement. Les équipes gagnent ainsi en efficacité en réduisant les temps morts causés par des questionnements en cours de réalisation sur certains éléments des récits.
Astuce : Des règles ou des chemins cachés seront toujours découverts en cours de développement, et cela est tout à fait normal. Lorsque cela arrive, ne modifiez pas le récit utilisateur en cours. Appliquez la méthode SPIDR pour créer un nouveau récit basé sur ce besoin découvert. Cela apportera une meilleure visibilité à l’ensemble de l’équipe, facilitera la priorisation et, dans certains cas, permettra de paralléliser les tâches.
Un dernier avantage que cette approche apporte aux équipes de développement concerne l’estimation. De nombreuses équipes à qui je présente SPIDR utilisent des approches comme les “Story Points” ou le “T-Shirt Sizing”. Bien que ces approches puissent être utiles pour estimer la vélocité, les unités de mesure qu'elles emploient sont souvent interprétées différemment par chaque membre de l’équipe. Ces estimations ont tendance à être trop spécifiques aux tâches à réaliser dans l’itération courante.
Par exemple, une équipe pourrait avoir une vélocité de 20 points en “Story Points” pour un sprint composé de 4 tâches de 5 points chacune. Mais cette vélocité n’aurait aucune pertinence dans un sprint comportant 20 tâches de 1 point. La relation entre la taille des tâches et la vélocité n’est pas linéaire lorsqu’on utilise les “Story Points”. Cela rend difficile l’utilisation de la vélocité comme référence fiable d’estimation sur le long terme.
En divisant le travail avec SPIDR, on remarque une tendance : la majorité des tâches finissent par être similaires en termes de taille. La plupart d'entre elles se situeront autour de 1-2 points en “Story Points” ou seront classées comme petites en “T-Shirt Sizing”. Lorsque toutes les tâches ont une taille comparable, une nouvelle métrique devient disponible pour estimer la vélocité : le débit.
Graphique du débit issu de notre produit, Axify.
En utilisant le débit comme métrique de vélocité, une équipe s’appuie davantage sur des données concrètes, qui laissent moins de place à l’interprétation. Il est difficile d’avoir une opinion divergente sur ce que représentent 5 tâches terminées. De plus, lorsqu’un bon raffinement des tâches a été réalisé en amont, il devient beaucoup plus simple d’estimer le temps nécessaire pour un ensemble de fonctionnalités. Enfin, en adoptant le débit comme mesure de vélocité, on élimine la nécessité d’estimer individuellement chaque tâche.
Astuce : L’exercice d’estimation en équipe, effectué à l’aide d’outils conventionnels comme les “Story Points”, a une valeur qui va bien au-delà de simplement attribuer un chiffre à une tâche. Il permet à l’équipe d’engager des discussions importantes sur des aspects moins bien compris de la tâche. Ces discussions émergent souvent lorsqu'il y a des divergences dans les estimations des différents membres de l’équipe. Cette dynamique reste valide avec le débit comme mesure de vélocité, mais elle se déplace au moment du raffinement des fonctionnalités en tâches plus petites.
Un retour fréquent lorsque je présente le débit comme outil de mesure est qu’il serait impossible de ramener toutes les tâches à une taille identique. Il y aura effectivement toujours des écarts entre des tâches plus grandes ou plus petites en raison de leur complexité. Et je suis tout à fait d’accord! En même temps, l’impact de ces variations sur les estimations reste minime, car ces différences tendent à s’équilibrer sur le long terme grâce aux moyennes et aux médianes.
L’approche SPIDR est bénéfique à tous les niveaux d’un projet de développement. Pour les développeurs, elle simplifie le développement en fragmentant les fonctionnalités en tâches plus petites et testables, réduisant ainsi les risques d’erreurs et permettant une rétroaction plus rapide. Pour les gestionnaires, elle apporte une visibilité accrue sur l’avancement du projet, facilite la priorisation des tâches et aide à prendre des décisions éclairées en cas de contraintes de temps ou de budget. Enfin, pour le client, cette approche garantit une livraison progressive de valeur, tout en lui offrant plus de contrôle et de flexibilité sur le produit final.