Développement produit Agile : la technologie peut-elle dynamiser le monde de la production ?
Depuis le début des années 2000, le développement logiciel Agile a vu sa popularité s’accroître de manière exponentielle, alors que jusqu’à présent, la production d’objets restait sur la touche. Mais la partie est loin d’être jouée. Aujourd’hui, les principaux acteurs se demandent « comment la méthode Agile pourrait s’appliquer au développement de biens matériels ».
Cette question, malgré ses bonnes intentions, sous-tend que l’activité de production devrait adapter la méthode Agile au développement d’objets et de pièces. Mais forcer les principes et les pratiques logiciels à s’adapter à la production de matériel a vraisemblablement plus de chance de produire des méthodes peu adaptées, voire impraticables. Reformulons la question : « Quels inconvénients rencontrés dans le développement de produits manufacturés pourraient être supprimés par des procédures inspirées de la méthode Agile ? »
Qu’est-ce que la méthode Agile avec un grand A ? Selon l’Agile Alliance, « le développement logiciel Agile est une expression créée pour désigner un ensemble de méthodes basées sur des valeurs et des principes, définis dans le manifeste Agile. Les solutions émergent de la collaboration entre des équipes aux compétences transversales et auto-organisées, se servant de pratiques adaptées à leur contexte. »
Ces valeurs et ces principes fournissent le cadre théorique pour des méthodes de développement logiciel, à l’instar du scrum, la méthode Agile la plus courante. Dans cette « mêlée » (le « scrum » est une image empruntée au rugby pour décrire ce mode de progression), des équipes de cinq à neuf personnes réalisent des éléments du journal de produit (ou « product-backlog items ») dans des itérations appelées « sprints ». Ces éléments du journal peuvent être des fonctionnalités, des besoins, des scénarios, etc. et un sprint dure généralement de deux à trois semaines. À la fin de chaque sprint, l’équipe doit terminer le projet et en présenter le résultat au client afin d’avoir son opinion.
Le processus traditionnel
Lorsqu’on pense aux idées d’Agile pour la production d’objets, il convient de se tourner d’abord vers le processus traditionnel de développement produit (appelé aussi « modèle en cascade ») avec l’exemple du drone-livreur de colis, tiré du projet Amazon Prime Air.
Exigences élémentaires de ce drone : il doit être capable de livrer des colis d’environ 2,2 kg, sur une zone de 10 km en 30 min ou moins (de la commande à la livraison), il ne doit pas causer d’accidents, il doit être conforme aux réglementations nationales et il doit pouvoir notifier le vendeur et le client du statut de la livraison.
Pour une équipe suivant le modèle en cascade, le processus de développement du drone est principalement linéaire. Chaque phase ne commence que lorsque la précédente est achevée. Conception > Fabrication > Utilisation. Le détail des spécifications du produit, c’est-à-dire les exigences et les normes que l’objet doit respecter, est défini au début et sert à la phase de conception, lors de la génération et de l’analyse des différentes options. Le projet sélectionné entre dans la phase de fabrication qui est planifiée et exécutée. Le déploiement du drone terminé vers le client lance la phase d’utilisation, qui comprend le fonctionnement et l’entretien.
Dans la réalité, un processus aussi strictement linéaire est rarement appliqué. Souvent, les équipes suivent un processus circulaire, dans lequel des itérations sont produites avec des retours d’expérience du client, mais seulement dans une phase donnée. Par exemple, le drone peut subir plusieurs itérations pendant la phase de conception et plusieurs options peuvent être considérées pendant la phase de fabrication. C’est une amélioration du modèle linéaire, mais il s’agit encore du modèle en cascade (appelé aussi « scrumfall », contraction de « scrum » et de « waterfall », cascade en anglais).
Dans tous les cas, le modèle en cascade présente trois inconvénients principaux :
1. Il suppose que le cahier des charges n’évolue pas. Le modèle en cascade repose sur un processus prévisible qui est planifié et exécuté sans surprise ou adaptation notable, les exigences du client étant figées dès le début. L’hypothèse que le cahier des charges n’évoluera pas n’est, au demeurant, presque jamais vérifiée. En effet, les nouvelles technologies, les découvertes et les variations du marché constituent une source permanente de changement.
2. Le retour d’expérience client arrive trop tardivement. Ici, l’interaction avec le client a lieu globalement en amont, lorsque l’équipe recueille ses exigences. Une fois que le document des spécifications du produit est terminé (et figé), l’équipe se met au travail. Mais les clients savent rarement ce qu’ils veulent exactement au début d’un projet, c’est donc la formule idéale pour manquer son but : le mauvais objet au mauvais prix et au mauvais moment, même si les spécifications sont respectées.
3. Trop de théorie sans mise en pratique. Dans le modèle en cascade, le statut du projet est plus ou moins « verrouillé » lorsqu’on passe à la phase de fabrication. C’est problématique, car l’équipe va certainement apprendre des choses au cours de la phase de production qui pourront avoir une incidence sur le projet, et le client n’aura rien vu de l’objet concret avant la validation. Rappelons que les modifications sur un projet validé sont difficiles et coûteuses à réaliser.
Maintenant, rapportons ces inconvénients au contexte s’appliquant au drone : quelques semaines après le début du projet, le client apprend qu’un concurrent développe un drone capable de livrer des colis de 2,2 kg en 20 min. À ce moment, le projet est « bouclé » et la phase de fabrication déjà bien entamée. Modifier le cahier des charges aux exigences du concurrent impliquerait de repenser la structure du drone, de refaire les analyses de certification, de redessiner les plans de production, etc. Retour à la case départ !
Aussi, l’équipe a supposé que le drone devrait avoir la capacité de livrer des colis de différentes formes. Mais lors de la présentation des cinq études de projet qui avaient déjà été générées, simulées et rendues, le client a finalement précisé que le drone livrerait des colis se trouvant dans des boîtes étanches à la taille définie. C’est beaucoup de temps et de ressources perdus à mettre sur le compte d’un manque de retour du client.
Et finalement, pendant la phase de fabrication, les concepteurs se sont rendu compte qu’ils pourraient imprimer la structure en 3D en modifiant sa forme, peut-être même à l’aide de la conception générative. La fabrication additive réduirait le poids et le temps d’assemblage, mais impliquerait de nombreuses modifications du projet validé, engendrant des coûts. Et 1, et 2, et 3-0, le modèle en cascade s’incline.
Un processus inspiré de la méthode Agile
Au vu de ces inconvénients, il est primordial de résister à la tentation « d’appliquer » le tout Agile au développement technologique. Simplement, quelques pratiques et principes issus de la méthode Agile (principalement du scrum), adaptés aux objets manufacturés, peuvent suffire :
1. Itérations de sprints. Les sprints pourraient sans doute apporter le plus d’avantages au développement d’objets, en ce qu’ils forcent les équipes à passer les cycles conception-fabrication-utilisation plus tôt, plus vite et pour des parts plus petites du projet. La progression s’effectue de gauche à droite. Les sprints apportent une solution aux trois inconvénients du modèle en cascade : ils évitent aux équipes de rester trop longtemps dans une mauvaise voie, raccourcissent le temps entre le projet et sa réalisation et offrent l’occasion de réviser les exigences en fonction des leçons tirées de chaque sprint.
La possibilité de reporter des décisions cruciales de conception à une phase ultérieure est un autre avantage de taille. Dans le modèle en cascade, toutes les décisions de conception sont prises au cours de la phase de projet, avant de passer à la fabrication. En revanche, une équipe qui travaille avec la méthode Agile peut repousser certaines décisions à un moment où les données réunies sont suffisantes, après plusieurs sprints.
2. Pas de document statique de spécifications produit. À la place, les exigences sont captées dans les éléments hiérarchisés de journal de produit. Elles doivent être utiles, pratiques et dimensionnéesafin d’être livrables en un sprint, négociable et vérifiable. Elles doivent contenir le qui, le quoi et le pourquoi. Au lieu de demander « Que souhaitez-vous que votre objet fasse ? » (donnant lieu à une liste d’exigences), demandez, « Que souhaitez-vous faire avec votre objet ? » (donnant lieu à des utilisations vérifiables).
3. Équipes collaboratives. La méthode Agile redéfinit la structure et les rôles au sein de l’équipe de développement produit. En lieu et place d’équipes divisées par spécialité (conception, analyse, production, etc.), Agile préconise de petites équipes aux compétences transversales, auto-organisées, autogérées et collaboratives. Une équipe assume la responsabilité de terminer un élément de journal de produit dans un sprint donné. Une équipe de scrum, par exemple, est composée uniquement d’un product owner(propriétaire du quoi) ; d’un scrum master(qui gère le processus) ; et d’équipes de développement (qui font le travail).
4. Des livrables plus sommaires tout au long du processus. Les opposants à l’utilisation de la méthode Agile dans la production rétorqueront que, à l’inverse des logiciels, fabriquer un prototype à la fin de chaque sprint n’est viable ni économiquement ni dans la pratique. C’est passer à côté de la vérité : produire un résultat physique (le « release ») n’est pas le seul moyen de réaliser des progressions graduelles. Les simulations informatiques, les démonstrations en réalité virtuelle, les jumeaux virtuels et les prototypes conceptuels constituent des résultats de qualité. La clé est de distribuer les éléments de journal de produit afin qu’à la fin de chaque sprint, les résultats présentés par chaque équipe soient significatifs. Les éléments peuvent être distribués de nombreuses manières, par exemple, par niveau de fidélité (de brut à définitif), par niveau de contenu virtuel vs physique, ou par rôle d’utilisateur.
La méthode Agile en pratique
Les problèmes rencontrés par l’équipe du drone avec le modèle en cascade auraient pu être évités grâce aux pratiques inspirées de la méthode Agile. Tout d’abord, les répercussions dues aux modifications des exigences auraient pu être réduites au moyen de l’ingénieuse planification des sprints, laissant pour plus tard les problèmes de structure. Ensuite, l’hypothèse (erronée) que le drone manipulerait des colis aux formes variées aurait pu être corrigée plus tôt. Pour finir, la découverte de la possibilité d’imprimer la structure en 3D serait intervenue avant.
Un pari gagnant ! Certes, mais la méthode Agile n’est pas infaillible. Ses pratiques peuvent dériver si elles ne sont pas exécutées et encadrées correctement. Cela dit, utiliser des sprints, suivre des scénarios au lieu des spécifications et autonomiser les équipes, contribuera à rendre l’avenir du développement produit toujours plus Agile.