MG : J'essaye d'accompagner l'entreprise dans sa transformation de pratique, de culture, de structure, d'usage de la tech au service du business. Beaucoup de transparence, au final. Transparence du code, transparence des perf', transparence de la valeur créée de chaque produit. Et ça fait que, petit à petit, on s'ouvre, on connecte les produits des autres, on enrichie son système d'information grâce au savoir des autres business units.
BR : Bonjour à tous et bienvenue sur le podcast CIO Révolution, le podcast des DSI modernes. Je m'appelle Bertran Ruiz, je suis le CIO d'Airsaas, une solution Web qui permet à la DSI, à la direction générale, de partager une vue claire des projets en cours, des décisions à prendre et des priorisations à faire. Pour faire le meilleur produit au monde, nous avons décidé de lancer ce podcast pour interviewer des DSI moteurs de la transformation de leur entreprise et tout faire pour comprendre leurs enjeux et leur méthodologie. Nous y abordons des sujets comme l'organisation projets, les copil, la relation avec la direction générale, l'impact du no code avec l'IT et bien d'autres choses encore. Grâce à eux et à leurs feedbacks, aujourd'hui, avec Airsaas, vos rapports projet de comité de pilotage sont faits en un clic. Plus besoin de passer des heures sur PowerPoint ni à rechercher l'information dans vos emails. Vous avez une vue agrégée de toutes vos données projets : budget, risques, temps passé. Et pour éviter toute ressaisie d'information, Airsaas se connecte à vos outils : Microsoft Teams, Jira, Wrike, etc. Sur ce, je vous laisse avec ce nouvel épisode, à la découverte de nouvelles façons de faire.
Écoutez, bonjour à tous. J'ai le plaisir aujourd'hui d'avoir avec moi Matthieu Grymonprez. Bonjour, Matthieu.
MG : Bonjour.
BR : Matthieu, qui est le CIO et CTO d'Adeo. Est-ce que, Matthieu, tu peux nous parler un petit peu de ta mission et de ton entreprise ?
MG : Alors, Adeo, c'est plus connu pour le grand public sous la marque Leroy Merlin. On est leader européen, mondial même, après les deux américains, dans tout ce qui est le home improvement. Donc ça dépasse même maintenant le bricolage. Mais on est quand même connu avant tout pour ça, les magasins de bricolage. Mais de plus en plus, on vend des solutions pour la maison. Et on est présent dans pas mal de pays. Beaucoup en Europe, donc Europe du Sud - Espagne, Italie, Grèce, Portugal - Afrique du Sud, Amérique du Sud, une très forte présence en Russie, également en Roumanie, en Pologne. On a également des brands sur le marché B2B, donc avec Bricoman où on sert les artisans professionnels, Bricomart en Espagne qui marche très bien, et en Italie aussi. Donc, on a vraiment deux marchés. On fait 28 milliards d'euros de chiffre d'affaires, d'une manière générale, donc ce n'est pas mal. Et on a plus de 300 magasins, de mémoire.
BR : OK. Et du coup, vous êtes le CIO/CTO groupe.
MG : Voilà, je m'occupe donc de toute la tech au niveau du groupe et de la transformation digitale. Donc ce n'est pas que le DSI, ce n'est pas que le CTO, mais j'essaye d'accompagner l'entreprise dans sa transformation de pratique, de culture, de structure, d'usage de la tech au service du business, sur l'ensemble des métiers depuis la supply chain, l'expérience client, le Web... l'intégralité de ce qu'on veut faire.
BR : Donc du coup, une des caractéristiques de votre parcours, c'est que vous avez été CIO/CTO d'une entité Leroy Merlin, celle du Brésil, et après, vous êtes venu au niveau groupe. Qu'est-ce qui vous a aidé dans cette expérience d'abord nationale ? Pour comprendre les spécificités et avant de pouvoir aussi l'appliquer ou aider à un peu cette standardisation au niveau global.
MG : Alors, ça fait partie un peu d'une association entre mon parcours et la culture de l'entreprise. J'ai fait beaucoup de réseau, de sécu, puis j'ai remonté un peu toutes les couches : de la base de données, du dev, de la gestion de projet, jusqu'à de l'architecture d'entreprise. Et donc, j'allais un peu là-bas pour coordonner la résolution des problèmes. Et puis, petit à petit, le directeur général local m'a demandé si je ne voulais pas venir de manière plus présente. Et c'est là qu'on a défini ensemble l'opportunité de transformer un peu cette boite-là. L'avantage, c'est qu'on est un peu loin de la France. C'était aussi notre capacité d'innover, d'avoir aussi une culture locale beaucoup plus agile, donc avec moins de peurs de transformations, moins de conséquences aussi, puisque nos grosses business units, comme la France ou la Russie, sont quand même plus lourdes à changer. Donc, on a beaucoup innové et on a pris le chemin de la transfo digitale. On a refait l'intégralité du systèmes d'information, mais avec des méthodes plus modernes, sur des techno plus modernes. Et c'est comme ça que cette boite s'est transformée. Et donc, en 2018, forte de la transformation de cette business unit, j'ai envie de dire successfull, en gros, le comex m'a demandé de venir le faire, mais à l'échelle du groupe.
BR : Et aujourd'hui, par rapport à une expérience, on va dire, où vous étiez un peu plus loin du groupe, avec peut-être une agilité aussi de décision qui était celle d'une entité extérieure, est-ce que, par rapport aujourd'hui au groupe, c'est différent ? Est-ce que votre expérience nationale vous permet de mieux comprendre les problématiques qu'ils ont un peu partout dans les pays, du coup aussi d'être peut-être plus dans l'empathie dans la proposition que vous faites ou dans la méthode que vous proposez pour travailler ensemble ?
MG : Oui, c'est indéniable qu'être passé par-là légitimise aussi le discours, quand on a un discours de groupe. Les challenges sont totalement différents. L'un alimente l'autre, mais la complexité de le faire à l'échelle d'un groupe et de multiples entreprises, c'est vraiment exponentiel par rapport à le faire à l'échelle nationale, puisque toutes les décisions qu'on peut prendre ont un impact indirect. Quand on est dans une business unit, qu'on est le DSI, qu'on pilote la refonte d'un site Web, on voit les développeurs tous les jours. Donc, si ça ne prend pas le chemin qu'on veut, s'il y a quelqu'un qui a une innovation qu'on veut tester, on peut tout de suite approuver, tout va très vite dans la capacité de prendre des décisions, des risques et de tester. Quand on le fait à l'échelle d'un groupe, il y a toujours une latence énorme, puisqu'il faut que ce soit compris par le manager qui va l'implanter dans son pays. Donc, on est beaucoup plus sur des aspects de culture, de systémique j'ai envie de dire, de l'organisation de notre structure organisationnelle et l'organisation de notre culture. Et donc, quand on parle de changement de culture, ça prend toujours du temps, parce que ça se fait au rythme des hommes. Donc, il faut savoir un peu anticiper les peurs, anticiper ce qui pourra freiner ce changement culturel ou structurel. On peut par exemple parler de ressources humaines. Quel niveau de strategic workforce planning je mets en place dans chaque pays pour que je puisse avoir le bon niveau de développeur, pour développer des produits digitaux localement si ça vaut le coup ? Comment je fais un assessment des skills dans chaque pays pour savoir si le gap est franchissable ou pas, pour intégrer une plateforme globale ? C'est à une autre échelle, vraiment, c'est un peu plus compliqué.
BR : Est-ce qu'on peut dire que vous devez animer, en fait, une communauté de DSI et de managers SI ? Et donc du coup, dans ce mot d'animation et aussi de communauté, c'est par le leadership, mais aussi la construction d'une vision commune et une envie d'avancer ensemble. Et que du coup, puisqu'il y a quand même une culture, de ce que j'ai compris, où chacun peut faire aussi un peu sa vie, c'est la culture du groupe, mais c'est aussi de créer une envie commune, d'avoir des solutions communes et d'avancer ensemble.
MG : Oui, c'est exactement ça. En fait, ça se travaille d'abord par le sens. Pourquoi on fait les choses ? Ensuite, quand on est tous d'accord sur le sens de ce qu'on cherche à atteindre, ce qu'on veut délivrer comme expérience pour le client final, pour les habitants du monde, c'est comme ça qu'on voit les choses. Après, on a beaucoup de discussions avec tous les DSI et la communauté des DSI sur la méthode. On n'est plus sur l'objectif de "est-ce on est vraiment tous d'accord", mais quelle méthode ? Quelle est la méthode la plus rapide ? Est-ce que c'est forcément la plus structurée ? Pas toujours. Quand on veut vraiment structurer les choses à une échelle industrielle pour être scalable, ça prend des fois un peu plus de temps. Et c'est vrai qu'une petite business unit qui fait 500 000 visites mensuelles sur son site n'a pas les mêmes problématiques que Leroy Merlin France, qui en fait des dizaines de millions. Donc forcément, ça demande un peu de souplesse. Ça ne sert à rien de tout centraliser et d'être ultra rigide, parce que ça ne marche pas, mais tout décentraliser, ça ne marche pas non plus, parce que les gens n'arrivent pas à fournir l'expérience digitale adéquate dans toutes les parties du monde. De par le manque de skills, tout simplement. Aujourd'hui, pour faire une très bonne expérience digitale, être reconnu, il faut beaucoup de skills, il faut des gens très bons sur tous les domaines : du search, de la publication, du front-end, du back-end, de la perf', du cloud, etc. Et on voit bien que quand on est en Afrique du Sud et qu'on a une business unit naissante, ce n'est pas évident de tout de suite arriver à un niveau d'excellence sur ces expériences digitales. Donc on est obligé de trouver ce qu'on a envie de faire en commun, ce qu'on a envie de faire en global, ce qu'on lâche, typiquement. Par exemple, une des décisions qu'on a prises dès que je suis arrivé, c'est de globaliser toute l'expérience cloud : le delivery, le CI/CD, la data... Voilà, on a arrêté les storages locaux, les clouders locaux et compagnie. Il n'y a que du global là-dessus. Comme ça, on a une vraie chaine de dev globale. On a mis en place des cultures comme l’open source interne, qu'on appelle l'inner source, pour que tout le monde puisse voir les produits développés par les autres, alors qu'avant, il y avait des difficultés de communication même pour savoir qui faisait quoi à l'échelle d'un groupe mondial. Donc, l'inner source, on voit le code de tout le monde. Tout est autour de beaucoup de transparence, au final. Transparence du code, transparence des perf', transparence de la valeur créée de chaque produit. Et ça fait que, petit à petit, on s'ouvre, on connecte les produits des autres, on enrichie son système d'information grâce au savoir des autres business units, et on crée une sorte d'agilité mondiale. Mais pour ça, il faut beaucoup l'expliquer, parce que ça veut dire que chaque DSI dans chaque business unit perd un peu de son pouvoir, perd un peu de sa capacité de décider seul. Et ça, il faut le faire comprendre.
BR : Et c'est intéressant sur l'opposition centralisation/décentralisation. Ça revient à des phénomènes qu'on a connus dans le mode du code, avec le côté cathédrale et le côté bazar. Est-ce qu'au niveau des organisations, et donc du coût de cet organisme vivant, on peut voir un peu un *** (12:20) avec un responsable qui contrôle le collectif et dit : "Voilà, ça, c'est à nous, ensemble, et tu peux l'utiliser comme tu peux ne pas l'utiliser." Mais qu'en même temps, les autres personnes, s'ils veulent l'utiliser, il faut quand même qu'ils l'utilisent de plus en plus parce que s'ils sont trop loin, ils ne pourront pas revenir. Et cette relation entre décision dictatoriale, dirons-nous, et collectif où tout le monde peut forker et faire les choses différemment. Est-ce que c'est une dynamique un peu identique ou similaire ?
MG : Oui, ça marche un peu comme ça. Comment on est organisés ? Tout d'abord, en partant de très haut, l'architecture d'entreprise est globalisée. Donc en fait, les building blocks sont définis et ne sont pas négociables. Comme ça, les périmètres des produits que l'on cherche à développer sont fixés. Ensuite, les repos sont publics, donc ils sont définis par type de plateformes. Donc on en a pour du customer and commerce, de la supply chain, les offres, le B2B, etc. Tout ça, ce sont des plateformes digitales cohérentes entre elles. Donc elles sont en capacité de fournir un service, ou global ou en micro service à l'intérieur de chacune d'entre elles, mais certaines plateformes sont composées de dizaines et dizaines de produits digitaux. Et chaque produit digital a un responsable, donc responsable de code. Donc, au final, ce qui se passe, c'est que soit il y a un produit concurrent en interne qui fait mieux le job, et à la fin, c'est lui qui remporte la mise. Soit j'ai besoin de rajouter quelques lignes sur un produit pour un développement local, parce qu'il me manque une donnée pour une API ou quelque chose comme ça. Je fais la pull request et puis le patron du produit en question approuve ou pas en fonction. Donc, c'est aussi simple que ça. Ce n'est pas absolument dictatorial, mais il y a des périmètres définis au niveau de l'architecture. En gros, ce qu'on fait, c'est qu'on favorise très fortement le reuse, par des initiatives financières, tout simplement. Donc, si tu veux forker ou si tu concurrencer un produit qui existe déjà, soit tu le fais en démontrant la valeur et à ce moment-là, il se substitue à l'existant, soit tu veux le faire vraiment, mais tu vas finir par payer le produit deux fois, puisque tu vas payer quand même le produit commun. Donc ce qui se passe, c'est que souvent, c'est les financiers qui reviennent derrière à dire : "Bon, tu as vraiment envie de faire un autre produit ? Il faut que tu m'expliques parce qu'on va payer quand même assez cher." Donc il y a vraiment une tendance à aller vers le commun. Et puis, encore une fois, beaucoup de transparence. Ça clôt beaucoup de débats. Quand on voit, je ne sais pas, on mesure la productivité d'un produit avec le nombre de releases qu'on peut faire par semaine, le nombre de commit qu'on fait par semaine sur ce produit. Ben, c'est simple, si il y a un produit avec une équipe de 20 mecs qui commit une cinquantaine de fois par semaine, l'autre, de l'autre côté, il va avoir du mal à arriver à ce niveau-là. Donc c'est assez rare, finalement, qu'on ait vraiment de la concurrence. C'est arrivé dans le passé sur certaines briques fondamentales, comme le design system ou des choses comme ça, parce qu'il y a des business units qui avaient déjà bien avancé et ça les fait un peu suer de revenir en arrière sur un produit commun. Mais ça se fait... Moi, je suis assez flexible sur ça. L'idée, c'est de le faire au fil du temps. Tant qu'on n'a pas d'urgence, je ne force pas non plus les gens à entrer sur du commun si ce n'est pas absolument nécessaire. L'idée, c'est de le faire de manière opportuniste et que ça crée de la valeur à chaque fois.
BR : OK, très clair. Et aujourd'hui, c'est combien de DSI dans la communauté Leroy ?
MG : En fait, on en a un par business unit, plus des patrons de plateforme qui sont au même niveau. Ça va faire une grosse trentaine, peut-être même un peu plus.
BR : Ok, donc il y a une équipe de 30 personnes qui converge plus ou moins vers les mêmes solutions, même stack, et qui collabore pour créer de nouvelles choses. OK, super intéressant.
MG : Oui, il y a plus de 2 000 personnes globalement dans le monde qui travaillent sur de l'IT chez nous. Donc très large, parce qu'on peut vraiment parler de tout, que ce soit du portail fournisseur, de la branche services, de la branche B2B, tout ce qui est dépannage... Enfin, il y a vraiment des gens de la tech dans pratiquement tout, de la workplace, de la finance. Enfin, aujourd'hui, l'idée de l'organisation, c'était vraiment de faire comprendre qu'il n'y a plus aucun métier qui se fait sans de la tech. Donc, on a créé des plateformes, ou des squads pour les plus petites entités, à côté de chaque business, donc chaque business a son équipe tech dédiée et est en capacité d'avancer. Moi, je voulais vraiment casser le principe de la DSI fonctions support, qui sert tour à tour les métiers. Ce n'est pas assez agile.
BR : Donc chaque BU, chaque entité a une équipe tech à elle.
MG : Oui. Chaque fonction business.
BR : Chaque fonction business a une équipe tech, OK. Et donc, ces équipes-là dépendent du DSI ?
MG : Alors, ça dépend. Soit elles dépendent des plateformes mondiales, quand il s'agit des plateformes communes qui s'appliquent à tout le monde, comme notre nouvelle plateforme e-commerce, soit elles dépendent du DSI local, si le sujet, c'est l'encaissement local, la fiscalité locale. Ouvrir un entrepôt au Brésil, ça ne sert à rien de le piloter depuis la France, quoi.
BR : Donc ça, ça a permis de casser les silos et la vision, même la culture, de la DSI est centralisée, c'est un service support. Là, c'est proche des gens qui ont des problèmes. Ils voient la valeur. Et donc, du coup, ils valorisent aussi beaucoup plus l'IT en termes de services.
MG : Oui, et puis en fait, c'est un peu obligatoire, parce que créer des cycles agiles, ça se fait... La confiance, elle ne se crée pas au premier cycle agile. Ça dépend des personnes, mais il en faut au moins 2 ou 3 ou 4, avant que le business comprenne que s'il ne demande pas ce trimestre-là, il sera servi le trimestre d'après parce que les équipes seront encore là. Donc ça, c'est un principe nouveau pour les métiers, parce que les métiers étaient habitués à des cycles d'investissement IT annuels, avec je fais ma lettre au Père Noël, parce que je sais que j'ai ma fenêtre de tir avec l'IT cette année, et je ne l'aurais plus avant un an ou deux, donc je remplis le sac le plus possible de features que j'ai envie. Et ça, ça crée plein de problèmes. Donc avoir des équipes dédiées à des métiers, des équipes tech dédiées à certains métiers comme la supply chain, ça fait que toute la communauté des patrons de supply chain dans le monde sait qu'elle a un bon paquet de tech pour eux, tout le temps, et à dispo, et donc définit les priorités qu'il faut développer pour ce métier-là. Ça agilise énormément l'entreprise.
BR : Ça l'agilise et ça détend certaines frustrations ou incompréhensions liées à des processus un peu plus longs.
MG : Mais de toute façon, à mon sens, c'est le sens de l'histoire des DSI, aujourd'hui, on est arrivé dans une période où vraiment il n'y a plus rien qui se fait sans la tech. Absolument aucun métier se fait sans la tech. Donc soit on considère que tous les métiers sont tech et que la tech est dans tous les métiers, soit on va vraiment vite galérer. Ou on a une stratégie de... Oui, une stratégie de prendre ce qu'il y a sur le marché. Après, nous, on fait beaucoup de choses par nous-mêmes, déjà parce qu'on peut le faire financièrement, ensuite parce que ça fait du sens dans notre expérience, dans nos process métier. On a beaucoup customisé des solutions du marché. Au final, on s'est très souvent détaché ou détourné d'un SaaS, ou pire d'un progiciel, dans le temps, parce que nos process ne rentraient plus dedans, ou petit à petit on avait d'autres idées qui n'étaient pas couvertes par le soft. Et ça, aujourd'hui, quand on veut être agile, quand on veut être rapide, quand on veut inventer des trucs, c'est quand même mieux d'avoir ses codes sources et de faire ses choix. Sinon on customise et puis on rentre dans des problématiques de support, etc. Donc je ne dis pas qu'on fait tout. On a vraiment un framework de développement, un framework de make or buy pour choisir si on va chercher en SaaS ou le faire nous-mêmes. Mais il y a quand même beaucoup d'endroits où on se rend compte que le faire nous-mêmes, c'est plutôt cool.
BR : Il y a plusieurs choses que vous avez dites, sur lesquelles j'aimerais bien revenir. J'aimerais bien connaitre un peu ce framework make or buy qui a l'air intéressant, parce que du coup, c'est une vraie question, parce que vous avez la capacité de faire, donc il faut quand même se poser la question à chaque fois de dire "attends, est-ce qu'on y va pas un peu trop vite parce qu'on a la possibilité, on a l'envie, on sait faire, etc". Mais le premier point, c'est une certaine forme d'évidence qui, malgré tout, n'est pas encore partagée, dans tous les cas dans les actes, l'évidence que toutes les entreprises vont avoir un cœur de modèle tech. Ça, aujourd'hui, moi, je rencontre plein de DG ou autres, ou même des DSI, qui ne considèrent pas que la tech va faire partie du cœur de modèle. Des fois, ils vont dire : "Oui, il faut qu'on passe d'une fonction support à des partenaires." C'est déjà un premier point. Mais le côté de dire toutes les entreprises, même le côté menuisier, même le côté, n'importe quel type va avoir une révolution tech au cœur de son modèle, ça, ce n'est pas encore partagé. C'est comme si c'était encore un gap un peu plus loin. J'aimerais bien avoir un peu votre vision là-dessus. Voilà, à quel horizon ? Comment ça peut se passer ?
MG : En fait, ça se passe depuis toujours. C'est juste qu'on n'osait pas le dire de cette manière-là. Depuis toujours, les personnes de la supply chain s'outillent d'outils informatiques pour faire leur boulot, mais ça fait quand même très longtemps qu'on ne remplit pas un entrepôt avec un carnet et un crayon pour savoir où on a mis les trucs. Donc, je pense que de plus en plus, ce qui arrive, c'est qu'on se substitue à des gestes métier de manière de plus en plus technologique. En supply chain, c'est très vrai. On bosse sur beaucoup, beaucoup de choses avec de l'IA pour automatiser des commandes, pour automatiser du forecasting, pour faire de la prévision sur les surfaces d'entrepôts, pour la prévision de ruptures, la prévision de saisonnalité, etc. On fait de la prévision de partout et ça aide le métier de plus en plus, mais ça l'aide, j'ai envie de dire, c'est aussi parce que c'est de moins en moins gérable humainement. Il y a quelques temps, on avait 30 000 références à vendre dans nos magasins, ce qui était déjà beaucoup pour un magasin. Ben, maintenant, on en a plus de 500 000, et ça va continuer. Donc à ce niveau-là, ce n'est plus gérable sans une assistance artificielle ou digitale. Donc, je pense que le métier se rend compte que ça lui fait gagner... Est-ce que derrière, on se dit "finalement, c'est la tech qui fait mon métier" ? Je ne pense pas qu'ils vont jusque-là, parce que personne ne va vouloir se dire qu'à un moment, je ne sers plus à rien, c'est un ordinateur qui pense mieux que moi. En plus, je pense que ce n'est pas vrai, parce que même les modèles ML, etc, des fois, ils racontent un petit peu n'importe quoi. Il faut toujours les mettre à la lumière du métier, de l'objectif d'expérience utilisateur que l'on veut avoir. Donc, le métier a toujours une nouvelle forme de travail avec la tech, mais c'est indéniable que la tech est là pour un bon moment, pour les aider à progresser, à prendre des décisions et à scaler, tout simplement. Donc, pour moi... Est-ce que demain, par contre, on va tous se trouver éditeurs à vendre des solutions tech ? Ça, ce n'est pas certain.
BR : Non, mais par contre, la tech fera partie de votre quotidien, parce que pour mieux faire son travail, pour le faire dans de bonnes conditions, etc.
MG : Mais aujourd'hui, c'est le cas depuis un bon moment, vous enlevez la tech d'un magasin, il ferme les portes. C'est aussi simple que ça. Aujourd'hui, avec le flux de clients qui passent dans nos magasins, ce n'est pas avec un pinpad qu'on pourra s'en sortir. Donc, ouais, c'est évident que la tech est partout et elle traverse les murs du magasin. Le magasin est juste une entité de connexion avec le client, mais il y a énormément de choses qui se passent online avant. Et voilà, donc il y a vraiment de la tech partout dans le parcours.
BR : OK. Et sur le framework make or buy, qu'est-ce que c'est ? Comment il fonctionne ? Comment vous résistez à la façon de ne pas faire, du coup ?
MG : Oh, il y a plein de composantes. Je ne les ai pas toutes en tête, mais on a essayé de le simplifier. Quelques points cruciaux : 1, la propriété des data. Qu'est-ce qui va se passer avec les data si on utilise un Saas ? C'est la première question qu'on se pose.
BR : Donc, Ok, vous voulez être propriétaire, la capacité de l'utiliser de manière anonyme...
MG : C'est tout ça. C'est évidemment propriétaire, évidemment pas d'usage annexe, réversibilité, anonymat, sécurité... La data, c'est le premier truc. Le second, c'est : qu'est-ce qui justifie qu'on n'utilise pas le SaaS ? "Montre-moi les processus métier, tes idées et tes innovations qui ne sont pas couvertes par le SaaS." Et pour moi, on doit développer quand on est arrivé au bout d'une solution du marché, quand elle est limitante par rapport à une innovation métier business qu'on veut avoir. Et voilà, moi, j'en ai fait l'expérience sur les plateformes Web. Je crois qu'on a testé au moins trois frameworks connus de plateformes Web et je crois qu'on a fini par les tordre dans tous les sens parce que notre métier est vraiment très différent. Ce qu'on vend, ce ne sont pas des fringues, ce ne sont pas quelques SKU avec des variantes de taille. Je ne dis pas que c'est facile de vendre des fringues, ils ont chacun leurs problématiques. Mais nous, on vend aussi bien des cuisines que des vis et des boulons, que des fenêtres sur mesure, que de la chaine au mètre linéaire, que les coupes de bois au mètre carré. Voilà, donc il y a des trucs dans tous les sens et on n'a jamais réussi à trouver un framework d'e-commerce qui savait prendre ça. Vous cumulez à ça un vendeur qui prend la main sur votre panier, donc avoir des systèmes où les paniers sont multipropriétaires. Ben, il n'y a aucun système e-commerce aujourd'hui qui fait ça, parce que ça n'a pas été designé pour ça. Donc, du coup, on les customise dans tous les sens, ce qui fait qu'à la fin on dit : OK, à force de customiser, on va le faire." Et c'est comme ça qu'on en est arrivé à faire nos front-end, toutes nos techno de micro front-end, de tunnel. Mais il y a d'autres outils... On bosse sur la market place. Aujourd'hui, quand on regarde ce qu'on fait, Mirakl, ça nous va. On n'a pas encore d'idée, j'ai envie de dire, et de blocage, peut-être que ça viendra, avec cet outil-là, parce que ben voilà, on l'a lancé il y a un peu plus d'un an au Brésil, et pour l'instant, pour ce qu'on en fait, ça nous va. On a d'autres chats à fouetter. Mais je ne doute pas qu'un jour, c'est ouvert, on a déjà eu la discussion plusieurs fois avec Mirakl, mais le principe est toujours le même. Si on est limité, on va aller au plus vite. On bosse beaucoup, par exemple, avec Google, évidemment, avec GCP, on fait plein de trucs. Mais récemment, il y avait une de leurs API, nos data scientists en ont fait une meilleures, du coup, on a arrêté de l'utiliser. Mais sur d'autres sujets, ils nous font des super API qui marchent super bien et on n'a aucune envie de les refaire. Donc, c'est presque du cas par cas, mais c'est sur ces deux trucs-là : est-ce que mes data vont enrichir d'autres personnes que moi ? Est-ce que j'en ai toujours le contrôle total ? Et est-ce que j'ai un process métier qui vaut le coup de faire un custom ? Grosso modo, c'est à peu près ça.
BR : OK. Et aujourd'hui, la direction générale, elle n'a pas une vision purement financière, du coup, des coûts de l'IT, mais elle comprend l'impact de l'IT sur la valeur métier, la valeur commerciale. Est-ce que c'est parce que c'est historique, culturellement parlant ? Ou est-ce que ça a été un processus qui s'est mis en place, parce que les expériences ont fait que ?
MG : Ça s'est construit au fil du temps. Ça s'est construit sur des douleurs, souvent. C'est-à-dire quand il n'y a plus de système d'information, comme quand je suis allé en 2011 au Brésil, et qu'il n'y a plus rien qui marche, tout de suite, on voit la valeur du système d'info, parce qu'il y a les magasins fermés et on compte la perte de chiffre d'affaires à la minute. Donc là, forcément, ça valorise très vite l'intérêt d'avoir un système stable. Et j'ai envie de dire, ça a été comme ça, ça s'est construit. Ce qui a été un peu plus difficile, c'est la compréhension des cycles agiles et des cycles budgétaires par rapport à l'agilité. Ça, c'est toujours un peu compliqué, parce que donner une enveloppe à une team sans travailler forcément un ROI. Parce qu'avant, les projets, on travaillait des gros ROI. On disait : "Voilà, je vais faire tel gros projet de transport management, ça va me prendre un an, ça va me faire tel ROI, je verrai ça dans 18 mois quand j'aurai fini le projet." C'était des cycles très longs. Forcément, quand on transforme la boite en orientation product management, l'organisation financière doit aller avec. Donc on doit donner une enveloppe de développement à un team qui va décider de ce qu'il veut faire. Mais donc, forcément, on les laisse maître de développer les features à la vitesse qu'ils veulent, dans la priorisation qu'ils veulent. Ce qui enlève un peu le côté ROI global, dont on avait l'habitude dans des trucs type comité d'investissement, etc. Tout ça, ça a pas mal changé. Et puis, là, on a eu une grand aide. Le Covid, ça a entériné définitivement, j'ai envie de dire, la nécessité de la démonstration de valeur des systèmes d'info, puisque là, on a eu une explosion du Web. On a eu une explosion des nécessités de delivery parce que nos magasins étaient fermés. Donc on était déjà de toute façon dans un trend transformationnel, j'ai envie de dire, mais voilà, c'est juste un catalyseur énorme qui nous a permis de d'enfoncer le clou sur plein d'autres aspects, qui étaient déjà dans les cartons, mais qu'on prenait peut-être un peu trop le temps de faire parce que concurrence de priorités. Et là, vous fermez tous les magasins, forcément, la supply chain, le delivery, le B2C du Web a droit à un beau coup d'accélérateur, et on s'en est bien sorti. Donc aujourd'hui, il n'y a vraiment plus de sujet sur il faut valoriser ce qu'on fait. Notre sujet, et je pense que c'est le sujet de tout le monde digital aujourd'hui, c'est les talents, c’est l'acquisition de talents. Il ne reste plus que ça comme guerre qui. Enfin, je pense que ça a toujours été la mère des guerres, mais ça restera celle-là la plus difficile. Comment trouver des bons ? Comment expliquer le projet ? Comment favoriser leur intégration ? Comment faire en sorte qu'on soit tous vite effectifs, fonctionnels ? Ça, c'est très difficile. Et pour le coup, on se bat avec tout le monde. Parce qu'un bon data scientist, un bon développeur, il peut bosser chez Google, chez nous, chez n'importe quelle boite, tout simplement. Donc ça, c'est là le vrai défi.
BR : Le quasiment n'importe où. Avant de revenir sur les talents, qui est super intéressant, et juste pour être sûr de comprendre au niveau de "on ne fait plus des projets, on fait des produits" et la façon dont on dit "ce ne sont plus des budgets par projet, ce sont des budgets par team, et c'est elle qui priorise les projets par rapport aux objectifs qu'elles ont", l'entreprise a des objectifs, elle donne les objectifs à des équipes ou les équipes proposent des objectifs par rapport à ce qu'elles voient sur le terrain, et on va donner des budgets à chacune de ces équipes-là qui, elles, vont prioriser les projets qu'elles veulent exécuter. OK, sur cette partie-là, je comprends. Juste la partie, la nuance, c'est la différence entre les coûts de CAPEX et d'OPEX qui sont que comment, en fait, dans une multiplication de projets, et les OPEX pouvant augmenter de plus en plus, comment l'équipe arrive à se projeter sur une équation financière un peu plus long terme en se disant "si je fais tous ces projets-là, les coûts d'OPEX, je pourrai les..." Parce que le budget, est-ce que c'est un budget CAPEX-OPEX sur l'ensemble des projets ? Sur quel horizon de temps ? Voilà, comment on gère ce point ?
MG : Alors déjà, on ne fait pratiquement plus que de l'OPEX, parce que, de toute façon, le trend du monde digital, qu'on utilise des services managés, qu'on utilise de la conso, etc, c'est de l'OPEX, donc ça devient très compliqué de mixer du CAPEX et de l'OPEX. Donc on est beaucoup sur de l'OPEX. Nos dev, c'est de l'OPEX, etc. Donc ce n'est plus très facile de gérer des CAPEX avec une vision long terme quand on a des cycles agiles. Donc nous, on a pris l'idée de fonctionner par OKR. Donc on a des OKR globaux, qui donnent un peu des guidelines générales sur ce qu'on cherche à atteindre d'un point de vue résultat client final. Ensuite, ça tombe, j'ai envie de dire, sur chacune des plateformes. Elle décline, un produit, un produit. Donc moi, dans le produit de publication ou dans le tunnel de commandes, à quel OKR je réponds ? Et qu'est-ce que je vais faire pour contribuer à cette OKR-là ? Et eux-mêmes font des OKR par domaine, puis par produit. Revus de manière trimestrielle. Et derrière, en fait, on a des enveloppes, pareil, donc on a une enveloppe globale annuelle pour une plateforme, qui va la distribuer comme bon lui semble sur ses domaines et sur ses produits. Donc, si on a un produit qui a 7 dev, mais qui, à la fin, n'avance pas dans ses OKR ou n'a plus suffisamment d'idées, son budget va être de plus en plus réduit, au point où ses dev iront faire du dev ailleurs, dans un autre produit, parce qu'il n'y a plus que de la maintenance et qu'il n'y a besoin que de quelques dev et qu'il ne soit pas dans une phase de croissance forte de son produit. Mais l'idée, c'est de fonctionner sur enveloppe fixe. Et moi, je cape l'investissement général, d'Adeo dans le digital, par rapport à la croissance de l'entreprise.
BR : Ok. Et alors, deux choses pour être sûr de comprendre. Donc OK, que de l'OPEX. Et quand je fais un projet, que j'utilise des services externes, cet OPEX-là peut durer des années comme un an. Comment vous visualisez le fait que le montant, il va être en continu d'année en année ? "Je vous ai donné à 200 000 pour ces cinq projets-là." Mais en fait, c'est 200 000 euros d'OPEX, mais en fait, l'OPEX jusqu'à quand, quoi ?
MG : En fait, nous, les produits, déjà, font le build et le run. Donc jusqu'à quand ? Je dirais jusqu'à ce que mort s'ensuive.
BR : OK, donc chaque budget, ce sont des OPEX qui s'accumulent.
MG : Oui, ben, de toute façon, on considère que... Ce ne sont pas des projets, donc ils n'ont pas de fin. Ce sont des produits. Un produit que je mets pour faire un master data client, ce n'est pas parce que je fais un produit et que... Il ne va jamais vraiment être fini. Il va peut-être avoir moins de dev, mais il ne sera jamais fini. Donc il y aura toujours besoin de maintenance. Comme l'équipe qui le construit et celle qui le run, peut-être qu'à un moment, je ne sais pas, dans 5 ans, elles vont me dire : "Écoute, en fait, cette techno, maintenant, elle commence à être limitante. On veut la changer." Ben écoute, change-la. Et en fait, ce qui se passe, c'est que, comme on définit dans chaque cycle agile une partie pour la maintenance, une partie pour la qualité de code, etc, du temps de l'équipe, certaines équipes décident de flinguer leur propre produit ou de le restructurer avec d'autres codes. Il y en a qui changent de framework de front, etc. Ils font ça sur leur temps et leur budget de produit. C'est eux qui décident ensemble, en fait, quand à un moment le produit doit bouger. Moi, je voulais vraiment essayer de sortir du cycle dent de scie, en fait, parce que j'ai trop vu des projets type gros ERP. Donc on fait un méga investissement CAPEX avec plein de build pendant 2 ou 3 ans, puis après le truc se met en mode run. Sauf qu'en fait, c'est un faux run. C'est un run dans lequel on fait plein de customisation, tout ça. On n'est plus du tout en projet, donc c'est un peu en shadow. Et puis on se réveille 5 ans, 10 ans après, avec un truc qui est full customisé, qui pète de partout. Et là, on se dit : "Ah ben ça y est, il faut que je refasse un méga gros projet." Ouais, mais en fait, on fait des avancées en dents de scie, on n'est pas du tout agile, et en plus, on prend des risques énormes sur la vision de ce que ce produit pourrait faire pour nous dans les 10 prochaines années. Je pense qu'on n'est plus dans ces modes-là, on n'est plus dans ces systèmes-là. Et sur les SaaS, c'est pareil. On prend des SaaS à contrat relativement court, comme ça on sait que si on veut continuer, on peut continuer, si on veut s'arrêter, on s'arrête.
BR : OK, très clair. Et donc du coup, après, c'était sur la partie produit et ensuite réallocation. Donc les personnes sont responsables de leur produit et, en fonction de ce qu'il y a, peuvent changer de produit. Est-ce qu'ils peuvent changer aussi d'équipe ?
MG : Ça, ça se gère, évidemment. On fait des reviews annuelles, on travaille les parcours des collab'. S'il y a un collab' qui veut... Ce n'est pas freestyle, on ne va pas dépoiler une équipe parce que les mecs n'ont plus envie de bosser sur ce produit-là. Mais évidemment qu'on crée des parcours pour les développeurs, pour les data scientists. S'il y a un mec qui a envie de passer du costumer à la supply, il peut, évidemment, ça se travaille.
BR : Et avant d'arriver au talent, le dernier point, c'était la partie sur le coût total de l'IT. C'est lié au chiffre d'affaires de l'entreprise. En gros, la dépense totale a certains indicateurs. J'imagine qu'avec la taille de l'entreprise, la croissance, etc, ça ne doit pas être facilement benchmarkable en disant : "Attends, on ressemble à eux, ils utilisent tel..." Comment vous arrivez à définir, avec le comité de direction, le bon indicateur de dépenses IT ?
MG : C'est une très bonne question. Moi, pendant très longtemps, je me suis battu contre l'indicateur du pourcentage de chiffre d'affaires, parce qu'en fait, on avait énormément de boites, de cabinets de consulting qui nous disaient "dans le retail, il faut que ce soit 1,5 du chiffre d'affaires". En fait, c'est super dangereux, ce truc-là. Moi, je peux faire un IT à 1,5. Je ne fais plus aucun dev, je serre tout, et pendant 3 ans, je tiens à 1,5. Mais à la fin, ça va nous péter à la figure. Et puis, c'est tout ce qui va arriver. Est-ce qu'après, c'est 5 % ? Ben non, je pense que ça commence à faire vraiment gros. Donc, c'est une discussion, c'est vraiment une discussion. Il n'y a pas de bons chiffres, à mon sens. Quelles ambitions on a ? Quelle conscience on a de ce partenariat avec le business ? Parce que c'est pareil, ça ne sert à rien d'enquiller des stars de développement si en face, il n'y a pas de métiers et que les mecs, ils n'ont pas d'idée business. Ils vont vite se tourner les pouces et les stars du dev vont se barrer. Donc c'est vraiment une adéquation. Et moi, je vois ça comme une réallocation. J'ai une enveloppe globale. Je vois que ça performe. Si jamais ça performe très bien et qu'on délivre encore mieux, je n'aurais pas de souci à aller demander plus d'argent, et je crois qu'on n'aura pas de souci à m'en donner. Tant que ça délivre. Le grand problème, c'est si ça ne délivre par. Je veux dire, nos general managers vivent dans la même société que nous. Ils comprennent bien qu'il y a des choses qu'on peut faire et qu'on ne peut pas faire. Je n'aurai évidemment jamais le budget d'Amazon, mais ils le savent, ils n'attendent pas non plus que je fasse exactement comme Amazon. Donc ils sont conscients de ça. On a vraiment fait tout un travail depuis pas mal d'années sur la conscientisation de la valeur tech, aussi bien dans notre capacité à le construire, de ce qu'elle peut créer comme valeur. Ce qui fait qu'aujourd'hui, je n'ai pas de problème d'investissement. On fait attention, parce qu'on est tous actionnaires de notre boite, donc on a vraiment envie de faire attention à ce qu'on fait. Mais voilà, ce n'est pas tellement le sujet, j'ai envie de dire.
BR : OK. Non, mais en gros, vous avez réussi à sortir de la discussion, peut-être un peu stérile mais classique, d'un chiffre magique. C'est plus une discussion constante par rapport à l'ambition, à ce que vous délivrez, à ce que vous sentez les besoins.
MG : Oui, en fait, c'est une chance, mais nos dirigeants s'intéressent à notre métier digital et IT. Donc comme ils s'intéressent, derrière, ils regardent... En fait, la comparaison n'est pas sur un KPI IT, enfin pourcentage de chiffre d'affaires, elle est sur ce que font les concurrents et ce que tu fais, toi. Moi, l'expérience client que j'ai... Aujourd'hui, ils me challengent sur l'expérience client d'Amazon en delivery, quoi.
BR : Ça va être chaud.
MG : Ben ouais, mais en fait, en vérité, je suis content qu'on parle de ça, parce que la vraie vie, elle est là. Au final, le client, il s'en fout de combien j'ai de budget. Ce qui compte, c'est que quand il commande un tournevis ou quand il commande une tondeuse, il l'a chez lui, soit le lendemain, soit en quelques jours, et c'est tout. Et donc moi, mon job, c'est de faire en sorte d'être compétitif avec ça. Donc, évidemment, notre stratégie, ce n'est pas d'être meilleur qu'Amazon sur ce point-là. Je pense qu'il y a plein d'autres points où on peut être meilleur qu'eux, mais sur ce point de supply chain, c'est d'être ni plus cher, ni plus long.
BR : OK. Et alors, vous avez parlé des stars dev. C'est pas mal. Et du coup, c'est le pain, ou en tout cas un des enjeux de la transformation, c'est le faire avec les bonnes personnes, dans de bonnes conditions. Comment on les recrute, ces stars ? Comment on les garde ? Et comment on est sexy par rapport peut-être à des nouvelles marques, des nouvelles sociétés, qui peuvent représenter peut être quelque chose de plus, à la base, moderne, différent, adapté ?
MG : Oui, c'est le vrai challenge. C'est un vrai challenge, parce que... Il y a plusieurs aspects. Déjà, effectivement, il y a le côté hype à bosser dans des start-up. Ça, je peux le comprendre. J'ai bossé dans une start-up aussi, ASF, dans les années 2000. On faisait des sites Web, du e-commerce, tout au début de la bulle, c'était canon. Je pense que c'est un parcours, quand on est jeune diplômé ou même autodidacte, qui est super intéressant parce qu'il y a une énergie, on ne se prend pas la tête, il n'y a pas de freins, on peut tester plein de trucs, c'est cool. C'est souvent après... Je pense que ce ne sont pas les mêmes dimensions, en fait. À un moment, dans sa vie, soit on commence à regarder le sens de l'entreprise, c'est-à-dire ce qu'elle offre comme valeurs, comme sens pour la société, ce qu'elle peut fournir comme services, comment elle traite plein d'aspects : les carrières, les gens, l'environnement... tout ce qui représente son set de valeurs. Et de plus en plus, on voit pas mal de mecs qui étaient dans des start-up ou des grands groupes digitaux qui en sortent un peu en disant : "OK, c'est bien, j'ai bossé comme un iench pendant des années, c'est super bien, mais au final, je ne me retrouve plus dans les valeurs." Parce qu'il y a un peu ce côté tu es essoré pendant le temps que tu passes chez eux, et dès que c'est fini, on ne te considère plus. Nous, on cherche aussi à avoir des gens un peu fidèles, avec des valeurs. Je n'ai pas besoin de construire une fusée SpaceX, donc je n'ai pas non plus besoin d'avoir les meilleurs du monde absolu. J'ai besoin d'avoir des gens très bons, qui s'éclatent, mais qui ont surtout envie de bosser avec d'autre mecs sympa. À la base, je regarde avant tout ça, moi, d'avoir un esprit d'équipe, des mecs sympa, des mecs qui s'éclatent, pour finalement une marque qui est reconnue. On a été a été la marque préférée des Français cette année pour la première fois. Donc on est super fiers. Mais voilà, il y a un terrain de jeu international sympa. Il y a des problématiques sympa à développer. On a de la bonne tech. Et c'est vrai qu'on ne met peut-être pas suffisamment en avant nos techno, ce qu'on fait en team de dev, l'environnement. C'est pour ça aussi que je parle avec toi aujourd'hui. Tu as plein d'acteurs historiques et on est un peu tous mis dans le même sac. Les acteurs historiques versus les start-up. Moi, ça me fait un peu rigoler ça, parce qu'on fait plein de trucs qui sont finalement dans les mêmes stack techno que plein de start-up et à une échelle de complexité qui est largement supérieure que plein de start-up. Aujourd'hui, à titre d'exemple, j'étais en train de regarder ce matin, on fait 1 500 mises en prod/jour, globalement, sur les produits. Donc c'est pas mal.
BR : Ça commence à faire, oui.
MG : Ça commence à faire. On est un des plus gros clients ***EGCP*** (48:45) en France, un des plus gros clients MongoDB, un des plus grands clients ***Kafka***. Donc, on fait plein de trucs sur des techno sympa. Donc l'idée, demain, c'est peut-être de faire mieux comprendre ça. Et oui, on a créé une équipe de développeurs expérience, et même de communication corporate sur la partie digitale. Mais spécifiquement pour les dev et les tech, on a carrément une équipe qui s'occupe d'eux, sur tout. C'est-à-dire non seulement on vous écoute sur comment vous bosser, sur ce qu'il faut changer dans les outils, sur les plateformes communes de dev. On a quand même pas mal d'exceptions aux règles qui sont dédiées à la communauté tech, parce que, évidemment, aujourd'hui, elle a le vent en poupe et elle peut se permettre d'avoir des exceptions.
BR : Bon, ben, j'espère que vous avez kiffé ce podcast. Comme toujours, n'hésitez pas à le partager sur LinkedIn, à le partager à vos collègues, chefs de projets IT, DSI. Ça nous aide toujours à trouver de nouveaux DSI, et toujours plus intéressants. Et écoutez, ciao !
