Les tests agiles : ma quête des meilleures pratiques !

Et si nos mauvaises pratiques de test étaient LE frein à notre agilité ?

Ce texte est l’article compagnon de la conférence du même nom, créée en 2023, et qui a été donnée dans plusieurs villes françaises.

Vous y trouverez : 

• Des explications et du contenu complémentaire 
• Des pointeurs vers les diapos et le replay de la session Agile Tour Bordeaux 2023 
• Des cartes Tests Heath Check à télécharger pour auto-évaluer vos pratiques en équipe 
• Des détails sur la genèse et la mise au point de cette conférence 

Le contexte

J’ai observé que, bien souvent, nos équipes agiles sont coincées par des pratiques de tests inadaptées : les tests sont trop fastidieux et font prendre des risques ou augmentent le Time To Market. On est obligés de tester en production. Bref : la façon dont on teste nous empêche de construire sereinement et avec agilité des produits fonctionnels et avec la qualité attendue. 

Une histoire vraie… mais un peu triste

Voici une situation que j’ai vécue : 
– moi : Salut l’équipe ! Quelle est votre principale préoccupation en ce moment ? 
– équipe : Les priorités changent tout le temps et c’est pénible. 
– moi : Ça veut quoi « tout le temps » ? Chaque heure, chaque jour, chaque semaine, chaque mois … ? 
– équipe : Hum, c’est plutôt chaque semaine.  
– moi : Votre rythme de travail actuel se base sur des itérations de 1 mois. Pourquoi ne pas tenter de faire des itérations de 2 semaines ? 
– équipe : Oui c’est une bonne idée mais on ne peut pas faire ça car nos tests de non-régression sont entièrement manuels et il faut 4 semaines pour les jouer tous. 
– moi : Comment pouvez-vous réduire la durée de tests ? 
– équipe : Bien sûr, il faudrait automatiser les tests. C’est la chose évidente à faire mais on ne peut pas décider de faire ça car ce n’est pas le même budget. L’assurance qualité est la mission d’un autre service et nous avons, aujourd’hui, très peu d’influence sur les décisions de leur responsable. 
– moi : arf… 😕

A partir de ce type d’observations, qu’est-il possible de faire ? Quelles sont les bonnes pratiques à mettre en place ?  Y a-t-il des pré-requis ?

Mon intention, pourquoi j’ai créé cette conférence 

J’ai découvert, avec certaines équipes, des pratiques vraiment top, et donc une meilleure réactivité et une meilleure qualité, les pratiques n’étaient plus un frein mais un facteur de succès, un soutien. 

J’ai envie de partager les pires et les meilleures pratiques observées en 10 ans de coaching d’équipes, classées selon 7 aspects du test, du plus essentiel au plus avancé : 

1. L’automatisation des tests

2. Le partage de la stratégie de test 

3. Un patrimoine de test optimisé et accessible à tous 

4. Le coaching de l’équipe 

5. La gestion professionnelle des campagnes de test

6. Des tests de qualité 

7. La gestion du risque industriel 

Cette classification est tout à fait subjective, et je l’assume. C’est juste mon avis issu de mes expériences et observations successives. 
J’ai eu la question « Pourquoi tu n’as pas établi une stratégie de test en niveau 1 ? » En effet, ça parait logique et je vous encourage à commencer par ça. Néanmoins, je souhaite insister sur la nécessité d’automatiser le plus de choses possibles. Une équipe agile qui établirait une stratégie de test sans inclure d’automatisation aura beaucoup de mal à atteindre les promesses de l’agilité. 

La recherche constante de l’excellence technique est un pré-requis à l’agilité. 

Remarque : Les exemples donnés pour chacun de ces axes ne sont que cela : des exemples. Ils sont utiles pour illustrer mon discours par des cas concrets (fruits de mes observations dans différentes organisations) et sont là pour nous inspirer (ou nous faire peur). Tout ce qui est décrit ci-dessous n’est pas nécessairement à mettre en œuvre, soyez curieux et créatifs suivant votre contexte. 

1) Automatisation des tests

La promesse de l’agilité est de mieux satisfaire nos utilisateurs en leur livrant plus souvent des petites choses pour prendre en compte rapidement leurs feedbacks. Le corollaire de tout cela, c’est qu’il faudra tester plus souvent et sur un périmètre croissant. Si les tests ne sont pas en grande partie automatisés, ça va juste nous prendre trop de temps et nous coûter trop cher. Donc les tests seront bâclés ou ignorés et la qualité ne sera pas au niveau attendu. Et pire, elle va baisser au cours du temps, et ce, de manière incontrôlée. 

L’agilité sans excellence technique, et donc sans un harnais de tests automatisés conséquent, est juste un mensonge ! 

Vu mon passé technique, j’accompagne depuis plusieurs années des équipes IT plutôt côté Infrastructure et Réseaux (OPs, Sysadmin…). Je peux observer que ces profils ont une image plutôt négative de l’agilité. Et au vu de leurs expériences passées, je ne peux que leur donner raison. En effet, nombreux sont ceux qui, parmi eux, avec le passage des équipes de « Dev » en mode agile, ont vu arriver des livraisons plus petites et plus fréquentes (ça c’est plutôt une bonne nouvelle) mais aussi, généralement, moins bien testées et introduisant plus d’instabilité dans les systèmes (et ça, c’est carrément pas terrible). 

❌ Pire situation observée 

Une non-régression entièrement manuelle et si longue que les tests éligibles à chaque campagne doivent être titrés au sort pour que la durée des tests reste raisonnable. Et malheureusement, cette équipe a vécu un incident grave en production, plusieurs jours d’indispo et bashing dans la presse et sur un scénario qui était pourtant présent dans le patrimoine de test (il n’avait juste pas été sélectionné cette fois-ci). 

✅ Meilleure situation observée 

Une équipe en full TDD, les tests écrits avant le code et avec rotation des binômes (avec un taux de couverture > 80%) qui a, grâce à ce harnais de test, absorbé en 2 jours les effets de bord dûs à un changement de technologie du moteur de stockage (moteur NoSQL vers une base de données relationnelle).

Convaincre avec des cartes à jouer 

Si investir du temps dans l’automatisation des tests est encore un sujet dans votre équipe, je vous invite à essayer en équipe le jeu CatTesTdrale. 
C’est un jeu assez court (~30 min) qui n’utilise pas de code, tout le monde peut ainsi participer (y compris votre PO ou votre manager). Il vous permettra à l’aide d’une simulation immersive très simple de provoquer un débat plus riche. 

2) Stratégie de test 

Déjà, il en faut une délibérée et non pas subie. Elle doit être établie collectivement et partagée par tous les acteurs du projet, puis revue à intervalles réguliers, en fonction des apprentissages. Son but est d’optimiser la couverture du risque par rapport à l’effort de test fourni. Il peut être normal que l’équipe décide de ne pas tester quelque chose, du moment que c’est délibéré et que le risque est accepté collectivement. 

❌ Pire situation observée

Stratégie de quoi ? Nous n’avons pas pris le temps de définir ensemble une stratégie. Des choses sont certainement testées en double et d’autres jamais. 

✅ Meilleure situation observée

Une stratégie définie ensemble y compris avec le métier. Formalisée et partagée à l’aide d’un document d’une demie-page. Les thèmes abordés : comment allons-nous tester l’accessibilité ? Jusqu’à quel niveau ? Jusqu’où va-t-on dans la combinatoire systèmes d’exploitation/navigateurs ? Les risques, pris en équipe, sont acceptés collectivement. 

3) Patrimoine de test 

Le patrimoine de test, c’est l’ensemble des jeux de données et des scénarios (manuels ou automatisés). On le souhaite complet et optimisé. C’est-à-dire que l’on veut du matériel nous permettant de tester tous les cas qui suivent notre stratégie de test (sans manques et sans doublons). 
La première de ses qualités est donc qu’il soit lisible par tous. Sinon, comment le faire évoluer et s’assurer facilement de sa pertinence et de sa complétude ? 

❌ Pire situation observée

Eparpillement du patrimoine selon les types de test : 

• TU automatisés rédigés en code et stockés sous Git 
• Les tests de non-régression manuels rédigés sous fichiers tableur et stockés dans la GED (les dev n’y ont pas accès) 
• Les tests de charge, sous-traités à un partenaire externe, rédigés et stockés dans un format propriétaire 

Personne n’est capable d’avoir une vue d’ensemble de notre patrimoine. Des choses sont probablement testées plusieurs fois et d’autres jamais. 

✅ Meilleure situation observée

Tous les tests (techniques/fonctionnels, automatiques/manuels, unitaires/intégration) sont rédigés en Gherkin, un DSL (Domain Specific Language) créé exprès pour rédiger des scénarios de test. Les scénarios fonctionnels sont saisis dans un WIKI, customisé avec un template pour les fiches Gherkin, et dont l’espace de stockage est Git, ce qui en facilite l’automatisation par les dev. L’exécution des tests automatiques donne lieu à un rapport HTML, lisible et accessible à tous, facilitant la relecture des tests qui ont été joués et quels ont été leurs résultats. 

4) Un rôle de testeur agile 

Savoir bien tester est une compétence et on doit l’avoir dans l’équipe. 
Le testeur ou la testeuse agile, ce n’est pas la personne qui fait les tests manuels à la fin (et qui, dans ce cas, devient un goulot d’étranglement). C’est plutôt la personne qui coach chaque membre de l’équipe pour faire monter notre niveau de compétence global sur ce sujet. Savoir bien tester, c’est aussi une attitude. Les développeurs ne sont pas les meilleures personnes pour la recherche de défauts, en effet, ils ont déjà mis tellement d’effort à construire la solution qu’ils n’ont pas tellement envie de lui découvrir des failles. 

Les personnes formées au test connaissent les différents types de test et sont sensibles aux biais introduits par certaines pratiques. En effet, à toujours ratisser aux mêmes endroits, nous risquons de créer des zones d’ombre propices à l’apparition de défauts inopportuns. Ce sont toutes ces compétences qu’elles apportent à l’équipe. 
Cette personne ne sait pas coder ? En vérité ce n’est pas grave. Réunir des jeux de données réalistes et de qualité est souvent chronophage. C’est un travail important et conséquent qui peut être pris en charge en parallèle de la mise au point de la solution. N’ayez crainte, cette personne ne sera pas sous-employée.

Cette personne va aussi contribuer à enrichir le backlog avec des fonctionnalités qui vont favoriser l’observabilité et la testabilité du système (par exemple : des points d’entrée pour les sondes ou des fonctionnalités facilitant la génération et la gestion des jeux de données). N’oublions pas : une application plus facile à tester sera aussi plus facile à utiliser et à maintenir dans la durée ! 

❌ Pire situation observée

Les testeurs sont dans un autre service. Ils ont un rythme de travail et des objectifs différents des nôtres. Les budgets de réalisation et des tests sont séparés, complexifiant l’allocation de moyens sur les chantiers d’automatisation. 

✅ Meilleure situation observée

Un rôle de « testeur agile » a été défini pour l’équipe avec pour mission d’être le coach de l’équipe sur les pratiques d’assurance qualité et d’être le garant de la stratégie de test définie collectivement. N’ayant pas pu recruter une personne avec le bon profil, l’équipe a choisi d’incarner le rôle par un binôme (un profil plus analyste et un profil plus technique). 

5) Gérer nos campagnes de tests comme des pros 

Ça y est, maintenant nous avons un patrimoine de test de complet et lisible par tous. Il s’enrichit au fur et à mesure de la vie de notre produit et devient conséquent. Ce n’est peut-être pas optimal de dérouler l’ensemble des tests pour chaque petite évolution. Il est bon de définir des campagnes, en accord avec notre stratégie de test, pour sélectionner le sous-ensemble des scénarios pertinents en fonction des impacts estimés des changements prévus, pour une livraison donnée.

Cette campagne va nous permettre de suivre le bon déroulé des tâches liées aux tests, d’assurer une traçabilité de ce que qui aura effectivement été testé pour chaque exigence, et de la couverture des tests, ainsi que des métriques qui nous permettront de challenger et éventuellement de revoir notre stratégie de test. 

❌ Pire situation observée

Campagne de quoi ? Rien n’est défini ni tracé, seuls sont testés les scénarios les plus évidents, tout le reste passe à la trappe. 

✅ Meilleure situation observée

Un outil a été sélectionné, en commun l’équipe et en prenant en compte l’avis du métier afin de gérer le patrimoine et les campagnes de tests. Dans ce cas, XRay pour Jira. Des métriques permettant d’inspecter la qualité produite et les pratiques de test étaient affichées et commentées lors des revues d’itération. 

6) La qualité : les tests aussi 

La qualité concerne aussi les tests. Nos jeux donnés doivent être complets et réalistes. Les scénarios doivent être les plus simples et les plus indépendants. 

Concernant le code des tests automatisés, je me pose la question suivante : pourquoi ce code est-il généralement de bien meilleure qualité que le reste du code ? 
Parce que les tests ne font pas partie des livrables ? Ah bon, en êtes-vous sûrs ? 
Nous devons avoir le même niveau d’exigence sur le code des tests que sur le reste, sinon l’automatisation, au lieu de nous apporter la sécurité attendue, risque fort de devenir un frein aux évolutions futures. Ceci explique surement en partie la réticence de certains face aux pratiques d’automatisations, issue de situations vécues par manque de compétences ou d’exigence.  

❌ Pire situation observée

Un refactor empêché par la non-qualité des tests automatiques : le code était raisonnablement bien organisé, avec des modules bien identifiés. Mais ce n’était le cas du code de test où tout dépendait de tout. Du coup, l’équipe s’est trouvée devant le dilemme suivant : faire le refactor et perdre le patrimoine de test ou garder ce harnais de test mais continuer à galérer sur les évolutions futures du produit. D’ailleurs, les métriques issues de la relecture automatique de code (ici par SonarQube) n’étaient pas fournies sur les packages de tests et après vérification, elles se sont révélées bien plus mauvaises.  

✅ Meilleure situation observée

Utilisation du principe de Mutation Testing pour inspecter la qualité des tests automatisés. Ce qui consiste à générer un certain nombre de variants du code original (les mutants) dans lequel nous avons introduit à chaque fois un bug connu. Puis, pour chacun de ces variants, le patrimoine de test est déroulé en entier pour voir combien de ces bugs connus sont détectés. Ici, le principe du Mutation Testing n’a pas été systématique mais plutôt utilisé de manière pédagogique. De plus, cette équipe avait organisé le code utilisé pour la rédaction des tests automatisés sous forme d’une API. Cette API évoluait avec la complexité du projet et était soumise, comme le reste du code, à des refactors fréquents, le code des tests unitaires automatisés étant aussi petit que possible (c’est-à-direde l’ordre du nombre de lignes du scénario correspondant). 

7) Gérer le risque industriel 

La gestion du risque industriel est une discipline à part entière. Il existe de nombreux livres sur le sujet. Ce qui peut sembler paradoxal, c’est que la probabilité d’occurrence d’un incident grave est proportionnelle à la durée de la période de confiance qui le précède. 

Par exemple : l’explosion de la navette spatiale Challenger. Le plus grave accident du programme spatial américain est survenu après la plus longue période sans incidents. 

Donc toutes les stratégies qui visent à augmenter la confiance dans le système conduisent, à plus ou moins long terme, à un incident grave. 
Que peut-on faire ? Le seul moyen de rester vigilants est d’introduire régulièrement des problèmes contrôlés sur la production afin de s’assurer que les personnes sont à l’aise et que le système se comporte convenablement lors de situations anormales et que les procédures de remédiation sont connues, maitrisées et fonctionnent comme prévu. 

❌ Pire situation observée

Rien n’est prévu pour ça. Et même pire, rien n’a été prévu pour suivre la bonne santé de l’application en production, difficile de détecter les dysfonctionnements et impossible de les anticiper. Par ailleurs, la sauvegarde n’a jamais été re-testée depuis sa mise au point. Et après vérification une partie des données n’étaient plus sauvegardées depuis un certain temps dû à un point de montage qui a évolué depuis. 
De plus, rien n’a été prévu pour tester certaines choses comme la supervision ou les seuils d’alarming par exemple. 

✅ Meilleure situation observée

Inspirée par la démarche à l’origine de l’outil Chaos Monkey (créé par la société Netflix), l’organisation a mis en place, à intervalles réguliers, un concours, sous forme de hackathon pour permettre à chacun de s’entrainer. Les personnes volontaires s’inscrivent en équipe (PO, Dev, OPs, QA, Support …) et ont une demi-journée pour résister à un scénario catastrophe imaginé par les Sys Admin.
L’équipe gagnante est celle qui rétablit en premier le service offert par son système. Ce concours est reconduit tous les 6 mois. On a pu observer : une meilleure sensibilisation de tous les acteurs, des améliorations apportées aux tableaux de bord de supervision et ainsi que du code spécifique ajouté pour augmenter la résilience des applications. Code qui, bien qu’écrit dans le but de gagner la prochaine instance du concours, est venu enrichir le patrimoine applicatif. 

Bien équipés pour partir à la chasse aux bugs 

Avec un bon niveau de maturité de test sur ces 7 axes, nous sommes bien équipés pour aller à la chasse aux bugs et assurer le niveau de qualité attendu tout au long de la vie du produit. 

Tests Health Check : des cartes pour s’auto-évaluer en équipe 

Ces cartes peuvent être vues comme une extension aux cartes « Squad Health Check ». Elles vous permettront de prendre du recul sur vos pratiques de test, via une auto-évaluation collective. Et, je l’espère, elles vous donneront de l’inspiration pour vous améliorer en équipe. Ainsi, vous pourrez apporter votre contribution à l’amélioration de nos pratiques professionnelles. 
Vous pouvez les utiliser seules ou après avoir regardé le replay de la conférence. 

Elles sont disponibles gratuitement en respectant la licence Creative Commons BY-SA (Attribution, Partage dans les mêmes conditions) 

En bref, c’est-à-dire que vous êtes autorisés à :   

• Partager ou adapter ce contenu pour tout usage (y compris commercial)  

Selon les conditions suivantes :

• Attribution — Vous devez citer l’auteur et la source de ce contenu. Un lien vers cet article peut suffire.  
• Partage dans les mêmes conditions — Dans le cas d’une modification ou d’un contenu dérivé, vous devez diffuser l’œuvre résultante dans les mêmes conditions, c’est à dire avec la même licence avec laquelle l’œuvre originale a été diffusée.

Comment j’ai construit cette conférence 

1) L’idée de départ 

L’idée de cette conférence m’est venue dans le train, en revenant d’Agile Grenoble en octobre 2022 et en parlant avec un confrère. Cette année-là, j’ai assisté à plusieurs sessions sur les tests dans plusieurs conférences agiles. Et j’avoue que je suis resté sur ma faim. J’ai trouvé que les sessions avaient trop survolé le sujet avec trop peu de choses concrètes. Je n’y avais pas trouvé ce que j’étais venu chercher. Du coup, en discutant, je me suis dit que c’était peut-être à moi de m’y mettre. A ce moment, je me suis posé les questions suivantes : qu’ai-je à dire sur le sujet ? Quelle est ma légitimité ? Cela fait maintenant plus d’une dizaine d’années que je fais du coaching d’équipe et ce n’est plus tellement moi qui réalise directement mais j’ai pleins d’observations intéressantes à partager. 

2) Message à faire passer et objectif 

A partir de ce qui me semble important et impactant, mon intention est de partager des exemples concrets et vécus, des pires et des meilleures pratiques observées, dans un but de prise de recul et d’inspiration. Mon objectif est atteint si les participants repartent avec une découverte ou l’envie de tester une nouvelle chose dans le but de progresser. 

3) Faire interagir le public au maximum 

Les neurosciences nous ont montré que le cerveau apprend en faisant, de manière dynamique. J’essaie donc de toujours maximiser les interactions avec le public. De plus, les nouvelles connaissances ont plus de chance d’être mémorisées si elles peuvent être reliées à des souvenirs existants. Pour cela, au tout départ de ma session, j’invite les participants à entrer dans le sujet par le rappel d’un souvenir positif et à se connecter à l’assemblée en partageant avec leur voisin le plus proche. 

Ensuite, avec l’objectif de prise de recul en tête, j’invite chacun à se positionner sur chaque axe présenté. Est-ce que sa pratique actuelle penche plutôt du côté du pire ou plutôt du côté du meilleur ? 

Entre chaque section, les intercalaires permettent de bien suivre le déroulé et de comprendre la logique du discours. De plus, la répétition des informations est utile pour l’ancrage et la mémorisation des apprentissages. A la fin, une diapo de synthèse résume les éléments clés du discours et quelques liens utiles invitent à poursuivre l’investigation ultérieurement. 

La session se termine par un « Take Away » avec 2 questions impactantes qui, en plus de me permettre de vérifier l’atteinte de mes objectifs, facilitent la mémorisation active d’une seule chose importante pour l’auditeur et le passage à l’action : 

• Qu’est-ce qui m’a le plus marqué ? 
• Qu’est-ce qui va m’être utile pour la suite ? 

4) Un mot sur les illustrations 

Pour les illustrations, vu le thème central de progresser et « gagner des niveaux », la thématique du jeu de rôle c’est imposée (merci Kervin pour m’avoir soufflé l’idée 😉). 
Elles facilitent la mémorisation par l’immersion dans un univers graphique spécifique et cohérent et à l’aide d’analogies visuelles. 
J’ai réalisé les illustrations moi-même à l’aide de l’outil de dessin vectoriel Inkscape. 

5) Adaptations pour la version en ligne 

Dans cette ère post-Covid, où la réunion en visio est à la mode, on m’a demandé de donner cette conférence sous forme de webinaire. J’ai dû adapter les interactions avec le public pour pouvoir les faire en ligne. Pour cela, je me suis appuyé sur l’outil Klaxoon. 
Pour connaître mon public, je commence par un atelier des constellations, où j’invite chaque participant à mettre son prénom à côté de la carte qui porte le nom de son métier ou rôle (à la place de lever la main). 

Afin d’appeler les souvenirs de participants, j’ai remplacé les 4 minutes d’échanges en binôme par un nuage de mots. 

Lorsque que j’invite les participants à se positionner par rapport aux différentes pratiques j’utilise un sondage dynamique (à la place de : pencher la main à droite ou à gauche).

Pour la partie Take Way, des post-its numériques remplacent aisément ceux en papier. 

Ressources 

• 🎬 Replay de la session Agile Tour Bordeaux 2023
• 🎬 Replay de la session Agile Niort 2024  
• 🎲 Jeu CaTesTdrale : http://catestdrale.github.io/  
• 📚 Gherkin : https://cucumber.io/docs/gherkin/  
• 🔧Mutation Testing avec PIT : https://pitest.org/  
• 📰 Chaos Monkey : https://fr.wikipedia.org/wiki/Chaos_Monkey 
• 📘 Culture Test livre blanc OCTO (3 tomes) : https://publication.octo.com/culture-test-vol-1
• 🗨 L’automatisation des tests en BD par Jérémy Sorant

Observations et apprentissages 

1) Cette conférence fonctionne très bien

Déjà, vu les réactions du public et les nombreux retours supers positifs que j’ai reçus, il me semble que les objectifs recherchés sont atteints : 

• Prendre du recul 
• Démystifier 
• Donner de l’inspiration sur les pratiques trop méconnues 

Quelques exemples de feedbacks, typiques de ceux collectés : 

• PO : « Je ne viens pas de la technique, et pourtant j’y tout compris. C’était hyper clair. Merci ! » 
• QA : « Enfin quelqu’un qui parle des pratiques de test concrètement et simplement » 
• DEV : « C’est bien cette idée de tester les tests. Je ne connaissais pas le Mutation Testing. » 
• Coach Agile : « C’est intéressant cette progression en 7 niveaux. Ca me donne envie de faire le tour des équipes pour échanger avec eux sur leur pratiques. » 

Mon sujet à même permis, à mon plus grand plaisir, de générer une discussion en ligne incluant des gens qui n’étaient pas présents à ma session. Cela a permis d’enrichir le débat avec d’autres points de vue. J’ai pu aussi obtenir des pointeurs vers des autrices que je ne connaissais pas : 

• Modern testing de Brian Page  
• Holistic Testing de Janet Gregory et Lisa Crispin 

2) Il y a encore du boulot !

Il est honnête de reconnaîre que les pratiques moyennes de l’industrie informatique se sont stabilisées autour de standards de qualité assez basse. 

• Lors des différentes sessions de cette conférence, j’ai observé qu’environ la moitié des participants estiment que leurs pratiques penchent plutôt du côté du pire cas. 
• Feedback particulier : « J’ai trouvé vos exemples de mauvaises pratiques un peu extrêmes. Il me semble que des entreprises qui se trouvent avec ce mode de fonctionnement vont droit à la faillite. » 

Ce feedback particulier m’a interpellé car, malheureusement, les pires cas cités sont issus d’observations terrain. De plus, ces mauvaises pratiques sont, de mon expérience, plutôt répandues. Après, il y a probablement un biais dans mes observations. En effet, mes clients sont, pour la plupart, des grandes entreprises qui ont à la fois les moyens de se payer du coaching et le besoin d’être accompagnées. Ces grosses structures manipulent, de par leur taille, une masse financière importante et peuvent probablement absorber les effets d’un gaspillage qui ne pourraient pas l’être par de plus petites structures. 

En conclusion, j’espère, avec cette petite conférence, vous avoir donné de l’inspiration et apporter ma modeste contribution à l’amélioration de nos pratiques professionnelles.