Matthew Skelton - Accidental Architects: how HR designs software systems (EN)

[00:00:14] Alors, je m'appelle Matthew Skelton. Je suis le co-auteur du livre Team Topologies, l'organisation des équipes métier et technologiques pour un flux rapide. Et j'aimerais partager avec vous quelques idées aujourd'hui sur la façon dont les RH, ou le département des ressources humaines, le département des personnes, peuvent en fait finir par être les architectes accidentels de nos systèmes logiciels. Cela semble vraiment étrange, n'est-ce pas ? Mais laissez-moi, euh, vous expliquer pourquoi cela pourrait être le cas.
[00:00:48] Ainsi, le livre Team Topologies est sorti il y a un peu plus d'un an, en septembre 2019, il a été publié par IT Revolution Press. Le foyer de livres comme le manuel DevOps, Phoenix Project, Project is Product et Accelerate. C'est une excellente collection de livres. Avant d'aller plus loin, examinons le mot topologie car il n'est pas très familier.
[00:01:09] Donc, cela vient d'un mot grec signifiant en quelque sorte où les choses sont placées. Et la façon dont nous l'interprétons de nos jours est, cela signifie la manière dont les parties constitutives sont interconnectées ou arrangées. Donc, si nous pensons aux topologies d'équipes, c'est la façon dont les équipes sont interreliées ou arrangées. Et cela se situe dans le contexte d'un flux rapide de changements pour la construction de systèmes logiciels.
[00:01:34] Et les idées qui, euh, sont contenues dans le livre, ont été vraiment utiles pour de nombreuses organisations à travers le monde. Donc, les idées sur lesquelles nous travaillions avant la publication du livre ont été utilisées par des entreprises comme Netflix. Phillip Fisher Ogden, directeur de l'ingénierie chez Netflix, a déclaré : « Merci pour vos articulations perspicaces des topologies de développement. Elles ont inspiré de nombreuses discussions et nous ont aidés à réfléchir au modèle que les équipes de Netflix pourraient utiliser. » Il est également utilisé dans des endroits comme Condé Nast, la grande maison d'édition. Crystal Hershon était directrice de l'ingénierie là-bas jusqu'à récemment, et elle a dit que votre modèle topologique a très bien résonné. Avec les côtés développement et opérations, et elle a aimé les arguments équilibrés pour les différentes perspectives de chaque modèle. Le livre a été décrit comme des outils et des concepts innovants pour structurer un modèle d'exploitation numérique de nouvelle génération.
[00:02:32] Ce sont donc des concepts et des idées stratégiquement importants que nous pouvons appliquer au moins au sein de l'informatique et, en pratique, probablement aussi dans d'autres parties de l'organisation.
[00:02:45] Ok, alors, réfléchissons un peu à qui conçoit l'architecture des systèmes logiciels.
[00:02:52] Est-ce que ce sont les développeurs de logiciels ? Cela peut être le cas. Est-ce que ce sont des architectes logiciels ? Ça pourrait être. Au fait, c'est une image officielle d'un architecte logiciel, ils ont tendance à ressembler exactement à ça, très heureux tout le temps. Je plaisante. Euh, ou est-ce que ce pourrait être le personnel du service des RH ?
[00:03:14] C'est bizarre.
[00:03:17] Mais en fait, le service des ressources humaines peut agir comme architectes accidentels du système logiciel.
[00:03:24] Ceci est une vraie photographie de moi quand j'ai réalisé cela pour la première fois il y a quelques années. Explorons pourquoi cela pourrait être le cas. Tout d'abord, nous devons en fait examiner quelque chose appelé la loi de Conway.
[00:03:36] Donc, en 1968, Mel Conway, qui travaillait alors, je crois, pour une grande société informatique, euh, il a écrit un article dans lequel il a, euh, publié dans une revue, a écrit un article qui disait, euh, toute organisation qui conçoit un système largement défini, produira une conception dont la structure est une copie de la structure de communication de l'organisation. Ceci est devenu assez connu récemment et, ces dernières années, a refait surface comme une sorte de principe directeur. Mais prenons juste quelques minutes pour vérifier cela. Est-ce vraiment vrai ? Regardons. Beaucoup de gens ont été assez sceptiques à ce sujet. Et l'une des choses que nous avons faites lors de la rédaction du livre sur les topologies d'équipes a été d'examiner la recherche universitaire dans ce domaine.
[00:04:31] En 2012, un article de recherche a été publié, euh, par Mac et ses collègues, et ils ont mené une étude sur les logiciels propriétaires et open source. Et voici l'une de leurs conclusions. Les produits ont tendance à refléter l'architecture des organisations dans lesquelles ils sont développés. Cette dynamique se produit parce que les structures de gouvernance des organisations, les routines de résolution de problèmes,
[00:04:56] et les modèles de communication limitent l'espace dans lequel il recherche des solutions.
[00:05:05] Ils ont en fait utilisé une matrice de structure de conception pour analyser les relations de limite et d'interface entre toutes sortes de logiciels différents. Il y a beaucoup de détails si vous lisez l'article original.
[00:05:18] Euh, nous n'allons pas tout passer en revue maintenant, vous serez ravi de le savoir. Leur principale conclusion était : « Nous trouvons des preuves solides pour étayer l'hypothèse selon laquelle l'architecture d'un produit tend à refléter la structure de l'organisation dans laquelle il est développé. » C'est donc pour le logiciel. Et il y a d'autres études à part celle-ci, mais c'est celle que nous allons examiner aujourd'hui. En 2004, une étude a examiné la conception et la fabrication de moteurs à réaction pour les avions.
[00:05:48] Et ils ont examiné les problèmes liés à l'endroit où les limites des composants se trouvaient à l'intérieur des moteurs à réaction.
[00:05:59] Et dans leur conclusion, ils ont déclaré : « Nous fournissons des preuves empiriques que l'ambiguïté des produits existe, et qu'elle est plus susceptible d'être présente à travers les frontières organisationnelles et système. » C'est une citation de leur article, en fait, cela dit quelque chose de très similaire : s'il y a un décalage entre l'organisation et l'architecture du produit, il y aura des problèmes. Et une autre étude en 2010, portant sur la conception et la fabrication de voitures, donc l'industrie automobile, de et ses collègues. Et dans leur étude, ils ont finalement conclu que
[00:06:35] les déséquilibres, les différences entre l'architecture produit et la structure organisationnelle, sont positivement associés aux problèmes de qualité. Cela signifie encore une fois que si vous avez un déséquilibre entre votre organisation et l'architecture de votre produit,
[00:06:49] il y aura probablement des problèmes.
[00:06:53] Maintenant, nous pouvons tirer parti de cet effet miroir de la loi de Conway.
[00:06:59] Et nous pouvons le faire en utilisant quelque chose appelé la manœuvre de Conway inversée.
[00:07:05] Maintenant, nous devons dire très clairement, ce n'est pas quelque chose que vous faites sur l'autoroute. Ce n'est pas quelque chose que vous faites avec votre voiture et que vous faites une manœuvre étrange, ce n'est pas de cela que nous parlons. En fait, ce que nous disons, c'est que nous devrions concevoir l'organisation pour qu'elle reflète l'architecture système souhaitée. Donc, si nous savons qu'il existe un type d'architecture système qui aiderait à répondre aux besoins de l'entreprise et aux besoins des clients, alors comment pouvons-nous organiser notre organisation de manière à ce qu'elle reflète, de sorte que les voies de communication reflètent, l'architecture souhaitée. Et si vous y pensez, c'est fondamentalement une hérésie, c'est fondamentalement, vous savez, si je disais cela, euh, je devrais être brûlé comme une sorcière à l'époque médiévale, au Moyen Âge, n'est-ce pas ? C'est, c'est fondamentalement une hérésie, c'est fondamentalement hérétique par rapport à l'architecture logicielle traditionnelle.
[00:07:54] Où nous le concevons très soigneusement, nous ne pensons pas vraiment à l'organisation et ensuite nous demandons aux gens de construire cette merveilleuse architecture. Il s'avère que nous devons concevoir notre organisation et notre architecture logicielle en même temps. C'est le même processus, en fait, lorsque nous avançons rapidement.
[00:08:14] Qu'est-ce que cela signifie en pratique ? Prenons un petit exemple. Euh, regardons un exemple de la loi de Conway en pratique. Ceci est une version simplifiée.
[00:08:25] Imaginez pour commencer que nous avons quatre équipes logicielles, A B C D. Elles ont un front-end et un back-end, donc le front-end en bleu, le back-end en vert. Et il y a une seule équipe de base de données, DBA, en orange.
[00:08:43] Et chaque développeur front-end de chaque équipe fait un travail, puis le transmet au développeur back-end, ils font un travail, puis le transmettent à l'équipe de base de données en disant : "Hé, pouvez-vous mettre à jour la base de données ?" C'est, si c'est la voie de communication dans l'organisation, alors prenons ce diagramme et faisons-le pivoter de 90 degrés. L'architecture logicielle probable ressemblerait à ceci.
[00:09:05] Nous aurions quatre applications distinctes, mais toutes partageant la même base de données. Si c'est ce que tu veux, c'est bien.
[00:09:15] Mais de nos jours, nous ne voulons probablement pas une architecture comme celle-là car elle limite le flux. La base de données partagée aura tendance à provoquer des goulots d'étranglement, elle aura tendance à provoquer des conflits. Nous aurions tendance à vouloir une architecture qui ressemble un peu plus à cela. Où nous avons des bases de données indépendantes pour différentes applications ou différents services. Si nous voulons ce genre d'architecture, alors changeons notre architecture organisationnelle pour qu'elle corresponde à cela. Donc, ce que nous allons faire, c'est simplement prendre ce diagramme et le faire pivoter de 90 degrés, et là, nous avons l'architecture organisationnelle. Nous avons donc maintenant une capacité de base de données ou une capacité de données au sein de chaque équipe. Ceci est un exemple très simpliste, mais c'est une sorte d'illustration de ce que nous voulons dire. Euh, par la loi de Conway en pratique.
[00:10:03] Ruth Malan a remporté plusieurs prix pour son travail sur l'architecture logicielle et elle le formule ainsi. Si l'architecture du système et l'architecture de l'organisation sont en désaccord, si elles sont différentes, l'architecture de l'organisation l'emporte. Elle l'a donc exprimé encore plus fortement que Mel Conway dans l'article original.
[00:10:22] La chose essentielle à réaliser ici est que la conception de l'organisation contraint réellement le type de solutions que nous pouvons trouver. Donc, la conception organisationnelle est une contrainte sur l'espace de recherche de solutions. Maintenant, c'est en quelque sorte un problème stratégique, potentiellement un problème stratégique. Si nous nous trompons dans la conception, si notre organisation a été mise en place d'une manière qui a pu avoir de bonnes intentions, mais qui va à l'encontre des architectures dont nous avons besoin, alors cela contraint réellement l'ensemble de l'entreprise, potentiellement l'ensemble de l'entreprise, pour trouver le bon type de solutions.
[00:11:06] Et quels types de principes devrions-nous avoir en 2020 et au-delà lorsque nous concevons une organisation ? Quels types de principes avons-nous besoin si nous avons beaucoup de logiciels dans l'organisation, si le logiciel est un aspect clé du fonctionnement de notre organisation ? Et vous savez, de nos jours, le logiciel est un aspect clé de très, très nombreuses organisations, même si vous ne construisez pas ou ne vendez pas de logiciels, le logiciel en est un aspect clé. Donc, notre point de départ dans les topologies d'équipes est un flux de changement rapide. Nous devons avoir un flux rapide de changements du système logiciel sur une base continue. Nous ne construisons pas un logiciel pour ensuite l'expédier, ce n'est pas discret. C'est un flux continu de changements, toujours, sur une base continue. Mais ce n'est pas seulement un changement allant dans une seule direction.
[00:12:00] Nous devons écouter ce qui se passe dans l'environnement réel, en production, et ramener cette information à l'organisation pour que nous puissions modifier ce que nous faisons d'une certaine manière. Donc, cet ancien modèle de développement, faire du travail et ensuite le passer à une équipe d'infrastructure opérationnelle ne fonctionne pas. Cela ne fonctionne pas car à ce point de transfert, les choses tournent mal. En fait, dans de nombreuses organisations, il y avait beaucoup, beaucoup de fonctions distinctes.
[00:12:35] Développement, tests, une sorte de transition ou de publication, en direct. Et quelque chose allait mal à chacune de ces étapes typiquement. Et tout aussi important, lorsque nous avons de nombreux transferts, cela provoque des retards. Cela entraîne une perte de temps, euh, en fait, nous avons de nombreuses files d'attente différentes au sein de l'organisation. Et cela provoque un énorme temps d'attente lorsque nous essayons de faire quelque chose. Donc ces transferts peuvent tuer un flux de changement. Ce que nous devons faire, c'est tuer ces transferts. Ce dont nous avons besoin, c'est une équipe.
[00:13:14] qui a une responsabilité de bout en bout pour tous les aspects d'une partie du système logiciel. Y compris non seulement les fonctionnalités, mais aussi ce que le logiciel fait, fournit. Mais aussi les autres aspects, comme notre capacité à le publier, notre capacité à le tester, notre capacité à le faire fonctionner correctement en production. Notre capacité à le prendre en charge. Donc la capacité de publication, la testabilité, l'opérabilité, la supportabilité, toutes ces choses doivent être prises en charge par cette équipe de bout en bout.
[00:13:46] Et donc une équipe produit, parfois appelée équipe produit, a cette responsabilité de bout en bout. Elle possède toutes les compétences et capacités nécessaires pour passer de l'idée à la construction, l'exécution, l'écoute des signaux qui se produisent dans l'environnement réel et ramener cette information à l'équipe pour pouvoir améliorer les choses.
[00:14:05] Et cela réduit, cela réduit tous ces il n'y a plus de transferts maintenant. Nous ne confions pas ce travail à une autre équipe, ce qui permet un flux de changement rapide. Et dans le livre, nous appelons dans le livre sur les topologies d'équipes, nous appelons ces équipes alignées sur le flux. Ces équipes sont alignées sur un flux de changement dans l'organisation.
[00:14:23] Euh, et c'est le point de départ.
[00:14:28] Si cela, si une équipe comme celle-ci peut, euh, construire et faire fonctionner un système entièrement par elle-même, alors c'est tout ce dont nous avons besoin. Mais généralement, dans une organisation plus grande, nous finissons par avoir ce qu'on appelle une plateforme, ce qui nous donne un certain type de capacités sous-jacentes. Cela peut concerner les données, la conception, l'infrastructure, l'automatisation, ce genre de choses. Ainsi, cette équipe, cette équipe alignée sur le flux, peut se concentrer sur le domaine d'activité ou sur la chose principale sur laquelle elle est concentrée, et elle n'a pas à se soucier des détails des choses qui ne sont pas liées à son objectif principal.
[00:15:06] Maintenant, nous nous retrouvons potentiellement avec plusieurs équipes rationalisées comme celle-ci, partageant certains aspects d'une plateforme.
[00:15:15] Euh, mais ces équipes de ligne de flux sont substantiellement indépendantes. Elles n'ont pas besoin, elles ne dépendent pas l'une de l'autre. Nous avons aligné l'architecture logicielle pour avoir plusieurs applications et services indépendants, faiblement couplés, avec une interface bien définie vers une plateforme. C'est donc notre architecture d'organisation et notre architecture d'équipe, pardon, l'architecture organisationnelle et l'architecture logicielle en même temps. C'est un diagramme de, euh, effectivement le même diagramme représente à la fois l'organisation et l'architecture logicielle.
[00:15:54] Maintenant, il y a une limite à la taille de ces équipes. Et c'est parce que
[00:16:00] il existe des limites humaines naturelles à la confiance que nous pouvons avoir envers les autres. Robin Dunbar est un anthropologue britannique qui a mené de nombreuses recherches dans ce domaine. Et il parle du réseau social d'un individu. Nous ne parlons pas seulement des médias en ligne comme Twitter et autres, nous parlons des relations avec d'autres personnes dans le monde réel. Et sa découverte, qui est assez célèbre, est que le réseau social d'un individu est typiquement d'environ 100 à 200 individus. Généralement, le nombre 150 est utilisé. Nous pouvons donc avoir des relations significatives avec environ 150 personnes. Fait intéressant, Robin Dunbar a répété ce travail sur les réseaux sociaux en ligne comme LinkedIn, Twitter et Facebook et a trouvé un modèle similaire : généralement, nous n'interagissons en fait qu'avec environ 150 autres personnes dans ces différents espaces. Donc, euh, il existe de nombreux types de limites de confiance de groupe, euh, qui ont été découvertes par un processus de recherche anthropologique, euh, par des personnes comme Robin Dunbar. Mais en fait, nous pouvons voir des limites de confiance similaires, euh, si nous regardons euh l'armée. Euh, et vous trouverez un article très intéressant intitulé 'Points d'inflexion sociaux' par euh par quelqu'un appelé Ben Ford. Ben Ford, euh, faisait partie de l'armée britannique dans une force d'élite britannique, il a donc une expérience directe de ce que c'est de travailler dans une équipe très performante dans un contexte militaire. Il travaille maintenant dans le développement de logiciels, aidant les gens à rendre leurs organisations plus efficaces et à comprendre la dynamique du développement de logiciels. Et il parle de ces points d'inflexion sociaux.
[00:17:55] qui existent dans les regroupements militaires. L'armée, dans l'armée, par exemple, euh, les armées ont eu des centaines, voire des milliers d'années pour trouver ces types de tailles de regroupement qui fonctionnent efficacement. Et il en décrit au moins trois : un groupe de huit personnes dans l'armée britannique s'appelle une section. Et c'est à peu près la taille d'une partie de chasse des temps anciens.
[00:18:28] Un groupe de 30 à 50 personnes est appelé, dans l'armée, une troupe, et cela correspond à peu près à une sorte de tribu de gens de nouveau des temps anciens. Et un groupe d'environ 100 à 150 personnes est appelé une compagnie, en termes militaires, et c'est à peu près la taille d'un village. Maintenant, voici ce qui est vraiment intéressant. Nous avons ce nombre 150, qui est le nombre de Dunbar, le nombre de personnes avec lesquelles nous pouvons avoir des relations significatives. Au Royaume-Uni, en Grande-Bretagne, nous avons de très anciens registres qui remontent à, euh, près de mille ans. Et si vous regardez ces registres, la taille typique d'un village en Angleterre à l'époque était de 150 personnes. Il y a eu un recensement et un ensemble de registres, des personnes ont été comptées. Nous avons donc des données remontant à plusieurs centaines d'années.
[00:19:20] Cela suggère que ces limites de confiance sont très cohérentes dans de nombreuses parties différentes de la société humaine. D'accord, revenons à un contexte organisationnel de livraison de logiciels. S'il existe un ensemble de limites de confiance en place, cela a une forte implication sur l'efficacité avec laquelle nous pouvons organiser l'organisation, sur la façon dont nous pouvons regrouper les choses. Pour permettre un flux de changement rapide. Si vous voulez le flux de changement le plus rapide possible, nous devons avoir la plus grande confiance possible. Et c'est un groupe d'environ huit personnes. Cela remonte au point d'inflexion social que nous avons vu de Ben Ford. Et c'est ce plus petit groupe de huit qui a été prouvé par l'armée pendant des centaines d'années. C'est la plus grande confiance, cela va nous permettre de déployer le changement le plus rapidement. Mais il y a d'autres regroupements légèrement plus grands que celui-là, euh, jusqu'à une limite d'environ peut-être 100, environ 50 personnes, c'est plusieurs équipes, mais pas beaucoup d'équipes. Et il y a un autre groupe d'environ 150 personnes. Encore une fois, c'est plusieurs groupes d'équipes, mais ce n'est pas infiniment grand. Le point clé ici est que la dynamique de la confiance peut changer lorsque nous franchissons l'une de ces limites de Dunbar ou l'un de ces points d'inflexion sociaux. Et nous devrions nous attendre à ce que différents types de règles, différents comportements émergent. Nous ne pouvons pas simplement continuer à faire grandir l'équipe. Nous devons comprendre la, euh, l'effet de ce type de dynamiques de confiance en jeu dans l'organisation. Ainsi, nous ne pouvons pas avoir, par exemple, les RH ou le département des personnes qui assignent simplement de plus en plus de personnes à ces regroupements, car la dynamique de confiance changera, cela affectera notre flux de changement, nous commencerons également à affecter le type d'architecture logicielle que nous construisons parce que nous faisons grandir certaines de ces équipes trop grandes et cela a un impact direct sur l'architecture logicielle probable qui va émerger.
[00:21:20] Il y a une étude de cas très intéressante dans notre livre sur les topologies d'équipes, concernant une entreprise britannique appelée Autotrader. Euh, et euh ils, c'était il y a quelques années, quand ils refaisaient, reconstruisaient et réaménageaient leur bureau, leur siège social. Euh, ils voulaient tirer parti de la loi de Conway et de ce type de mise en miroir socio-technique. Ils voulaient permettre un flux rapide de changements dans chacune de leurs trois activités. Euh, pour les besoins de la discussion d'aujourd'hui, nous appellerons ces différents domaines d'activité : la vente de voitures particulières, la vente de voitures commerciales et la location de voitures. Et ils voulaient avoir le flux de changement le plus rapide dans chacun de ces différents domaines d'activité.
[00:22:03] Ce qu'ils ont fait, c'est qu'ils ont mis toutes les personnes qui travaillaient sur la vente de voitures particulières au même étage. Toutes les personnes qui travaillaient dans la vente de voitures commerciales au même étage et toutes les personnes qui travaillaient sur la location de voitures au même niveau, au même étage du bâtiment. Quand je dis tout le monde, je veux dire tout le monde. Support, ingénierie, opérations, juridique, RH, marketing, ventes, tout le monde était au même étage. Ils étaient donc tous concentrés sur un flux de changement dans cette unité commerciale particulière, dans ce domaine particulier.
[00:22:44] Et ils n'avaient pas un groupe de personnes pour le marketing ou les ventes tous assis ensemble travaillant sur ces trois domaines différents. Ils l'avaient divisé par type de domaine d'activité. C'est un exemple très intéressant de réflexion sur les effets de la communication et des limites de confiance au niveau organisationnel lorsque l'on pense à un flux de changement rapide. Cela signifie également que nous devrions peut-être faire attention à la façon dont notre communication numérique, notre communication en ligne est configurée. Si nous utilisons quelque chose comme Slack ou Microsoft Teams ou quelque chose comme ça. C'est le genre d'environnement numérique. Qu'est-ce que ça fait ?
[00:23:21] Eh bien, peut-être que nous avons réellement besoin d'avoir des groupes Slack ou de communication séparés pour différentes parties de l'organisation. Parce que sinon, nous pourrions ne pas avoir le bon type de confiance au sein de ce regroupement. Nous pourrions perdre confiance parce qu'il y a trop de personnes à l'intérieur de ce groupe. C'est quelque chose que les organisations commencent à explorer maintenant. Peut-être que vous avez un Slack séparé pour chacun de ces trois groupes. Cela signifie certainement que cela les garderait significativement séparés.
[00:23:54] Donc, de manière cruciale, nous devons co-concevoir, nous devons concevoir ensemble l'organisation et l'architecture système. C'est donc un effort conjoint, un effort conjoint entre ingénieurs, architectes et personnes qui prennent des décisions concernant les équipes. Il s'agit donc des managers, des RH, des personnes chargées des installations, Ils prennent tous des décisions sur l'endroit où les gens travaillent dans une organisation, que ce soit un bâtiment physique ou un regroupement au sein d'un outil de discussion ou d'une limite d'équipe ou quelque chose comme ça. Nous devons travailler sur ces choses ensemble, ce n'est pas possible, ce n'est pas sensé de les séparer.
[00:24:36] Et fondamentalement, c'est alors une approche axée sur l'équipe d'abord.
[00:24:40] Donc, c'est en gros ce qui vous donne un aperçu de pourquoi les RH pourraient accidentellement concevoir l'architecture logicielle si nous ne pensons pas à la place des gens, si nous ne pensons pas, si nous n'adoptons pas une approche axée sur l'équipe, nous pourrions accidentellement influencer et concevoir des aspects du système logiciel. Donc, ne faisons pas cela. Adoptons une approche axée sur l'équipe, comprenons que nous devons concevoir ces choses ensemble, euh, et tirons parti de choses comme la manœuvre de Conway inversée pour nous aider à le faire.
[00:25:14] Comme je l'ai mentionné, le livre est disponible en ligne. Si vous allez sur teamtopologies.com/book, vous trouverez de nombreuses librairies du monde entier vendant le livre. Nous travaillons actuellement sur un manuel spécifique aux équipes à distance, c'est-à-dire aux modes de travail à distance tels que nous nous trouvons actuellement dans la pandémie. Euh, nous espérons que cela sortira bientôt. Nous travaillons avec IT Revolution, l'éditeur du livre à ce sujet. Et euh, certainement au début, ce sera un téléchargement PDF gratuit.
[00:25:47] Donc, si vous souhaitez plus d'informations, rendez-vous sur notre site web. Il y a beaucoup de matériel et d'apprentissage, de vidéos et de diapositives et toutes sortes de choses comme ça sur le site web teamtopologies.com.
[00:25:59] Nous proposons des formations adaptées au télétravail, nous le faisons depuis mars. Euh, contactez-nous si cela vous intéresse.
[00:26:06] Euh, nous avons aussi quelques évaluations.
[00:26:09] Beaucoup de ressources en ligne. Euh, nous avons aussi un dépôt GitHub pour des modèles et du code et des choses comme ça, donc vous pouvez nous envoyer une pull request et nous modifierons les choses. Utilisation gratuite, euh, librement disponible, en quelque sorte open source. Alors, Merci beaucoup. C'était super d'être ici. C'est la fin de ma présentation et j'attends maintenant les questions avec impatience.

Transcription (Traduit)