Repenser la R&D chez Somfy

Le département R&D de Somfy se met au lean engineering pour combler les écarts de connaissance, améliorer la collaboration et développer innovation et compétence technique.

Être leader sur le marché aujourd’hui ne signifie pas que vous le resterez demain. C’est un défi permanent pour Somfy, pionnier français des volets roulants motorisés et aujourd’hui spécialiste mondial des équipements connectés pour la maison, des volets roulants aux stores et rideaux, en passant par les portails et portes de garage, les serrures, le chauffage, l’éclairage, les caméras et les alarmes.

Je viens voir Somfy aujourd’hui dans les Alpes, plus précisément à Cluses, une ville qui fournit depuis longtemps l’industrie horlogère suisse voisine (Genève n’est qu’à 45 kilomètres). En 1969, alors que le décolletage et l’usinage de haute précision prospéraient autour d’eux, Somfy a inventé le moteur tubulaire qui allait remplacer les manivelles manuelles des volets.
Je rencontre Sébastien Fonta, vice-président R&D du groupe Somfy, et Jean-Christophe Deshayes, Manager R&D. Certaines équipes R&D ont expérimenté le lean en ingénierie au cours des deux dernières années, et je suis impatiente de découvrir ce qu’elles ont changé et appris. Sébastien a une expérience dans le domaine des opérations et connaît donc bien le lean en production. Lorsqu’il est passé à la R&D, il s’est cependant vite rendu compte que le rythme des projets, l’interdépendance entre des livrables complexes, la variabilité du contenu des tâches et la masse de problèmes techniques à résoudre rendaient très difficile l’application des concepts et outils de performance utilisés sur les flux de production. C’est pourquoi Sébastien et Jean-Christophe ont fait appel à Cécile Roche, experte en ingénierie lean.

ACCROITRE LA COMPETENCE PRODUITS

Pour en savoir plus sur cette nouvelle approche, j’accompagne Jean-Christophe chez Linda, qui gère un projet représentatif de ce que les équipes ont accompli au cours des deux dernières années. Jean-Christophe est le facilitateur enthousiaste de l’approche Lean en Ingénierie chez Somfy R&D.
La stratégie R&D actuelle de Somfy est de créer des objets techniques réutilisables d’un projet à l’autre, appelés briques techniques, afin de prévenir les risques liés aux nouveaux équipements, de gagner du temps dans le développement et de réduire les coûts.

À l’heure actuelle, m’explique Jean-Christophe, sur les 120 projets R&D, environ 20 % dont celui de Linda, développent des briques, le reste étant consacré à de nouveaux produits ou de nouvelles solutions. Les solutions cherchent à résoudre un problème rencontré par l’utilisateur final en combinant différents produits (actionneurs, capteurs, logiciels, connectique). Par exemple, une fenêtre connectée qui s’ouvre automatiquement pour aérer la pièce lorsque les capteurs en détectent le besoin.

Les briques peuvent être développées in-cycle, dans le cadre d’un projet de nouveau produit ou de nouvelle solution (la brique de Linda, par exemple, est créée dans le cadre d’une solution de store intérieur) : l’intérêt est de se confronter tout de suite à la réalité du client, car elle doit être livrée dans le cadre d’un projet réel.
Les briques peuvent également être développées off-cycle, avec moins de pression pour la mise sur le marché, mais avec le risque de détecter tardivement une inadéquation au besoin usager.
Linda explique que le module sur lequel son équipe travaille est un petit moteur pour stores intérieurs : le tube ci-dessous contient le moteur lui-même, le réducteur (qui réduit la vitesse du moteur de 3 000 tr/min à 20 tr/min pour créer un effet de couple) et la carte de commande. Elle a apporté un prototype afin que je puisse comprendre les différentes pièces qui le composent – un bon ingénieur en design aura toujours le produit en main lorsqu’il discute de problèmes.

Lorsque Cécile, leur sensei lean, est intervenue, le projet motor brick était source de tensions car il prenait du retard, compromettant ainsi la livraison globale du projet. L’équipe était loin d’être sereine. Cécile décida de recentrer l’équipe sur les attentes de valeur des clients.

Évaluer ces attentes représente souvent un véritable défi en ingénierie, car les ingénieurs design rencontrent rarement les utilisateurs de leur produit. Les clients ultimes de Somfy sont les usagers des stores ou des volets, et il y a toujours un intermédiaire qui fournit la solution : les fournisseurs de volets ou de portails, par exemple, intègrent la motorisation dans leurs propres produits ; les installateurs spécialisés l’installent dans les bâtiments neufs ou les maisons existantes ; les magasins de bricolage ou en ligne proposent des moteurs, capteurs ou kits de connectivité.

Les problèmes les plus importants des clients, s’il y en a, sont traités par les ingénieurs qualité de Somfy, et non par le département R&D.

L’équipe parvint néanmoins à réunir les spécialistes du marketing autour d’une table pour discuter des attentes des utilisateurs finaux. Sans surprise, le bruit s’avéra un point critique : comme ils conçoivent un petit moteur pour des stores d’intérieur, celui-ci doit être aussi silencieux que possible.
Le prototype n’était malheureusement pas silencieux, et ils ne savaient pas pourquoi. C’est ce que Cécile appelle un gap de connaissance, quelque chose qui doit être identifié et éliminé le plus tôt possible dans le projet.

IDENTIFIER ET ELIMINER LES GAPS DE CONNAISSANCE

L’équipe s’est livrée à une session approfondie de résolution de problèmes, en examinant tous les éléments à l’intérieur et à l’extérieur du tube – tels que la commande électronique du moteur, afin de comprendre comment ils pouvaient interagir. Cela lui a permis de réaliser un diagramme d’influence causale, montrant quelle décision relative au matériau ou à la conception avait un impact sur quoi. Les arbres des causes constituent une étape clé dans l’investigation d’un problème, car ils permettent une analyse approfondie de tous les facteurs potentiels. À partir de là, il est possible de discuter des hypothèses que l’on souhaite tester.

Les diagrammes d’influence causale sont aussi une étape clé pour mieux comprendre un produit, ses interdépendances, comment les options et les décisions prises à un stade donné peuvent avoir un impact sur d’autres parties du produit et son intégration globale. Le lean en ingénierie nous apprend à nous concentrer sur « ce que nous ne savons pas » et à creuser en profondeur jusqu’à ce que nous puissions prendre la bonne décision.

Il s’est avéré que le problème de bruit avait des causes mécaniques, qui pouvaient être corrigées rapidement. Linda sourit : « Cela nous a ouvert les yeux. Cela nous a permis d’adopter une approche systématique pour identifier nos lacunes, nous a obligés à discuter et à apprendre les uns des autres, à noter ce que nous savions et ce dont nous n’étions pas sûrs. »

MA SOLUTION EST SOUVENT LE PROBLEME DE QUELQU’UN D’AUTRE

Les arbres de causes constituent une excellente occasion de développer vos compétences lorsque vous parvenez à discuter avec des experts issus de différents domaines (dans le cas présent, la mécanique, l’acoustique, l’électromagnétisme ou les logiciels). Tous les chefs de projet que j’ai rencontrés lors de ma visite chez Somfy disent la même chose : c’est en discutant en profondeur des influences causales et des interfaces avec des experts que l’on apprend son métier. La seule difficulté, selon Linda, est de « réunir les experts autour d’une table. Ils sont tous très occupés et ne se déplacent que si nous avons un problème ».

Mais n’est-ce pas là l’essence même du jidoka ? Repérer un problème (une lacune dans les connaissances), tirer l’andon et creuser le point avec l’aide de personnes compétentes.

La confrontation des différents points de vue des différentes parties prenantes peut être extrêmement utile dans un projet. Linda explique que Cécile les a encouragés à travailler sur les changements, qui sont bien sûr nécessaires dans un projet, mais qui peuvent devenir un véritable casse-tête. Les changements de conception mal communiqués peuvent avoir des conséquences indésirables. Les changements de périmètre demandés par un client, ingénieur ou marketeur, s’ils sont systématiquement acceptés, peuvent compromettre le projet en termes de qualité et de délais.

Il est donc primordial de s’assurer que tous les changements, qu’ils soient mineurs ou majeurs, sont suivis et discutés, et que toutes les parties prenantes peuvent vérifier leur impact sur leurs propres livrables. Linda a utilisé un modèle simple, mais a constaté à sa grande surprise, une fois celui-ci rempli, qu’un changement de matériau sur l’axe du rotor avait été décidé à l’insu de l’expert. Les performances électromagnétiques et du moteur pouvaient ainsi être compromises.

Linda confirme que le modèle est toujours utilisé régulièrement par l’équipe et qu’il alimente les discussions. Parvenus à la phase de prototypage, ils ont de nouveau eu des problèmes de bruit, mais ont rapidement réussi à en trouver les causes :

• L’assemblage du prototype avait été réalisé rapidement pour permettre aux équipes en charge du logiciel de vérifier leur développement. Certaines pièces ont ainsi été déformées quand elles ont été poussées dans le tube, d’où le bruit.
• Le logiciel utilisé pour les prototypes n’envoyait pas les bons signaux.

Jean-Christophe renchérit : « Le suivi et les échanges sur les changements présentent un autre avantage. Nous avons vu des personnes devenir très émotives pendant les projets, affirmant qu’elles n’étaient pas écoutées et prédisant que nous allions échouer. Cécile leur a demandé d’évaluer elles-mêmes la probabilité du risque si rien n’était fait, puis les contre-mesures possibles, et enfin la probabilité du risque une fois les contre-mesures mises en place. Faire preuve d’empathie tout en ramenant la conversation aux faits et aux données fut un bon point de départ pour poursuivre la discussion et la collaboration. »

UNE SEQUENCE DE DECISIONS CLES

Le lean engineering, nous l’avons vu, avait déjà aidé Linda à créer des occasions de collaboration à intervalles réguliers et à avoir des conversations approfondies avec les principales parties prenantes sur les gaps de connaissances, la résolution de problèmes, les changements et les risques associés.
Mais il fallait aller plus loin. Les projets sont trop souvent réduits à une série de livrables, de tâches à accomplir dans un délai imparti : vous devez produire des dessins CAO, de la documentation, des nomenclatures, des contrôles qualité, des tests. Mais, si on y réfléchit bien, un projet est surtout une succession de décisions sur le produit et le processus. Si vous êtes un familier des projets d’ingénierie ou d’informatique, peut-être haussez-vous les sourcils : « Oui, bien sûr, n’est-ce pas le rôle des roadmaps de projet ?»

Même lorsqu’ils sont conçus avec les meilleures intentions, les systèmes de roadmaps avec passage de gates se transforment rapidement en bureaucratie. Franchir une gate signifie bien souvent produire une documentation qualité ou une multitude de spécifications, plutôt que discuter des options techniques du produit ou de l’architecture, susceptibles de couvrir au mieux les attentes des clients.

Un projet de développement produit fourmille en effet de décisions structurantes. Savoir quand les prendre et comment s’organiser pour le faire est le meilleur moyen de limiter les coûts et respecter le délai prévu de mise sur le marché.

Cécile a donc demandé à Linda et à l’équipe de travailler sur ces décisions techniques, même si le projet était déjà bien avancé :
• Quels sont les gaps que nous avons encore (sur les attentes des clients, sur le produit, le logiciel, l’acoustique, etc.) ?
• Quand allons-nous les combler et quelle décision devrons-nous prendre à ce moment-là ? Cécile a encouragé l’équipe à envisager plusieurs options, une approche contre-intuitive puisque notre cerveau veut économiser de l’énergie et, à la première solution trouvée, passer rapidement à la partie exécution.
• La discussion suivante a porté sur comment et quand choisir une des options retenues, et si l’équipe devait creuser certaines d’entre elles en parallèle, avant de pouvoir choisir. Cela permet de définir la séquence de décisions techniques clés à adopter, d’identifier les dépendances entre ces décisions et dans quel ordre les prendre.
Travailler sur la séquence des décisions techniques clés est une autre occasion de se recentrer sur le client, l’utilisation et l’apprentissage. En d’autres termes, de prendre du recul par rapport à la liste interminable des livrables.

ACCROITRE LA COMPETENCE EN COLLABORATION

Cette collaboration sur la séquence des décisions techniques clés est la colonne vertébrale du pull scheduling (planification en flux tiré). Comme mentionné ci-dessus, l’approche traditionnelle d’un projet consiste à terminer des tâches à des dates butoirs données. À l’inverse, le pull scheduling se concentre sur le flux de connaissances, à des intervalles beaucoup plus courts.

Dans l’exemple ci-dessous, extrait du livre de Cécile et de Luc Delamotte, Le Lean en Ingénierie – guide de voyage, l’interaction entre les décisions clés et les unités de connaissances à tirer en temps et en heure pour y arriver est explicite. L’équipe Système Antenne (en vert) doit décider quel émetteur de puissance utiliser avant la fin de la semaine 18 et tirera du Service Industrie (en jaune) le résultat de la comparaison entre les émetteurs de puissance 50 W et 100 W. Le Service Industrie aura lui-même tiré de l’équipe Système Antenne, avant la fin de la semaine 17, l’information sur les contraintes environnementales.

Les discussions sur le pull scheduling ont eu un effet considérable sur l’équipe de projet de Linda :

1. Le pull scheduling apporte du sens et une direction, car toutes les activités sont directement liées aux décisions clés à prendre.
2. Il met en évidence quand une information sera nécessaire et à quelle fin. Cela nécessitera des discussions (voire des négociations), mais créera un sentiment d’engagement une fois qu’un accord aura été trouvé. Il s’agit d’un véritable exercice d’empathie cognitive : vous ne partagez peut-être pas le point de vue de l’autre, mais au moins vous comprenez ce dont il a besoin pour avancer.
3. Elle implique toutes les parties prenantes, et pas seulement l’équipe centrale du projet.

En d’autres termes, le pull scheduling déclenche la collaboration sur les bons sujets, tout comme le jidoka sur une chaîne de montage concentre les priorités du management sur la qualité (« Il y a un problème avec cette pièce ») et la livraison (« Je ne peux pas faire l’assemblage à temps »), plutôt que sur les réunions, un processus interne à améliorer ou un rapport à préparer.
De plus, ajoute Linda, « nous consignons le résultat de chaque décision clé et la raison pour laquelle elle a été prise, dès que nous la prenons. Si des problèmes surviennent à un stade ultérieur, cela constitue un outil fiable pour retracer les choix que nous avons faits et à quel moment ». Sans parler d’une excellente occasion de capitaliser les connaissances.

Se concentrer sur les décisions clés et discuter du pull scheduling est une autre occasion de se réunir et de réfléchir aux changements de périmètre : comment ceux-ci affectent-ils notre séquence de décisions ? Quelles gaps supplémentaires devons-nous combler ? Pouvons-nous le faire tout en maintenant le projet sur la bonne voie ? Pouvons-nous reporter ce changement de scope ? A défaut, que pouvons-nous reporter d’autre ?
Jean Christophe le confirme : « Nous avons fait des statistiques sur les causes de retards et, comme Cécile l’avait prédit, la plupart des décalages dans le planning proviennent de modifications tardives, de nouvelles technologies ou des deux. Nous avons appris à mieux gérer ces décisions ».

FAIRE UN TEST, APPRENDRE UN TRUC

« Le projet s’est déroulé plus sereinement après cela », explique Linda. Il est désormais en phase d’industrialisation et le client interne – le chef de projet chargé de l’actionneur des stores intérieurs – est désormais beaucoup plus confiant dans les performances du moteur.

Linda se souvient d’une autre session finale intéressante avec Cécile : ils devaient tester la viabilité totale du produit, composants compris. Mais personne ne semblait vouloir prendre la responsabilité des tests d’intégration finaux. Un projet, par définition, ne peut avancer qu’en découpant l’éléphant (le produit ou la solution finale) en petits lots : d’abord parce qu’une technologie donnée (mécanique ou logicielle, par exemple) nécessite une expertise spécifique ; ensuite, parce que c’est plus simple ainsi. Quand tout est prêt, cependant, il faut tester l’intégration des différents éléments et vérifier que l’ensemble fonctionne comme prévu.

Linda me montre des photos prises à l’époque : « Encore un moment de grande collaboration. Nous avons commencé à rédiger la séquence des tests, comme nous l’avions fait pour la séquence des décisions, en testant progressivement l’ajout d’un élément ou d’un module à la fois. Comme l’a dit Cécile, « on n’apprend pas en testant tout en même temps, il faut procéder étape par étape et apprendre pas à pas ».

Au moment où nous quittons Linda, elle a une dernière remarque : « Nous ne pouvons pas continuer à gérer les problèmes au fur et à mesure qu’ils surviennent et être pris au dépourvu lorsqu’ils se présentent. Nous devons prendre le temps, dès le début, avec toutes les parties prenantes, d’identifier les décisions clés à prendre, les gaps à combler et les compromis nécessaires. Les décisions et les événements clés permettront ensuite de répartir les tâches en fonction des besoins. Ce n’est pas une perte de temps si vous voulez avoir l’esprit tranquille. Il y aura toujours des imprévus techniques, mais ils seront plus faciles à gérer ».

DEVELOPPER LE CAPITAL INTELLECTUEL

En fin de visite, nous débriefons avec Sébastien et je lui demande si son expérience avec Cécile l’a fait changer d’avis. Il confirme qu’en deux ans, il est passé d’une « approche KPI centrée sur la livraison des projets dans les délais » à la conviction que « puisque les ingénieurs aiment l’idéation, l’innovation et les solutions intelligentes, nous devons leur donner envie d’apprendre ». Il considère désormais le lean en Ingénierie comme une opportunité d’accroître les compétences tant sur le produit que sur la collaboration, à tel point qu’elle fait désormais partie intégrante de la stratégie R&D de Somfy.

Jean-Christophe abonde dans ce sens : « Les équipes ont accepté d’être interrogées et challengées pendant ces sessions, et de travailler dur, car les outils étaient pertinents et qu’elles voyaient des résultats significatifs et positifs pour leur projet. Elles ont développé leur capacité à identifier et à discuter des bons sujets ; elles ont appris les unes des autres et ont renforcé leur collaboration. La différence est on ne peut plus évidente. »
Le développement des compétences humaines est, ou du moins devrait être, une préoccupation majeure dans toute organisation. L’IA offre et continuera de développer de multiples moyens de calculer plus rapidement, de réagir plus vite, d’identifier les facteurs et les causes de manière plus systématique. Mais elle ne peut pas faire de kaizen, définir une stratégie ou développer un avantage concurrentiel pour nous. Elle n’a aucune empathie pour les clients ou les fournisseurs, et elle ne vérifie pas les conditions de travail des employés. Les humains, eux, le font.

Catherine Chabiron

Article paru en mai 2025 dans Planet-Lean.com