> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/fr/2024/essay-collection-informal-talks.md).

# Recueil de notes — Réflexions diverses

Avant le Nouvel An, j’ai étudié la construction des plateformes de tests A/B. Les détails sont réunis dans [Le domaine des problèmes A/B](https://km.sankuai.com/collabpage/2103469706).

1. Où en sommes-nous ? Dans le modèle de maturité de l’expérimentation, Jingwan se situe à peu près au stade de la marche, tandis que les autres activités en sont à ramper. Ramper est le premier stade du modèle. Avant cela, je parlerais plutôt d’éveil ou d’initiation. À ce premier stade, l’objectif est de créer les conditions élémentaires de l’expérimentation, notamment les outils et les compétences de base en science des données.
2. Les plateformes A/B les plus avancées de l’entreprise. Nous avons surtout échangé avec Horizon, de la plateforme centrale du groupe, et avec la plateforme A/B de l’exécution des services à domicile. Elles en sont à peu près au stade de la course. Toutes deux cherchent à abaisser à grande échelle les barrières à l’expérimentation tout en garantissant la fiabilité des résultats. Il s’agit d’éviter que les expérimentateurs consacrent trop d’énergie à justifier leur protocole, ou que des facteurs humains compromettent la confiance dans les expériences. Des postes de science des données ont été introduits. Les indicateurs montrent une prise en compte de toute la chaîne : intégration, répartition du trafic, mise en œuvre et décision. On suit, par exemple, la proportion des nouvelles expériences dont l’objectivité peut être évaluée et celle des résultats objectifs parmi les expériences importantes.
3. **Les enseignements de l’évolution de la plateforme A/B de l’exécution des services à domicile. Ces informations viennent de mes échanges avec l’un de ses membres clés. J’y vois un exemple typique de la technologie au service du métier. Dans cette adaptation continue de la relation entre technologie et activité, le plus précieux est la capacité des personnes à penser les deux ensemble.** Dans un domaine aussi spécialisé, les équipes métier ne savent pas toujours décrire leur problème, ni même parfois en reconnaître l’existence. Pour bien les servir, il faut sortir de son propre domaine, aller sur le terrain, comprendre leur travail et changer de perspective. L’exécution est au cœur des services à domicile ; en améliorer l’efficacité est donc essentiel. Le modèle à plusieurs parties des services géolocalisés exige beaucoup d’expériences sur les algorithmes et les stratégies, d’où un besoin particulièrement fort de plateformes A/B de haut niveau. Au départ, la plateforme et le métier fonctionnaient avec un couplage faible, ce qui mettait davantage en valeur la souplesse du modèle de plateforme. En 2022, l’équipe a choisi de se concentrer sur l’exécution et de proposer un service entièrement pris en charge. Le métier n’a plus qu’à exprimer ses besoins ; la conception, la réalisation et l’analyse des expériences sont assurées de bout en bout par l’équipe de données. Celle-ci fournit une solution, avec des capacités, des outils et des méthodes, plutôt qu’une simple capacité technique. Face aux difficultés les plus exigeantes de l’activité, l’équipe d’exécution a aussi exploré assez tôt la collaboration avec la recherche. La plateforme A/B propose trois niveaux d’ouverture : un service entièrement géré, un service partiellement géré et un accès au moteur d’analyse. Ils correspondent respectivement à une prise en charge centralisée, à l’ouverture des capacités de conception et d’évaluation des expériences, et à l’accès aux méthodes d’analyse élémentaires.

***

En revenant récemment sur notre chantier de bibliothèque de composants, j’ai essayé de répondre à une question assez floue : comment créer une bibliothèque pleine de vitalité ? Le sujet est très courant et paraît généralement clair, simple et facile à comprendre. Pourtant, les bibliothèques populaires, agréables à utiliser et durables sont rares, surtout celles qui durent. Je propose deux angles de réponse.

**Résoudre de vrais problèmes dans un périmètre donné, en conservant un rapport positif entre les moyens investis et la valeur produite.**

Il faut trouver le problème réel au niveau de la valeur recherchée, mener une étude approfondie, puis le résoudre concrètement. Le périmètre compte : les coûts et les solutions possibles changent selon l’échelle. Une bibliothèque destinée à tout Meituan, aux services financiers ou à une seule équipe peut viser des valeurs très différentes.

Pour un projet dont le potentiel de création de valeur est limité, il faut surveiller en permanence ce rapport. Les coûts de maintenance peuvent dépasser la valeur réelle sans qu’on s’en aperçoive, et cet écart finit par être corrigé à moyen ou long terme. Beaucoup ont récemment regretté l’arrêt de la maintenance de YAPI, un outil de simulation d’API offrant une meilleure expérience, alors que PAPI reste l’outil officiellement recommandé. Sans discuter des différences entre les deux outils dans l’organisation, je suppose que la maintenance de YAPI coûtait déjà plus que le supplément de confort apporté aux développeurs. Je n’ai pas de données pour le démontrer. Mais le fait que la majorité des projets n’aient pas choisi de migrer vers YAPI suggère que ce gain était faible, voire insuffisant pour compenser le coût de migration.

**Résoudre le problème au bon niveau d’abstraction.**

La nature du problème, ajoutée à son périmètre, définit le vrai problème. Une bibliothèque de composants est déjà une solution. À certaines échelles, elle n’est peut-être pas la meilleure. En montant dans l’abstraction, on peut distinguer grossièrement l’implémentation, la bibliothèque, le framework et le standard. La bibliothèque de composants se situe au deuxième niveau. C’est, selon moi, ce qui explique pourquoi MTD n’a pas abouti. Un projet communautaire appelé [A Global Design System](https://component-odyssey.com/articles) ambitionne de fournir des composants universels aux designers et développeurs du monde entier. Ce n’est pas réellement une bibliothèque de composants : c’est un système, mais pas non plus un design system comme Material Design. La question n’est pas forcément de savoir s’il réussira. L’intérêt est d’apprendre à explorer un problème posé à un haut niveau d’abstraction.

***

Les sujets techniques d’une équipe métier se divisent en deux grandes catégories. Certains visent les problèmes les plus pressants du moment. Il faut concentrer les moyens et les résoudre un par un, souvent sous forme de chantiers techniques dédiés. D’autres demandent une construction et une exploitation de longue durée : bibliothèques de composants, infrastructure d’ingénierie, etc. Ce travail est dense et continu ; il exige de la persévérance, mais manque d’un mode de fonctionnement adapté. Un tel mécanisme répondrait aussi, en partie, à la question essentielle de la vitalité de l’infrastructure.

À mesure que l’équipe grandit et que ses bases d’ingénierie se consolident, notre travail doit progressivement passer des campagnes ponctuelles aux mécanismes durables.

Notre infrastructure a franchi le passage de zéro à un. Nous devons maintenant apprendre à passer de un à l’infini. Le fonctionnement actuel reste plutôt fermé, et un système fermé dépend des individus. Les contributions spontanées sont rares ; on s’appuie sur les instructions hiérarchiques. Mon idée est de nous inspirer des projets open source mûrs pour construire un fonctionnement ouvert et durable, qui stimule la créativité de l’équipe.

Voici une première proposition : [Le mécanisme de groupe de travail — Working Group](https://km.sankuai.com/collabpage/2610619313). Elle reprend le concept de Working Group et introduit des mécanismes de RFC et de Membership. Je les ai adaptés à la taille de l’équipe pour équilibrer efficacité et ouverture. Vos idées et vos remarques sont les bienvenues.

***

Les récents ajustements de l’activité autour du grand livre comptable ont soulevé, côté frontend comme côté backend, la question de la pertinence de l’architecture. Celle-ci se reflète directement dans la qualité. C’est de là qu’est partie la refonte de la carte professionnelle. Voici quelques réflexions sur l’architecture métier du frontend.

1. L’architecture n’occupe pas la même place dans le frontend et le backend. Le frontend ne dispose pas encore d’un consensus suffisant sur la conception de l’architecture métier. On parle surtout du choix des frameworks et des chaînes d’outils. Une raison possible est que les défis architecturaux y sont moins fréquents. Beaucoup de projets n’atteindront jamais, pendant leur durée de vie, les limites créées par leurs choix d’architecture métier. Une structure générique issue d’un outil d’initialisation peut suffire jusqu’au plafond des besoins de l’activité.
2. Qu’est-ce qui relève d’une décision d’architecture, et qu’est-ce qui n’en relève pas ? L’architecture résulte d’échanges, d’analyses et de raisonnements ; elle ne se réduit pas à choisir des outils. Se concentrer sur l’arborescence des fichiers et la documentation livrées fait facilement oublier des notions importantes comme l’isolation et la réutilisation, la gestion de l’état ou l’inversion des dépendances. Ces aspects influent bien davantage sur la qualité réelle et sur la capacité à répondre aux besoins métier. L’architecture ECS dans le jeu vidéo, par exemple, résout un problème de maintenabilité propre à ce domaine.
3. Faut-il séparer les architectures frontend et backend, ou une seule équipe d’architecture générale suffit-elle ? La question est vaste. La structure du système reflète naturellement la façon dont les équipes communiquent ; je ne développerai pas ici la loi de Conway. Deux idées méritent néanmoins d’être mentionnées. D’abord, la conception globale de l’architecture intégrera progressivement le frontend. Nous sommes encore dans une situation où une langue minoritaire essaie de faire comprendre son travail à la langue dominante. La qualité et l’efficacité commencent à prendre en compte le frontend, même si l’examen de prévention des risques techniques ressemble encore à un examen d’informatique déconnecté du terrain. L’architecture suivra-t-elle bientôt ? Ensuite, frontend et backend peuvent apprendre l’un de l’autre. Le frontend peut tirer parti du DDD et d’autres approches du backend pour mieux comprendre les problèmes métier. Le backend peut apprendre les méthodes rapides de prototypage du frontend et sa façon de penser le composant comme un service.
4. Pour comprendre l’architecture frontend, [What is Frontend Architecture?](https://ducin.dev/what-is-frontend-architecture) est une lecture indispensable. Son auteur, Tomasz Ducin, mérite d’être suivi sur ce sujet.

***

Limites physiques, limites d’ingénierie, limites de l’expérience : ces distinctions peuvent aider à répondre à une question observée la semaine dernière. Quand nous parlons d’optimisation, de quel niveau parlons-nous, et à l’intérieur de quelles limites travaillons-nous ?

Comprendre les limites physiques permet de reconnaître les contraintes fondamentales, de garder les idées claires dans une innovation complexe et de mieux investir ses ressources. Des chercheurs amateurs travaillent encore sur le mouvement perpétuel, alors que Carnot a démontré dès le XIXe siècle l’existence d’un plafond théorique au rendement des machines thermiques. Cette recherche est donc vouée à l’échec. Beaucoup pensent aussi que le développement de l’IA résoudra tous les problèmes et remplacera les humains. Turing, au XXe siècle, permettait déjà de répondre clairement à cette idée. Parmi tous les problèmes du monde, seule une petite partie est mathématique. Une partie de ceux-ci a une solution ; une partie encore est calculable par une machine de Turing ; une autre peut être résolue par les ordinateurs actuels. Les problèmes que l’IA peut résoudre ne sont qu’un sous-ensemble de tout cela. Les limites physiques sont presque impossibles à renverser. Les limites mathématiques le sont absolument, car les mathématiques reposent strictement sur la logique, et non sur l’observation expérimentale.

Les limites d’ingénierie donnent une direction à la pratique et la rendent plus efficace. À l’intérieur de frontières physiques connues, on améliore les performances selon plusieurs dimensions pour trouver la meilleure solution d’ingénierie. Remplacer la lumière rouge par la lumière bleue dans les DVD, par exemple, exploite une longueur d’onde plus courte pour augmenter la capacité. Le passage de la 2G à la 6G n’a pas dépassé non plus la limite théorique de capacité d’un canal fixée par Shannon pour une bande passante et un rapport signal-bruit donnés. Chaque génération optimise le spectre, le codage et la modulation, l’architecture du réseau et d’autres paramètres. La loi de Moore continue de se manifester. Alors que nous approchons des limites physiques du silicium, les performances peuvent encore progresser par des techniques d’assemblage comme l’empilement 3D ou par des améliorations architecturales comme les SoC et le calcul hétérogène.

Les limites de l’expérience rappellent qu’il s’agit d’un jeu sans fin : l’expérience se construit au contact des frontières. Les besoins, les attentes et l’imagination des humains évoluent eux-mêmes sans cesse. Quel que soit le progrès technique, l’amélioration de l’expérience autour des moments de vérité (MOT) et des facteurs humains ne sera jamais terminée. Il n’existe donc pas de niveau de développement technologique à partir duquel telle optimisation deviendrait définitivement inutile.

***

J’ai lu un ouvrage dont le titre chinois se traduit par « La trésorerie est reine ». Le chiffre d’affaires relève de la vanité, le bénéfice du bon sens, mais la trésorerie est reine. C’est particulièrement vrai dans la période actuelle, où l’on se dispute un marché qui ne croît plus comme avant et où l’efficacité prime. La concurrence ne consiste plus seulement à augmenter sa taille ou à rechercher la croissance, mais à approfondir l’efficacité.

Le livre utilise la gestion du poids pour expliquer la logique de la priorité donnée à la trésorerie.

1. Utiliser une assiette plus petite. Être économe et maintenir les dépenses d’exploitation dans une enveloppe raisonnable de ressources limitées. La loi de Parkinson énonce que les besoins augmentent avec l’offre disponible. Cela explique pourquoi élargir les routes ne résout jamais durablement les embouteillages : davantage de conducteurs viennent toujours remplir les voies supplémentaires.
2. Manger les légumes avant les féculents. Réécrire la formule comptable classique « chiffre d’affaires − charges = bénéfice » sous la forme « chiffre d’affaires − bénéfice = charges ». Mettre d’abord le bénéfice de côté, puis décider comment dépenser le reste. Cette méthode s’appuie sur l’effet de primauté.
3. Supprimer la tentation et cacher ce qu’il ne faut pas manger. Placer le bénéfice réservé, la rémunération des actionnaires et les sommes destinées aux impôts dans un compte séparé, de préférence peu facile d’accès.
4. Manger moins, mais plus souvent, pour lisser les variations. Consulter deux fois par mois les soldes bancaires et évaluer l’activité à partir de la trésorerie disponible : une comptabilité très simple fondée sur les soldes bancaires.

Cela me fait penser à la refonte du réveil dans la gestion du sommeil d’Apple. Je ne sais plus dans quelle version d’iOS elle est apparue. Habituellement, régler un réveil consiste à choisir l’heure à laquelle on veut se lever. L’interface du réveil sommeil d’Apple commence par la durée de sommeil souhaitée, puis ajuste les heures de coucher et de lever en fonction de cet objectif. C’est la traduction d’un changement de conception dans le produit. La priorité donnée au bénéfice devrait trouver un équivalent dans notre petit outil de comptabilité.

***

Le déploiement élargi du nouveau module de paiement en panneau partiellement superposé, après sa refonte, est longtemps resté en suspens. Nous arrivons maintenant au moment de l’affrontement direct. Face à un problème qui use la détermination de l’équipe depuis presque un an, j’ai deux options : le résoudre moi-même, ou emmener une équipe le résoudre. Du point de vue des attentes envers un responsable, je pense que l’organisation attend la seconde. Pour conduire cette résolution collective, je dois clarifier, dans cet ordre, l’état d’esprit, les personnes, l’objectif et la stratégie. Le premier problème est de reconstruire notre cadre mental. Face au même défi, il faut adopter une nouvelle attitude, une nouvelle disposition, et la transmettre à l’équipe.

Je viens justement de découvrir *Reframe Your Brain*. Le recadrage consiste à modifier volontairement le cadre d’interprétation et à faire de la réalité un nouveau récit plus utile pour soi. C’est une reprogrammation du cerveau, comparable à celle d’une puce FPGA. La psychologie propose un concept proche, la restructuration cognitive. Face à une situation, une expérience, une pensée ou une émotion, on identifie sa manière de l’interpréter, on la met en question et on en adopte une autre. On peut, par exemple, voir une difficulté comme un défi, le défi comme une aventure, et l’aventure comme un jeu.

Le livre présente de nombreuses techniques. L’une des plus importantes consiste à passer d’une posture passive à une posture active. Jerry m’avait dit quelque chose de semblable il y a quelques années : passer de « ce qu’on me demande de faire » à « ce que je veux faire ». Un pas de plus consiste à passer de ce que je veux faire (*want to*) à ce que je décide de faire (*decide to*). Décider est un acte pleinement actif, un engagement envers soi-même. L’envie peut disparaître si les conditions changent. Une décision, en revanche, pousse à chercher tous les moyens d’aboutir, sans laisser quoi que ce soit nous arrêter.

Ce recadrage mental serait-il une consolation illusoire, une sorte de méthode consistant à se déclarer vainqueur dans sa tête ? La distinction ressemble à celle entre le marketing et la vente pyramidale : en surface, les deux vendent quelque chose ; au fond, il faut regarder qui produit une valeur finale. L’intérêt du nouveau récit n’est pas tant de savoir s’il est vrai que s’il fonctionne. Certaines formulations peuvent être inexactes, mais utiles pour soi.

***

La semaine dernière, lors d’une intégration au module de paiement, les limites du conteneur de la plateforme ont forcé une équipe métier à changer de type de produit de paiement, au prix de nombreux échanges. Nous en avons profité pour revoir les effets des changements de conteneur sur l’activité au fil du temps. En reconstituant la chronologie, les problèmes essentiels sont apparus. Comme le dit la signature de tiange, il faut « éviter autant que possible, dans la standardisation, de rendre les objets abstraits et vagues, de simplifier les règles à l’excès et de mécaniser les actions ». Le premier problème me paraît le plus marqué. Les services financiers sont peut-être le plus gros client des conteneurs standardisés. Pourtant, dans les nombreuses décisions techniques passées, je n’ai jamais vu d’initiative pour venir interroger nos équipes de terrain. Une conception pragmatique se construit en allant au cœur du métier.

Les produits techniques ou les standards imposés par une plateforme couvrent généralement bien 90 % des situations. Le plus difficile, c’est que les 10 % restants, les cas rares, résultent souvent de ce que les concepteurs « ne savaient pas ». Les équipes métier doivent alors combler ces défauts par une dégradation de l’expérience ou par des coûts supplémentaires. Ce sont précisément ces derniers 10 % qui déterminent notre jugement sur le travail de la plateforme. Dans un trajet de cent lieues, les quatre-vingt-dix premières ne représentent que la moitié de l’effort. Cela rappelle la théorie Six Sigma en contrôle qualité : pour obtenir un résultat de haut niveau, le processus doit atteindre une capacité de six écarts-types. Il faut se concentrer sur les derniers défauts de conception, les plus difficiles à percevoir. L’attention portée aux cas limites et leur résolution apportent les gains décisifs de qualité ou d’avantage concurrentiel.

C’est une leçon à retenir, et un point auquel nous devons être particulièrement attentifs dans nos propres travaux de standardisation et de gouvernance.