- Speaker #0
Bonjour, bienvenue sur ce nouvel épisode de DinoSapiens, le podcast qui parle de l'humain dans la transformation des organisations. Je suis Bérangère Ducimetière et je vous emmène à chaque épisode à la découverte de personnalités qui façonnent et modèlent les transformations des entreprises et ce dans le respect de l'humain. Je reçois aujourd'hui Rémi Pougeot avec qui j'ai eu le plaisir de travailler lors d'une expérience passée. Et c'est lui qui m'a fait découvrir l'architecture d'entreprise dont il va nous parler aujourd'hui. Rémi est un précurseur de l'architecture d'entreprise pour les systèmes d'information, vente et marketing. Il a débuté sa carrière dans un groupe international français du CAC 40 et a commencé au Japon avec une double casquette, celle du support produit pour des automatismes industriels, notamment des lignes de production robotisées, et aussi une casquette d'interface France-Japon pour le développement d'un ordinateur industriel. De retour en France, Il travaille en R&D sur des systèmes extrêmement complexes, dans des équipes pluridisciplinaires et internationales. Comprenant rapidement l'importance de dénouer les situations humaines pour faire avancer les projets, il a évolué rapidement vers un rôle de leader d'intégration. Il revient ensuite au Japon pour déployer SAP à l'ensemble des filiales et joint ventures de son groupe et découvre à ce moment-là l'importance de la relation avec les utilisateurs, que ce soit les clients ou les employés. et aussi l'importance d'être présent sur le terrain, le Gemba en ligne, afin de rester dans le concret de l'IT et de son utilisation. Au début des années 2010, Rémi retourne à Paris au moment du déploiement du CRM Salesforce pour son groupe. Il s'agit d'un déploiement mondial du même outil pour toutes les forces de vente de chacun des pays, de chacune des business units, pour chacune des offres, qu'elles soient une offre produit ou une offre solution. On comprend bien que dans cette aventure, au-delà de la... Technologique et nouvelle, la principale difficulté du programme réside dans l'alignement d'une myriade de parties prenantes autour d'un processus qui devra être le plus commun possible, tout en respectant au maximum les spécificités de chacun. Fort de ses expériences d'intégration, Rémi va alors imaginer une architecture inédite pour conjuguer à la fois la rationalisation des pratiques des vendeurs et la souplesse exigée par les affaires. Son objectif ? permettre de dépasser les clivages entre les personnes et les silos grâce à l'architecture de la solution dont il s'apprête à diriger le développement et la partie innovation. Après un enchaînement de programmes souvent pluriannuels dans l'écosystème de l'expérience client de la multinationale française, allant des ventes, au support, au marketing digital, Rémi rejoint le BCG pour faire bénéficier le groupe de son savoir-faire sur l'innovation. Il rallie ensuite Audaceva, une scale-up de l'environnement Salesforce, en tant que responsable innovation produit. Et finalement, il décide de cofonder Pelago, une start-up tech dont la solution reflète en même temps les concepts d'architecture du système d'information et les principes de gouvernance pertinents pour les organisations complexes d'aujourd'hui. En quoi l'architecture IT, appelée aussi urbanisation des systèmes d'information, est-elle une clé des grandes transformations ? En quoi savoir, écouter et comprendre le métier, le business, est incontournable pour cette fonction d'architecture ? C'est ce que Rémi va nous expliquer aujourd'hui. Bonjour Rémi, je suis très heureuse de te retrouver aujourd'hui sur mon podcast pour parler architecture d'entreprise.
- Speaker #1
Bonjour Bérangère.
- Speaker #0
Est-ce que tu peux nous expliquer ce qu'est l'architecture des systèmes d'information et quel est son rôle dans les organisations ?
- Speaker #1
Alors l'architecture des systèmes d'information, je vais la comparer à l'urbanisme. En français, l'architecture d'entreprise s'appelle l'urbanisme du système d'information. Donc si on compare le système à une ville, la ville a un plan d'urbanisme. globale, de savoir quel quartier je vais développer, quelle route je vais construire, est-ce que je vais construire des quartiers d'habitation, des centres commerciaux, donc la planification globale de ma ville. Une fois que j'ai cette planification globale, je vais construire des bâtiments. Donc chaque bâtiment va avoir une architecture propre, cohérente avec le reste de la ville. Et donc là, on a des architectures de niveau solution et aussi je vais construire mes routes et là, on a l'architecture de l'intégration. Et dans chaque bâtiment, je vais faire un câblage électrique, je vais faire ma plomberie. Donc là, on a l'architecture technique de l'informatique. Donc, on a vraiment ce parallèle des niveaux d'architecture, de l'architecture de la ville, l'architecture de l'entreprise, à l'architecture technique et de l'électricité.
- Speaker #0
Et comment est-ce qu'on gère l'architecture d'entreprise ?
- Speaker #1
Il y a deux grandes approches possibles. La première, c'est de faire une carte, une cartographie exhaustive de l'entreprise, de tous ses systèmes. et aller même savoir dans quelle salle on a quel serveur. À la fin, on a une belle carte qui peut être assez utile, mais aussi assez inutile parce qu'on a passé beaucoup de temps à cartographier. La deuxième approche, qui est mon approche préférée, c'est de comprendre les priorités de l'entreprise et de savoir sur quels éléments de la carte on va se concentrer et sur quelle partie de la ville, pour reprendre le parallèle, on va faire des plans précis et aller en profondeur jusqu'à la couche technologique pour être sûr que l'architecture... servent les ambitions de l'entreprise.
- Speaker #0
Pourquoi l'architecture est-elle l'une des fondations de la transformation digitale dans les organisations ?
- Speaker #1
Je dirais que dans une transformation non digitale, il n'y a pas de système, donc finalement c'est gérer des gens ou gérer des usines. Dans une transformation digitale, on rajoute une dimension qui est la dimension technologique et il n'est pas possible de penser une transformation digitale sans savoir comment elle va être exécutée en termes de technologie ou en termes de système. Donc on doit avoir un plan qui va prendre en compte. des deux aspects, la roadmap business et la roadmap IT qui doit être mise en cohérence. Si la roadmap est purement tirée par des contraintes de business, alors à ce moment-là, ça ne va pas suivre, on va dire l'IT est en retard. Et si la roadmap est tirée uniquement par des contraintes IT, on ne va finalement pas servir les priorités du business. Donc, ces deux aspects sont fondamentaux et l'architecture, en partant de l'architecture business, assure cette cohérence entre les deux.
- Speaker #0
Et alors, quel est le rapport avec la gouvernance ?
- Speaker #1
Le rapport avec la gouvernance, c'est que la gouvernance c'est définir son... ce qu'on fait et vérifier qu'on fait ce qu'on a dit qu'on ferait. Donc l'architecture aide à la fois à définir ce qu'on va faire et à vérifier qu'on est bien dans les clous et à identifier des points chauds, par exemple, en disant on veut faire ça, mais là j'ai un point chaud, j'ai une incohérence ou je n'ai pas une bonne priorisation de mes activités par rapport à ma roadmap.
- Speaker #0
Et alors concrètement, comment ça marche ? À quel moment faut-il faire intervenir l'architecte d'entreprise lorsqu'on se lance dans une transformation ?
- Speaker #1
Alors, il y a une erreur qui est... de le faire intervenir trop tard, pour moi, ça va être en continu. On est en projet où on fait évoluer de manière continue ce qu'on fait. Je dirais, pour prendre une approche agile at scale, ça fait un peu peur, mais en fait, le principe est très simple. Agile at scale, c'est d'aligner tout le monde, d'avoir des équipes qui sont autonomes, mais alignées, alignées sur leur objectif et alignées dans le temps. Donc, tous les trois mois, on va faire ce qu'on appelle un programme incrément où on va définir ce qu'on fait dans les trois mois qui suivent de manière cohérente entre toutes mes équipes. Et donc là, l'architecte... va aider à structurer ça et à regarder les impacts de ce qu'on fait dans les trois mois qui suivent sur les systèmes existants ou à identifier les nouveaux systèmes à développer. Donc, un architecte intervient au début du PI planning et en continue pour être sûr que ce qui est fait correspond bien à ce qui était prévu ou que si ce qui était prévu n'était pas ce qu'il fallait, alors il est au courant. Une image que je prends, c'est que si on prend des bateaux du 18ème siècle, donc d'avant la révolution, on a tous les plans très précis de ces bateaux, à tel point qu'on sait reconstruire un bateau comme l'Hermione à l'identique des plans. Et on trouve des épaves de bateaux. Et ces épaves ne correspondent pas aux plans, parce que les gens n'ont pas construit en fonction du plan, parce qu'ils savaient mieux que les architectes. Ce qui est bien, mais ce qui est un peu triste, il a manqué cette boucle de feedback des constructeurs vers les architectes. Et donc pour moi, le rêve, c'est que ... l'architecte soit en permanence dans le projet pour regarder, pour vérifier que ce qu'il a défini marche ou pas et avoir du feedback de la réalité. Et en parallèle, pour avoir une stratégie complète, il faut en parallèle de cette équipe de PI Planning avoir une équipe d'innovation qui est très proche de l'architecture, qui n'est pas directement liée au delivery, au projet, qui va permettre d'anticiper, de tester des choses sans impacter le planning du reste. Et pour moi, c'est aussi un des rôles de l'architecture de fédérer cette innovation.
- Speaker #0
Alors pour que ça fonctionne et pour que la sauce prenne bien, quel type de leadership tu penses puisse être le plus efficace pour la transformation digitale ?
- Speaker #1
Alors j'ai vu beaucoup de combinaisons. Un qui a bien marché, c'est quelqu'un qui vient du business et qui prend un rôle IT. J'ai vu quelqu'un qui était directeur des ventes et qui a pris la direction du programme de mise en place d'un ERP. L'inverse aussi, quelqu'un qui venait plutôt de l'IT et qui a pris un rôle business. et ces gens là sont très rares et ça prend des années donc la combinaison la meilleure pour moi c'est d'avoir ce qu'on appelle le power couple c'est à dire deux personnes, un qui représente le business et qui représente la éthique, qui sont au niveau d'autorité égale et qui travaillent ensemble sur le sujet pour moi c'est le meilleur montage et chacun doit comprendre les contraintes de l'autre, c'est à dire on respecte je suis le business, je respecte les contraintes de l'informatique, je suis l'informatique, je respecte les contraintes du business et c'est un dialogue constructif qui se... qui s'établit au lieu d'avoir une bataille entre les deux.
- Speaker #0
Et donc, tu as dit que l'architecte devait avoir une connaissance technologique pour faciliter les arbitrages. Est-ce que tu as quelques exemples ?
- Speaker #1
Oui, on sait que pour chaque technologie, il y a les cas d'usage idéaux, les cas d'usage possibles et ce qui ne marche pas pour une technologie. Par exemple, si on choisit une base de données, il y a plusieurs technologies de bases de données, les bases de données relationnelles, graphes ou NoSQL. C'est très structurant pour la réussite du projet. Et souvent, mon expérience montre que ce n'est pas aussi simple que je choisis une technologie. Il faut combiner des technologies. Et c'est là que c'est l'achat de différents systèmes qui est super important. pour combiner le meilleur des mondes de chacune des technologies. Et on ne peut pas simplifier en disant « Allez, je mets SAP partout, je mets Salesforce partout. » La réalité est un peu plus compliquée, et le succès est dans les détails de ces choix technologiques.
- Speaker #0
En termes de méthodologie, qu'est-ce que tu recommandes ? Quel est le niveau de connaissance que l'architecte doit avoir sur différentes méthodologies de projets ? Et en quoi est-ce utile pour l'architecte de comprendre ces méthodologies ?
- Speaker #1
La méthodologie, c'est un peu comme la technologie qu'on a vue avant. Il y a des méthodologies qui ont un objectif. Pour moi, c'est très important que l'architecte comprenne les raisons d'être de chacune des méthodologies. Chaque méthodologie a une raison d'être qu'il comprenne dans les détails. Le Scrum ou autre, c'est moins important, mais il comprenne dans les détails pour qu'il aide à adapter la méthodologie au projet et qu'il comprenne à quel moment il doit intervenir. dans le projet. J'irais même plus loin, la manière dont on conçoit l'architecture est très liée à la méthodologie. Si j'ai un projet qui est très waterfall, le fait d'avoir un système dit monolithe... système, ce n'est pas très gênant. Par contre, si je veux être en méthode agile, il faut que mon système, mon architecture soit beaucoup plus modulaire, de manière que je sois orienté service et que je puisse faire évoluer les choses en parallèle avec des équipes qui travaillent en parallèle de manière agile. Et donc,
- Speaker #0
pour en venir à Pélago, la startup que tu viens de cofonder, l'application que vous construisez avec Vincent Delamare, quelle est votre ambition pour cette startup ?
- Speaker #1
Ce qu'on a vu dans les transformations numériques et ce qu'on a vu avant, c'est que l'alignement est un facteur clé. Alors quand on dit alignement, c'est l'alignement sur deux dimensions. L'alignement entre la stratégie business, la technologie, les systèmes, l'informatique et les projets, et les données aussi. Et l'alignement dans le temps, de vérifier que dans le temps, on n'a pas une dérive des choses qui soient trop tirées par le business, trop tirées par la technologie. Donc comment on assure cet alignement ? Par une carte partagée. Tout le monde a la même vision du monde. J'ai un angle business, un angle IT ou data et un angle projet de ma transformation numérique, mais tout le monde regarde la même carte. Cette carte va pouvoir détecter des incohérences. Simplement, il n'y a pas de cohérence entre ça et ça. Donc, donner des alertes et pousser la discussion pour l'alignement. Ça permet aussi de connecter les équipes, de savoir qui fait quoi.
- Speaker #0
L'application s'adresse à quel type d'entreprise ou de projet ?
- Speaker #1
L'application est conçue pour être très... ... pouvoir être implémenté d'une manière incrémentale. Donc, on commence petit. Ça peut commencer sur un sous-ensemble d'une transformation, sur une très grosse société, ou la transformation d'une ETI. Et ensuite, on peut progressivement croître. Par exemple, on peut démarrer sur le domaine RH. Et après, on voit, j'ai un projet d'acquisition de société. Donc là, j'ai plus d'autres domaines. Donc, on ne préhente pas la taille de la transformation. Ça peut être une... un sous-ensemble d'une grosse transformation ou une petite transformation. Mais je dirais que la valeur de l'outil, plus la solution... En gros, si la transformation tient dans la tête de quelqu'un et quelqu'un qui sait répondre à toutes les questions sur une transformation, l'outil ne fait pas beaucoup de valeur. Donc, je dirais, la valeur de l'outil est au carré de la taille de la société. Parce que c'est là qu'on a un volume de plus en plus gros et que c'est plus difficile de s'aligner. Plus c'est complexe, plus la valeur est importante.
- Speaker #0
Il y a un besoin de transparence. Est-ce que tu peux nous parler rapidement de ta philosophie sur la transparence dans un projet de transformation ?
- Speaker #1
La transparence, elle est importante. C'est-à-dire que si chacun cache la copie à chaque niveau, finalement la réalité, on ne sait plus où elle est. La transparence, ça ne veut pas forcément dire que tout le monde a le même niveau d'information, mais l'information nécessaire pour sa prise de décision. Je prends un exemple, si on veut avoir un projet qui est en rouge, mais le programme qui est en vert parce que finalement, le fait que le projet soit en rouge n'a pas un gros impact sur le programme. Mais la transparence, c'est comprendre ce que font les gens. Et dès qu'on met des murs, on complique la transformation digitale et on peut aller dans le mur rapidement. et on renforce les silos. Et après, moi je crois beaucoup à l'holocratie, donc il faut que... Il y a forcément des silos, on ne va pas mettre tout le monde, on ne va pas mettre 2000 personnes dans la salle et discuter. Donc forcément qu'on fasse des groupes, d'accord, en autonomie, et que ces groupes se connectent les uns aux autres, mais ces groupes ne correspondent pas à la hiérarchie de la société. C'est cette dimension qui est très importante pour moi.
- Speaker #0
Pour finir et pour conclure sur ce très riche échange, Rémi, j'aimerais que tu nous partages, comme chaque invité le fait sur Dinosapiens, quelques conseils pour bien gérer une transformation numérique tout en prenant soin de l'humain.
- Speaker #1
Pour moi, mon motto, c'est de dire qu'il faut de la technologie pour connecter les hommes et il faut des hommes pour connecter la technologie. La technologie, à la fin, elle ne pousse pas sur des arbres. C'est des hommes et des femmes qui le font. Donc cet aspect humain, il critique sur la transformation numérique. Et je dirais, en conséquence, il ne faut pas surestimer le rôle de la technologie, ce qui est un peu le technosolutionnisme, on va être de l'AI partout, on va tout régler les problèmes de réchauffement climatique. Et on ne peut pas sous-estimer la technologie en disant finalement tout est dans l'humain. Et c'est cet équilibre très fin entre technologie et humain qui est clé, et que les gens comprennent bien. les contraintes et les avantages, les forces et faiblesses de la technologie et de l'aspect humain. Et se poser la question, quand j'ai un problème, est-ce que c'est un problème technique ou un problème humain ? Est-ce que ma solution est technique ou humaine ? On peut résoudre un problème technique par de l'humain, mais le plus souvent, on a tendance à résoudre un problème humain par de la technique, ce qui n'est pas forcément une bonne idée.
- Speaker #0
conseil tu donnerais à un jeune qui débute sur le terrain de l'architecture ou des systèmes d'information de manière générale ?
- Speaker #1
Mon conseil, c'est de maîtriser, d'être vraiment spécialiste avant d'être généraliste, donc spécialiste d'à la fois une technologie et d'un métier. Quand je prends un exemple de Salesforce et du CRM ou de RP et la logistique ou de la supply chain ou d'un système de RH et des RH. Donc d'avoir cette double compétence technique et business sur un sujet très pointu. de manière à bien comprendre les interactions super complexes qu'on a entre le métier et l'IT sur le terrain, d'accord, et pas en théorie, et si possible, j'ai eu cette chance-là dans ma carrière de démarrer sur le terrain, dans le game bar, c'est-à-dire d'aller dans l'usine et voir comment les utilisateurs dans l'usine utilisaient le système et découvraient des choses, ils imprimaient des listings, ils les scannaient, ils les remettaient dans une autre base à côté, voilà, je me suis dit, bon, j'ai raté quelque chose, donc... commencer sur le terrain, sur quelque chose de très pointu. Ne commencez pas tout de suite à faire du management, de transfert numérique. C'est mon approche. Il peut y avoir deux approches, mais c'est mon approche.
- Speaker #0
Et enfin, un livre, une question que tu te poses.
- Speaker #1
Alors, il y a plein de bons livres business. Et là, je pense que tout le monde les connaît. Un qui m'a vraiment marqué, c'est un livre de Hartmann Rosa, qui est un sociologue, qui s'appelle « Alignation et accélération vers une théorie critique de la modernité tardive » . Le livre, j'ai du mal à le résumer, mais en gros, il dit La technologie évolue vite. Est-ce qu'il y a une limite humaine, physique, physiologique, sociologique, à cette évolution de la technologie ? Est-ce que c'est la technologie qui nous fait accélérer ? Est-ce qu'on va atteindre une limite ? Et l'exemple qu'il donne, c'est quand on a mis les premiers trains, les médecins ont dit, non, 60 km heure, c'est très mauvais pour le corps humain, ça ne supporte pas, on sait que non. Par contre, maintenant, quand on reçoit 1000 mails par jour, oui, on sait que notre cerveau... temps ne peut pas gérer ses mille mails, ce qui fait qu'on est en permanence en train d'essayer de remettre la technologie pour rattraper l'accélération que la technologie nous a donnée. Donc, c'est un peu philosophique. Et finalement, la question que ça pose derrière, c'est est-ce qu'on construit le monde dans lequel on a envie de vivre ? On voit plein de gens qui disent « je vais mettre des agents autonomes, des robots pour me faire mes cocktails » . Parce qu'on a vraiment envie que ce soit des robots qui nous fassent un cocktail. Donc, il faut se poser la question. Est-ce que cette transformation digitale, c'est vraiment le monde dans lequel je veux vivre ?
- Speaker #0
Un grand merci, Rémi, d'être venu sur Dinosapiens. Et je vais suivre de près l'aventure Pélago, avec de grands vœux de succès de ma part pour cette aventure entrepreneuriale.
- Speaker #1
Merci, Bérangère. Merci de m'avoir invité. Ça a été un plaisir.
- Speaker #0
Voilà pour aujourd'hui. Cet épisode de Dinosapiens est terminé. Grâce à Rémi Pougeot, j'ai mieux compris l'importance de l'architecture d'entreprise et la bonne posture pour faire le lien entre l'humain et la technologie. Sans architecte, la transformation numérique, c'est un peu comme l'Hermione sans gouvernail ou bien une crevette sans queue. Pour aller un peu plus loin sur le sujet, n'hésitez pas à visiter le site de Pélago. Je vous mets dans les notes du podcast le lien vers le site, ainsi que la référence du livre d'Artmunt Rosa, « Aliénation et accélération vers une théorie critique de la modernité tardive » . Vous pouvez écouter ce podcast sur votre plateforme préférée, Deezer, Spotify, Apple Podcasts, également sur Ausha et sur YouTube sur la chaîne Dino Sapiens. N'hésitez pas à noter le podcast et à en parler autour de vous pour lui donner de la visibilité. A très bientôt pour un nouvel épisode de Dino Sapiens et d'ici là, évitons l'extinction !
