Dans de nombreuses organisations, dès qu'une difficulté apparaît, la réaction immédiate est de chercher une solution. L'énoncé du problème est traité comme une étape secondaire, presque administrative. Les réunions se succèdent, les hypothèses circulent, les plans d'action se construisent rapidement.
Pourtant, cette précipitation produit fréquemment des résultats décevants. Les actions mises en œuvre n'ont qu'un effet limité, les difficultés réapparaissent, parfois sous une autre forme. Le sentiment d'avoir agi masque souvent l'absence de réel progrès.
Une cause récurrente de ces échecs se situe en amont des solutions, dans la manière même dont le problème est posé. Un énoncé de problème vague ou biaisé conduit mécaniquement à des réponses inadéquates. Avant d'agir, encore faut-il avoir nommé exactement ce qui doit être résolu.
Pourquoi cette phase est si souvent bâclée
Dans la DMAIC logique, la première étape — Define — est celle de la définition du problème. Sur le papier, elle ouvre toute la démarche. En pratique, elle est régulièrement traitée à la hâte.
L'attention des équipes se tourne spontanément vers les phases Analyze et Improve, perçues comme plus actives. La phase Define apparaît alors comme un préalable administratif, à franchir rapidement pour passer aux choses sérieuses.
Cette précipitation a un coût. Un projet d'amélioration mal défini consomme du temps, mobilise des ressources et conduit à des conclusions fragiles. La rigueur initiale conditionne tout le reste du raisonnement.
Décrire un symptôme n'est pas poser un problème
Une confusion fréquente s'installe dès les premiers échanges. Un symptôme observable est pris pour le problème lui-même.
Un délai qui s'allonge, un taux de rebut qui monte, une réclamation client qui se répète : ce sont des signaux, pas des problèmes. Ils signalent qu'un dysfonctionnement existe quelque part dans le processus. Ils ne disent rien de sa nature, de son ampleur ou de sa localisation précise.
Confondre le symptôme et le problème conduit à traiter ce qui est visible sans toucher à ce qui produit le phénomène. Le résultat est connu : l'effet revient dès que la vigilance baisse.
Nommer une cause n'est pas non plus un énoncé de problème
L'autre dérive consiste à imbriquer une cause supposée dans la formulation même du problème. L'énoncé du problème devient alors une explication déguisée.
"Les délais de livraison s'allongent parce que les équipes manquent d'effectifs" n'est pas un énoncé de problème. C'est une hypothèse de cause posée comme une évidence. Le diagnostic est déjà fait, l'analyse est court-circuitée, et les autres causes possibles deviennent invisibles.
Cette confusion ferme l'analyse avant même qu'elle ne commence. Les actions qui suivront cibleront la cause supposée, qui n'est peut-être pas la bonne.
Les composantes d'un énoncé de problème utile
Un bon énoncé de problème reste neutre, descriptif et mesurable. Il décrit un écart observé sans préjuger de son origine ni de sa solution. Il se compose de plusieurs éléments précis :
- ce qui se passe concrètement, en termes observables
- où le phénomène se produit, dans quel processus ou sur quelle ligne
- quand il est apparu et à quelle fréquence il se manifeste
- quelle est son ampleur, exprimée par un indicateur
- quel écart cet état reflète par rapport à la situation attendue
- quelles conséquences mesurables cela entraîne pour l'organisation ou le client
Réunis, ces éléments transforment une plainte vague en un énoncé actionnable. L'équipe sait alors ce qu'elle cherche, où le chercher et comment vérifier qu'elle l'a trouvé.
L'écart par rapport à l'attendu, le pivot de tout énoncé de problème
La notion d'écart est centrale. Sans référence à un niveau attendu, il n'y a pas de problème, seulement un constat.
Le niveau attendu peut être une norme, un standard interne, un engagement client, un objectif de performance ou un niveau historique. Quelle que soit sa nature, il rend le problème intelligible. Il transforme un chiffre brut en information porteuse de sens.
Poser un problème, c'est d'abord nommer cet écart. Tant que l'attendu n'est pas explicité, l'analyse tourne à vide.
Le rôle du management dans la qualité de l'énoncé du problème
La manière dont une difficulté est cadrée dépend largement de la posture managériale qui l'entoure.
Quand le management attend des réponses immédiates et valorise la vitesse d'action, les équipes apprennent à écourter la phase de définition. Le problème est posé en quelques mots, souvent sous forme de cause présumée, et la discussion bascule immédiatement dans le plan d'action. L'énoncé du problème devient un passage obligé formel, sans réelle exigence d'analyse.
À l'inverse, quand le management prend le temps de questionner la formulation initiale, demande des données, fait reformuler, la qualité de la définition s'élève. L'équipe comprend qu'un problème mal cadré est un risque, pas un détail. Elle investit le temps nécessaire pour bien le cadrer.
Cette posture demande une forme de patience peu naturelle dans les contextes sous pression. Mais elle conditionne directement la pertinence des solutions qui suivront. Un management qui exige un énoncé de problème rigoureux s'épargne des allers-retours inutiles.
Les signaux d'un énoncé de problème défectueux
Plusieurs indices trahissent une définition fragile. La formulation contient un verbe d'action déguisé en problème, tel que "manque de communication" ou "besoin de formation". Elle énonce un jugement plutôt qu'un fait. Elle utilise des termes vagues sans grandeur associée, comme "trop souvent" ou "beaucoup".
Elle peut aussi être trop large, englobant plusieurs phénomènes hétérogènes, ou au contraire trop étroite, isolant un cas particulier sans portée générale. Dans tous ces cas, la suite de la démarche en pâtira.
Reformuler n'est pas perdre de temps. C'est une étape de fond.
D'une formulation précipitée à un énoncé de problème pérenne
Construire un énoncé de problème solide n'est pas un exercice ponctuel. C'est une discipline qui s'installe progressivement dans les pratiques d'une organisation.
Cela demande des cadres simples, partagés par les équipes, qui rappellent les composantes attendues d'un énoncé. Cela demande aussi du temps dédié à la définition, distinct du temps d'analyse et de résolution. Et cela demande un management qui valorise cette rigueur autant qu'il valorise la vitesse d'exécution.
Lorsque ces conditions sont réunies, la qualité des projets d'amélioration progresse visiblement. Les analyses gagnent en pertinence, les solutions tiennent dans le temps, les rechutes diminuent. L'énoncé du problème devient un véritable levier de performance durable, et non une simple formalité préliminaire.
À retenir
- Un mauvais énoncé de problème conduit mécaniquement à une mauvaise solution
- La phase Define du DMAIC est souvent bâclée à tort
- Un symptôme n'est pas un problème
- Une cause supposée n'est pas un problème
- L'énoncé du problème décrit un écart par rapport à un niveau attendu
- Un bon énoncé est neutre, descriptif et mesurable
- Le management détermine le niveau de rigueur requis
- La rigueur initiale fait gagner du temps sur l'ensemble du projet
