Transcription

• Speaker #0

  Aujourd'hui, je suis très content d'accueillir Laurent Buisson de BC6, qui est notre partenaire depuis un petit moment chez MyReport, pour parler d'un thème qui vous concerne beaucoup, en tout cas l'évolution du rôle du consultant en analyse de données, pour parler sans jargon technique. On va essayer d'éviter le jargon technique dans le podcast. Et mieux sûr du possible. Voilà, dans la mesure du possible, parce que l'idée c'est aussi de faire quelque chose qui soit abordable, et le jargon technique pour moi n'apporte rien forcément. C'est ce qu'on essaie d'ailleurs d'éviter avec nos clients et nos utilisateurs en général, tant que possible. Donc du coup, Laurent, je vais te laisser la parole pour te présenter, présenter peut-être un petit peu BC6 aussi, ton parcours. À toi !

• Speaker #1

  Avec plaisir. Donc moi, je suis responsable du pôle ERP et BI chez BC6. BC6, on est un intégrateur système de conseil autour des solutions de gestion majoritairement, même si on accompagne nos clients qui sont des PME. Dans la grande majorité, ce sont des PME. Et donc, on les accompagne autour de tout le système SI. Donc ça part aussi bien du système SI très traditionnel, infrastructure, infogérance, mais aussi et surtout, c'est ce qui me concerne moi au quotidien, tout ce qui est solutions de gestion. Donc ça commence forcément autour de l'ERP, mais pas que, et on en reparlera un petit peu tout à l'heure, autour de la BI qui est arrivée assez rapidement finalement derrière les ERP pour les seconder. C'est ce que j'essaye de faire au sein de BC6 avec notre équipe de 100 lits, puisqu'on est basé nous dans l'Oise. Ça fait depuis plus de 20 ans maintenant qu'on opère, ça fait plus de 25 ans maintenant que je suis autour des solutions de gestion, principalement ERP. Puis, on va dire 2010-2012, autour de ce qu'on va appeler les premiers pas de la BI pour les PME. La BI existait déjà avant pour des sociétés plus grandes, mais donc du coup, les premiers pas en BI, donc ça fait une quinzaine d'années aujourd'hui, à peu près, autour de la BI. Et donc, en accompagnant les clients là-dessus.

• Speaker #0

  Très bien. En tout cas, encore une fois, merci. Moi, j'aimerais juste qu'on repasse encore un peu sur toi, sur ton histoire. Comment tu as commencé, peut-être dans l'IT, mais aussi comme consultant BI, puisque tu as un petit peu d'expérience sur le sujet.

• Speaker #1

  J'ai un parcours à la fois atypique et à la fois typique de certains consultants qui vont se retrouver. Atypique parce que je n'ai aucune formation en informatique. Moi, je viens de la mécanique, donc ce qui n'a strictement rien à voir. Je suis autodidacte en informatique. C'est là où le parcours devient plus typique par rapport à beaucoup de profils qui se reconnaîtront. J'ai commencé développeur. Sans connaître l'informatique, ça paraît bizarre, mais c'est peut-être l'affinité que j'avais avec l'informatique. Donc développeur, et progressivement, le développement m'intéressait de moins en moins. Je me suis intéressé plus aux clients qu'aux codes que je faisais. Progressivement, je suis arrivé à faire des entretiens avec les clients, des expressions de besoin, de la formation. progressivement, pas vers le consultant, ensuite chef de projet, et puis maintenant manager au fil des années, donc pendant ces 20... Voilà un petit peu le parcours. Et donc sur la BI, c'est venu un petit peu différemment, puisque ça, c'est le parcours plutôt solution de gestion, ERP. Et après, sur la BI, en fait, il y a une quinzaine d'années, nos clients, parce qu'il faut savoir qu'on travaille principalement pour eux, nos clients nous ont dit bah voilà c'est bien maintenant on a des solutions de gestion qui sont installés chez nous des comptes à des gestes comme des erp après c'est assez varié mais on a besoin de reporting on a besoin d' analyse de nos données parce qu'on prend toutes nos données déjà un seul endroit donc ça c'était déjà un bon pas en avant mais maintenant comment on les exploite et comme tout bon développeur on avait la solution pas de problème je développe le reporting que vous avez besoin sauf que ça leur donnait pas de souplesse Quand ils avaient une réunion avec un fournisseur ou avec un client, ils avaient besoin de quelque chose et ils n'avaient pas le temps d'attendre un développeur. En interne ou en externe, ils n'avaient pas le temps d'attendre qu'on leur développe un reporting. Et donc, du coup, ils nous ont dit comment on pourrait faire, puisque les éditeurs ne proposaient pas réellement de solution, comment on pourrait faire pour accompagner la décision plus rapidement avec des solutions. Et donc là, aux alentours de 2010-2012, je suis parti en quête d'une ou plusieurs solutions qui pouvaient répondre. Je rappelle, pour ceux qui se rappellent de ça, on avait des BO dans les grosses boîtes, mais pas tellement adaptées à des PME. On avait du Power Pivot dans Excel, pour ceux qui se souviennent, qui permettait de bidouiller un petit peu dans Excel, mais rapidement, ça implosait suivant les données, etc. Donc, ce n'était pas très stable. Et donc, du coup, il a fallu chercher des solutions. Il y avait des solutions qui étaient natives pour un ERP donné. Si on voulait agréger de la donnée venant d'autres solutions, il n'y en avait pas. Donc cette solution était très contrainte. Et donc il y avait quelques solutions. Et à l'époque, MyReport était déjà présent sur le marché. Si je ne dis pas de bêtises, ça faisait peut-être 5 ou 10 ans que ça existait encore avant, pour du reporting en Excel. Et ça répondait déjà à un premier besoin. Mais c'est surtout ce qui a attiré mon attention à l'époque, c'était justement cette simplicité d'usage. Et c'était d'arriver rapidement aux besoins du client sans technicité, en tous les cas, dans les grandes lignes.

• Speaker #0

  Super, merci. En tout cas, tu as dessiné un petit peu de comment c'était hier. Je pense qu'on passait de quelque chose de très artisanal peut-être au départ, et custom avec des systèmes forcément, puisque c'est artisanal, c'est très spécifique, difficile de couvrir le besoin et d'avoir cette souplesse en fait pour pouvoir répondre à l'évolution des besoins qui viennent. L'appétit vient en mangeant. On commence par un petit truc, un petit rapport. Au début, on fait ce qu'on peut avec ce qu'on a. Et puis, on arrive à des besoins plus grands. Donc, voilà, on a vu que tu as un petit peu beaucoup de consultants, si tu reconnaîtrais. On se débrouillait avec ce qu'on avait sous la main. Et puis, petit à petit, il faut industrialiser, il faut fiabiliser, il faut automatiser. Donc, effectivement, chez MyReport, c'est un petit peu notre... notre toute notre philosophie autour de faire quelque chose de simple mais en même temps qui reste industrielle qui reste fiable qui reste automatique pardon maintenant les attentes des clients c'est toujours la clé et du coup bah comment tu as géré le côté attentes et qui évolue parce que dans l'évolution de la posture du consultant Il y a aussi ces aspects-là.

• Speaker #1

  En fait, dans le positionnement, pour revenir sur le sujet du consultant BI, il a changé de forme parce que si on prend le consultant, je ne suis pas sûr qu'on l'appelait comme ça à l'époque, j'avoue, je ne me souviens plus trop, mais dans les années 2000, avant les années 2010, on avait vraiment des consultants BI ou data, etc., qu'on pouvait trouver dans des grosses structures, mais dans des structures à taille humaine, on parlait plutôt de développeurs. On avait un besoin, on développait ce besoin, on livrait ce besoin, mais ça se limitait à un besoin identifié. Quand on a réussi à mettre des solutions de BI, de décisionnel, parce que c'était ça, c'est de l'accompagnement à la décision, toute la donnée était centralisée plus ou moins dans les systèmes, mais on voulait les restituer pour accompagner à la décision. Et donc, à partir de 2010, entre 2010 et 2015, on a accompagné les PME. Je parle bien des PME, puisque c'est un vrai virage pour les PME. pour dire « j'ai la souplesse de répondre à un besoin quasi en un sens plané » . C'est-à-dire que j'ai un processus où le consultant BI va avoir besoin d'exprimer un besoin plus large qu'un simple reporting. Qu'est-ce que la PME, qu'est-ce que le client attend précisément dans toutes les fonctionnalités ou dans toutes les branches de l'entreprise ? On n'adresse plus simplement un reporting financier. ou un reporting pour un DG, on adresse une population en face et on va adresser toute cette population. Et du coup, avec des outils qui sont beaucoup plus adaptés. Power BI n'existait pas à l'époque. Il a fallu un peu de temps pour que Microsoft parte d'Excel et propose Power BI. Pendant ce temps-là, des solutions comme MyReport et autres, ont commencé à proposer des solutions qui étaient beaucoup plus adaptées. Et donc, le consultant est passé de développeur à quelqu'un qui est là pour comprendre le besoin du client. un besoin plus large et surtout qui se veut plus dynamique. Et donc, de dire, finalement, je ne construis plus un rapport, je construis un modèle de données qui est accessible aux clients pour le rendre autonome.

• Speaker #0

  Oui, la philosophie n'est pas du tout la même.

• Speaker #1

  Pas du tout, pas du tout. Le travail est différent. Là où le développeur, s'il n'avait pas passé le cap, il n'était pas capable de le faire. Et ceux qui ont passé le cap, ils ont pu comprendre ce besoin pour mettre en place ce qu'on appelle aujourd'hui... des data warehouse ou autres, des entrepôts de données en bon français, mais en tous les cas de dire, voilà, cet entrepôt de données, je l'ai constitué, je lui ai donné une intelligence, et je ne parle pas d'intelligence artificielle, je lui ai donné l'intelligence métier de mon client, et cette intelligence métier, elle peut lui être restituée quand il en a besoin, suivant le contexte. Et le métier, il a changé. Certains diront, oui, mais dans les grosses boîtes, on l'avait déjà. Bien sûr, on l'avait déjà. Pour quel prix et avec quel effort ? On développait en SQL. On avait des développeurs SQL qui développaient des cubes de données et ils passaient leur journée à développer. Alors que là, avec des solutions comme Agriport et d'autres, on passait de plusieurs jours ou dizaines ou centaines de jours de développement à une semaine, quinze jours, trois semaines, peut-être un mois de projet.

• Speaker #0

  Donc finalement, c'est une sorte de démocratisation de ce qui était avant accessible, donc en fait qu'il y a des grands groupes capables de mettre des budgets parfois faramineux dans ces projets-là, à quelque chose. de faisable aussi à l'échelle d'une PME.

• Speaker #1

  Et apporter de l'agilité. Et donc, le consultant BI a dû être agile. Là où il devait être organisé, normé, bien sûr, il doit toujours l'avoir, mais il doit avoir cette agilité à comprendre un besoin client urgent et de pouvoir le restituer, puisque le client, il n'est pas bête, il a un besoin rapide, il sait que la solution peut l'apporter, il ne va pas attendre trois semaines pour avoir son résultat.

• Speaker #0

  Bien sûr, la question au niveau de la problématique reste aussi cette question d'agilité, de ne pas non plus sortir des projets à six mois, un an. L'agilité est très importante, mais ça me ramène, ça me fait la transition avec la question des compétences clés. Effectivement, peut-être les compétences que tu avais besoin en tant que consultant BI à l'époque. Tu faisais un peu de développement, un peu de touche à tout. Aujourd'hui, ils ne sont plus les mêmes. Justement, sur ce côté un peu humain aussi, je dirais soft skills, c'est aux compétences, on va dire, humaines, pour ne pas encore faire de mémétisme. Je dis ça parce que je sais que Laurent est prêt à se chevaler sur le français. Alors, on va essayer de parler au bon français. Et donc, voilà, qu'est-ce que tu dis sur cet aspect-là pour les compétences et l'évolution des compétences ?

• Speaker #1

  Il y a eu un virage sur le consultant. On va parler de consultant technique BI ou consultant fonctionnel BI. Et c'est là où la différence se fait. Aujourd'hui, ça existe toujours. Il y a toujours des gros développements. Il y en aura toujours sur la partie data analysis. D'autant plus aujourd'hui, on en parlera plus tard avec ce qui nous attend demain. Donc, on a toujours besoin de ces développeurs. Un solution comme MyReport, si on n'a pas de développeur derrière pour développer la solution, certes, c'est plus simple à utiliser par le client, il a fallu la développer en amont. On a quand même besoin de ces développeurs, ces consultants techniques ou ces développeurs pour la partie BI, mais on a besoin de ces consultants fonctionnels, ces consultants métiers BI. Et là, du coup, de ce consultant BI, il y a bien sûr, il y aura toujours ceux qui sont à cheval entre les deux, qui connaissent la technique et qui font aussi le fonctionnel. Et tant mieux, c'est très bien. Mais aujourd'hui, on a la place aussi pour des personnes qui vont avoir une compétence plus fonctionnelle, plus métier, compréhension du besoin. Parce que si on comprend bien le besoin, on le restitue beaucoup mieux. Si on n'a pas compris le besoin, on peut être le meilleur développeur du monde, on n'y arrivera pas. Clairement. Donc du coup, finalement, le métier aujourd'hui, il est surtout dans la compréhension de ce que le client nous exprime. Et finalement, ce n'est pas que pour la BI, c'est vrai pour toutes les solutions de gestion. C'est vrai pour toutes les solutions en général. On a besoin de déployer une solution technique. C'est pareil, c'est la même chose, que ce soit une infrastructure, que ce soit... Ça sera toujours la même chose. Si on comprend le besoin, et c'est ça, bien comprendre le besoin, bien l'exprimer, et bien le traduire pour qu'ensuite, soit soi-même, en tant que consultant BI technico-fonctionnel, le mettre en œuvre, si c'est notre compétence aussi de le faire, on peut aussi le mettre en œuvre dans la foulée, ou le transmettre à ses collègues qui sont consultants techniques pour eux la mise en œuvre directement, ou alors... expliquer au client comment lui va le mettre en oeuvre dans sa propre solution. C'est-à-dire qu'on n'est plus là à prendre un besoin et à le restituer aux développeurs de l'équipe qui vont le mettre en oeuvre, puisqu'on est sur des solutions qui sont beaucoup plus agiles, beaucoup plus souples, orientées aux utilisateurs finales. Alors ça, on aime beaucoup le dire, mais utilisateur final, c'est qui ? C'est notre client. Et du coup, on prend un besoin, on explique au client comment il peut le faire, et il le fait tout seul. Il prend en pleine possession de son outil BIA. Oui,

• Speaker #0

  ça c'est un peu l'ultime. Mais effectivement, il y a quelque chose qui me paraît très important et souvent critique, c'est la partie storytelling. En fait, notamment quand on fait de l'analyse de données, la donnée raconte une histoire. Donc être capable de prendre ce recul, notamment avec le métier, pour voir, ok, mais c'est quoi l'histoire des données de mon client ? Pourquoi en fait cette histoire est importante pour lui ? Qu'est-ce qu'elle dit par rapport à son business ? à l'évolution de son métier par rapport à ses challenges, sa stratégie. Et ça, derrière, pouvoir le mettre de manière visuelle, le retranscrire avec tous les outils qu'on a, c'est quelque part une forme d'art, je dirais, de manière ultime. Parce que ce n'est pas forcément évident, mais c'est aussi une compétence. C'est-à-dire que, quelque part, l'idée, c'est de... Là, on arrive vers des choses qui sont... Plus dans l'ergonomie, dans... Quelle est la place, par exemple, de ça dans les projets ? Est-ce que tu as des exemples où ça a été important, ces aspects-là ?

• Speaker #1

  Je vais te donner deux exemples, sans forcément citer les clients, parce que ce n'est pas forcément important, mais je me souviens d'une démonstration de MyReport auprès d'un client et son équipe de développeurs internes qui faisait de la BI institutionnelle sur... SQL Server, etc., où la moindre demande prenait plusieurs jours de travail derrière. Et du coup, le fait de présenter une solution qui était plus agile et qui justement demandait des compétences différentes, ça refroidit l'équipe. forcément technique du client. Donc, il y avait le responsable financier, il y avait le directeur technique et il y avait deux personnes de l'équipe technique. Et on a senti ce malaise-là. Mais quand on leur a dit, écoutez, on fait exactement la même chose et demain, ce produit, plutôt que... Ce n'est pas nous qui allons l'intégrer chez vous, nous, on le déploiera chez vous, mais c'est vous qui allez le maintenir. Vous ferez juste un travail différent avec, effectivement, un certain nombre d'assistants. Alors, à l'époque, on ne parlait pas de l'intelligence artificielle, on parlait d'assistants. qui permettaient de simplifier les choses plutôt que d'aller coder tout à la main. Il y avait des accélérateurs, on va les appeler comme ça, qui permettaient justement d'aller plus vite.

• Speaker #0

  Rapunz, Drogund, enfin... Oui,

• Speaker #1

  c'est ça. Par des glissés-déposés ou par des formules qui étaient déjà intégrées dans l'outil et donc on gagnait du temps. Parce qu'il y avait des mécanismes. Comme je le disais tout à l'heure, il y a des développeurs qui avaient conçu cette solution pour que ça aille plus vite sur certains sujets. Par contre, ça n'enlevait pas la matière grise qu'on avait besoin. pour mettre en place une structuration de données, les bons index. Et là, on a besoin de cette technicité. Donc, le consultant, il a quand même besoin de cette compétence-là. Par contre, il y a cette évolution-là. Et donc, dans cet exemple-là, il faut… Et là, le consultant ou le chef de projet BI, en tous les cas, la personne qui va accompagner le projet BI, il doit avoir cette vivacité de dire « Attention, monsieur le client, vous allez prendre possession » et de dire… De ne pas laisser de côté une équipe interne, ce n'est pas parce que vous allez mettre une solution qui est plus ou moins assistée, plus ou moins automatisée, que ça remet en cause l'écosystème interne. Oui, peut-être qu'ils vont devoir changer un petit peu de casquette, etc. Mais leur rôle sera le même. Ils devront produire des reportings, mais ils les produiront plus rapidement parce qu'ils ont une solution plus évoluée. Et à l'inverse, des clients qui vont nous challenger sur le métier. C'est-à-dire que là, il faut avoir une case en plus. qui permettent de switcher. Je ne suis plus consultant technique BI, mais je suis métier. Et je bascule côté casquette métier. Alors, pas spécialiste, on ne peut pas être spécialiste dans tout. Moi, je ne suis pas spécialiste en paye. C'est bien un domaine que je ne connais pas, je ne maîtrise pas, on connaît les bases, mais ça s'arrête là. Mais par contre, il faut avoir cette capacité à comprendre, à bien capter le besoin. Si on n'a pas compris certaines choses, on échange avec le client. De toute manière, le client maîtrise bien son sujet. Il réexplique à la manière où nous, on pourrait expliquer un jeune qui vient dans le métier, etc. Donc ça, ce n'est pas un problème, l'échange se fait. Par contre, il va y avoir cette vivacité d'esprit aujourd'hui. Un consultant BI doit être à l'écoute du client, énormément à l'écoute du client. Et donc, du coup, pour être sûr de bien avoir cerné et bien orienté la solution, parce que bien des fois, finalement, une fois que le besoin est exprimé, la mise en œuvre, elle découle toute seule. Et maintenant, aujourd'hui, avec les solutions qu'on a sur le marché, je cite Power BI, il y a du tableau, MyReport, bien sûr, mais... Il y a plein, plein, plein, il y a pléthore de solutions qui sont assistées. Alors là, maintenant, on verra qu'il y a plein d'autres choses. Mais du coup, ça simplifie, mais ça simplifie uniquement si le besoin est bien exprimé, bien compris au débat.

• Speaker #0

  Il y a peut-être partie donc à un moment. Mais bon, justement, là, voilà, maintenant que la partie à un moment est bien établie, c'est-à-dire qu'on a cette démarche d'écouter le client, de comprendre. Il y a quand même beaucoup, beaucoup de choses. Ça offre quand même quelques défis. Aujourd'hui on est à l'époque de l'IA, du cloud, du big data, on a connu toutes ces toutes ces vagues un petit peu ces dernières années. Comment cela impacte un peu le quotidien des consultants et comment peut-être le gérer sereinement ? Je sais que tu es quelqu'un de très curieux, autodidacte, comment toi tu fais pour gérer un petit peu tout ça et qu'est ce que tu conseillerais peut-être à des consultants qui démarrent ou qui ont peut-être un peu plus d'expérience ?

• Speaker #1

  Alors déjà, avant l'IA, le cloud, je rappelle, c'est juste délocaliser son infrastructure chez un éditeur. Globalement, c'est ça. C'est parce qu'il y a toujours eu le cloud un peu partiel, où on déplaçait simplement, au lieu de le mettre chez soi, on le mettait chez un prestataire qui hébergeait notre solution. Mais bien sûr, on était en cloud parce que ce n'était pas chez nous. Mais aujourd'hui, on est sur des solutions hébergées éditeurs. Ce qui est fondamentalement différent, parce que contrairement à l'époque où on était en ce qu'on appelait le PAS, Platform as a Service, c'est-à-dire qu'on mettait à disposition la plateforme en SaaS, mais on pouvait toujours accéder à la base de données, traditionnellement. Si c'était une base SQL, on pouvait toujours attaquer la base SQL, puisque la base SQL nous appartenait et donc on pouvait le faire même si c'était chez un tiers. Là, aujourd'hui, ce n'est plus possible. Et donc là, aujourd'hui, on a depuis beaucoup d'années, parce qu'il y a beaucoup d'éditeurs qui sont orientés sur le cloud, le vrai cloud à part entière depuis longtemps. On a eu un challenge, c'est de dire, à l'époque, on adressait quelques acteurs de base de données, mais il n'y en avait pas tant que ça. En gros, soit on attaquait du SQL, soit on attaquait du Oracle, on avait quelques moteurs de base de données un petit peu open source, mais globalement, c'était très normalisé et on avait toujours un peu les mêmes règles. Et bien sûr, évidemment, on attaquait toujours du fichier plat, Excel ou autre, et ça, il y en a toujours aujourd'hui. Est-ce qu'on n'en aura plus demain ? Je ne saurais pas dire, mais dans tous les cas, on en a toujours. par contre aujourd'hui le fait d'être en sas c'est complètement différent On n'attaque plus de base de données, on attaque un API. Alors, on l'appelle différemment. Certains l'appellent web service, API, connecteur, ce que l'on veut. Mais fondamentalement, c'est différent parce que là, on n'attaque plus une base de données où on va avoir une liste de tables. Là, on va attaquer un processus qui est documenté et qu'on doit attaquer d'une certaine manière. Et là, l'éditeur a sa propre documentation. On peut avoir des grands standards, Odata, JSON, etc. Mais derrière, la documentation, elle est différente éditeur par éditeur. Et donc là, le consultant... technique, donc là on remet sa casquette technique, doit comprendre ces points-là. Donc là, il y a certains éditeurs qui ont déjà bien documenté les choses, il y en a d'autres, oui, ils ont dit, bon voilà, j'ai mon API, mais finalement l'API ne fait pas grand-chose. Après, il y a des soucis de performance. Ce qu'on était capable de faire sur des volumes de données importants en on-prem et ce qu'on est capable de le faire chez l'éditeur en SaaS, etc. Donc là, il y a une mise en œuvre technique qu'il ne faut pas négliger sur les projets. Et quand on a ce besoin que j'expliquais tout à l'heure, exprimé par le client c'est bien d'identifier toutes les sources parce qu'aujourd'hui même quelqu'un qui a un erp qui a une solution de paye bien souvent on se retrouve chez le client avec deux trois voire quatre solutions de gestion différentes la paye et en général la paye et l'erp sont rarement au même endroit on peut avoir une solution budgétaire ou trésorerie externalisée voilà donc on va voir peut-être trois quatre solutions qui transitent autour de l'ERP et donc du coup, la solution BI va avoir besoin de se connecter sur chacune de ces branches-là et donc peut-être avec des règles de gestion différentes et donc des implémentations qui ne sont pas forcément évidentes à faire par le client et c'est là où le rôle du consultant BI, il est là, bien accompagner le client, bien traduire ça techniquement en fonctionnel et après, une fois qu'il a mis à disposition la donnée, c'est plus facile pour le client pour l'utiliser.

• Speaker #0

  Donc ouais, peut-être un peu plus de technicité.

• Speaker #1

  Clairement, là, on retombe dans la technicité. l'outil va donner de la souplesse au client Une fois que la connexion est opérée dans l'outil de BI, mais tant qu'on n'a pas opéré cette connexion technique, à moins d'avoir des vraies compétences, comme je donnais l'exemple de tout à l'heure du client qui avait une équipe technique interne, où là, ils peuvent être autonomes, il n'y a pas de sujet. Mais par contre, si le client n'a pas d'équipe technique, je rappelle dans des PME, on n'a bien souvent même pas de RSI, de responsable informatique ou quoi que ce soit. On a un directeur financier, on a un contrôleur de gestion qui a un besoin BI et au mieux il a un responsable Quelqu'un qui est chargé de l'informatique en interne, mais bien loin des problématiques de data, puisque la data, on en parle avec la RGPD ou d'autres choses, on doit gérer la donnée de l'entreprise. Oui, cette donnée, du coup, il faut aller l'adresser. Il faut des compétences techniques.

• Speaker #0

  Oui, donc OK. En fait, il n'y a pas 36 000 solutions, avec la multiplication de tout panorama des solutions, des nouvelles manières de se connecter à la donnée. plus de technicité, donc il faut suivre un petit peu sur ces aspects.

• Speaker #1

  Il faut se maintenir à jour.

• Speaker #0

  Mais effectivement, il y a quelque chose que tu as un petit peu abordé, c'est ce côté un peu… T'as l'air, ce côté qu'on travaille en équipe aujourd'hui. Et effectivement, c'est difficile d'être bon partout, de maîtriser… Même si je pense que le consultant BI, vu qu'il est un peu à l'habitude de travailler dans un contexte hétérogène… va forcément avoir un peu une culture de plein d'outils, de solutions, etc. Mais des fois, moi le premier, ça m'est déjà arrivé, la PI est très exotique, ils ont fait un système d'authenticité qui n'est pas forcément standard, et effectivement, on se retrouve bloqué avec… certains consultants se reconnaîtront avec « tiens, moi je n'arrive plus à me connecter à ça, ou comment on fait ? » Donc c'est aussi ça les challenges que ça offre.

• Speaker #1

  et puis La BI, on pense l'adresser souvent sur des sujets, ou la data analysis, sur des sujets gestion commerciale, comptabilité, finance, tout ce qui transite autour de la solution de gestion. Mais on en oublie tout l'autre écosystème qu'on aborde rarement. Par exemple, combien de clients aujourd'hui analysent les données de leur serveur Exchange pour savoir les entrées, les sorties, est-ce que les licences sont bien gérées, etc. Aujourd'hui, bien sûr, les éditeurs, quand on est chez Microsoft, ils donnent un certain nombre d'outils. Mais aujourd'hui, il y a des clients qui analysent leurs données qui sont très techniques. On va adresser, par exemple, des plateformes de phoning qui vont dire combien j'ai décroché d'appels, pas d'appels, etc. Ce n'est pas forcément dans l'outil de CRM, ce genre de choses. Des fois, c'est dans l'outil technique, dans le serveur téléphonique que l'on va récupérer toutes ces infos ou dans le serveur Exchange dans lequel on va recevoir, dire voilà. J'ai reçu tant de mails, quelle est la volumétrie d'emails que j'ai traité par jour, par semaine, etc. Donc, on est sur de la donnée très technique. Et donc, c'est pour ça que le consultant BI, lui, va avoir besoin. de changer rapidement de sujet, mais effectivement, on ne peut pas être expert dans tout. Et donc, il y a un moment, on doit être accompagné. On peut être accompagné. Moi, je me fais régulièrement accompagner par mes collègues de l'équipe infra. Quand ça touche à des sujets, la dernière fois, on travaillait avec un serveur Exchange. Même si c'était de l'Exchange Online, oui, bien sûr, il y a des requêtes PowerShell. On peut faire beaucoup de choses avec Exchange Online. Énormément d'outils à l'admin. Mais moi, avec mes connaissances IT, j'ai pas pléthore de connaissances là-dessus. J'ai mes limites et on se fait accompagner d'experts à côté et ça n'empêche. On garde sa casquette consultant BI, mais on se fait accompagner de vrais experts de la même manière. Demain, on ne peut pas s'inventer expert en recouvrement ou quoi que ce soit. Donc, voilà.

• Speaker #0

  C'est important de rester un petit peu ouvert. Ce qui ramène aussi à la question des tendances. Aujourd'hui, on a un petit peu dessiné, de quelque chose. plus ou moins artisanale, à des solutions de plus en plus mature. Plus à buter. Oui, la question que j'ai envie de te poser c'est quel est le futur ? En fait les challenges, peut-être c'est un exercice qui n'est pas forcément évident, mais comment par rapport aux tendances actuelles, les problématiques qu'on peut avoir aujourd'hui, parce qu'aujourd'hui on a aussi des problématiques de saturation des fois, les systèmes commencent à être matures, même dans une PME, le serveur est bien dimensionné. Et du coup, comment évoluer, enfin comment tu vois le consultant BI évoluer pour traiter ces problématiques dans les cinq, peut-être dix prochaines années, ça fait peut-être un peu beaucoup, beaucoup de choses en dix ans qui peuvent se passer, mais comment toi tu le vois ? Je sais que la question n'est pas facile.

• Speaker #1

  Alors il y a deux points qui sont très différents. il y en a un, c'est... La volumétrie des données. Ça fait quand même de nombreuses années maintenant. Alors bien sûr, il y a toujours encore des PME qui ne sont pas dotées, mais ça viendra. Mais la volumétrie des données centralisées, ça fait longtemps qu'on en parle. Depuis les années 2000 et même avant, les sociétés étaient déjà dotées de systèmes centralisés de données. On appelle ça ERP, PGI, qu'on appelle ça une solution comptable et financière. Mais en tous les cas, ils avaient déjà centralisé leurs données. Et donc, ils ont... une volumétrie d'historique très importante dans ces solutions de gestion. Aujourd'hui, la BI, chez certains clients, on adresse des milliers, des millions, voire plus pour des PME, de données par an. Beaucoup de PME ont plusieurs millions de données par an à analyser. Donc si on compare N, N-1, N-1, on commence à avoir des volumétries. Donc il faut aussi, et c'est là la valeur du consultant BI, challenger le client sur son besoin d'avoir et est-ce qu'il en a réellement besoin à l'image de dans tout projet BI on a sûrement parlé avec d'autres partenaires mais mais mais le nombre de fois où le client dit ah si j'ai besoin de toutes ces colonnes j'ai besoin de tout ça etc mais quand on challenge on le pousse mais finalement on se rend compte qu'il en utilise 10% donc pourquoi ne pas construire vraiment ce qu'on a besoin puisque l'objectif c'est que 1 la BI réponde à mon besoin. 2. Que ce soit rapide à obtenir. Si le client est obligé d'attendre une éternité pour que le reporting se finalise, finalement on fait un pas de 10 ans en arrière, on faisait ça dans Excel avec ses SOM6 et ses recherches V, tout le monde s'y retrouvera, et où le fichier pesait des mégas et des mégas pour ne pas dire plus, et que ça mettait trois plombes pour quand ça ne plantait pas. Et donc là l'objectif c'est d'avoir une solution qui est rapide, qui est pertinente en résultat, plus on met de données, plus on la remet en question, plus la donnée est claire et... et qu'on a bien construit au départ, ça, c'est fait. Et donc, c'est important de préparer, quand on met un projet, de tout de suite mettre en place uniquement l'historique dont on a besoin. Ce n'est pas la peine de garder 10 ans dans sa BI. À tout moment, on est capable de le constituer si on a besoin. Par contre, on a des contextes, il y a des clients qui disent « Ah oui, mais j'arrête mon ancien système, je voudrais injecter dans ma BI mon historique pour éviter de garder mon ancien URP. » Pas de problème, on peut le faire. On fait une base statique à un endroit, on la stocke, et puis on viendra l'interroger au besoin.

• Speaker #0

  mais il n'y a pas besoin de faire un OTL toutes les nuits ou des choses comme ça parce que souvent quand on est face notamment à des cas où il n'y a pas eu forcément cette réflexion et que le consultant arrive et que là il pose au client de quoi vous avez besoin la réponse c'est tout je veux tout Et le risque, surtout, c'est que le consultant et le client, surtout après, derrière, soient mécontents de la solution. Ce qui est dommage, puisque la solution ne fait qu'évoluer vers le mieux. C'est-à-dire qu'elle va apporter plus de fonctionnalités. Mais si la volumétrie augmente, si les capacités, on est obligé d'augmenter les serveurs, etc., ça a un coût. Pour derrière, un delta, finalement, de gain qui n'est pas si important. Alors que si derrière, on faisait un travail... Je ne vais pas dire intelligent, mais un travail de préparation de données plus constitué, plus raisonné, derrière, le client voit au quotidien le gain qu'il a, il voit toujours les nouvelles données. Et l'autre point sur le demain, en fait, on a déjà un pied dedans. C'est-à-dire aujourd'hui, qu'est-ce qu'on attend demain de la BI ? C'est finalement demander à la BI elle-même de me sortir le reporting sans passer par un tiers. Je sais qu'il y en a qui n'aiment pas ça. Mais ce n'est ni plus ni moins que l'usage de l'IA, c'est-à-dire qu'aujourd'hui, il existe déjà des outils où on écrit, où on parle, et où on a le résultat escompté. Eh bien, c'est ni plus ni moins que ça, c'est qu'aujourd'hui, les premiers outils de BI existent déjà sur ce périmètre-là, où on va écrire ce que j'ai envie en toutes lettres, en disant « j'ai besoin de mon chiffre d'affaires par client n n-1 » . avec un tel, etc. ou j'ai besoin d'une projection prévisionnelle de mes ventes basées sur l'année précédente et le système va me proposer le reporting.

• Speaker #1

  Alors du coup, qui du consultant BIA ? Parce que le consultant, lui, maintenant, il va avoir un client qui va avoir une IA. Bien sûr. L'IA va demander peut-être au système décisionnel qui est là, où il y a les données sans structurer. Ça, c'est déjà l'avantage quand on en a un. Parce que l'IA, il ne faut pas se faire d'illusions. Comme disent les américains, cheat in, cheat out. Donc si les données ne sont pas déjà propres, structurées, etc., c'est difficile d'attendre quelque chose de qualitatif et de pertinent de la part de l'IA. Quel est le rôle maintenant du consultant ? Est-ce que ça va être une sorte de submettre de l'IA pour venir à peu près préparer les choses ou à former les utilisateurs finitiers ?

• Speaker #0

  Le consultant BI, il sera toujours là. Je rappelle, quand on revient aux années 2000 ou même avant, ceux qu'on connut, on était des purs développeurs. On faisait de la technicité à 100% et très peu de besoins métiers. On avait des grands chefs de projet, des grands directeurs de projet qui faisaient le besoin, ils ne connaissaient rien à la BI, ils redescendaient le besoin, on faisait le développement et on livrait. Il a fallu changer de casquette. Quand on est devenu consultant BI dans les années 2010, là il a fallu changer de casquette. Il a fallu se mettre en frontal avec le client, on ne passait plus par un directeur de projet puisqu'on parlait en direct, il fallait comprendre le besoin. Demain, je vais devoir changer de casquette. C'est-à-dire que si le client est capable de restituer son rapport directement, finalement il n'a plus besoin de nous pour le faire, en dehors de support ponctuel. Ok, je suis consultant support BI, très bien, je réponds à des besoins ponctuels du client. Eh bien, ça sera à nous de faire en sorte que le moteur derrière fonctionne correctement et soit pertinent et d'ajouter de nouvelles fonctionnalités à ce moteur. C'est-à-dire que l'IA, c'est une chose, mais je rappelle que l'IA n'existe que parce qu'on l'a nourri de quelque chose. Si on la nourrit des bonnes choses, finalement, elle nous restitue normalement de bonnes choses. Mais si on met un peu tout et n'importe quoi, c'est ce que je disais tout à l'heure, on met toutes les colonnes de la Terre, on n'a pas ciblé, etc. Bien sûr, il a beaucoup de données. Mais plus il aura de données, plus derrière, il y aura des résultats qui seront approximatifs. Alors que si on a bien ciblé, donc on va devoir changer un petit peu de casquette. On aura toujours de l'accompagnement au changement. Ça, c'est important. Quand on va amener une solution, quelqu'un qui est déjà équipé, on va l'accompagner au quotidien. peut-être des mini-projets complémentaires, donc on va continuer à l'accompagner. Mais quelqu'un qui aura besoin de déployer cette solution chez lui, il va falloir l'accompagner. De quelqu'un qui n'avait rien, ou qui avait encore des fichiers Excel, ou un outil de BI très manuel, et quelqu'un qui va devoir utiliser un outil qui sera quasi automatisé, il va falloir l'accompagner, il va falloir accompagner les équipes, les former pour qu'ils soient autonomes dessus, et satisfaits de la solution, et surtout être sûr que le modèle qui se trouve derrière, de toute manière, ça a toujours été le cas. Si on remonte avant 2000, En 2010 ou aujourd'hui, c'est toujours la même chose. Si mon modèle de données initial n'est pas bon, on peut faire le reporting que l'on veut, il ne sera pas bon. Donc voilà, notre métier, demain, il sera toujours de maintenir cet écosystème technique derrière. Alors derrière, peut-être que les éditeurs vont se placer, et peut-être que du coup, les consultants BI, est-ce qu'ils resteront dans des intégrateurs SI, ou est-ce qu'ils vont migrer chez les clients, ou migrer chez les gros éditeurs ? Sans doute qu'il y aura une migration, mais il faudra bien évoluer dans notre métier.

• Speaker #1

  Tu penses qu'il faudrait un permis de conduire pour devenir consultant de BI ? Parce que beaucoup se sont retrouvés dans le métier par la force des choses, j'ai envie de dire, avec l'expérience, les appétents se sont découverts consultants de BI. Est-ce que demain, ça sera encore possible ?

• Speaker #0

  Il y a deux choses. Un, on manipule la donnée du client. Ça, ce n'est pas neutre, parce qu'on est responsable de la donnée du client. Il y a une question d'un aspect sécuritaire, un aspect confidentialité, etc. Donc ça, c'est inhérent à tous les intégrateurs, conseils, en solution de gestion, pas que la BI, c'est vrai dans les ERP, c'est vrai dans les logiciels comptables, etc. Donc, on est garant de cette donnée, et ça va plus loin. Quand on construit ce modèle de données, on est garant que le résultat est conforme. Parce qu'on prend un ou plusieurs systèmes à mon, on vient les mettre dans un modèle de données, mais si on fait n'importe quoi, c'est pire que bien. Donc ça, c'est déjà un premier aspect. L'autre aspect, il est déjà cadré, plus ou moins, par les éditeurs. Je dis plus ou moins puisque certains éditeurs le font et d'autres non. On appelle ça certification, on appelle ça formation éditeur, on appelle ça comme on veut. Mais en tous les cas, aujourd'hui, ce sont les éditeurs de ces solutions qui font en sorte, ou qui devraient faire en sorte, que leur consultant interne ou externe ait les bonnes compétences et les bonnes impédances pour le faire. Et donc, du coup, ça peut passer par une certification. Mais en tous les cas, il y a forcément une bonne pratique. Comme quand on met en place un projet, il y a une méthodologie. On peut les appeler comme on veut, mais c'est toujours globalement les mêmes règles. C'est pareil. Quand on va mettre un projet BI, c'est ni plus ni moins qu'un projet informatique. Et il y a un certain nombre de règles et un certain nombre de jalons à respecter. Et ça peut s'apprendre. Ce n'est pas inné. Ça peut être inné pour certains, mais ça peut s'apprendre. Donc, ce n'est pas un problème. Quelqu'un qui voudrait faire ce métier-là, ça s'apprend. Et puis après, derrière, ça se met en œuvre dans les bonnes pratiques. Et donc, ça sécurise à la fois le processus et, bien sûr, en parallèle de la sécurité des données.

• Speaker #1

  La certification, c'est chez MyReport. C'est quelque chose qui est très important parce que justement on tient à ce qu'il y ait une certaine maîtrise des projets. On sait très bien que c'est critique les systèmes qui permettent aux chefs d'entreprise de décider d'avancer ou aux opérationnels, sans arriver aux chefs d'entreprise pour mener leur activité, s'ils ne sont pas bien conçus, mène à des décisions qui sont erronées parce que les données n'étaient pas... pas bien structuré ou je ne sais pas quel problème, l'impact n'est pas anodin.

• Speaker #0

  C'est important parce qu'en fait, on ne vend pas une boîte de logiciels qu'on installe et puis on s'en va derrière. Il y a une certaine compétence à avoir et c'est la grosse différence que l'on a entre des éditeurs qui ont, on dit, qui ont pignon sur rue, mais qui ont une vraie organisation, une vraie méthodologie d'implémentation. et accompagnement de leurs partenaires, et des solutions, il en existe beaucoup, open source, où les clients peuvent développer eux-mêmes les solutions chez eux parce qu'ils existent. Mais sauf qu'entre les deux, entre une solution open source qui n'est pas forcément cadrée, qui est parce que c'est une communauté qui fait vivre une solution, oui, mais derrière, il n'y a pas de certification, il n'y a pas d'accompagnement, des fois pas de support en tant que tel. Et donc, c'est ça aussi, cet accompagnement que certains éditeurs mettent en place comme MyReport, c'est que derrière il y a Bien sûr, la certification, mais il y a l'accompagnement des partenaires et aussi la validation ou pas du partenaire. C'est-à-dire que si un partenaire n'est pas compétent, Mary Pop peut très bien dire, non, il faut rebucher ça, il faut refaire ça et vous n'êtes pas prêt à implémenter les projets. Parce que c'est important vis-à-vis des clients, parce qu'encore une fois, on travaille pour nos clients et si nos clients ne sont pas satisfaits, déjà pour nous, ce n'est pas valorisant et puis deux, pour l'éditeur, encore moins. C'est pour ça que c'est important et c'est pour ça que je comprends que certains éditeurs mettent en place un certain... cursus spécifique pour ses partenaires ou ses propres consultants en interne, puisque vous, c'est votre cas aussi.

• Speaker #1

  Bien sûr, on a abordé pas mal de sujets pendant ce podcast. Merci beaucoup, Laurent. Moi, il me reste une question, peut-être une question encore plus ouverte. Est-ce qu'il y a une question que tu aurais aimé que je te pose, que je ne t'ai pas posée, ou un sujet qui te tient à cœur, que tu aurais apprécié qu'on aborde ? et qui pourrait être utile aussi à nos consultants, à notre communauté et à nos auditeurs.

• Speaker #0

  C'est plus pour des gens qui écouteraient le podcast et qui ne seraient pas forcément dans le monde, c'est pourquoi devenir consultant BI ? Et le pourquoi, il est dans la richesse des échanges que l'on a au quotidien. C'est-à-dire que c'est un métier où tous les jours, on apprend de nouvelles choses. Hier, on a mis un projet. technique et fonctionnelle en place. Demain, on va avoir un autre client, on va avoir un autre sujet qui va arriver. qu'on maîtrise ou qu'on ne maîtrise pas, mais c'est un sujet qu'on va amener à terme parce qu'on va se donner les moyens, pas seul, encore une fois, à ce que je disais, et c'est ce que tu disais tout à l'heure, on travaille en équipe, mais on va apprendre énormément de choses. Contrairement à certaines solutions, alors moi je vais rester sur les solutions de gestion qui ont un cœur de métier, quand on est spécialiste finance, on fait un petit peu, même si c'est partiellement vrai ce que je dis, on est quand même dans un cocon qui est très, très... Et donc du coup, avec... Peu de variations, bien sûr, un jour on va faire un peu de trésor, un jour on va faire ci. Alors que là, comme je disais, le consultant BI, demain il va analyser de la donnée sur les Jeux Olympiques 2024 qui ont eu lieu à Paris pour savoir quels ont été les retombées économiques pour la ville de Paris, pour la France, etc. Ou demain il va passer, il a un client, il a des problèmes de recouvrement de trésorerie, il va falloir l'accompagner à améliorer ça parce que son entreprise est en risque. demain il va aller analyser du chiffre d'affaires, il va analyser des prévisions, voilà on va avoir vraiment de la donnée purement technique, analyse technique etc. Donc on va vraiment avoir une diversité de métiers et c'est ça qui est très riche dans ce métier de consultant BI et qu'on soit technico ou fonctionnel ou les deux.

• Speaker #1

  Je comprends très bien la question du sens en fait, de quel sens on y met, c'est un petit peu… peu à la question centrale. Je pense que effectivement, pour évoluer, ça fait longtemps que tu fais ce métier, que tu es dans le domaine. Je pense que le sens qu'on y met est très important. Moi, je peux parler aussi un petit peu de mon expérience, ayant toujours été très curieux de nature, et voilà, même, je dirais, insatiable sur plein de sujets. Il n'y avait pas cette diversité qu'on peut avoir dans ce métier-là, et tout ce qui gravite autour. Je pense que c'est quelque chose que je n'aurais pas creusé. Donc effectivement, je pense que la question du pourquoi, en fait, de venir consulter en BI ou pourquoi s'orienter dans ça est essentielle. Et voilà, merci d'avoir abordé ça. En tout cas, encore une fois, merci de ce moment de partage. J'espère que nos auditeurs vous auraient apprécié ce moment-là. Alors... Voilà, Laurent fait partie de la communauté MyReport, mais l'un de l'autre, il ne fait pas que ça. Si on veut te contacter, est-ce que tu es sur une plateforme, un réseau ?

• Speaker #0

  Bien sûr, sur LinkedIn. Oh, par mail, LinkedIn. Sur LinkedIn, de toute manière, que ce soit sur mon profil LinkedIn, Laurent Buisson, ou sur la page BCSYS, ou sur le site Internet, simplement, et vous tomberez assez rapidement sur moi, mais sinon en direct sur LinkedIn aussi.

• Speaker #1

  Super, je mettrai aussi les contacts de la page de BC6 et le profil de Laurent pour ceux qui souhaitent le contacter. Merci encore. A bientôt pour un nouvel épisode de notre podcast sur toutes les plateformes et les réseaux.

• Speaker #0

  Au revoir.