Comment concevoir un poste numérique pour des opérateurs qui ne lisent pas la consigne
Quand un opérateur ne suit pas la procédure, la première conclusion est souvent qu'il manque de rigueur. J'ai pensé la même chose, jusqu'à ce que je travaille dans un atelier où une partie de l'équipe ne lisait pas le français couramment. La contrainte est devenue impossible à ignorer — et elle m'a forcé à regarder le vrai problème : une consigne écrite est lue une fois, à l'intégration, puis jamais. Sous cadence, avec des gants, dans le bruit, le texte perd systématiquement. Ce n'est pas un problème de discipline. C'est un problème de support.
« Ils ne lisent pas la consigne » dit quelque chose du poste, pas des gens
La procédure signée donne l'impression d'être couvert. Tout le monde a paraphé, le classeur est à jour, le responsable qualité peut montrer la fiche. Mais sur le poste, personne ne la consulte. Et si vous y réfléchissez : pourquoi le ferait-on ? La fiche est dans le classeur, pas sur le poste. Elle contient dix étapes quand l'opérateur n'a besoin que de l'étape en cours. Elle dit ce qu'il faut faire en toutes lettres, dans une langue que certains maîtrisent mal, au moment où les deux mains sont occupées.
Ce n'est pas de la mauvaise volonté. C'est une conception qui n'a pas intégré les conditions réelles du travail.
Montrer plutôt que dire, et ne poser qu'une décision à la fois
Dans un atelier de reconditionnement manuel — une structure d'insertion de cinquante personnes — j'ai travaillé sur une application destinée à guider les opérateurs à travers six points de contrôle qualité, avec une contrainte ferme : aucun texte. Chaque écran ne posait qu'une question, sous forme d'image. Bon ou pas bon. L'opérateur ne déclarait rien : c'est le système qui enregistrait la réponse, horodatée, traçable pour la réglementation en vigueur.
Le principe du détrompeur numérique change la question. On ne se demande plus « comment expliquer l'erreur à éviter » mais « comment rendre l'erreur impossible à commettre sans que le système le remarque ». La différence est énorme : dans le premier cas, on forme et on espère ; dans le second, on conçoit et on vérifie.
Cette approche fonctionne aussi hors contexte d'insertion. La cadence, les intérimaires en poste depuis trois jours, la fatigue en fin d'équipe — ces facteurs produisent exactement la même réalité, juste moins visible parce que les opérateurs ont l'air de lire le français. L'atelier d'insertion a rendu la contrainte explicite. Ailleurs, elle existe quand même.
Ce travail a un prérequis qu'on oublie souvent
On ne numérise pas bien un processus flou. Dans le même type d'atelier, avant de toucher au moindre écran, il a fallu analyse la chaine de valeur, comprendre les flux, définir un logigramme décisionnel, modéliser les rôles, organiser les postes en 5S. Des rôles distincts ont été documentés. Ce travail amont est la condition pour que chaque décision de conception soit arbitrable : si on ne sait pas exactement ce que fait l'opérateur à l'étape trois, on ne peut pas décider quelle interaction créer.
La même logique vaut pour la transmission entre équipes. Sur un site de haute technologie en salle blanche, j'ai eu à construire un outil de passage de consignes pour des équipes postées. L'objectif n'était pas de rédiger davantage — il y avait déjà beaucoup d'écrit. C'était de rendre traçables les problèmes récurrents qui se perdaient entre deux équipes, sans que personne puisse affirmer les avoir signalés. La preuve ne peut pas venir de ce que l'opérateur déclare : elle doit être produite par le système.
En 2012, pour un site de production agroalimentaire aseptique, j'ai mis en place un outil informatique de collectes des arrêts de production automatique avec connexion aux capteurs existant sur les lignes de production afin de pouvoir mesurer en permanence les cadences, les durées d'arrêt planifiés & non planifié ainsi que les micros arrêt qui irritent les opérateurs de production voire les obligent à mettre les mains dans les machines (risque sécurité). L'outil déjà prérempli par des groupes de travails en amont du projet, permettant de sélectionner en deux clics et de manière inclusive les causes des arrêts, cadence faible ou dépassement du temps d'arrêt autorisé.
Ce que ça coûte réellement
Il serait inexact de présenter cette approche comme simplement plus efficace qu'une procédure écrite. Elle est aussi beaucoup plus longue à concevoir.
Rédiger une procédure prend quelques heures. Concevoir sans texte demande de rester au poste à regarder travailler — pas en réunion, au poste — jusqu'à comprendre où l'ambiguïté se loge vraiment. Chaque cas limite doit être tranché par la conception elle-même, pas par une phrase explicative qu'on ajouterait en marge. Et quand on retire le texte, on perd aussi le confort de la procédure signée : la couverture formelle disparaît, et il faut assumer que la qualité tient à la conception du système, pas à un document.
Sur des ateliers de vingt à cinquante personnes à dominante manuelle, ce temps d'investissement reste absorbable. Ce serait une autre affaire sur un site industriel de plusieurs centaines de personnes avec des dizaines de postes différents — et je ne voudrais pas laisser croire que ces cas sont directement transposables à cette échelle à des industrie très normés (microélectronique, pharma, agro, automobile, aéronautique).
Ce qu'on peut faire dès maintenant
Prenez le poste qui concentre le plus de non-conformités ou de retours. Ne cherchez pas à réécrire la procédure. Passez une heure à regarder quelqu'un travailler dessus, sans intervenir. Comptez combien de fois l'opérateur a besoin d'une information qu'il ne peut pas trouver sans s'arrêter, chercher, demander. Quels sont ses Muda ?
Ce que vous observez n'est pas une erreur humaine à corriger. C'est une liste de décisions de conception à prendre. La procédure en classeur ne les prendra jamais à votre place.