Stress positif. Oui. Lisse. Ouais. D’accord, autre chose? Quelqu’un veut utiliser son larynx maintenant ? Pointe! D’accord.

Dernière chance. Dernier appel pour le flow.

Clarté! Oui. Flow. Vous avez dit lueur ou flux? D’accord. Bon, alors, pour les enfants de l’automne, les enfants d’automne et les enfants de l’hiver. Quels mots vous sont venus à l’esprit ?

Attendre. Frustration! Encore du stress. D’accord, ici?

Tension.

Pardon?

Obstacles. Oui, des bloqueurs. Ouais. Hein? Multi-charge. Charge mentale. Ah oui. D’accord, oui, c’est vrai. Oui. Autre chose du,

Travail en solo. Oh, d’accord, c’est l’absence de flux. D’accord. Certaines personnes pourraient ne pas être d’accord. D’accord. Hiérarchie. D’accord, intéressant. Ça devient de plus en plus intéressant. D’accord, donc, j’entends vraiment des mots surgir, c’est à propos du flow personnel, n’est-ce pas ? Et d’autres portent sur, vous savez, le flux collectif et, et, et ainsi de suite. Pour certaines personnes, même le travail en solo est un flow. D’autres choses, pas tant que ça. Alors, laissez-moi partager, personnellement, vous savez, quand je suis dans le flow, je sens que, d’accord, il y a quelques mots qui surgissent, quand je suis dans le flow, je sens une connexion. N’est-ce pas ? Connexion à moi-même et à ce que je fais. D’accord? Donc, et puis je suis aussi en mouvement, je ne suis pas bloqué, je ne stagne pas. Et, Quoi d’autre, euh, je pense aussi qu’il y a une sorte de légèreté quand je suis dans le flow. N’est-ce pas ? Je suis léger, je suis même, il y a même une sorte de douceur. Comme si je ne gérais pas ou, ou, euh, ne contrôlais pas les résultats. Parce qu’habituellement, gérer et contrôler, c’est ce qui me tire, vous savez, Je dois vous montrer les diapositives, n’est-ce pas ?

Euh, ça m’a sorti du flow comme, comme un tuyau d’arrosage tordu, un tuyau de jardin, n’est-ce pas ? Donc, c’était un peu, euh, un, euh, ce n’est pas un brise-glace, c’est quelque chose qui s’appelle la connexion avant le contenu, merci d’avoir piqué cette grenouille avec moi. Et en passant à la première partie, où le flow rencontre-t-il l’architecture ? Eh bien, une suggestion est que c’est le cas, comme ils le font dans le 11e principe agile. Qui dit, les meilleures architectures, conceptions et exigences émergent des équipes auto-organisées. Et la logique est en fait assez simple, n’est-ce pas ? Quand vous êtes impliqué, vous comprenez ce qui a été conçu, alors vous êtes plus motivé, plus autonome et plus engagé, n’est-ce pas ? Alors, mais vraiment, levons la main, qui a vu en pratique une architecture véritablement émergente dans son expérience vécue ? Ouais? Oui. Génial. Et qui a surtout vu une architecture de front ? Plus de mains se lèvent. Qui pense que ça dépend ?

Mm, c’est la majorité, je suppose que beaucoup d’entre vous sont architectes ou consultants. Oui? D’accord. Donc, de toute façon. Alors, en ce moment, une autre invitation, activez votre imagination et imaginez une sorte de bascule, si je dis bascule, vous savez ce que je veux dire, la bascule dans une aire de jeux pour enfants. Et imaginez que vous avez une architecture d’avant-garde de ce côté, et c’est, c’est comme des décisions difficiles à changer, n’est-ce pas ? Et de ce côté, imaginons une architecture véritablement émergente, c’est là que le principe Agile 11 veut que nous soyons, n’est-ce pas ? C’est-à-dire, vous savez, quand le logiciel devient plus complexe, euh, que ce soit un projet neuf (Greenfield) ou existant (Brownfield), notre organisation devient également plus complexe, et la coordination devient de plus en plus difficile. Et donc, la complexité fait en sorte que cette bascule pivote davantage vers le côté ascendant, vers le côté frontal, n’est-ce pas ? Et, euh, Jean Kim et Stephen Spear, euh, ont saisi cette tension dans leur livre de 2024, apprendre des organisations gagnantes. Et dans ce livre, ils ont posé cette question: comment Jean et C déplacent-ils un canapé dans une organisation à grande échelle ? Cela peut sembler une tâche très simple. Mais déplacer un canapé nécessite en fait un certain design, n’est-ce pas ? Il faut trouver le centre de gravité, et si vous avez cet escalier étroit et tortueux, il faut déterminer, vous savez, quel côté passe en premier, à quel angle le faire pivoter, qui avance et qui recule, et ce genre de choses, n’est-ce pas ? Mais bien d’autres choses peuvent se mettre en travers de leur chemin, n’est-ce pas ? Vous savez, ils, ils devront peut-être obtenir, euh, la pièce où va le canapé, elle n’est peut-être pas encore prête, elle doit être débarrassée des meubles. Et c’est une autre équipe, et il pourrait, il faut le peindre. C’est une troisième équipe qui, euh, qui travaille sur différentes tâches. Et peut-être que c’est toute cette information contextuelle, ils doivent la faire filtrer par cinq personnes différentes, euh, n’est-ce pas ? Donc, ces personnes doivent coordonner cette tâche très élémentaire qui leur est propre, qui a déplacé un canapé dans un graphe de dépendances contextuelles, euh, de sorte que les choses puissent, vous savez, être coordonnées dans les Scrums de Scrums et la planification PI et ce genre de choses. Et peut-être que leurs architectes veulent qu’ils décomposent ce canapé en petits microservices, déplaçant une partie à la fois, ou pire encore, peut-être qu’ils n’ont aucune idée de la raison pour laquelle ils déplacent même ce canapé. C’est le pire, n’est-ce pas ? Donc, une fois, j’ai entendu un développeur se plaindre en ligne, vous savez, l’agilité venait de. Vraiment étouffe mon autonomie et me contraint, euh, dans ce moule d’un ouvrier d’usine obéissant et micro-géré. Donc, en parlant d’usine, c’est en fait de là que le concept de flux, vous savez, est né, n’est-ce pas ? Euh, c’est là que, vous savez, euh, la pensée Lean, euh, la réduction des déchets, euh, la limite avec le processus d’entrée vers la sortie de manière prévisible, reproductible, et ce genre de choses, c’est beau quand ce que vous déplacez est matériel. Dans le développement logiciel, nous ne déplaçons pas de matériel, nous déplaçons des informations. Et le déroulement de notre travail dépend du déroulement de la compréhension. Et donc, vous savez, dans nos chaînes de valeur agiles, dans nos pipelines de CD, nos pipelines de livraison, nous nous efforçons vraiment de déplacer ces informations vers les points de décision et les points d’action réels pour que les humains puissent agir. Mais les humains ont cette chose appelée rationalité limitée, nommée par Herbert Simon en 1955. Et cela signifie, vous savez, qu’en tant qu’humains, nous ne pouvons pas charger toute l’information de l’ensemble du système dans nos cerveaux en une seule fois. Et même si nous le pouvions, cet ordinateur qui est le nôtre, il ne fonctionne pas, vous savez, il ne calcule pas parfaitement, n’est-ce pas ? Sous la pression du temps, il prendra des raccourcis et il remplira les blancs avec des préjugés. D’accord? Sous la pression du temps, si certains d’entre vous ont déjà fait, vous savez, du codage avec, euh, des agents IA. Remarquez-vous une différence lorsque vous révisez un code génétique tôt le matin et tard l’après-midi, lorsque vous êtes fatigué ? Vous auriez tendance à penser, oh, c’est suffisant. Vous savez que non. Vous savez, c’est ainsi que fonctionne la rationalité limitée. Donc, Cet ordinateur que nous possédons ne fonctionne pas, vous savez, il ne calcule pas parfaitement, n’est-ce pas? Sous la pression du temps, il prendra des raccourcis et comblera les lacunes avec des biais. N’est-ce pas? Sous la pression du temps, si certains d’entre vous ont déjà codé, vous savez, avec des agents d’IA, Remarquez-vous la différence lorsque vous examinez un code agentique tôt le matin et tard l’après-midi? Quand vous êtes fatigué l’après-midi? Vous auriez tendance à dire, c’est suffisant et vous savez, ça ne l’est pas. Vous savez, c’est ainsi que fonctionne la loi de Conway sur l’émotivité. Donc, Martin Fowler a dit un jour quelque chose qui a fondamentalement changé ma façon de penser l’architecture. L’architecture est une construction sociale, a-t-il dit.

Il s’agit de la compréhension partagée des choses importantes. N’est-ce pas? Donc, ce qui est important ici est vraiment de faire circuler cette compréhension partagée

vers les points de décision, non pas en déversant des informations, mais en facilitant d’une manière ou d’une autre la compréhension contextuelle de la situation globale. Donc, voici à nouveau cette bascule, n’est-ce pas? Visualisée. D’un côté, nous avons l’architecture initiale, les décisions difficiles à prendre. Et c’est la discipline agile. Et de l’autre côté, nous avons l’architecture émergente, c’est le principe 11, c’est, c’est la vraie agilité. N’est-ce pas? Et pour maintenir la balançoire en mouvement de manière fluide, nous devons cultiver l’architecture en tant que pratique sociale pour nous assurer que nous avons, nous pouvons faire circuler la compréhension partagée

vers les points de décision réels. Donc, de ce point de vue, l’architecture est une balançoire socio-technique. N’est-ce pas? Alors, passons à la partie suivante. Êtes-vous toujours là? Personne ne s’endort? D’accord, super, je vérifie juste. D’accord, donc, dans cette, dans cette prochaine partie, euh, un petit avertissement, parce qu’il y aura quelques grenouilles, je suggère que nous touchions ce qui pourrait sembler un peu visqueux ou juste un peu confortable au toucher. Donc, euh, voyons comment ça marche. Donc, je pense que nous connaissons tous la loi de Conway, n’est-ce pas? Donc, en gros, la conception logicielle suit la structure de communication de l’organisation qui construit le logiciel. Donc nous avons trois, si vous avez trois équipes, alors vous vous retrouvez probablement avec trois parties d’architecture avec leurs propres sous-systèmes, composants, etcetera, etcetera. Et maintenant, récemment, certaines entreprises ont essayé quelque chose appelé la manœuvre inverse de Conway. C’est-à-dire, vous savez, concevons l’architecture logicielle en amont et remodelons l’organisation pour qu’elle corresponde à cela, en faisant en sorte que l’architecture logicielle s’intègre à l’organisation. Et maintenant, dans cet exemple particulier, nous voulons des tranches verticales et nous voulons des services indépendants et nous voulons des plateformes réutilisables. Et donc nous utilisons les topologies d’équipe pour concevoir, attention ça devient trop bruyant. Euh, pour concevoir des équipes alignées sur les flux soutenues par des équipes de plateforme. Donc, en pratique, quelque chose d’intéressant se produit dans certaines entreprises. Les plateformes sont parfois contournées, généralement parce que, vous savez, ces plateformes n’ont pas une bonne expérience développeur. Et donc la logique est dupliquée de toute façon, elle devient incohérente et l’intégration devient compliquée. Ainsi, l’architecture que nous voulions au moment de la conception et l’architecture que nous avons observée à l’exécution semblent diverger. Et pourquoi cela se produit-il? Une explication est que l’architecture tend, vous savez, à refléter la culture de manière beaucoup plus fiable que la culture n’obéira à l’architecture. Fondamentalement, c’est aussi parce que, vous savez, les organisations et les systèmes logiciels sont des types de systèmes complètement différents. Une organisation est un système vivant qui se recrée à travers ce processus appelé autopoïèse. Et c’est un mot grec, auto signifie soi-même. Et poiesis signifie création. Donc une forêt tropicale est autopoiétique, n’est-ce pas? Elle crée, elle, elle produit des arbres, sol, cycles d’humidité, et surtout, elle crée les conditions qui lui permettent de rester une forêt tropicale.

En revanche, une voiture comme une Ferrari est créée par un processus appelé allopoïèse. Allo signifie autre.

Donc une Ferrari est créée par quelque chose d’autre qu’elle-même. Il en va de même pour un microservice.

Ainsi, les organisations et les équipes continuent de reproduire les mêmes schémas de communication, les mêmes habitudes de décision et même leurs modèles mentaux ou récits, n’est-ce pas? Encore et encore. Mais les organisations logicielles sont aussi une combinaison de ces deux types de systèmes. Nous avons ces, nous avons notre système logiciel qui sont des systèmes techniques et ils sont allopoïétiques, ce qui signifie qu’ils ne peuvent pas se générer eux-mêmes, enfin pas encore du moins. Euh, ils sont intégrés au sein des organisations et des équipes qui les créent. Et donc cet enracinement implique fondamentalement que la complexité sociale englobe la complication technique. Et donc dans cet exemple précédent, inverse Conway, euh, ce que nous voyons se produire, c’est qu’une usine à fonctionnalités axée sur le backlog est réorganisée en équipes de produit, de tranches virtuelles de produit et en organisation. Mais ensuite les structures changent, mais les habitudes organisationnelles n’ont pas changé. Vous savez, en gros ce que la raison pour laquelle je le savais, c’est parce que j’y étais. Ce qui se passe, c’est que les chefs de produit, de projet

à l’époque étaient essentiellement réaffectés aux propriétaires de produits et les DBA devenaient des équipes de produit. Mais, vous savez, produit signifie toujours tickets priorisés et valeur signifie toujours débit et performance signifie toujours vitesse de livraison.

N’est-ce pas? Donc, euh, fondamentalement, pour l’autopoïèse, cette organisation continuera à reproduire une pensée cloisonnée et une optimisation locale, euh, locale, et le récit de l’autonomie peut même, vous savez, conduire à plus de fragmentation. Donc, voici la grenouille à piquer ensuite. C’est-à-dire que la loi de Conway est une voie à sens unique. Point. Fin de l’histoire. Donc, essayer d’intégrer un système humain, vous savez, à l’intérieur d’une architecture cible technique, c’est comme essayer de contenir une forêt tropicale à l’intérieur d’une Ferrari. Un système vivant ne peut être contenu par une structure mécaniste. D’accord. Donc, si les organisations continuent simplement à se reproduire pour l’autopoïèse, cela signifie-t-il que rien ne peut changer? Cela signifie-t-il que nous sommes simplement tous piégés à l’intérieur de systèmes? Et c’est là que la conversation sur l’autopoïèse peut devenir quelque peu inconfortable. Euh, parce que, euh, ça bascule d’une certaine manière dans le fatalisme, n’est-ce pas? Donc nous connaissons tous ces histoires. Oh, c’est le système. C’est la direction.

Ces gens, ils s’en fichent. Ils doivent changer.

Moi? Oui, le système est si grand, je suis si petite, que puis-je faire? C’est au-dessus de mon niveau de salaire de toute façon. N’est-ce pas? Donc, et ceux qui externalisent, n’est-ce pas? Euh, nous n’avons pas de rôles clairs. Pas les bonnes compétences.

Et, vous savez, ah, rien ne va changer, c’est, euh, ça a toujours été comme ça. Les lieux de travail ne sont jamais sûrs. Et puis, vous savez, quand nos interventions préférées comme le DDD, comme les topologies d’équipe, ou les cartes de Wardley, ou peu importe, lean, agile, etc., ne fonctionnent pas, notre décharge numéro un, vous savez, semble être de rejeter la faute sur la culture. La culture dévore la stratégie. Et tout le reste d’ailleurs, pour le petit déjeuner. N’est-ce pas? Ce n’est pas de notre faute. N’est-ce pas? Donc c’est toute la culture. Euh, bien. Alors Peter Block nous invite à, euh, fondamentalement renverser la question. Au lieu de demander, qu’est-ce qui ne va pas avec le système? Qu’est-ce qui ne va pas avec ces gens? Vous savez, je peux dire, est-ce que je veux être la cause ou l’effet? Une victime du système ou participer à la création de quelque chose de nouveau?

Euh, et donc parce que si, si les organisations sont recréées par les interactions dans le système, alors chaque interaction dont je fais personnellement partie a le potentiel soit de maintenir le système tel quel, soit de le changer. Que cela nous plaise ou non, nous avons un rôle inévitable

dans l’autopoïèse en faisant partie du système. Et donc c’est une conversation, une conversation de propriété que nous pouvons avoir avec nous-mêmes et les uns avec les autres. Alors Peter Block propose un ensemble de questions, inconfortables, inopportunes, mais importantes. L’une d’elles est : quelle est ma contribution

à la chose même dont je me plains? Quelle est ma contribution à cette chose même qui me frustre?

Et donc, vous savez, euh, je vous demande de refaire ça. Maintenant, rappelez-vous cette fois où vous, où le travail était vraiment, vraiment fluide pour vous. Comme si vous ne faisiez pas seulement le travail, ce n’est pas parce que le travail doit être fait, mais c’est comme si vous étiez créatif et connecté et que le travail vous poussait en avant. Alors, rappelez-vous cette fois où rien n’a coulé pour vous, n’est-ce pas? Vous êtes comme une tâche qui est allouée et vous êtes comme, vous savez, vous êtes comme une ressource, vous savez, qui passe simplement par le pipeline vers le tableau de bord de quelqu’un d’autre. Donc, cette question de la cause ou de l’effet, concrètement, devient : est-ce que je suis entraîné, ou est-ce que j’entraîne quelque chose dont je veux faire partie?

Et donc, cette question pointe en fait vers deux états qui sont liés à deux types de flux dans notre développement logiciel. L’un est le flux de livraison. C’est un flux allopoïétique, où la valeur est créée dans les nœuds, n’est-ce pas? Dans chacune des étapes du sous-processus. N’est-ce pas? Et ici, nous supposons que l’information, immatérielle d’ailleurs, peut être objectivement traitée, stockée et, euh, transférée d’un nœud à l’autre, d’un composant à l’autre et d’une équipe à une autre équipe. Si ce que vous faites circuler est vraiment matériel, c’est beau, n’est-ce pas? Et une autre chose est que nous voulons vraiment minimiser les lignes, nous voulons minimiser les interactions, vous savez, les lignes entre ces nœuds, parce que c’est là que se trouve le gaspillage, c’est là que se trouve le temps d’attente. Et nous ne voulons pas ça. D’accord. L’autre type de flux est un flux génératif, et c’est un flux autopoiétique, où la valeur réside dans les nœuds et dans les lignes, dans les connexions. Oui? Et donc Jake Bloom le décrit de cette façon, ce n’est pas que j’ajoute de la valeur dans le processus de création d’informations et que je la transmets en aval à quelqu’un d’autre. C’est dans le fait de remettre ma chose à quelqu’un d’autre que se crée l’information. C’est donc J Loom.

Et donc ici, les lignes sont l’endroit où la rencontre réelle se produit, n’est-ce pas? C’est et les interactions ajoutent de la valeur, elles ne sont pas du gaspillage. Les transferts doivent être conçus en douceur. C’est le flux génératif.

Et donc maintenant nous revoyons cette bascule avec, vous savez, le flux de livraison de ce côté, et c’est le débit stable, c’est notre pratique lean, c’est notre pipeline CICD prévisible, ce sont nos métriques de porte mesurables, c’est ce que n’importe quel de nos tableaux de bord peut voir, n’est-ce pas? Et puis d’un autre côté, nous avons le flux général, génératif, n’est-ce pas? C’est le relationnel, le conversationnel, parfois le relationnel, euh, et c’est, vous savez, c’est, c’est l’énergie que nous avons. C’est l’énergie dans la pièce quand nous collaborons, quand nous faisons de la modélisation collaborative. Et c’est, c’est en quelque sorte le sentiment que nous tirons ensemble vers quelque chose de plus grand. Et dans le flux de livraison, nous déplaçons le travail. Et dans le flux général, génératif, nous déplaçons le sens. Et pour architecturer le flux, nous avons besoin d’une architecture sociotechnique. La chose dont nous devons prendre soin, c’est toujours la compréhension partagée des choses importantes afin que nous puissions faire en sorte que les gens se soucient, euh, de leur énergie et de leur créativité pour qu’elles s’écoulent parallèlement à la production et au résultat. Et c’est la conception socio-technique. nous collaborons, nous utilisons un modèle collaboratif. Et c’est un peu le sentiment que nous travaillons ensemble pour des choses formidables. Et dans le flux de livraison, nous déplaçons le travail et dans le flux génératif, nous déplaçons le sens. Et pour concevoir l’architecture pour le flux, nous avons besoin d’une architecture socio-technique. Ce dont nous devons encore nous occuper, c’est cette compréhension partagée des choses importantes. afin que nous puissions avoir le soin des gens, euh, leur énergie et leur créativité pour s’écouler aux côtés des extrants et des résultats. Encore une fois, c’est de la conception socio-technique. Euh, et donc, la prochaine chose est de poser une question sur l’architecture socio-technique. Donc, quand nous parlons d’architecture technique, d’architecture logicielle, nous travaillons souvent avec ce qu’on appelle un attribut de qualité pour les caractéristiques architecturales. Ces éléments, comme ces capacités, sont les conditions du flux de livraison, n’est-ce pas ? Et le système socio-technique autour du logiciel, il a aussi ses propres attributs de qualité, comme la connectivité commerciale, l’appartenance, la vivacité, la liberté, et l’intégrité et l’ouverture, n’est-ce pas ? Ce sont les conditions pour le flux génératif. N’est-ce pas ? C’est un peu comme

l’architecture socio-technique. Vous voyez la différence et il y a un paradoxe à naviguer. Parce que quand nous regardons, encore une fois, l’architecture technique, l’accent est mis sur le découplage, sur le découplage, n’est-ce pas ? Modularité, séparation des préoccupations. C’est presque une déclaration d’indépendance. Et maintenant, du côté social, ce que nous mettons en avant, c’est la connexion, le contexte partagé, le terrain d’entente. N’est-ce pas ? Ce sont en quelque sorte une déclaration d’interdépendance. Et donc le paradoxe est que parfois, pour bien découpler le logiciel, nous devons mieux connecter les gens, et non pas mieux les diviser pour régner.

Donc, c’est en fait un paradoxe assez difficile, et je pense que cette métaphore du bac à sable m’a aidé à naviguer, euh, euh, la distinction dans mon travail. Et donc, pour concevoir l’architecture pour le flux de livraison, nous avons souvent besoin de ce côté gauche, qui est l’alignement délibéré, qui est généralement un effort centralisé en amont, pour concevoir l’architecture pour le flux génératif. Ce dont nous avons souvent besoin, c’est d’une émergence cohérente.

L’alignement me regarde du côté gauche, et la cohérence a l’air vivante, n’est-ce pas ?

Et le le point idéal entre ces deux, c’est là où, vous savez, c’est là où je vois la frontière de mon travail. Et c’est très cher à mon cœur. Et donc, vous savez, si vous si nous n’avons que l’alignement, nous n’avons que, vous savez, des réunions en diamant, une stratégie et tout structuré en arbre. Nous amenons les gens à regarder avec un grand intérêt intellectuel, euh, et ils peuvent suivre les règles. Mais si nous avons aussi, vous savez, si nous avons aussi de la cohérence, alors nous pouvons amener les enfants dans le bac à sable et jouer et s’engager. C’est ça le point idéal. Alors, euh, donc si j’ai fait tant de conférences sur l’architecture socio-technique. Et donc, Je pense que si je prétends être un architecte socio-technique, je dois mettre une définition sur la table. Et il est grand temps. C’est trop long. C’est la définition abrégée (TLDR). Euh, cette image dit exactement la même chose. Et donc, l’architecture socio-technique est la conception intentionnelle des conditions et l’échafaudage de l’interaction du moment. Qu’est-ce que nous concevons et échafaudons ?

Émergence délibérée. Et ce que cela signifie, c’est de conjointement

optimiser le bien-être des systèmes logiciels et le bien-être des systèmes sociaux afin que la stabilité et le changement puissent coexister en co-évolution avec l’environnement, car nous parlons de systèmes ouverts.

D’accord. Vous me suivez toujours ? D’accord, super. C’est beaucoup de choses complexes, beaucoup de matière à réflexion, n’est-ce pas ? Alors, passons brièvement au mode narration. C’est ma propre histoire de déménagement du canapé. Quand j’étais, euh, quand j’étais l’architecte principal d’une très grande initiative produit dans une institution financière nordique il y a quelques années. Et cette initiative produit, cette organisation a été réorganisée en utilisant le modèle, euh, Spotify. Et, euh, vous savez, chaque, euh, et cela concerne 27 escouades et cinq tribus, je crois. Et chaque flux de travail de cette initiative impliquait une chaîne d’appels API profondément imbriquée et une cartographie continue des événements. Il y en a sept, 27 d’entre eux, n’est-ce pas ? Donc, euh, l’effort de coordination et de création de ce contexte partagé, qui était en partie mon travail en tant qu’architecte principal, était énorme. Euh, aucun canapé ne peut être déplacé comme une action indépendante dans cette initiative. Mais cette histoire a également servi de toile de fond pour que je comprenne les deux types de bloqueurs socio-techniques du flux.

Donc, l’un est la délamination. C’est le terme de J. Bloom. Donc, la délamination, comme vous pouvez le voir sur l’image, vous savez, c’est un peu comme le tuyau d’eau qui est plié de différentes manières, n’est-ce pas ? Les bloqueurs, euh, ici le flux vertical est, est coupé en fait, n’est-ce pas ? Donc, euh, et donc nous avons la couche stratégique et la couche d’exécution déconnectées l’une de l’autre. Les personnes qui fixent les directions et les personnes qui effectuent le travail ne sont plus dans la même conversation. Et toutes les couches, vous savez, y compris la direction intermédiaire, elles continuent de bouger, mais elles ne bougent plus ensemble. Et donc, dans mon histoire de déménagement de canapé avec ces 27 équipes, c’est ce que nous essayons d’atténuer, n’est-ce pas ? Alors, ne pas délaminer, faire quelque chose à ce sujet. L’autre obstacle au flux, selon les termes de J.K., est appelé désintégration. C’est là que le flux horizontal est coupé, n’est-ce pas ? C’est lorsque les équipes sont déconnectées les unes des autres, l’exécution est fragmentée, nous avons une optimisation locale, nous avons une pensée en silo. Chacune de ces 27 équipes a ses propres OKR. Et ils doivent gérer leur, vous savez, prioriser leurs propres affaires en parallèle avec le, le, le, de l’initiative produit, n’est-ce pas ? Donc, c’est cette intégration.

Et donc, un antidote à la délamination est est est ceci, n’est-ce pas ? Donc, en gros, ce que nous devons faire, c’est rétablir le flux vertical, euh, et échafauder la conversation afin que les personnes qui travaillent sur cette tâche, ici, puissent comprendre comment cette tâche peut compléter l’expérience, valider l’hypothèse, soutenir la stratégie et réaliser le besoin de l’utilisateur. Cette chaîne, de la tâche au besoin de l’utilisateur, c’est ce que J appelle le retour à la case départ. Et c’est ce qui était mon modèle mental à l’époque, lorsque nous faisions face à la délamination dans cette initiative de produit. Et et la raison, donc j’ai corrélé, la raison pour laquelle cela fonctionne est ce que Danny a dit, n’est-ce pas ? La joie au travail vient de la compréhension de pourquoi votre travail est important. Non pas du travail lui-même, mais de la différence que votre travail fait dans le rythme d’une autre personne, n’est-ce pas ? Donc, en gros, c’est l’étoile polaire, et si vous pensez à toute la confusion que l’IA nous apporte, nous avons toujours besoin de quelque chose comme une étoile polaire centrée sur l’humain, en tant qu’humains. Nous y reviendrons plus tard. Un antidote à cette intégration pourrait être cette chose appelée le recomptage. Il m’a fallu plusieurs itérations moi-même pour comprendre ce qu’est vraiment cette chose. C’est aussi de J Bloom. Cela s’appelle les trois économies.

Alors, à gauche, nous connaissons tous cela, n’est-ce pas ? Nous avons l’économie de la vitesse. La question qui se pose ici est la suivante : comment nous différencions-nous en tant qu’entreprise, comment nous faisons-nous concurrence sur le marché ? Pas de différenciation, tu vas mourir. Et de l’autre côté, nous avons l’économie d’échelle, n’est-ce pas ? Les économies d’échelle. Et la question qui importe ici est la suivante : comment standardisons-nous, réduisons-nous les coûts, réduisons-nous, vous savez, limitons-nous avec, euh, réduisons-nous le gaspillage et augmentons-nous la réutilisation, n’est-ce pas ? Ce genre de question. Au milieu, nous avons l’économie de la portée.

Et ici, la question est : comment standardiser pour se différencier pour le bien commun ?

Et donc, la capacité de penser en économie d’échelle et de recombinaison, ce n’est pas quelque chose qui peut être imposé, enseigné, euh, ou spécifié.

Il ne peut être atteint qu’en concevant l’architecture pour le flux génératif afin que les équipes de personnes puissent choisir de prendre en charge.

Vous savez, optimiser pour le bien commun, pas leurs OKR individuels, n’est-ce pas ? Pas ceux-là, vous savez, ces 27 équipes, comment peuvent-elles sortir de leurs propres feuilles de route et commencer à voir ce qui est bon, ce qui est bon au niveau commun, oui ? Donc, en gros, cette capacité de flux génératif est ce qui peut transformer la tragédie des biens communs à la joie des biens communs. Et c’est pourquoi on l’appelle le recombiner.

Et la capacité de recombinaison dépend aussi de la question de savoir si l’architecture socio-technique peut devenir l’affaire de tous. Et ce que l’on entend par là, c’est que l’architecture est un ensemble de compétences qui doivent être adoptées par, vous savez, les ingénieurs logiciels, les ingénieurs d’exploitation, les chefs de produit et les coachs agiles. Toutes ces personnes doivent comprendre les conséquences pour que l’architecture puisse émerger.

Ne pas venir d’en haut. Et l’architecture concerne les politiques et les interactions, et non la technologie. Et cela me rappelle ce que Jim White a dit à propos du développement logiciel : c’est un exercice de relations humaines.

D’accord. Ce sont les théories sèches, sèches, sèches.

J’espère que vous êtes toujours éveillé.

Et maintenant, faisons un rapide point. Alors, au compte de trois, je, euh, pouvez-vous me donner un pouce levé pour ‘Je vais très bien’ ? Et au compte de trois, pas maintenant, d’accord ? Alors, un pouce sur le côté est un, ou n’importe quel angle, je m’accroche quelque part, n’est-ce pas ? Et les pouces vers le bas, où est la porte ? Je dois partir maintenant. C’est ça, n’est-ce pas ? Alors, un, deux,

trois.

Oh, waouh. D’accord. Merci pour votre honnêteté, et je vois la plupart des pouces levés, je suis en fait assez surpris.

Euh, mais il y a, d’accord, des signaux de risque et et et merci de partager cela avec moi.

Je suis presque tiré d’affaire. Mais voici, euh, la dernière chose. Ceci est une expérience socio-technique, euh, que nous avons menée l’année dernière dans une compagnie d’assurance. C’est toujours un travail en cours, et cette entreprise ne veut pas que son vrai nom soit divulgué. Nous les appelons donc Flux Care. Donc, l’année dernière, vers septembre, Flux Care, euh, a organisé un séminaire de plusieurs jours pour, euh, vous savez, réimaginer leur future IA. Beaucoup d’entreprises l’ont fait. N’est-ce pas ? Donc, euh, la question qu’ils ont posée sur la table est fondamentalement, vous savez, comment intégrer une architecture agencielle dans leur flux de travail de domaine principal, qui est, euh, dans ce cas particulier, le flux de travail de gestion des sinistres d’assurance. Et donc, Je suppose que tout le monde a une intuition sur le fonctionnement des réclamations d’assurance. Lorsque, par exemple, le pare-brise de votre voiture est endommagé, alors une adresse le traversera. Cela pourrait potentiellement impliquer de nombreux acteurs et de nombreuses étapes. Et imaginez ajouter, vous savez, des agents d’IA, des agents à ce flux de travail, n’est-ce pas ? Ainsi, des agents, euh, assistant à l’évaluation, euh, organisant, coordonnant l’inspection, réservant du temps, et, euh, soutenant les décisions, euh, et même, vous savez, codant des logiciels de domaine central. Donc, tout cela. Euh, et donc, la guilde des architectes de cette entreprise, euh, a suggéré que nous, euh, explorions cela à travers ce qu’ils appellent des ateliers d’API collaboratifs, euh, des ateliers d’enregistrement de décisions d’architecture (ADR). En gros, c’est une variante de Njus, euh,

vous savez, un processus de conseil en architecture, euh, mais ils l’appellent juste comme ça. Donc, j’utiliserai simplement leurs termes. Euh, bref, donc, euh, pour découvrir les exigences de l’architecture, euh, euh, nous avons fait quelque chose appelé la cartographie des émotions ou la cartographie de l’empathie, qui est une version allégée de la cartographie du parcours client. Qui a déjà fait de la cartographie de parcours client ici ? Oh, waouh. Super. Content de vous avoir ici. Euh, bref, en gros, vous tracez le parcours émotionnel du client à travers les points de contact. N’est-ce pas ? Alors, et quand nous avons mis cette question sur le, euh, calendrier, euh, en mai, beaucoup de gens sont devenus curieux. Qu’est-ce qui rend un voyage émotionnel si formidable ? En fait, les guildes d’architecture ont eu le taux de participation le plus élevé à ces ateliers parce que c’est volontaire et parfois les gens ne se présentent pas. Donc, cela a évidemment créé une certaine attraction. Alors, le premier jour du, je n’ai pas beaucoup de temps, donc le premier jour de l’atelier se concentre principalement sur deux choses. Les gens, les moments et les émotions. Et, euh, ce que nous demandons aux gens de faire, c’est de cartographier les acteurs et les moments clés dans le flux de travail des réclamations et, euh, vous savez, à la fin, euh, les hauts et les bas émotionnels lorsque l’IA fait partie du flux de travail. Comme vous pouvez l’imaginer, cela a déclenché pas mal, vous savez, euh, compétences techniques, ils ont le taux de participation le plus élevé à ces ateliers parce que c’est volontaire et parfois les gens ne se présentent tout simplement pas. Cela a évidemment créé une certaine dynamique. Donc, le premier jour, je n’ai pas beaucoup de temps, donc le premier jour des ateliers se concentre essentiellement sur deux choses : les personnes, les moments et les émotions. Et euh ce que nous demandons aux gens de faire, c’est d’essentiellement cartographier les acteurs et les moments clés du flux de travail des réclamations et, euh, vous savez, à la fin, euh, les hauts et les bas émotionnels lorsque l’IA fait partie du flux de travail. Comme vous pouvez l’imaginer, cela a déclenché pas mal de, vous savez, euh, Oh, je suis désolé.

cela a déclenché des conversations vulnérables. Et par exemple, euh, prenons Sam, l’agent de support client par exemple. Ainsi, lorsqu’une réclamation est refusée, euh, Sam pourrait vouloir, pourrait devoir expliquer le le refus, donc la décision à un client frustré ou même en colère, n’est-ce pas ? Donc, mais alors, parce que la décision a probablement été prise par des systèmes multi-agences que Sam ne comprend probablement pas entièrement. Et à ce moment-là, il pourrait se sentir assez impuissant. C’est donc une narration. Et donc, euh, maintenant, le deuxième jour, euh, c’est essentiellement le pipeline que nous suivons, c’est le chemin, les moments, les émotions, puis la question architecturale et ensuite les exigences architecturales, euh, ou les caractéristiques architecturales. Et donc, dans le cas de Sam, l’émotion serait alors, vous savez, d’aider cela, n’est-ce pas ? Et cela mène à la question de l’architecture, vous savez, comment éviter de mettre Sam dans une position où il se sent euh euh euh euh impuissant à expliquer des décisions assistées par l’IA à un client qui appelle. Et ces questions sont en quelque sorte formulées comme un déclencheur de conversation, ce qui conduit finalement à l’exigence architecturale énoncée d’abord en langage naturel dans ce cas. Le système devrait pouvoir tracer les décisions à travers les systèmes d’agence. Et finalement, cela s’est affiné en cette étiquette que nous voulons, n’est-ce pas ? L’architecture, je ne veux pas dire ce mot, l’explicabilité ou la traçabilité des décisions. C’est donc en quelque sorte le projet.

Et ce qui est découvert, c’est que lorsque nous documentons, lorsque nous consolidons essentiellement les résultats des différents groupes d’atelier, les caractéristiques architecturales semblent, beaucoup d’entre elles semblent se trouver du côté droit. Donc, fondamentalement, il s’agit à la fois d’attributs de qualité des systèmes techniques et d’attributs fonctionnels, mais aussi du social, du relationnel, de l’organisationnel, il s’agit, vous savez, de la façon dont les gens, la relation entre les gens et le système et entre les gens et les gens. Si vous regardez la puce, vous auriez une réunion à ce sujet.

Et donc, les idées que nous avons tirées de cet exercice sont que les émotions et les questions deviennent ou peuvent devenir un matériau d’architecture. Donc si nous prenons les émotions d’abord, si nous aimons penser que ces décisions sont rationnelles, n’est-ce pas ? Elles ne sont pas émotionnelles. Mais vous savez, il s’avère que si vous retirez le centre émotionnel du cerveau d’une personne, cette personne ne peut prendre aucune décision, pas même quelle couleur de stylo utiliser ou quels vêtements mettre. Les raisons, la neuroscience en fait, euh, montre que nous, les êtres humains, nous ne sommes pas des machines pensantes qui ressentent occasionnellement. Nous sommes en fait des machines ressentantes qui pensent occasionnellement. Et donc, pour avoir une authenticité émotionnelle, nous avons aussi besoin de sécurité psychologique. C’est pourquoi il est important que l’équipe exécutive soit venue le premier jour de l’atelier et a donné cette permission. Parlons tous de ce que nous ressentons vis-à-vis de l’IA, pas de tabou, pas de jugement. Donc, en fin de compte, cette phrase que nous avons écrite, en fait, ce n’est pas moi qui l’ai fait, c’est leur équipe d’architecture. Ce sont des caractéristiques architecturales qui sont des réponses compressées aux émotions humaines à des moments critiques.

Super. Alors, vous feriez mieux.

D’accord. Euh, donc, sur le plan personnel, si nous voulons avoir du flow, nous avons besoin de fluidité émotionnelle, euh, émotionnelle. La capacité de ressentir toutes nos émotions et de les laisser nous traverser sans résistance, car ce à quoi vous résistez persistera en fait. Les émotions évitées ne disparaissent pas simplement, elles apparaissent comme des blocages dans notre corps et dans nos conversations et dans nos décisions architecturales. Vous savez, ces gars, ces éléphants dans les pièces et ces sujets dont on ne peut pas parler lors de nos sessions de travail, ils sont généralement là parce que nous ne voulons pas ressentir ces choses. la peur, le blâme, le jugement et le ressentiment. Et ces éléphants émotionnels dans notre atelier d’architecture, vous savez, ils règnent sur les décisions à chaque fois. La seule question est de le faire visiblement ou invisiblement, n’est-ce pas ? Et, vous savez, l’équipe de direction de Luxpair était parfaitement consciente des émotions ambivalentes que les gens avaient, euh, vous savez, dans leur relation avec l’IA. Mais je pense que ce n’est vraiment pas seulement les gens de Luxpair, mais nous avons tous ressenti le FOMO par rapport à l’IA, n’est-ce pas ? La confusion,

la surcharge cognitive, n’est-ce pas ? Courir très, très vite, aussi vite que des coussins. Et probablement quelque part en dessous, vous savez, aussi la honte de manquer le bon vieux temps où je pouvais passer toute une journée, où je pouvais passer toute une journée sur un problème de conception, n’est-ce pas ? Esquisser sur papier,

prendre une douche, et revenir avec clarté. N’est-ce pas ? Donc ces choses sont aussi des sujets dont on ne peut pas parler. Et elles ont un impact sur nos décisions personnelles et architecturales dans chaque entreprise en ce moment.

Donc, pour faire ça, vous savez, leurs téléphones. D’accord.

Et donc nous avons déjà vu cette image auparavant, n’est-ce pas ? Euh, la guerre de l’espoir étant euh due au manque de compréhension partagée. Et maintenant, il est de nouveau là, d’une manière différente, par des émotions évitées. Le fait est que, encore une fois, grâce aux neurosciences, nous savons que lorsque, vous savez, toutes nos addictions et nos et nos et nos conduisent à la perdition, au défilement sans fin sur Facebook, n’est-ce pas ? Nous prenons des décisions pour éviter de ressentir certaines émotions. Donc, quand les émotions ne circulent pas, les décisions ne circulent pas non plus. D’accord. D’accord, préparez-vous maintenant, qu’est-ce que vous faites d’intéressant ? Prenez votre photo. Je vois beaucoup de… Il doit y avoir beaucoup d’experts. Qui a entendu parler du Gemba Walk ? Oh, c’est le public. Pas mal. D’accord. Je suis à moitié… enfin, pas à moitié, je suis euh chinoise, je suis née chinoise et le japonais est hérité du chinois, encore une fois le en japonais. Euh et en chinois. C’est ça le vrai endroit, n’est-ce pas ? Dans la fabrication, c’est là que la valeur est réellement créée, n’est-ce pas ? Donc, quand vous faites le Gemba walk, vous allez voir, vous demandez pourquoi, vous montrez un profond respect si vous êtes un manager, vous gérez non pas à partir de rapports d’état mais à partir d’observations de première main. Et donc, mais quand le travail est invisible dans le logiciel, ce que vous devez faire le Gemba walk d’une manière différente. Et ce sera nos conversations. où nous pouvons apporter nos difficultés, où nous pouvons négocier notre ré-communion de ces choses partagées et nous pouvons nommer ces indescriptibles. Et c’est le mot étant l’architecture socio-technique.

Et donc, un philosophe a écrit une autobiographie intitulée « À ma manière ». Et ce titre capture le

l’attention à laquelle je reviens personnellement. Si vous avez un flux personnel, n’est-ce pas ? Vous faites les choses à votre manière. Vous êtes enthousiaste, vous êtes ininterrompu et vous euh vous vous enlevez du chemin des autres. Mais lorsque nous avons un flux social, nous créons quelque chose que personne ne peut créer seul, n’est-ce pas ? Alors, Mais le dilemme, c’est que, euh, vous savez, faire les choses purement à ma manière peut me gêner. Vous comprenez ? Donc, le flux personnel et le flux social ne sont pas des opposés à dissoudre. C’est une tension que nous devons maintenir et célébrer et, vous savez, en tirer profit. Euh, et donc, nous avons parlé des émotions, mais pour les questions, vraiment, la question euh ce que nous avons expérimenté dans cette expérience, c’est que le résultat de l’atelier était différent à cause des questions posées sur Sam, sur Claire, sur Dave. Et fondamentalement, littéralement, les questions posées ont changé ce qui allait venir ensuite, n’est-ce pas ?

Donc cela a changé l’avenir de l’atelier. Donc je sais que vous êtes un peu tous dépassés et fatigués à la fin de la conférence. Quelles sont les cinq premières lettres du mot championnat ?

Oui. Donc les questions nous lancent dans une quête partagée. Les réponses les arrêtent. Alors imaginez si nous avions fait ce que nous avons fait dans l’atelier, c’est-à-dire, vous savez, donner aux gens la liste des capacités et leur demander d’analyser les compromis et de prioriser, les résultats auraient été très différents.

Donc les questions sont pour moi essentiellement des boutons d’édition pour l’avenir. Et donc, vous savez, mais nous devons croire que c’est une possibilité.

Euh, oui, donc c’est une question que euh vous pouvez euh essayer par vous-même. Quelle est la question qui apporterait plus de fluidité à votre travail ? Parce que si vous êtes capable de poser cette question, vous répétez en fait le futur. C’est euh, pensez-y à l’ère de l’IA, les questions sont, vous savez, les réponses deviennent bon marché, n’est-ce pas ? avec la dépréciation de nous, c’est la question, la qualité de la question. Bref, voici les points clés. Les flux de travail, quand et leurs flux permanents. découpler le logiciel, connecter les personnes et les questions et les émotions sont des matériaux d’architecture. Alors, c’est l’image d’ouverture de la présentation. Vous vous demandez peut-être ce que c’est ? C’est la philosophie Ubuntu, philosophie sud-africaine et philosophie open source. Quelqu’un se souvient-il de ce que cela signifie ?

Ubuntu.

Ensemble.

Oui. Je suis parce que nous sommes. Et donc une personne est une personne à travers les autres personnes. Ainsi, notre ingéniosité et notre créativité coexistent avec les autres dans notre marche Gemba partagée, n’est-ce pas ? Dans euh dans cette danse socio-technique entre le flux de livraison et le flux génératif, n’est-ce pas ? Donc ma dernière invitation est bien sûr à vous tous, de vous intéresser davantage à devenir, à votre manière, un architecte socio-technique. trouver le flow ensemble en tant que comité.

C’est tout. Merci beaucoup.

D’accord, j’ai malheureusement utilisé toute l’heure, mais je serai là et vous pourrez me trouver et discuter si vous voulez. Merci beaucoup pour

votre attention. Bonne conférence.