Le diagramme en arête de poisson place un problème observable à la tête du poisson et répartit les causes possibles par catégorie sur les arêtes principales et leurs branches. L'outil ne se contente pas d'écrire des noms de causes : il conserve la cause parente, le statut de preuve, les éléments favorables ou contraires, la prochaine vérification et le responsable. Le schéma exporté se rattache ainsi au travail d'enquête, au lieu de s'arrêter à un remue-méninges.

Les six catégories par défaut sont main-d'œuvre, machines, matières, méthodes, environnement et mesure ; leurs noms s'adaptent à un service, à des études ou à la vie quotidienne. Ce sont des repères pour repérer les oublis, pas des réponses à remplir coûte que coûte. Chaque trait du schéma représente d'abord une explication à tester, jamais une causalité démontrée.

1. 01Écrivez le problème précis à la tête du poisson, avec le périmètre, la période d'observation et l'écart constaté, par exemple « les trois derniers jalons du projet de cours ont été déposés après la date convenue ». Évitez les étiquettes invérifiables du type « l'équipe est inefficace ».
2. 02Renommez les catégories selon le contexte. Un problème d'apprentissage peut utiliser compétences et soutien, outils et équipement, documents et entrées, déroulé d'étude, temps et environnement, puis retours et mesure.
3. 03Ajoutez les causes possibles et, si besoin, choisissez une cause parente pour former une chaîne de sous-causes. Supprimer une cause parente supprime aussi ses descendantes, avec un retour en arrière en une étape.
4. 04Pour chaque explication importante, enregistrez un statut de preuve : hypothèse à vérifier, preuves favorables déjà réunies, ou réfutation par les preuves. Les deux derniers statuts exigent de joindre les éléments ; des preuves favorables n'écartent pas les autres explications.
5. 05Indiquez comment vérifier ou réfuter, et qui contrôlera. Exportez le diagramme en PNG ou SVG avec la liste de vérification en Markdown ou CSV ; le JSON restaure l'ensemble.

L'ouvrage de Kaoru Ishikawa sur la gestion de la qualité a présenté de façon systématique le diagramme causes-effet comme outil de contrôle qualité. Les notes de méthode d'ASQ et de l'IHI l'emploient elles aussi pour repérer et organiser les causes possibles d'un résultat. Son intérêt est de rendre les explications visibles et de chercher les manques dans les différentes catégories ; ce n'est pas le dessin qui découvre une cause racine unique.Note de méthode ASQ, note d'outil IHI

Les arêtes principales portent les catégories, les branches portent les causes ou des sous-causes plus fines. Cette implémentation enregistre la structure avec des identifiants stables et des références parentes ; le canevas garde les fiches de chaque catégorie et affiche la référence parente sur une sous-cause. Une référence parente qui traverse les catégories déclenche une alerte de contrôle, pour que la disposition ne laisse pas croire que le rattachement est tranché. Les références circulaires sont impossibles et refusées à l'import.

Face à une carte mentale, le diagramme en arête de poisson organise les explications autour d'un même résultat observé ; face aux 5 Pourquoi, il incite à balayer plusieurs catégories au lieu de suivre une seule chaîne. Les deux peuvent se combiner : élargir d'abord les candidats, puis choisir la chaîne à soumettre à une vérification. Face à une analyse par arbre de défaillances formelle, l'outil n'offre ni probabilité de défaillance, ni calcul de porte logique, ni intégrité de sécurité, ni conclusion de certification.

Ses limites viennent de cette structure ouverte : les participants écrivent volontiers les causes qui leur sont familières, prennent une parole d'autorité pour une preuve, ou s'arrêtent à « quelqu'un n'a pas été sérieux ». Catégories et liaisons n'imposent aucun plan d'expérience ; il reste donc à examiner les processus, les informations, les ressources, l'environnement et les contre-exemples. Un diagramme achevé ne remplace pas l'investigation d'un incident à risque élevé.

Dans l'exemple « échec de restauration après publication », le problème s'énonce ainsi : un utilisateur ouvre un ancien brouillon, voit une page blanche et ne peut pas distinguer l'absence de données d'un échec de restauration. La catégorie méthode avance une vérification insuffisante de la restauration entre versions, avec pour sous-cause le manque d'échantillons d'ancien format ; la catégorie machines envisage un stockage limité ; la catégorie mesure un message d'erreur trop pauvre. Chaque hypothèse est reliée à un contrôle, par exemple rejouer la restauration avec une archive de la version précédente, plutôt que de déclarer qu'un développeur précis a causé le problème.

L'exemple « tâches d'étude sans cesse reportées » sépare la découpe des tâches, la date d'arrivée des documents, l'organisation entre travail et aide à un proche, et le mode de retour d'information. Comparer le temps disponible aux rendus déposés peut faire changer l'explication ; compter les heures d'étude ne suffit pas à juger si la compréhension est solide.

Problème : ouvrir un ancien brouillon donne une page blanche
Catégorie : méthode
Cause principale r1 : vérification insuffisante de la restauration entre versions
Sous-cause r2 → r1 : échantillons de données d'anciennes versions manquants
Statut : hypothèse à vérifier
Vérification : examiner les échantillons des publications passées et rejouer la restauration
Responsable : responsable des tests

• 80 causes au maximum, 20 niveaux de structure parent-enfant et six catégories renommables.

• Les catégories par défaut ne conviennent pas à tous les secteurs et leurs noms se modifient, mais cette page n'est pas un éditeur graphique libre.

• Des causes et des problèmes très longs agrandissent le canevas et le PNG peut être réduit ; le SVG garde le détail vectoriel et le JSON la structure modifiable.

• « Réfutée par les preuves » est un jugement saisi par l'utilisateur : l'outil ne contrôle pas les éléments, et une réfutation ne doit pas être supprimée pour alléger le schéma.

• Il ne sait ni identifier une cause racine, ni déduire une probabilité, ni prouver une causalité.

• Les questions médicales, de sécurité au travail et de responsabilité juridique relèvent de personnes qualifiées et des procédures officielles applicables.

Ne prenez pas une mesure corrective pour une cause : « il faut une formation » ne dit pas quelle lacune de compétence a été observée. Ne reformulez pas non plus le symptôme en explication, du genre « c'était en retard parce que ce n'était pas fini à l'heure ». Proposez d'abord un mécanisme précis que les éléments peuvent confirmer ou réfuter, puis fixez le contrôle.

Ne remplissez pas de causes sans fondement pour équilibrer les six catégories. La catégorie « personnel » peut traiter du soutien, des passations et des conditions de compétence ; elle ne doit pas devenir une colonne de reproches. Gardez les autres explications et les contre-exemples, et notez quel résultat retirerait son appui à l'hypothèse en cours.

• Convient à la recherche de régressions logicielles, aux temps d'attente d'un service, aux projets de cours repoussés, aux reprises de travail répétées et aux bilans de processus quotidiens.
• Quand l'action est déjà claire, utilisez une matrice d'actions ; pour comparer des solutions, une matrice de décision.
• Un incident à risque élevé ne se traite pas définitivement sur la seule sortie de cette page.

Le tri des causes, le dessin et l'export se font dans le navigateur, sans synchronisation de compte. L'enregistrement automatique n'est pas une sauvegarde : un nettoyage du navigateur peut l'effacer. Un lien de partage contient tout le document en clair et reste lisible par son porteur ; au-delà de 8 KB, passez à un fichier JSON. Les comptes rendus d'enquête touchent souvent à des informations personnelles ou clients : anonymisez d'abord et ne mettez jamais les éléments sensibles bruts dans un lien. Un import échoué ne remplace pas le travail en cours.

• Kaoru Ishikawa, Guide to Quality Control, Asian Productivity Organization, 1986 : l'ouvrage de l'auteur sur le contrôle qualité et le diagramme causes-effet.
• ASQ : Fishbone Diagram : note institutionnelle sur les causes possibles, les catégories et la construction du schéma. (consulté le 2026-09-22)
• IHI : Cause and Effect Diagram : usage du diagramme causes-effet dans les démarches d'amélioration ; la sortie de l'outil ne vaut pas certification médicale ou de sécurité. (consulté le 2026-09-22)