Le bon modèle mental
Résoudre un problème complexe n'est jamais une ligne droite — c'est une boucle qu'on répète jusqu'à ce que ça marche.
C'est comme conduire de nuit avec des phares qui n'éclairent que 20 mètres devant vous. Vous n'avez pas besoin de voir toute la route pour arriver à destination — juste assez pour avancer un peu, corriger, avancer encore. La résolution de problèmes complexes, c'est exactement ça : on n'a jamais toute l'info au départ, on avance par petites boucles vérifiées.
Ce que ça change concrètement
- Un problème complexe n'a pas une bonne réponse évidente, contrairement à un problème compliqué (juste difficile, mais avec une méthode déjà connue) — la distinction change l'approche à adopter.
- La boucle de base : Identifier → Décomposer → Chercher des solutions → Tester → Mesurer → Corriger, puis recommencer.
- Pourquoi cette compétence résiste à l'automatisation : chaque boucle exige un jugement sur CE cas précis, un compromis sans règle fixe pour trancher — contrairement à une tâche répétitive, chaque problème complexe diffère un peu du précédent.
Quelle est la différence entre un problème compliqué et un problème complexe ?
Voir la réponse
Un problème compliqué est difficile mais résoluble par une méthode déjà connue et applicable directement. Un problème complexe n'a pas de méthode toute faite : il exige d'identifier, tester et ajuster au cas par cas, car chaque situation diffère.
Identifier le vrai problème
Le problème qu'on vous présente au départ est presque toujours un symptôme, pas la cause.
Un patient vient pour un mal de tête. Le vrai problème est peut-être sa vue, son stress ou sa tension — pas la douleur elle-même que traite un antidouleur. Traiter le symptôme fait disparaître la plainte, pas la cause : elle revient.
Techniques qui marchent
- Les « 5 pourquoi » : demander « pourquoi » cinq fois de suite sur le symptôme observé, jusqu'à atteindre une cause sur laquelle on peut agir.
- Reformuler le problème en une phrase, puis demander à quelqu'un d'autre de le reformuler à son tour — si les deux versions divergent, le problème n'est pas encore clair.
- Distinguer le problème ressenti (ce qu'on nous dit) du problème réel (ce qui cause vraiment la situation) — souvent visible dans les faits et les données, plus que dans les plaintes.
Pourquoi la technique des « 5 pourquoi » aide-t-elle à distinguer un symptôme d'une cause réelle ?
Voir la réponse
Parce que chaque « pourquoi » creuse un niveau plus profond que la plainte de surface, jusqu'à atteindre une cause sur laquelle on peut réellement agir — s'arrêter au premier niveau ne traite que le symptôme, qui revient ensuite.
Décomposer en étapes
Un problème qui semble impossible en un bloc devient gérable une fois découpé en morceaux qu'on peut résoudre un par un.
C'est comme manger un éléphant : impossible d'un coup, mais possible bouchée par bouchée. La décomposition transforme « je ne sais pas par où commencer » en « je sais faire cette première petite partie ».
Techniques qui marchent
- Découper par étapes séquentielles (ce qui doit arriver avant, pendant, après) plutôt que de tout attaquer en même temps.
- Isoler la partie déjà maîtrisée de la partie inconnue — avancer d'abord sur le connu réduit le problème restant.
- Se demander : « quelle est la plus petite version de ce problème que je pourrais résoudre aujourd'hui ? » — un problème miniature qui teste déjà l'approche.
Pourquoi la décomposition rend-elle un problème complexe plus gérable, même si elle ne change rien à sa difficulté totale ?
Voir la réponse
Parce qu'elle remplace un bloc informe et intimidant par une suite de petites parties concrètes, chacune abordable individuellement — la difficulté totale reste la même, mais elle devient traitable étape par étape au lieu de paralyser d'un coup.
Chercher plusieurs solutions
La première solution qui vient à l'esprit est rarement la meilleure — elle est juste la plus familière.
Un architecte dessine 3 plans différents avant de choisir. Le premier trait de crayon n'est presque jamais le meilleur bâtiment possible — juste le plus évident compte tenu de ce que l'architecte a déjà vu ailleurs.
Techniques qui marchent
- Forcer au moins 3 options différentes avant de choisir, même si la première semble déjà bonne — la contrainte du nombre force à sortir du premier réflexe.
- Emprunter une solution d'un domaine complètement différent — comment un autre secteur résout un problème structurellement similaire (technique de l'analogie éloignée).
- Utiliser une IA comme partenaire de brainstorming pour générer des options qu'on n'aurait pas envisagées seul, puis évaluer chaque option soi-même.
Pourquoi forcer au moins 3 options différentes avant de choisir une solution, même quand la première semble déjà bonne ?
Voir la réponse
Parce que la première idée est souvent la plus familière, pas la meilleure : la contrainte du nombre oblige à explorer au-delà du premier réflexe et révèle des options qu'on n'aurait pas envisagées spontanément.
Tester rapidement
Un test rapide et imparfait qui répond à une vraie question vaut mieux qu'une analyse parfaite qui prend trois semaines.
C'est comme goûter la sauce avant de servir tout le plat. Un petit test à faible coût révèle si la direction est bonne, bien avant d'avoir investi tout l'effort dans la version complète.
Techniques qui marchent
- Prototype minimal : tester la partie la plus incertaine de la solution en premier, pas la plus facile.
- Se demander : « quel est le test le moins cher qui pourrait me faire changer d'avis ? » avant de lancer un test — ça évite de tester ce qu'on sait déjà.
- Accepter qu'un test rapide donne une réponse approximative, pas définitive — c'est un signal de direction, pas une preuve finale.
Pourquoi un test rapide et imparfait vaut-il souvent mieux qu'une analyse longue et complète avant d'agir ?
Voir la réponse
Parce qu'un test rapide révèle vite si la direction est bonne, à faible coût, alors qu'une analyse longue retarde la découverte des vrais problèmes — mieux vaut ajuster tôt sur un signal approximatif que découvrir un défaut majeur après des semaines d'investissement.
Mesurer le résultat
Sans mesure définie avant le test, on interprète toujours le résultat dans le sens qui nous arrange.
Un arbitre qui déciderait des règles du match après l'avoir vu se terminer rendrait toujours le verdict qui favorise l'équipe qu'il préfère. Définir la mesure avant le test, c'est fixer les règles avant de connaître le score.
Techniques qui marchent
- Définir avant le test : quel chiffre ou quel signal dira que ça a marché, et quel seuil dira que ça n'a pas marché.
- Choisir une mesure directement liée au vrai problème identifié au bloc 01 — pas une mesure facile à obtenir mais qui ne dit rien du problème réel.
- Comparer au point de départ (avant/après), pas seulement regarder le résultat final isolé — un résultat « bon » peut être pire que la situation de départ.
Pourquoi faut-il définir la mesure de succès AVANT de lancer un test, plutôt qu'après avoir vu le résultat ?
Voir la réponse
Parce que définir la mesure après coup permet de choisir, consciemment ou non, l'indicateur qui arrange l'interprétation voulue — comme un arbitre qui fixerait les règles après la fin du match. Fixer la mesure avant garantit une évaluation honnête.
Corriger ce qui ne fonctionne pas
Corriger n'est pas recommencer de zéro — c'est reprendre la boucle précisément là où la mesure a montré l'écart.
Un pilote corrige sa trajectoire de quelques degrés en vol plutôt que de faire demi-tour et redécoller. La correction cible l'écart précis mesuré, pas tout le plan.
Techniques qui marchent
- Revenir à la mesure du bloc 05 pour savoir précisément quelle partie a échoué, pas juste « ça n'a pas marché » en général.
- Distinguer trois causes d'échec possibles : mauvais problème identifié (retour bloc 01), mauvaise solution choisie (retour bloc 03), ou bonne solution mal exécutée (ajuster l'exécution seulement) — chacune demande une correction différente.
- Ne changer qu'une seule variable à la fois lors de la correction, sinon impossible de savoir laquelle a réellement eu un effet la fois suivante.
Face à un échec, quelles sont les trois causes possibles à distinguer avant de corriger quoi que ce soit ?
Voir la réponse
Un mauvais problème identifié au départ (retour à l'identification), une mauvaise solution choisie parmi les options (retour à la recherche de solutions), ou une bonne solution mal exécutée (ajuster seulement l'exécution) — chaque cause appelle une correction différente.
Bloc mêlé
Les six étapes ci-dessus sont ici volontairement mélangées — dans la vraie vie, un problème ne vous dit jamais à quelle étape de la boucle vous en êtes.
Vous testez 2 solutions et ne gardez que le chiffre qui va dans votre sens. Quel biais ?
Le biais de confirmation — la mesure doit être définie avant le test, pas choisie après coup.
On vous dit « les ventes baissent, il faut plus de pub ». Premier réflexe ?
Chercher le vrai problème (5 pourquoi) avant d'accepter la solution proposée d'emblée.
Votre première idée semble déjà bonne. Que faire avant de la choisir ?
Forcer au moins deux autres options avant de comparer objectivement.
Une solution complète est prête après 3 semaines, jamais testée en cours de route. Risque ?
Découvrir tous les problèmes trop tard — il fallait tester une version minimale bien avant.
Un test échoue. Quel réflexe éviter ?
Tout abandonner sans savoir précisément quelle partie — problème, solution ou exécution — a raté.
Un projet semble ingérable d'un bloc. Que faire en premier ?
Identifier la plus petite partie du problème qu'on peut résoudre aujourd'hui.
Atelier approfondi et votre projet
Un seul problème réel, résolu de bout en bout, vaut mieux que six méthodes apprises sans jamais les appliquer — la technique 4 appliquée à ce cours.
Atelier — des réunions d'équipe qui n'aboutissent à rien
- Identifier — cinq « pourquoi » jusqu'à la vraie cause : pas d'ordre du jour clair, aucune décision actée (bloc 01).
- Décomposer — séparer avant la réunion / pendant / après (bloc 02).
- Chercher des solutions — trois options différentes : ordre du jour obligatoire, chronométrage strict, réunion debout (bloc 03).
- Tester — une seule option, sur deux réunions, sans généraliser tout de suite (bloc 04).
- Mesurer — défini à l'avance : durée moyenne et nombre de décisions actées par réunion (bloc 05).
- Corriger — si ça n'a pas marché, identifier si c'était le mauvais diagnostic, la mauvaise solution, ou juste mal exécuté (bloc 06).
Chaque bloc de ce cours est un maillon de cette boucle, jamais une étape isolée — c'est cette boucle complète qui distingue résoudre un problème de simplement réagir dessus.
Votre projet — apprentissage par le projet
Cochez au fur et à mesure. Rien n'est acquis tant que vous n'avez pas résolu un vrai problème récurrent, pas un exemple du cours.