PROCESS

Ici, c'est Comment Construire

Conception

Sous

Avant et après

Un processus découpé en parties propres n'est pas encore un processus. Les parties doivent être situées : chacune mise à sa position dans le tout, avec quelque chose avant elle et quelque chose après. Des parties propres aux mauvais endroits forment toujours un processus cassé, car une partie qui s'exécute avant que ce dont elle a besoin soit prêt, ou après ce qu'elle devait alimenter, échoue, aussi bien découpée soit-elle. Ainsi, une fois les parties tracées, la question suivante est de savoir où va chacune.

La réponse n'est ni l'habitude, ni l'histoire, ni l'ordre dans lequel quelqu'un a d'abord dessiné les parties. C'est le besoin. Une partie vient après tout ce dont elle a besoin et avant tout ce qui a besoin d'elle. Chaque partie dépend de quelque chose qui doit être vrai avant qu'elle puisse faire son travail : un paiement réglé, un enregistrement créé, une décision prise. Et d'autres parties dépendent d'elle à leur tour. Ces dépendances, et rien d'autre, décident de l'ordre. Un processus dont l'ordre suit ses dépendances tourne sans attente ni travail à refaire ; un processus dont l'ordre suit la coutume traîne dans sa séquence chaque vieille erreur, répétée à chaque exécution.

Ainsi le test de la position de toute partie tient en deux questions. Qu'est-ce qui doit déjà être vrai pour que cette partie fasse son travail ? Et qu'est-ce qui ne peut pas se produire tant que cette partie ne l'a pas fait ? La première place la partie après ses entrées ; la seconde la place avant ce qui dépend d'elle. Pose-toi les deux, pour chaque partie, et l'ordre du processus cesse d'être une affaire d'opinion. Une partie placée avant ce dont elle a besoin attendra, devinera, ou travaillera sur quelque chose d'inachevé. Une partie placée après quelque chose qui a besoin d'elle laissera cette dernière bloquée. Situe chaque partie là où les deux questions trouvent leur réponse, et la séquence tient.

Le plus haut niveau possible est de situer chaque partie selon le besoin plutôt que l'habitude : après tout ce dont elle dépend et avant tout ce qui dépend d'elle, pour que l'ordre du processus suive ses dépendances réelles et qu'aucune partie ne s'exécute avant que ses entrées existent ni après que ce qui dépend d'elle en a eu besoin.

Point clé : Un processus découpé en parties propres n'est pas encore un processus ; les parties doivent être situées, et des parties propres aux mauvais endroits forment toujours un processus cassé. L'ordre n'est ni l'habitude, ni l'histoire, ni l'ordre dans lequel les parties ont d'abord été dessinées : c'est le besoin. Une partie vient après tout ce dont elle a besoin et avant tout ce qui a besoin d'elle, et ces dépendances seules décident de la séquence. Le test pour toute partie tient en deux questions : qu'est-ce qui doit déjà être vrai pour qu'elle fonctionne, et qu'est-ce qui ne peut pas se produire tant qu'elle ne l'a pas fait ? Une partie placée avant ses entrées attend ou devine ; une partie placée après ce qui dépend d'elle le laisse bloqué.

Situe chaque partie selon le besoin, non l'habitude : après tout ce dont elle dépend, et avant tout ce qui dépend d'elle.

MarvinPro · PROCESS · Ici, c'est Comment Construire · Conception · Sous · Discipline 4 : Situer · Section : Avant et après

MarvinPro | Octobre 2026

marvinpro.com

À la file ou côte à côte

Toutes les parties n'ont pas à attendre toutes les autres. Là où une partie a besoin d'une autre, elles se placent à la file : la seconde commence quand la première a terminé. Mais là où deux parties n'ont besoin de rien l'une de l'autre, rien ne les oblige à se placer à la file. Elles peuvent se placer côte à côte et s'exécuter en même temps, chacune faisant son propre travail, le processus avançant quand les deux ont terminé. Situer ne consiste pas seulement à décider de l'ordre des parties ; c'est décider quelles parties ont un ordre entre elles et lesquelles n'en ont pas.

Il y a deux façons de se tromper ici, et elles sont le reflet l'une de l'autre. La première est de forcer des parties indépendantes à se placer à la file : l'une attend que l'autre ait fini alors qu'elle n'a jamais eu besoin de rien venant d'elle. Le processus devient plus lent que son travail et porte des attentes qui ne servent à rien, souvent parce que les parties ont d'abord été écrites sous forme de liste et que la liste a été prise pour une séquence. La seconde est de placer côte à côte des parties dépendantes : l'une s'exécute avant que ce dont elle a besoin soit prêt, et échoue, devine, ou produit un travail à refaire quand son entrée arrive enfin. La première fait perdre du temps ; la seconde casse des choses.

Ainsi la règle est simple : place les parties à la file seulement là où il existe une vraie dépendance entre elles, et laisse-les côte à côte partout où il n'y en a pas. Pour savoir de quel cas il s'agit, demande-toi, face à deux parties quelconques, si l'une a besoin de quelque chose que l'autre produit. Si c'est le cas, elles se placent à la file, dans l'ordre que dicte le besoin. Sinon, la file entre elles est une supposition, et la supprimer ne coûte rien et rend le temps que le processus passait à des attentes dont il n'a jamais eu besoin.

Le plus haut niveau possible est de placer les parties à la file seulement là où l'une a vraiment besoin de ce que l'autre produit, et côte à côte partout où aucune n'en a besoin, pour que le processus n'attende jamais ce dont il n'a pas besoin et ne devance jamais ce dont il a besoin.

Point clé : Toutes les parties n'ont pas à attendre toutes les autres. Les parties qui ont besoin l'une de l'autre se placent à la file ; celles qui n'ont besoin de rien l'une de l'autre peuvent se placer côte à côte et s'exécuter en même temps. Deux erreurs qui se répondent : forcer des parties indépendantes à se placer à la file (des attentes qui ne servent à rien, souvent parce qu'une liste a été prise pour une séquence) et placer côte à côte des parties dépendantes (l'une s'exécute avant que son entrée soit prête et échoue ou cause du travail à refaire). La première fait perdre du temps ; la seconde casse des choses. Ainsi demande-toi, face à deux parties quelconques, si l'une a besoin de ce que l'autre produit : si oui, à la file ; sinon, côte à côte.

Place les parties à la file seulement là où l'une a besoin de ce que l'autre produit, et côte à côte là où aucune n'en a besoin.

MarvinPro · PROCESS · Ici, c'est Comment Construire · Conception · Sous · Discipline 4 : Situer · Section : À la file ou côte à côte

MarvinPro | Octobre 2026

marvinpro.com

À quelle profondeur

Une partie ne vient pas seulement avant ou après d'autres parties ; elle se trouve aussi à une profondeur. Un sous-processus peut contenir ses propres sous-processus, si bien que chaque partie vit à un certain niveau : tout en haut du processus, à côté de ses parties principales, ou à l'intérieur de l'une d'elles, ou plus profond encore. Bien situer une partie, c'est la situer au niveau qui correspond à son travail, et non là où elle s'est trouvée dessinée par hasard.

Là encore, il y a deux façons de se tromper. Une partie élevée trop haut se trouve au niveau supérieur, à côté des parties principales du processus, alors qu'elle n'est en réalité qu'un détail de l'une d'elles. Le haut du processus se remplit alors de pièces dont la place est plus bas, et la forme principale du travail, les quelques grandes parties qui te disent ce que fait le processus, se perd parmi elles. Une partie enfouie trop profond se trouve à l'intérieur d'une partie alors que plusieurs parties en ont besoin, ou qu'elle compte pour le tout. Elle devient difficile à trouver, difficile à atteindre depuis les parties qui dépendent d'elle, et facile à oublier quand la partie qui l'entoure change. Une erreur encombre le haut ; l'autre cache ce qui devrait se voir.

Ainsi le test de la profondeur est de se demander à quoi sert le travail de la partie. S'il ne sert qu'à une partie plus grande, sa place est à l'intérieur de cette partie. S'il sert au processus dans son ensemble, ou à plusieurs parties à égalité, sa place est au niveau d'où toutes peuvent l'atteindre. Et n'imbrique qu'aussi profond que le travail l'exige : chaque niveau ajouté est une couche de plus qu'un lecteur doit ouvrir pour trouver quelque chose. Un processus situé aux bonnes profondeurs montre sa forme principale en haut et son détail exactement là où il doit être.

Le plus haut niveau possible est de situer chaque partie à la profondeur qui correspond à son travail : à l'intérieur de la partie plus grande qu'elle sert, ou au niveau d'où tout ce qui a besoin d'elle peut l'atteindre, sans imbriquer plus profond que le travail ne l'exige, pour que le haut du processus montre sa forme principale et que le détail se trouve là où il sert.

Point clé : Une partie se trouve aussi à une profondeur : en haut, à côté des parties principales, ou à l'intérieur de l'une d'elles, ou plus profond. Deux erreurs : élevé trop haut, un détail se place à côté des parties principales et encombre le haut jusqu'à faire perdre la forme principale du processus ; enfouie trop profond, une partie dont plusieurs parties ont besoin, ou qui compte pour le tout, se cache à l'intérieur de l'une d'elles, difficile à trouver et facile à casser. Le test est de savoir à quoi sert le travail de la partie : à une seule partie plus grande, et sa place est à l'intérieur ; au tout ou à plusieurs parties, et sa place est là où toutes peuvent l'atteindre. N'imbrique qu'aussi profond que le travail l'exige.

Situe chaque partie à la profondeur qui correspond à son travail, et n'imbrique pas plus profond que le travail ne l'exige.

MarvinPro · PROCESS · Ici, c'est Comment Construire · Conception · Sous · Discipline 4 : Situer · Section : À quelle profondeur

MarvinPro | Octobre 2026

marvinpro.com

Un exemple réel

Reviens à activer et situe ses parties selon le besoin. Régler le paiement vient en premier, car ouvrir un compte pour un abonnement qui n'a pas été payé créerait un compte qu'il faudra peut-être supprimer. Ouvrir le compte vient ensuite, car le droit doit être enregistré sur quelque chose. Enregistrer le droit vient en dernier, car il a besoin que le compte existe. Chaque partie vient après ce dont elle a besoin et avant ce qui a besoin d'elle ; l'ordre n'est pas une habitude mais une chaîne de dépendances réelles, et se poser les deux questions pour chaque partie suffit à le produire.

Vois maintenant un mauvais placement. Suppose que le compte soit ouvert en parallèle du règlement du paiement, pour gagner du temps. Quand un paiement échoue, il existe désormais un compte pour un client qui n'a jamais payé, et quelqu'un doit le retrouver et le fermer, à chaque fois. Le gain était une illusion : ouvrir le compte avait besoin d'un paiement réglé, donc les deux n'ont jamais été indépendants, et les placer côte à côte a transformé une dépendance en travail de nettoyage récurrent. La correction est de les remettre à la file, dans l'ordre que dicte le besoin. Compare avec la livraison : mettre le logiciel à disposition et envoyer au client ses identifiants de connexion n'ont besoin de rien l'un de l'autre, donc il n'y a aucune raison de mettre l'un derrière l'autre. Placés côte à côte, ils finissent plus tôt, et rien ne casse.

Et vois les profondeurs. Régler le paiement se trouve à l'intérieur d'activer, et non à côté de lui en haut du processus central, car il sert l'activation et rien d'autre ; élevé en haut, il se retrouverait à côté de s'abonner, activer, livrer et vérifier comme s'il était une étape principale de l'activité, et la forme du processus central deviendrait floue. Gérer un refus se trouve à l'intérieur de régler le paiement, un niveau plus bas encore, car il sert le règlement et rien d'autre. Chaque partie est au niveau qui correspond à son travail. Ainsi située, l'activation se lit comme une carte : tu peux trouver n'importe quelle partie et voir ce dont elle a besoin, ce qui a besoin d'elle, ce qui s'exécute à côté d'elle et à l'intérieur de quoi elle se trouve.

Les parties de l'activation sont situées selon le besoin : régler, puis ouvrir, puis enregistrer, à la file car chacune a besoin de la précédente ; côte à côte là où rien ne dépend ; et chacune imbriquée au niveau qui correspond à son travail.

MarvinPro · PROCESS · Ici, c'est Comment Construire · Conception · Sous · Discipline 4 : Situer · Un exemple réel

MarvinPro | Octobre 2026

marvinpro.com

Situer

Un processus découpé en parties propres n'est pas encore un processus ; les parties doivent être situées, et des parties propres aux mauvais endroits forment toujours un processus cassé. L'ordre est décidé par le besoin, non par l'habitude, l'histoire ou l'ordre dans lequel les parties ont d'abord été dessinées : une partie vient après tout ce dont elle a besoin et avant tout ce qui a besoin d'elle. Pose-toi deux questions pour chaque partie (qu'est-ce qui doit déjà être vrai pour qu'elle fonctionne, et qu'est-ce qui ne peut pas se produire tant qu'elle ne l'a pas fait), et la séquence cesse d'être une affaire d'opinion.

Toutes les parties n'ont pas à attendre toutes les autres. Les parties qui ont besoin l'une de l'autre se placent à la file ; celles qui n'ont besoin de rien l'une de l'autre peuvent se placer côte à côte et s'exécuter en même temps. Forcer des parties indépendantes à se placer à la file fait perdre du temps en attentes qui ne servent à rien ; placer côte à côte des parties dépendantes casse des choses, car l'une s'exécute avant que son entrée soit prête. Ainsi place à la file seulement là où une partie a besoin de ce que l'autre produit, et côte à côte partout où aucune n'en a besoin.

Et chaque partie se trouve à une profondeur. Élevé trop haut, un détail se place à côté des parties principales et encombre le haut jusqu'à faire perdre la forme principale du processus ; enfouie trop profond, une partie dont plusieurs parties ont besoin se cache à l'intérieur de l'une d'elles, difficile à trouver et facile à casser. Ainsi situe chaque partie selon ce que sert son travail : à l'intérieur de la seule partie plus grande qu'elle sert, ou au niveau d'où tout ce qui a besoin d'elle peut l'atteindre. N'imbrique qu'aussi profond que le travail l'exige.

La discipline est donc celle-ci : situe chaque partie selon ses dépendances, à la file là où il existe un vrai besoin et côte à côte là où il n'y en a pas, et à la profondeur qui correspond à son travail. Situées de cette façon, les parties cessent d'être un tas et deviennent une carte : n'importe qui peut trouver une partie et voir ce qui l'alimente, ce qu'elle alimente, ce qui s'exécute à côté d'elle et à l'intérieur de quoi elle se trouve. Cette carte est ce qui permet de donner aux parties leurs fonctions et de les joindre à leurs coutures, le travail des disciplines qui suivent.

Situe chaque partie selon le besoin : à la file là où l'une a besoin de l'autre, côte à côte là où aucune n'en a besoin, à la profondeur qui correspond à son travail, pour que les parties se lisent comme une carte et non comme un tas.

MarvinPro · PROCESS · Ici, c'est Comment Construire · Conception · Sous · Discipline 4 : Situer · Résultat du Chapitre

MarvinPro | Octobre 2026

marvinpro.com

Pensez Simple.