Shift-left sur le QA : une nouvelle approche de l’assurance qualité

Dans plusieurs de nos projets, nous avons travaillé dans des environnements de co-développement, où nos équipes collaboraient avec des équipes externes, des clients ou différents départements au sein de l’entreprise. Ces configurations ont souvent introduit des complications supplémentaires : attentes divergentes, différences dans les processus de travail et désalignement des responsabilités en matière d’assurance qualité. De nombreuses équipes ont été confrontées à des problèmes similaires : détection tardive de bogues, manque de clarté des exigences et corrections coûteuses dues à des changements de dernière minute.

Au fil de nos expériences, nous avons réalisé qu’une approche plus structurée était nécessaire pour éviter que ces problèmes ne se reproduisent. C’est là que l'appeoche shift-left est apparue comme une étape logique. Le shift-left aide les équipes à définir les attentes plus tôt, à collaborer plus efficacement et à réduire les frictions tout au long du cycle de développement.

Le problème que nous avons rencontré

Notre équipe éprouvait des difficultés. Chaque mise en production ressemblait à une course contre la montre et, le plus souvent, nous étions perdants. Les bogues passaient entre les mailles du filet et nos boucles de rétroaction étaient douloureusement longues. Lorsque l’assurance qualité signalait des problèmes, le développement était déjà passé à d’autres tâches, ce qui entraînait des corrections et des délais frustrants. Nous avions l’impression d’être toujours en train de rattraper le temps perdu, et les processus rigides que nous avions mis en place ne faisaient qu’empirer les choses. La séparation entre le développement et l’assurance qualité créait des frictions inutiles, ce qui nous ralentissait encore plus.

Notre processus d’assurance qualité était principalement orienté sur la détection des bogues. Nous avions l’impression de toujours courir après les problèmes plutôt que de les prévenir, ce qui était frustrant et épuisant. Les responsables de l’assurance qualité devaient tester chaque branche envoyée en revue, ce qui créait souvent des goulots d’étranglement. Nous réalisions des tests de groupe chaque semaine pour détecter encore plus de bogues, ce qui consommait un temps et des efforts précieux. Par ailleurs, les responsables de l’assurance qualité effectuaient des tests de fumée dans un environnement d’essai avant chaque mise en production, ce qui retardait encore le processus et alourdissait la charge de travail.

Nous avons réalisé que quelque chose devait changer. Nous avions besoin d’un meilleur moyen de collaborer, de fluidifier nos flux de travail et d’assurer la qualité sans qu’elle ne devienne un goulot d’étranglement. Notre objectif était clair : supprimer les silos, identifier les goulots d’étranglement, éliminer les contraintes et placer la qualité au cœur de notre processus de développement plutôt que de la traiter comme une réflexion a posteriori.

Se concentrer uniquement à trouver des bogues ne peut que mener à en découvrir encore plus. La véritable solution consiste plutôt à modifier les processus de l’ensemble de l’équipe afin de prévenir les bogues et les maîtriser avant la conception. L’approche shift-left n’est pas seulement une question de tests en amont ; il s’agit de s’assurer que la qualité est intégrée dans le processus dès le départ, en privilégiant les personnes par rapport aux processus.

Qu’est-ce que le shift-left?

Le shift-left en développement logiciel est une approche qui privilégie l’intégration des activités d’assurance qualité plus tôt dans le cycle de vie du développement. Au lieu de traiter les problèmes tardivement, cette approche encourage des mesures proactives telles que la collaboration, l’automatisation des tests et l’amélioration des processus afin de détecter et de prévenir les problèmes le plus tôt possible. Cette approche permet non seulement de réduire les coûts, mais aussi d’améliorer l’efficacité globale et la qualité des logiciels.

Consultez l’article de mon collègue pour voir comment le shift-left peut contribuer à réduire les délais et à livrer plus tôt au marché.

Comprendre l’assurance qualité et le contrôle de la qualité

Pour appliquer avec succès le principe du shift-left, il est essentiel de comprendre la distinction entre l’assurance qualité (AQ) et le contrôle qualité (CQ). Alors que le shift-left vise à intégrer la qualité dès le début du cycle de développement, savoir comment l’AQ et le CQ se complètent permet de s’assurer que les bonnes stratégies sont appliquées aux bons stades du développement.

L’AQ et le CQ sont souvent utilisés de manière interchangeable, mais ils ont des rôles distincts dans le cycle de vie du développement logiciel. L’AQ se concentre sur la prévention des bogues en améliorant les processus et en veillant à ce que les meilleures pratiques soient respectées tout au long du développement, tandis que le CQ se concentre sur la détection et la correction des bogues dans le produit final.

Principales différences entre l’AQ et le CQ :

Focus

• L’AQ est orientée vers les processus, garantissant que la qualité est intégrée dans le cycle de vie du développement.
• Le CQ est orienté vers le produit, identifiant les défauts du produit final.

Objectif 

• L’assurance qualité vise à prévenir les défauts en améliorant les processus.

• Le contrôle qualité vise à détecter et à corriger les défauts avant la mise en production.

Approche

• L’assurance qualité adopte une approche proactive en optimisant les flux de travail et en prévenant les problèmes.
• Le contrôle qualité adopte une approche réactive en testant et en identifiant les problèmes après le développement.

En privilégiant l’AQ par rapport au CQ, les organisations peuvent passer de la simple détection des bogues à leur prévention.

Imaginez que vous travaillez dans une usine de saucisses. Vous recevez des plaintes de clients signalant que votre produit est défectueux, disons qu’il ne contient pas de sel du tout […] Vous n’allez pas aller à l’épicerie et coller un paquet de sel sur chaque emballage du magasin pour résoudre le problème, non ? Vous allez plutôt trouver la cause sous-jacente du problème et ajouter des processus pour éviter que ce type d’erreur ne se produise à l’avenir. Et c’est ainsi, mes amis, qu’on fait de l’assurance qualité. 

— Vincent Cartier, Responsable de l’assurance qualité senior, anciennement chez Newforma

Comment la culture influence le succès de l’assurance qualité

La culture joue un rôle essentiel dans le succès du processus d’assurance qualité. Une mauvaise culture d’entreprise — qui sous-estime les contributions des responsables de la qualité et les isole du processus de développement — peut avoir un effet néfaste sur la qualité globale du produit. Lorsque les responsables de l’assurance qualité sont traités comme de simples gardiens et gardiennes plutôt que comme des partenaires stratégiques, ils sont amenés à gérer une avalanche de défaillances plutôt qu’à les prévenir dès le départ. Il en résulte des frustrations, des inefficacités et un produit sous-optimal.

D’un autre côté, une culture positive qui responsabilise les responsables de la qualité et favorise la collaboration peut transformer ce rôle en une fonction beaucoup plus importante. Lorsque les responsables de l’assurance qualité sont intégrés très tôt dans le processus de développement, qu’ils disposent des bons outils et qu’ils sont encouragés à contribuer au-delà des tests, ils deviennent des facilitateurs de la qualité plutôt que de simples testeurs. Ils peuvent se concentrer sur l’amélioration des processus, le partage des connaissances et aider l’équipe de développement à éviter les problèmes avant qu’ils ne surviennent. 

Les gestionnaires peuvent jouer un rôle important dans le soutien des responsables de la qualité par des mesures incitatives soulignant leurs contributions et leur valeur au sein de l’équipe. Les motivations telles que les opportunités d’évolution de carrière, la reconnaissance publique et les responsabilités supplémentaires peuvent aider les responsables de la qualité à se sentir plus valorisés et motivés. Toutefois, les mesures incitatives les plus efficaces sont celles qui sont mises en place de manière organique — lorsque les responsables de la qualité se voient confier davantage de responsabilités, de confiance et d’avantages, ils se sentent naturellement responsabilisés et s’investissent dans la réussite de l’équipe.

Valoriser les responsables qualité, c’est en faire des acteurs à part entière du cycle de développement, reconnaître la valeur de leurs opinions et s’assurer qu’ils prennent part aux discussions clés dès le début du processus. Lorsque les organisations adoptent cette approche, les AQ sont plus impliqués, assument la responsabilité de la qualité et contribuent de manière significative au succès de l’équipe.

La meilleure façon d’aider les AQ est de les aider, de les coacher, de les former. Faciliter les contacts et améliorer la communication au sein de mon équipe. Donner aux AQ un objectif plus important que la simple recherche de défaillances. 

— Catalin Bunescu, Responsable de l’assurance qualité chez Newforma

Simplifier notre processus de travail

Compte tenu des difficultés rencontrées avec nos processus d’assurance qualité existants et de la différence entre l’assurance et le contrôle de la qualité, nous savions que simplifier notre processus de travail était une étape cruciale pour la suite des choses. Nous devions éliminer les silos, améliorer la collaboration et simplifier notre approche pour mieux nous aligner sur la philosophie shift-left.

L’un des changements les plus importants que nous avons apportés a été de simplifier notre séquence de travail sur le tableau Kanban. Notre processus précédent était lourd, avec trop de colonnes, ce qui rendait le processus trop séquentiel. Chaque étape nécessitait un transfert, ce qui entraînait des délais et un manque d’efficacité. Cette rigidité nous bloquait souvent, nous empêchant de nous adapter et de réagir rapidement aux changements.

Imaginez un scénario dans lequel un développeur termine une fonctionnalité et la soumet à la revue avant que l’assurance qualité n’intervienne. Au cours de la revue, une autre développeuse suggère un refactoring pour améliorer la maintenabilité du code, que le développeur initial applique. La fonctionnalité passe ensuite à l’assurance qualité, où un testeur identifie un problème majeur d’interface utilisateur qui n’avait pas été pris en compte auparavant. Le développeur doit alors retravailler la fonctionnalité pour résoudre le problème d’ergonomie, ce qui risque de compromettre ou de compliquer le refactoring qu’il vient d’effectuer.

Dans ce cas, le fait de suivre un processus séquentiel strict — d’abord la revue, puis l’assurance qualité — se traduit par un gaspillage d’efforts. Le développeur a affiné la structure du code sans se rendre compte que la fonctionnalité elle-même pouvait nécessiter des changements. Si l’AQ avait été impliqué plus tôt, le problème d’interface utilisateur aurait pu être détecté avant le refactoring, ce qui aurait permis de trouver une solution plus efficace et plus efficiente.

En simplifiant le processus de travail et en regroupant la revue et l’assurance qualité, nous nous assurons que les commentaires critiques arrivent au bon moment, en évitant les reprises inutiles et en améliorant la collaboration entre les différents rôles.

En simplifiant le tableau, nous nous sommes concentrés sur la collaboration plutôt que sur le respect d’un processus rigide. L’ancien processus imposait un travail séquentiel, créant des frontières artificielles entre le développement et les responsables de la qualité. Cependant, en réduisant les colonnes inutiles, en identifiant les goulots d’étranglement et en nous concentrant sur les responsabilités partagées, nous avons créé un environnement plus dynamique et coopératif qui a permis des pratiques telles que le travail en binôme, qui favorise une meilleure collaboration.

Au lieu de déplacer le travail d’une colonne à l’autre pour attendre la validation ou le rejet, nous avons introduit une étape de revue au cours de laquelle l’assurance qualité et le développement ont travaillé ensemble. En collaborant plus tôt, nous pouvions traiter les problèmes potentiels plus rapidement et améliorer collectivement la qualité du code. Au lieu de signaler les bogues dans des tickets distincts, les AQ ajoutaient des commentaires directement dans les pull requests, ce qui permettait d’agir instantanément et de réduire les frictions.

En simplifiant notre processus de travail, nous avons réduit les lourdeurs et préparé le terrain pour une collaboration et un travail d’équipe plus étroits. Les changements que nous avons apportés ont favorisé des interactions plus fluides entre l’assurance qualité et le développement, ce qui a permis d’améliorer considérablement nos processus et nos performances.

C’était la première fois que je voyais ce type de processus dans ma carrière d’assurance qualité. Ça m’a beaucoup aidé. En intégrant et en fusionnant certains de nos processus d’assurance qualité avec ceux de l’équipe de développement, nous nous sommes sentis sur un pied d’égalité. Nous étions soit impliqués, soit tenus au courant. 

— Vincent Cartier, Responsable de l’assurance qualité senior, anciennement chez Newforma

Comment la simplicité a favorisé la collaboration

En éliminant de nombreuses colonnes qui imposaient un processus séquentiel, nous avons accidentellement créé un climat de coopération en encourageant le chevauchement des tâches entre l’assurance qualité et le développement. Avec moins de barrières, nous avons pu communiquer plus efficacement et détecter les problèmes avant qu’ils ne deviennent sérieux. Ce qui était auparavant un processus strict de passation des tâches s’est transformé en un effort de collaboration.

• La revue est devenue une étape collaborative : Au lieu de se contenter de signaler les bogues, les responsables de la qualité ajoutent désormais des commentaires constructifs dans les pull requests, ce qui aide l’équipe de développement à résoudre les problèmes rapidement.
• Réduction des lourdeurs : Au lieu de déplacer les cartes d’une colonne à l’autre pour les accepter ou les rejeter, les responsables de la qualité se contentent d’approuver les pull requests.
• Moins de défauts : Les problèmes sont désormais corrigés plus tôt dans le processus, lors de la phase de revue, plutôt que plus près du déploiement.
• Le déploiement continu a rendu les étapes finales obsolètes : Notre nouvelle stratégie de déploiement a considérablement réduit la nécessité de phases prolongées de staging et de tests de fumée, permettant des mises en production plus rapides et plus fiables.

L’empathie et le fait de ne pas avoir peur d’essayer des méthodes de travail peu orthodoxes sont très utiles. Nous devons penser davantage aux facteurs humains parce que nous pensons souvent trop aux facteurs artificiels. 

— Vincent Cartier, Responsable de l’assurance qualité senior, anciennement chez Newforma

Développement et assurance qualité : une mission de qualité partagée

En nous appuyant sur nos efforts pour simplifier les processus de travail et favoriser la collaboration, nous avons compris que la qualité réelle ne pouvait être atteinte qu’en partageant les responsabilités avec l’ensemble de l’équipe. Simplifier notre processus de travail n’a pas seulement amélioré l’efficacité, mais a également mis en évidence la nécessité pour le développement et l’assurance qualité de collaborer plus étroitement afin d’affiner les processus et de prévenir les défauts à un stade plus précoce du cycle de développement.

Un point essentiel de la transformation shift-left est de prendre conscience que la qualité est une responsabilité partagée. L’équipe de développement doit s’approprier les tests et garantir la qualité du code, tandis que les responsables de la qualité devraient se concentrer davantage sur l’assurance qualité réelle, c’est-à-dire sur les processus de travail avant la conception afin de réduire les risques de bogues.

En transférant la responsabilité des tests au développement, les AQ peuvent cesser d’être de simples testeurs et agir comme des facilitateurs, en guidant les équipes pour qu’elles intègrent la qualité dans leurs processus. Cette évolution permet aux responsables de l’assurance qualité de :

• Analyser et raffiner les processus de travail afin d’éviter les erreurs récurrentes.
• Collaborer plus tôt avec les équipes chargées des produits pour définir des exigences claires et testables.
• Appliquer des stratégies de qualité qui réduisent les risques avant le début du développement.

Voir l’équipe de développement s’approprier la qualité a joué un rôle déterminant ; notre travail en tant qu’AQ est devenu plus stratégique et plus utile. L’équipe de développement, à son tour, s’engage davantage dans les tests et les efforts de qualité, ce qui conduit à une meilleure collaboration et à une compréhension plus étroite des risques potentiels.

Les responsables de l’assurance qualité ne sont pas vos testeurs personnels. Si l’assurance qualité trouve beaucoup de bogues dans votre code, c’est que vous ne révisez pas suffisamment votre propre travail. 

— Dan Kennedy, Directeur de l’ingénierie, leader technique Full-Stack et coach

Les Quatre Fantastiques : une approche adaptée de la collaboration

En nous appuyant sur le concept de responsabilité partagée, nous avons d’abord essayé l’approche des « Trois Amigos », qui réunissait l’équipe de développement, les testeurs et les gestionnaires de produits (Product Owners) pour collaborer à la définition des exigences et des critères d’acceptation. Dans mon expérience passée, les Trois Amigos ont été un moyen efficace d’encourager une collaboration et un alignement en amont. Cependant, nous avons souvent constaté que les responsables de l’assurance qualité étaient exclus de ces discussions cruciales, ce qui entraînait des lacunes dans la planification de la qualité et des occasions manquées de prévenir les défauts à un stade précoce.

Bien que l’approche des Trois Amigos soit très utile pour favoriser le shift-left, elle ne répondait pas tout à fait à nos besoins. Nous avons développé le concept des « Quatre Fantastiques », une approche sur mesure qui correspondait mieux à la dynamique et aux objectifs de notre équipe. Les Quatre Fantastiques sont composés d’un représentant ou d’une représentante de chacune des disciplines principales qui composent une équipe de développement : produit (Product Owner), conception (designer), assurance qualité (AQ), et développement (Team Lead dans notre contexte, mais n’importe quel membre de l’équipe conviendrait). Cette structure a permis de s’assurer que tous les aspects du projet étaient pris en compte dès le départ, ce qui a favorisé une meilleure compréhension du logiciel et du domaine.

Nous étions confrontés au défi d’impliquer une quinzaine de membres de l’équipe dans les réunions, ce qui devenait rapidement inefficace. Nous avons considérablement amélioré notre efficacité globale en réduisant le nombre de participants et en confiant des responsabilités clés à un plus petit nombre de personnes. Les Quatre Fantastiques ont servi de pont entre les différentes parties et les différents départements, en veillant à ce que la communication soit centralisée et que la prise de décision soit allégée. Les membres désignés ont servi d’intermédiaires, facilitant les discussions, s’appropriant certaines tâches et permettant à l’équipe de développement de se concentrer davantage sur le développement des fonctionnalités sans distraction.

Les Quatre Fantastiques sont étroitement adaptés à nos besoins, mais peuvent se décliner en de multiples configurations en fonction de la structure de l’équipe. Par exemple, le Team Lead pourrait être un développeur senior et le Product Owner pourrait être remplacé par un chef de projet. Ce qu’il faut retenir, c’est que les membres de ce groupe doivent être ceux qui ont des intérêts importants dans le produit. Le succès de cette approche réside dans la sélection des bonnes personnes qui peuvent apporter le plus de valeur aux discussions et aux processus de prise de décision.

Notamment, l’équipe de développement était toujours impliquée dans le raffinement et la prise de décision, mais leur participation se situait à un stade où l’ambiguïté était réduite et où la clarté atteignait un niveau satisfaisant. Ils pouvaient ainsi travailler plus efficacement sans avoir à se préoccuper des modifications constantes ou des exigences floues.

Dans la plupart des configurations des Trois Amigos, les responsables de l’assurance qualité étaient souvent écartés. En les intégrant comme partie intégrante des Quatre Fantastiques, nous avons favorisé une meilleure culture de collaboration et de prise en charge, ouvrant la voie à une intégration accrue entre les processus d’assurance de la qualité et de développement.

Une meilleure communication améliore l’assurance qualité en plaçant la qualité des logiciels au centre des préoccupations. Nous devrions être des stratèges de la qualité. 

— Catalin Bunescu, Responsable de l’assurance qualité chez Newforma

Développement guidé par le comportement (BDD)

Compte tenu du changement de culture et des améliorations apportées par des initiatives telles que les Quatre Fantastiques, le développement guidé par le comportement (Behavior-Driven Development ou BDD) est apparu comme la prochaine étape logique de notre transformation vers le shift-left. Le BDD encourage la collaboration entre le développement, l’assurance qualité et les parties prenantes de l’entreprise en s’intéressant à la manière dont le système devrait se comporter plutôt qu’à ce qui doit être fait. En écrivant des scénarios de test dans un langage commun compris par toutes les parties, le BDD permet d’éviter les malentendus et de garantir l’alignement au sein de l’équipe.

Par exemple, un récit utilisateur classique en BDD pourrait inclure :

Récit utilisateur : En tant qu’utilisateur, je souhaite réinitialiser mon mot de passe afin de retrouver l’accès à mon compte.

Critères d’acceptation :

• Si je suis sur la page de connexion, lorsque je clique sur « Mot de passe oublié », je dois recevoir un courriel avec un lien de réinitialisation.
• Si je reçois le courriel de réinitialisation, lorsque je clique sur le lien de réinitialisation, je dois être dirigé vers la page de réinitialisation du mot de passe.

En adoptant la méthode BDD, nous pouvons nous assurer que tout le monde, de l’équipe de développement aux responsables de la qualité en passant par les parties prenantes, a une compréhension commune des exigences et des attentes. Cette approche consoliderait davantage notre culture d’équipe en favorisant une collaboration encore plus étroite et un sentiment partagé de responsabilité envers la qualité.

Prenons l’exemple d’une équipe qui peaufine une fonctionnalité permettant aux utilisateurs de télécharger des photos de profil. Sans une implication en amont de l’assurance qualité, le développement peut supposer que n’importe quel format d’image est acceptable, pour découvrir ensuite, lors des tests, que les utilisateurs essaient souvent de télécharger des GIF animés, qui ne sont pas pris en charge. Des discussions de dernière minute s’ensuivent, qui peuvent conduire à des modifications du produit.

Avec le BDD, puisque l’assurance qualité et le développement sont impliqués dès le début, ils peuvent demander de manière proactive : « Que se passe-t-il si un utilisateur essaie de télécharger un format non pris en charge ? » ou « Avons-nous besoin d’une compression d’image pour éviter les problèmes de performance ? » Ces questions permettent de mettre en évidence les cas limites plus tôt dans le processus de raffinement, ce qui permet à l’équipe d’ajuster le champ d’application ou d’adapter la conception dès le départ, plutôt que de découvrir des problèmes tardivement dans le processus et de retarder la mise en production.

Pour continuer à approfondir la notion de shift-left, voici quelques possibilités :

• Adoptez Kanban avec des politiques d’extraction : Kanban améliore la visibilité et la collaboration, tout en simplifiant les processus de travail, en permettant une rétroaction en continu ainsi qu’une détection précoce des problèmes, et en privilégiant la livraison d’éléments plus petits et plus faciles à gérer, dans le respect des objectifs en matière d’assurance qualité.
• Éliminez les barrières : En éliminant les étapes d’approbation inutiles et les interventions manuelles, les transitions dans le processus de travail sont plus fluides, ce qui permet une livraison plus rapide et donne aux équipes la possibilité de prendre en charge la qualité tout en maintenant des normes élevées.
• Arrêtez de planifier les tests, commencez à les faire : Les plans de test rigides sont souvent inefficaces et ne s’adaptent pas à l’évolution des besoins du projet. Au contraire, l’adoption d’une stratégie de test plus souple et flexible garantit que les contrôles de qualité sont intégrés de manière harmonieuse tout au long du cycle de développement, ce qui favorise une approche proactive pour identifier et résoudre les problèmes rapidement.

Le shift-left : une initiative sur mesure

En adaptant notre approche à la dynamique unique de notre équipe, nous avons constaté que la prochaine étape naturelle consisterait à raffiner nos processus à l’aide de méthodologies telles que le développement guidé par le comportement (BDD). En appliquant des initiatives sur mesure, nous pourrions consolider davantage notre engagement à prévenir les défauts à un stade précoce et à collaborer avec tous les rôles de l’équipe.

Chez Nexapp, nous abordons les initiatives shift-left avec flexibilité, en comprenant qu’il n’y a pas de solution unique pour tous les projets. En tant qu’entreprise de services et de produits, nous travaillons avec diverses équipes, à la fois internes et en co-développement, où nous nous intégrons aux équipes existantes de nos clients. Chaque équipe a ses propres défis et besoins, ce qui signifie que l’approche shift-left doit être une initiative sur mesure, et non une solution unique.

Les initiatives itératives et l’amélioration continue sont essentielles pour parvenir à un changement significatif. Identifier et éliminer les goulots d’étranglement est essentiel pour favoriser la collaboration et éliminer les entraves à l’efficacité. Certaines équipes de Nexapp s’appuient sur un partage des responsabilités entre tous les membres de l’équipe de développement pour l’assurance et le contrôle de la qualité plutôt que de dédier des personnes à l’assurance qualité. Dans les équipes sans AQ, nous avons constaté que les développeurs et les développeuses étaient plus proactifs en matière de qualité, ce qui a permis de réduire le nombre de problèmes en production. Cette approche fonctionne bien pour nous, mais pourrait ne pas s’appliquer à de grandes organisations avec une gestion des risques et des accords de niveau de service (Service Level Agreement ou SLA) plus stricts.

Le leadership joue un rôle clé dans la transformation vers le shift-left. Il est important de faire la différence entre les leaders et les gestionnaires — les deux sont des rôles de leadership avec des influences et des pouvoirs différents. Les leaders inspirent et guident les équipes, favorisant la collaboration et l’innovation, tandis que les gestionnaires se concentrent sur la structure, les processus et l’efficacité opérationnelle. Les deux aspects du leadership sont nécessaires pour soutenir les équipes et leur donner les moyens d’adopter une culture de responsabilité partagée et d’amélioration continue.