DMAIC structure la résolution de problèmes en cinq étapes : Définir, Mesurer, Analyser, Innover, Contrôler. Guide complet des cinq phases, des outils associés et des pièges à éviter pour mener un projet d'amélioration en usine.
DMAIC est une méthode structurée de résolution de problèmes issue du Six Sigma, organisée en cinq étapes : Définir, Mesurer, Analyser, Innover (Improve) et Contrôler. Elle sert à améliorer un processus existant en s'appuyant sur des données mesurées plutôt que sur des intuitions. Un projet DMAIC dure généralement de 3 à 6 mois et s'applique à tout problème récurrent dont la cause racine n'est pas évidente.
En atelier, la tentation est toujours la même : un défaut apparaît, quelqu'un propose une solution, on l'applique, et six semaines plus tard le défaut revient. DMAIC existe précisément pour casser ce cycle. La méthode impose de mesurer avant d'agir, et de verrouiller avant de passer à autre chose.
La différence tient en un mot : la preuve. Une réunion classique s'arrête à la première cause plausible. DMAIC exige que la cause soit démontrée par les données avant qu'on investisse dans une solution.
Cette discipline a des résultats documentés. Motorola, qui a créé le Six Sigma en 1986, a attribué plus de 16 milliards de dollars d'économies à la démarche sur la période 1986-2005 (Motorola, cité par iSixSigma). Chez General Electric, deux ans après le déploiement lancé en 1995, les bénéfices attribués au Six Sigma atteignaient environ 700 millions de dollars, puis dépassaient 2,5 milliards trois ans plus tard (6Sigma.us).
Ces chiffres concernent des groupes de plusieurs dizaines de milliers de salariés. Dans une PMI, l'ordre de grandeur est évidemment différent — mais le mécanisme est identique : on cesse de payer plusieurs fois pour le même problème.
DMAIC se distingue aussi du PDCA, avec lequel on le confond souvent. Le PDCA est un cycle d'amélioration léger, adapté aux ajustements rapides et aux chantiers courts. DMAIC est un cadre de projet, plus lourd, réservé aux problèmes complexes, chiffrables et à cause racine inconnue. Choisir DMAIC pour régler un rangement d'établi est un gaspillage ; choisir un PDCA pour traiter une dérive qualité multifactorielle est une perte de temps.
L'étape de cadrage. On formule le problème en termes factuels, on délimite le périmètre du processus concerné, on identifie le client (interne ou externe) et ce qui compte pour lui, et on fixe l'objectif chiffré.
Le livrable central est la charte de projet : problème, périmètre, objectif, équipe, jalons, gain attendu. Outils courants : SIPOC (Fournisseur-Entrées-Processus-Sorties-Client), voix du client, diagramme de Pareto pour prioriser.
Le piège classique : définir le problème en y glissant déjà la solution. « Nous devons changer la machine 4 » n'est pas un problème, c'est une hypothèse. « Le taux de rebut de la ligne 2 est de 4,2 % contre 1,5 % d'objectif » est un problème.
On quantifie l'ampleur réelle du problème et on établit la performance de départ. Sans cette ligne de base, aucun gain ne sera démontrable en fin de projet.
Cette étape suppose de vérifier que le système de mesure est lui-même fiable — c'est l'objet des analyses R&R (répétabilité et reproductibilité). Une mesure de contrôle qui varie selon l'opérateur qui la réalise invalide tout ce qui suivra.
Outils : plan de collecte de données, cartes de contrôle, calcul de capabilité (Cp, Cpk), TRS si le sujet touche à la performance machine.
On identifie les causes racines à partir des données collectées. L'objectif est de répondre à trois questions : où le problème survient-il, quand, et pourquoi.
Outils : diagramme d'Ishikawa pour structurer les causes possibles, méthode des 5 pourquoi pour creuser une branche, tests d'hypothèse et régressions pour confirmer statistiquement, Value Stream Mapping si le problème est un problème de flux.
C'est l'étape la plus souvent bâclée. Une cause racine validée doit vérifier un critère simple : si on la supprime, le problème disparaît, et si on la réintroduit, il revient.
On conçoit, teste et déploie les solutions qui traitent les causes validées. Les solutions sont d'abord testées à petite échelle — sur une ligne, une équipe, une référence — avant généralisation.
Outils : plans d'expériences (DOE), SMED pour les temps de changement, poka-yoke pour rendre l'erreur physiquement impossible, essais pilotes.
Une solution qui repose uniquement sur la vigilance des opérateurs n'est pas une solution robuste. La hiérarchie à respecter : éliminer la cause, puis rendre l'erreur impossible, puis la rendre détectable, et seulement en dernier recours ajouter un contrôle humain.
On verrouille les gains pour qu'ils tiennent dans le temps. C'est l'étape qui distingue un projet réussi d'une amélioration qui s'érode en six mois.
Concrètement : mise à jour des modes opératoires et des standards, formation des équipes concernées à la nouvelle façon de faire, mise en place d'un plan de surveillance avec cartes de contrôle et seuils d'alerte, définition du responsable du suivi, et transfert formel au propriétaire du processus.
C'est le maillon le plus fragile de la chaîne. Le nouveau standard existe souvent sous forme de compte rendu de projet que personne ne lit. Des outils comme Komin permettent de transformer ce standard en mode opératoire consultable au poste et de tracer qui a été formé à la nouvelle version — condition pratique pour que le gain survive au départ du chef de projet.
Trois conditions déterminent le résultat, et aucune n'est technique.
Choisir le bon problème. Récurrent, coûteux, mesurable, et dont la cause n'est pas connue. Un problème dont tout le monde connaît déjà la solution ne justifie pas un DMAIC.
Sécuriser la disponibilité des données. Si l'étape Mesurer prend trois mois parce que rien n'est enregistré, le projet s'enlise. Vérifiez en amont ce qui est déjà tracé.
Nommer un pilote et un sponsor. Le pilote anime, le sponsor arbitre et débloque les ressources. Sans sponsor au comité de direction, un projet DMAIC meurt au premier conflit de priorité avec la production.
Comptez 3 à 6 mois pour un premier projet, avec des revues de jalon à la fin de chaque étape. Ne passez pas à l'étape suivante tant que le livrable de l'étape en cours n'est pas validé — c'est le principal facteur d'échec observé.
Que signifie exactement l'acronyme DMAIC ?
DMAIC signifie Define, Measure, Analyze, Improve, Control — traduit en français par Définir, Mesurer, Analyser, Innover (ou Améliorer) et Contrôler. Ce sont les cinq phases séquentielles d'un projet d'amélioration Six Sigma.
Quelle est la différence entre DMAIC et DMADV ?
DMAIC sert à améliorer un processus qui existe déjà. DMADV (Define, Measure, Analyze, Design, Verify) sert à concevoir un processus ou un produit nouveau, ou à refondre entièrement un processus existant devenu inadaptable. En industrie, DMAIC couvre la grande majorité des besoins.
Faut-il être certifié Green Belt ou Black Belt pour piloter un DMAIC ?
Non, ce n'est pas une obligation légale ni normative. Une certification Green Belt apporte la maîtrise des outils statistiques utiles en phases Mesurer et Analyser, ce qui accélère le projet. Sur un premier projet à faible complexité statistique, un responsable méthodes formé aux outils de base peut piloter efficacement.
Combien de temps dure un projet DMAIC ?
De 3 à 6 mois en général, la phase Mesurer étant souvent la plus longue quand les données ne sont pas déjà collectées. Un projet qui dépasse 9 mois est généralement mal cadré : le périmètre est trop large et doit être découpé.
DMAIC est-il compatible avec une démarche Lean ou ISO 9001 ?
Oui. DMAIC est le cadre de résolution de problèmes du Six Sigma et s'intègre naturellement dans une démarche Lean Six Sigma. Pour l'ISO 9001, il fournit une méthode documentée de traitement des non-conformités et d'actions correctives, directement exploitable en audit.
"Avec Komin, nous avons documenté nos modes opératoires 10x rapidement qu'avec le papier"
- J. Cerruti (Responsable Méthodes & Industrialisation)
