Quand nous avons lancé KeepFlow, nous avons été confrontés au choix auquel toute équipe technique fait face au commencement : construire des logiciels pour des clients, ou construire des logiciels que nous possédons. La voie de l’agence est la plus sûre. Les clients paient à la livraison, le chiffre d’affaires est prévisible, et lorsqu’un projet est livré, il devient le problème de quelqu’un d’autre. Nous avons délibérément choisi la voie la plus difficile. Chaque produit que fait KeepFlow, nous le possédons de bout en bout — nous le construisons, nous l’exploitons, et nous vivons avec chaque décision aussi longtemps qu’il existe.
Ce n’est pas une déclaration de marque. Cela change la manière dont l’ingénierie fonctionne réellement, d’une façon qu’il nous a fallu du temps pour pleinement apprécier. Voici ce que la propriété fait à votre manière de construire.
Quand la relation ne s’arrête pas à la livraison
Le trait déterminant du travail en clientèle, c’est qu’il a une fin. Vous cadrez un projet, vous le construisez, vous le remettez, et la relation se referme. Quoi qu’il advienne de ce logiciel par la suite — les bugs qui surgissent sous une charge réelle, les décrochages de performance, le correctif de sécurité qui n’est jamais appliqué — cela appartient désormais à quelqu’un d’autre. Vous êtes passé au contrat suivant.
Posséder ses produits supprime la fin. Il n’y a pas de passation, pas de moment où le code cesse d’être votre problème. Cela ressemble à un fardeau, et certains jours ça l’est. Mais cela supprime aussi la plus grande source de raccourcis dans le logiciel : la certitude que ce n’est pas vous qui gérerez les conséquences. Quand il n’y a pas de porte de sortie, prendre un raccourci ne fait pas gagner du temps — cela revient à vous prêter un problème avec intérêts, et c’est vous qui remboursez.
Chaque bug est votre bug
L’effet le plus immédiat porte sur la responsabilité, et il n’a rien d’abstrait. Chaque bug dans un produit KeepFlow est notre bug. Chaque régression de performance apparaît dans nos propres chiffres. Chaque utilisateur frustré est un verdict direct sur un travail que nous avons fait. Il n’y a personne à qui refiler le ticket.
Cela fait tomber un mur que la plupart des organisations logicielles dépensent une énergie considérable à maintenir — celui qui sépare les gens qui écrivent le logiciel de ceux qui l’exploitent. Chez KeepFlow, ce sont les mêmes personnes. L’ingénieur qui a construit une fonctionnalité est celui qui la surveille en production, qui répond quand elle sonne l’alerte à trois heures du matin, et qui lit ce que les utilisateurs en disent.
Cet arrangement est inconfortable par conception, et c’est le but. Quand la personne qui livre le code est la personne qui se fait réveiller par lui, les incitations autour de la qualité cessent d’être quelque chose que l’on doit imposer par un processus. Personne ne veut déboguer son propre raccourci à 3 h du matin. La pression à bien faire du premier coup vient de la structure du travail, pas d’un document de politique interne.
Construire pour des durées de vie, pas pour des échéances
Les projets clients s’organisent autour d’échéances. Les produits que l’on possède s’organisent autour de durées de vie, et cette différence atteint des décisions techniques qui se ressemblent en surface mais aboutissent à l’opposé.
Quand vous construisez quelque chose que vous exploiterez pendant des années, le calcul de presque chaque choix s’inverse :
- Vous investissez d’emblée dans l’observabilité, parce que c’est vous qui scruterez les tableaux de bord à 2 h du matin, et qu’un système que vous ne pouvez pas observer est un système que vous ne pouvez pas exploiter.
- Vous écrivez les tests que vous seriez tenté de sauter sous la pression d’une échéance, parce que c’est vous qui modifierez ce code dans deux ans, bien après avoir oublié comment il fonctionne.
- Vous choisissez une technologie ennuyeuse et éprouvée plutôt que le nouveau framework excitant, parce que vous vous engagez à maintenir cette décision très longtemps, et que la nouveauté a le don de se transformer en fardeau une fois l’engouement retombé.
Aucun de ces choix ne vous aide à livrer plus vite ce trimestre. Tous sont manifestement justes dès lors que votre horizon temporel se mesure en années plutôt qu’en semaines. Le travail en clientèle les récompense rarement, parce que la personne qui fait l’arbitrage n’est pas celle qui en hérite le coût. La propriété fond ces deux personnes en une seule.
La boucle de rétroaction se referme
Il y a un bénéfice plus subtil que nous avons mis plus de temps à remarquer : quand vous possédez le produit, la boucle entre le problème d’un utilisateur et sa correction se raccourcit radicalement, parce qu’aucun contrat ne se tient au milieu.
Dans le travail en agence, apprendre quelque chose sur vos utilisateurs est souvent le début d’une négociation. Vous remarquez un point de friction, mais agir dessus suppose une demande de modification, une discussion de cadrage, un nouvel énoncé de travail — et le temps que tout cela se règle, l’intuition s’est éventée. L’économie décourage activement d’agir sur ce que vous apprenez, parce que chaque amélioration est facturable et donc contestée.
Quand le produit est le vôtre, remarquer et corriger sont un seul et même geste. Un ingénieur lit un fil de support, reconnaît le schéma derrière trois plaintes, et livre le correctif l’après-midi même — sans chaîne d’approbation, sans facture, sans débat pour savoir si c’est dans le périmètre. Les personnes les plus proches du problème ont à la fois le contexte pour le comprendre et l’autorité pour le résoudre. Sur des mois, ce cumul de petites améliorations sans blocage fait l’essentiel de ce qui sépare un produit que les gens tolèrent d’un produit sur lequel ils s’appuient.
Cela change aussi ce que nous construisons au départ. Parce que nous exploitons tout ce que nous fabriquons, nous ressentons nos propres fonctionnalités manquantes avant même qu’un utilisateur ne les signale. Plusieurs des idées les plus tranchantes de nos produits sont nées d’un agacement que l’un de nous a rencontré en utilisant un autre produit au sein de la même équipe. Être son propre client le plus exigeant est un type de recherche qu’aucun cahier des charges client ne peut acheter.
Ne pas courir après les tendances
Il y a une tentation dans ce secteur à traiter la nouveauté comme le mieux — à tout reconstruire sur le framework du moment, à courir après le motif d’architecture qui fait le tour des conversations. Nous nous efforçons d’y résister, et la propriété facilite cela, parce que nous ressentons le coût complet de chaque tendance que nous suivons. Une réécriture à la mode cette année est un fardeau de maintenance que nous portons les cinq années suivantes.
Ce que nous construisons à la place, c’est une infrastructure dont les entreprises dépendent chaque jour : un support client qui doit répondre, une détection de fraude qui doit être juste, une modération qui doit être rapide, des outils que les gens saisissent sans penser à ce qu’il y a dessous. Ce genre de logiciel gagne la confiance lentement, par les vertus ennuyeuses — la fiabilité, la constance, être là et fonctionner. Ces vertus ne viennent pas de la nouveauté. Elles viennent du soin porté à quelque chose assez longtemps pour bien le faire, puis du fait de rester pour que cela le demeure.
C’est toute la raison pour laquelle nous construisons nos propres produits. Non parce que c’est plus facile — ça ne l’est pas — mais parce que vivre avec ses décisions est le moyen le plus fiable que nous connaissions d’en prendre de bonnes.
