La vague de licenciements de la fin de l'année dernière, plusieurs de mes amis ne l'ont pas échappée. Moi aussi, j'ai pris mon indemnité et je suis rentré chez moi. Les deux premières semaines, c'était plutôt agréable : je dormais jusqu'à midi, je jouais aux jeux vidéo, je regardais des séries. Mais à la troisième semaine, en voyant le solde de ma carte bancaire qui ne faisait que diminuer, j'ai commencé à stresser. Le crédit immobilier et le crédit auto ne se soucient pas de savoir si tu es au chômage ou pas, ils prélèvent à la date prévue.
Pas le choix, j'ai commencé à chercher des missions dans les groupes de freelance. Avant, quand j'écrivais du code en entreprise, je pensais qu'il suffisait d'être bon techniquement : architecture, algorithmes, optimisation des performances, je parlais de tout ça sans problème. Mais après avoir accepté ma première mission freelance, la réalité m'a giflé violemment.
Le client était un petit patron d'e-commerce, qui m'a contacté via un ami, en disant qu'il avait un projet de système d'administration backend, délai d'un mois, prix assez bas. J'étais pressé de commencer, je n'ai pas trop réfléchi et j'ai accepté. Le projet en lui-même n'était pas difficile, juste des opérations CRUD. J'ai utilisé React avec Ant Design, les yeux fermés. Une fois terminé, je l'ai fait tourner en local, les tests étaient bons, j'ai packagé et envoyé au client.
Une demi-journée plus tard, le client m'envoie une capture d'écran sur WeChat et me demande : « Mon pote, ton code je ne comprends pas trop, tu peux le rendre plus propre ? »
J'étais abasourdi. Comment ça, plus propre ? J'ouvre la capture d'écran qu'il m'a envoyée, j'ai failli m'évanouir. En fait, il avait ouvert directement le fichier bundle.js que j'avais packagé, à l'intérieur c'était du code compressé et obfusqué par Webpack, une seule ligne dense de plusieurs dizaines de milliers de lignes, les noms de variables tous a, b, c, d. À ses yeux, c'était un amas de charabia.
Je lui ai expliqué que c'était compressé, pour la mise en ligne, que le volume était réduit et le chargement plus rapide. Il a fait semblant de comprendre, puis a insisté : « Mais tu peux m'en donner une version lisible ? Si plus tard je veux modifier quelque chose, ou si quelqu'un d'autre doit maintenir le code, c'est impossible là. »
À ce moment-là, j'ai soudain réalisé que ce qui était évident pour moi — la « compression et obfuscation » — était pour le client « ce type n'est pas fiable, il écrit du code comme de la merde ». Il ne comprend pas ce qu'est le Tree Shaking, il ne comprend pas ce qu'est un AST (arbre syntaxique abstrait), il ne connaît qu'une seule règle : le code doit être lisible par un humain.
Par la suite, j'ai appris ma leçon. Avant chaque livraison, j'utilise un outil de formatage et compression JS pour réorganiser le code. L'outil est simple : il restaure le code compressé en un format avec indentation, sauts de ligne, et même si les noms de variables restent courts, au moins la structure est claire, puis je génère un document pour le client. Parfois, je formate aussi proactivement le code source avec prettier, j'ajoute des commentaires, et j'envoie tout ensemble.
Devinez quoi ? Pour les missions suivantes, la satisfaction client a grimpé en flèche. Une fille qui fait du média indépendant m'a contacté pour un petit outil, après avoir reçu le code elle était ravie, elle a dit « même si je ne comprends pas, ça a l'air professionnel ». Un autre client m'a directement recommandé à son ami, en disant que ce jeune homme travaille avec soin.
Cette histoire m'a fait réfléchir longtemps. Nous, les techniciens, on tombe facilement dans une sorte d'auto-satisfaction, en pensant qu'utiliser un framework récent, écrire un algorithme astucieux, c'est ça être bon. Mais ce que le client veut est en fait très simple : que ça fonctionne, qu'on puisse trouver quelqu'un en cas de problème, et que le code ne ressemble pas à un livre de sorcellerie. Surtout ces donneurs d'ordre qui ne comprennent pas la technique, leur critère pour juger si tu es fiable, c'est parfois juste si le code semble propre ou pas.
Maintenant, dans mon processus de prise de missions, le formatage du code est une étape obligatoire. Même pour un petit projet, avant la livraison je passe un coup d'outil pour générer une version lisible. Parfois j'écris aussi un petit README pour expliquer au client comment déployer, comment modifier la configuration. Juste ce petit effort supplémentaire m'a permis de fidéliser plusieurs clients sur le long terme.
Alors, vous voyez, le licenciement d'une grande entreprise, c'est effrayant ? Oui. Mais parfois, en changeant de perspective, c'est justement parce que j'ai quitté cet environnement qui ne regarde que les KPI et les OKR que j'ai vraiment compris que la technique est finalement au service des gens. Ce qui importe au client, ce n'est pas la complexité de ton code, mais si tu peux lui simplifier la vie et le rassurer. Et le formatage du code, cette petite chose, est justement l'interrupteur qui fait que le client se sent « pris au sérieux ».