Pilier Résolution de problèmes, article 4 - Traiter les causes, pas les symptômes
Si vous lisez cet article, c'est probablement que vous vous intéressez à la manière dont on décortique un problème - sans oublier que cela n'est possible qu'à la condition de l'avoir décrit et bien formulé. C'était l'objet du précédent (Résoudre des problèmes : des ressentis aux faits); celui-ci commence là où il s'arrêtait. Le problème est posé : nous allons chercher ce qui le produit, imaginer des solutions, arbitrer - puis vérifier que la solution choisie contribue réellement à le résoudre.
Voyons cela avec notre cas fil rouge, du symptôme à la décision.
Où en sommes-nous ?
Un cas nous sert de fil rouge, rappelons-le pour ceux qui arrivent ici directement. Une équipe gérait ses projets au rythme des Go/No-Go et se plaignait :
Une fois la plainte filtrée - analyse fonctionnelle, QQOQCCP, Est / N'est pas, dessins - la reformulation disait autre chose :
Le problème était posé, cartographié, dessiné. Il n'était pas encore expliqué.
Un avertissement d'abord. Cette méthodologie s'applique aux problèmes d'organisation - pas aux ampoules. Face à un objet à une cause, la démarche naturelle suffit, et il n'y a rien à intellectualiser : vous savez déjà faire. Un problème d'organisation exige plus, parce qu'il se regarde autrement : des flux, des goulots d'étranglement, des dépendances, des règles d'interface. Le diagnostic d'ici n'est pas l'inspection d'une douille, c'est la plongée dans un système.
Rappelons les cinq étapes de la démarche :
| L'étape | Le point de vigilance |
|---|---|
| 1. Poser le problème → Transformer un ressenti en énoncé factuel et exploitable |
La description est entachée de subjectivité : se mettre d'accord à plusieurs sur ce qu'on voit et comprend est déjà difficile. Tout seul, c'est encore plus compliqué. |
| 2. Identifier les causes → Chercher ce qui produit l'écart, pas qui le provoque |
Traiter toutes les causes disperse le capital de temps, d'énergie et d'attention (TEA) : chercher les causes maîtresses - 20 % des causes pèsent 80 % des effets (cf. loi de Pareto). |
| 3. Imaginer des solutions → Ouvrir plusieurs hypothèses, pas une seule |
On ne peut pas inventer ce qu'on ne connaît pas : aller chercher ailleurs : benchmarks, créativité, penser à côté (la pensée latérale). |
| 4. Choisir → Expliciter les critères et arbitrer |
Inutile de se disperser sur toutes les solutions imaginables : se concentrer sur celles qui produisent le plus de résultats (Pareto, encore). |
| 5. Vérifier → S'assurer que la solution contribue à la résolution |
La faiblesse habituelle de la démarche : l'insuffisance de la rétroaction et du suivi. |
Cet article traite des lignes 2 à 4 — puis de la cinquième, que tout le monde croyait pouvoir sauter.
La rustine
Nous tenons notre problème : les huit jours de délai sur le document X. Le réflexe immédiat ? Créer une alerte mail automatique pour relancer le demandeur. Ou ajouter un point de passage de contrôle. En vingt minutes, c'est réglé, et tout le monde repart satisfait.
C'est une rustine. On s'attaque au symptôme (le délai) sans chercher pourquoi ce document manque ou pourquoi ce contrôle bloque. Résultat : le problème réapparaîtra sous une autre forme la semaine prochaine. L'alerte automatique ne fabrique pas un bon format ; elle ne fait que crier plus vite qu'il est mauvais.
Remonter aux causes racines — sans se noyer
Pourquoi chercher les causes ? Pour passer de la réaction au pilotage. Tant qu'on ne sait pas ce qui produit l'écart, on subit ; dès qu'on le sait, on décide.
Deux pièges d'abord, car la recherche des causes a ses réflexes malsains :
La première cause commode
Celle qui arrange, celle qui désigne un coupable : « c'est le service financier ». C'est presque toujours une défaillance de regard, pas de méthode - le coupable désigné clôt la question avant qu'elle soit posée.
La dispersion
Un problème d'organisation a toujours plus de causes qu'il n'en faut. Les traiter toutes disperse le capital de temps, d'énergie et d'attention. On cherche les causes maîtresses : 20 % des causes produisent 80 % des dysfonctionnements - la loi de Pareto, encore.
La boîte à outils du diagnostic tient en trois outils simples, trois fonctions distinctes. Leur mode d'emploi du béotien (une feuille, des post-its) fera l'objet du dernier article de la série ; ici, retenons ce que chacun apporte :
Ouvrir
Le brainstorming : lister toutes les hypothèses de dysfonctionnement, sans auto-censure - on triera après.
Structurer
Le diagramme d'Ishikawa : ranger les hypothèses par grandes familles (les 5 M : Milieu, Main-d'œuvre, Matière, Matériel, Méthodes), pour que la réflexion collective y voie clair.
Approfondir
La méthode des 5 Pourquoi : creuser pourquoi après pourquoi, pour ne pas s'arrêter à la première explication venue.
Une règle d'arrêt pour les 5 Pourquoi, apprise sur le terrain : on s'arrête quand la cause sort du champ de celui qui agit. Au-delà de trois niveaux, ce n'est plus lui qui peut faire quelque chose.
Trois fonctions, un même geste : transformer un ressenti de cause en une hypothèse vérifiable. C'est tout ce que le diagnostic demande ; le reste est de la technique, et la technique a son article.
Le cas, déroulé
Retour au document X. Creusons :
Pourquoi le document arrive-t-il au mauvais format ?
→ Parce qu'aucun gabarit n'existe ; chacun refabrique le sien.
Pourquoi aucun gabarit n'existe-t-il ?
→ Parce que les deux services ne partagent pas le même outil, et que personne n'a jamais tranché.
Pourquoi personne n'a-t-il jamais tranché ?
→ Parce que la règle du format attendu n'appartient à personne : la donnée existe, mais dans la tête de l'actuel contrôleur.
Trois niveaux, une cause maîtresse :
Ce n'est pas le service financier qui est en cause, ce n'est même pas le circuit : c'est une règle manquante à un point de jonction. Le coupable désigné de la plainte initiale n'était pas commode par hasard : il était commode parce qu'il ne fallait surtout pas chercher là.
Imaginer et choisir : l'arbitrage pragmatique
La cause maîtresse identifiée, la question bascule. C'est la seconde fonction de l'analyse fonctionnelle que ce blog a présentée en son temps : comment faire pour... ?
- Les causes étaient les réponses à « en quoi est-ce un problème ? » ;
- les solutions sont les réponses au « comment faire pour... ? ».
Deux exigences, deux moments :
Ouvrir le champ.
→ On ne peut pas inventer ce qu'on ne connaît pas : pour chaque cause racine, ouvrir plusieurs hypothèses — la créativité, le benchmark (comment font les autres ?), la pensée latérale (regarder le problème par un autre bord). Trois solutions au minimum ici : un gabarit partagé et une règle de format notifiée ; la formation des demandeurs ; et, bien sûr, notre alerte mail automatique - la rustine, qui reparaît toujours dans les séances de créativité. Elle n'est pas interdite : elle est une candidate, pas une évidence.
Puis arbitrer.
→ C'est le geste que les groupes sautent volontiers : expliciter des critères de choix - impératifs d'abord (faisable, dans le délai, dans le budget), souhaitables ensuite (confort d'usage, impact sur le temps global, coût en capital temps, énergie et attention de la solution elle-même). Et pour trancher sans s'enliser dans les débats d'experts, une grille d'analyse multicritères avec pondération - ou la matrice de compatibilité quand les solutions doivent cohabiter.
Sur notre cas, la grille dit nettement :
| La solution | Coût / délai | Règle la cause ? | Verdict |
|---|---|---|---|
| Le gabarit partagé + règle de format notifiée | Deux semaines de mise au point | Oui - la cause maîtresse | D'abord |
| La formation des demandeurs | Une session, à renouveler | En partie : la demande, pas la règle | Qui accompagne |
| L'alerte mail automatique (la rustine) | Faible, immédiat | Non - crie plus vite que le format est mauvais | Gardien de secours |
L'arbitrage : le gabarit d'abord, la formation qui l'accompagne (et l'alerte, si on y tient, en gardien de secours).
Remarquez ce qui vient de se produire : le choix n'est plus une opinion, c'est un engagement daté sur des critères explicites. On pourra même l'évaluer - c'est l'objet de la dernière étape.
Vérifier - pas contrôler
Une solution arbitrée n'est pas un problème résolu. Reste l'étape que tout le monde croyait pouvoir sauter : vérifier que la solution contribue à la résolution. Le mot importe : on ne dit pas « contrôler ». Contrôler surveille l'exécution ; vérifier s'intéresse à la contribution : est-ce que ça résout, oui ou non ?
Quatre pièges guettent cette phase, et la pratique les connaît bien :
- Le problème déplacé : le délai se réduit au contrôle budgétaire et réapparaît à l'étape suivante. On n'a pas résolu, on a déplacé.
- L'effet rebond : la solution en crée de nouveaux - le gabarit partagé ajoute une version à maintenir.
- Le coût TEA jamais compté : la solution elle-même consomme du temps, de l'énergie et de l'attention. Une solution qui coûte plus cher que le problème n'en vaut pas la peine.
- L'absence de critère d'arrêt : sans date de vérification ni mesure de référence (huit jours, on la connaît), la vérification devient une intention, pas un geste.
Sur notre cas : trois mois plus tard, on mesure à nouveau le temps de traversée du circuit. S'il est tombé à deux jours, la boucle est close, et le constat de l'article 3 (« 20 minutes de travail effectif, 8 jours de traversée ») devient une mesure de référence pour toute la série de projets transverses.
Si le délai est resté, on ne repart pas de zéro : on revient au diagnostic, à la cause suivante. Et si le problème revient sous une autre forme dans six mois, vous savez désormais ce que c'est : pas un incident, mais un message du système sur lui-même.
Car la rétroaction ne sert pas qu'à vérifier. Elle a deux autres fonctions, qu'on perd de vue dès qu'on la réduit à un contrôle de conformité :
- Éviter que le problème se reproduise.
→ Vérifier, c'est aussi demander : que changeons-nous pour que la cause ne revienne pas ? Le gabarit est adopté ; la règle de format est notifiée dans le système, plus dans une tête. C'est la différence entre régler une occurrence et neutraliser une source. - Apprendre, constituer une mémoire.
→ Un problème résolu est un acquis : le déroulé (symptôme, diagnostic, arbitrage, mesure avant/après) vaut pour le prochain problème du même type, et pour la prochaine personne. L'expérience qui ne s'écrit pas n'existe que pour celui qui l'a eue - j'en avais fait l'un de mes « trucs » bien avant cette série : tenir la mémoire des choses faites, pour ne jamais repenser ou rechercher ce qu'on a déjà pensé et trouvé. La vérification est le moment où cette mémoire se constitue. Quelques lignes suffisent, mais il faut les écrire.
Le problème est désormais diagnostiqué à sa racine, la solution arbitrée, la vérification programmée. Et ce geste de rétroaction, vous le retrouverez en grand dans le dernier pilier de la démarche, l'évaluation : il n'est pas un appendice de la résolution, il en est le moteur.
📌 À retenir
- La méthodologie s'applique aux problèmes d'organisation : la rustine traitera toujours le symptôme, jamais la cause.
- Rectifier des erreurs est une dépense ; s'intéresser à leurs causes est un investissement.
- Deux pièges du diagnostic : la première cause commode (le coupable désigné) et la dispersion → chercher les causes maîtresses (Pareto).
- Trois outils, trois fonctions : ouvrir (brainstorming), structurer (Ishikawa), approfondir (5 Pourquoi - s'arrêter quand la cause sort du champ de l'acteur).
- Choisir, c'est expliciter des critères (impératifs, souhaitables) et arbitrer avec une grille. Le choix devient un engagement daté, pas une opinion.
- Une solution ne se juge pas à ce qu'elle fait, mais à ce qu'elle fait cesser : ce qu'elle rend en capital TEA doit dépasser ce qu'elle coûte.
- La rétroaction a trois sens : vérifier la contribution, éviter la répétition, constituer une mémoire.
📚 Articles liés
- La résolution de problèmes est-elle une des méthodes de la gestion du temps ? (article 1 de la série : à partir de quand se préoccuper d'un problème)
- Vous résolvez déjà des problèmes sans le savoir (article 2 : pourquoi le bon déclic part au mauvais endroit)
- Résoudre des problèmes : des ressentis aux faits (article 3 : poser le problème, le formuler en faits)
- Du diagnostic à la décision : remonter aux causes racines et arbitrer les solutions (le présent article)
- La boîte à outils du béotien (article 5 de la série - à venir)
🔎 Ressources
- Le Guide du Problem Solver : Boîte à outils et fiches méthodes (à venir)
- Gérer son temps : la démarche en un coup d'œil (l'infographie de la méthode)
- Mes trucs pour gérer mon temps : avoir de la mémoire (la mémoire des choses faites - le « truc » évoqué dans Vérifier)
Aucun commentaire:
Enregistrer un commentaire