Deep Systemic Design : ne dessine pas un flow avant d'avoir trouvé la cause
L'IA a transformé la recherche en un sprint de cinq minutes. Andrej Karpathy l'a montré avec le code : itère vite, garde ce qui marche, implémente et passe à la suite. Cette cadence s'exporte naturellement au design. Mais elle dissimule un piège : on peut désormais simplifier plus vite que jamais le mauvais problème.
La promesse des cycles courts
Le modèle autoResearch est séduisant dans sa logique. En cinq minutes de recherche dense et guidée, un designer peut acquérir une compréhension contextuelle suffisante d'un domaine métier inconnu. Il garde ce qui est utile, jette le reste, passe à l'hypothèse suivante. La machine tourne.
Ce modèle a une vraie valeur. Il démocratise l'accès au savoir métier, réduit la dépendance au monopole de l'expert, accélère l'onboarding conceptuel. Il permet de comprendre suffisamment vite pour poser de bonnes questions.
Mais la vitesse crée une tentation : celle de sauter directement à la cartographie des flux avant même d'avoir posé la bonne question.
Le biais dominant : On raffine les cartes, les diagrammes, les "user flows", mais on cartographie parfois le mauvais problème, ou seulement ses symptômes.
Deux pensées systémiques, et la confusion entre elles
La pensée systémique classique s'intéresse aux flux : qui interagit avec quoi, quels processus se succèdent, quelles boucles de rétroaction s'activent. Elle produit des Service Blueprints, des cartographies d'écosystème. C'est un outil puissant, qui reste pourtant en surface. On décrit comment ça circule.
La pensée deep systémique pose une question différente : pourquoi le système produit-il ce comportement de façon quasi inévitable ? Elle remonte jusqu'aux structures sous-jacentes : les contraintes institutionnelles, les croyances implicites, les asymétries de pouvoir.
« La pensée systémique classique demande : comment ça circule ? La pensée deep systémique demande : qu'est-ce qui, à la racine, rend ce comportement inévitable ? »
Les quatre niveaux d'un problème de design
Niveau 1 — Surface : L'événement observable. Ce qu'on voit : un comportement, une friction, un bug récurrent. Exemple : Les utilisateurs abandonnent le formulaire de remboursement à l'étape 3.
Niveau 2 — Pattern : Les récurrences et tendances. Ce qui se répète dans le temps. Exemple : Ce pattern existe depuis 3 ans, sur tous les formulaires réglementaires.
Niveau 3 — Structure : Les mécanismes qui produisent le pattern. Les processus, règles, incentives. Exemple : Le formulaire est conçu par le service compliance pour minimiser le risque juridique, non pour être complété.
Niveau 4 — Cause profonde : Les croyances et conditions de base. Les mental models, les asymétries de pouvoir. Exemple : La croyance implicite : « un utilisateur qui abandonne a probablement une demande illégitime. » L'abandon est une feature déguisée en bug.
La différence entre un designer qui s'arrête au niveau 2 et un designer qui descend au niveau 4 n'est pas une différence de méthode, c'est une différence de ce qu'il est prêt à remettre en question.
Un modèle intégré : la profondeur minimale viable
La réconciliation n'est pas un compromis mou. C'est une stratégie de séquençage : consacrer 10 à 15% du temps en amont à descendre assez profond pour formuler une hypothèse de cause racine claire, puis remonter immédiatement pour itérer vite dessus.
Pourquoi les cycles courts de l'IA aggravent ce biais
En design, les critères de succès sont rarement tranchés. On peut avoir un excellent résultat local sur un mauvais problème. Un formulaire mieux designé qui réduit l'abandon de 20%, mais qui reste un formulaire conçu pour décourager.
Ce n'est pas un argument contre la vitesse. C'est un argument pour séquencer correctement : les cycles courts sont puissants une fois qu'on a identifié la bonne cause.
Comment opérationnaliser la pensée deep systémique
Étape 01 — Partir de la réaction. Identifier un comportement observable, récurrent, résistant aux corrections habituelles.
Étape 02 — Remonter les niveaux. Événement → pattern récurrent → structure → mental model ou croyance sous-jacente.
Étape 03 — Formuler une hypothèse de cause. Une cause profonde claire et testable avant de dessiner quoi que ce soit.
Ce que cela implique pour les équipes et les recruteurs
01 — Distinguer vitesse d'analyse et profondeur de diagnostic.
02 — Valoriser le designer qui ralentit au bon moment.
03 — Évaluer la capacité à remonter les niveaux.
04 — Comprendre vite ≠ avoir simplifié.
Conclusion
L'IA a rendu la recherche rapide et le savoir accessible. Mais elle n'a pas changé ce qu'est un bon diagnostic. Ne dessine pas un flow avant d'avoir trouvé la cause.
---
Sources & références
1. Andrej Karpathy — "Software is changing (again)"
2. AutoResearch — Système de recherche augmentée par IA
3. Donella Meadows — Thinking in Systems, MIT Press, 2008.