Ask Your Developer

Pour comprendre d'où vient la conviction, il faut regarder le parcours de l'auteur. Avant Twilio, Lawson enchaîne les startups des années 2000, dont StubHub, revendue à eBay. Partout, il constate la même friction : intégrer la téléphonie ou l'envoi de messages dans un produit relève du cauchemar, il faut négocier avec des opérateurs, empiler des systèmes lourds, attendre des mois. Un développeur qui veut juste passer un appel depuis son application se heurte à un mur.

En 2008, il fonde Twilio avec deux associés autour d'une idée simple : transformer ces fonctions téléphoniques en quelques lignes de code que n'importe quel développeur peut appeler en une après-midi. Pas un logiciel fini vendu à des acheteurs, mais des briques offertes à ceux qui construisent. Le client de Twilio n'est pas le directeur des achats. C'est le codeur, directement, celui qui va essayer le produit un soir et le mettre en production le lendemain.

Le nœud du livre est là : dans la manière dont on considère les gens qui codent. Le modèle dominant, hérité de l'usine, traite le développeur comme un exécutant. On rédige des spécifications détaillées en haut, on les fait descendre, on mesure la productivité au nombre de fonctionnalités livrées. Le développeur reçoit une commande, il l'exécute. Personne ne lui demande son avis sur le problème lui-même, comme si penser et coder étaient deux métiers séparés.

Lawson trouve ce modèle absurde parce qu'il gaspille précisément ce qui fait la valeur d'un bon développeur : sa capacité à résoudre. Écrire du code, c'est passer sa journée à trouver des solutions à des difficultés que personne n'avait anticipées. Les meilleurs voient des raccourcis, des risques, des possibilités que le cahier des charges ignore. Les enfermer dans l'exécution, c'est acheter une Ferrari pour la garder au garage — on paie le talent et on interdit qu'il serve.

Si on prend un peu de hauteur, le livre pose une question qui dépasse la gestion des équipes techniques : qu'est-ce qu'une entreprise, quand tout ce qu'elle fait passe par du logiciel ? Longtemps, le code a été un outil au service du métier — une caisse enregistreuse plus rapide, un tableur à la place d'un cahier. Lawson défend une bascule : le logiciel n'est plus l'outil du métier, il devient le métier. La banque est son application, le transporteur est son système de suivi, le commerçant est son parcours d'achat en ligne. Ce que le client touche, c'est du code, et rien d'autre.

Dans ce monde, acheter son logiciel revient à louer son identité. Celui qui tourne avec les mêmes solutions standardisées que ses concurrents propose forcément la même chose qu'eux, à la marge près. Il ne peut se distinguer que sur le prix — le pire terrain qui soit, celui où l'on se saigne pour rester en course. À l'inverse, celui qui construit décide de chaque détail de ce que vit son client, et ce détail, personne d'autre ne l'a. La capacité à écrire son propre logiciel devient la frontière entre les entreprises qui façonnent leur produit et celles qui assemblent celui des autres.

Le livre de Lawson tient finalement dans un déplacement de regard. Là où le dirigeant classique voit un poste de coût à optimiser, un service à sous-traiter, une file de tickets à faire descendre, Lawson voit un interlocuteur — quelqu'un qui, parce qu'il fabrique le produit de ses mains, comprend le problème par en dessous, là où le patron ne le comprend que par en haut. Parler aux développeurs plutôt qu'aux fournisseurs, ce n'est pas remplacer un prestataire par un autre. C'est reconnaître qu'une partie de la stratégie se joue désormais dans le code, et que le code a des auteurs, avec leurs idées, leur regard sur le client, leur manière de flairer ce qui va coincer.