La résolution de problèmes est l’une des compétences les plus universelles qui soient, et l’une des plus rarement enseignées, structurées ou standardisées. Toutes professions confondues, chacun improvise sa propre méthode, souvent sans en avoir conscience, et le résultat se mesure à l’usure : les mêmes problèmes reviennent, encore et encore, parce qu’on s’est contenté de les calmer au lieu de les éliminer.
Pourtant, cette culture repose sur un procédé d’une simplicité désarmante : le PDCA (Plan-Do-Check-Act), hérité de l’approche Lean. C’est un outil que j’ai eu la chance d’approfondir et de mettre en pratique aux côtés de Philippe Fenot durant l’excellente formation Learning to Scale, et que j’applique aujourd’hui au quotidien, aussi bien individuellement que collectivement. Au-delà même du software engineering, c’est un cadre de pensée qui s’applique à n’importe quel problème : organisationnel, technique, ou personnel.
Le PDCA en quatre étapes
Le cycle tient en quatre mouvements, qui s’enchaînent et se rejouent en boucle tant que le problème n’est pas réellement résolu.
-
Identifier un problème, qu’il soit organisationnel ou technique. C’est un problème qui peut être signalé par un client ou un collaborateur, ou bien simplement vécu ou observé par une personne sur le terrain. La condition est qu’il soit réel et constaté, pas supposé.
-
Chercher la ou les causes racines. C’est consacrer une réflexion approfondie et franche, dans le but de formuler des hypothèses sur l’origine véritable du problème, et non sur ses manifestations visibles.
-
Apporter une contre-mesure dont l’objectif est d’éradiquer le problème, le plus efficacement possible.
-
Constater et vérifier les résultats obtenus par rapport à ceux attendus. Si ça fonctionne, on généralise et on diffuse la connaissance. Sinon, on recommence le procédé.
La mécanique paraît évidente. Et c’est précisément là que se niche le piège : l’étape qui sépare une résolution durable d’un bricolage perpétuel est rarement celle qu’on croit.
L’étape cruciale : symptôme ou cause racine ?
C’est l’étape 2 qui fait toute la différence, et c’est aussi celle qu’on escamote le plus souvent. Trop fréquemment, la réflexion s’arrête à la découverte d’un symptôme. On traite ce symptôme, on observe un soulagement immédiat, on se déclare satisfait, et le problème racine, lui, continue naturellement de sévir, prêt à ressurgir sous une forme ou une autre.
Confondre un symptôme avec sa cause, c’est s’engager dans une réparation sans fin plutôt que dans une éradication.
Un exemple de mauvaise approche
Prenons un cas volontairement trivial pour rendre le mécanisme évident :
- Problème : j’ai du mal à respirer correctement, ce qui m’empêche de dormir tranquillement.
- Cause racine identifiée : j’ai le nez bouché. (Piège ! C’est un symptôme, pas une cause.)
- Contre-mesure : se moucher.
- Résultat attendu : pouvoir dormir.
- Résultat obtenu : dix paquets de mouchoirs plus tard, une narine fonctionne un peu mieux, mais globalement le nez reste bouché.
L’erreur saute aux yeux dans cet exemple, mais elle est exactement la même que celle qu’on commet tous les jours sur des problèmes autrement plus complexes. Le nez bouché n’est pas la cause : c’est le signal d’autre chose : une allergie, un virus, un environnement trop sec, une réaction à un aliment. Tant qu’on traite l’écoulement, on ne fait que gérer la conséquence d’un mécanisme qui, lui, reste intact.
Réparer ou éradiquer
Une citation de Philippe Fenot résume tout cela mieux que je ne saurais le faire :
Une contre-mesure appliquée sur un symptôme équivaut à une réparation. Une contre-mesure appliquée sur la cause racine permet l’éradication du problème.
Toute la valeur du PDCA tient dans cette distinction. Réparer, c’est remettre temporairement le système en marche en sachant, consciemment ou non, que la panne reviendra. Éradiquer, c’est remonter le fil jusqu’à l’origine pour que le problème, une fois traité, cesse définitivement de se manifester. La première approche consomme de l’énergie en continu ; la seconde en libère pour de bon.
Dans l’exemple précédent, la véritable contre-mesure ne consiste pas à acheter davantage de mouchoirs, mais à identifier pourquoi le nez se bouche, puis à agir sur cette cause-là. Le saut paraît anodin sur un rhume ; sur un incident de production récurrent, une équipe qui s’épuise ou un client qui s’en va, il fait toute la différence entre une organisation qui apprend et une organisation qui colmate.
Pourquoi si peu d’organisations le font
Si l’outil est si simple et si puissant, pourquoi si peu de personnes, et même d’entreprises, incorporent et standardisent ces procédés visant à identifier en continu les problèmes, à les résoudre et à en tirer un apprentissage collectif ?
Il y a sans doute plusieurs raisons. La pression du court terme pousse à éteindre l’incendie plutôt qu’à comprendre pourquoi le feu a pris. Traiter un symptôme procure une gratification immédiate, alors que remonter à la cause racine demande du temps, de l’honnêteté et parfois le courage d’admettre que le problème vient de soi ou de son propre fonctionnement. Et surtout, sans cadre partagé, chacun résout les problèmes à sa façon : rien ne se capitalise, rien ne se transmet, et l’organisation réapprend sans cesse les mêmes leçons.
Le PDCA répond précisément à cela : il transforme la résolution de problèmes en discipline standardisée et collective, où chaque problème résolu devient un apprentissage diffusable au reste du groupe.
Conclusion
Le prochain problème que vous rencontrez est une invitation. Plutôt que de réagir à chaud, essayez d’y appliquer un PDCA : posez le problème, cherchez honnêtement sa cause racine, pas son symptôme le plus visible, appliquez une contre-mesure ciblée, puis vérifiez ce que vous obtenez réellement par rapport à ce que vous attendiez.
C’est un outil extrêmement puissant, d’autant plus quand il devient un réflexe partagé. La vraie culture de la résolution de problèmes ne commence pas le jour où l’on sait résoudre un problème difficile, mais le jour où l’on cesse de confondre un nez qu’on se mouche avec un nez qu’on débouche.