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 s'enchaînent, 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 forme différente. Le sentiment d'avoir agi masque souvent l'absence de progrès réel.
Une cause récurrente de ces échecs se situe en amont des solutions, dans la façon même dont le problème est formulé. Un énoncé de problème vague ou biaisé conduit mécaniquement à des réponses inadaptées. 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 logique DMAIC, la première étape — Définir — est celle de la définition du problème. Sur le papier, elle lance l'ensemble de la démarche. Dans la pratique, elle est régulièrement traitée à la hâte.
L'attention des équipes se tourne spontanément vers les phases Analyser et Améliorer, perçues comme plus actives. La phase Définir apparaît alors comme un prérequis 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 énoncer un problème
Une confusion fréquente s'installe dès les premières discussions. 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 sur sa nature, son ampleur ou 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 énoncer un problème
L'autre dérive consiste à intégrer une cause supposée dans le libellé 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 de personnel » 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 de l'avoir commencée. 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 il entraîne pour l'organisation ou le client
Rassemblés, ces éléments transforment une plainte vague en un énoncé exploitable. 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, 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 significative.
Énoncer un problème, c'est d'abord nommer cet écart. Tant que l'attendu n'est pas explicité, l'analyse tourne dans le vide.
Le rôle du management dans la qualité de l'énoncé du problème
La manière dont une difficulté est formulée dépend largement de la posture managériale qui l'entoure.
Lorsque le management attend des réponses immédiates et valorise la vitesse d'action, les équipes apprennent à raccourcir 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 formel, sans réelle exigence d'analyse.
À l'inverse, lorsque le management prend le temps d'interroger le libellé initial, 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, non un détail. Elle y investit le temps nécessaire pour bien le cadrer.
Cette posture exige 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'évite des itérations inutiles.
Les signaux d'un énoncé de problème défaillant
Plusieurs indices trahissent une définition fragile. Le libellé contient un verbe d'action déguisé en problème, tel que « manque de communication » ou « besoin de formation ». Il énonce un jugement plutôt qu'un fait. Il utilise des termes vagues sans grandeur associée, comme « trop souvent » ou « beaucoup ».
Il peut aussi être trop large, englobant plusieurs phénomènes hétérogènes, ou au contraire trop étroit, isolant un cas particulier sans portée générale. Dans tous ces cas, la suite de la démarche en souffrira.
Reformuler n'est pas une perte de temps. C'est une étape de fond.
D'un libellé hâtif à un énoncé de problème durable
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 nécessite 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 de l'analyse et de la résolution. Et cela exige 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 récidives diminuent. L'énoncé du problème devient un véritable levier de performance durable, et non une simple formalité préalable.
Ce qu'il faut retenir
- Un mauvais énoncé de problème conduit mécaniquement à une mauvaise solution
- La phase Définir 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
