Quand j’accompagne un développeur junior, la même conversation revient. Quelque chose, dans le projet, est manifestement inefficace : une étape manuelle qu’on pourrait automatiser, un détour que personne ne justifie, une règle qui ralentit tout le monde. La frustration est réelle et elle est légitime.

Dans la plupart des cas, il suffit d’identifier pourquoi c’est comme ça pour que le problème cesse d’en être un.

Le plus souvent, la raison est hors de notre contrôle — une contrainte d’un autre service, une décision prise ailleurs, un système qu’on ne peut pas toucher. L’inefficacité ne disparaît donc pas. Le travail reste exactement le même.

Et pourtant, ça va mieux.

Une absurdité contre une contrainte

Ce n’est pas de la résignation, et ce n’est pas non plus un tour de passe-passe psychologique.

Ce qui a changé, c’est la nature de ce qu’on subit. Une absurdité est insupportable ; une contrainte est vivable. Ce sont deux expériences différentes, et la seule chose qui les sépare est de savoir d’où ça vient.

Une absurdité n’offre aucune prise : on ne peut ni l’accepter, ni la combattre, ni l’expliquer à quelqu’un d’autre. Une contrainte, elle, a une forme. On sait qui la porte, ce qui la lèverait, et si ça vaut la peine d’essayer. On peut même décider de vivre avec — décision qui n’existe pas tant qu’on prend la chose pour une bêtise.

Et il y a un effet secondaire que je vois à chaque fois : celui qui a compris le pourquoi devient capable de proposer autre chose. Pas avant.

Ce que le pourquoi fait pour l’apprentissage

Le même phénomène est visible dans les cours, sous une autre forme.

Quand j’enseigne l’architecture des ordinateurs, le fonctionnement d’internet ou l’hébergement, je passe un temps qui peut paraître excessif sur la conception historique — pourquoi c’était fait ainsi, à ce moment-là, avec ces contraintes-là.

Ce n’est pas de la culture générale. La plupart des choix techniques que vous rencontrez portent la marque du problème qu’ils résolvaient au moment où ils ont été faits, et beaucoup survivent aujourd’hui par pure inertie. La limite d’affichage à 80 caractères vient de la largeur des cartes perforées ; plus personne n’a de cartes perforées, la limite est restée.

Sans le pourquoi, tout ça est une liste à mémoriser, sans structure et sans moyen de vérifier quoi que ce soit. Avec, deux choses deviennent possibles.

D’abord, le comment s’apprend beaucoup plus vite : ce n’est plus une suite arbitraire, c’est la conséquence d’un problème qu’on a compris. On peut le reconstituer au lieu de le retenir.

Ensuite — et c’est le vrai bénéfice — on devient capable de distinguer ce qui est encore valable de ce qui n’est plus que de l’inertie. Cette distinction est impossible à faire quand on ne connaît que la règle. C’est aussi celle qui sépare un développeur qui applique de un développeur qui décide.

Ce que ça change dans son propre travail

Sur mes propres projets, j’essaie systématiquement de comprendre le maximum de contexte avant de commencer, et en particulier pourquoi ce travail est nécessaire.

La raison est prosaïque : aucune spécification ne couvre tout. Faire un travail, c’est prendre des centaines de micro-décisions que personne n’a anticipées — un cas limite, un compromis, un détail d’affichage, un arbitrage entre deux choses également défendables.

Sans le pourquoi, ces décisions se prennent au hasard, ou en demandant à chaque fois. Avec, elles se prennent seules, et dans le bon sens la plupart du temps.

C’est la même mécanique que pour le junior, vue de l’intérieur : le pourquoi n’est pas du confort intellectuel, c’est ce qui permet d’agir là où la consigne s’arrête.

Là où l’idée devient sérieuse

Cette idée a une formulation autrement plus dure que la version managériale habituelle, et elle vient du domaine militaire.

En opération, on ne sait jamais à l’avance qui reviendra — et cela inclut celui qui commande. Un changement de commandement en cours de mission ne doit pas compromettre la mission. Il faut donc que chacun, dans l’équipe, ait le pourquoi, parce qu’un plan est bon jusqu’à la première difficulté et qu’il doit ensuite être adapté par ceux qui sont là.

Ce principe porte un nom : l’intention du commandement¹. Elle énonce le but et l’état final recherché, délibérément sans prescrire la méthode, pour que les subordonnés puissent continuer à agir quand les ordres initiaux sont devenus caducs. Elle est l’héritière directe de l’Auftragstaktik prussienne, et de l’idée — communément attribuée à Moltke — qu’aucun plan ne survit au premier contact avec l’adversaire².

Regardez ce que cette version fait à l’idée de départ. Expliquer le pourquoi n’est plus une attention portée aux gens : c’est de la redondance opérationnelle.

graph TD
    P[Le pourquoi
le but, les contraintes] --> C1[Un comment
valable ici et maintenant]
    C1 --> S{La situation change}
    S -->|on n'a que le comment| B[Blocage
il faut demander]
    S -->|on a le pourquoi| C2[Un nouveau comment]
    class B alerte
    class C2 ok

Un comment se périme. Un pourquoi permet d’en refabriquer un.

C’est pour ça que je l’ai transposé dans ma façon de constituer des équipes. Expliquer le pourquoi avant le comment donne à chacun la possibilité de se situer, de comprendre le problème plutôt que la tâche, et de monter en compétence — mais surtout, ça retire à l’équipe son point de défaillance unique : la personne qui est la seule à savoir pourquoi.

Ce que ça coûte, et quand ça ne marche pas

Un article qui s’arrêterait ici serait un sermon. Trois objections tiennent debout.

Ça prend du temps, et parfois il n’y en a pas. Dans l’urgence, on donne la consigne et on explique après. « Après » doit alors exister réellement, sinon c’est juste un mensonge poli.

On ne connaît pas toujours le pourquoi soi-même. Du code hérité, une règle que personne n’a écrite, un choix dont l’auteur est parti. Là, la réponse honnête est de le dire : « je ne sais pas pourquoi, et c’est un problème du système, pas de ta question. » C’est très différent de « c’est comme ça ». La première laisse la question ouverte, la seconde la ferme.

Toutes les archéologies ne valent pas leur prix. Chercher pourquoi une bibliothèque abandonnée fait ce qu’elle fait peut coûter une journée pour une information dont on ne fera rien. Le critère est simple : cherchez le pourquoi de ce que vous allez devoir adapter, pas de ce que vous allez seulement utiliser.

La question à se poser

Devant une consigne, une règle d’équipe, une architecture qu’on vous impose, une seule question dit si vous avez ce qu’il vous faut :

Si la situation change demain, est-ce que je saurais quoi faire ?

Si la réponse est non, ce qui vous manque n’est pas un complément de méthode.

C’est le pourquoi.

Références