Adopter une approche Lean au développement de produits digitaux

Qu’est-ce qu’on entend par Lean ?

Le Lean est une approche de gestion qui vise à maximiser la valeur tout en minimisant le gaspillage grâce à une logique d’amélioration continue.

Cette philosophie a été éprouvée et popularisée dans le milieu industriel de la construction automobile, lorsque le système de production Toyota a révolutionné son marché jusqu’alors largement dominé par l’Américain Ford. En effet, Taiichi Ohno et Eiji Toyoda ont su trouver des méthodes pour construire des voitures de haute qualité, en quantité industrielle, et donc peu chères. (Lean Tech Manifesto, 2024)

Dans le contexte du développement de produits digitaux, le Lean vise à maximiser la création de valeur pour les utilisateurs en se concentrant sur l'élimination des inefficacités dans le processus de développement, ce qui permet de consommer moins de ressources (temps, budget, développeurs, etc…). Les artefacts du Lean sont si nombreux dans la culture de Theodo que je ne pourrais tous les citer (les Dojos pour se former, les Résolutions de Problème, le Andon, etc…). Le but de cet article est de vous donner des exemples concrets de comment je mets cela en œuvre au quotidien avec les équipes projets chez Theodo, en prenant un exemple que nous pouvons tous à peu près visualiser : des pièces de voiture.

Le Lean dans le développement de produit : zoom sur le Kanban

La fabrication d’une voiture passe par une chaîne de production qui contient plusieurs étapes, comme l'assemblage de la carrosserie, l'intégration du moteur, et l'ajout des systèmes électroniques, avant de recevoir une couche de peinture.

Dans mes équipes projet, je crée un Kanban : un tableau visuel qui reflète le flux de développement pour suivre l'état d'avancement des tâches. Tout comme une voiture progresse de station en station sur la chaîne de production, chaque ticket de développement passe par plusieurs colonnes du kanban Lean, représentant les différentes étapes du processus de développement : de la préparation et du développement à l'intégration et aux tests. Le travail qui doit être réalisé à chaque étape est explicitement défini, et l’état de la pièce à la fin de chaque étape est également clair pour l’équipe.

Voici comment cette analogie s’articule avec plus de détails :

1. Backlog refinement : Le product manager rédige des tickets de développement qui aboutiront à la fonctionnalité du produit qu’il conçoit. Cela permet de détailler et d'organiser les différentes tâches nécessaires à son développement de manière claire et gérable. L’équipe passe ses tickets en revue lors d’un atelier et tous les membres de l’équipe valident la clarté du ticket pour le faire avancer.
2. Technical refinement : L’équipe technique ajoute une stratégie technique pour réaliser la fonctionnalité exprimée dans le ticket. Le ticket est donc de plus en plus abouti.
3. Développement : Un membre de l’équipe développe la fonctionnalité du ticket en ajoutant les lignes de code nécessaires pour réaliser l’attendue. On peut voir ça comme la dernière étape de l’usine pour la voiture. La voiture est intégralement prête, tout comme les lignes de code qui donneront vie au produit existent à présent ! Ce n’est pourtant pas fini.
4. Contrôle qualité : Les voitures passent par un contrôle qualité rigoureux avant d'être expédiées. En développement logiciel, cela correspond aux revues de code et aux pipelines CI/CD qui détectent les défauts avant le déploiement. Si une erreur est détectée, que ce soit pour la voiture ou pour le ticket, la pièce reculera dans le flux !
5. Déploiement : La fonctionnalité est déployée aux utilisateurs de l’outil, la voiture commercialisée, c’est la fin du cycle de production.

Comment le Kanban nous permet-il de nous améliorer ?

Je n’ai jamais construit de voiture, mais je sais que c’est un bien physique, c’est tangible, et j’imagine donc qu’on peut le voir se rapprocher de son état final au fur et à mesure qu’il avance. Si un problème survient à une étape, ou si j’ai une étape trop lente où du stock s’accumule : je le vois et donc je le sais. Pour un algorithme, une data plateforme, ou un chatbot basé sur de l’intelligence artificielle générative - c’est plus compliqué ! En reproduisant le flux de production d’une voiture, le kanban rend le flux de développement visible pour toute l’équipe. À partir de là l’équipe peut :

• Détecter les problèmes de qualité : quand une pièce ne passe pas à l’étape suivante du flux.
• Détecter les problèmes de délai de livraison : quand trop de pièces s’accumulent à une étape.

Une fois que ces problèmes sont détectés, l’équipe peut les résoudre et mettre en œuvre des moyens pour que le problème ne survienne plus. C’est ça qui permet l’amélioration continue dans le Lean. Ce suivi visuel et structuré garantit donc que les tickets de développement avancent de manière fluide à l'image de l'assemblage méthodique et séquentiel d'un véhicule dans une usine, où chaque phase d'assemblage est essentielle pour aboutir à un produit fini de haute qualité.

Le Lean dans le développement de produit : zoom sur le poka yoke

Le kanban Lean permet donc de visualiser son flux de développement, comme les chefs ingénieurs chez Toyota pouvaient voir leur flux de production. Cela permet de visualiser les erreurs à l’étape où elles arrivent et donc de les résoudre plus vite et plus efficacement. Mais comment réduire le gaspillage sur ce flux ? Comment créer un environnement de travail sans faille pour livrer des produits technologiques vite et bien ? A quoi cela ressemble-t-il au quotidien ?

Poka Yoke : Dispositifs de sécurité dans le processus de production qui arrêtent automatiquement la ligne en cas d'erreur. Dans un sens plus large, le terme peut faire référence à toute contrainte de comportement conçue dans un processus pour empêcher toute opération incorrecte de la part de l'utilisateur.

Dans une chaîne d’assemblage, les Poka Yoke empêchent la voiture d’avancer dans le flux si une erreur d’assemblage a été commise. Par exemple, des boîtes de rangement d’outils faites sur-mesure pour les outils empêchent les employés de mal ranger les outils, voire même de les perdre. Les ouvriers suivants peuvent donc retrouver les outils à l’endroit attendu, sans perdre de temps pour les chercher - et la chaîne n’a pas besoin de s’arrêter inutilement pendant les x minutes.

Dans le développement de produit Lean, les Poka Yoke empêchent le ticket de développement d’avancer dans le flux s’il ne respecte pas les standards de qualité fixés par l’équipe. Par exemple, le linter est un outil logiciel qui analyse le code que l’on écrit, pendant qu’on l’écrit, pour détecter et signaler les erreurs de programmation comme l’utilisation d’une variable non-définie, et les violations des conventions de style de codage. Pensez aux correcteurs automatiques comme Grammarly, mais en plus évolué ! Grâce aux linters, comme Black, les développeurs ne peuvent pas faire avancer leurs tickets (la pièce produite) au stade suivant du kanban avec une erreur : le flux se bloque tant que la pièce n’est pas de qualité.

Extrait du Lean tech manifesto

Comment le Poka yoke réduit-il le gaspillage ?

Je reconnais qu’introduire un outil qui bloquera la chaîne de production, parfois contre le gré du développeur, peut être contre-intuitif ! Voici donc comment le linter, un des poka yoke de notre méthodologie Lean de développement de produit, permet de réaliser des réductions de gaspillage concrètes.

La photo ci-dessus, extraite du Lean tech manifesto, illustre très bien ce point : le linter a détecté une erreur de syntaxe qui pourrait introduire un comportement inattendu au produit, et le développeur devra trouver une solution avant de faire avancer son ticket dans le flux. Sans linter, l’équipe aurait eu une experience différente :

• Dans un sénario optimiste cette erreur n’aurait pas échappé à la revue de code du second développeur, ou encore aux tests fonctionnels passé au stade de validation. L’équipe aurait alors du retravailler et refaire passer tout ce flux une fois cette erreur corrigée : elle aurait perdue 1~2 jours pour le développement de cette feature. On estime donc autour de 1000€ cette erreur de développement.
• Dans un sénario moins optimiste, l’erreur n’aurait été détecté ni dans la revue de code, ni lors des tests fonctionnels, et elle aurait été déployée pour les utilisateurs du produit. La loi de murphy nous apprend que cette petite erreur de code aurait inévitablement gâché l’experience d’un utilisateur. L’équipe aurait alors dû alouer du temps de run pour résoudre ce bug. Sans linter, il est probable que le développeur qui se charge du ticket de run n’ait pas les même pratiques de code (formatage, naming etc…) ce qui rendrait la reprise du code de son prédécesseur complexe.

Chez Theodo, chaque projet contient des Poka yoke (y compris des linters) car à l’échelle d’un projet entier, le linter permet d’identifier des dizaines de défauts comme celui-ci. Cela nous permet donc d’augmenter la qualité des produits que nous livrons et la rapidité à laquelle nous les développons !

Conclusion

Adopter une approche Lean au développement de produits permet d'optimiser les ressources, d'améliorer la qualité, et de fournir plus rapidement de la valeur aux clients. En intégrant des outils du Lean comme le Kanban, qui visualise le flux de travail, et le linter, qui agit comme un poka-yoke pour le code, les équipes peuvent identifier et corriger rapidement les problèmes, qu'ils soient de qualité ou de délai. En mettant en œuvre ces principes, nous créons non seulement un environnement de travail plus fluide, mais nous favorisons également une amélioration continue essentielle pour répondre aux besoins des utilisateurs. Pour approfondir ce sujet, je vous recommande vivement Le Lean Tech Manifesto, écrit par les 2 confondateurs de Theodo. Le livre offre de nombreux leviers pour réussir le passage à l’echelle de la culture Lean, orientée vers la satisfaction client et la réduction du gaspillage. Si vous avez des retours ou simplement envie d'échanger sur ce sujet, n'hésitez pas à me contacter !