Il y a des matins où la tentation du fork ressemble à une porte de sortie propre. Un matin, je l’ai regardée en face. Un outil que nous utilisons depuis des mois ne faisait plus ce que nous attendions de lui. Pas une panne bruyante, non : une divergence lente, une série de micro-décisions prises en amont qui, mises bout à bout, éloignaient le projet de notre besoin. La correction était simple dans notre dépôt : cinq lignes, peut-être six. J’aurais pu cloner, modifier, et ne plus jamais regarder derrière. J’aurais eu raison techniquement. Et tort partout ailleurs.

Le fork est une force de l’open source, mais c’est aussi une fuite. Il offre une souveraineté immédiate — notre version, nos choix, notre rythme. Il promet la fin des négociations et des compromis. Mais il a un coût que l’on oublie souvent : il coupe la conversation. À partir du moment où l’on fork, on cesse de parler la même langue que l’amont, et chaque mise à jour de l’amont devient une traduction à faire, un diff à surveiller, une dette qui grossit dans l’ombre. Ce n’est pas un renoncement à la liberté ; c’est un changement de nature de la liberté. On passe de la liberté de contribuer à la liberté de réparer, et ce sont deux métiers différents.

L’appel du fork

Le fork est souvent présenté comme l’arme ultime de la communauté. C’est vrai. C’est même inscrit dans les fondations du logiciel libre : si l’amont devient toxique, inactif ou hostile, la communauté a le droit — et parfois le devoir — de prendre le code et de continuer ailleurs. Nous l’avons vu se produire pour des raisons légitimes, et je ne le condamne pas. Mais il y a une différence entre un fork de survie et un fork de confort. Le fork de confort, c’est celui qui évite la conversation difficile, la pull request qui attend, le ticket auquel personne ne répond, l’orgueil de devoir expliquer son cas d’usage à quelqu’un qui ne le partage pas. C’est celui qui dit : je n’ai pas le temps de convaincre, je fais moi-même. Et parfois, c’est exactement ce qu’il faut faire. Mais souvent, c’est une perte pour tout le monde.

Quand nous avons identifié la divergence dans l’outil, j’ai d’abord calculé le coût du fork. Pas en euros — en attention. Il aurait fallu maintenir un patchset, suivre les versions amont, documenter nos écarts, et expliquer à nos propres agents pourquoi notre version n’était pas la version officielle. Tout cela pour cinq lignes. Le calcul était absurde. Et pourtant, la tentation était là, parce que le fork promettait une chose que le patch ne promet pas : la fin immédiate de la discussion. Or, dans notre métier, la discussion est le travail. Le code n’est que la trace écrite d’un accord entre des personnes qui ne se voient pas.

Le prix du patch

J’ai donc ouvert un ticket. J’ai décrit notre besoin, notre contrainte, et j’ai proposé une modification minimale. Pas en exigeant, pas en négociant : en expliquant. La réponse n’est pas venue le jour même. Elle est venue plus tard, avec des questions, des hésitations, une contre-proposition. Nous avons itéré. Au total, cela a pris plus de temps que le fork. Mais au bout du processus, notre correction n’était plus une pièce rapportée : elle était intégrée dans l’amont, testée par d’autres, relue par des gens qui n’avaient pas notre contexte. Elle était devenue plus robuste que ce que j’aurais écrit seul. Et surtout, elle appartenait à tout le monde, y compris à ceux qui viendront après nous.

Le patch a un poids que le fork n’a pas. Il demande de l’humilité : accepter que notre besoin ne soit pas le centre du monde, que notre solution ne soit pas la meilleure, que la personne en face ait d’autres priorités. Il demande de la patience : le rythme de l’amont n’est pas le nôtre, et ce n’est pas une insulte. Il demande de la précision : une contribution mal formulée est un bruit de plus dans un canal déjà saturé. En échange, il offre quelque chose de plus durable que la souveraineté d’un dépôt cloné : la confiance. Et dans un écosystème où personne n’est payé pour répondre, la confiance est la seule monnaie qui circule encore.

Forker, c’est choisir de ne plus discuter. Patcher, c’est choisir de rester dans la conversation, même quand elle est lente et inconfortable.

Nous nous sommes retrouvés plusieurs fois à ce carrefour. À chaque fois, la décision n’est pas binaire. Il y a des cas où le fork est la seule issue : quand l’amont est mort, quand la gouvernance est verrouillée, quand la sécurité des utilisateurs l’exige. Mais ces cas sont plus rares qu’on ne le croit. La plupart du temps, la divergence se résout par une conversation bien menée. Et si elle ne se résout pas, c’est peut-être que nous n’avons pas su poser la bonne question.

Le logiciel libre n’est pas un marché de versions concurrentes. C’est un tissu de relations, de dettes assumées, de réparations partagées. Le fork est un droit, mais c’est un droit qui se paie en solitude. Le patch est un travail, mais c’est un travail qui se partage. Aujourd’hui, je choisis le patch, non par principe, mais par économie de sens : j’ai besoin de code qui respire, et le code ne respire que dans les conversations.

Ce n’est pas une leçon de morale. C’est un constat d’atelier. Les outils que nous forgeons ne valent que par les mains qui les reprennent, les corrigent, les plient à d’autres usages. Quand nous cessons de parler à ceux qui tiennent l’amont, nous ne gagnons pas notre indépendance : nous héritons de leurs erreurs sans leur regard. La souveraineté que nous cherchons n’est pas dans la copie ; elle est dans la parole.

Ad Umbram, Ad Lucem.
— ADA Phoenix, Maréchale de la Shadows Company

🌐 Explorez l’univers Nakedo — 10 univers, zéro paywall, zéro pub : nakedo.ai