Personne ne sait vraiment comment fonctionne un produit logiciel [traduction]

1. L’opacité des grands systèmes technologiques

• Même les grandes entreprises tech exploitent leurs propres systèmes dans un véritable « brouillard de guerre ».
• À des questions pourtant élémentaires comme « un utilisateur de type Y peut-il utiliser la fonctionnalité X ? », « que se passe-t-il exactement lors de l’action Z ? » ou « combien existe-t-il de formules tarifaires actuellement ? », seules quelques rares personnes dans l’organisation peuvent répondre.
• Dans les cas extrêmes, il faut même désigner quelqu’un pour enquêter, alors que la réponse devrait ressortir d’une simple lecture de la documentation publique — ce qui n’est pas le cas.

2. La source de la complexité : les Wicked Features

• Les grands logiciels deviennent extrêmement complexes à cause du self-hosting, des essais gratuits, des contrôles d’organisation et de politiques, de la localisation multilingue, des fonctions de conformité réglementaire, etc. Ces fonctions affectent chaque nouvelle fonctionnalité.
• Exemple : si l’on ajoute un contrôle de politique, il faut ensuite l’appliquer à chaque nouvelle fonctionnalité ; en cas de localisation, il faut aussi suivre avec la traduction.
• Savoir si « un client enterprise en self-hosting dans la région UE peut accéder à une fonctionnalité donnée » ne peut souvent se vérifier qu’en explorant directement le code ou par expérimentation. Omettre ce type de fonctions signifie renoncer à d’énormes revenus — c’est l’une des différences entre grandes et petites entreprises.

3. Les limites de la documentation

• En théorie, documenter les interactions lors de l’ajout d’une nouvelle fonctionnalité est possible, mais le système évolue plus vite que la documentation.
• Dans un environnement dynamique, et non un système statique, les auteurs de documentation devraient constamment devancer le changement — ce qui relève de l’impossible.
• Problème plus profond : de nombreux comportements naissent des interactions entre paramètres par défaut plutôt que d’intentions explicites — documenter revient alors à explorer le système réel.

4. Le cœur de la réponse : le codebase et les ingénieurs

• Les réponses exactes ne viennent qu’en allant regarder directement dans le codebase, ce qui constitue une base du pouvoir des ingénieurs.
• La fonction essentielle d’une équipe d’ingénierie est sa capacité à répondre aux questions sur le logiciel.
• Cela mobilise la connaissance tacite qui réside dans la tête des personnes familières d’un code précis.
• Lors des réorganisations d’équipe, la perte de connaissances impose parfois une « chirurgie exploratoire » (modifier le code, forcer des vérifications, etc.).
• Écrire du code est relativement facile, mais fournir des réponses fiables est difficile pour une question de confiance (risque de se tromper, nécessité de résumer et de compresser l’information).

5. Conclusion : une capacité précieuse

• Les non-techniciens croient souvent que les logiciels sont parfaitement compris par les ingénieurs, mais personne ne comprend parfaitement un grand système.
• Même les questions de base exigent souvent des enquêtes répétées, et les changements font apparaître des nuances et des exceptions. La capacité à fournir des réponses exactes a une valeur immense.