PDCA et Ishikawa 6M — la méthode derrière la documentation

Toute la documentation technique Odoo 19 publiée ici repose sur deux outils méthodologiques inséparables et complémentaires, issus du même mouvement qualité japonais d'après-guerre (Deming + Ishikawa). Le premier gouverne quand une information a le droit d'être inscrite ; le second structure comment on analyse un problème ou on prépare un chantier.

Outil	Rôle
PDCA (Plan-Do-Check-Act)	Cycle temporel de gouvernance — règle d'inscription des faits validés
Ishikawa (5M/6M)	Analyse multi-causale (correctif) et structuration de chantier (prospectif) — utilisé dans les étapes P et C du PDCA

Le cycle PDCA — pourquoi cette documentation est fiable

La règle est absolue : aucune entrée n'est inscrite dans le socle technique sans avoir transité par les quatre étapes du cycle PDCA. Aucune exception. C'est ce qui distingue cette documentation d'une compilation de sources : chaque affirmation a été formulée comme hypothèse, appliquée sur du code réel, testée avec des critères de succès écrits à l'avance, puis — et seulement alors — inscrite.

Étape	Critère
P (Plan)	Hypothèse formulée par écrit AVANT toute action. Exemple : « D'après la doc officielle X.rst ligne Y, le champ Z devrait fonctionner ainsi. Hypothèse à vérifier : applicable en Odoo 19 ? »
D (Do)	Application de l'hypothèse dans le code, identification de la divergence ou confirmation du bon comportement.
C (Check)	Test rigoureux avec critères de succès écrits AVANT le test : le module compile sans erreur, démarre sans warning bloquant, la fonctionnalité produit le résultat attendu de bout en bout. Pas de validation partielle.
A (Act)	SEULEMENT après un Check complet et concluant : inscription dans le socle. Si une information préexistante est contredite, elle est corrigée à sa source — remplacée par l'information exacte, pas annotée « obsolète ».

La règle anti-pollution

Le socle reste épuré parce que cinq comportements y sont formellement interdits :

❌ Inscrire ce que dit la documentation officielle sans l'avoir testé en pratique sur du code réel
❌ Inscrire une correction non testée de bout en bout
❌ Inscrire une expérience qui n'a pas abouti à un résultat constructif et validé
❌ Inscrire « il semblerait que », « probablement », « à confirmer », « selon la doc »
❌ Inscrire un fait propre à un projet particulier (champ d'un modèle précis, xmlid, convention métier)

Chaque entrée est un fait validé et universel. Si ce n'est pas validé, ce n'est pas dedans. Si ce n'est pas universel, ce n'est pas ici.

Mise à jour corrective automatique

Dès qu'un bug est corrigé sur du code Odoo 19 et que la correction a passé le cycle PDCA complet (validation end-to-end), le socle est mis à jour : l'information erronée est remplacée, l'information nouvelle est ajoutée dans la section thématique appropriée, et aucune trace de l'erreur n'est conservée dans le document de référence. L'historique des corrections vit ailleurs — dans les commits Git et le journal de bugs du projet, qui contient le détail PDCA complet de chaque cas.

Le diagramme d'Ishikawa (5M/6M)

Origine et nature

Conçu par Kaoru Ishikawa, ingénieur qualité japonais — présentation initiale en 1943, démocratisation dans les années 1960. Il est aussi nommé diagramme cause-effet, arête de poisson ou fishbone diagram. La « tête du poisson » porte l'effet à expliquer (mode correctif) ou l'objectif à atteindre (mode prospectif) ; les « grandes arêtes » portent les catégories de causes (les 5M ou 6M) ; les « petites arêtes » les détaillent.

Articulation avec le PDCA — règle d'imbrication

PDCA et Ishikawa ne sont pas concurrents mais complémentaires et imbriqués : l'Ishikawa intervient à deux moments précis du cycle.

Étape PDCA	Outil Ishikawa déclenché	Question posée
P (Plan)	Ishikawa prospectif	« Pour atteindre l'objectif visé, quelles conditions réunir sur chacune des 6M ? »
D (Do)	—	(exécution selon le plan)
C (Check)	Ishikawa correctif (si le test échoue)	« Pourquoi le résultat attendu n'a pas été obtenu — quelles causes sur chacune des 6M ? »
A (Act)	—	(standardisation des bonnes pratiques validées)

Les deux modes d'usage

Mode	Question	Les branches représentent	Cas d'usage Odoo / VPS
Correctif (rétrospectif)	Pourquoi ce problème est-il apparu ?	Causes possibles à investiguer	Échec d'installation de module, bug d'exécution, comportement de vue inattendu, erreur SQL silencieuse
Prospectif (préventif)	Pour atteindre cet objectif, que faut-il réunir ?	Leviers de réussite, conditions, risques	Installation en production, conception d'un nouveau module, plan de déploiement VPS, chantier structurant

Les 6M (5M historique + Mesure)

Les catégories classiques du diagramme, adaptées au contexte logiciel Odoo 19 :

Branche 6M	Définition générique	Adaptation software Odoo 19
Matière	Données / composants d'entrée	Code Python, fichiers XML de données, `__manifest__.py`, ACL CSV, fichiers de migration
Méthode	Procédures, modes opératoires	`-i` vs `-u`, ordre `depends`, séquence de chargement `data`, redémarrage Odoo, commandes CLI
Main-d'œuvre	Compétences, comportement	Opérateur (humain ou agent IA) — commande lancée, base cible, version utilisée, oublis
Milieu	Conditions, contexte	Version Odoo 19.x, Python, dépendances Python, Postgres, locale, timezone, variables d'environnement, `odoo.conf`
Matériel	Équipements, infrastructure	RAM, disque, ports, `wkhtmltopdf`, droits fichier sur `custom_addons`, virtiofs, réseau, Git
Mesure	Instruments, indicateurs, logs	Niveau de log (`--log-level=debug`), stderr ignoré, erreur masquée par try/except, journald vs fichier, troncature

Règles de déclenchement — l'anti-cérémonie

L'Ishikawa n'est pas systématique : le déclencher sur tout et n'importe quoi le viderait de sa valeur. Deux règles absolues encadrent son usage :

Mode correctif : déclencher après 2 tentatives de correction échouées avec des causes apparentes différentes. Avant ce seuil, la lecture des logs et un fix ciblé suffisent.
Mode prospectif : déclencher avant tout chantier critique — installation en production, conception d'un nouveau module, chantier méthodologique structurant, déploiement VPS majeur (migration, mise à jour Odoo, changement de Postgres).

Hors de ces deux cas, le PDCA seul suffit.

Par cohérence avec les règles PDCA, cinq dérives sont interdites :

❌ Lister des branches sans en tester aucune (cérémonie sans contenu)
❌ Conclure « cause = X » sans preuve testable
❌ Mélanger les branches (chaque cause appartient à une seule catégorie 6M)
❌ Inventer un Ishikawa rétroactif pour justifier un fix qui a marché par hasard
❌ Déclencher sur un cas trivial, avant 2 tentatives échouées

Chaque cause listée doit être soit testée, soit explicitement écartée avec une justification factuelle.

Exemple — Mode correctif : un module refuse de s'installer

Tentative 1 : ParseError XML (fix de l'attribut ). Tentative 2 : ImportError sur une dépendance Python. Les causes apparentes sont différentes — le seuil est atteint, l'Ishikawa correctif est déclenché.

Branche	Causes possibles à tester
Matière	Manifest valide ? XML data conformes v19 ? ACL CSV avec `group_id` ? Python sans syntax error ?
Méthode	Mode d'installation correct (`-i` vs `-u`) ? Base cible correcte ? Restart entre install et test ?
Main-d'œuvre	Commande lancée par le bon user (`odoo` vs `root`) ? Bonne base `-d` ? Mot de passe admin connu ?
Milieu	Version Odoo 19.x.y ? Python 3.10+ ? Dépendance Python du manifest installée dans le venv Odoo ? ← cause détectée
Matériel	RAM > 2 Go libre ? Disque > 1 Go ? Port 8069 libre ? Droits `odoo:odoo` ? `wkhtmltopdf` présent ?
Mesure	Log en `--log-level=debug` ? stderr capturé ? Pas de try/except masquant ? Logs non tronqués ?

Diagnostic convergent : branche Milieu — la dépendance Python déclarée dans le manifest n'était pas installée dans le venv Odoo (pip install --break-system-packages). La cause racine est identifiée par investigation structurée, pas par intuition.

Exemple — Mode prospectif : préparer une installation en production

Branche	Conditions à vérifier AVANT l'installation
Matière	Manifest lu ligne par ligne. XML/CSV/Python validés. ACL avec `group_id`. Pas de `numbercall` (F001), pas de (F002), routes en `type='jsonrpc'` (B003).
Méthode	Commande `-i` documentée. Rollback prêt (backup de la base avant install). Validation PDCA prête.
Main-d'œuvre	Bon opérateur identifié. Base cible vérifiée (prod, pas dev). Credentials admin connus.
Milieu	Odoo 19.x compatible. Python 3.10+. Toutes les dépendances Python installées (`pip list`). `dbfilter` autorise la base.
Matériel	Backup base + filestore (moins d'une heure avant). RAM > 4 Go libre. Disque > 5 Go. Pas d'autre installation en cours.
Mesure	Log `--log-level=debug`. Critère de succès écrit : « module visible dans Apps, sans warning bloquant, fonctionnalité X end-to-end ».

L'installation n'est lancée qu'après que chaque case est cochée.

Sources de référence sur la méthode Ishikawa

Asana — Diagramme d'Ishikawa : méthode, 5M et exemples (asana.com/fr/resources/ishikawa-diagram)
ASQ — Fishbone Diagram (asq.org/quality-resources/fishbone)
Chef-de-projet.fr — Le diagramme d'Ishikawa et les 5M
Performance-Industrielle.fr — Diagrammes d'Ishikawa
Wikipedia — Ishikawa diagram

Le résultat concret de cette discipline se lit sur la page Socle technique Odoo 19 : chaque règle qui y figure est le produit d'un cycle PDCA complet, parfois éclairé par un Ishikawa.