Fathi Bellahcene - L’architecture n’appartient pas aux architectes ! @Veepee

[00:00:05] Alors, bonjour, je me présente, je m'appelle Faty Bellahssene. Je suis un principal architecte chez Vente Privée, chez Vipi, pardon. Et euh, avant de commencer, j'aimerais juste vous raconter euh comment je me suis retrouvé sur cette scène. Euh, donc je sais pas si si Samuel il est dans la salle. Non? Donc il y a il y a quelques mois, on discutait avec Samuel, Samuel Reutier, qui organise la conférence sur on échangeait sur les pratiques de l'architecture entre vente privée et et euh et ses discount, et donc on a échangé plusieurs fois et à la fin, il m'a dit, Ah bah, ça serait cool que tu viennes un peu pitcher ce que tu m'as raconté et ce que vous faites chez Vente Privée. Ah, donc je lui ai dit euh non, je pense pas que ce soit intéressant et je pense qu'il y a des des choses plus intéressantes à raconter que ce qu'on fait chez Vente Privée, il m'a dit si si, c'est bien, c'est bien. Donc vous savez comme quand on dit aux enfants, oui oui, on verra. Et me voilà. Donc euh je me suis retrouvé dans la sauce. Donc euh si Sam vous propose de parler avec lui,
[00:01:05] ne parlez pas avec lui. Et merci pour la sauce. Donc on va démarrer, euh, la présentation, elle va suivre le plan suivant. Je vais commencer par vous présenter un peu le contexte dans lequel on travaille, vous expliquer ce que c'est que Vente Privée, le le le contexte de l'e-commerce et une note définition de l'architecture. Ensuite, ce que ça implique et comment on la pratique et comment se positionnent les architectes les architectes d'entre dans notre organisation.
[00:01:34] Donc pour commencer, quelques chiffres. Alors c'est pas pour pour montrer qu'on est gros et qu'on fait qu'on est important, mais c'est juste pour vous donner un peu une idée de la taille de ce que représente le système d'information de Vipi.
[00:01:46] Parce qu'il y a beaucoup de gens quand on les rencontre et qu'on leur parle de Vipi pensent que c'est juste une application. Donc c'est 650 employés.
[00:01:54] Euh, un système d'information qui est très très gros, donc c'est 1200 applications, mais des centaines de bases de données, des milliers de services, euh, 7000 déploiements en production depuis depuis le début de l'année. Et euh fonctionnellement, on expose pas juste, on n'est pas juste un site e-commerce où on expose des catalogues. On fait de la logistique, on fait de la supply, on fait de la production, donc on fait du shooting, il y a une vraie densité fonctionnelle. Et le système est vraiment large. Donc quand on parle d'architecture dans cette présentation, il faut garder à l'idée que c'est un système qui est vraiment très gros, euh qui a une vraie complexité fonctionnelle et euh l'architecture ça va passer de l'architecture applicative voir un exercice qui qui relève plus de l'urbanisation.
[00:02:42] Le contexte de l'e-commerce. Ça c'est la l'une des premières choses qu'on m'a dit chez Vente Privée et euh je pense que c'est la la plus importante à à partager, à comprendre quand on travaille dans dans l'e-commerce. Euh, contrairement à toutes les industries où alors c'est c'est ma première expérience dans l'e-commerce, j'ai fait beaucoup de bancaire, d'assurance, d'automobile, des industries un peu classiques. Euh, ce qui m'a frappé dans l'e-commerce par rapport aux autres industries, c'est l'importance d'aller vite. Euh, si vous prenez les banques, l'automobile, la taille de l'entreprise est importante. Euh, on prenne l'automobile, Toyota, même s'il y a des nouvelles sociétés qui arrivent, avant que Toyota soit détrôné ou soit mis en difficulté ou Ford, il va se passer beaucoup de temps. Pareil pour les banques, c'est des industries où la taille de la boîte, sa valorisation a un vrai, une vraie importance euh dans dans son poids dans dans l'écosystème. L'e-commerce et j'aimerais dire un peu plus tous les business qui sont aujourd'hui sur internet, c'est très différent. Ce qui va compter, c'est vraiment la vélocité. Vente Privée, c'est une boîte qui est relativement jeune, début des années 2000, et entre 2000 où Vente Privée a commencé, et pas Amazon, Amazon est arrivé est devenu bah le Mastodo qu'on connaît. Aujourd'hui, il y a beaucoup d'acteurs. Dans notre domaine, vous pouvez avoir un acteur qui démarre aujourd'hui, qui deux 3 ans, peut devenir majeur, voire très important dans dans dans notre écosystème. Donc, il y a une vraie importance à aller vite. Ce qui est important, c'est pas d'être gros et de grossir, l'important c'est vraiment d'aller vite et d'accélérer.
[00:04:21] Euh, c'est vraiment quelque chose qui a un impact sur notre manière de travailler euh au jour le jour. En tant qu'architecte, on va avoir trois interlocuteurs et là encore quand j'ai fait ma présentation, on m'a dit mais ça va être qui la brute et ça va être qui le truand? entre le business, les gens du produit et les gens de la tech. Donc en tant qu'architecte, vous avez trois grandes familles d'interlocuteurs.
[00:04:45] Les gens du business. Quand ils vont interagir avec vous, euh, ça va être principalement de l'alignement. Ils vont vous exposer leur vision business, leurs préoccupations et les initiatives qu'ils ont envie de faire. J'ai envie de développer le voyage, j'ai envie d'ouvrir un nouveau business, de nouvelles fonctionnalités, et cetera. Euh, vous devez très rapidement, encore une fois la vitesse est importante, leur dire bah si c'est faisable, euh en combien de temps et à quel prix. Donc eux ce qu'ils vont chercher à comprendre, c'est
[00:05:15] être rassuré sur le fait que vous ayez compris leur vision business, que vous êtes aligné avec celle-là et leur rapporter des réponses.
[00:05:25] Les PO ou la famille produit, les BPO, enfin ce que j'appelle la famille du produit.
[00:05:32] leur interaction, c'est qu'une fois que les les sujets sont sur la table, ils doivent construire des roadmap et euh une des principales difficultés, c'est les interdépendances entre les produits. Donc on a une organisation produit et souvent les grosses fonctionnalités, elles sont cross-produit. Et un PO, ce qui va l'intéresser, c'est,
[00:05:48] OK, je dois faire ça, je maîtrise ma roadmap, je maîtrise mon équipe, mais j'ai besoin d'avoir de la visibilité sur ben ce qui va se passer dans les autres équipes, euh, et cetera. Donc d'avoir de la visibilité sur les interdépendances,
[00:06:03] euh, ce que implique cette fonctionnalité et ce développement pour les autres équipes de de l'organisation. Et là c'est pareil, c'est on doit être capable de leur donner de la visibilité, de leur expliquer comment développer les choses et surtout de la visibilité sur les interdépendances. La famille de Tech, donc les développeurs, les lead développeurs, les gens de l'infra, et cetera.
[00:06:26] Ils vont aussi être intéressés par la vision, ils ont besoin de savoir où ils vont et ce qu'on leur demande, de donner un sens à leur travail, c'est très important. Mais en plus de ça, ils vont vous demander dans quel cadre ils évoluent. Donc d'être capable de leur définir un peu les règles du jeu, où ils travaillent, et aussi euh d'avoir de la visibilité sur
[00:06:49] la solution globale, le développement global, et de pas juste se dire bah moi, je suis là, j'ai des fonctionnalités, je dois les développer, mais ils ont besoin d'avoir vraiment la vision globale et de donner du sens. Et on verra dans cette présentation ce que ça implique.
[00:07:00] Donc si on résume notre travail en tant qu'architecte vis-à-vis de nos principaux interlocuteurs, c'est d'être capable de répondre vite et de donner des solutions. Si le business me demande est-ce que c'est possible de faire cette nouvelle chose, oui, non, et comment on va le faire pour les PO, et techniquement comment ça ça ça se transforme en développement pour la partie technique.
[00:07:24] Donc c'est vraiment ça nous nous nous notre principale mission et notre principale tâche chez Vente Privée.
[00:07:34] Alors, la définition de l'architecture. Il y a Martin Foller en 2005 a écrit un article ou 'Who needs an Architect'. Alors à l'époque j'étais développeur et je cherchais des arguments pour
[00:07:45] critiquer les architectes que je pensais qu'ils, je pensais que c'était des emplois fictifs, des gens inutiles qui servaient pas à grand-chose parce qu'ils venaient nous voir tous les 6 mois avec des règles et des contraintes.
[00:07:58] Et c'était un peu la question, on se soumettait à la question. Donc je me suis dit, tiens, quelqu'un déjà que je respecte énormément, qui crée un article un peu tape à l'œil où je vais trouver des arguments pour prouver que les architectes servent à rien. Euh, dans cet article, il y a deux, il y a trois parties, mais les deux parties sont intéressantes. La première chose, c'est il pose la question de bah au fond, c'est quoi la pratique de l'architecture et euh il sépare la pratique du rôle. Donc il parle dans la première partie de la pratique de l'architecture, qu'est-ce que c'est que faire de l'architecture dans une entreprise informatique, bien évidemment. Et quel est le rôle de l'architecte pour justement appliquer cette chose-là. Et dans les différents échanges, enfin dans dans l'article, il termine avec cette définition qui peut paraître un peu générique,
[00:08:46] mais qui pour moi est vraiment en tout cas, c'est la meilleure et c'est celle que que que que je porte. L'architecture, c'est à propos des choses importantes, quelque quoi que ce soit. Et il définit l'importance par les choses qui ont un impact systémique sur le système d'information ou l'application sur lequel vous travaillez ou un impact irréversible.
[00:09:10] Ça peut être un choix d'algorithme qui peut avoir un impact sur votre performance ou la performance de votre entreprise, par exemple le search pour une entreprise d'e-commerce. Ça peut être un choix de base de données, où c'est très bien pour les développeurs que changer une base de données une fois qu'elle est en production avec beaucoup d'historique, c'est extrêmement compliqué. Ça peut être un design, un flux, un process, quand vous travaillez sur l'échelle d'un système d'information et vous faites de l'urbanisation. Donc pour lui, c'est vraiment ce qui est irréversible, qui peut avoir des impacts sur le temps ou difficilement réversible et euh qui peut avoir un impact systémique. C'est ça ce qui est important. Et on se rend compte qu'en fait, euh, ça couvre aussi bien les décisions que peuvent prendre des développeurs que des architectes d'entreprise. Le le scope est vraiment large,
[00:09:59] et euh ça touche beaucoup de choses. Et là, on retrouve les métiers classiques de l'architecture avec des architectures logiciels, des urbanistes, des architectes d'entreprise, et cetera.
[00:10:12] Nous, on a un peu adapté ça à notre contexte chez Vente Privée en prenant les deux les deux éléments euh qui qui qui nous sont propres, à savoir la prise de décision et la vitesse. Donc pour nous chez Vente Privée et c'est ce qu'on fait tous les jours, c'est de prendre des décisions. On essaie de prendre des bonnes décisions.
[00:10:30] J'espère qu'elles sont bonnes, sinon, enfin, je pense que si je prenais des mauvaises décisions, je serais pas là. sur les choses importantes, le plus vite possible. Donc c'est notre définition de l'architecture et ce qui est important, ça peut être un choix d'algorithme, un choix de base de données, euh un modèle de base de données, euh ou un flux, euh un choix de solution sur euh un progiciel, et cetera.
[00:10:58] Donc les conséquences de ça, euh, là, on a un problème organisationnel, on est 650, on est une soixantaine de produits, des décisions, il y en a beaucoup. On est une équipe de 10 architectes ou une quinzaine d'architectes chez Vente Privée. Euh, si c'est les architectes qui doivent prendre toutes les décisions sur ce qui marche, ça rentre pas, ça fit pas. Vous allez ralentir et vous devenez très vous êtes un bottleneck. Donc vous ne pouvez pas déléguer la responsabilité de l'architecture telle qu'on l'a défini aux seuls architectes. Il y a un vrai problème si vous le faites. euh, vous allez contre le premier principe qui est d'aller vite et d'accélérer et vous êtes un vrai bloqueur pour l'organisation. Donc vous n'avez pas le choix que de déléguer cette responsabilité à d'autres personnes dans l'organisation.
[00:11:44] Alors déléguer, c'est un grand mot, c'est facile euh de dire bon bah je te délègue la responsabilité de prendre des décisions, mais il faut mettre en place le contexte qui va bien. Et c'est ce qu'on va un peu expliquer. C'est comment mettre en place un contexte de délégation sur des décisions d'architecture dans l'organisation.
[00:12:03] La première chose, c'est à qui on délègue? Euh, donc notre système d'information, mais aussi notre organisation, il est découpé en partie. Donc on a la partie globale qui est le système d'information, qu'on divise en trois domaines qui sont trois sous-ensembles fonctionnels euh du système d'information qu'on redécoupe en sous-ensemble fonctionnel que sont les tribes.
[00:12:26] qu'on redécoupe en produit et à l'intérieur des produits, on a les applications, les bases de données, vraiment tout ce qu'on appelle les software system.
[00:12:38] Aujourd'hui, l'idée, c'est euh quand on a une prise de décision. Et on retrouve ça aussi dans dans beaucoup de de de de livres dans accelerate aussi dans dans the chip programme. Si vous voulez prendre la meilleure décision, vous devez vous vous orienter vers les experts, ceux qui ont la meilleure connaissance. Si vous devez aller vite, vous devez maximiser vos connaissances sur le sujet. Donc vous devez sélectionner la personne qui concentre le plus de connaissances. Ensuite, il y a deux choses. Soit vous demandez à cette personne de vous expliquer tout ce qu'elle connaît et ensuite vous prenez la décision. Soit vous lui faites confiance et vous lui vous lui demandez de prendre la décision. C'est le choix qu'on a pris.
[00:13:19] Euh, dans notre dans cette organisation, le niveau produit est apte, donc on est une organisation produit où chaque produit a une équipe produit avec un lead dev et des développeurs et un PO.
[00:13:31] Si une décision touche un produit ou une application d'un produit, la décision automatiquement est déléguée au lead développeur de ce produit là. C'est que en tant qu'architecte, principal architecte de chez Vente Privée, je peux pas aller dans un produit et dire bon bah, tu vas développer ça comme ça, ou tu vas faire ça comme ça, tu vas utiliser telle technologie, et cetera. C'est pas comme ça que ça marche la délégation.
[00:13:55] Chez nous, le produit est maître à bord, c'est le maître de son produit et c'est lui qui fait ses choix, après il les assume bien évidemment, mais en terme de délégation,
[00:14:04] si la décision se fait sur un produit ou une application, c'est euh c'est le lead développeur de ce produit qui prend les décisions. Bien sûr, il peut nous demander notre avis, il va interroger des gens, collaborer, mais c'est lui le seul honneur de la décision. Ensuite, si ça touche plusieurs produits à l'intérieur d'une tribe, au niveau domaine, on a des équipes d'architectes. Donc on a trois domaines, trois équipes d'architectes et dans les tribes, dans les domaines, on parlera aussi de l'organisation des architectes dans les différents domaines. On va avoir des architectes qui sont euh qui peuvent être spécialisés sur une tribe, par exemple dans opération dans une des tribes qui est sales préparation, où on va retrouver la partie négociation.
[00:14:45] Donc tout ce qui est commercial et la partie production des ventes, donc génération du catalogue, fiches techniques, les images, tout ce qui est bannières. Et euh on a des architectes qui sont spécialisés sur tout ce qui va être production. Donc on va leur demander. Si ça touche un sujet euh qui concerne la tribe de production, on va leur demander à eux. L'idée derrière tout ça, c'est de se dire
[00:15:08] au niveau de la tribe et au niveau du domaine, on a des architectes qui sont la connaissance la plus étendue sur le sujet, donc on va aller leur donner la délégation. Et si ça touche le système dans sa globalité, bah ça va être ça va être pour Bibi, ça va être pour moi.
[00:15:24] Euh, encore une fois, la philosophie derrière ça, c'est d'essayer d'aller vite dans la décision et pour aller vite, on délègue à la personne la plus compétente dans notre organisation. Donc si c'est du produit, le lead dev, si c'est du cross produit dans une tribe, un architecte, si c'est dans un domaine, la personne du domaine qui a le plus de connaissances, et si c'est en transverse, c'est pour moi.
[00:15:46] La le deuxième élément, alors, pour moi, c'est l'élément le plus important. Et hier Arnaud en a parlé dans sa présentation dans les trois piliers de la mesure, il disait que une des choses qui était vraiment important, c'était de mettre les gens dans
[00:15:58] dans un contexte vraiment euh, je sais pas comment dire, mais dans un contexte sain où on va pérenniser la productivité. Vous vous pouvez pas déléguer la responsabilité à quelqu'un, en allant voir un lead dev en disant bon, maintenant tu es responsable et tu assumeras tes responsabilités, si vous créez pas une relation de confiance avec lui. Euh, ce que j'ai appris chez Vente Privée au bout de 8 ans, c'est que le plus important pour un architecte, c'est sa proximité avec les gens avec qui il travaille. S'il n'y a pas de proximité, il y a pas de confiance. S'il y a pas de confiance, si vous allez les voir, c'est comme un élastique. Si vous allez les voir les gens juste pour des problèmes ou relever les comptes, vous tendez l'élastique. Euh, on fait une revue d'architecture. Donc c'est une sorte de question. Euh, pourquoi est-ce que tu es en retard sur tes développements? Euh, pourquoi tu as utilisé telle technologie? Vous tendez votre relation et à un moment donné l'élastique casse.
[00:16:57] Et quand il casse, la relation est complètement brisée, il y a plus de confiance. Et quand vous mettez un lead développeur à qui vous demandez de prendre des responsabilités dans un contexte tendu ou de non confiance, il prendra pas de décision. Parce que il sera pas dans un il sera pas dans un contexte où il va se sentir à l'aise. Il va se dire bon bah, si je prends des décisions, derrière, il va falloir que je me justifie, donc il va vouloir se baquer, il va pas chercher à aller vite.
[00:17:26] Euh, c'est vraiment important de de développer cette proximité. Nous, par exemple chez Vente Privée,
[00:17:33] les équipes d'architectes sont vraiment dans les domaines et on est mélangé dans les mêmes plateaux. On n'a pas un endroit à nous où on se réunit, on est vraiment dans les équipes et distribué.
[00:17:42] Un conseil aussi que je donne aux architectes, c'est passe du temps avec tes équipes. Va déjeuner avec eux, va prendre un café, va manger. Il y a pas de meilleur moyen pour comprendre un système d'information. Alors vous pouvez lire la doc, vous pouvez lire le code, mais le meilleur moyen pour avoir la meilleure information, c'est de parler avec les gens. En parlant avec les gens, vous allez construire une relation, construire la confiance, améliorer vos connaissances. La personne, quand elle fera des choix, va vous en parler. Donc vous serez dans l'anticipation et pas dans la réaction d'un comité d'architecture. où vous découvrez des choses qui ont été faites et bah vous allez dire bah pourquoi tu as fait ça et il faut recommencer mais c'est trop tard, on a déjà engagé des développements, on a déjà choisi la base de données. Il y a que des bénéfices à aller voir. Ça peut paraître anodin, mais déjeuner, prendre du temps, s'intéresser aux gens, écouter ce qu'ils font,
[00:18:31] euh, pour moi, c'est vraiment le plus important euh dans notre travail d'architecte. Il y a énormément de bénéfices à tous les niveaux. moyen pour avoir la meilleure information c'est de parler avec les gens. En parlant avec les gens, vous allez construire une relation, construire la confiance, améliorer vos connaissances. La personne, quand elle fera des choix, va vous en parler, donc vous serez dans l'anticipation et pas dans la réaction d'un comité d'architecture où vous découvrez des choses qui ont été faites et bah vous allez dire bah pourquoi tu as fait ça et il faut recommencer mais c'est trop tard, on a déjà engagé des développements, on a déjà choisi la base de données. Il y a que des bénéfices à aller voir. Ça peut paraître anodin, mais déjeuner, prendre du temps, s'intéresser aux gens, écouter ce qu'ils font. Pour moi, c'est vraiment le plus important euh dans notre travail d'architecte.
[00:18:36] Il y a énormément de bénéfices à tous les niveaux.
[00:18:40] La chose suivante, c'est faire vraiment confiance. Alors ça c'est vraiment difficile, on a jusqu'à aujourd'hui, c'est quelque chose dont on a beaucoup de mal à faire. Si vous prenez le rugby ou n'importe quel sport collectif, on va vous dire comment gagner, donc gagner c'est marquer plus de buts que l'adversaire. On va vous définir les règles.
[00:18:59] C'est quoi un avant? C'est quoi une mêlée? une touche et cetera et cetera.
[00:19:05] Et pareil pour tous les sports. Mais on dans les règles, vous trouvez rien sur la stratégie, vous dit pas que par exemple au foot vous devez jouer en 4 4 2 et être défensif. Ou au rugby d'envoyer des ballons en l'air. Nous, on doit faire pareil. Si on fait confiance, on doit pas mélanger l'objectif et le moyen. Si vous regardez par exemple les guidelines techniques qui sont un peu les règles les règles du jeu, souvent, vous allez avoir des règles qui vont toucher à au moyen d'atteindre un objectif plutôt que l'objectif. Un exemple simple, c'est sur les tests. Donc on va très souvent dans beaucoup d'entreprises où je suis passé dans les guidelines, on va vous dire bah, je veux 90 % de couverture de tests ou je veux que vous fassiez du TDD. Alors moi je veux bien, mais quand vous bossez sur un pro comme Aix qui est un langage propriétaire faire du TDD ou alors un très très très vieux logiciel Legacy qui a pas de couverture. Quand vous allez voir l'équipe qui est vous leur dites que leur objectif c'est d'atteindre 80 70 % de couverture, ils vont rigoler. Ça n'arrivera jamais.
[00:20:14] Est-ce qu'il y a un intérêt à faire ça? Moi je me pose la question. Le temps qui couvre tout leur code et en plus le temps qu'ils implémentent ces codes là, ça va leur prendre une plombe sur du code qui est en production depuis des années qui tourne qui tourne sinon il y aura d'autres soucis. Il y a pas d'intérêt à faire cette règle là. Par contre, sur une application qui part de zéro, qui est une application qui qui démarre, leur imposer d'avoir des tests unitaires, ça peut faire du sens. Mais cette règle elle a pas de sens, c'est quoi le vrai objectif de test unitaire ou de la couverture ou du TDD? C'est d'avoir un système stable en production avec pas de bug, avec des bonnes performances. C'est la notion de SLA. Donc plutôt que d'imposer des moyens sur la performance de faire du TDD, de faire du BDD, de faire du trunk based development, du faire du mono repo, interrogez-vous sur ce qui compte vraiment, quelle est l'outcome visé par tout ça et laisser la liberté aux gens.
[00:21:13] Faites leur vraiment confiance sur les choix et les moyens qu'ils vont mettre en place. Euh, si vous dites aux personnes calcule ta SLA, met en place des moyens techniques pour mesurer cette SLA et t'assurer que cette SLA est respectée. Et les moyens c'est ton problème. Là, vous faites preuve de respect. Mais si vous allez voir la personne en lui disant bon, il faut que tu fasses du TDD, il faut que tu aies 70 % de couverture, que tu étu que tu utilises telle base de données et que tu fasses du trunk based development, où est la responsabilité, où est le choix, où est la délégation? C'est comme si vous allez voir un entraîneur de foot, vous lui dites bon bah tes joueurs c'est eux, je t'impose ton 11, tu joueras en 4 3 3 parce que j'ai envie et tu joueras défensif. Mais c'est toi l'entraîneur.
[00:22:02] Il y a aucune délégation et il y a aucun respect, j'ai même envie de dire. Donc quand on fait confiance,
[00:22:09] vous devez vous focaliser et laisser vraiment un champ de un un un champ des, enfin, vous devez laisser le à la personne à qui vous déléguez, que ce soit un architecte ou un lead dev ou même un développeur le choix de faire les choses comme il en a envie. Ça, c'est vraiment important et lisez vos guidelines, vous verrez que très souvent on fait cette Amalgame et très souvent bah ça marche pas.
[00:22:33] Le timing. Donc là, on a parlé, donc on a mis en confiance les gens, on les respecte en leur laissant le choix vraiment le choix de faire ce qu'ils veulent, maintenant il faut qu'ils aillent vite. Euh, aux échecs, il y a il y a différentes cadences dans les parties, ça peut être des parties classiques de 2h plus des incréments, une partie peut durer plus de 6h. Et puis vous avez des parties, ce qu'on appelle des parties rapides qui vont durer 15, 10 voire 5 minutes. Euh, on a demandé il y a enfin j'ai lu une interview de Maxime Vachier Lagrave, qui est un des très très, enfin le meilleur joueur français plus ces dernières années, mais au moins sur les 10 dernières années, voir le plus grand joueur français qui était sur la précision des parties. Donc la précision, aux échecs, quand vous jouez un coup, vous avez une note de précision. Si vous avez 100 %, ça signifie que le coup que vous avez joué, c'est le meilleur. Et plus votre note plus ça descend, ça signifie que vous avez peut-être joué le deuxième meilleur coup, le troisième et cetera. Et une partie, elle va avoir une précision globale qui va dire la qualité des décisions que vous avez pris à chaque coup. Donc si vous faites une partie à 100 % de précision et ça arrive pour les grands maîtres, ça signifie que à chaque coup, chaque fois, vous avez pris la meilleure décision possible. Et plus ça baisse, ça signifie que vous êtes il y a des moments où vous avez fait des coups qui étaient pas les meilleurs, pas optimisé. On lui a posé la question de comparer la précision entre une partie classique 3 6h plus de 6h. avec une partie avec une partie la précision d'une partie rapide de 5 minutes ou 10 minutes. Et sa réponse ça m'avait ça m'avait pas mal troublé. Il a dit la qualité et la précision c'est la même.
[00:24:17] En moyenne, la précision d'une partie longue de 6 on a 3 heures de temps de réflexion et une partie, on a 10 minutes de réflexion. C'est la même. La seule différence entre ces deux parties, c'est que vous allez avoir des épiphénomènes, il va y avoir de temps en temps une erreur sur les parties rapides. Mais en moyenne, la précision est identique.
[00:24:38] Un grand maître quand il joue 2h ou quand il joue 3h, prend toujours les bonnes décisions, parfois il se trompe. Vous avez des épiphénomènes qui sont des erreurs.
[00:24:47] Euh, et il justifie ça de manière extrêmement claire, il dit quand vous jouez, vous avez tout de suite le sentiment
[00:24:56] vous avez tout de suite le feeling et vous savez tout de suite que il y a pas vous regardez pas toutes les toutes les tous tous les coups, il y en a trois ou quatre, vous savez que c'est les meilleurs. Donc déjà, vous avez une intuition sur les trois meilleurs coups. Et sur les trois meilleurs coups, intuitivement, vous savez quel est vraiment le meilleur. Donc déjà, quand vous êtes sur une partie rapide, vous avez trois coups, il y en a un vous vous dites c'est probablement lui le meilleur, vous faites vos calculs rapidement et très souvent vous suivez votre votre intuition. Il dit bah la partie longue. On a les mêmes impressions sauf que on se sécurise en regardant le 4e, le 5e, le 6e. Mais dans la majorité des cas, pour les très grands maîtres, pour les gens qui sont assez doués, le meilleur coup, le coup intuitif, c'est très très très souvent le meilleur. Et faites les l'expérience et faites le test dans dans autour de vous. Quand on va voir un lead développeur et qu'on lui pose un problème, tout de suite il vous répond, tout de suite il vous dit bon bah pour faire ça, il faut faire ça ou ça, mais je pense que c'est ça, et dans 99 % des cas, ce qu'il vous dit c'est c'est la bonne chose à faire. Il a l'intuition du bon coup parce qu'il maîtrise son sujet, il a la connaissance. Et si vous le mettez, si vous avez une bonne relation, s'il est en confiance et qu'il se sent en sécurité en vous parlant, en vous disant bon ben si je lui réponds, je joue pas ma vie ou on va pas me reprocher des choses, tout de suite il vous répond. Un exemple concret, c'est quand on a fait la convergence, donc vente privée, il y a 5 ans, on a on était trois compagnies. On a vente privée a acheté de deux compagnies Priva et vente exclusive. Et on a demandé de converger ces plateformes. D'avoir une plateforme qui relle les trois business et de plus avoir trois plateformes différentes. Je me rappelle, on s'est retrouvé avec Arnaud à à Amsterdam à l'époque, il était avec nous. Euh, en une semaine, on a défini donc on avait imposé la vision qui était d'avoir une seule plateforme, très vite, on savait, on avait trois options et très vite on s'est positionné, on savait laquelle on devait faire. Derrière, on a backupé, on a backupé notre intuition avec des réflexions et des vérifications, mais en une semaine, deux semaines, on savait quelle approche on devait faire, quelle était notre stratégie de convergence. Parce qu'on était entre on se faisait confiance, on n'a pas voulu évaluer toutes les options. On en avait vraiment trois sur la table, créer une nouvelle plateforme, hybrider les plateformes pour tirer le meilleur d'eux-mêmes en faisant de l'interopérabilité ou prendre celle qui avait la meilleure couverture fonctionnelle et développer les coumanquants. C'est celle qu'on a choisi. Parce que les deux autres, développer une nouvelle plateforme en un an, c'était impossible, hybrider les plateformes, c'était trop complexe et le contexte humain s'y prêtait pas. Et il y avait des bouts qui étaient pas capables d'assumer la charge globale du business. La troisième c'est c'était la seule plausible et sur les plateformes qu'on avait les trois, on a choisi celle qui maximisait la couverture fonctionnelle et qui nous donnait des gages de sécurité en terme de couverture et de capacité à à à gérer à soutenir la charge globale. Donc ça nous a pas pris énormément de temps et c'était le plus gros projet que j'ai fait dans ma vie et derrière ben le on a eu raison de faire ça et ça s'est très bien passé.
[00:28:16] Les erreurs. Euh, c'est aussi quelque chose d'important. Euh, si vous demandez aux gens de, comme je l'ai dit aux échecs, la différence entre une partie longue et une partie rapide, c'est les épiphénomènes d'erreur. Donc si vous demandez d'aller aux gens d'aller vite, il y a forcément des moments où ils vont se tromper et c'est pas grave. Quand vous êtes dans une optique et vous êtes vraiment dans une philosophie d'accélérer, d'aller très vite, euh, vous devez à un moment assumer les erreurs collectivement et les accepter. On n'est pas dans un une industrie où l'erreur peut être critique et fatale comme les industries du transport humain, pardon, ou euh. On peut se permettre d'avoir des erreurs si euh la somme de nos succès et le ROI l'impact de nos succès couvre nos erreurs.
[00:29:08] On s'est trompé sur beaucoup de projets, l'un des plus gros, enfin il y a un des plus gros projets sur lesquels on s'est trompé, c'était la transformation de la chaîne de production. Pareil, on est parti sur une approche, on avait une stratégie pour développer la chose, au bout d'un moment, on s'est rendu compte qu'on s'est trompé. On a admis l'erreur et on a changé. Et on a continué.
[00:29:29] L'erreur fait vraiment partie euh vous pouvez pas juger une personne sur ses erreurs, mais vous devez la juger sur ce qu'elle a apporté à la boîte. Bien sûr si elle a fait des grosses choses, enfin si elle était de bonne foi dans ses erreurs et enfin qu'elle a pas fait quelque chose de grave ou euh c'est autre chose. Mais vous pouvez pas si vous êtes dans une organisation où vous montrez les erreurs, vous en toute humilité, vous assumez vos erreurs et c'est pas grave et on voit que vous continuez à être là et qu'on vous fait confiance, c'est aussi une manière de montrer que vous êtes dans un écosystème et un environnement assez sain où vous en tant que lead dev, vous auriez pu cacher les choses qui marchent pas ou qui vont pas.
[00:30:09] Et vous vous sentirez rassuré sur le fait de bah lui, il a planté un très gros projet de la boîte, moi si je me suis trompé là, ça ça ça ça devrait passer. Donc la relation à l'erreur, elle est vraiment importante.
[00:30:23] Et vous devez faire en sorte que les gens qui prennent des décisions, surtout quand les gens arrivent dans la boîte ou quand ils font, ils ont une promotion dans des postes, de les rassurer sur le fait que un C'est sûr qu'ils vont se tromper à un moment donné, c'est certain qu'ils vont se tromper. Le zéro erreur n'existe pas. 2, c'est pas grave. On assumera tous ensemble. Si s'est délégué la responsabilité, ça sera de ma faute.
[00:30:51] C'est de ma faute, c'est moi qui en assumerai les conséquences. 3, les erreurs sont aussi une opportunité d'apprendre. Le projet dont je vous ai parlé qui est un projet qui a duré un an qui impactait une dizaine d'équipes, donc c'était vraiment un très très gros projet, on s'est trompé. On a décidé de repartir, on n'est pas reparti de zéro.
[00:31:13] On a appris beaucoup, on a gardé les fondamentaux qu'on estimait être bons et on a changé les choses qui allaient pas. Donc on n'est pas reparti de zéro, mais on est reparti avec une meilleure connaissance, des fondations, on est reparti avec des certitudes sur les choses qui marchaient et celles qui marchaient pas. Et on a pu arriver et en 6 mois, on a fait plus que ce qu'on avait fait en 1 an. C'est important de communiquer sur ces erreurs dans l'organisation.
[00:31:40] La vision et la stratégie, ça, c'est quelque chose que j'ai compris vraiment sur le tard et après le projet de convergence qui est aussi important. Euh, surtout quand vous déléguez aux lead dev et sur des très très gros projets qui vont impacter beaucoup de gens dans l'organisation, vous devez communiquer sur votre vision et votre stratégie. Si on prend le projet de convergence, la vision c'était One platform One brand. D'avoir une seule marque VP à la base, on avait trois marques, vente exclusive, Priva et VP et d'autres boutiques. Donc c'était de fusionner tout ça dans une seule marque et d'avoir une seule plateforme pour faire ça. Donc on a pris les décisions sur la stratégie abordée et derrière ça, on avait un plan. Si vous prenez un GPS, les équipes, c'est comme le GPS. Votre GPS, vous allez lui dire j'ai envie d'aller à un endroit, c'est votre vision et votre stratégie, ça va être les contraintes. Vous allez lui dire bah moi je vais aller à Lille, j'y vais en voiture, mais je veux pas payer de péage et je veux que ce soit le chemin le plus court. Ou je vais aller en train et cetera, donc vos contraintes, ça va être votre stratégie. Et votre GPS, votre équipe va définir le chemin pour y accéder optimisé, elle va définir sa road map en toute autonomie. Et si en route il se passe quelque chose, donc vous êtes dans votre voiture, il y a un embouteillage, un accident, votre équipe connaissant la vision et la stratégie est capable de s'ajuster
[00:33:05] de choisir un autre itinéraire et de de continuer sa route sans revenir vous voir en vous disant, il y a un embouteillage.
[00:33:13] Il y a un problème, qu'est-ce qu'on fait?
[00:33:17] Vous donnez de l'autonomie et vous permettez d'éviter à ce que l'équipe s'arrête, vous pose une question, vous lui répondez et repart, donc vous participez aussi à la vélocité de l'équipe et à avoir vraiment une continuité dans dans son travail. Ce qui s'est passé sur convergence, c'est qu'au bout de 6 mois, euh le board est venu nous voir en nous disant, bon, on a changé, on veut plus aller à Lille, on veut aller à Valenciennes, donc ils ont changé leur vision en nous disant bon en fait,
[00:33:45] on va garder la marque Priva, on va pas faire VP une plateforme, on va faire VP Priva une plateforme.
[00:33:54] Et euh donc c'est un vrai changement de vision et ils nous ont dit bah c'est quoi les impacts? Déjà, il y a des vrais impacts sur le front où à c'était complètement transparent pour eux d'avoir une plateforme et euh une plateforme pour une marque parce que vous aviez un seul site web à à déployer, là vous vous retrouviez en Espagne avec deux sites web. Donc il fallait développer le site web brand et Priva. Vous alliez aussi avoir à gérer de la multicy, un membre peut avoir deux comptes sur ces deux marques. Avec des commandes différentes et cetera, sur la finance, il fallait aussi diviser et gérer les chiffres d'affaires de manière séparée, donc ça avait des impacts techniques à tous les niveaux, logistique.
[00:34:36] Euh, financier, comptable, sur le front, sur la production des ventes et cetera et cetera.
[00:34:44] Le fait d'avoir et on l'a fait, on l'a pas fait exprès, mais c'était notre manière de communiquer, on avait communiqué la vision et la stratégie. Quand on est on a communiqué le fait que la vision avait changé aux équipes en 2 semaines ou 3 semaines, en 2 semaines, 2 3 semaines, on avait un chiffrage de c'était quoi les impacts, les équipes nous ont remonté les impacts euh en terme de coût et en terme de délai.
[00:35:10] En 2 semaines, en 3 semaines, on a remonté les coûts, les délais, donc il y a eu des allers-retours parce qu'il y avait des questions et des points de précision et l'équipe avait shité sur la nouvelle vision en toute autonomie, il y a pas eu d'accou, il y a pas eu de blocage, il y a pas eu de délai. Parce que les gens avaient en tête la vision et la stratégie et encore une fois, on n'a pas fait exprès, mais après coup quand on analyse, c'était vraiment ça. Les gens savaient quelle était la stratégie, notre vision c'était One platform One brand.
[00:35:35] Notre stratégie c'était à Rome fait comme les Romains, à l'époque c'était ce que je disais, c'est on développe sur VP tout ce qui est fonctionnellement comme VP, vous le faites, s'il y a un trou fonctionnel qui est pas couvert, on le développe et si en tactique, il y a un moyen de faire mieux dans les délais et dans les contraintes imposées par le business, on fait. Les gens avaient la stratégie, avait compris que la stratégie avait pas shifté et qu'on avait une deadline et qu'il fallait à Rome faire comme les Romains, donc utiliser au maximum le fonctionnement de la plateforme VP et ne pas s'en écarter. Ils ont très vite compris qu'elle était le nouvel ajustement pour aller vers cette nouvelle vision, ce que ça signifiait en coût et quand on leur a dit go, ils étaient complètement autonomes pour shiter et y aller. Donc communiquer sur la vision et la stratégie, ça permet d'éviter ces à coups parce que sur des gros projets, certainement à un moment donné, il y aura un imprévu, il y aura un changement. Là, c'était un vrai un vrai changement de vision, mais vous pouvez aussi avoir des changements. Et en leur communiquant ça, vous leur donnez vraiment l'autonomie comme un GPS, quand il y a un accident sur la route ou un embouteillage, il recalcule son chemin, il recalcule sa road map.
[00:36:42] Les architectes dans tout ça. Alors la première chose c'est qu'on est garant de mettre en place la délégation et de pas agir en enfin de de vraiment déléguer euh sans se substituer dans les décisions. C'est très dur, on a beaucoup de mal euh surtout quand les gens arrivent euh de se mettre dans cette posture de le leader le lead dev dans son produit, c'est lui qui décide, c'est lui qui est maître à bord. C'est lui qui fait, donc c'est lui qui sait et c'est lui qui assumera les responsabilités tous les jours dans ses développements, c'est lui qui fait sa prod, c'est lui qui gère ses supports, c'est lui qui gère ses bugs, donc c'est à lui de prendre les responsabilités. Donc l'une des difficultés, c'est vraiment de faire rentrer ce mindset euh dans la tête des des des des des des des des des architectes moins inclus et de s'assurer que ça fonctionne comme ça. Puisque vous allez avoir plein de gens qui vont vouloir volontairement ou involontairement prendre des décisions à la place, dire bon bah, c'est je pense tout le cas du business qui vient vous voir avec la solution et pas le problème ou des fois ça va être le PO qui va vous imposer une solution ou pas. Nous, on est un peu les gardiens, on est un peu garants de non, celui qui doit prendre la décision sur un sujet technique, c'est cette personne, donc on doit s'assurer qu'il est dans de bonnes conditions et de protéger des ingérences. Ensuite, l'attitude des architectes. Donc, l'une des difficultés, c'est vraiment de faire rentrer ce mindset euh dans la tête des des des des des architectes, un moins inclus, et de s'assurer que ça fonctionne comme ça. Puisque vous allez avoir plein de gens qui vont vouloir, volontairement ou involontairement, prendre des décisions à la place, dire, bon, ben, vous savez, je pense tous le cas du business qui vient vous voir avec la solution et pas le problème, ou des fois ça va être le PO qui va vous imposer une solution ou pas. Nous, on est un peu les gardiens, on est un peu garants de, non, celui qui doit prendre la décision sur un sujet technique, c'est cette personne, donc on doit s'assurer qu'il est dans de bonnes conditions et de protéger des ingérences. Ensuite, l'attitude des architectes, euh, l'exemple que que que que je donne souvent, c'est euh la Belgique en 2010-2011, euh, pendant 18 mois, ils ont vécu sans gouvernement. Donc, il y avait un problème politique où ils se sont pas mis d'accord, et pendant 18 mois, il y avait pas de gouvernement. Donc les gens, ils disaient, mon Dieu, ils vont mourir, la Belgique, ça va être un carnage. Et en fait, ce qui s'est passé, c'est que ils ont eu de très très bonnes performances, le pays s'est très bien porté sur le plan économique, sur le plan sur tous les plans administratifs et cetera. Le pays a très bien tourné sans politicien. Ce que je veux dire par là, c'est que l'architecte est pas indispensable. Si vous retirez tous les architectes de vente privée, vente privée fonctionnera. Vipi fonctionnera. Ceux qui produisent la valeur, ce ne sont pas les architectes.
[00:38:56] Ce sont les développeurs et les lead développeurs. Ce sont eux qui produisent la valeur et la richesse de la boîte. Nous, on est là pour les aider à maximiser leur productivité dans le meilleur contexte et dans le meilleur environnement possible. On est vraiment une fonction support. C'est pas eux de faire des choses pour nous, mais c'est à nous de faire des choses pour eux pour faire en sorte qu'ils soient dans le meilleur contexte et dans le dans les meilleures conditions. La première question que tout architecte doit poser à un lead développeur ou à une équipe, c'est comment je dois vous aider, comment je peux vous aider ? C'est vraiment ça. Et si vous regardez, euh, j'hésitais entre cette image et des images de Cherpa. Mais j'aime bien l'attitude du chef d'orchestre, c'est que il est face à l'orchestre et pas face à la foule. Donc il est pas là pour prendre la lumière et c'est pas lui qui produit euh la musique, c'est les musiciens. S'il y a pas de chef de, s'il y a pas de chef d'orchestre, il y aura de la musique. Ils vont produire de la musique. Peut-être pas aussi bien, mais ils vont produire. S'il y a pas de musicien, il y a pas de musique. Il y aura un un gars qui qui s'agite.
[00:40:05] Ça peut être marrant. Euh, le vraiment, c'est c'est c'est vraiment c'est vraiment ça. Notre attention, elle doit être complètement tournée vers les gens qui produisent et s'assurer qu'ils sont dans de bonnes conditions et euh que s'ils ont un besoin de support sur des choix, s'ils ont besoin d'une aide, s'ils ont des interrogations, s'ils ont des questions, on est là pour les aider et leur apporter des réponses. On est vraiment une fonction support et euh c'est euh c'est c'est chez nous, c'est non négociable. C'est vraiment important. Et quand vous vous mettez dans cette attitude, quand vous vous mettez dans cette posture, votre relation va être meilleure, votre relation et les gens vont vous interroger. vont vous poser des questions, vont partager leur choix. Vous déléguez le choix, mais vous participez à la décision parce que vous avez une bonne relation avec eux. Ils savent que vous êtes là pour les aider, pas là pour les contrôler. Vous êtes pas l'œil de Moscou. Et que euh dans tous les cas, vous serez à côté d'eux. L'attitude, c'est vraiment important, et on est une fonction support. Non euh, je devrais pas dire ça. Je risque d'avoir des problèmes pour mon emploi, mais euh c'est ce que je pense. On n'est pas on est beaucoup moins important que les développeurs.
[00:41:14] Notre organisation, euh, en tant qu'architecte dans les trois domaines. Alors là, si vous regardez cette image, il y a fonctionnellement, ces gens changent des roues. Alors, c'est pas pareil, on soit euh sur un pit stop de Formule 1 ou en galère sur le bord de la route, mais ces gens, fonctionnellement, changent des roues. Euh, chez Vente-privée, si vous prenez nos trois domaines, donc on a la partie sourcing qui va être production des ventes, négociation, opération logistique, supply, finance et le front.
[00:41:47] C'est des contextes extrêmement différents. Si vous prenez, par exemple, toute la partie distribution channel, qui est le front, les appli mobiles. Fonctionnellement, c'est pas très dense. Il y a pas une richesse fonctionnelle extraordinaire et une vraie complexité. Par contre, techniquement, c'est extrêmement pointu. On a un business où on a une ouverture de vente où pendant la première, les deux trois premières les premières minutes, on est on a un pic de charge vraiment très très fort. Travailler au front, les contraintes sont plutôt techniques et extrêmement pointues.
[00:42:20] Donc les architectes qu'on va avoir au front n'ont pas ne peuvent pas avoir le même profil que des architectes côté sourcing où là il y a une complexité plutôt fonctionnelle et business. ou côté opération où on a besoin de gens qui maîtrisent vraiment les flux et euh les réglementations. Tout ça pour vous dire que en terme d'organisation,
[00:42:43] moi pour moi c'est de la paresse que de vouloir d'avoir une organisation symétrique partout dans votre, dans votre organisation. Parce que euh si vous cherchez la vitesse et la performance, vous devez vous ajuster à vos contextes. Et dans votre organisation, les différentes parties de votre organisation ont des contextes différents. Le front a un contexte extrêmement différent des opérations qui est très différent du sourcing. Un architecte chez nous au front, ben je l'embaucherai pas comme architecte côté opération. Parce qu'ils ont pas les mêmes profils, ils ont pas les mêmes appétences et même lui serait malheureux. Au front, les architectes développent, ont des responsabilités sur certains composants, ont une équipe dédiée de développeurs. Côté sourcing, ils ne développent pas, ils font de l'urbanisation. C'est plutôt une équipe d'urbanisation qui fait un exercice d'architecture d'entreprise. Donc c'est vraiment des profils différents, ils ont des tailles différentes et des organisations différentes pour répondre au mieux aux problématiques et au contexte de chacun des domaines. Et pour moi, c'est vraiment vraiment important. On cherche pas à avoir une organisation symétrique, mais on donne la liberté de la même manière qu'on donne de la liberté dans la prise de décision, on donne de la liberté dans la manière de s'organiser et travailler aux architectes dans chacun des domaines. Ce que je vous disais sur la délégation au tout début, de comment on délègue. Par exemple, pour côté opération, logistique, supply. Les architectes sont spécialisés par flux. Le passage de commande, l'approvisionnement, la comptabilité. Donc, si on a une fonctionnalité ou une feature ou quelque chose à faire sur la descente de commande, on va plutôt s'orienter vers ces architectes. Côté front, ils vont avoir une responsabilité plus sur les sur les éléments critiques communs à tout le front. Euh, le catalogue, l'exposition du catalogue, l'exposition du stock et cetera et cetera. Donc ça va être plus une organisation où ils vont avoir de leur responsabilité et du développement sur des composants communs. Côté sales prep, négociation, production, ils sont plutôt organisés par tribe.
[00:44:50] Vous allez avoir des gens qui sont spécialisés sur la partie négociation et des gens qui sont plutôt spécialisés sur la partie euh production. Donc, on n'a pas une organisation symétrique, euh, les architectes n'ont pas le même rôle à travers l'organisation et le but, c'est de répondre au mieux aux questions des différents contextes dans lequel ils sont ils sont engagés.
[00:45:13] Le pragmatisme. Ah, ça c'est mon sujet préféré. Euh, on est une industrie qui aime bien la polémique et les discussions stériles sur euh ah, tu fais de l'architecture d'entreprise, tu fais de l'informatique des années 60, moi je fais de l'agilité ou je fais du safe. C'est super à la mode, c'est la meilleure méthode, il faut faire ça. Euh, nous, on s'en fout. On s'en fout de savoir d'où vient et d'où tu es issu une pratique à partir du moment où elle a une utilité ou elle répond à un problème, on prend. Ma conviction, c'est que il n'existe pas de framework aujourd'hui. Un framework, c'est un ensemble de solutions, d'organ d' de process, et cetera. Il y en a aucun qui répond de manière cohérente aux problématiques que vous allez rencontrer. Par contre, dans chacun des frameworks, que ce soit des frameworks Agile ou des frameworks à l'ancienne, vous allez trouver des choses qui sont extrêmement pertinentes et utiles. Et le choix qu'on a fait chez Vente-privée, c'est de se dire, bah, on part du problème, qu'est-ce qu'on a comme problème, et qu'est-ce qui existe qui résout ce problème ? Alors si c'est des trucs à l'ancienne, on prend, on s'en fout. Si c'est des trucs très récents, on prend, on s'en fout. Par exemple, l'organisation produit de VP et je pense que c'est une des choses dont je suis le plus fier chez Vente-privée.
[00:46:35] qui est d'avoir participé et contribué à l'organisation produit. La base de cette organisation, c'est un plan d'occupation des sols. Donc c'est l'architecture à l'ancienne. Et c'est l'un des assettes les plus importants chez Vente-privée. Notre organisation, notre découpage domaine tribe, c'est rien de plus qu'un exercice d'urbanisation et d'architecture d'entreprise. Euh, on utilise des Wardley Map pour discuter avec le business et faire apparaître les dépendances. Ils sont intéressés par la partie élevée du de la Wardley Map. Et nous, ce qu'on veut leur faire voir, c'est, OK, tu veux faire ça, mais oublie pas que ça a des impacts sur ces produits et sur ça, et que ça nécessite cette charge de travail. Donc la Wardley Map, c'est extrêmement utile pour définir pour se bosser sur les dépendances.
[00:47:19] Euh, on utilise aussi de l'Event Storming euh côté production pour voir et identifier les flux et voir comment est-ce qu'on peut optimiser euh ces choses-là. On va utiliser du BPMN aussi sur la vision statique dynamique du système d'information avec des swim des swim des swimpool, des piscines. pardon, pour voir comment pour pour visualiser les process. Euh, on utilise qui et des fois euh pareil euh des des fois il y a rien et on invente nos propres on a nos propres support comme notre la la Light map qu'on utilise et qui sont pas des choses de l'industrie et qui répondent à un besoin. Donc, au lieu de se poser la question de, est-ce que c'est vieux, c'est c'est nouveau et d'appliquer un framework de manière complète ? Et on utilise aussi le C4 pour la modélisation des systèmes et cetera. C'est quel est mon problème ? Qu'est-ce qui existe comme solution, et on l'applique. Si c'est prati si c'est efficace, on le garde, quelle que soit sa provenance. Et ça, c'est vraiment important.
[00:48:23] Alors, pour conclure, euh, on a parlé de contexte, on a parlé d'architecture et des architectes. Une chose aussi à prendre en compte dans le contexte, c'est la maturité des gens et le niveau. Il faut rester humble sur son niveau. Et souvent, vous allez voir des gens qui vont lire des livres et qui vont venir vous voir et vous dire, bon, ben, on va déployer ça ou cette méthode, c'est génial. sans prendre en compte la maturité de l'équipe ou la maturité du système d'information, quand vous avez beaucoup de Legacy euh, il y a des méthodologies, des pratiques qui peuvent pas fonctionner. Et le niveau des gens, il faut se connaître et être vraiment très humble sur son niveau, ça fait partie du contexte. N'appliquez pas, ne mettez pas en place des choses que vous ne pouvez pas assumer. Euh, j'ai lu énormément de livres où vous lisez des pratiques, vous dites, c'est génial, ça, ça serait bien, mais quand vous regardez, vous dites, est-ce que j'ai la capacité de le mettre en place ? Est-ce que j'ai le niveau de compréhension d'expérience ? Est-ce que c'est le bon timing pour le mettre ? Ça, ça fait partie aussi des choses. Donc,
[00:49:27] c'est important quand on parle de contexte, de aussi prendre en compte notre niveau et le niveau global de la boîte et la capacité de la boîte de vous suivre. Il y a rien de pire que de faire quelque chose qu'on n'est pas capable d'assumer. Si vous n'êtes pas capable d'assumer, ne le faites pas. Et le dernier point, c'est, ça a marché chez nous, c'est en complète transformation, il y a des choses qu'on a mis en place il y a 5, 6 ans, qu'on a retiré, qu'on a remis, c'est quelque chose qui évolue dans le temps, euh, dans notre approche, il y a aussi beaucoup d'erreurs, on se trompe beaucoup. Et en tout cas, nous, c'est comme ça qu'on essaie d'avancer et qu'on essaie de travailler. Et je vous remercie pour votre patience, votre écoute. Je vous remercie pour votre patience.
[00:50:13] Ok.
[00:50:25] Merci beaucoup. Ouais, super. Euh, vraiment je vous remercie de votre présentation qui était super claire. Je réagis juste sur la Belgique.
[00:50:37] Je suis désolé hein, mais en fait, ça s'est mal passé en fait, parce que ce qui s'est passé, c'est que notamment les associations les associations culturelles, euh, les les budgets étaient reconduits tels quels. Ils avaient pas le droit de changer les budgets. Donc notamment les Asols, elles se sont retrouvés dans des histoires un peu compliquées où on pouvait plus rien créer et c'était celles qui avaient déjà de l'argent qui continuaient d'en avoir. Donc c'est pas du tout pour critiquer votre image, c'est justement pour la prolonger et je me demande si le rôle de l'architecte, c'est pas aussi ça à des moments d'éviter que ce soit c'est pas parce qu'on faisait ça bien qu'on va continuer de faire pareil. Et que bah quand il y a pas d'architecte, on va continuer mais cette idée de mettre la lumière là où ça marche pas ou ça marche bien justement éteindre dans les pièces où bah finalement ça marche plus, c'est pas aussi un des rôles de l'architecte dans une entreprise telle que VP.
[00:51:23] Si si. Alors alors merci pour la la remarque et je je le prendrai en compte pour les prochaines présentations, je creuserai, je travaillerai plus mon exemple. Euh c'est c'est exactement ça, c'est on est des facteurs d'optimisation et d'accélération. Et quand dans l'exemple de la Belgique, ce que je voulais dire, c'était le pays est pas tombé, enfin, le pays est ça a pas été la catastrophe. C'était plus pour dire l'architecte, il a une importance.
[00:51:50] Le le chef d'orchestre, c'est lui qui donne le rythme, c'est lui qui qui synchronise les gens, qui reprend les gens quand ils font quelque chose de mal, il a un rôle. Avec le chef d'orchestre, on optimise quelque chose. Donc il y a un impact, un intérêt. Un gouvernement, ça a aussi un impact, c'est lui qui donne la vision et qui donne le rythme. Je c'est ce que ce que ce que j'ai essayé de dire et je l'ai mal dit et je vous remercie de la question pour pouvoir préciser mon propos. C'est dire que, on a quand même de la musique. On a quand même un pays qui fonctionne. C'est pas la fin du monde vous voyez ce que je veux dire. Oui, je suis d'accord avec vous, il y avait sûrement des choses qui se sont mal passées, qui auraient pu être améliorées. Et le rôle des gouvernements, c'était de prendre des décisions, d'allouer les budgets aux endroits, et ils ont cette importance là. Mais euh, l'exemple que j'essaie de prendre, c'est de dire, bah, s'ils sont pas là, certes, on s'améliore pas, certes, on va pas, mais c'est pas la catastrophe. Là où si demain il y a plus euh il y a plus d'administration,
[00:52:48] là c'est vraiment la catastrophe.
[00:52:51] Encore une ou deux questions? Il y en a un devant. Ah, pardon.
[00:52:56] Bah, alors du coup, j'ai pas vu qui.
[00:53:04] Bonjour, merci beaucoup pour cette présentation, c'était très intéressant. J'ai une question par rapport euh à la confiance qu'il y a entre les architectes et les lead Dev, par rapport à ce qui s'est passé, entre autres aussi avec le Covid, dans le sens où on a beaucoup plus de télétravail, c'est beaucoup moins facile de créer des relations de confiance. Euh, et aussi des fois, il y a des personnes qui ont pu un peu lâcher, on va pas se mentir, euh, des gens qui sont beaucoup plus difficiles à à embarquer. Comment vous avez réglé cette problématique au sein de Vipi ? Alors, euh, on en a parlé en interne et euh, en tout cas, moi, c'est ma conviction, si on avait fait convergence pendant pendant le Covid, on n'y serait pas arrivé.
[00:53:33] Euh, on a, je crois au rapport humain et au contact humain. Je dis pas que le télétravail c'est des mauvaises choses, je suis très content d'être à la maison en télétravail. je crois au rapport humain et au contact humain. Je dis pas que le télétravail c'est des mauvaises choses, je suis très content d'être à la maison en télétravail, mais à un moment ce contact humain, cette proximité, elle a aussi une importance. Quand on a fait quand on a démarré convergence, c'était d'un point de vue humain très compliqué. Il faut s'imaginer trois équipes, enfin, les Belges et les espagnols, on était l'envahisseur pour eux. Euh, le fait de se déplacer, d'aller les voir, de manger avec eux, de discuter avec eux, de vraiment montrer qui on est, la personne qu'on est, de leur montrer qu'on est là pour le bien de l'entreprise et pas pour les envahir et récupérer les choses, que le choix qu'on a fait, qui a priori était, on va prendre la plateforme Vipi et pas celle de Privalia, c'était un choix raisonné et objectif. euh, ça a eu son importance. Le Covid, ça a été très dur, on on a eu sur le plan humain beaucoup beaucoup de casse, il y a eu beaucoup de gens qui ont été recrutés avec qui il y a pas le même niveau de confiance. Et euh c'est très dur. C'est très très dur. On a euh le morning café, on a des présentations, on a des channels Slack où on va échanger des blagues, on va rigoler, mais en tout cas, moi ma conviction, c'est que ça remplace pas un déjeuner ou euh c'est très dur, c'est très très dur. On a le morning café, on a des présentations, on a des channel slack où on va échanger des blagues, on va rigoler, mais en tout cas, moi ma conviction, c'est que ça remplace pas un déjeuner ou aller boire un coup après le boulot ou aller prendre un café, discuter c'est différent. Une réunion, ça se programme, prendre un café, c'est c'est voilà, c'est je suis là, j'ai mal à la tête ou je vois l'autre qui vient de passer une réunion où il s'est énervé, bon viens, on va prendre un café, on va discuter.
[00:55:23] Le contact humain pour moi, c'est vraiment essentiel.
[00:55:26] Et le Covid, on a eu de la chance d'avoir fait tout ce travail un peu avant. Je sais pas si ça répond.
[00:55:34] Merci.
[00:55:37] Merci pour cette présentation très intéressante. Euh, je voulais juste revenir sur le la délégation et euh, est-ce que vous avez des des moyens peut-être de de remonter l'information après ? Parce que j'imagine qu'il y a des des pratiques qui sont adoptées à l'échelle de l'équipe qui peuvent bénéficier peut-être. Est-ce que vous avez des retours d'expérience sur comment propager sans sans forcer finalement vous-même prendre la décision.
[00:55:57] En fait, euh, ça c'est super intéressant.
[00:56:03] Euh, oui, euh, c'est c'est ça fait partie des choses dont je voulais parler et je vous remercie pour la question. C'est que le fait de déléguer et d'être dans l'équipe, ça permet justement d'avoir une fluidité dans dans dans la décision et de participer à la décision et pas de la contrôler après coup. La deuxième chose aussi qui est utile, c'est que nous, on a une communauté d'architectes qui discutent entre nous. Donc, quand on va identifier quelque chose qui se passe bien dans une équipe, euh, une approche, une technique et cetera, on va en discuter et on va en faire en sorte que cette pratique, cette chose, on va la diffuser. Donc, on va pas dire, maintenant, vous allez tous faire ça parce qu'on revient dans le premier biais qui est d'imposer une approche, mais on va communiquer sur cette approche, sur cette méthodologie. Donc on a en interne ce qu'on appelle les experts corner, toutes les semaines, on a des présentations techniques où les gens viennent, on les pousse, on les aide à présenter ce qu'ils font et comment ils font. Après, on a aussi des outils en interne qui nous permettent de visualiser qui utilise quoi comme technologie et cetera.
[00:57:00] Donc, nous, on est aussi des des agents des des promoteurs dans les échanges entre les différents lead dev. Si quelqu'un fait quelque chose dans une équipe et que je travaille avec une autre équipe qui fait une problématique similaire, je vais les mettre en relation. Donc on a aussi ce rôle de partage de connaissance et diffusion des bonnes pratiques.
[00:57:22] Ben, je pense qu'il est l'heure de conclure et d'aller prendre un café. Merci encore.

Transcription