Je n'ai pas commencé dans l'architecture système. J'ai commencé dans le design graphique, en prenant le travail qui venait, en apprenant le métier au contact de clients qui avaient besoin de quelque chose sans pouvoir le décrire précisément.
Le design m'a enseigné la partie du métier que la formation en ingénierie saute souvent : un livrable n'est bon que s'il résout le problème que le client a réellement, qui est rarement celui qu'il a énoncé en premier. Remonter jusqu'au vrai besoin — par des questions, des esquisses, et en se trompant quelques fois à peu de frais — est la même compétence, que la sortie soit un logo ou un modèle de données.
La transition s'est faite progressivement, et pour des raisons peu glorieuses. Les clients demandaient sans cesse des choses qu'aucun fichier de design ne pouvait résoudre. Il leur fallait un parcours de réservation, puis un suivi de stock, puis comprendre pourquoi deux rapports se contredisaient. Chaque réponse exigeait de descendre d'une couche, jusqu'à ce que le travail ne soit plus une décoration posée sur un système, mais le système lui-même.
Ce qui a le plus changé, c'est l'horizon temporel. Un design est jugé à sa livraison. Un système est jugé pendant des années, par des personnes absentes de la conversation initiale, dans des conditions que personne n'avait anticipées. Cela déplace les priorités : nommer clairement, garder des modules réellement séparables, écrire pourquoi une décision a été prise et pas seulement ce qui a été décidé. Le travail qui ressemble à de la surcharge au premier jour est ce qui rend le trentième mois gérable.
Les années de freelance se sont révélées être la préparation utile, non le détour. Tout faire soi-même — la proposition, le cadrage, la réalisation, la facture, la conversation gênante quand quelque chose a glissé — apprend où les projets cassent vraiment. C'est rarement le code. C'est l'écart entre ce qui a été promis, ce qui a été compris et ce qui était nécessaire.