Comment gouverner ses décisions d'architecture ?

0:14 Bonjour à toutes et bonjour à tous. Je suis ravi d'être avec vous pour ce premier Meetup Tech.Rocks de l'année, inspiré de certaines problématiques soulevées au sein de la communauté architecture, comme l'a dit Noémie, cette communauté dans la communauté Tech.Rocks. Il y a un sujet qui est revenu assez souvent, c'est comment gérer ces décisions d'architecture, comment les initier, les suivre, les réviser et surtout les diffuser. Quel doit être le format? Est-ce qu'on s'appuie sur un template? Comment en débattre? Dans quelle instance débattre de ces décisions d'architecture? Comment garantir la mise en application, la conformité de ces décisions? Comment accoster aussi cette gouvernance d'architecture avec les pratiques projet que vous avez en place? On parle de ces pratiques agiles qui prônent souvent d'éliminer les scénarios plutôt que d'en choisir en amont. Donc, comment on s'adapte? Et quel outil adopter pour maximiser l'efficacité? Donc, c'est des questions auxquelles on va tenter de répondre aujourd'hui au sein de ce meet-up Tech.Rocks avec le témoignage de Célia et de Thomas.

1:24 Que je vais laisser se présenter. Donc Célia, bonjour. Est-ce que tu peux te présenter? Quel est ton rôle? au sein de France Travail. Bonjour à toutes et tous. Moi, je suis Célia Carceller-Kémy, je suis architecte d'entreprise chez France Travail. Dans mes missions, j'ai pour objectif de faire pivoter les pratiques d'archives vers une approche plus continue, c'est-à-dire au service de l'autonomie des équipes produites. Très bien, merci. Thomas, bonjour. Peux-tu te présenter? Quel est ton rôle au sein de Hokla? Bonjour à tous. Thomas, je suis situé au confinateur de Hokla. On est la branche santé du groupe Théodo, pour ceux qui connaissent. Nous, on est une quarantaine de profils ingénieurs. On développe surtout des applications à destination de professionnels de santé et de patients. Et je vais essayer d'illustrer un petit peu cette thématique avec deux, trois exemples d'architecture, de décisions d'architecture qu'on a eu le point sur nos projets. Ok, super, merci Thomas, merci Célia. Et donc pour ma part, moi je m'appelle Frédéric, je suis architecte au sein du programme interopérabilité des systèmes d'information du groupe VYV,

2:33 qui a pour objectif de travailler sur des architectures d'intermédiation et permettre la mise en place de passerelles d'échange entre les différentes maisons du groupe, parce qu'il y a beaucoup de maisons dans le groupe. Et ce, pour proposer à nos adhérents une offre complète de services, d'assurance, de soins, d'accompagnement, de logement. L'objectif, c'est de permettre d'agir sur l'ensemble des déterminants de santé d'un adhérent. Pour essayer de faire simple. N'hésitez pas à poser vos questions. Vos questions. dans la partie Q&A. On essaiera de répondre au fur et à mesure si des questions coordonnent avec les sujets abordés. Pour commencer ce meeting, je vais juste poser le contexte, donc très rapidement, parce qu'on va vite laisser la place aux retours d'expérience qui sont plutôt chers en fait à la communauté Tech.Rocks, mais je vous propose une démarche d'architecture schématisée ici par quelques architectes qui travaillent autour d'un récit que l'on a mis en place, d'ailleurs avec certaines personnes de la communauté Tech.Rocks, qui s'appelle l'épopée d'un architecte.

3:33 Et je ne vais pas rentrer dans les détails parce que ce n'est pas l'objectif, vous pouvez aller découvrir l'épopée. Mais l'objectif, c'est de vulgariser, de démystifier en fait une discipline, de la mise en place d'une discipline d'architecture d'entreprise au sein d'une organisation. Et l'objectif sera de suivre au jour le jour un architecte qui va vous expliquer simplement, pour des profils plutôt métiers, chacune des étapes de la démarche pour mettre en place une discipline d'architecture. Donc, où se situent les ADR dans cette démarche? On commence par le centre, en fait. Vous avez les principales couches qui constituent la capacité d'une entreprise à apporter de la valeur à son client, qu'elle soit métier, solution ou technique. On ne rentre pas dans les détails, il y a déjà une première étape qui est déjà en ligne. À gauche, on a la partie organisation, qui est l'équipe. Le rôle, la comitologie, les premiers liens entre les entités. Et à droite, ce qui va nous intéresser, plutôt la partie opération, dans laquelle il y a deux grandes missions d'un architecte. Donc la première, c'est l'architecture. Cela correspond à l'art modélisé le monde réel afin de bâtir une espèce de terrain de jeu virtuel.

4:40 C'est souvent des cartes qui vont nous permettre de simuler des changements et visualiser les impacts que cela aura sur votre système, qu'il soit fonctionnel, solution ou potentiellement technique. Et la seconde, c'est assurer la gouvernance. La gouvernance, ça se traduit par la mise en place mise en place, la mise en œuvre plutôt d'une domaine d'activité que l'on va impacter, donc via le lancement de projet, en proposant des socles déjà éprouvés, donc on va mettre en place des référentiels qui vont permettre de partir, ne pas partir de zéro, des pistes d'architecture qui vont donner un sens, un schéma directeur, et la mise en place de checkpoints pour assurer justement la conformité, c'est important, la conformité et s'assurer l'alignement des livrables par rapport aux objectifs fixés. Et dans cette phase de gouvernance, certaines hypothèses que l'on a émises durant la phase d'architecture ne peuvent pas être assurées sur le terrain. On est confronté à certains problèmes, ce qui va nous obliger à nous adapter, à revoir toutes les validations qu'on avait préétablies et donc remettre, enfin émettre plutôt, de nouveaux changements.

5:48 Qui devront être validés par des décisions d'architecture. Alors, qu'est-ce que le processus décisionnel? Donc, on va le détailler. Là, je vais passer rapidement et après, je laisserai la main aux autres speakers. Donc, l'objectif, en fait, c'est de déterminer un cycle. D'abord, on va lier la prise de décision à un contexte, un projet, un changement, un besoin ou une exigence. Pour décider, nous devons être éclairés. Donc, pour ça, on va aller récolter des informations. Ça, c'est la base, en fait, du processus de décision. Comme une démarche un peu de design thinking, on va avoir une étape de divergence qui va nous permettre de définir plusieurs alternatives. réaliste par rapport aux besoins et surtout à notre faisabilité. Ensuite, on va évaluer par une phase de convergence qui va apporter tous les arguments qui vont permettre d'évaluer, de choisir des alternatives, ou du moins l'alternative peut-être la plus judicieuse. Enfin, la phase de décision.

6:51 C'est là qu'on va écouter, partager, analyser pour s'accorder autour d'une décision. Cette décision peut et sûrement doit être accompagnée de conditions, de réserves, voire une durée de mise en place. Pourquoi? Parce que soit c'est une décision qui doit servir à atteindre une architecture intermédiaire, soit c'est une décision qui peut sembler plus pérenne et qui pourrait être transformée en principe d'architecture, qui deviendra un référentiel pour les futurs projets. Donc à cette étape, il est encore possible de garder plusieurs alternatives, n'impactant pas le court terme, qui pourraient être statuées plus tard à la suite de décisions ou d'actions. On parle alors de mettre en place des architectures de transition. Et donc pouvoir relancer cette boucle de décision. Donc ensuite, il faut passer à l'action. Pour s'assurer de ça, il faut définir des porteurs, des contributeurs, des sponsors, des personnes qui vont le faire. Donc, ça peut vous rappeler les fameux racis qu'on a dans certains projets. Et enfin, s'assurer de la pérennité et de garder les possibilités de relancer un second tour, on va mettre en place du versionning.

7:57 Sur ces décisions, c'est souvent indispensable pour organiser. plusieurs passages et surtout assurer l'historisation des changements. Voilà, donc pour assurer ce cycle, il faut un outillage adapté. Donc là, je vous ai mis un lien vers un outil que j'utilise qui s'appelle Arcadis. Donc, c'est une solution plutôt complète sur la démarche qui permet d'assurer l'ensemble de la gouvernance d'un projet, de la transformation, de la modélisation jusqu'à sa mise en conformité. Je vous mets le lien parce que c'est un produit intéressant que j'utilise, mais bien sûr, Célia et Thomas vous présenteront également d'autres produits. Voilà, voilà. Je passe d'ailleurs la parole à Célia qui va vous présenter la gestion de ces ADR dans le cadre d'une démarche d'architecture continue. Je te laisse la parole, Célia, est-ce que tu veux prendre la main sur les slides? Non, je vais te laisser faire, ça va bien. Ok, ça marche. Si, ça te convient aussi. Donc, France Travail, c'est l'ex-Pôle emploi pour ceux qui ne connaissent pas depuis le 1er janvier. Sur la diapo d'après, je vous ai positionné nos services en ligne.

9:02 Et en fait, l'idée pour moi, c'était de vous fournir quelques éléments dimensionnants pour vous... Prenez en compte un peu notre contexte. France Travail, c'est 900 000 offres d'emploi disponibles chaque jour sur Pôle emploi.fr. C'est environ 20 millions d'offres qui sont diffusées chaque année. Ça représente plus de 59 000 professionnels mobilisés pour l'emploi et environ 33 milliards d'euros versés chaque année. Et dans le système d'emploi, Ça va se traduire par 1 500 produits IT, environ 3 000 composants actifs qui sont hébergés dans le système d'information, 260 équipes produits et 1 500 collaborateurs. Donc, voilà pour la big picture. Ensuite, sur la diapo d'après, quelques informations sur l'orientation de la DSI pour les années qui viennent. Et moi, je voulais surtout vous partager le discours de notre directeur général qui dit, voilà, nous, Cette année qui s'ouvre sera une année de préparation, d'expérimentation, d'accélération.

10:04 En 2024, on va avoir le lancement de nombreux tests qui doivent nous permettre d'éprouver de nouvelles solutions pour aller vers les usagers, notamment ceux qui sont éloignés de l'emploi. Et favoriser un retour à l'emploi durable de chaque personne et faciliter les recrutements de chaque entreprise en ayant à cœur d'innover avec nos partenaires du réseau pour l'emploi. Ça veut dire que notre système d'information va se transformer en plateforme et elle va le faire progressivement autour d'équipes produits responsables et autonomes. Et donc, le déploiement de pratiques d'architecture continue, comme les ADR, du coup, nous permet de faciliter l'alignement à l'échelle des équipes autour de nos enjeux SI. Ce qui se dessine parce qu'en fait, on a un rendez-vous qui est les évolutions législatives qui entrent en vigueur le 1er janvier 2021. Alors, pour faire ça, sur la diapo d'après, on s'est inspiré d'un framework qui s'appelle Continuous Architecture. En synthèse, lui, ce qu'il préconise, c'est d'avoir un architecte référent plus près des équipes produits pour faire le lien avec l'écosystème SI.

11:12 Et on lui met à disposition un certain nombre d'outils pour accompagner ses équipes à en gagner en autonomie et en simplicité à travers un certain nombre d'ateliers. Le premier, c'est un cadre de collaboration. L'idée ici, c'est de nous aligner collectivement sur le patrimoine de l'équipe. ses enjeux, ses défis d'architecture, et identifier avec elle quel est son niveau d'autonomie pour relever ses challenges. Et si l'équipe dit qu'effectivement, elle a besoin d'un accompagnement, on bascule sur un plan d'accompagnement, suspense, pour identifier les pratiques ou les outils qui lui permettront de répondre à ses enjeux. L'objectif ici, c'est d'aller piocher dans une boîte à outils des kits prêts à l'emploi qui leur permettent de faciliter la prise de décision d'architecture. Pareil, si ça vous intéresse, je vous ai mis le lien pour accéder à ces informations-là. Concrètement, chez Pôle emploi, nous, ça va se traduire par… Voilà, on a matérialisé tout ça autour de ces six dimensions qui représentent un peu les activités d'architecture assez classiques.

12:25 Et donc, la décision est vraiment le cœur de la matrice. Nous décidons au bon moment. Ce bon moment, pour nous, c'est le dernier moment responsable. C'est celui qui va nous permettre de voir loin, mais évidemment sans anticiper les besoins. Et c'est lui qui va permettre aux équipes d'évoluer vite pour développer la valeur de leurs produits et prendre en compte les changements. Chaque dimension ici met à disposition du coup ces kits prêts à l'emploi pour aider à prendre les meilleures décisions dans notre contexte SI. Et en fonction des objectifs recherchés pour construire, on va aller piocher dans des standards. du marché que vous connaissez peut-être, comme DDD, les WordLemaps ou encore Team Topologie. Ensuite, petit focus, je vous amène directement sur la diapo d'après, dans notre espace Confluence. Donc, ça peut peut-être vous surprendre, les équipes France Travail ont choisi Confluence pour tracer leurs décisions d'architecture.

13:27 Et c'est un outil qu'elles ont préféré plutôt que Git ou d'autres qui sont peut-être plus classiques. Parce que ça correspond parfaitement au positionnement des ADR chez nous, qui sont plutôt utilisés comme un outil de facilitation. Pour mieux collaborer autour de la prise de décision avec les métiers, les experts techniques ou même entre équipes. Parce que finalement, une bonne décision, c'est quand il y a les bonnes personnes autour de la table quelque part. Concrètement, comment ça se passe? Dans Confluence, sur la diapo d'après, nous, on a créé un template qui permet d'activer, quel que soit l'espace privilégié de l'équipe, une nouvelle décision d'architecture. Et ce que je vous propose, c'est du coup d'aller consulter une décision d'architecture au sein d'une équipe. Et je vous emmène du coup chez les Monstreuils. Les Monstreuils, c'est une de nos équipes produits. Et pouvons mettre en situation un petit peu, voilà, ce jour-là.

14:31 Avec cette équipe de FAB, notre objectif, c'est vraiment de nous approprier le template. Pour eux, la décision était posée, il n'y avait pas de suspense. Et on voulait juste la formaliser. Donc ici, on est sur la première étape. Ce qu'on voit, c'est qu'on accède directement à la doc s'il y a besoin. On a un petit tableau de synthèse qui nous permet de faire un certain nombre de listes et deux informations qui sont un petit peu plus importantes. importante pour nous, qui est c'est quoi le type de l'ADR, plutôt métier, applicatif ou technique, et où est-ce qu'elle en est dans son cycle de vie, puisque une décision d'architecture, en fait, c'est une documentation vivante et elle évolue en fonction de la vie du produit. Une fois qu'on a fait ça, ce qu'on va voir avec l'équipe sur la diapo d'après, c'est qu'on va noter finalement les participants à cette prise de décision. Donc ici, c'est le leader technique qui la pose.

15:35 On retrouve des personnes de l'équipe de dev, le PM, un architecte. Et on partage le contexte métier et le problème à traiter. Et là, généralement, à ce moment-là, on a une première surprise, c'est qu'en partageant, en écrivant ces informations, on se rend compte que l'équipe se réaligne sur les objectifs et c'est super intéressant parce que ça permet de s'assurer qu'on comprend tous le même message. On identifie aussi les facteurs de décision, c'est-à-dire les critères qui vont permettre de s'assurer que la décision sera la bonne et un certain nombre de critères quelquefois un peu objectifs aussi pour évaluer les différents scénarios d'architecture. Et ici, comme la décision était déjà prise, on l'a aussi liée à l'US pour permettre aux devs, s'ils ont besoin, de remonter jusqu'à la décision, histoire de comprendre un peu le sens de... De la story qu'ils vont devoir développer. Une fois qu'on a fait ça, on va basculer sur une deuxième étape, sur la diapo d'après, qui s'appelle la description des options.

16:43 Et ici, deuxième surprise, l'équipe avait déjà choisi sa solution. Et pour eux, il n'y avait pas de suspense, sauf qu'en favorisant le dialogue, ils se rendent rapidement compte que d'autres options sont possibles. Ils analysent et ils affinent un peu leurs facteurs de décision. Et en confrontant ces scénarios aux facteurs de décision, naturellement, ils s'alignent sur une nouvelle solution qui est beaucoup plus pérenne et beaucoup plus en phase avec leurs enjeux. Et à l'issue, on se retrouve avec une meilleure décision pour les métiers et aussi un engagement fort de l'équipe pour l'implémenter. Étape d'après, finalement, c'est la dernière. On reporte la décision sur le template et avec une analyse de l'impact pour savoir si une escalade est nécessaire pour la dérisquer en revue de perte. Donc ici, ce n'était pas le cas. On est vraiment sur une décision qui est relativement simple et qui n'a pas d'impact sur d'autres produits.

17:45 Et ce qu'on fait aussi généralement, c'est qu'on recommande de tracer les conséquences de la décision qui peuvent certaines fois avoir des adhérences de planning avec d'autres équipes ou s'insérer dans une trajectoire avec de la data épurée. Donc, on le préconise parce que c'est plutôt une bonne pratique. Dernière petite étape sur ce template, quand il y a besoin, on peut aussi tracer les éléments d'action qui sont nécessaires pour dérisquer la décision, parce que quand il y a une analyse, quand plusieurs scénarios sont posés, il peut y avoir un certain nombre de POC à réaliser, et c'est bien d'en avoir une petite trace, surtout que Confluence fait plutôt bien le job. Et petit point important, nous, ce qu'on conseille aussi, ce qu'on leur recommande, c'est d'utiliser des étiquettes. Et parce qu'avec ces étiquettes, derrière, on va pouvoir faire des listes d'ADR. Et c'est pour ça que sur la diapo d'après, je vous amène sur les différentes listes qu'on propose. C'est ces listes qui vont nous permettre de faciliter le partage et la recherche de décisions et à les piocher

18:53 dans la documentation des différentes équipes pour partager un peu, essayer de retrouver des situations équivalentes et s'inspirer. Et ce qu'on peut voir, c'est que du coup, on a des listes globales. Les monstres, eux, ont leur propre liste d'ADR. Donc ça, ce sont les leurs. Et on arrive aussi à construire des listes autour d'un produit en particulier pour auto-alimenter la documentation qui est consacrée au produit. Si on parle un peu gouvernance sur la diapo d'après, nous, notre objectif, c'est vraiment de décentraliser la prise de décision. Donc, du coup, on les a catégorisés un peu en fonction de leur impact au sein du système d'information. On ne va pas se mentir, il y a 80% des décisions qui ont peu d'impact et qui sont à la discrétion même des équipes. Pour les autres, ce qu'on préconise, c'est de travailler avec un architecte pour qu'il puisse intervenir en soutien.

20:00 Il y a des dérogations à faire en normes et aux standards et les accompagner pour construire des trajectoires. Et on organise aussi des revues de pairs dans des comités ad hoc, on va dire, pour les décisions qui ont des portées transverses, c'est-à-dire celles qui impactent plusieurs produits, comme des capacités, par exemple, techniques ou métiers, voire sur des décisions très stratégiques. Je voulais partager aussi avec vous deux informations un peu en conclusion de ce partage. La première, c'est des OKR sur la diapo d'après. Nous, tous les six mois, en fait, on évalue l'impact des pratiques d'architecture. Donc, ces OCR, elles ont été définies par notre communauté, quelque part. Et celles-ci, même si elles datent un peu, elles ont été calculées à peu près six mois après les premières expérimentations.

21:02 Donc la première, c'est les décisions d'architecture sont prises au bon moment, partagées au bon niveau et applicables. Et on voit qu'au bout de trois mois, on aura 11% des équipes qui prennent des décisions mesurables via des ADR. Et c'est super intéressant parce que nous, on a accompagné six équipes lors des expérimentations. Et très rapidement, les ADR ont infusé auprès d'une vingtaine d'entre elles. Donc, c'est hyper prometteur. Le deuxième OKR, c'est le colis. L'objectif des architectes adhère à une culture d'architecture continue et pratique une architecture plus cohérente, fluide et performante. Et quand on leur pose la question, recommanderiez-vous ces pratiques à un autre architecte de Pôle emploi, on a un NPS de 8,2 sur 10, donc c'est plutôt satisfaisant. Et sur le dernier OKR, qui est les équipes produits sont plus autonomes et responsables dans leur pratique d'architecture. À la question, recommanderiez-vous à une autre équipe fabricante ces pratiques pour gagner en autonomie, on a un NPS de 8,2 sur 10.

22:03 Donc, pareil, c'était plutôt… plutôt très satisfaisant comme pratique. Moi, je voulais clôturer du coup cette intervention avec quelques perspectives. Notre objectif, c'est, voilà, on a un écosystème qui est assez large et il faut qu'on continue notre déploiement auprès de ces 260 équipes. Et pour faire ça, on a adopté une logique qu'on appelait« archi as a product», c'est-à-dire que les pratiques d'archi sont considérées comme un produit au même titre que les produits IT. On met en place une véritable écoute des problèmes et des besoins de nos clients, qui sont les équipes produits, pour leur permettre d'être elles-mêmes actrices des priorités et des artefacts d'architecture. On a un enjeu à adapter les outils de gouvernance du SI aux ADR, et notamment cette volonté de proposer des tableaux de bord pour analyser les risques

23:05 directement sur les décisions qui sont prises, avec cette idée de capturer très tôt les problèmes pour pouvoir réaligner les équipes dans la bonne direction. Et puis organiser des catas aussi pour qu'on puisse progresser collectivement et dérisquer les décisions qui sont très transverses. Et puis, dernier point, c'est tout récent. On veut aussi mieux partager nos pratiques. Et on est en train de voir comment injecter dans des outils de LLM les ADR et les kits d'archi. Et là, bon, Claire, On sent que c'est prometteur, mais on a encore un peu de valeur à démontrer sur ce sujet. Donc, c'est notre dernier point en cours, je veux dire. Merci beaucoup. Merci beaucoup, Célia. N'hésitez pas à poser vos questions dans le chat.

24:09 On y répondra. Il y en a une qui vient d'arriver de Dora. On peut peut-être y répondre tout de suite, si tu le veux bien, Célia. Est-ce que vous avez eu des décisions qui sont passées d'un niveau? À un autre niveau, N1, N3, et comment avez-vous géré ce cas? C'est une bonne question. Ça peut arriver en général. On les capte grâce au tableau de bord en faisant des petits audits réguliers des décisions d'architecture. Ou alors, très souvent, c'est la majorité des cas qu'il y a même des équipes qui font appel aux architectes pour les accompagner sur les décisions. Et eux, ça va analyser l'impact très rapidement et sans erreur. Très bien, merci Célia pour ta réponse. Posez vos questions dans le chat. Et du coup, je laisse la parole à Thomas. Thomas qui va nous parler. C'est une bonne pratique d'ADR avec ses clients chez Ocla.

25:11 Je vais reprendre la main sur les slides. Je ne sais pas si ça a bien marché. Vas-y. Oui. Déjà, merci beaucoup, Célia, pour ta présentation. Je pense qu'il y aura pas mal de points qui vont se recouper et je vais essayer d'apporter un angle un peu différent aussi. Donc, pour vous présenter ce qu'on fait chez Oclat, nous, on développe des logiciels d'éducation mobile web. À destination de professionnels de santé et de patients, pour tous les acteurs de la santé. Donc nos clients, ça va être à la fois des startups, des petites boîtes, et aussi des grands comptes, des groupes pharmaceutiques, établissements de santé. Et les décisions d'architecture qu'on prend, c'est essentiellement des décisions d'architecture logicielle. Je suis en train de développer cette application. Est-ce que je vais devoir adopter plutôt ce pattern d'architecture ou quelle librairie je vais choisir pour développer mon produit, tout simplement?

26:14 Et on essaie d'adopter cette pratique à la fois sur des petits projets pour des petits comptes, des startups, mais aussi des plus gros. Donc voilà, on a quelques apprentissages à tirer de ça. Pour vous donner quelques chiffres, on fait partie du groupe Théodo, on est plus de 700 experts et nous, Donc là, les spécialistes de la santé, on est 40. Et une équipe type, ça va être un tech lead avec deux, trois développeurs et un product owner. Et c'est le tech lead qui a la responsabilité de l'architecture, de ces choix-là. Donc, c'est lui qui tire. C'est ça, d'ailleurs. Alors, j'ai essayé de théoriser un petit peu comment on gouverne finalement ces décisions d'architecture sur nos projets. Donc, comme tout modèle, il est sûrement faux, mais il a le mérite d'exister. Donc, c'est celui-là que j'aimerais vous partager. Donc, la première question qu'on se pose, c'est, OK, on va écrire un ADR pour prendre une décision d'architecture, mais c'est quoi un bon ADR? C'est quoi les critères de qualité d'un ADR pour prendre finalement les bonnes décisions? Je vais essayer de l'illustrer avec un exemple.

27:16 Ensuite, comment les équipes s'entraînent à faire des bons ADR, quelques approches là-dessus. Et pareil, comme toi Célia, on s'est posé la question de comment les diffuser. Alors peut-être à des échelles peut-être plus petites, à l'échelle d'une startup, ou ça peut être aussi à l'échelle du groupe Théodo, par exemple, de 700 personnes. Donc si je reviens un peu sur Standard, pour vous, la première question qu'on s'est posée, ce qu'on a fait, c'est qu'on a, ça fait deux ans qu'on essaie de faire des ADR, d'écrire ces documents pour prendre des décisions d'architecture. Et en les regardant, en équipe, on s'est posé la question, finalement, ça sert à quoi l'ADR? Est-ce que ça sert à prendre une décision? Est-ce que ça sert à prendre la bonne décision? Ou est-ce que ce qui est important, c'est le... Record, est-ce que ça sert à tracer la décision pour revenir dessus plus tard ? Et déjà, en fait, alors on n'est pas encore complètement au sec, en fait, finalement, sur cette question, je pense que les deux sont vrais. Mais c'est vraiment une question essentielle parce que ça drive complètement le système qu'on va construire derrière et que vous allez construire derrière. Donc, on essaie de faire des standards qui répondent un peu à ces questions.

28:20 C'est à la fois une bonne décision et pour la tracer, pour revenir dessus. Je vais essayer d'illustrer avec un petit exemple. On développe une application mobile à destination de patients qui souffrent de douleurs chroniques pour un institut de recherche, c'est l'analgesia. C'est une application mobile sur laquelle le patient va... Fréquemment renseigner ces symptômes, comment ils se portent, et on va lui proposer des activités pour supporter ces douleurs chroniques. Et du coup, sur cette application, on avait besoin d'envoyer des emails. Et du coup, on a dû se poser la question, quelle technologie on va utiliser pour envoyer ces emails-là? Donc, finalement, comment je fais pour prendre la bonne décision avec l'ADR de quelle technologie je vais choisir pour envoyer des emails à mes patients et les professionnels de santé qui ont utilisé cette solution? Donc voilà, c'est Raphaël qui a écrit ce document, donc nous on utilise nos solutions en général, mais finalement on retrouve à peu près le même format qui est représenté, c'est-à-dire...

29:26 Et du coup, la première partie de l'ADR, C'est le contexte, on va poser le problème. Et ce qui nous paraît essentiel dans cette partie, ce qu'on s'est rendu compte, c'est que le contexte doit rappeler les objectifs business. Pourquoi on le fait, mais pourquoi selon le point de vue du client, de l'utilisateur final, ce genre de choses. Donc ici, ce qu'on illustre, c'est que, voilà, pourquoi en fait on prend cette décision? Parce qu'on doit envoyer un email de bienvenue quand le patient rejoint une étude. Et... On précise bien, il y a une centaine de, a priori, une centaine de millions de patients par mois. Donc, on fait le lien avec le monde réel, finalement, de ce choix-là d'architecture. Les erreurs un peu types qu'on a remarquées, c'est les ADR qui sont techniques et qui commencent déjà par de la technicité sans faire le lien avec le business, les utilisateurs. Un truc assez classique qu'on a vu, c'est cette décision, est-ce que je vais choisir une architecture backend qui est synchrone ou plutôt asynchrone, par exemple event-driven.

30:32 Et dans le contexte, on ne parle pas du tout du pourquoi on le fait d'un point de vue business. On va construire des routes, on peut le faire de manière synchrone ou asynchrone, il faut qu'on choisisse, il faut choisir la meilleure stratégie. Mais on ne comprend pas vraiment pourquoi. Et du coup, le gros risque, c'est du coup, tout le reste de l'ADR ne se pose pas les bonnes questions. Et finalement, c'est aussi un moyen, dès le début de l'ADR, de se rendre compte, mais est-ce que ça vaut le coup de faire un ADR? Est-ce qu'il y aura un impact derrière de faire? En fait, finalement, ce n'est pas forcément une décision stratégique. Si on a bien posé le contexte de business, on va déduire des critères de choix, parce qu'on va avoir plusieurs options, on va choisir selon ces options, selon certains critères. Et du coup, si les critères sont déduits des objectifs de business, on pense qu'on va prendre une meilleure décision. Donc là, par exemple, un des éléments clés, c'est d'être capable d'avoir du templating, parce que... On veut que les emails puissent être envoyés par un profil qui est non technique et qui est à l'IS, notre cliente.

31:38 Et donc, c'est un élément essentiel. Pareil, il faut aussi avoir une API parce que l'envoi doit être automatique à chaque fois qu'on s'inscrit sur la plateforme. Donc ensuite, on va, exactement comme Célia l'a montré, en général, on se retrouve avec un tableau comme ça. Chacune des options qu'on propose, donc là, on a trois technologies, ImageJet, Sengrid et Brevo. Et puis, on retrouve les critères et on essaye de déterminer pour chacune des solutions s'il remplit le critère ou pas. Je ne détaille pas trop ce point, mais évidemment, pour prendre une bonne décision, il faut que les bonnes personnes soient impliquées et que ces personnes puissent collaborer. C'est pas mal sur Notion, on peut mettre des commentaires. Quentin, qui est chez le client, va le challenger. Au moment où on prend la décision, le fait qu'il ait été impliqué simplifie. La présidence, on s'assure que tout le monde est allé. Donc voilà, trois critères clés pour moi pour prendre une bonne décision.

32:42 Encore une fois, tous les modèles sont faux et l'idée, c'est de le faire avec vous, avec votre contexte. Mais nous, c'est ce qu'on s'est rendu compte en regardant nos ADR. Qu'est-ce qui fait un bon ADR? Aujourd'hui, c'est essentiellement ces trois critères pour prendre une bonne décision. Maintenant, Une fois qu'on a pris la décision, imaginons, on revient dans un an, on fait une autre application. On doit reprendre, soit on doit changer quelque chose sur cette application, soit sur une autre application, on doit choisir quelle technologie on doit utiliser pour envoyer des emails. On aimerait bien retrouver des informations sur cet ADR. Et du coup, le premier élément qui paraît clé pour réussir cette partie-là, c'est déjà que la décision qui a été prise, elle soit claire. On a décidé de prendre un mailjet et que le raisonnement qui a mené à cette décision soit compréhensible en une phrase, on essaie de résumer en une phrase, en moins de 30 secondes. Si on laisse toute l'analyse qui peut être assez exhaustive et qu'on met juste sa décision, c'est difficile de comprendre finalement qu'est-ce qui a pêché, qu'est-ce qui a permis de prendre sa décision.

33:52 Ce qui est important, c'est que les traits d'offre de cette décision, les conséquences de cette décision seront explicites. Typiquement ici, on est au clair qu'on ne peut pas envoyer plus de 6000 emails par mois. Et du coup, on imagine que si demain la solution évolue et on dépasse ces 6000, on comprendra que peut-être que Mailjet n'est plus la technologie adaptée. On pourra peut-être revenir dessus. Et enfin, honnêtement, là-dessus, ce n'est pas la partie où on est le meilleur, mais ce qui est important, c'est de lister tous les ressources, tous les liens, les ZR précédents sur lesquels on s'est basé pour prendre cette décision, parce que les contextes changent au fur et à mesure. Donc, si on doit revenir dessus, c'est important de les avoir. Voilà, donc c'est quelques points de contrôle qu'on essaye de standardiser pour faire des bons ADR chez OCO. Une fois qu'on a ce standard, ce qui est essentiel, c'est de former les équipes.

34:54 Et du coup, notre moyen de faire ça, c'est un dojo, un kata. Chaque semaine, tous les tech leads chez Ocla ont un dojo, participent à un dojo. Et chaque semaine, un tech lead présente un ADR sur lequel il est en train de travailler. Alors ça a deux effets. La première, c'est qu'il pratique de manière délibérée. On regarde le standard. Est-ce que cet ADR respecte le standard? Est-ce que finalement le standard est toujours bon? Et en faisant cette pratique délibérée, le jour où on doit refaire un ADR, on a les bons réflexes. Et puis le deuxième avantage, c'est comme on est tous ensemble, tous les tech leads ensemble pour challenger cet ADR, on utilise aussi l'intelligence collective et ça permet de prendre une meilleure décision. Donc ce training fréquent, ça paraît essentiel pour que ce système d'ADR fonctionne bien. Pour autant, une des autres types, c'est d'aller chercher la perfection.

35:55 Ok, je vais faire le meilleur DR, je vais être sûr de prendre la bonne décision. Et ça, on a tendance à voir... Ce qui est important, c'est qu'on arrive à prendre une décision rapidement parce qu'on veut délivrer une application dans les temps. On est très à cheval sur la tenue des jalons. Et le risque ici, c'est de faire un ADR qui est trop exhaustif, on prend trop de temps, on n'arrive pas à prendre la décision. Alors je voulais illustrer avec ce petit manuel qui est rigolo, je pense que pas mal de gens l'ont déjà vu, c'est le manuel qui était donné pour la seconde guerre mondiale aux espions britanniques qui étaient en... Un terrain ennemi, et qui leur expliquait, voilà les bonnes pratiques pour saboter les organisations chez nos ennemis. Et en fait, c'est marrant parce qu'on peut retrouver plein de choses qu'on voit dans nos organisations, qu'on cherche à parler fréquemment, donner plein de points nouveaux, des anecdotes, mettre en avant aussi souvent les problèmes et les conséquences, rabâcher ça, chipoter chacun des mots, les comptes rendus, la résolution, en permanence demander une...

37:02 Une étude approfondie, etc. Et en fait, tout ça, on peut le retrouver vraiment cristallisé dans les ADR. On a vu des ADR où on prend deux semaines après la décision et en fait, chacun des mots est challengé, etc. Il faut être vigilant. En rapport à ça, ce n'est pas forcément, finalement, on tombe un peu sur cette conclusion, l'ADR, ce n'est pas forcément l'outil pour prendre la bonne décision, mais c'est un outil pour prendre une décision et que tout le monde soit aligné et on avance et éviter de la saboter. Et dernier petit élément qu'on est en train de tester et que je trouve assez rigolo, comme tout le monde, je suis très fan de Genia et j'essaie absolument partout de l'utiliser. Aujourd'hui, on a la notion qui est centralisée et qui, comme... Comme à France Travail, on essaie que tout le monde collabore sur le même outil pour qu'on puisse se retrouver. Dans les faits, c'est un peu difficile puisqu'il faut bien le taguer, il faut mettre le bon nom, la recherche sur notion n'est pas forcément toujours efficace. Et en pratique, on ne retrouve pas forcément l'ADR au bon moment.

38:06 Alors, on a testé un petit... Chatbot avec ChatGPT, on lui a donné le standard, c'est quoi un bon ADR, on lui a donné les ADR précédents, et la question c'est est-ce qu'il va être capable de faire un ADR qui se base sur les ADR précédents. Et en fait, en le faisant, on s'est rendu compte que ça répondait plutôt à l'erreur que je vous ai présentée tout à l'heure, qui est comment faire un bon ADR. Typiquement, en lui donnant le standard et en lui donnant un début d'ADR, le chat GPT challenge et dit attention, en fait, tu ne respectes pas le standard. Pose-toi des bonnes questions. Alors, je voulais vous partager, je ne sais pas si je vais réussir à... Je vais changer. J'ai mis le lien, vous pourrez tester par vous-même ce custom GPT. Alors, il faut tester GPT Plus aujourd'hui. Je suis désolé pour ceux qui ne l'ont pas, mais je voulais vous partager ce... Ce petit échange avec lui. Et du coup, la première chose que j'ai testée, c'est, tiens, est-ce que selon toi, ça, c'est un bon contexte d'ADR?

39:10 Qu'est-ce que tu en penses? Et il me dit tout de suite, attention, ce n'est pas... Ça ne fait pas clairement le lien avec les objectifs business. C'est pas mal. Bon, après, il essaie de le faire lui-même. Ce n'est pas forcément très pertinent. Mais si je commence à lui préciser des objectifs un peu plus business, par exemple, le client a des SLA, il doit répondre en moins de deux secondes, la plateforme qu'on est en train de développer doit répondre en moins de deux secondes, il le prend en compte, il nous génère un nouveau contexte, je ne vais pas le détailler, il y a pas mal d'éléments, et si ensuite je lui demande de générer un ADR, il fait des choses assez intéressantes, on retrouve le contexte, décision critère, où il remet bien le response time, donc il a fait ce lien entre les critères de choix et l'ADR, et il propose des options qu'il évalue lui-même. Alors, complètement challengeable, mais c'est assez marrant parce que c'est une bonne base et je suis persuadé que ça peut aider les tech leads à faire des meilleurs adhérents.

40:18 Pour autant, il ne s'est pas basé sur des décisions précédentes pour... Il a pu utiliser ses connaissances, on va dire, personnelles. Donc en fait, en faisant cet exercice, je me suis rendu compte que c'est plus un outil qui va permettre de challenger les ADR, comme aujourd'hui on fait dans les dojos. Est-ce que tu as respecté le standard? Plutôt que je vais te faire l'ADR et je vais te donner, je vais te prendre la décision pour toi, je vais prendre la bonne décision pour toi. Ça aujourd'hui, en fait, j'ai l'impression qu'il n'est pas encore parfait pour le faire. Voilà, c'était à peu près tout ce que j'avais à partager. Frédéric, je te mets la main. Et si vous avez des questions là-dessus, avec plaisir. Merci, merci Thomas. Donc, oui, on arrive bientôt à la fin de ce meet-up. C'est le moment de passer aux questions. Et potentiellement, si vous voulez, vous pouvez monter sur scène pour répondre aux questions. Je pense notamment à Jean-Rémi. Malheureusement, je ne connais pas assez bien Olaf Zimmermann.

41:24 Donc, si tu veux poser ta question sur scène, tu es le bienvenu. Je ne sais pas comment on fait, Lucas, mais je compte sur toi. Une autre question d'Eric. Doit-on attendre des architectes qui challengent les critères business aussi et qu'ils les prennent en l'état? Ou qu'ils les prennent en l'état, pardon. Et si challenge, comment faire pour qu'ils gagnent cette connaissance? C'est une très bonne question. Je pense qu'on prend des meilleures décisions en tant qu'architecte si on comprend les objectifs business. Donc, à minima, le comprendre et le fait de les challenger, je pense que c'est un peu la pratique délibérée d'essayer de comprendre le business. Même si ce n'est pas leur responsabilité. Pour moi, ça paraît essentiel que c'est plutôt le rôle du product manager sur un produit qui doit l'apporter. Donc, je m'attendrais plus à ce que l'architecte demande au product manager, en fait, je me rends compte en faisant l'ADR que les objectifs business ne sont pas clairs.

42:31 Est-ce que tu peux me réexpliquer? Du coup, on travaille cette première partie ensemble. Mais voilà, je ne pense pas que ce soit lui qui est responsable de ça. Très bien. Est-ce que, Célia, tu as une réponse? Alors, oui, je n'aurais pas forcément challenge, mais en tout cas, challenge, mais bien comprendre. Et nous, pour faire ça, on aime bien, du coup, utiliser des outils un peu collaboratifs ou d'intelligence collective, peu importe comment on les appelle, autour du DDD qui permettent justement d'instaurer un vrai dialogue entre les métiers, l'équipe technique et les architectes. Parce que c'est par la collaboration, du coup, qu'on peut prendre de meilleures décisions, à mon sens. Effectivement, oui. Donc oui, effectivement, nous, pour notre part, en tant qu'architectes d'antan, entreprise, comme je vous ai dit, on a quand même trois couches et on a quand même une couche du coup business et notre objectif effectivement c'est de challenger le business sur le parcours, un minimum entre

43:32 le début et la fin du process, donc on va modéliser les process, on va les challenger sur les différents parcours, ne serait-ce que pour savoir si on a la capacité C'est-à-dire, si une solution offre la capacité de supporter ce qu'il souhaite, parce que là, dans ces cas-là, on va rentrer dans une démarche, on va devoir créer une nouvelle capacité de l'entreprise et donc forcément une solution derrière qui amènera de l'outillage. Et puis surtout, peut-être simplifier certaines choses et puis apporter aussi cette vue technologique que nous, on peut avoir comme on prend cet ascenseur entre la technique et le métier. Des fois, peut-être que deux, trois idées peuvent les aider un peu à revoir leur process et puis peut-être à le simplifier. Donc oui, pour moi, un architecte s'intéresse fortement au métier. Est-ce que, Jérémy, est-ce que tu souhaites prendre la main, monter sur scène pour nous partager ton expérience, enfin ce que tu as lu autour du billet du coup d'Olaf, et puis

44:36 nous partager en fait ta question pour qu'on puisse peut-être débattre dessus rapidement. Tu peux le faire monter sur scène, du coup, Lucas ou Noémie? Ah, parfait, super, Jérémy. Bonjour, Jean-Rémi, pardon. Bonjour. Bonjour. Merci beaucoup pour ce petit moment de parole que vous m'offrez. Merci beaucoup pour tous les éléments que vous avez déjà tous donnés. Ma question était donc... Dans la continuité de ce qui a été dit, si on se dit qu'on peut tracer toutes les décisions, l'architecture, et j'entends le cas de ma qui a été posé, ça va de même faire des décisions métiers, des décisions qui impactent un produit. Et dans la continuité de nous, architectes, on doit challenger le produit. Comment est-ce que vous avez déjà, l'un d'entre vous, challengé et ou tracé ces options métiers qui elles-mêmes pourraient être des entrants à des éthiques, des époques, et donc faire aussi le lien avec des décisions d'architecture? Ou toute autre décision, mais métier, vous paraissez avoir. J'ai une petite expérience sur le sujet.

45:38 Quand on a déployé ce template-là auprès des équipes, on fait un partage avec l'ensemble de l'équipe, PO, PM, équipe de dev. Et du coup, la PO, s'est approprié le template pour s'en servir comme support de dialogue avec les métiers. Et c'est vrai qu'elle a naturellement reproduit la mécanique. Donc oui, c'est adaptable. Ce qu'elle a fait, c'était intéressant parce que du coup, elle posait des scénarios aussi. Ce n'est pas une décision d'architecture, mais moi, je trouve que ça reste quand même une bonne pratique d'entreprise. C'est quand même mieux de tracer des décisions sur un template plutôt que dans une chaîne de mail qui navigue ou dans des PowerPoints qui se perdent au fil de l'eau. Et pour compléter, je pense que c'est tout à fait faisable. Après, ce qu'on a observé aussi, c'est qu'il faut être aussi pragmatique.

46:40 On a des délais, il faut les tenir. Et du coup, la question, c'est lesquelles les bonnes décisions, en fait, aussi, c'est lesquelles les décisions importantes où il faut passer ce formalisme. Parce que si on le fait, je pense, sur absolument toutes les décisions, on va prendre beaucoup. Beaucoup de temps et peut-être pour des choses qui ne sont pas forcément importantes. Et du coup, on risque de ne pas tenir certains jalons, ce genre de choses. Donc voilà, je modérerais peut-être en ciblant sur uniquement les décisions qui sont importantes. Merci beaucoup. Merci beaucoup, Jean-Rémi. Merci d'être monté sur scène. Est-ce que vous avez d'autres questions? Vous pouvez lever la main si vous souhaitez monter sur scène pour une question, peut-être partager une expérience sur tout ce qu'on a raconté autour des décisions d'architecture. l'impact de ces décisions, comment vous les diffusez. Voilà, des choses auxquelles on a tenté de répondre aujourd'hui. Je crois qu'il y a une question sur les... Tracer les mauvaises décisions et leurs raisons.

47:43 Ah oui, je n'avais pas vu comment il est tout le temps. Oui, effectivement. Donc, comment tracer... Donc, une question de Jean-Michel. Comment tracer, gérer vos mauvaises décisions et surtout tracer leurs raisons? Alors, moi, je peux donner un avis qui est très perso. Je pense que, en fait, déjà, l'objectif, c'est d'éviter qu'une décision soit trop mauvaise. Je fais des guillemets avec mes doigts. Mais du coup, l'essence même, c'est quand même d'avoir les bonnes personnes autour de la table. C'est-à-dire que si on mobilise les bons interlocuteurs, on va quand même déjà gommer une bonne partie du problème. Et puis après, ce que j'aime bien avec l'idée de tracer la décision avec la story, c'est qu'on rentre aussi dans une boucle d'amélioration continue, c'est-à-dire que derrière, on va avoir des priorisations, de la réalisation, de la rétrospective. Et donc, ça se fait naturellement, c'est-à-dire que c'est vraiment qui crée un dialogue au sein de l'équipe pour qu'on puisse se dire ça, ça s'est bien passé, ça s'est mal passé et on ne reproduit pas.

48:48 Il faut aussi le faire à l'échelle de l'entreprise. Quand on est architecte d'entreprise, c'est un autre sujet. Et ça, ça se passe plutôt dans des instances ad hoc. Ce ne sera pas la même mécanique. Moi, je n'ai pas encore suffisamment de recul pour ça. C'était cher. Je suis complètement aligné avec toi, Célia. Personnellement, on a une pratique de résolution de problèmes quotidienne. On demande aux équipes, est-ce que vous avez rencontré des problèmes aujourd'hui? Et voilà, passer 30 minutes à faire une résolution de problème. Et du coup, il s'est trouvé la cause racine de ce problème. Et on peut tomber sur un ADR. Un exemple que je peux vous partager, c'est qu'on a développé une application mobile, on a décidé un pattern d'architecture basé sur les événements, l'event streaming. Et en fait, on s'est rendu compte deux ans plus tard que ça n'apportait pas vraiment de solution au problème qu'on avait sur l'application.

49:49 En fait, on en causait plusieurs. Et du coup, on s'en est rendu compte en faisant la raison du problème. On a retrouvé l'ADR qui était à l'origine. Et du coup, maintenant, on essaie de se poser la question sur les prochains ADR. sur ce genre d'architecture, est-ce que dans ce contexte, on va prendre cette décision ? Je pense que c'est la résolution de problèmes fréquentes qui permet de refaire le lien avec des ADR et de moins de décisions. Merci, du coup ça peut peut-être s'enchaîner avec ce que tu viens de dire Thomas, avec une excellente question de Frédéric, qui parle en fait de référentiel ou de partner ou de building block que vous avez créé suite à ces problèmes, donc tu parles effectivement d'événementiel, moi je sais que du coup effectivement l'événementiel ça peut créer certains problèmes dans certains cas d'usage, sur lequel on a du mal après à s'en sortir. Et justement, est-ce que vous avez ces espèces de référentiels qui sont liés en fait à des dettes ou des échecs pour dire en fait ce pattern ou ce building block ou

50:55 building block d'architecture ou building block de composants, de solutions, ça fonctionne ou ça a fonctionné dans telle et telle condition, mais attention, on a rencontré tel et tel problème suite à la suite de la prise en compte de ce... De ce pattern? Est-ce que vous avez ce type de référentiel chez vous? Et si oui, quand vous l'utilisez? Est-ce que vous l'utilisez dans le cycle? Est-ce que c'est présenté dans des PI, par exemple? Je ne sais pas, est-ce que tu as des retours là-dessus par rapport à tes clients? Honnêtement, c'est un peu là où ça blesse, notamment sur la diffusion. D'accord. Effectivement, si je reprends mon exemple, le tech lead qui a pris cette décision à l'époque a tiré un apprentissage de ça. On a une culture, on place vraiment au centre l'apprentissage, donc on croit plus, enfin on pense qu'on va prendre des meilleures décisions par le développement des personnes. La contrepartie, c'est que la connaissance, elle a tendance à plutôt être chez les personnes. qu'être capable de la retrouver au bon moment par une autre personne qui parle, par une autre organisation, franchement, honnêtement, on n'a pas résolu ce problème-là.

52:03 Donc voilà ce qu'on essaie avec un chat GPT, des modèles LLM, où on pourrait... Mais voilà, ce problème de diffusion, je trouve qu'il est encore là. Oui, tout à fait. Ça passe souvent par la tête de l'architecte, je trouve. Donc, d'où l'intérêt, effectivement, qu'il y ait une espèce de gouvernance avec un comité qui permet à un architecte de pouvoir intervenir, parce que souvent, effectivement, ce que je rencontre, c'est souvent dans sa tête. Célia, est-ce que tu as peut-être des retours d'espérance là-dessus? Comment tu arrives peut-être à tracer une piste architecturale pour éviter justement que ça se plante? Alors nous, on a deux outils. On a la boîte à outils qui fournit du coup des kits prêts à l'emploi pour prendre des bonnes décisions en fonction du contexte. Effectivement, elle va contenir des références, c'est-à-dire... des espèces de guidelines pour les équipes en fonction du sujet qu'elles ont à traiter.

53:04 Est-ce que c'est un portail web? Est-ce que c'est une API? Est-ce que c'est de la donnée? Et puis, à côté de ça, on a ce qu'on appelle une boîte à apprendre. Et dans cette boîte à apprendre, on va retrouver des choses aussi basiques que pouvoir se former un certain nombre de... Et améliorer ses compétences techniques. Mais on a aussi des événements qu'on organise régulièrement. Cette année, par exemple, on a organisé Tech4PE, et c'est l'idée de regrouper des équipes autour d'un enjeu d'entreprise. Nous, c'était l'ESI Platform, pour qu'elles partagent leurs bonnes pratiques. Alors, c'est plus orienté aux bonnes pratiques, mais voilà ce que j'ai fait qui fonctionne. Et donc, du coup, on fait un peu des espèces de... De stand pour qu'elles puissent échanger entre elles en fonction des usages et des problématiques du moment. D'accord. Merci.

54:05 Merci à toi. On arrive sur la fin. Je crois que la question d'Eric, on y a répondu. Donc, il n'y a plus d'autres questions. Il est 57. Je pense qu'on peut conclure. Les next steps, n'hésitez pas à vous inscrire sur le canal Cher Architecture. Posez vos questions, partagez votre curation. Ce canal, il est pour vous. Et puis, je ne sais pas si tu as un mot de fin, Noémie. mais sinon on se retrouve tout de suite pour ceux qui veulent rester à une table dans cette plateforme Primo. Non, le mot de fin, c'est juste un grand merci. Je ne sais pas si vous m'entendez, mais un grand merci Frédéric, Célia et Thomas. Merci pour vos interventions, votre partage. Et puis, au plaisir de se retrouver un avis sur les tables de networking. Et à très vite pour nos prochains événements de Fox. Merci beaucoup. Merci à toutes et à tous. Merci. Merci beaucoup.