Si vous n’essayez pas, vous ne saurez JAMAIS…

Temps de lecture estimé : 4 minutes

Ces dernières semaines, j’étais dans une entreprise d’un grand groupe industriel pour les accompagner sur le prototypage rapide d’un moyen qu’ils développent : un chariot de contrôle.

La transformation du chariot revêt plusieurs objectifs : faciliter l’accès à l’ensemble des faces du produits (4) pour permettre le contrôle visuel et l’accès physique aux éléments, tout en réduisant les manutentions.

C’est en m’appuyant en grande partie sur cet exemple concret que je vais essayer d’illustrer 3 constats que nous faisons lors de chaque projet de prototypage.

1er constat : On ne sait pas ce que l’on veut.

« Si tu veux satisfaire ton client, le premier truc à faire, c’est de ne surtout pas l’écouter ». Steeve Jobs

Qu’en est-il quand on travaille avec l’utilisateur? Et bien c’est un peu la même chose !

Pour l’entreprise porteuse du projet, le prototypage est une démarche nouvelle. Jour 1, on m’a donc donné un cahier des charges (comme ils le font habituellement) avec un chariot FULL options (sans les vitres tintées 😉 ) : réglable en hauteur, des rotations de partout, motorisé, les dimensions et le principe d’utilisation déjà parfaitement définis.

Sur la base de ce cahier des charges, nous avons conçu notre premier prototype : on l’appellera « Produit Minimum Viable » (PMV) et il évoluera au fil des itérations.

Le 1er test utilisateur (utilisation du prototype en situation réelle, avec les utilisateurs habituels) nous a permis d’apprendre bien des choses : finalement, on ne sait pas trop ce que l’on veut. On s’aperçoit que la hauteur réglable ne sert à rien, que la motorisation non plus et que les dimensions du chariot ne permettent pas de travailler dans de bonnes conditions.
Cependant, ce test valide le principe d’utilisation, totalement nouveau par rapport à l’ancien chariot : on a une solution utile, mais pas encore utilisable.

Pour l’équipe, la première impression est mitigée. Elle est d’abord surprise de voir que leur besoin n’était pas très clair et qu’il est inutile de faire un cahier des charges avant de prototyper (si votre objectif est d’avoir une solution utile et utilisable à la fin, bien sûr 😉 !). Elle a également le sentiment d’avoir beaucoup travaillé pour rien car la solution qu’ils ont imaginée ne fonctionne pas.

En soit, le fait de ne pas connaître la solution paraît même logique… si l’entreprise connaissait la solution pour avoir « un bon chariot », elle n’aurait pas fait l’erreur sur la version précédente… En réalité, c’est tout l’inverse. L’immense travail fourni par l’équipe nous a permis d’apprendre, et c’est bien le but principal du prototypage : apprendre à moindre coût et le plus tôt possible. Ils le comprendront au fil du projet.

Constat 2 : Accepter de se tromper, c’est difficile.

C’est le début du Jour 2. On commence la journée en faisant évoluer le prototype en tenant compte des hypothèses formulées le jour précédent.

On change les dimensions, on prend une décision sur la hauteur de rotation du produit. En réalisant la V2, l’équipe se rend compte que les hypothèses  sur les dimensions ne sont pas bonnes et souhaite faire évoluer la V2 en V3 sans réaliser de test utilisateur.

Arrive le moment du débat que l’on connait tous, cela ressemble à ça :

• « moi je pense que c’est 80cm »
• « Non, c’est 50cm, regarde là c’est trop grand. Il faut changer »
• « Oui mais non parce que… »

Hey, vous n’avez jamais travaillé avec cette dimension de chariot, comment pouvez-vous savoir que la dimension que vous avez choisi initialement n’est pas bonne ?!?! Prototyper, c’est montrer plutôt que démontrer. C’est essayer ses idées le plus rapidement possible pour les faire évoluer en fonction des retours utilisateurs, et non sur la base de ses idées. Se tromper sur la dimension du chariot, ce n’est pas grave, on apprendra si c’est trop grand, ou trop petit en TESTANT.

Vous connaissez tous ça, la peur de faire une erreur, l’envie de confronter tout de suite l’utilisateur à un produit parfait, même si cela passe par des heures et des heures de travail en amont.

Que se passe-t-il quand votre hypothèses ne marche pas, après toutes ces ressources engagées ?

Le SEUL élément qui doit guider l’évolution de votre PMV est les données du test utilisateur. On ne transforme JAMAIS, JAMAIS son idée sans l’avoir testé en situation d’usage réel.

« In God we trust. All others must bring data ». WE. Deming

Petit paradoxe de l’expérience, les dimensions de la V2 étaient finalement bonnes =)

Constat 3 : L’engagement, c’est mieux que « la bonne idée ».

Pour faire ce constat, je vais m’appuyer sur un autre cas rencontré. L’entreprise en question a de grand problème de place et souhaite proposer à ces utilisateurs un environnement de travail adapté pour améliorer les Conditions de Travail, tout en réduisant au minimum de 30% la surface au sol occupée. Des mois qu’elle y travaille pour en arriver par le même constat par les utilisateurs : « C’est pas possible ».

En intégrant l’utilisateur dans la phase d’idéation, il a proposé de réduire de 50% la surface de son poste. En réalisant le prototype ? Il a encore réduit (sans tester, pas bien on a dit !!!) de 25% la surface initiale, soit une réduction de 75% avant test utilisateur.

En situation de travail réel, on s’est très vite aperçu que réduire le poste de 75% tout en proposant de bonnes conditions de travail était impossible. Par l’expérimentation, nous sommes arrivés, après plusieurs itérations à un poste réduit d’environ 50%.

Que s’est-il passé entre le début du projet ou l’objectif était « impossible » et la validation finale ? L’utilisateur est engagé dans la démarche. C’est à dire que dans le processus de conception, il n’est pas sollicité pour donner son avis ou pour nous remonter des problèmes : il est acteur, avec nous, dans la conception de SON environnement de travail.

C’est la grande différence entre une « solution exceptionnelle » (pas tant que ça finalement) qui ne sera pas utilisé et une solution, parfois plus simple, répondant strictement au besoin et à ce que valorise l’utilisateur.

Dans cette approche, l’utilisateur est dans une dynamique de réflexion sur sa situation de travail lui permettant dans une premier temps d’accepter et d’utiliser le poste, puis dans un second de le faire évoluer avec l’expérience.

Et chez vous, le prototypage est-il intégré dans vos pratiques ? Qu’en avez-vous appris ?

Quelles compétences le manager doit-il acquérir pour aider son collaborateur à se développer ?

La semaine dernière, j’étais dans une entreprise d’un grand groupe industriel de l’aéronautique pour travailler sur le développement des Hommes et la transmission de savoir-faire clés.

L’entreprise fabrique des produits complexes où la qualité, avec une exigence maximale, dépend en grande partie de la compétence et du savoir-faire de l’opérateur.

Pour développer la capacité de l’opérateur à détecter des problèmes, à enrichir la vision de sa propre activité et accélérer la transmission de savoir-faire, l’entreprise développe une routine entre le manager et son collaborateur.

Marc, le manager de la zone, est un peu hésitant. Cela fait 4 semaines qu’il réalise quotidiennement un atelier avec ses collaborateurs (chaque jour une personne différente, dans un « roulement » organisé) pour préparer la journée d’aujourd’hui mais là, c’est le premier exercice que l’on fait ensemble pour comprendre et analyser la pratique qu’il développe.

« Salut Richard. Je viens pour l’atelier. C’est pas un audit, fait comme si je n’étais pas là. Est-ce que tu peux m’expliquer sur quoi tu bosses ? ». Très vite, l’échange s’installe entre Marc et l’opérateur, qui lui explique ce qu’il fait avec la fiche d’instruction non loin de là en support pour illustrer ce qu’il raconte.

Marc s’intéresse à l’activité et pose de nombreuses questions « Et qu’est-ce que tu penses de ce problème ? », « Et ça [il montre un document de suivi administratif pour un produit] c’est important, comment tu le gères ? [ils regardent le document ensemble] ». JB, opérateur de l’îlot depuis 7 ans, joue le jeu et répond aux questions.

Après 20 minutes d’échanges, c’est le moment pour le manager de faire un débriefe avec l’opérateur afin d’exploiter ce qu’ils ont appris durant ces 20 minutes. « Alors voilà ce que j’ai vu… [Marc fait une synthèse de ses notes en direct] ». Une fois le rapide résumé réalisé, il propose de travailler sur un problème qu’il a identifié grâce à l’exercice. Les deux Hommes se mettent d’accord avant de se séparer.

Point de vue utilisateur VS point de vue manager ?

Sur l’exercice, on peut légitimement se questionner sur le point de vue de l’utilisateur. Voici le bilan que nous avons fait avec le manager à l’issu de l’atelier :

• On s’est surtout intéressé au processus et à l’aspect technique, et non à l’activité réelle de l’utilisateur,
• Marc n’a pas cherché à faire verbaliser l’opérateur sur sa propre expérience, sa vision ou encore sa façon de faire. Non, dans l’exercice, ce qu’il a essayé de faire, c’est avant tout d’obtenir un retour d’informations de l’opérateur pour conforter ou faire évoluer sa propre vision de l’activité.
• L’exercice a permis au manager d’apprendre des choses sur le terrain et d’identifier des problèmes (de son point de vue). Mais pour l’opérateur, le bilan nous semble plus léger. Qu’a-t-il appris ?! En quoi l’a-t-on aidé à se développer / à progresser ?

L’hypothèse d’amélioration que nous formulons pour le prochain exercice, c’est de plus s’intéresser aux usages de l’opérateur. C’est lui qui doit parler, c’est sa vision de l’activité qui doit ressortir de l’atelier. Pour ce faire, l’atelier ne sera pas une discussion : l’opérateur doit continuer de travailler « normalement ».

Développer le regard de l’opérateur

L’opérateur est-il le mieux placé pour expliquer sa propre activité ?

Avec l’expérience, une partie de l’activité se fait en « pilote automatique ». Nous travaillons par habitude, les situations que nous rencontrons tous les jours deviennent normales, les opérations / pratiques / réponses (pourtant parfois d’une complexité importante) sont intégrées par l’opérateur : il n’a plus forcément conscience de tout ce qu’il fait, des compétences et astuces qu’il mobilise pour réaliser son activité parce qu’après tout… c’est normal pour lui de le faire. On parle alors de savoir-faire tacites.

Le rôle du manager dans cet exercice et d’aider l’opérateur à reprendre conscience de cette activité, de sa situation de travail. Il doit être un facilitateur pour aider l’utilisateur à verbaliser ce qu’il fait, comment il le fait, voir même pourquoi il le fait.

Mettre des mots sur son activité, sur ses sensations ou sur des savoir-faire intégrés depuis bien des années peut paraître simple mais c’est en réalité loin d’être facile. Vous pouvez faire l’exercice sur quelque chose que vous faites tous les jours : trouver le point d’embrayage sur un véhicule. Alors, surpris ? C’est un geste anodin si vous avez le permis de conduire, et pourtant, je suis persuadé que ce sera une réelle difficulté pour votre enfant et qu’il vous sera difficile de mettre des mots pour l’aider.

C’est un réel exercice d’apprentissage pour l’opérateur… et pour le manager. Nous l’avons d’ailleurs très bien vu lors du 2^ème exercice. Il doit apprendre à devenir ce facilitateur pour aider l’opérateur à décrire, à mettre des mots sur des connaissances ou compétences parfois intégrées et loin de toute conscience.

Et vous, comment faites-vous pour développer l’ensemble des acteurs dans votre entreprise ?

Pourquoi ce blog ?

Je m’appelle David Le Pré et suis ergonome chez LAB’ergo, une structure dédiée à l’ergonomie et la compréhension des usages.

Pourquoi ce blog ?

Malgré les importantes avancées que j’ai le plaisir de voir tous les jours chez nos clients , je constate qu’il est encore difficile pour beaucoup d’industrialiser cette approche centrée utilisateur. Le monde de l’entreprise est lent, la technique domine et ses acteurs sont de moins en moins… acteurs !

J’espère, à travers ce blog, partager – discuter et enrichir ma vision d’une entreprise dynamique et innovante où le travail est source de développement et l’expérimentation reine.

Le monde change, le travail aussi. Celui qui gagne n’est pas celui qui bouge, tout le monde bouge : il faut le faire plus vite.