Le diagramme d’Ishikawa est connu sous de multiples noms. Inventé par le professeur japonais Kaoru Ishikawa en 1962, cet outil permet d’appréhender des problèmes complexes. Son but ? Pour éviter qu’un incident ne se reproduise, il est nécessaire de l’appréhender sous toutes ses facettes.
Pour cela, trois étapes : sur un graphique, lister les causes profondes d’un problème, les classer puis les hiérarchiser.
Comment établir un diagramme d’Ishikawa
Lorsqu’un incident survient, on l’étudie sous l’angle de ses intrants au fil du projet. Par intrant, nous entendons les moyens humains, techniques et financiers mis en œuvre pour produire quelque chose.Initialement destiné à l’industrie, M. Ishikawa les catégorise en 5M : Méthodes, Matières, Milieu, Matériel et Main d’œuvre.
Source : Wikipedia.fr
Il est possible d’adapter cette approche à l’IT, en mettant en avant des catégories plus pertinentes. Par exemple, étudions ici le cas d’un incident en production sur un projet Big data.
Etude de cas : la prod est en feu !
Nous sommes lundi matin : incident critique en production. De gros retards sont constatés dans le traitement des flux de données. Vous consultez les différents dashboards et outils pour vérifier les indicateurs.Il est essentiel d’identifier rapidement les causes profondes de ce problème pour le résoudre et éviter qu’il se reproduise. Où commence votre analyse ? Le diagramme d’Ishikawa est là pour ça, réunissez une petite équipe pluridisciplinaire pour une session d’une heure et en avant !
Avant tout, vous pouvez adapter les catégories à votre contexte. Pensez à toutes les facettes qui conditionnent la vie de votre projet. Vous pouvez vous inspirer du 5M d’Ishikawa pour construire, avec votre équipe, les catégories pertinentes à votre contexte. Pour des projets Big Data, les intrants peuvent être : Code, Infra, Ops, Données, Processus.
1 : Définition de l’effet
En tête de poisson : le problème. Chaque arête est une catégorie d’intrant
Vous pouvez utiliser ce Template miro.
Premier tour de table. En étudiant les données, l’équipe cherche à qualifier l’effet négatif. Il convient de le délimiter et de collecter de la donnée pour éclairer l’analyse. Vous pouvez utiliser un outil comme Miro, ou encore des bons vieux post-its. Prévoyez de la place, certaines analyses peuvent aller loin.
2 : Identification des causes
À chaque branche, on cherche les causes possibles. Lorsqu’une cause peut être expliquée par une autre, on rajoute sur une branche. Ainsi, les causes profondes se révèlent.
L’important ici n’est pas de juger, mais d’explorer. On creuse chaque piste, même les plus improbables. L’objectif est d’être exhaustif, pas forcément précis à ce stade.
Dans un premier temps, une réflexion individuelle est nécessaire afin d’activer l’effet “purge” : un maximum d’idées sont émises, sans calquer son analyse sur les éléments déjà donnés. Ensuite, il est possible d’appairer les participants pour supprimer les doublons puis placer les idées sur le diagramme.
3 : Hiérarchisation des causes
Une fois toutes les causes identifiées, on passe à la priorisation. Qu’est-ce qui est probable ? Qu’est-ce qui a un fort impact ? Pour ça, chaque membre de l’équipe procède au dot voting. Très souvent, ce sont plusieurs causes qui s’entremêlent — c’est justement là que l’approche Ishikawa révèle toute sa puissance.
En offrant une vision structurée et visuelle des différentes familles de causes, elle permet de mettre en évidence les interactions entre facteurs techniques, organisationnels et humains. On ne cherche plus une cause unique, mais on identifie des systèmes de causes qui, combinés, mènent à l’incident. Cette approche systémique favorise des plans d’action plus ciblés, plus durables, et évite de tomber dans le piège de la solution rapide qui ne traite que les symptômes.
Dans notre exemple, on découvre que :
- Un nouveau flux a été déployé sans test de charge (Processus/données),
- Ces nouveaux batch n’ont pas déclenché d’alerte sur le week-end (Ops).
- Le noeud Spark s’en est trouvé saturé (infra)
4 : Actions correctives et amélioration continue
Identifier les causes, c’est bien. Mettre en place des actions correctives, c’est mieux. Pour chaque cause retenue, creuser le sujet avec l’équipe pour déterminer le meilleur moyen de la résoudre : systématiser (voire automatiser) les tests de charge (avec quels outils ?), renforcer la surveillance des volumes, créer des alertes sur les durées d’exécution.
Ici, la méthode des 5 Pourquois est utile pour enquêter sur une root cause et trouver une solution d’amélioration par exemple. Pourquoi cette cause est survenue, pourquoi…etc.
Vous aurez certainement plusieurs actions au sortir de cette étape. Il faudra alors les prioriser pour être efficace dans leur implémentation.
Et surtout, on s’inscrit dans une logique d’amélioration continue. Après la résolution, l’équipe partagera les enseignements dans une rétrospective technique ou un post-mortem. On documente, on adapte les process, on prévient les répétitions.
Conclusion
Le diagramme d’Ishikawa est un outil puissant pour structurer une réflexion collective après un incident. En adaptant ses catégories à votre contexte (Big Data, DevOps, API, etc.), vous transformez un problème en opportunité d’apprentissage. L’incident devient un tremplin vers plus de robustesse, stabilité et performance des systèmes informatiques.
On peut également utiliser le diagramme d’Ishikawa pour traiter des sujets plus larges, comme “Pourquoi l’incertitude empêche-t-elle de prendre des décisions ?”
En utilisant la pensée en diamant (élargissement de la réflexion pour générer de l’idée, focus sur les points les plus pertinents) vous maximisez vos chances de réussir cet atelier. Le dot voting, puis le choix des actions correctives sont une belle manière de pratiquer l’intelligence collective et mettre en pratique le savoir d’une équipe.
En résumé : quand la prod est en feu, pensez à sortir la tête de poisson.
