Webinaire – Data, Explored #7 – Nouvelles perspectives sur les topologies d'équipe

Tout d'abord, je souhaite la bienvenue à Manuel Pais sur Data Explored. Merci. Merci.

C'est un honneur de vous accueillir. Pour nos auditeurs et nos téléspectateurs, je tiens à préciser que vous êtes un conférencier de grande expérience. Vous êtes le co-créateur du concept des « Team Topologies », qui désigne à la fois un ouvrage et une académie.

Vous êtes donc manifestement aussi coauteur du « Manifeste de la plateforme » que vous avez rédigé, et vous êtes un leader d'opinion dans le domaine du Fast Flow. Et vous parlez portugais. Je vois… C'est vrai, mais pas lors de ce webinaire.

Non. Je voulais dire quelque chose en portugais, mais je n'y arrive pas. Je suis désolé.

Mais… Ce n’est pas grave… C’est un vrai plaisir de vous accueillir, Manuel Pais. J’apprécie beaucoup votre travail et je vous suis de près.

Nous avons organisé cet appel pour parler de la deuxième édition de votre livre, « Team Topologies ». Je sais que j'ai mes notes sous les yeux, donc je ne suis pas sûr de pouvoir... Mais j'ai les deux éditions, la première et la deuxième... C'est bien... parce que j'ai lu le...

Ouais. J'ai pris l'habitude de ne pas jeter les premières éditions des livres que j'achète quand je passe à la deuxième édition, parce que je me rends compte que parfois je prends des notes et je réfléchis, et je me sens un peu perdu si je ne peux pas revenir en arrière pour retrouver ça. Je sais que je suis un geek, mais bon, je suis comme ça.

Mais j'ai lu le livre que vous avez coécrit avec Matthew Skelton. Du coup, j'ai beaucoup de questions, et nous avons également eu le temps de passer en revue certains points avant le début de l'émission ; nous aurons peut-être l'occasion d'en discuter au cours de cet appel. Nous disposons d'environ une heure.

Et si quelqu'un souhaite poser des questions, merci d'utiliser la section Questions-Réponses et non le chat. Mais pour ce webinaire, je propose que nous commencions par aborder certains aspects liés au livre, non pas ce qui figure dans le livre, mais ce qui l'entoure. Car il est évidemment encore un peu trop tôt pour parler de la deuxième édition et de la manière dont elle a été réalisée.

Mais la première édition, parce qu'elle vient tout juste de sortir, non ? Mais la première édition… Ouais, en septembre de l'année dernière. Oh, déjà en septembre.

Oui. Le temps passe si vite. Est-ce vraiment septembre de l'année dernière ?

Ouais. Oh, waouh. Ouais.

Voilà. Mais ce que je voudrais savoir, c'est que la première édition a reçu plusieurs milliers d'avis sur Amazon, alors ne me donne pas de chiffre. Je ne pense pas que tu devrais, mais ce livre marche bien, n'est-ce pas ?

Alors, ça fait quoi d’écrire un livre qui marche aussi bien ? Eh bien, ça fait vraiment plaisir. Mais je tenais aussi à vous remercier de m’avoir invité.

Évidemment, j'admire également ton travail d'auteur, et tu t'en es très bien sorti. J'ai aussi beaucoup apprécié nos échanges sur divers sujets. Le livre, « Team Topologies », est sorti en 2019, en première édition.

Ça a vraiment bien marché. Je pense, bien sûr, et nous en avons un peu parlé avant de commencer, que pour moi, ce livre, et pour Matthew aussi, ce n'était pas quelque chose dont nous nous sommes dit : « Oh, on a cette super idée. Écrivons là-dessus. » C'est quelque chose qui s'est cristallisé au fil de nombreuses années d'expérience, tant de mon côté que du sien, et je pense que plusieurs facteurs ont contribué à ce succès.

Je crois que les derniers chiffres dont je me souviens, c'était quelque chose comme 200 000 exemplaires vendus au cours des cinq premières années, en gros. C'est donc plutôt pas mal.

Waouh. Je pense que c'était une combinaison de facteurs : nos expériences respectives, à Matthew et moi, se sont très bien complétées. Nous avons écrit ce livre à une époque où de nombreuses entreprises – et nous l'avons entendu maintes et maintes fois – nous disaient : « C'est exactement ce dont nous avions besoin », car nous savions que nous avions des problèmes organisationnels, mais nous ne disposions pas d'une approche structurée pour y réfléchir.

Cela s'est également construit au fil de notre expérience, à Matthew et moi, qui avons travaillé plusieurs années comme consultants dans les domaines du DevOps et de la livraison continue. Si l'on réfléchit aux principes qui sous-tendent ces approches, ils rejoignent largement ceux des « Team Topologies », à la différence près que nous nous intéressons davantage à l'aspect organisationnel qu'à l'aspect technique ou aux pratiques. Et je pense que c'était le bon moment pour écrire ce livre.

Nous avions déjà travaillé sur ce que nous appelons les « topologies DevOps ». C'est Matthew qui a lancé le projet, puis je l'ai aidé à le développer ; il s'agissait d'un site web. Il est toujours en ligne, si quelqu'un souhaite consulter les topologies DevOps.

Et puis on a commencé à se rendre compte que ces tendances allaient bien au-delà du simple DevOps, qui faisait alors beaucoup parler de lui. Et ce qui est vraiment génial, là je m'éloigne un peu du sujet, mais tu peux toujours m'arrêter. Non.

Mais ce qui est vraiment intéressant à voir aujourd’hui, c’est que, bien sûr, tout le monde parle de l’IA, n’est-ce pas ? Quand on pense aux modèles que nous avons décrits dans Team Topologies et aux principes – que nous avons d’ailleurs cherché à mettre davantage en avant dans la deuxième édition –, il y a une nouvelle préface qui approfondit les principes qui sous-tendaient Team Topologies dans la première édition, car nous n’avions en fait pas beaucoup écrit à ce sujet. Nous nous sommes plutôt directement plongés dans les modèles et les objectifs.

Mais il existe un ensemble de principes, et quand on aborde l'IA d'un point de vue organisationnel, je dirais que presque tout ce que nous avons écrit dans la première édition reste d'actualité en ce qui concerne la gestion de la charge cognitive, la manière de s'organiser pour garantir un flux rapide lorsqu'on donne plus d'autonomie aux équipes, et toutes ces questions. Bien sûr, lorsque l’on ajoute l’IA à tout cela, cela peut accélérer certaines choses, mais cela peut aussi en ralentir d’autres si l’on n’est pas organisé de manière à se concentrer sur la création de valeur pour les clients. Mais bon, je m’éloignais un peu du sujet là.

Non, pas du tout.

Et nous pourrons d'ailleurs approfondir ce sujet dans un instant. Mais avant cela, il y a tant de choses dans ce livre qui me plaisent et qui sont surprenantes. Je suppose que beaucoup de gens dans le milieu de la technologie ont entendu parler de la loi de Conway, car elle reflète avec une grande précision l'impact des systèmes informatiques sur les organisations.

C'est donc vraiment intéressant de discuter de la loi de Conway, de ses conséquences, des moyens de l'éviter, etc. Vous citez également la loi de Conway. Mais au-delà de cela, vous citez de nombreux autres ouvrages et de nombreux autres points de vue.

Et l’un des ouvrages que vous citez est ce livre qui vous a inspiré, intitulé « Improving Performance : How to Manage the Whitespace on the Organizational Chart ». Oui. Et c’est justement là une observation très intéressante. Quel potentiel voyez-vous, ou plutôt avez-vous vu, mais que vous voyez sans doute encore, évidemment, dans les « espaces vides » de l’organigramme ?

Et pour situer un peu le contexte à l'intention de nos auditeurs, bien sûr, un organigramme comporte des cases et des flèches, ainsi que les intitulés des divisions opérationnelles, etc. Mais juste à côté de tout cela, il y a évidemment l'espace blanc. Or, ce que vous dites, c'est qu'il y a quelque chose dans cet espace blanc, qu'il y a un potentiel dans cet espace blanc qui doit se révéler pour que les organisations deviennent efficaces.

Alors, qu'est-ce que tu as vu dans cet espace blanc, Manuel ? Oui. C'était le concept vraiment central de ce livre : cette idée d'espace blanc.

Parce que cela met en évidence bon nombre des, disons, dysfonctionnements au sein des organisations : quand on regarde l'organigramme, tout semble généralement logique. On s'organise ainsi, avec les différents services et tout ça. Mais les « zones d'ombre », ce sont toutes ces choses qui n'y figurent pas, et qui se produisent au quotidien.

C'est donc un peu comme si les choses qui ne sont pas explicitement définies et comprises concernaient souvent les interfaces entre les équipes, entre les services. Car quand on regarde un organigramme, comme tu l'as dit, ce ne sont que des cases et des flèches, et on voit comment on est organisés. Si l’on superpose la manière dont le travail est réellement effectué, c’est là que les espaces vides deviennent, comment dire, plus visibles, et l’on se rend compte qu’il y a beaucoup de choses qui n’ont pas été clairement pensées de manière intentionnelle, et c’est là que l’on commence à s’en rendre compte.

Et c'est intéressant : un exercice très simple que chacun peut faire au sein de sa propre organisation consiste à réfléchir à un projet que vous avez mené à bien, peut-être une nouvelle fonctionnalité ou quelque chose d'utile, puis à tracer une ligne sur l'organigramme pour identifier les services et les équipes qui ont dû y participer, et on se retrouve souvent face à un véritable casse-tête. Et c'est intéressant, même dans la deuxième édition de Team Topologies, il y a une étude de cas. Il y a donc 10 nouvelles études de cas dans la deuxième édition, car l'un des objectifs de cette édition était de présenter des cas où des entreprises ont commencé à appliquer Team Topologies.

Dans la première édition, les études de cas étaient davantage axées sur des modèles spécifiques. Mais aujourd’hui, nous parlons d’entreprises, et notamment de grandes entreprises qui ont véritablement adopté ces idées et les ont mises en œuvre. Il y a par exemple une entreprise appelée Telenet en Belgique.

C'est l'un des principaux opérateurs de télécommunications. Dans le cas client, ils ont constaté que le point de départ était la présence de toutes ces « tribus ». Ainsi, lorsqu'on examine l'organisation sous l'angle de ces tribus, cela semble logique sur le papier.

Bon, il y a une équipe pour support client, une autre pour ceci et cela. Et puis ils ont défini les limites, comme je le disais : quand le travail est réellement effectué, quelles sont les dépendances ?

Et en gros, il y a des lignes partout. Mm-hmm. Et c'est là que l'espace blanc qui était là avant devient, disons, un espace sombre.

Je ne sais pas. On se rend simplement compte qu’il y avait beaucoup de choses qui ne fonctionnaient pas bien. Et puis, ce cas client d’ailleurs extrêmement intéressant, car il a réellement mis en pratique certains des concepts et des types d’équipes dont nous parlons dans « Team Topologies » au niveau de la tribu.

Donc, ils disent que cette tribu se concentre sur le client final, que cette tribu est une tribu « plateforme » chargée de fournir Fonctionnalités internes Fonctionnalités Mais oui, de ce point de vue, les « zones d'ombre » correspondent à ces éléments qui ne sont pas clairement définis de manière intentionnelle et qui finissent par devenir des obstacles majeurs à la création de valeur pour nos clients. Oui.

Je vois cet espace blanc à la fois comme un labyrinthe caché et, en même temps, comme la manière dont le travail s'effectue réellement. Oui. C'est donc les deux à la fois.

C'est justement l'effervescence du quotidien professionnel qui ne transparaît pas vraiment dans ces tableaux très formels. Nous reviendrons sur les études de cas et les modifications que vous avez apportées dans la deuxième édition, car tout cela vaut vraiment la peine d'être lu. Nous y reviendrons donc sans faute.

Mais bon, je suppose… et je sais que tu as déjà fait ça un million de fois, alors s'il te plaît, ne t'endors pas d'ennui, Manuel. C'est un peu comme… Mais décris très, très brièvement les équipes que tu conseilles aux entreprises d'adopter. Ouais.

Bien sûr. Pas de problème. C'est comme un groupe qui joue ses plus grands succès, non ?

Tous les soirs. Oui. Non, mais en fait, comme je le disais, quand nous avons rédigé la première édition, je pense que c'est l'une des principales différences par rapport à la deuxième édition.

La première édition reflétait vraiment ce que nous avions observé dans ces schémas et ce travail ; comme je l’ai dit, nous avions consolidé bon nombre de ces schémas et idées issus de notre expérience, et nous voulions ensuite les intégrer dans le livre. À l’époque, j’avais l’habitude de dire en quelque sorte : « Bon, voilà ce type d’équipe et tel autre type d’équipe. » Aujourd’hui, j’aime bien, et avec vous, j’aime bien partir du « pourquoi ».

L'approche « Team Topologies » vise donc à assurer un flux rapide de valeur vers le client. Il faut donc garder à l'esprit qu'il ne s'agit pas simplement de dire : « Allons-y vite et devenons une machine à produire des résultats. » Sa valeur ne se concrétise que lorsqu'il y a quelqu'un qui utilise ce que vous fournissez, que cela lui est utile et que cela profite à votre organisation. C'est là que la valeur est réellement apportée.

Il ne s'agit pas simplement de proposer des fonctionnalités, des solutions d'IA à la va-vite ou quoi que ce soit d'autre. Donc, si c'est ce que nous voulons, alors, dans une certaine mesure, les types d'équipes dont nous parlons dans « Team Topologies » sont conçus comme des aimants, dans le sens où c'est ce vers quoi nous devons tendre. Et le premier type est ce que nous appelons les équipes « alignées sur le flux ».

C'est donc similaire aux équipes produit transversales. La raison pour laquelle nous avons voulu faire une distinction avec les « streams », c'est que les produits ont tendance à être très complexes, et qu'il n'est donc pas possible de confier la responsabilité d'un produit entier à une seule équipe. Nous devons donc nous demander, au sein même des produits, quels sont les différents « streams » ?

Et ces filières peuvent être adaptées en fonction utilisateur différents utilisateur qui existent pour un même produit. Nous pourrions donc avoir besoin de différentes équipes chargées de s'occuper des profils les plus expérimentés, des moins expérimentés, ou de toute autre distinction qui pourrait exister. Ou bien, nous avons évidemment différents utilisateur au sein du produit, et c'est peut-être cela qui justifie la mise en place de filières distinctes.

Ou parfois, il s'agit d'un ensemble de fonctionnalités ou de modules relativement indépendants les uns des autres, ce qui pourrait correspondre à vos flux. Souvent, c'est une combinaison de ces différents facteurs. Et en fait, cela rejoint ce que vous disiez tout à l’heure à propos de la loi de Conway, selon laquelle, d’un point de vue de l’architecture technique, nous sommes manifestement passés de l’idée que les monolithes sont mauvais, qu’il s’agit de grosses applications, et qu’il est difficile de les modifier et de les faire évoluer.

Puis les microservices sont arrivés, et on s'est dit : « Bon, si on dispose de toute cette modularité et de petits services, on peut les faire évoluer plus rapidement. » Mais en réalité, il nous manquait quelque chose au milieu, que l'on appelle « macroservices » ou tout autre type de services adaptés à une seule équipe. Car on ne souhaite probablement pas avoir des centaines de petits services dont une seule équipe doit s'occuper.

C'est donc là que ces équipes alignées sur les flux devraient, dans l'idéal, être responsables d'un service ou d'une partie d'un produit qui soit largement indépendant du reste, capable d'évoluer de manière autonome et d'apporter de la valeur aux clients. Il ne s'agit donc pas simplement d'un composant technique, mais bien d'un élément qui présente une valeur claire, et nous savons qui en sont les utilisateurs et quels sont leurs besoins. Or, la difficulté avec ce type d’équipes, c’est que l’on attend d’une équipe relativement petite qu’elle dispose d’un large éventail de compétences et d’aptitudes.

Et il y a aussi beaucoup à faire pour comprendre vos clients, mener des études, puis traduire concrètement ces informations en un logiciel ou en ce que nous devons développer, avant de le livrer aux clients et d'analyser s'il est utilisé, s'il améliore les indicateurs de performance de l'entreprise, etc. Idéalement, tout cela relève de la responsabilité de l'équipe alignée sur le flux. C'est donc beaucoup à gérer, et c'est la raison principale pour laquelle nous intégrons d'autres types d'équipes.

Il existe donc trois autres types d'équipes, à savoir les équipes de soutien, qui sont généralement spécialisées dans un domaine particulier. Leur rôle n'est pas, disons, d'effectuer elles-mêmes le travail spécialisé, mais d'aider les équipes à acquérir les connaissances nécessaires pour qu'elles puissent accomplir ce travail.

C'est donc un changement très important par rapport à la vision traditionnelle selon laquelle il y aurait une sorte d'élite d'experts. Ce sont les seules personnes qui savent comment faire X. Si ces personnes adoptent une approche facilitatrice, elles apporteront, comme le dit le vieil adage, « Ne donnez pas de poisson aux gens, apprenez-leur à pêcher pour qu'ils puissent être plus autonomes. » Mm-hmm.

C'est donc plutôt du côté des compétences. Et puis il y a les équipes « plateformes », que nous avons un peu précisées dans la deuxième édition. Mais il s'agit essentiellement d'équipes qui fournissent des produits internes, si l'on peut les considérer comme des outils destinés aux équipes internes afin qu'elles aient moins de soucis à se faire.

Ils sont moins soumis à ce que l'on appelle la « charge cognitive », car nous disposons de services internes qui peuvent nous aider. Cela commence souvent par de nombreux aspects techniques, comme les déploiements, la surveillance ou l'infrastructure. Tout cela peut être réalisé de manière automatisée, idéalement par la plateforme elle-même, et de façon simple à utiliser.

Cela permet donc de soulager l'équipe alignée sur le flux d'une grande partie de ses soucis, afin qu'elle puisse se concentrer sur les besoins des clients. Nous avons ensuite abordé la question des équipes chargées de sous-systèmes complexes, dont nous avons longuement discuté pour déterminer si elles étaient vraiment nécessaires. Il arrive en effet que l'on soit confronté à un algorithme très complexe, à un sous-système, voire à un service qui effectue des traitements complexes ou qui a des besoins très exigeants en matière de traitement ou de calcul. Et parfois, on a besoin d’une équipe dédiée à ce service ou à ce sous-système, car si l’on demande à l’équipe alignée sur le flux de s’en charger, cela va tout simplement dépasser ses capacités cognitives.

On peut donc considérer ces équipes chargées de sous-systèmes complexes presque comme une sorte de mini-plateforme. Il s'agit certes d'un seul type de sous-système ou de service, mais il doit être fourni de manière à ce que les équipes alignées sur les flux puissent l'utiliser facilement. Oui.

Merci. Voilà donc les quatre... Merci... types.

Oui. Merci. Et merci de nous avoir accordé un peu de votre temps.

Ça doit être la énième fois, je ne sais pas combien de millions de fois tu as dit ça, mais… j'ai perdu le compte. Ouais. Bien sûr.

Mais il fallait en quelque sorte clarifier ce point, car en gros, les équipes que tu proposes fonctionnent selon des topologies, n'est-ce pas ? C'est le principe des topologies d'équipe. C'est que ces équipes... Oui...

Ils travaillent dans des structures bien précises, au sein d'entreprises bien précises, pour accomplir des tâches bien précises, n'est-ce pas ? Oui. Et ils évoluent.

Ou alors, elles devraient évoluer de manière assez continue. La topologie est donc une combinaison de différents types d’équipes, ainsi que de leurs interactions, n’est-ce pas ? Si l’on considère cela comme un système, où, encore une fois, dans l’idéal, si nous n’avions que des équipes alignées sur les flux, dotées de toutes les compétences nécessaires et soumises à une charge cognitive raisonnable, alors cela suffirait.

Il suffirait que des équipes alignées sur le flux travaillent en parallèle pour apporter de la valeur aux clients. Mais nous savons que ce n'est pas très réaliste. La topologie, en quelque sorte, s'apparente à cette idée d'une « équipe d'équipes » qui collaborent efficacement pour apporter cette valeur aux clients.

Mais cela devrait évoluer avec le temps, en fonction des défis auxquels nous sommes confrontés aujourd’hui. Si l’on considère la situation actuelle, il existe peut-être des lacunes au sein des équipes en matière d’adoption de l’IA ou de compréhension de la manière d’intégrer l’IA dans nos processus de travail et nos produits, et ce, de manière éthique.

Et il y a beaucoup de questions pour lesquelles nous aurons peut-être besoin de l'aide d'experts ou d'une équipe de soutien capable d'aider les équipes alignées sur les flux à y voir plus clair. Nous aurons peut-être besoin d'outils de plateforme qui facilitent l'utilisation de certaines de ces nouvelles approches. Voilà donc les défis auxquels nous sommes confrontés aujourd'hui.

Mais peut-être que d'ici un, deux ou trois ans, tout cela sera plus ou moins bien établi au sein de l'organisation. Nous saurons plus ou moins quels outils utiliser, et les équipes auront acquis suffisamment de connaissances ; nous n'aurons donc peut-être plus besoin des mêmes équipes de soutien, ou bien il y aura peut-être de nouveaux services de plateforme, car ce qui était autrefois plus expérimental sera désormais bien établi. C'est une bonne façon de procéder, et nous pourrons en quelque sorte le proposer sous forme de service de plateforme.

Il est donc essentiel de ne pas considérer les topologies comme quelque chose de statique. Ce n'est pas, disons, un modèle opérationnel statique.

C'est ce qui fonctionne aujourd'hui pour relever les défis auxquels nous sommes confrontés, et qui vont évoluer au cours des prochains mois et des prochaines années. Oui, et j'apprécie cette flexibilité. C'est une structure organisationnelle capable de s'adapter, de changer, de se recentrer, et tous ceux qui ont travaillé dans le secteur des technologies savent que c'est une capacité indispensable pour une organisation.

Oui. Sinon, on se retrouve avec des structures extrêmement lourdes, composées d'équipes très complexes et peu Mm ... productives, en gros.

Je suppose qu’on est tous passés par là à un moment ou à un autre de notre carrière. Et c’est aussi intéressant de voir que, d’après ce que je constate, beaucoup d’entreprises investissent massivement non seulement dans les outils, mais aussi dans l’expertise et la mise en place de bonnes pratiques. Évidemment, aujourd’hui, on parle d’IA, mais c’était avant le DevOps et le CI/CD ; si l’on s’intéresse aux aspects plus techniques, vous êtes manifestement dans le domaine des données, avec des concepts comme data mesh tout ce qui s’y rapporte.

Bien sûr, ils ont souvent besoin d'expertise et d'outils, et ils investissent beaucoup dans ce domaine, mais ils n'investissent pas dans ce qui permet de les mettre en œuvre. C'est donc comme si nous avions de très bons outils à notre disposition, mais que les gens n'en tirent pas parti parce que les équipes alignées sur les flux ou les équipes produit sont accaparées par leur quotidien, qu'elles subissent une forte pression pour livrer, et que personne n'est là pour les aider à comprendre comment bien utiliser ces outils, n'est-ce pas ? Souvent, ils adoptent certaines choses parce qu’il y a une certaine pression qui les pousse à se dire : « Bon, il faut qu’on mette en place le DevOps ou autre chose. »

Mais elles finissent souvent par le faire de manière désordonnée. C’est pourquoi l’aspect « facilitation » est vraiment intéressant, et c’est, du moins pour moi, l’un des aspects dont je suis le plus fier dans Team Topologies. C’est quelque chose qui semble inhabituel pour de nombreuses organisations, et lorsqu’elles voient cela se produire, elles peuvent constater l’impact que cela a, mais c’est tout simplement une question d’apprendre aux gens à utiliser ces excellents outils et ces pratiques.

Il ne suffit pas de leur donner ces informations et de s'attendre à ce qu'ils apprennent comme par magie, n'est-ce pas ?

Parce qu'il n'y a souvent pas assez de temps pour apprendre et vraiment mettre les choses en pratique. Non, je crois que je peux admettre que je suis un geek. Mais voir la technologie d'entreprise fonctionner concrètement est un tel plaisir pour moi, et j'ai donc pu en faire l'expérience à de nombreuses reprises.

Évidemment, je trouve que le taux d'échec des technologies d'entreprise est extrêmement élevé. Quand j'occupais d'autres postes, j'ai pu le constater de temps à autre, n'est-ce pas ? Ces projets informatiques qui tournent mal... Ouais...

ou ces équipes qui avaient été recrutées, et en général, il s'agissait de data scientists dizaine d'années, n'est-ce pas ? Ils touchaient des salaires colossaux, mais ne faisaient pas grand-chose, voire rien du tout, si ce n'est être des génies des maths… C'est vraiment décevant, n'est-ce pas ? Mais bon, cela touche vraiment à la flexibilité et à la simplicité d'utilisation compétences techniques, des personnes et simplicité d'utilisation la technologie, et je suppose que cette « Team Topology », c'est un peu la dimension organisationnelle de ces décentralisations technologiques que nous avons observées, comme le data mesh ou les microservices.

Dans quelle mesure ces éléments sont-ils liés, et comment avez-vous tendance à percevoir ce lien avec ces mouvements de décentralisation... Oui... technologiques ? Oui, je dirais que si l'on prend du recul, c'est en fait ce que vous avez mentionné tout à l'heure.

La loi de Conway traite de l'impact de notre mode d'organisation et de nos moyens de communication, ainsi que des interfaces entre les équipes et du type de systèmes que nous sommes capables de produire. Mais il existe une troisième dimension à cela, à savoir l'architecture métier proprement dite, si l'on veut. Ainsi, chaque entreprise utilise un vocabulaire qui lui est propre pour décrire l'organisation de ses activités.

J'aime parler des flux de valeur. Lorsque les entreprises ont recours à des approches telles que la conception orientée domaine, elles ont tendance à parler de domaines métier et de sous-domaines. Mais au fond, il s'agit de la même chose : comprendre l'architecture de votre entreprise.

Quelle valeur offrez-vous à quels clients, et comment cela est-il organisé ? Quels sont les différents flux de valeur ou domaines, etc. Et pour que cette architecture métier soit en adéquation avec votre architecture organisationnelle, c'est-à-dire votre structure et votre organigramme, mais aussi vos canaux de communication et tout le reste.

Et si cela correspond à votre architecture technique, alors vous bénéficiez d’un réel avantage : ces éléments sont en phase. Ils ne se font pas concurrence. Je pense donc que ce qui s’est passé, je ne sais pas si c’est un peu, comment dire, arrogant de ma part de le dire, mais je pense qu’avant Team Topologies, il y avait une sorte de séparation entre, disons, l’architecture technique, et c’est là que des concepts comme les microservices et data mesh, dans une certaine mesure, entrent en jeu.

Et ces éléments, ces modèles, ces idées sont certes valables et utiles, mais ils n’étaient pas reliés au reste, à l’aspect organisationnel. Nous ne voyions peut-être pas autant l’impact de la simple adoption des microservices ; comme je le disais tout à l’heure, si l’on se retrouve avec des centaines ou des milliers de microservices, la charge liée à la gestion de tous ces services est bien plus importante. Et souvent, les entreprises commencent alors à se rendre compte que cela ne nous aide pas vraiment à aller plus vite.

Nous avons davantage de charges de travail qu’auparavant, car il y a toutes ces petites prestations, qui n’étaient souvent pas segmentées ou réparties en fonction des besoins des clients. Nous fonctionnons davantage selon une approche fonctionnelle. Je pense donc que c’était là le problème : nous adoptions ces bonnes pratiques techniques, mais elles n’avaient pas l’impact escompté sur l’activité ni ne nous permettaient d’apporter rapidement de la valeur ajoutée.

Et c'est pour ça que je pense qu'à un moment donné, c'est pour ça qu'on essaie d'introduire aussi les topologies d'équipe : pour que les équipes réfléchissent, ou quand on réfléchit à l'architecture technique, à ce qui est pertinent pour une équipe comptant généralement jusqu'à huit ou neuf personnes. Ce qui est pertinent, en tant que service ou composante d'un produit, pour qu'une équipe puisse gérer et créer de la valeur de manière essentiellement autonome sur ce service ou ce flux spécifique. N'est-ce pas ?

C'est un peu comme relier les points, si tu veux. Ouais. Je crois que je peux être honnête là-dessus.

Je ne sais pas si je devrais en avoir honte ou non, mais je savais que *Team Topologies* était un livre important avant même de l'avoir lu. Je ne savais tout simplement pas pourquoi. Et il m'a fallu...

Je lisais et je lisais, et au début, je ne comprenais toujours pas pourquoi c'était important. Et puis ça m'est tombé sous les yeux, tu vois ? C'est exactement ce dont tu parles : j'ai soudain compris qu'on a l'habitude de considérer les technologies comme quelque chose qu'il faut démanteler.

Il faut décomposer les architectures de données. Il faut décomposer les grands systèmes ERP. Quoi qu'il en soit, il faut décomposer ce monolithe pour libérer le potentiel de ce dont vous vous occupez.

Et là, ça m'a frappé : « Bon, ce livre explique qu'on peut faire la même chose, ou qu'il faut faire la même chose pour son organisation. C'est aussi un monolithe, et on peut aussi le démanteler. Et c'est exactement le sujet de ce livre. »

Et puis j'ai compris. Du moins, je crois avoir compris, mais à toi de me dire. Bref.

Oui, je crois bien. Eh bien, merci. On a tout enregistré.

Merci. Si l'on relie cela à ce que vous me demandiez tout à l'heure concernant les raisons du succès du livre, je pense que, d'une part, beaucoup de gens ont dit : « Je me suis senti(e) compris(e) », comme lorsque nous parlons des points faibles et de ce que vous venez de dire : si nous ne regardons que dans une seule dimension, alors nous faisons de notre mieux pour améliorer, disons, l’architecture technique et notre façon de travailler, mais nous ne voyons pas l’impact de l’autre côté. Les gens se sont donc fortement identifiés à la façon dont nous décrivions ces problèmes.

Et puis certains ont également fait remarquer, et je suis d'accord avec eux, que les idées que nous avons proposées en termes de solutions, disons, ou de modèles, s'appuient largement sur ce qui a déjà été fait par le passé : le mouvement DevOps, l'Agile dans une certaine mesure, et la pensée systémique, qui est également très importante. Certains diront donc : « Eh bien, il n’y a rien de vraiment nouveau dans les Team Topologies », mais ce qui était nouveau, c’était la façon dont elles rassemblaient ces éléments, en leur donnant un vocabulaire. Et comme je l’ai dit précédemment, je pense que l’aspect « habilitant » est celui auquel beaucoup de gens n’avaient peut-être pas pensé pour le rendre plus intentionnel.

Mais bien sûr, une grande partie de tout cela s'appuie sur ce que nous savions déjà, même des concepts comme la « plateforme en tant que produit ». Mais il s'agissait surtout de rassembler tous ces éléments. Je pense qu'au final, c'est exactement ce qu'a fait Team Topologies.

Et c'est peut-être pour ça que tu dis qu'il t'a fallu un certain temps pour comprendre pourquoi c'est important : ça permet, je crois, de relier les points entre toutes ces choses que nous avons ressenties, que nous savions. Il y a quelque chose qui cloche ici. Pourquoi n'obtenons-nous pas d'autres résultats ?

Je pense donc que, pour moi, la force de « Team Topologies » réside dans le fait qu’il s’agit d’un ouvrage relativement court qui synthétise bien les choses et permet de comprendre l’aspect organisationnel, tout en étant parfaitement en phase avec les principes techniques et les idées qui sous-tendent le DevOps et la livraison continue.

C'était donc tout à fait logique pour beaucoup de techniciens aussi. Tout à fait. Je me suis moi aussi senti interpellé par ce livre, tout comme de nombreux autres lecteurs.

Penchons-nous maintenant un peu plus en détail sur la deuxième édition. Il y a quelques changements, et tu en as déjà un peu parlé, mais approfondissons un peu le sujet. Oui.

Je voudrais conclure cette discussion par les études de cas, car il y en a tellement, elles sont tellement intéressantes et tellement variées. N'est-ce pas ? Je préfère donc garder ce sujet pour plus tard.

Je pense que la première chose dont nous devrions parler, en gros, c'est un sujet qui me tient particulièrement à cœur, car j'y ai consacré la majeure partie de ma carrière. Laissez-moi donc vous donner quelques éléments de contexte. C'est une longue introduction pour une question courte.

Je vous demande un peu de patience. J'ai passé la majeure partie de ma carrière dans de grandes entreprises, tant en tant que salarié interne qu'en tant que consultant externe, où j'ai conseillé de nombreuses personnes. Tout a vraiment décollé lorsque je suis devenu auteur spécialisé dans les technologies et que mes écrits ont trouvé un écho auprès du public. J'ai donc créé ma propre société de conseil parallèlement à mon emploi en interne.

Ce à quoi j’ai été confronté à maintes reprises, ce sont ces multiples technologies identiques ou des technologies qui faisaient plus ou moins la même chose, mais peut-être pas tout à fait la même chose. C'est en grande partie dû à l'étude que j'ai menée, ou à la direction que j'ai prise, principalement au niveau de métadonnées technologies que je considère comme pouvant être connectées à un réseau, un méta-réseau comme je l'appelais. Mais assez parlé de moi.

Ce que je trouve particulièrement intéressant, c'est que vous avez modifié une équipe en particulier dans la configuration de la topologie des équipes, à savoir l'équipe chargée de la plateforme. Et cela repose sur le fait que, si j'ai bien compris, votre coauteur, Matthew, a dit que vous en aviez en fait discuté pendant la rédaction de la première édition, mais… Oui… puis ça s'est perdu dans un fil de discussion Slack ou quelque chose comme ça.

Mais tu as modifié l'organisation, tu as changé le nom, passant de « équipe plateforme » à « groupe plateforme ». Pourquoi cela ? Oui.

Pourquoi parle-t-on désormais d'une plateforme ? Alors, si je peux me permettre d'évoquer la deuxième édition... Mm-hmm... pour ceux qui ne l'ont pas vue.

L'idée était donc de ne pas trop toucher à la première édition, car, comme je l'ai dit tout à l'heure, tout ce qui figurait dans la première édition reste fondamentalement d'actualité. On ne parle peut-être plus autant de DevOps qu'en 2019, mais les principes restent valables. Nous avons ensuite ajouté une nouvelle préface, qui revient principalement sur les cinq six années qui se sont écoulées depuis la publication de la première édition, et quelles étaient les choses sur lesquelles nous nous étions trompés ou qui n’étaient pas assez claires dans le premier livre, comme les principes qui le sous-tendaient, puis des éléments tels que la manière dont les modèles ont été adoptés de différentes manières par différentes entreprises comme Telenet, que j’ai mentionnée plus tôt, en appliquant les types d’équipes, mais au niveau de la tribu.

Il y a donc une nouvelle postface, qui fait davantage le lien avec la situation actuelle et les années à venir en matière d’IA, et qui examine comment cela modifie – ou non – notre façon d’envisager la dynamique organisationnelle. Il y a également dix nouvelles études de cas, ainsi qu’une note concernant le regroupement des plateformes. En effet, pour la première édition, nous avions souhaité rester simples.

Donc, l'idée de l'équipe « plateforme » : d'une part, pour faire simple, l'équipe « plateforme » est un type d'équipe à part, car certains disent : « En fait, c'est un peu comme une équipe produit, puisque c'est un produit interne. » Oui, mais nous avons estimé qu’il y avait suffisamment de différences, car vous avez des clients internes, et non externes, et que vous fournissez souvent des services complexes d’un point de vue technique. Nous parlions beaucoup de ce genre de services techniques.

Ce qui nous a en quelque sorte échappé, et c'est peut-être quelque chose dont je ne m'étais pas rendu compte lors de la première édition, c'est que cette notion d'« équipe de plateforme » pouvait parfois être mal interprétée, comme s'il s'agissait d'une seule et même équipe chargée de l'ensemble de la plateforme. Et bien sûr, avec le temps, vos plateformes internes plateformes à se développer. Si elles connaissent le succès, ce qui est une bonne chose, elles auront tendance à se développer.

Et donc, pour moi en tout cas, c'était, je suppose, l'une de ces choses qui me semblaient assez évidentes : il fallait plusieurs équipes, et il fallait une plateforme plus grande. Si c'est petit et qu'on a une ou deux équipes, ça va. Mais si vous commencez à en avoir trois, quatre, cinq, ou si vous commencez à avoir en gros plus de, je dirais, 30 personnes travaillant sur la plateforme, vous devez réfléchir aux différents flux au sein de la plateforme, n’est-ce pas ?

Quels sont les différents services qui vous permettent d'organiser la structure de la plateforme d'un point de vue organisationnel, de la même manière que vous le faites pour vos produits ? Nous devons identifier différents flux, qu’il s’agisse uniquement de clients ou de collaborateurs internes. Et c’est là que, dans certaines organisations, nous avons discuté avec eux et réalisé qu’ils disposaient simplement d’une énorme équipe de plateforme comptant des dizaines de personnes, et bien sûr, ils étaient extrêmement occupés, extrêmement surchargés, courant dans tous les sens pour essayer de réparer des choses et de livrer de nouvelles fonctionnalités, mais tout cela était très ponctuel.

C'est pourquoi, dans la deuxième édition, nous essayons de préciser davantage qu'en réalité – et c'est peut-être une meilleure façon de présenter les choses –, il s'agit toujours d'un regroupement de plateformes. Vous allez avoir un ensemble d’équipes, et celles-ci doivent avoir des responsabilités et des limites bien définies entre elles. Cela ne signifie pas qu’elles sont totalement indépendantes en permanence, mais nous ne devrions pas avoir cinq équipes qui doivent coordonner leur travail en permanence.

Ainsi, si l'on part du principe qu'il s'agit d'un regroupement de plateformes, mais que parfois ce regroupement ne comprend qu'une seule équipe, c'est peut-être une meilleure façon d'envisager les choses, ce que nous avions omis dans la première édition. D'un autre côté, comme il était plus simple de parler d'« équipes de plateforme », cela a, je pense, aidé les organisations à comprendre la différence entre « plateforme » et « rationalisation » du point de vue du produit. Mais j'espère que c'est désormais clair.

Oui, bien sûr.

Non, mais je suis d'accord, et il est évident que je réfléchis à des choses similaires. Je suis en train de rédiger la deuxième édition de mon premier livre, « The Enterprise catalogue de données », et c'est un peu la même chose, n'est-ce pas ? En effet, la première édition catalogue de données traitait catalogue de données d'un catalogue de données catalogue de données une entreprise. Or, en réalité, dans la plupart des cas, on se retrouve avec plusieurs catalogues de données. Oui.

Et elles seront implantées ou réparties dans différents secteurs de l'entreprise. Certaines n'utilisent qu'un seul fournisseur de services cloud, d'autres se contentent d'une plateforme de données spécifique avec son catalogue associé. C'est tout simplement quelque chose de très naturel.

Oui. Et je suppose que c'est l'avantage d'écrire une deuxième édition. Mais ça ne présente pas vraiment d'avantages.

C'est un travail de longue haleine. Mais l'un des avantages, c'est que l'on peut s'appuyer sur les connaissances acquises grâce à la première édition, n'est-ce pas ? Oui.

Je suppose donc que ça aurait été difficile. Oui. Je dirais que c'est en fait un bon indicateur : on se rend compte, dans la deuxième édition, que certains éléments de la première édition avaient été mal compris.

Cela signifie qu'elles ont été adoptées, n'est-ce pas, et que les organisations ont mis ces idées en pratique. C'est juste que certaines choses n'étaient peut-être pas aussi claires qu'elles auraient pu l'être. Mais c'est l'une des choses qui, comme pour le développement de produits et de services, nous fait prendre conscience que c'est ce qui nous semblait logique à l'époque.

En réalité, nous devons nous adapter et rectifier le tir.

Je considère donc un peu cette deuxième édition comme une façon de rectifier le tir ou d’apporter davantage de contexte et de nouvelles perspectives à ce qui figurait déjà dans la première édition. Mm-hmm. Tout à fait.

Et j'aimerais entrer dans les détails, plus précisément en ce qui concerne la deuxième édition, comme vous l'avez mentionné, qui contient de nombreuses études de cas. Je pense que nous devrions nous pencher sur ces études de cas. Je me suis concentré sur deux d'entre elles, mais n'hésitez pas à évoquer la troisième.

Mais... Bien sûr... Je crois qu'EBSCO, je pense, c'est... Je reçois beaucoup de notifications sur une autre plateforme, et je les désactive tout simplement.

Désolé. Pas de souci. C'est juste un peu bruyant.

Trop de demandes d'attention. Ouais, exactement. Voilà.

Bon, vous y voilà. Super. En gros, parlons d'abord de ce premier cas d'usage, qui s'appelle, c'est ça, EBSCO.

C'est EBSCO, l'entreprise ? Oui, EBSCO. EBSCO.

Si j'ai voulu évoquer ce cas, c'est bien sûr parce qu'il s'agit d'un projet de moindre envergure, je crois. Mais il est intéressant de noter qu'ils ont également travaillé avec un cadre de référence pour la constitution d'équipes, comme Team Topologies. Ils ont réfléchi à la mise en place d'une structure organisationnelle qui pourrait les aider à être plus performants, et c'est ce qu'est SafeAgile.

Mais dans ce cas-là… Ouais… ils ont en quelque sorte épuisé le potentiel de SafeAgile. Et… peux-tu nous expliquer pourquoi, et ce que tu as fait… Ouais…

qui ont modifié leur configuration ? Je n'ai donc pas travaillé directement là-dessus. Et en fait, pour la plupart des études de cas de la deuxième édition – ce qui est intéressant –, nous n'avons pas été directement impliqués.

Ce n'est pas comme si nous avions mis en œuvre ces changements à leur place. C'est ainsi que les entreprises elles-mêmes ont envisagé de mettre en pratique ces idées et de se transformer, et c'est vraiment génial. Et puis, par divers moyens, nous avons fini par l'apprendre, ou bien elles sont venues nous voir pour nous parler de ce qu'elles avaient fait.

Dans certains cas, nous avions peut-être donné quelques conférences ou participé à apprentissage. Mais souvent, dans les études de cas de la deuxième édition, nous n'étions pas directement impliqués. Je trouve donc ça plutôt sympa aussi.

EBSCO fait partie de ces entreprises intéressantes… Je pense que si vous posiez la question à n’importe qui dans cette salle, je parierais que presque personne n’a jamais entendu parler d’EBSCO. Et puis on se rend compte que c’est en fait une entreprise assez importante. Elle fournit donc des bases de données de recherche et des informations aux bibliothèques, aux universités, etc.

C'est donc le genre d'entreprise dont on ne parle pas souvent. En fait, ils utilisaient Safe, et je dirais que ça marchait plutôt bien. Évidemment, Safe est un cadre qui, à mon avis, s'avère particulièrement utile quand on part d'une organisation très chaotique où il y a toujours des retards, où tout le monde court dans tous les sens et essaie de faire avancer les choses, mais où c'est toujours le chaos total.

Bien sûr, je pense que Safe peut vous aider à mettre en place une certaine structure et à mieux planifier, et il apporte, je dirais, beaucoup de clarté sur les interdépendances qui existent entre les équipes, entre les domaines ou les flux de valeur. Le problème avec SAFE, c’est qu’à un certain moment – et nous l’avons constaté non seulement chez EBSCO, mais aussi dans d’autres entreprises –, cela vous aide en quelque sorte à passer de cette phase initiale, plus chaotique, à quelque chose de plus structuré, un peu plus ou beaucoup plus prévisible.Mais à un certain moment, cela cesse en quelque sorte d’aider dans le sens où il s’agit surtout de gérer les dépendances et pas tant de les éliminer ou de gérer les effets de ces dépendances. Mm-hmm.

En gros, on finit par s'y faire. Bon, on connaît les interdépendances. On sait qu'il faut établir ce planning pour pouvoir disposer, en général, d'un plan trimestriel indiquant quelles équipes vont devoir travailler sur quelles initiatives ou fonctionnalités, etc.

Donc, comme je le disais, si vous partez d’une situation où tout était chaotique et où tous les délais n’étaient pas respectés, alors oui, ça aide. Mais ensuite, on est en quelque sorte bloqué là. Et ce qu’EBSCO a très bien fait, c’est qu’ils disposaient d’excellents indicateurs, notamment des indicateurs de lenteur, et qu’ils identifiaient les goulots d’étranglement, les temps d’attente pour apporter de la valeur à nos clients ou mettre en œuvre des changements qui, espérons-le, leur seront utiles.

Et c'est ainsi qu'ils ont commencé à se rendre compte : « Bon, on s'est beaucoup améliorés, mais on stagne un peu, non ? On a atteint, disons, le plafond de ce que SAFe peut nous apporter. » Ils se sont donc tournés vers les topologies d'équipe pour commencer à s'attaquer au problème : « Bon, ne nous contentons pas de subir ces dépendances. »

En réalité, nous devons ensuite utiliser ces modèles pour éliminer les dépendances bloquantes et mettre en place Fonctionnalités internes Fonctionnalités contribuent réellement à dynamiser les équipes. Et comme ils disposaient d’une très bonne télémétrie organisationnelle interne, si l’on peut dire, c’est-à-dire d’excellents indicateurs, c’est en partie pour cette raison que ces études de cas nous ont intéressés : ils ont ainsi pu constater comment l’utilisation des topologies d’équipe avait permis d’améliorer ces indicateurs.

Oui, exactement. Et je suppose que si tu es certifié SAFe Agile, comme moi et comme beaucoup d'autres, tu sens bien qu'il y a une limite à ce que cette méthode peut apporter, n'est-ce pas ? Mm.

J'ai entendu dire que certains l'appelaient un « framework monolithique ». Je ne sais pas si tu souhaites reprendre cette expression, étant donné qu'il s'agit d'un framework concurrent. Mais si tu y jettes un œil, sur leur site web, il y a beaucoup d'éléments qu'il faut comprendre, ainsi que leurs interactions, pour pouvoir...

Ce n'est pas une configuration simple. D'une part, cela représente un investissement initial important, et puis, à mon sens, au-delà de cet aspect financier, cela semble vous mener... Nous parlions tout à l’heure de la nécessité de s’adapter et d’évoluer en permanence, et je pense – même si je ne suis pas un expert en SAFe – que d’après ce que j’ai vu, cela semble vous mener à un point où vous obtenez ce genre de cadre, disons, stable et monolithique, qui fonctionne dans ce contexte, mais où vous ne réfléchissez plus vraiment à la prochaine étape.

Comment continuer à nous améliorer ? Et bien sûr, il y a les cycles de livraison et tout ça qui, oui, je pense, comme tu l'as dit, en sont une bonne illustration. Ça aide dans une certaine mesure, mais il y a tout de même une limite, car nous sommes liés à ces cycles de livraison, et de toute façon, c'était intéressant.

À un moment donné, SAFe s'est inspiré de certaines idées issues des topologies d'équipe, mais pas d'autres, ce qui, à mon avis… Hum. Oui, en gros, ils ont repris les types d'équipes, ce qui, je pense, a constitué un pas en avant.

Mais vous ne pensez pas forcément pour autant à améliorer votre flux simplement en adoptant ces types d'équipes. Et si vous conservez ces « release trains », vous continuez à coupler, au moins temporairement, une grande partie du travail, ce qui a tendance à se traduire ensuite par un couplage au niveau technique également, n'est-ce pas ? Car si nous devons de toute façon faire une livraison ensemble dans, disons, quatre semaines, pourquoi devrais-je investir pour rendre cela plus modulaire et capable d’évoluer plus indépendamment si, au bout du compte, nous devons tout intégrer ensemble ?

Oui. Bon, changeons un peu la tournure de cette conversation en admettant simplement que, selon moi, SAFe Agile est un mélange hétéroclite de méthodologies. Je ne savais pas qu’ils s’étaient inspirés des topologies d’équipe, mais c’est tout à fait leur style, non ?

Ils se sont également inspirés du Lean et d'autres principes, et donc, évidemment, si vous y adhérez, cela peut sans doute apporter une grande valeur ajoutée. Je pense que c'est le cas à un niveau élémentaire, mais cela devient très compliqué. Je voulais vous parler d'cas client autre cas client, mais je crois que nous manquons de temps ; je vais donc plutôt vous parler du cas client Adidas.

Je trouve juste leur plateforme, leur architecture numérique, vraiment intéressante, mais on n'a pas le temps. C'est trop compliqué... pour en parler en quelques minutes.

Du coup, je me disais… On en a un peu parlé avant de passer en direct, et je voudrais donc poser une autre question, d'un niveau plus général : vous avez publié ces livres chez IT Revolution. C'est vraiment une excellente maison d'édition. C'est là qu'ont été publiés « The Phoenix Project » et bien d'autres ouvrages très influents, même s'ils ne publient pas beaucoup de livres.

Comment avez-vous mis en place cette collaboration avec eux, et quelle est la nature de cette maison d'édition ? Oui. En gros, ils se consacrent principalement à aider les dirigeants d'entreprise.

Et les livres qu’ils publient, comme vous l’avez dit, ne sont qu’une poignée par an. C’est une petite maison d’édition, et ils se concentrent vraiment sur la publication d’ouvrages pertinents et utiles pour les dirigeants d’entreprise. Évidemment, chaque maison d’édition a sa propre stratégie.

Certains se basent sur le volume. Leur priorité, c'est la qualité de ce qu'ils publient. Et comme tu l'as dit, la raison pour laquelle ils avaient déjà publié des ouvrages de référence tels que « Phoenix Project », « Accelerate » et « From Project to Product », également de Mik Kersten.

Nous avons donc estimé que notre livre, dont l'objectif était... Au départ, nous pensions que notre public cible serait constitué de dirigeants d'entreprise, ainsi que de responsables commerciaux, d'ingénieurs seniors et d'architectes. Il correspondait donc parfaitement au public d'IT Revolution.

Je connaissais déjà Gene Kim grâce à mon travail dans le domaine du DevOps, donc oui, tout cela m'a semblé tout à fait logique. À l'époque, je ne connaissais pas encore très bien le monde de l'édition ni les différentes approches en matière de publication et de révision. Je pense donc que nous avons eu beaucoup de chance qu'ils acceptent, qu'ils aient su reconnaître la valeur de notre proposition, et qu'ils aient mis en place un processus éditorial très rigoureux.

Donc, si vous aviez lu la première version de « Team Topologies », ça aurait été difficile, car, comme c'est souvent le cas pour ceux qui n'ont jamais écrit de livre, la structure était assez académique. Les éditeurs d'IT Revolution – un grand merci à eux – nous ont vraiment aidés. « Bon, transformons ça en un véritable récit que les gens peuvent lire et auquel ils peuvent se référer plus tard », comme vous le disiez à propos de la première édition. Notre objectif était aussi de créer un livre que les gens peuvent lire et auquel ils peuvent revenir plus tard.

« Oh, je me souviens d’un passage du chapitre six qui pourrait m’être utile dans ma situation actuelle », disons, à titre de référence. Ils nous ont donc vraiment aidés à transformer ce premier jet en une version bien meilleure. Et on leur a fait confiance parce qu’au début, on se disait : « Ils veulent détruire notre travail. » C’est l’impression qu’on a, n’est-ce pas ?

Quand quelqu'un me dit : « Tu dois revoir en profondeur la façon dont tu abordes le sujet dans le livre. » Donc oui, c'est un peu comme ça que ça s'est passé, et je pense que ça a joué un rôle déterminant dans le succès du livre, j'en suis sûr.

Oui. Et merci d'avoir précisé ce détail également. Nous n'avons plus beaucoup de temps.

J'ai trouvé une question dans la rubrique Questions-Réponses, posée par Sabrina Sheila. Nous n'avons pas le temps de l'examiner maintenant. Je te l'enverrai, et nous pourrons peut-être y répondre plus tard.

Mais Manuel, je tiens à prendre le temps de te remercier chaleureusement d'avoir participé à cette émission, Data Explored. J'espère que les auditeurs en ont tiré beaucoup de choses. Pour ma part, c'est le cas.

Je souhaite à cette deuxième édition un immense succès, et… merci… de rester en contact. Nous le ferons.

Merci beaucoup. Ça m'a fait plaisir. Merci.