Sur le tableau, une flèche file vers la droite. À son extrémité, un problème formulé sans détour : « Les livraisons arrivent trop tard ». De longues arêtes obliques viennent s’y raccorder, portant des mots comme « méthode », « matériel », « fournisseurs », « planning ». En quelques minutes, une plainte vague a pris la forme d’un paysage explorable. C’est toute la force du diagramme d’Ishikawa : faire apparaître les chemins possibles qui mènent à un effet indésirable.

On le surnomme volontiers « diagramme en arêtes de poisson ». L’image est juste, mais elle pourrait faire oublier l’essentiel : cet outil n’est pas un joli dessin de réunion. C’est une discipline de pensée. Il oblige un groupe à passer d’une intuition rapide — « c’est la faute de… » — à une exploration plus patiente des conditions, habitudes, décisions et contraintes qui produisent un résultat.

Un poisson pour sortir du réflexe du coupable

Lorsqu’un incident se répète, les organisations cherchent souvent une cause unique. Un retard serait dû à une personne distraite ; un client mécontent, à un message maladroit ; une panne, à un logiciel défaillant. Cette tentation est humaine : une explication simple rassure et semble immédiatement actionnable.

Mais la plupart des problèmes de travail ne ressemblent pas à une bille tombée d’une table pour une raison unique. Ils émergent d’un système : des consignes ambiguës, une charge variable, un outil mal configuré, un contrôle absent, une information arrivée trop tard. Le diagramme sert à cartographier ces hypothèses sans les confondre avec des certitudes.

À droite se place l’effet étudié : défaut constaté, délai non tenu, erreur récurrente, baisse de qualité, friction client. À gauche, les grandes branches représentent les familles de causes potentielles. Des ramifications plus fines détaillent ensuite les mécanismes envisagés.

Le dessin a un mérite décisif : il rend visible la différence entre une explication et une accusation. « L’opérateur n’a pas suivi la procédure » n’est pas encore une cause satisfaisante. La procédure était-elle accessible ? Compréhensible ? Compatible avec la réalité du terrain ? Connue des nouveaux arrivants ? Contrôlée à un moment utile ? L’arête de poisson invite à poursuivre le raisonnement.

Un problème bien décrit n’est pas encore résolu ; il devient simplement moins facile à mal résoudre.

Commencer par une tête de poisson nette

La qualité d’un diagramme dépend d’abord de la précision du problème inscrit à sa pointe. « Notre communication ne marche pas » est trop flou : chacun y projettera son propre sujet. « Les demandes adressées au support restent sans première réponse pendant plusieurs jours » ouvre déjà une enquête plus concrète.

Une formulation utile décrit un fait observable, son périmètre et, si possible, les conditions de son apparition. Il faut éviter de glisser une explication dans l’énoncé. « Les clients abandonnent à cause du formulaire » préjuge déjà de la réponse. Mieux vaut écrire : « Une part importante des visiteurs quitte le parcours avant l’envoi du formulaire. »

Cette prudence linguistique n’est pas du formalisme. Elle protège l’analyse contre le biais de confirmation : une équipe qui croit connaître la cause ne recueille souvent que les éléments qui confortent son intuition.

• Décrire le résultat indésirable, non le responsable supposé.
• Choisir un seul problème par diagramme.
• Employer des termes compris de tous les participants.
• Distinguer les faits observés des interprétations.
• Délimiter la situation : quel processus, quel public, quel moment ?

Les grandes arêtes : une grille, pas une religion

La version la plus connue du diagramme s’appuie sur les 5M. Ces catégories, issues des démarches de qualité, constituent une aide-mémoire très pratique :

• Main-d’œuvre : compétences, transmission, disponibilité, répartition des rôles, fatigue, coordination.
• Méthodes : procédures, séquences de travail, règles de validation, documentation, priorisation.
• Matériel : machines, logiciels, interfaces, équipements, accès, maintenance.
• Matières : données, composants, contenus, informations fournies en entrée, qualité des ressources.
• Milieu : environnement physique ou organisationnel, interruptions, contraintes réglementaires, culture d’équipe, saisonnalité.

Certains ajoutent la mesure : indicateurs, instruments de contrôle, règles de calcul ou qualité des données. Cette extension peut être précieuse dans les activités où l’on pilote beaucoup par tableau de bord. Après tout, une mauvaise mesure ne produit pas seulement une mauvaise lecture : elle peut entraîner de mauvaises décisions.

Il serait toutefois absurde de plaquer mécaniquement les mêmes catégories sur tous les sujets. Pour un produit numérique, des branches comme « parcours utilisateur », « architecture technique », « contenu », « gouvernance » et « support » seront parfois plus parlantes. Pour une équipe éditoriale, « brief », « sources », « validation », « calendrier » et « diffusion » peuvent mieux refléter le travail réel.

La grille n’a donc pas vocation à imposer le monde tel qu’il devrait être rangé. Elle sert à empêcher que l’enquête ne s’arrête aux causes les plus visibles.

De l’idée lancée à la piste vérifiable

Le diagramme commence généralement par un remue-méninges. Ce moment doit rester ouvert : on note les hypothèses, y compris celles qui paraissent banales ou inconfortables. Une branche peut ainsi faire apparaître qu’un outil est lent, mais aussi qu’une règle de validation multiplie les allers-retours, ou que deux services ne disposent pas de la même version d’une information.

Ensuite, il faut descendre d’un niveau. À chaque hypothèse, la question « pourquoi ? » permet d’ajouter une sous-cause. Si les réponses client sont tardives, est-ce parce que les demandes sont mal orientées ? Parce que les catégories ne sont pas homogènes ? Parce que personne n’est clairement responsable du tri ? Parce que le tri n’est fait qu’à certains moments ?

Ce mouvement vers les détails est utile à condition de ne pas tourner à l’interrogatoire abstrait. Une cause devient intéressante lorsqu’elle peut être vérifiée : par observation, par comparaison de cas, par lecture d’un historique, par échange avec les personnes concernées ou par un test limité.

C’est là que le diagramme retrouve sa juste place. Il ne démontre pas la causalité. Il organise des hypothèses causales. Une branche très fournie n’est pas nécessairement la plus importante ; elle peut simplement refléter la loquacité du groupe ou la familiarité de ses membres avec un sujet.

Le passage décisif : enquêter plutôt que décorer

Un diagramme est souvent réussi graphiquement bien avant d’être utile. Le risque est de le photographier à la fin de l’atelier, puis de le laisser dormir dans un dossier partagé. Son utilité commence après la réunion, lorsque l’équipe sélectionne quelques pistes à examiner.

On peut alors évaluer chaque hypothèse selon des critères simples : quelles preuves existent déjà ? Quelle vérification est possible ? Quel serait l’impact si cette cause était confirmée ? Qui peut agir dessus ? Cette étape évite deux écueils symétriques : vouloir tout corriger d’un coup, ou choisir la solution la plus commode sans avoir testé le diagnostic.

La recherche des causes racines ne signifie pas qu’il existerait forcément une racine unique, cachée au fond du système. Dans un environnement complexe, plusieurs facteurs peuvent se combiner. Le bon objectif consiste plutôt à repérer des conditions suffisamment déterminantes et modifiables pour réduire durablement la probabilité du problème.

Une action correctrice solide répond donc à une hypothèse étayée. Si les erreurs viennent d’une information source instable, former davantage les équipes ne réglera pas le défaut principal. Si le processus est devenu inutilement complexe, demander « plus de vigilance » revient à transférer le coût du mauvais système vers les individus.

Ce que le diagramme révèle aussi d’une équipe

Au-delà de l’analyse technique, l’outil fait souvent émerger des zones silencieuses. Les équipes découvrent qu’elles n’emploient pas les mêmes mots pour désigner une même étape, qu’un savoir essentiel n’est détenu que par une personne, ou qu’une contrainte connue sur le terrain n’apparaît dans aucun document.

À condition que la discussion soit menée sans recherche de coupable, le diagramme crée une conversation rare : chacun peut décrire sa portion du système sans devoir défendre son territoire. La personne qui exécute une tâche, celle qui la conçoit et celle qui en reçoit le résultat n’observent jamais tout à fait le même processus. Réunir ces regards est souvent plus fécond que chercher immédiatement une solution brillante.

Le diagramme d’Ishikawa reste ainsi un outil remarquablement contemporain. À l’heure des flux numériques, des chaînes de décision dispersées et des problèmes hybrides, il rappelle une idée simple : avant d’optimiser, automatiser ou réorganiser, il faut apprendre à voir les liens qui produisent ce qui ne fonctionne pas.