Description

😱 Vis ma vie de DSI à la BPI ! Les défis de l'agilité maîtrisée et de l'autonomie métier !

🎙️ “ Si on avait fait des bouts je ne suis pas sûr qu'on serait arrivé au bout ! Là, on brûle les ponts ! “

Lionel Chaine est le Directeur des Systèmes d'Information de Bpifrance, au micro de CIO Révolution, il est revenu sur la réinvention de la banque en fintech et le déploiement d'une culture lean-agile avec SAFe “by the book”, complété par les OKR ! 

Bienvenue dans cet épisode passionnant ! Le 82e ✨ du podcast CIO Révolution by AirSaas , saison spéciale : L’agilité dans l’entreprise en 2023 en partenariat avec Valiantys - Atlassian Platinum Solution Partner.

🎙️ “ Je préfère le terme d’organisation « distribuée » à celui « d’agile », car ce mot est souvent utilisé à tort et à travers.  S’organiser en équipes autonomes est l’un des  moyens de gérer la complexité et l’incertitude.“

🎙️“On a 26 métiers ce fut 26 histoires différentes et 26 interlocuteurs à convaincre 26 fois !“

🎙️" Les COPIL où on se retrouve à quinze pour dire l'état d'avancement des sujets etc… on ne fait plus ça."

🟢 Aller vite et répondre en proximité pour devenir une fintech…avec un réseau physique 

Le lean-agile a été retenue comme modèle opérationnel cible (Target Operationing Model), notamment parce que la BPI travaille avec de nombreux partenaires qui sont des fintechs, en open innovation avec des enjeux de réactivité très forts. Un challenge déjà relevé quand il fallut monter le prêt garanti de l'état en très très peu de temps. 

🟢 Transformer le pilotage du budget IT

Le DSI a créé ce qu'il appelle des composants IT “socles” centraux et métiers. Hors socles centraux, le budget est ainsi réparti dans les métiers. Les  métiers décident de ce qu’ils vont en faire de leurs socles et gèrent leur enveloppe budgétaire… Sachant qu’à terme Ils ont  pu gérer …Et se rendre compte que ce n’était  pas gratuit ^^ !

Développer la frugagilité...avec une culture du MVP, ou Vital product !  la règle des 20 % d'énergie pour 80 % de la valeur. Mais ça a beaucoup plu aux métiers qui ont préféré avoir moins mais plus vite ! Avec a la clé une amélioration du taux de tenue d'engagement  

🟢 Brûler les ponts,  lancer « tout en même temps » et mesurer

Notre DSI souligne que toutes ces transformations ont été menées « en même temps ». Architecture, orga, Bascule cloud, CI/CD, tous les outils, l’architecture microservices, le traitement du Legacy, l’augmentation de la sécurité…la segmentation, la partie préparatoire autour du SOC et des outils de détections qui ont été tous revus…, les PO métiers, Program Manager ont été formés…Une tactique de déploiement SAFe « by the book first » avec beaucoup de formations.

🙍‍♂️ Pour favoriser l'innovation et la flexibilité de l’organisation, notre DSI a recherché  le (bon) équilibre entre l'agilité métier et la maîtrise de l'IT. En établissant des règles de gouvernance claires et en définissant les responsabilités vers une culture de collaboration agile maîtrisée ...à l'échelle !

Bpifrance aide les entrepreneurs, les entreprises, et leur DSI également 👍  !  

Bravo aux équipes de cette DSI réinventée et merci encore Lionel 🙌 pour ce (top!) retour d'expérience au micro de CIO Révolution, avec la communauté des #ProdeLaTransfo !  

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Transcription

• Speaker #0

  Et souvent la vie des auditeurs DSI, ils savent bien, c'est à la fois les projets, l'ambition, la stratégie, mais c'est aussi de façon très concrète la qualité de ce que vous délivrez à vos utilisateurs. Et on a deux pieds, donc si un de nos pieds lâche, la vie d'un DSI est souvent courte. Donc il faut vraiment être solide et sur le run opérationnel, donc l'ops, donc maintenant dans notre modèle, et à la fois le dev. Parce que si vous ne délivrez pas les produits dont l'entreprise a besoin, c'est pareil, vous êtes en difficulté.

• Speaker #1

  Bonjour à tous, moi c'est Bertrand Ruiz,

• Speaker #2

  le CEO d'Ersas,

• Speaker #1

  l'outil de gouvernance projet qui révolutionne la façon dont les directions peuvent prendre des décisions éclairées. Et je vous souhaite la bienvenue sur le podcast Serieux Révolution. Dans cette saison dédiée à l'agilité dans l'entreprise en 2023, en partenariat avec Valiantis, qui est partenaire Atlassian spécialisé Agile Scale, nous allons creuser à fond cette thématique. Une entreprise qui est agile, ça veut dire quoi ? Quel est le niveau d'investissement nécessaire du DG ? Comment mettre en place une démarche agile dans une ETI, dans une collectivité ? Comment gérer les budgets quand on fait de l'agile ? Quel est le principal bénéfice à ce type de démarche ? Dans un contexte de crise à répétition, il est important de questionner notre capacité à nous organiser. C'est cela que nous aurons voulu faire avec cette saison. Bonne écoute à tous.

• Speaker #2

  Bonjour à tous, je suis ravi aujourd'hui d'être avec Lionel Chen qui est le DCI de BPI France. Bonjour Lionel.

• Speaker #0

  Bonjour.

• Speaker #2

  Bon, du coup, avec Lionel, BPI France, je ne vais pas expliquer, on ne va pas te demander de présenter BPI France, franchement, ou dans tous les cas, parce que les gens entendent, mais je pense que tu, vu que ça a quand même pas mal bougé, notamment avec ton recrutement, ton arrivée, parce qu'il y a eu une vision d'une nouvelle, voilà, une nouvelle étape de BPI, tu m'en as parlé un peu, BPI comme une fintech, est-ce que tu peux nous parler tout rapidement de toi sur ton parcours, qu'est-ce qui t'a amené à BPI, qu'est-ce qui t'a suivi dans le poste, et en fait, après, on ira bien sûr sur ton aventure, puisque le... Le podcast va beaucoup parler de cet épisode de SAFE et de tout ce que tu as mis en place dans ton équipe qui est assez nombreuse.

• Speaker #0

  Tout à fait. Donc moi, mon parcours, c'est assez simple. Je suis dans l'IT depuis que j'ai commencé. Donc maintenant, ça fait quelques dizaines d'années pour ne pas dire autre chose. Donc là, pendant très longtemps, j'ai travaillé dans des DSI. J'ai très longtemps travaillé dans le groupe La Poste. Donc j'étais le DSI de Codissimour, le DSI de La Poste, branché à Service Corier, donc en clair le DSI des factures. Et puis BPI m'a proposé de prendre la DSI d'une banque pour l'information. Je ne suis pas banquier historiquement. Donc là, c'était un beau challenge pour se faire. Et effectivement, pourquoi ils m'ont choisi ? Justement parce que je n'étais pas du métier et qu'il fallait voir un petit peu autrement. Parce qu'effectivement, notre logique était d'être une FinTech avec un réseau. C'est un projet que je m'attèle de transformer maintenant depuis plus de trois ans et dans des métiers que j'ai découverts depuis et qui sont vraiment super passionnants. Donc là, on est au service des entrepreneurs, BPI France, on est là pour aider. les entrepreneurs de plein de façons. On est le guichet unique, on est l'impressario, on est l'assistant des entrepreneurs et on les finance, on les aide à innover, on les aide dans plein d'étapes. Et donc, du coup, beaucoup de systèmes d'information à leur service.

• Speaker #2

  Ok, et du coup pour être sûr, tu sais en fait c'est bête à dire mais ça veut dire quoi de passer de BPI qui n'est pas une FinTech à BPI qui est une FinTech ? En fait c'est quoi le constat de pourquoi en fait ? Qu'est-ce que ça veut dire ?

• Speaker #0

  En fait globalement ce qu'on voit souvent et moi qui ai souvent vu dans les organisations, quand on intègre de l'open innovation notamment une startup ou une FinTech dans son système d'organisation, généralement on tue. la FinTech ou ont eu la solution. Pourquoi ? Parce qu'en fait, naturellement, les modèles d'organisation des FinTech ou des startups sont des organisations qui sont plutôt plus petites que nous, nos grandes organisations, on va dire. Et globalement, on n'a pas les mêmes modèles, les mêmes façons de travailler et globalement autour de ces sujets-là. Et donc, de vivre une FinTech avec un réseau, nous, l'objectif, c'était de dire, c'est à nous de nous transformer, nous, grandes organisations, pour être comme des organisations et aussi agiles. Parce que derrière, il y a bien sûr la notion d'agilité qui est forte chez nous. Et donc d'agilité à l'échelle, puisque nous, on est des grandes organisations, on doit être aussi agile qu'une startup, une FinTech. Pourquoi ? Parce qu'on a des sujets de time to market. Il faut savoir qu'on doit réagir très vite. Et nous, un enjeu fort qu'on a, c'est de déployer des choses. Ce qu'on a déjà fait, donc globalement, quand il fallait monter le prêt garanti de l'État, c'était à terme 147 milliards d'euros. On a dû le faire en très, très peu de temps. Et si on n'avait pas structurellement cette agilité-là, on n'aurait pas réussi à le faire. Et le Avec-un-Réseau, c'est qu'on est au service de nos chargés d'affaires, c'est-à-dire que le client est notre cœur de métier. Donc nos clients du système d'information, c'est nos chargés d'affaires, ceux qui dialoguent tous les matins, qui tutoient les entrepreneurs, qui vont les voir en local dans nos 47 sites dans toutes les régions. Donc c'est ça notre projet, donc beaucoup d'agilité, beaucoup d'aller vite et de répondre en proximité. C'est ça un petit peu les valeurs de notre projet.

• Speaker #2

  Donc du coup c'est autant la plateforme, nous par exemple chez RSS on a accès à BPI en tant qu'entrepreneur, c'est là où on peut faire les dépôts, la bourse French Tech, les subventions, là tous ces sites-là, toutes ces parties-là c'est vous qui les faites avec le chargé d'affaires qui regarde le back-office etc.

• Speaker #0

  Tout à fait, donc on a tous les produits de financement, donc on te finance, on t'accompagne, c'est aussi beaucoup d'accompagnement, c'est de la formation, on est sans doute un des plus grands formateurs. de France, c'est on aide à investir, on est une banque de plein d'exercices là-dessus, donc on est régulé, on sort toutes ces informations-là, et c'est effectivement de t'en charger d'affaires avec tout le back-office qu'on a à produire, c'est toute cette informatique-là, et c'est plein de sites web, on en a plusieurs centaines, qui correspondent à des éléments d'offres, c'est effectivement TechInFab, FrenchTech, c'est l'aide aux entrepreneurs, à la création d'entreprises. Donc, tous les parcours associés à ces éléments-là. Donc, c'est les deep tech comme site, c'est le hub dans lequel il y a toutes les startups françaises qui sont identifiées dedans. Donc, c'est beaucoup de données qu'on intègre autour de tous les usages que peuvent avoir les entrepreneurs et on aide à ce qui s'accélère, qui se développe.

• Speaker #2

  Ok, et du coup aujourd'hui, quand tu parlais de 200 sites, j'imagine qu'il y a les sites et puis il y a les produits même internes, etc. Tu as le nombre de produits que vous maintenez,

• Speaker #0

  vraiment de produits ? Aujourd'hui, on a à peu près 183 produits en catalogue pour tous les produits de BPI France. C'est 26 métiers différents, donc vraiment, c'est des métiers comme l'accompagnement, c'est l'assurance export, on aide à exporter et donc on fait des très grands contrats pour exporter. C'est effectivement du fonds de fonds, c'est du financement, c'est de l'investissement. Et dans les financements, on fait du financement court terme, moyen terme, long terme. On fait du credit buy, du credit buy immobilier, du credit buy matériel. Donc là, on a tous ces éléments-là. La seule chose que nous n'avons pas, c'est une banque de retail. Il n'y a pas de compte bancaire chez nous. Mais par contre, une banque en ligne, on a des revues de presse personnalisées, on a beaucoup de communication. On anime beaucoup, on fait des grands événements. Bientôt, le 5 octobre, 50 000 entrepreneurs qui vont venir à l'Accor Arena à Paris. Tout ça, c'est beaucoup d'informatique derrière, parce que tout ça, c'est du processus certes agile, mais qui doit s'intégrer et qui reporte. C'est beaucoup de données, puisqu'on produit aussi des rapports pour l'État, pour... On a des gens qui cotent les risques dans tous les pays du monde, parce que quand on investit à l'étranger, on sait quels risques on doit porter. On a des comptes, on a des data analysts qui font des synthèses, soit pour nous, soit pour nos parties prenantes. C'est tout cet écosystème qu'on anime, avec beaucoup d'informatique, et une informatique qui est de plus en plus disponible. En ligne, donc la plupart de nos services maintenant, nos produits se vendent en ligne donc aussi, même si on a toujours nos chargés d'affaires qui viennent voir aussi en physique donc nos métiers. Et notamment en termes de prêts, on a fait des prêts digitaux, on est sans doute la plus grosse fintech d'Europe en termes de volume et de millions décaissés full digital donc globalement. Donc voilà, et donc on est banque de plein d'exercices là-dessus, sur des prêts digitaux. Donc c'est des choses qu'on opère maintenant depuis un an. plusieurs années et en volume.

• Speaker #2

  Et du coup, toi aujourd'hui, en termes d'équipe, le nombre de personnes dans l'IT ?

• Speaker #0

  Donc là, mes équipes, c'est à peu près 300 personnes en interne et aujourd'hui, on a 1200 prestataires parce qu'on est encore très externalisé au gouvernement. Donc là, ça fait une belle force de travail.

• Speaker #2

  1500 personnes qui sont dans l'IT, interne et externe.

• Speaker #0

  Tout à fait, donc 1500 personnes qui sont même en agilité distribuées à l'échelle. Toutes nos équipes sont des équipes de 6-8 personnes qui travaillent de façon autonome et dans une vision très architecturée de notre système d'information qui travaille en rythme de 10 semaines avec des imprimants de 10 semaines et une façon de se synchroniser toutes les 10 semaines au service de nos métiers pour produire le maximum de valeur métier, de valeur business.

• Speaker #2

  Donc quand toi tu arrives, tu arrives parce qu'il y a un enjeu de devenir une fintech, c'est challenging et excitant mais ça reste un enjeu. Et donc du coup se pose bien sûr la question du cadre méthodologique ou cadre organisationnel que tu peux proposer avec tes équipes pour délivrer la valeur qui est souhaitée dans un temps toujours record parce que forcément tu parlais de time to market, donc c'est une question de, il fallait que ça aille vite. Et donc du coup tu me disais en préparation... Toi tu es arrivé et tu as dit par rapport à ce qu'on veut faire et la taille qu'on est, il y a un framework qui s'impose un peu à nous, c'est SAFe et tu as voulu l'appliquer. Tu as dit voilà pour couper court un peu à des débats aussi, on pourrait faire ça différemment, tu as donné un cadre méthodologique. J'aimerais bien que tu nous expliques un petit peu quand tu es arrivé pourquoi SAFe du coup ? Est-ce que c'est les arguments que j'ai donnés ? D'autres ? Comment c'est devenu une évidence et comment ça s'est lancé ?

• Speaker #0

  En fait, quand je suis arrivé, j'ai fait le constat qu'effectivement, un des sujets majeurs qu'on avait à traiter, c'était le time to market et l'accélération du delivery de la valeur qu'on avait à faire. Et donc, notamment, il fallait le faire de façon itérative. On avait des progiciels, des choses comme ça qu'on livrait quatre fois par an. Et donc là, en l'occurrence, on demandait d'aller beaucoup plus vite et de sortir beaucoup plus de produits. C'était normalement dans la période, moi je suis arrivé en 2020, donc c'était juste la sortie de la phase du confinement du Covid. Et même si j'étais là en partie dans la phase de lockdown, de confinement, derrière on a dû faire des plans pour la relance. Donc on a un peu oublié. parce qu'il a fallu faire plein de choses pour que l'économie ne tombe pas. Donc, redonner du cash dans l'économie, c'est le rôle de BPI, et prendre des risques dans ces périodes-là. Et c'est quelque chose qu'on a plutôt bien fait. Donc, le constat qui a été fait, c'est de dire qu'on avait une transformation sur plusieurs axes à faire. Une transformation, je dirais, par l'architecture. Moi, je compense toujours par ce sujet-là. C'est que pour faire plus vite en qualité de données, il faut bien poser nos cadres d'architecture. Donc on a choisi de faire de l'architecture de microservices. Pour aller plus vite, on s'est dit qu'il faut continuer notre transformation sur le cloud. On a fait une transformation par le cloud. On a bien sûr vu que le sujet de la sécurité était essentiel dans ce qu'on avait à faire. Donc on s'est dit qu'on allait se transformer, y compris sur les éléments de cadres de sécurité. Et est arrivé finalement la problématique du modèle opérationnel. Le modèle opérationnel, on a appelé ça notre target operational model, donc on s'est regardé et on a regardé plusieurs points. Et en fait, le modèle opérationnel qu'on a choisi, c'est de dire ok, il faut de l'agilité, et donc l'agilité à l'échelle, parce que notamment il faut qu'on intègre et qu'on travaille avec des partenaires qui sont des FinTech, parce qu'on fait pas mal d'open innovation dans ce qu'on fait, donc on intègre des composants, et donc l'idée c'est de travailler comme elles, donc ça c'est le premier point, donc l'agilité. Et deuxième point, on s'est dit, en fait, il faut sortir du mode, je développe et j'opère. On s'est dit, il faut faire du DevSecOps, donc on développe, you build it, on opère, you run it. Et vous êtes propriétaire de nos équipes, sont propriétaires de leurs assets, de leurs produits, grosso modo. Et donc, on est parti en démarche produit. Quand on a fait ce calcul-là, on s'est dit, il faut trouver un pattern pour ce faire. Et on s'est dit, c'est pour l'information que j'avais déjà mis en place. Et c'est un document que... Donc à la poste, il savait plutôt bien marcher, donc à grande échelle. Un des intérêts du modèle, c'est qu'il est déjà open, donc on peut tout avoir. Il y avait tout un cadre de formation qui existait. Pour l'époque, il n'y avait pas encore l'engouement ou le volume de gens qui savaient faire. Donc là, on s'est dit, on y va et on y va by the book. Donc by the book, ça veut dire qu'on a appris safe comme il est. Donc voilà, et on a dit on va déjà faire, je venais à l'époque souvent la recette suivante, moi je ne suis pas un grand cuisinier, mais j'aime bien manger, si je veux faire une tarte tatin demain, je suis nul qu'en cuisine, mais je vais prendre un bon bouquin de cuisine, Jean-François Piège qui fait la recette de la tarte tatin, si je le suis au gramme près sa recette, je vais pouvoir faire une tarte mangeable. Et donc c'est comme ça qu'on a commencé, donc on a fait des tartes mangeables avant. Save by the book. Donc là, en alignant tout le monde, en formant tout le monde, donc beaucoup de formations, donc Leading Safe, par exemple, la formation, j'ai formé tous mes équipiers. Tous nos prestataires qui voulaient travailler avec nous, il fallait qu'ils comprennent le langage et qu'ils soient formés. Donc là, c'est un gros élément de formation. Et on a fait tout en même temps. Le tout en même temps, c'est, OK, on bascule dans le cloud, donc le plus possible d'assets. On a un CI-CD, on a tous les outils qui vont avec. Donc là, on a fait tout en même temps en disant, OK, maintenant... L'architecture, c'est du microservice. On fait de l'architecture événementielle, on fait du live-on, drive-on architecture sur tous les nouveaux sujets qu'on traite. Donc là, on a bien sûr du legacy et on traite le legacy en même temps, donc bien évidemment. Et on l'a fait aussi en même temps. On a augmenté notre sécurité, notre segmentation, donc toute la partie préparatoire autour de notre choc. qui a été tous revus, et donc on a fait tout ça en même temps. Et paradoxalement, c'est un gage de réussite, parce qu'on a un cadre, on a une façon de travailler correcte. Gualement, on traite et on progresse sur tous les éléments. C'est une méthode itérative, on est apprenant, on fait les rétrospectives, on avance, donc on regarde ce qui ne va pas bien, on traite et on progresse de façon très lean, parce que c'est une méthode qui est à la fois agile et qui est très lean. Et en même temps, on a revu tous nos modèles de sourcing, nos partenaires, la façon dont on travaillait. Donc voilà, et on a beaucoup ciblé autour de la compétence et donc nos équipiers. Donc on a animé tout ça dans la transformation et c'est comme ça que ça le fait. Et voilà, et donc maintenant on y est full. Donc depuis maintenant, on a trois ans de... de fonctionnement complet. Et aujourd'hui, ce n'est plus un sujet. Et même nos métiers, parce qu'il faut bien sûr embarquer une partie de nos métiers, notamment les PM, les programmes managers et les PO, qu'on essaie d'accompagner, on les a formés et on l'a dit, c'est comme ça. Alors, ça a été possible parce que c'était un projet d'entreprise, parce qu'effectivement, c'était porté comme ambition. Donc, être une FinTech à 20 ans à l'Azo, c'est-à-dire, c'est travailler comme les FinTech, avoir des méthodes agiles. Donc voilà, c'est comme ça qu'on a posé et utilisé des pratiques d'environnement, de gestion, qui ont été agiles. C'est comme ça qu'on a porté ce projet qui était porté par la direction générale, sur lequel j'étais venu pour l'incarner, et sur laquelle les deux missions étaient un peu plus claires. Et c'est comme ça qu'on a pu réussir cette transformation. Dans l'agilité, il y a un pattern japonais qui vient de l'automobie qui s'appelle Shu A-Ri. S-H-U-H-A-R-I. On a fait la partie qu'on appelle Shu dans laquelle on fait la recette de cuisine. Pour information, on est en train de passer dans une étape intérieure qui s'appelle A où on commence à revisiter un certain nombre de pratiques parce que maintenant on les a bien compris. A mes équipes, je leur donne souvent cette image-là. On a une idée, au niveau de la tête, on avait l'idée de l'agilité, de notre ambition d'agilité. On l'a bien mangé, on en a eu plein le ventre. Des fois, on a un peu mal au ventre parce que tout ne passe pas bien. Et puis maintenant, on commence à bien l'aimer. Et c'est maintenant qu'on commence à bien l'aimer qu'on peut la revisiter. Comme j'évoquais la tartate, maintenant, on est en train de revisiter un petit peu la recette. Et voilà, on commence à avoir des solutions, large solutions, des gouttes de large solutions dans nos fonctionnements. Pour autant, on n'est pas large solution by the book parce qu'on a bien compris et parce qu'on aime la méthode et qu'on l'a comprise et donc du coup on peut la revisiter ou la retravailler. Et pendant trois ans, on a fait by the book.

• Speaker #2

  Tu as dit plusieurs choses sur lesquelles j'aimerais bien qu'on revienne. Tu fais toutes les transactions en Martian en même temps, l'architecture, la sécurité, l'organisation. Point positif, point négatif d'avoir fait ça avec le recul ?

• Speaker #0

  Le point positif, c'est qu'à dire que pour opérer de l'agilité, pour vraiment que tes résultats avancent, je vous donne un exemple. L'année dernière, on a doublé le nombre de mises en production donc itérative par rapport à l'année d'avant. On a diminué le nombre d'incidents par deux sur nos patrimoines applicatifs. Cette année, en six mois, on a doublé par rapport à l'année dernière. Donc on a encore doublé le nombre de mises en production. Donc là, pour être clair, aujourd'hui, on pilote beaucoup par un indicateur qui est inventé par Google qui s'appelle le DORA. Aujourd'hui, nos équipes, pour être ce qu'on appelle élite, doivent mettre en production l'ensemble de leur patrimoine tous les 15 jours. Donc on fait des mises en production tous les 15 jours. Pour faire ça, il faut du cloud. Pour faire ça, il faut des CLCD. Pour faire ça, il faut des Ops qui opèrent, parce que sinon, derrière, on peut faire très vite, mais on aura ce que j'appelle le change failure rate qui va se planter, c'est-à-dire qu'on va faire des mises en production non qualitatives, donc il faut faire un saut qualitatif dans ce que vous produisez. Il faut automatiser vos tests, vos tests unitaires doivent être automatisés, donc il faut tous les outils, l'arsenal qui va avec. Il faut avoir les capacités de faire du roll back et de la résilience parce que vous mettez en production en continu donc voilà et ça nécessite de faire toutes ces transformations et tous les outils qu'on a aujourd'hui et vous les utilisez en même temps que vous construisez donc la pratique donc voilà et donc ça c'est un gain. structurel qui fait que ça nous permet de tenir ces engagements et tourner la business value. Parce qu'en même temps, toute cette transformation-là, moi, elle est pilotée par un indicateur qui est le NPS, le Net Promoter Score, c'est-à-dire qu'en clair, tous les mois, on interroge nos utilisateurs et on leur dit qu'est-ce que vous pensez du SI de BPI France ? Donc, quand je suis arrivé, le NPS était négatif. Donc, il est assez négatif. Voilà, on connaît peu de gens qui disent j'utilise le NPS quand il est négatif Et donc, aujourd'hui, on n'est pas dans des sommets. On est à 25, mais globalement, on a atteint notre objectif d'un NPS positif durable sans à-coups de 25. On a diminué surtout la partie incidentogène de notre SI et en même temps qu'on développait notre time to market. Et c'est le en même temps qui permet de faire ça. Si on avait fait des bouts, je ne suis pas sûr qu'on arrive au bout parce que l'agilité, il y a toujours ceux qui vont dire oui mais c'est pas bien, il y a des choses que finalement on n'avait pas compris et on veut revenir à l'ancien, etc. Là en clair on brûle les ponts, on va en avant et on démontre avec des indicateurs. Donc tout ça c'est beaucoup d'indicateurs, moi je travaille beaucoup dans le pilotage. Donc tout ça dans le SI d'information aujourd'hui, je vais vous dire le nombre de mises en production, là où je suis. En termes de niveau de qualité, on a ce qu'on appelle l'excellence opérationnelle qu'on pilote sur plein d'axes, sur mes pratiques agiles, sur mes pratiques DevOps, sur mes pratiques de sécurité, le nombre de CV par équipe. On ramène tout ça à la notion d'équipe. L'équipe est notre sujet unitaire dans lequel tout est ramené. Et cette excellence opérationnelle, elle est faite par l'équipe pour l'équipe. Et ce qui fait d'ailleurs que le modèle est scalable. Parce que pendant la même période, pour être clair, nous on a eu en plus des augmentations de volume de charge et de budget quelque part de 20% par an. C'est-à-dire que si je n'avais pas fait ça, je n'aurais pas été dans un mode escalade, je n'aurais pas su tenir ma qualité. Et souvent, l'avis des DSI, les auditeurs DSI, ils savent bien, c'est à la fois les projets, l'ambition, la stratégie, mais c'est aussi de façon très concrète la qualité de ce que vous délivrez à vos utilisateurs. Et on a deux pieds. Donc si un de nos pieds lâche, La vie d'un DCI est souvent courte, donc il faut vraiment être solide et sur le run opérationnel donc l'ops, donc maintenant dans notre modèle et à la fois le dev. Parce que si vous ne délivrez pas les produits dont l'entreprise a besoin, c'est pareil, vous êtes en difficulté. Et un point qui est très important, parce que j'ai peu parlé des métiers, j'ai parlé du NPS, qui est ce qui nous travaille. Les méthodes qu'on évoque là sont très centrés clients, puisque c'est le business qui est obligé de participer à nos démos tous les 15 jours, qui évalue la business value, et la valeur est basée sur le métier.

• Speaker #2

  Ça m'intéresse sur la partie SAFE, parce que tu disais formation, donc du cœur des 300 plus 1200 de ton équipe. Et tu parlais aussi des PIO que tu allais chercher chez les métiers, parce que là, tu parlais de cadre, de target personnel modèle, mais du coup de l'entreprise, pas de la délétim, de l'entreprise. Bien sûr. Donc du coup, il y a aussi les changements RH qui sont liés à d'autres parties prenantes. A ce niveau là, est-ce que ça s'est passé à la même vitesse ? Ce côté tous les métiers ont réussi à être formés, à avoir des producteurs, à avoir des recrutements pour compenser des gens qui sont chez les métiers et qui vont passer plus de temps sur les produits. Est-ce que toutes tes équipes ont du coup un PO métier ? Et est-ce que ce PO métier là est à 100% dédié à cette équipe là ?

• Speaker #0

  Donc en fait, nous on a 26 métiers, donc ça a été 26 histoires différentes. Donc Goulalement, il a fallu convaincre 26 fois Goulalement, gérer les éléments, les particularités Goulalement. Mais par contre, la cible était très claire. Donc, sachant que la DSI est elle-même un métier. Quand on fait des enablers techniques, moi j'ai des PO et des PM de la DSI, mais pas sur un posant technique. Donc c'est un point qui est à avoir. Donc on voit et on traite ces éléments-là au fur et à mesure. Et donc on a traité ça sur toutes nos équipes métiers, avec des éléments de schémas de transformation qui ont été mis en place. Et donc il y a des leaders bien sûr, il y en a qui ont montré très vite beaucoup d'appétence.

• Speaker #2

  d'autres beaucoup moins donc leur résistance elle a été liée plus à la peur, la méconnaissance, voilà. Ou est-ce que c'était aussi lié à, en fait, moi, les gens qui peuvent aller dans les équipes, elles sont super intéressantes et importantes, mais il faut du coup les remplacer. Et du coup, comment je les remplace ? Est-ce que j'ai les budgets ? Parce que c'est des vraies aussi questions que les métiers peuvent se poser.

• Speaker #0

  Donc, en fait, on a fait une vraie transformation sur les budgets parce qu'effectivement, avant, quand je suis arrivé, la DSI avait un budget centralisé et opérait le budget IT. Donc, quand je suis arrivé, je leur ai dit, non, mais on ne va pas faire comme ça. Donc, voilà. Moi, j'ai besoin de créer ce qu'on appelle les composants des socles. Donc, on a fait un budget IT de socle. Et le reste, j'ai dit, mais en fait, c'est des budgets IT, mais pour vous, métier. Et c'est vous qui avez décidé ce que vous voulez en faire. Et donc, vous allez pouvoir, du coup, gérer votre enveloppe budgétaire pour savoir ce que vous allez en faire. Et sans doute, il faut vous renforcer sur certains éléments. Donc là, sachant qu'à terme, le savoir et la compétence d'un PM, ça doit s'internaliser. Donc, on doit faire ces éléments-là. Donc, ils ont pu le gérer. Alors, ça a été déjà un premier point, parce qu'en fait, ils se sont aperçus quand le... L'IT c'était pas gratuit, on jouait au mesquine, ne sort pas de son propre argent, c'est souvent moins important. On a appris beaucoup ce que j'appelle la frugagilité, parce qu'en fait la particularité de la méthode quand elle est bien appliquée, c'est qu'on fait des MVP, des Minimum Viable Product. Et ça c'est quand même une source de gains, c'est d'ailleurs la principale source de gains de cette transformation-là quand on regarde bien, parce que SAFe, toutes les pratiques etc. c'est pas gratuit, c'est des compétences, c'est même une formation qui coûte assez cher. Par contre là où vous gagnez, et on le voit nous sur le long terme, c'est grosso modo, c'est qu'avant on faisait des cahiers des charges, on écrivait son besoin etc. Mais en fait il y a... Un peu comme dans Excel, on n'utilise même pas 25% d'Excel. Souvent, on faisait des applications qu'on n'utilisait pas parce qu'on pensait que c'était nécessaire de faire. L'itération et la mise en production continue de nouvelles fonctionnalités fait que vous pouvez les tester. Et en fait, vous vous concentrez sur l'essentiel au départ, le MVP, le Minimal Viable Product, ou moi j'appelle même le Vital Product au départ, je disais. Commencez par le Vital, on va faire déjà les fonctionnalités vitales. Et on voit bien que dans l'informatique, souvent, avec 20% de l'énergie, vous faites 80% de la valeur. Et finalement les 20% complémentaires souvent vous dites finalement je peux m'en passer de toute façon j'ai d'autres problématiques et vous enlevez ce que j'appelle les Mickey dans les coins. Donc les Mickey dans les coins ce sont les nice to have, les trucs qu'on pourrait avoir mais finalement qui sont finalement peu en valeur. Et ça ça a beaucoup plu je trouve au métier et ce changement là, ils se sont dit mais moi je préfère effectivement donc avoir moins mais plus vite. Et après, il y a un autre point qui est très important dans la méthode, dans la pratique. Nous, on a un taux de tenue d'engagement à peu près de 86%. C'est notre benchmark qu'on a atteint déjà depuis très longtemps. Et en fait, les métiers avant, on leur promettait des grands délais de charge, puis on ne tenait pas les délais. Nous, là maintenant, on tient les engagements, les équipes tiennent les engagements à 86%. Alors pourquoi pas 100% ? C'est parce que des fois, il y a des choses qui bougent dans l'incrément. Ils prennent des notes cométides, donc des features. qui n'était pas prévu finalement, donc ils font voilà. Mais aujourd'hui, ce qui a beaucoup changé, c'est que nos métiers ont totalement confiance sur notre capacité à délivrer dans le timing. Donc voilà, et ça c'est super important. Et donc les métiers, quand ils ont vu ça, ils ont dit Ah, finalement, j'ai peut-être moins, mais de façon... Un, à temps, et deux, façon maîtrisée, donc également. Et du coup, c'est moi qui maîtrise. Et en même temps, on leur a dit C'est votre argent. Et donc du coup, elle dit, mais finalement, du coup, je peux voir où je mets plus de liberté dans les choix associés. Bien sûr, après, il y a des cadres d'architecture et un certain nombre d'éléments. Et après, il y a eu un autre phénomène qui est aussi très intéressant, c'est que nous, les composants qu'on appelait socles, c'est-à-dire qu'on avait travaillé et qu'on a mis comme Enabler, en fait, quand tu les utilises, c'est gratuit. Donc ça, c'est assez magique, parce que grosso modo, les métiers disent, OK, comme c'est mon argent, si tu me donnes un composant gratuit, je préfère le faire. Donc avant, je vous donne un exemple. Quand je suis arrivé, j'avais... j'ose pas le dire combien, j'avais beaucoup de systèmes de GED. Parce que chaque métier avait dit, ah oui, mais moi ma GED, elle est totalement spécifique, donc dans mon silo, j'avais fait mon... Aujourd'hui, moi j'ai fait un socle de GED, qui marche d'ailleurs super bien. Donc voilà, et globalement, je leur dis, si tu utilises la GED commune, centrale, elle est peut-être moins bien que ce que tu voulais, mais elle est gratuite. versus si tu veux un autre truc, ok, mais dans ce cas-là, tu le prends sur ton budget spécifique. Et comme par hasard... quand on fait des composants aussi de valeur, ça permet de converger et donc d'avoir des architectures avec beaucoup moins de composants, donc qui coûtent moins cher en termes de maintenance, parce que you build it, you run it c'est tu payes ce que tu construis et ce que tu opères aussi Et du coup, avant, on disait oui, il ne faut pas trop s'occuper de la maintenance, etc. quand les métiers ont dans leurs éléments de pilotage budgétaire le fait qu'effectivement… s'il change de version ça coûte moins cher ou qu'il y a moins d'erreurs ou qu'il y a moins de bugs. Donc là ça facilite ce qu'on appelle les non-functional requirements, c'est-à-dire qu'un métier bien sûr il veut du fonctionnel, mais aussi tout ce qui est non-fonctionnel, ça améliore la sécurité, ce qui fait qu'on patch et qu'on délivre les patchs et les CVE tous les 15 jours, ou même plus vite qu'il faut le faire s'il y a une CVE critique qui vient de tomber. Donc tout ça va dans le sens d'une plus grande valeur portée. mais d'une façon fondamentalement différente. Donc là, il s'achance quelque part aussi la culture, et la culture, ça c'est plus lent. Donc la culture, c'est au moins en année, alors que la pratique, ça peut se traiter en mois. Et du coup pour revenir sur les deux points, donc la construction budgétaire, donc tu avais un budget de X, tu as gardé un socle pour toi et après tu as réparti le budget dans les métiers en disant en général on consommait tant, maintenant vous choisissez dans ce que vous voulez faire, c'est ça ?

• Speaker #1

  Exactement.

• Speaker #0

  Et dans ça, avec le côté en disant par contre pour travailler avec nous, il va falloir que vous ayez des personnes à temps plein. qu'on appelle PO etc. Donc dans ce parti-là, vous devez former des jeunes, sinon on ne pourra pas travailler, c'est cette partie-là.

• Speaker #1

  Tout à fait, et au départ, il y en a qui ont pris de l'assistance pour dire on fait des proxy PO, ce que j'appelle des proxy PO, au fur et à mesure du temps, les métiers sont montés, sont organisés, il y a encore quelques métiers qui ont du mal à mettre un PO à temps plein, et du coup ils font encore des petits bouts de PO, ce qui n'est pas très facile à gérer, et eux-mêmes sont aperçus que etc. Avec le temps, on arrive maintenant dans des organisations qui sont effectivement selon le modèle, donc grosso modo, et ça fonctionne bien. et on capitalise, gérer. Et oui, les métiers disent que prendre du SI, ça a du temps. du temps dans leur métier, mais ça apporte de la valeur aussi. Donc quand cette chaîne-là s'enclenche, ça avance.

• Speaker #0

  Et donc du coup, le second point, vous parlez du MVP. Moi, ce que je vois souvent, la difficulté, c'est le langage commun de ce qu'on livre. Il y a le mot projet, des fois il y a le mot sprint. En gros, il y a plein de mots pour dire ce qu'on fait dans un temps imparti. Aujourd'hui, vous, c'est des trains de 10 semaines, c'est ça ?

• Speaker #1

  Tout à fait.

• Speaker #0

  Et donc du coup, comment vous appelez, c'est quoi le langage commun de BPI pour dire ce que vous faites ?

• Speaker #1

  En fait, le langage commun de BPI, c'est celui de SAIF. Donc en fait, c'est un des points qu'on a vu, c'est-à-dire qu'on utilise by the book c'est-à-dire que grosso modo, le vocabulaire de SAIF, et on essaie surtout pas de rejeter celui-là. Alors au départ, on m'a dit mais on s'appelle BPI France, on dit mais tu ne fais que parler anglais, là c'est tous des termes, etc. Et je lui ai dit oui, j'assume totalement. Mais si SAFE a été en espagnol, on aurait tout utilisé des termes espagnols. Le sujet n'est pas là. Le sujet, c'est que derrière un mot, il faut mettre la même définition. Et donc là, en parlant de l'aspect langage, le langage commun, il est from the book, by the book de SAFE, ce qui fait qu'on a eu naturellement un langage commun, ce qui est très important pour se comprendre et qui est source de réussite à mon sens. Donc là, c'est ça. Et par contre, on n'a pas des voyés de ce langage-là.

• Speaker #0

  Et du coup, tu as des produits, etc. Tu fais ça toutes les dix semaines, tu fais une rétrospective. Et donc, du coup, la question que je me pose, c'est quand tu veux faire un point un peu de ce qui s'est passé dans le trimestre, etc. avec d'autres métiers, le directeur ou autre, tu me regardes, tu ne fais pas ça ?

• Speaker #1

  Non, je ne fais plus ça, je n'ai plus de copine. Donc les copiles on se retrouve à 15 pour dire l'état d'avancement des sujets etc. On ne fait plus ça. Les métiers s'ils veulent avoir l'état d'avancement, on a tous les outils qui vont bien. Ils ont leur reporting en ligne dans le Jira, donc ils peuvent dire est-ce que mes features donnent, pas donnent etc. Pour information, au COMEX on reporte tous les trimestres de l'état d'avancement budgétaire, de l'avancement global, de tenue de nos engagements. Est-ce qu'on a tenu nos engagements ? Est-ce qu'on tient nos vélocités ? Donc des grands indicateurs. nos KPIs dans l'entreprise. Et si nos métiers veulent savoir où ils sont, de toute façon, tous les 15 jours, ils ont une démo. Et s'ils veulent en plus savoir, ils viennent aux rétrospectives. Et s'ils veulent savoir ce qu'ils vont avoir dans 10 semaines, ils viennent aux PIs. Les PIs, c'est les Programming Criminals Planning. Donc là, non, non, on ne fait surtout pas de copier. Alors, je ne dis pas qu'il n'y a pas quelques exceptions quand on fait des sujets un peu en task force ou qu'il y a un risque majeur dans lequel on veut suivre un sujet particulier ou de prise de décision rapide sur quelques éléments. Mais ça, c'est plus des réunions, j'irais, opérationnelles de décision qui peuvent apparaître de temps en temps, mais on n'essaie plus de faire. Après, on a mis en place, par contre, des choses qui existent. C'est-à-dire pour avoir cette reporting globale un peu générale à froid, on a des revues mensuelles. Donc tous les mois, on a ce qu'on appelle des correspondants métiers qui font la synthèse de toutes les équipes avec les outils, puisqu'on a de la donnée partout. Donc grosso modo, ils sortent du reporting et le partagent.

• Speaker #0

  S'il y a des sujets qu'il faut discuter… Donc il y a quand même aussi ce reporting mensuel de…

• Speaker #1

  Tout à fait, mais c'est quasiment… c'est assez court. Donc nos reporting mensuels, c'est une réunion d'une demi-heure sous lequel on… donc peut-être trois quarts d'heure dans certains les plus longs, mais dans lequel on dit juste, voilà, si vous avez des questionnements, etc. Mais l'aspect reporting est accessible en ligne, tout est outillé, et nos métiers maintenant sont formés à utiliser pour savoir où est ennui leur backlog, où est-ce qu'il avançait, pas avancé, et les éléments, les grands jalons sont partagés.

• Speaker #0

  Ok, et donc du coup, tous les développements sont portés en mode produit, du coup, avec des équipes de DIA.

• Speaker #1

  Tout à fait, donc on a des composants pour nos composants, on développe des produits pour nos métiers, donc voilà, et donc voilà, on est dans cette logique produit qui est délivrée de façon continue.

• Speaker #0

  Ok, et aujourd'hui, les métiers, des fois aussi, ça questionne, donc vous avez réussi à recréer un langage commun, donc les mots ont un sens et le même sens, il y a la question de la projection dans le futur, tu parlais du BI Planning juste avant. Mais des fois, il y a aussi une question de…

• Speaker #1

  Tout à fait, c'est un sujet qu'on a retravaillé, on va dire, maintenant, ça fait un an et demi. Donc, en fait, ce qu'on voyait juste, c'est qu'un des inconvénients de la pratique, c'est que tous les dix semaines, vous repassez dans la moulinette de replanifier, etc. Et au bout d'un moment, vous avez l'impression que ça tourne, parce qu'en fait, le rythme est quand même assez soutenu, même s'il y a des sprints typés. Mais au bout d'un moment, vous pouvez perdre, on guillemet, la direction globalement où vous allez. Donc, on a couplé ça à une autre pratique qui s'appelle les OKR, les objectifs qui résultent. Donc en fait on a chaque année, on a la chance chez BPI de remettre à gérer, d'actualiser plutôt notre plan stratégique. Donc notre plan stratégique c'est par exemple, je vous donne un exemple, on doit donc permettre et orienter la transition énergétique des entrepreneurs, donc premier sujet. Par exemple on doit faire de la réindustrialisation de la France par l'innovation, donc ça c'est des grands thèmes qui sont à revoir. On doit multiplier par deux le nombre d'entrepreneurs, donc ça c'est un de nos objectifs, pour donner les grands axes. Et donc en partant de ces grands axes là, on décline tout ce qu'on fait autour de ces axes là. C'est à dire qu'en clair, quand on fait un système d'information pour faire le programme France Relance, donc France Relance c'est par exemple très lié à l'industrie, on sait le rattacher à notre enjeu de réindustrialisation par l'innovation. Nous équivons à implémenter donc, gérer une EPIC, donc c'est le nom qu'on appelait avant des projets mais donc qui dure du 6 à 9 mois. Cette EPIC là va être rattachée à une feature, une feature à une US. Et grosso modo, le développeur qui travaille dans son US, ou le testeur, il sait qu'il contribue à réindustrialiser la France, donc on aligne bien ses mains. Et des fois, on arrive à avoir des EPICS qui n'ont pas, on ne sait pas les rattacher, donc on se dit, mais qu'est-ce qui se passe ? Ça veut dire que ce n'est peut-être pas ça qui est dans nos stratégies. C'est aussi important pour prendre les décisions. On cote beaucoup les features qui arrivent. Il y a toujours... 200 features pour une capacité de, je ne sais pas, 150 ou 100 même des fois, donc globalement. Et donc l'idée c'est de prioriser. Et donc la priorisation, c'est ce qu'on appelle aussi, qui nous aide à faire les MVP, et on utilise la pratique donc SAFE, qui s'appelle le WAJF. Donc en fait c'est grosso modo les quick wins. On essaie de prioriser ce qui a le plus de valeur business. Et donc on a défini avec tous nos métiers ce qu'était la valeur business. Il y a des cadres. On a des Des fois, c'est parce que ça t'amène plus de PNB ou plus de chiffre d'affaires. Des fois, c'est parce que ça réduit tes charges. Des fois, c'est parce que c'est réglementaire. Donc, il y a tous les critères qui nous permettent de coder ça. Et donc passe en premier les features qui déjà tiennent dans un incrément, qui tiennent dans 10 semaines, ce qui nécessite de faire petit, small is beautiful, donc de délivrer ça de façon continue et bien sûr de rattacher ça à un objectif stratégique. C'est-à-dire que si on a une feature ou une epics qui ne correspond pas à nos axes stratégiques, on met en désalignement stratégique. Alors ça peut nous arriver quelques cas sur des trucs qui sont très rentables mais qui ne correspondent pas à la stratégie. Donc, globalement, ça permet d'avoir cet alignement. Donc, nous, on a complété, parce que ça, ce n'est pas dans le SAFE. Donc, c'est une méthode.

• Speaker #0

  Et les OKR, tu les laisses à l'année ou tu redescends le trimestriel par équipe ? Parce qu'il y a aussi une question de la déclinaison des OKR jusqu'où tu vas en termes de temporalité et en termes d'équipe.

• Speaker #1

  Donc, pour information, nous, on travaille l'année d'avant les OKR de l'année d'après. Parce qu'en fait, on lie nos OKR à nos exercices. ce qu'on appelle plan moyen terme, donc le PMT, donc plan moyen terme, et en même temps que nos budgets, parce qu'en fait, nos budgets sont là pour des ambitions, des OKR, c'est en fait le mot d'ailleurs, objectif qui résulte, et pas le bon mot, parce qu'en fait, c'est des ambitions qu'on pose, donc voilà. Donc là, et donc du coup, on positionne nos ambitions à l'avance, donc pour une année, donc là, même s'il y a des ambitions qui vont faire plusieurs années, bien évidemment, donc là, et on les pose à l'année, et par contre, on en rend compte. de l'avancée de nos OKR, donc, globalement, donc tous les trimestres, donc tous les trimestres à mi-incrément.

• Speaker #0

  Mais tu as des objectifs annuels, des ambitions annuelles, et tous les trimestres, tu définis à quel niveau tu te trouves par rapport à cet objectif-là.

• Speaker #1

  On fait en avancement l'objectif pour dire qu'on avait prévu d'être, je ne sais pas, on avait prévu de doubler, ce que j'évoquais tout à l'heure, on avait prévu de doubler le nombre de mises en production dans l'année. Donc là, il s'avère que notre OKR a été atteint au mois de juin, Donc on a finalement atteint notre objectif annuel au mois de juin, donc on en rediscute, on se refixe une échéance, donc voilà c'est assez rare qu'on le fasse. Il y a plein d'ambition qu'on n'atteint pas. Bien sûr. Donc là on a…

• Speaker #0

  Et il y a combien d'objectifs sur une année ? C'est quoi en termes de nombre ? C'est un truc comme un peu ceux qui sont massifs c'est 3,5 ou c'est 50 parce que toutes les équipes en ont 8 ?

• Speaker #1

  En fait, toutes les équipes se déclinent dans ce nombre d'objectifs, parce qu'il y a des porteurs d'objectifs. Donc là, je n'ai pas le nombre exact, parce qu'en fait, tout est hiérarchisé, c'est dans les arbres. Et à la fin, certains descendent dans des choses assez fines. Mais c'est décliné totalement dans les équipes qui elles-mêmes ont contribué. On appelle ça les away. On les envoie au vert. Donc là, on fait… le cyber away, le cyber sécurité away, on fait le data away sur la data. En fait, on se donne des ambitions sur un certain nombre de sujets. On fait bien sûr les socles away pour tout ce qui est composant. Et les équipes ont eux-mêmes défini ces éléments-là, par contre réalignés. Donc il y a un top-down et un bottom-up, il y a deux cycles pour challenger ces éléments-là. Et ça nous file nos ambitions et comme ça, les équipiers savent où ils vont et pourquoi ils vont. Donc ça donne beaucoup de sens. Et tout ça est chaîné. Pour ceux qui connaissent dans notre Jira, on a nos OKR et on sait dire une feature sert à tel OKR. Et à l'inverse, on sait dire tel OKR, donc telle ambition, elle est portée par telle équipe qui contribue, etc. Ce qui est très valorisant pour les équipes de savoir qu'elles, à la fin, représentent nos résultats. Elles savent se projeter dans les résultats de l'entreprise. Et sur cet aliment, depuis notre stratégie qui est partagée en comité exécutif, on fait juste que... nos équipiers qui produisent.

• Speaker #0

  Mais du coup, on est d'accord, il y a les grands objectifs annuels de BPI, et après, on les décline par équipe, des personnes, etc., sur des objectifs, et tous y contribuent, et on sait à quel objectif, mais il y a une question d'un objectif, un layer contribue à un autre layer, etc. Ce n'est pas un objectif qui contribue au rata d'autres objectifs, etc.

• Speaker #1

  Absolument pas, non, non. Les objectifs restent purs à la fin, donc c'est juste l'arbre qui te permet de voir Dans quel branche tu es, dans lequel tu remontes. Et donc nos métiers, maintenant on déploie les OKR aussi chez nos métiers. C'est-à-dire que nos métiers, c'est en cours de déploiement, tous nos métiers ont parcours basculé, mais par exemple le métier de la finance, ça définit ses objectifs qui résultent. Et donc tout ce qu'on fait et tout ce qu'on opère pour eux, on sait le rattacher à leurs OKR, aux ceux qui les ont définis, et ça nous permet d'aligner tout le monde. Et à la fin, tout le monde a les dix grands noms. Les autres échilles stratégiques que j'évoquais tout à l'heure, il y en a 10 maintenant que j'ai pépé. Du coup, tout le monde les connaît, tout le monde sait à quoi ils contribuent. Et ça permet aussi de faire de l'alignement entre nos différents métiers, puisqu'on a quand même beaucoup de métiers, nous. Mais tous sont opérés et centrés sur un plan stratégique qui est commun.

• Speaker #0

  Ok, et le plan stratégique c'est les X objectifs initiaux qui sont décomposés en plan objectif par équipe, par personne ?

• Speaker #1

  En fait ce sont les grandes orientations, c'est les axes stratégiques sur lesquels on veut et nos ambitions. Avec effectivement, comme je dis je veux doubler le nombre d'entrepreneurs, il y en a un million aujourd'hui, il peut y en avoir 2 millions par an, donc à 5 ans, et donc on a fait une feuille de route, donc la direction générale a donné cette feuille de route-là et on opère ces ambitions-là.

• Speaker #0

  Ok, super intéressant. Donc tu as complété un SafeBusinessBook complété par l'ISOCR pour avoir une vision un peu plus dans le temps, un peu plus long terme et redonner du sens à ce qu'on fait parce que c'est très delivery orienté de Safe sur la partie planning, etc.

• Speaker #1

  Tout à fait, il y a des choses. On a implémenté dans Safe ce qu'on appelle le Lean Portfolio Management, le LPM, qui te donne une vision, je dirais, un peu moyen terme au niveau des EPICS. Mais par contre, je pense qu'il faut encore travailler ces choses-là. Il y a une partie qu'on n'a pas encore totalement à appliquer, ce qu'on appelle, mais qui est à cheval entre le Lean Portfolio et la partie OCR, qui sont les différents horizons de temps. C'est-à-dire que dans les éléments de solution qu'il y a dans SAFE, tu as ce qu'on appelle les trois diamants, donc les trois périodes dans lesquelles tu diverges, tu reconverges. Et donc, on a pour le moment, nous, deux diamants. C'est-à-dire que... Un PI c'est un diamant, c'est-à-dire qu'en clair, tu as 200 de capacité de besoin, tu converges sur 100. C'est pour ça que j'appelle ça un diamant, c'est-à-dire que tu converges. Mais après, dans la création des EPICS, on peut avoir aussi des phases de divergence, reconvergence, dans les périodes d'élaboration budgétaire. donc on diverge et on reconverge donc et donc on le fait avec tous ces outils là donc de convergence donc donc ils sont aussi dans ces faits donc cette partie là dans la partie lpm existe donc donc là ok et du coup la titille d'aidé donc gérard

• Speaker #0

  mais tu utilises aussi gérard line pour le porter tout ça ou pas pardon je tiens à l'aïe gérard line c'est la partie non sur la grosse solution de giras sur la partie vraiment agile En fait,

• Speaker #1

  on utilise Jira qu'on a complété d'un certain nombre d'outils. On a des plugins. Donc, dans Jira, on a un truc qui s'appelle Ativo pour faire notamment les interdépendances inter-trains. Donc, voilà. Et après, on a un système d'information qu'on a développé derrière nous qui est très data, puisqu'on est très data-centric. On sait en fait appliquer ce qu'on… On demande à nos métiers, c'est que de la donnée propre déversée dans ce qu'on appelle nous des comptoirs de données, des modèles d'objets métiers. Et derrière, du coup, ça nous permet d'avoir beaucoup d'informations et on le traite au niveau de chaque équipe. Puisque tout ça tourne autour des équipes, on leur donne les moyens de vérifier, de piloter leur excellence opérationnelle.

• Speaker #0

  Ok, écoute, on a fait un super tour. Est-ce que Lionel, tu voudras bien aider des DSI ou entrepreneurs qui sont en train de se poser la question de l'égalité à l'échelle, s'ils ont des questions, te contacter ? Parce que je pense que tu es une des personnes qui l'aura. Ça fait trois ans maintenant, bien déployé sur une grosse équipe, il n'y en a pas non plus plein plein. J'imagine que tu parles beaucoup avec tes homologues, mais ça va se répandre.

• Speaker #1

  Donc, on est là pour aider. Donc, notre job, c'est d'aider les entrepreneurs, d'aider les entreprises, donc bien sûr, d'aider les DSI qui sont en train de se poser la question de l'égalité à l'échelle. On le sait, une cheville essentielle ouvrière souvent, stratégique parfois pour nos entreprises.

• Speaker #0

  Ok, écoute, merci pour tout, c'était super intéressant. Franchement, c'était top, ça permet de mettre de l'eau dans le moulin, dans la réflexion. Je pense que la question du target operational model, elle est bien sûr liée à l'ambition de la société, au moyen qu'elle ait la capacité de se mettre aussi. Et ce qui est intéressant, c'est que vous avez la possibilité et l'ambition de faire un target, une ambition importante pour BPI, donc plus vous arrivez à réussir et du coup ça a permis aussi d'avoir une ambition sur un target de modèle assez forte, donc c'est top. Est-ce qu'une dernière question, est-ce qu'il y a un mois, on va dire… Un moment où tu t'es dit, en fait, safe, c'est cool, mais ça va être compliqué ? Ou est-ce que ça a toujours été, non, c'est bon, ça va le faire ?

• Speaker #1

  Je dirais que non, toujours ça va le faire parce que je suis naturel optimiste et tenace globalement. Mais toujours avec l'ambition de dire qu'on aura une période que j'appelle A, de revisite du modèle. Mais il faut déjà délivrer et que le modèle ne soit même plus un sujet pour avoir l'intelligence parce qu'il faut être très humble dans ces sujets-là. Donc c'est très compliqué à mener ce type de transformation-là. Et du coup, c'est bien d'avoir un cadre, je dirais, stable. Parce que... Ce n'est pas des transformations pour 6 mois, puis à dire je change, etc. Il faut avoir une cible, s'améliorer, l'adaptation continue. Donc en fait, pour répondre plus précisément à ta question, c'est grâce à l'amélioration continue que j'ai jamais d'outil du modèle, parce que c'est un modèle qui est lean. Et le modèle qui est lean fait que tu te transformes et tu bouges en permanence, par contre dans un cadre quand même qui est très contraint, parce que l'agilité nécessite un cadre très contraint. Donc c'est beaucoup de rigueur, ça demande plus de rigueur d'ailleurs que faire des projets en cycle en V. Nous avons un manque, donc voilà. C'est ça qui est aussi la complexité du modèle et j'ai fait beaucoup de cycles en V dans ma carrière avant.

• Speaker #0

  Oui, et tu as un métier super intéressant, tu en as fait beaucoup et…

• Speaker #1

  Qu'est-ce qui s'est passé ? Ce qui s'est passé, c'est que le monde des entreprises et les entreprises ont changé. Et ce qu'on nous demande, nous, DSI, ce n'est pas la même chose. J'ai fait des énormes programmes ERP de plusieurs dizaines de millions d'euros. J'ai déployé SAP à la poste. Ce n'était pas les mêmes enjeux. Et là, je suis encore des ERP, mais on ne le fait pas de la même façon parce que, grosso modo, les cycles et les enjeux, et je ne dis pas que ça fonctionne à toute entreprise. Nous, ce qu'on nous demande, c'est d'être très réactif et de porter de la valeur et d'intégrer la valeur de solutions externes rapidement. Et notre modèle fait qu'on est propre à ce modèle-là et l'agilité est au cœur de notre transfo.

• Speaker #0

  Et du coup, juste pour être sûr, aujourd'hui, si tu dois déployer un SIRH, tu le fais en agile ou en cyclin V ?

• Speaker #1

  Je le fais en cyclin V.

• Speaker #0

  C'est bon, je vais le piéger.

• Speaker #1

  Donc, non. Pour l'information, on le fait en agilité, mais avec une partie qui est adaptée. Mais par exemple, notre ERP qu'on a déployé dans le cloud, en fait, le sujet est très lié au cloud, notamment avec des pratiques DevOps. Donc, si on peut faire tous nos développements en DevOps, parce qu'y compris sur le SaaS, on est en full agile à l'échelle.

• Speaker #0

  Ok, je t'ai piégé c'est tout. Je vais garder cette partie là et je la mettrai tout le temps. Bon écoute, merci Lionel, c'était super intéressant. Merci pour ton temps. Merci c'est tout.

• Speaker #1

  Merci Lionel, au revoir.

• Speaker #0

  Au revoir.

• Speaker #2

  Bon, j'espère que vous avez adoré ce podcast comme nous. C'est super intéressant de pouvoir poser toutes ces questions et vraiment aller au fond des choses. Pour aller encore plus loin, on lance un cycle de live un vendredi sur deux, du coup entre 13h et 14h, entre 11h et midi. Donc pour vous inscrire, soit vous suivez sur LinkedIn, vous verrez les événements passer, soit vous allez sur rsas.io et vous aurez tous les événements qui vont sortir. Donc n'hésitez pas, dans ces lives, vous pouvez poser vos questions. et intervenir directement avec le speaker. Et en attendant, bien sûr, n'hésitez pas à partager le podcast sur LinkedIn et à le noter sur Apple Podcasts ou Spotify. Merci à tous.