Marc 00:00:00 – 00:00:14 : Aujourd’hui, je reçois Antoine Buat, dirigeant de DigDash. DigDash est une société française basée à Aix-en-Provence depuis 2007, éditrice d’un logiciel de business intelligence. Bonjour Antoine. Bonjour. Alors, est-ce que tu peux nous présenter un peu plus DigDash, Antoine ? 

Antoine 00:00:14 – 00:00:37 : Alors effectivement, on est éditeur de logiciels entièrement basé à Aix et fondé sur fonds propres. Donc ça, c’est important à comprendre aussi. Une société française avec des concurrents qui sont principalement des concurrents américains. On a beaucoup de concurrents dans le domaine de la BI. Donc notre but, c’est effectivement l’analyse de données pour nos clients. Et on est un peu plus de 60 personnes basées à Aix-en-Provence. On a aussi un bureau à Madrid, mais qui est de beaucoup plus petite taille. 

Marc 00:00:37 – 00:00:41 : Vos clients types, qui sont vos clients types ? 

Antoine 00:00:41 – 00:01:28 : Alors on a beaucoup de diversité dans nos clients. On a à la fois du secteur public et du secteur privé sur des typologies de comptes assez variées. Dans le secteur privé, on va avoir du retail, de la logistique, de l’industrie, de la finance. Et du côté public, pareil, c’est assez varié aussi. On tape à la fois dans les ministères, les collectés de toutes tailles, régions, départements, communautés de communes, des grandes villes. Donc on a vraiment une diversité de clients et de fonctions chez nos clients qui sont assez importantes. Par contre, ce qui les caractérise tous, c’est qu’ils ont besoin de manipuler de la donnée et c’est également qu’ils ont une taille suffisamment importante pour avoir besoin de nos outils. Donc on ne s’adresse pas à la petite PME ni à l’ETI, ce n’est pas notre but, ce n’est pas trop notre… Il faut du volume. Exactement. 

Marc 00:01:28 – 00:01:37 : Alors pourquoi avoir créé un outil de BI ? Quel était le besoin repéré ? Quel était le point non adressé par ce qui existait à l’époque du coup ? 

Antoine 00:01:37 – 00:02:18 : Alors ce qu’il faut comprendre, c’est qu’effectivement, je ne l’ai pas cité en introduction, mais DigDash a été fondé par trois anciens business objects. Donc la BI, c’est quelque chose qu’on connaît depuis longtemps, puisque BO, c’est l’un des premiers outils français, d’ailleurs, de business intelligence, qui était à l’époque concurrent avec Cognos, qui ont été chacun rachetés, l’un par IBM et l’autre par SAP. Et le problème de ces outils un peu anciens, c’est qu’ils sont basés sur des générations différentes de hardware, de contraintes, et que donc aujourd’hui ne sont absolument plus adaptés aux besoins des utilisateurs. Donc nous, on s’est dit qu’il y a besoin d’un produit différent, plus simple, plus efficace, mais quand même qui répond à ces critères d’entreprise. C’est-à-dire qu’on veut quand même organiser l’information, on veut être capable en tant qu’entreprise d’avoir une vision complète sur l’ensemble de ces données. 

Marc 00:02:18 – 00:02:27 : Et par rapport à des solutions plus récentes, comment est-ce que vous vous différenciez ? Par exemple, je pense à Looker ou à Metabase. Quelle est votre particularité ? 

Antoine 00:02:27 – 00:03:50 : Oui, c’est un bon point de comparaison. Alors nous, les compétiteurs qu’on voit le plus souvent sur notre marché, c’est plutôt quand même Microsoft Power BI, numéro un. C’est ensuite Tableau et ClickView. C’est plutôt les trois gros qu’on retrouve. Looker est un peu moins présent en France. On le retrouve plus sur le marché Amérique du Sud et américain, mais beaucoup moins sur le marché français. On a un certain nombre de différences. Et nous, il y a un point sur lequel on insiste assez fortement. C’est ce qu’on va appeler la souveraineté de données. Donc c’est où est-ce qu’on met ces données, où est-ce qu’on les héberge pour avoir une garantie que personne d’autre que nous va pouvoir y accéder. Donc ça, je pense que c’est un point différenciant clé. Alors on fait du on-prem, bien sûr, certaines solutions le permettent, mais par exemple, dans Microsoft Power BI, on ne peut pas faire de on-prem, enfin en tout cas pas avec le même niveau fonctionnel que ce qui est dans le cloud. Donc ça veut dire qu’on embarque ces données directement dans un cloud américain, avec toutes les contraintes et sécurités que ça implique. Nous, on a décidé d’avoir un partenariat quand on est dans le cloud avec OVHcloud, qui est notre numéro 1 en termes de choix de sélection d’hébergeurs. On travaille aussi un petit peu avec Outscale. En tout cas, ce sont deux clouds qui ont les normalisations Secnum Cloud. Ça veut dire qu’effectivement, par l’ANSI, ils ont été normalisés, comme quoi leur processus respecte bien cette sécurité de données en termes de… Ça peut être physique, l’intrusion dans les data centers, comment ça se passe, mais aussi d’un point de vue sécurité informatique, comment je mets en place des solutions de sécurité informatique pour protéger mes données. 

Marc 00:03:51 – 00:04:16 : Ok, très clair. Alors, si on rentre un peu plus dans le métier business intelligence, donc on pourrait le définir, l’analyse des données business et essayer de récupérer des insights, prendre des décisions à partir des données. Est-ce que tu peux rentrer un peu dans le détail des usages de la BI, si tu devais segmenter les usages ? Qui fait appel à ça ? Quelles fonctions d’entreprise font appel à ça ? 

Antoine 00:04:16 – 00:05:51 : Alors effectivement, on peut segmenter, on l’a fait nous dans notre produit déjà pour des principes simples d’avoir une interface utilisateur adaptée à l’utilisateur qui va utiliser le produit. Mais par contre, on ne l’a pas segmenté nécessairement par métier. C’est-à-dire que ce qu’on constate, c’est que tous les métiers qui manipulent de la donnée, c’est-à-dire à peu près tous les métiers, ont besoin d’un outil de business intelligence dans une forme ou une autre. Nous, on a catégorisé trois grandes formes d’usage. Le premier usage, c’est ce qu’on appelle le pilotage. Le pilotage, c’est juste avoir des indicateurs de manière plus ou moins condensée pour qu’un décideur puisse en un clin d’œil avoir une vision éclairée d’où en est son business. Deuxième usage, c’est déjà ce qu’on appelle exploration. j’ai une masse de données et je veux être capable de rentrer dans le détail, dans des axes d’analyse, de filtrer par tel ou tel élément, de rentrer, ce qu’on appelle de driller dans les données, rentrer dans le détail de l’information pour comprendre comment cet indicateur est arrivé à cette position-là. C’est vraiment rentrer dans cette capacité d’analyse. Et puis enfin, le dernier usage que l’on constate chez nos clients, c’est un usage qu’on appelle data communication. chez nous, c’est cette capacité à partager de l’information avec des gens qui ne savent pas nécessairement de quoi on va leur parler. Et en fait, ça, si je leur fournis juste un tableau ou des chiffres, ce n’est pas suffisant. Il faut être capable d’accompagner ces représentations visuelles, tableaux ou graphiques, avec du texte explicatif autour de la donnée. Aujourd’hui, ces insights sont plutôt générés par l’utilisateur lui-même du tableau de bord, donc il va produire des insights et donc générer son tableau de bord. on imagine dans la suite qu’effectivement l’IA va l’accompagner pour l’aider à générer ses insights. Alors l’IA, ça ne veut pas forcément dire LLM, peut-être qu’on en parlera tout à l’heure de manière plus détaillée, mais ce n’est pas forcément le sujet principal pour nous. Il y a d’autres méthodes que le LLM pour générer de l’insight, notamment sous forme textuelle. 

Marc 00:05:52 – 00:06:04 : Oui, alors peut-être que c’est un bon moment pour en parler. Qu’est-ce que les évolutions récentes de l’IA ont changé finalement à votre business ? Et qu’est-ce qu’on peut faire avec de l’IA dans le cadre d’un éditeur de logiciels de BI ? 

Antoine 00:06:04 – 00:08:23 : Oui, alors l’IA au sens large du terme existe depuis longtemps. Je pense qu’on partage ce point de vue. Il y a plein de méthodologies d’IA qui sont encore applicables. Ce n’est pas parce qu’il y a aujourd’hui un raz-de-marée du LLM et de ce qu’on peut faire avec. Et je trouve ça super d’ailleurs ce qu’on peut faire avec. Il y a vraiment des vrais avantages. Mais c’est vrai qu’au-delà d’écrire un poème dans ChatGPT, quelles sont les applications business ? Écrire un poème, ce n’est pas une application business. C’est bien d’avoir ces modèles larges, c’est bien d’ailleurs qu’il y ait des sociétés, notamment françaises, qui s’occupent de ça. Je pense à Mistral AI, par exemple, qui fournit en plus en open source ces modèles, donc c’est génial pour nous. Parce que ce qu’il nous reste à faire, c’est la dernière couche, c’est-à-dire le fine-tuning, le paramétrage de… du modèle pour un champ d’application spécifique. Et ça, je pense que c’est la responsabilité de chacun des éditeurs logiciels de faire ce paramétrage-là. Ils nous fournissent un modèle, c’est génial, on n’a pas besoin de dépenser des centaines de milliers de dollars dans l’acquisition de GPU, on peut juste faire la dernière partie, le fine-tuning, pour préparer effectivement ces modèles-là au champ applicatif de nos clients. Donc là, effectivement, moi je dis, il y a un intérêt, ce n’est pas de générer des poèmes pour nous, mais c’est de générer des choses qui vont interagir avec nos logiciels de manière plus intéressante. Avant ce système de LLM, on avait déjà le requêtage en langage naturel, l’endigdage, donc avec un système complètement différent, uniquement basé sur ce que je vais appeler du fuzzy matching, des choses comme ça, de l’analyse en gros de termes proches ou de choses comme ça. Ça marchait déjà plutôt bien. Donc les gens posent une question et obtiennent en réponse pas du texte, parce que ce n’était pas un générateur de texte, mais obtiennent en réponse un graphique ou un tableau qui va effectivement, en fonction de la question qui a été posée, en fonction de la donnée auquel j’ai accès, générer la meilleure réponse possible. Et la meilleure réponse possible, ce n’est pas forcément un tableau. Parce que par exemple, si je pose une question sur l’évolution de mon chiffre d’affaires, la meilleure manière de le présenter, c’est peut-être un graphique en courbe. Parce qu’on est sur l’évolution d’une donnée temporelle. La donnée temporelle, cette continuité qui existe dans la donnée temporelle, c’est bien la courbe qui va nous le présenter. Oui. Alors que si je demande une question différente, je voudrais par exemple mon chiffre d’affaires par famille de produits, c’est plutôt un graphique en barres qui va apparaître. Parce que la famille de produits, ce n’est pas une dimension continue. Donc cette discontinuité, elle est bien exprimée par la notion de barres. Donc on a toute cette intelligence qui exige d’agents le produit et qui permet de générer finalement les meilleures représentations graphiques sur une question simple qui peut être posée par l’utilisateur. 

Marc 00:08:23 – 00:08:23 : En langage naturel. 

Antoine 00:08:23 – 00:08:57 : En langage naturel. D’accord. Et qui ne se base pas sur du LLM. Ça veut dire qu’en termes de coût d’installation, de coût d’exploitation, ce n’est pas du tout la même chose non plus. Pas besoin d’avoir un GPU. Une sobriété computationnelle. Et c’est pour ça que je dis qu’il y a des usages pour le LLM, mais il n’y a pas tout le temps des usages pour le LLM. Et surtout, il ne faut pas essayer de le mettre partout quand on n’en a pas besoin, parce que ça a un certain coût. Même d’exploitation, je ne parle pas de l’entraînement du modèle qui est encore complètement différent, nous on ne rentrera pas là-dedans. Mais même l’exploitation nécessite quand même d’avoir un GPU. Et aujourd’hui, un GPU dans un data center avec une cloud, ce n’est pas gratuit. C’est beaucoup plus cher qu’une machine standard telle qu’on peut l’utiliser dans nos produits actuellement. 

Marc 00:08:57 – 00:09:02 : Oui, ça commence à quelques euros de l’heure. Après, si on fait du volume, on peut réduire. 

Antoine 00:09:02 – 00:09:03 : Oui, c’est ça. 

Marc 00:09:03 – 00:09:15 : Est-ce que tu peux nous donner des exemples de décisions business qui sont prises grâce à vos outils, qui de préférence n’auraient pas été possibles avec un autre outil de BI ? 

Antoine 00:09:15 – 00:11:34 : Pas possible avec un autre outil de BI, je n’en sais rien, parce que c’est toujours possible de paramétrer, de fine-tuner des outils de BI pour faire des choses. Mais nous, on a effectivement dans notre outil un moteur d’analyse multidimensionnel qui est capable de supporter des très gros volumes de données. Donc ça veut dire qu’effectivement, on peut répondre à des cas d’usage où il y a des milliards de lignes, des centaines de colonnes, ça ne pose pas de problème. Par exemple, dans le cadre du… Alors c’est un peu ancien maintenant, mais on peut quand même continuer à en parler. Dans le cadre de la crise Covid qui a eu lieu il y a quelques années, le ministère de la Santé avait besoin de distribuer à l’ensemble des acteurs autour du Covid ce qu’on va appeler la cellule de crise. Mais elle est assez élargie, cette cellule de crise, parce qu’elle contient à la fois les préfets des différentes régions, elle contient les ARS, donc les… les organismes régionaux de santé, donc il y a plein de décideurs finalement qui ont besoin d’avoir des indicateurs sur tout ce qui s’est passé sur le Covid. Et tout ce qui s’est passé, c’est par exemple qui s’est fait tester, à quel endroit, à quel moment, par qui. On avait toutes ces informations au niveau individuel. Donc c’est de la donnée qui est hypersensible. Les données de santé, on sait quelle problématique est associée à ça, donc on veut absolument avoir des niveaux de sécurité qui sont maximum sur ces données de santé. Ils n’avaient pas l’infrastructure en interne, donc ils ont choisi effectivement avec nous de mettre en place une solution chez OVHcloud pour analyser l’ensemble de ces données. Donc on avait vraiment au niveau unitaire, à la fin, plus de 400 millions de tests réalisés en France sur les tests Covid, que ce soit des tests… les différents types de tests, PCR, puis après ça s’est transformé en d’autres types de tests, mais enfin on avait tout un panel, et donc ils étaient capables de savoir effectivement l’évolution du Covid à travers le temps, à travers les régions, comment le Covid se déplaçait en France uniquement en analysant ces données. Et pareil après dans la deuxième étape qui a été la vaccination, quand les vaccins sont arrivés, ils avaient besoin de savoir où en était la vaccination dans l’ensemble des régions. Et là aussi c’est quand même un certain volume de données, parce qu’on avait non seulement les personnes qui se sont fait vacciner, mais à quel moment ? à quel endroit, par qui, et combien de fois. Donc ça veut dire qu’in fine, il y avait plus de 180 millions de lignes aussi dans cette base, puisque chaque personne, un peu plus de 60 millions de Français se sont fait injecter trois doses, donc à la fin de l’étude, puisqu’ils n’ont pas continué après sur la suite, mais il y avait un peu plus de 180 millions de lignes, et donc ils étaient capables de faire des analyses assez intéressantes sur l’ensemble de ces données. Donc ça a été en plus une mise en place très rapide, puisque l’objectif c’était ça, c’est une cellule de crise, donc c’est pas je vais avoir le projet, il faut que ce soit prêt dans deux ans, il faut que ce soit prêt dans deux semaines, c’était ça globalement l’objectif. Et c’est ça qu’on est capable de mettre en place dans DigDash. 

Marc 00:11:34 – 00:11:44 : D’accord. Et alors, si on rentre un peu dans la technique, comment est-ce qu’on gère 180 millions de lignes sans colonne ? 

Antoine 00:11:44 – 00:12:59 : Oui. Alors, effectivement, puisque le but, c’est d’analyser ces données de temps réel, il faut que les temps de réponse sur une requête classique soient inférieurs à la       seconde. C’est ça qu’on entend par le temps de traitement classique d’un tableau de bord. Donc, on n’est pas du tout…. On parlait tout à l’heure de LLM, d’apprentissage et tout ça, qui sont plutôt « Tiens, quand je vais générer un nouveau modèle de LLM, ça se mesure en mois, ça ne se mesure pas en secondes. ». Donc là, les temps de réponse sont hyper importants parce que les gens qui sont des acteurs derrière ont besoin effectivement d’avoir un flux de pensée, donc d’être assez naturel sur la manière d’explorer leurs données. Pour obtenir ces performances-là, nous, on a effectivement derrière notre propre base d’analyse. Donc ce n’est pas un moteur disponible sur le marché, c’est vraiment fourni dans DigDash. C’est basé sur ce qu’on appelle la base de données vectorielle, donc toutes les colonnes globalement sont indexées et avec beaucoup de in-memory, donc effectivement on utilise la RAM pour faire accélérer le processus de requêtage. C’est un moteur qui est spécialisé pour faire des agrégats, donc des calculs de somme, de moyenne, de médiane sur des volumes de données très importants. C’est complètement différent si on doit prendre un parallèle avec des bases de données transactionnelles type SQL. Parce que le but de la base transactionnelle, c’est comme son nom l’indique, de faire des transactions, d’être capable d’insérer ou de retirer des petits volumes de données. Là, notre but, ce n’est pas du tout ça. Ce n’est pas de faire ça de manière simultanée du tout. C’est de dire, je vais insérer des gros blocs de temps en temps. Tous les jours, je vais rajouter un ou deux millions de lignes. Mais après, quand je le parcours, il faut que ce soit efficace. Ce ne sont pas du tout les mêmes mécanismes de locking. 

Marc 00:12:59 – 00:13:08 : D’accord. Très intéressant, ça. Alors, est-ce que vous faites du machine learning dans votre outil ? Si oui, quel intérêt ça a ? 

Antoine 00:13:08 – 00:15:25 : Alors aujourd’hui, on fait du machine learning en amont pour nos clients, mais ce n’est pas un outil qu’on propose. Nous, encore une fois, l’outil DigDash, c’est… une suite de différentes interfaces qui vont permettre à nos clients d’exploiter leurs données, mais on ne va pas jusqu’au machine learning. Parce que nos typologies de clients ne vont pas jusqu’au machine learning. En gros, on a trois types d’utilisateurs dans la plateforme DigDash. On va avoir un utilisateur qu’on appelle l’utilisateur métier chez nous, donc c’est vraiment la personne qui est un débutant en données. Quelqu’un qui, par exemple, dans Excel, ne saura même pas faire un tableau croisé dynamique, c’est ce type de personne-là qu’on adresse aussi avec la plateforme DigDash. Donc on lui rend la main finalement sur l’usage de ces données avec une interface très simple, très presse bouton pour qu’il soit capable en toute autonomie de cliquer, de rentrer dans le détail sans avoir besoin d’explications particulières. Deuxième profil qu’on va avoir, c’est le profil qu’on appelle analyse chez nous. Alors attention, il ne faut pas confondre avec tous les métiers de data analysis, etc. Le profil analyste chez DigDash, qu’on appelle aussi utilisateur intermédiaire, c’est quelqu’un qui a déjà une expertise autour de la donnée, mais pas forcément en tant que data scientist ou data analyst. Ça peut être quelqu’un qui, dans une entreprise, sait se servir d’un rapport BO, sait construire ses propres requêtes, ça peut être ce genre de choses-là. Donc lui, on veut qu’il ait un peu plus la main pour être autonome dans la création de tableaux de bord et les partager à d’autres personnes. Donc une interface encore spécifique qui lui permet en toute autonomie de créer ses formules, d’enrichir ses modèles de données, etc. Puis, troisième type d’utilisateur qu’on appelle l’utilisateur avancé. Alors, en répartition, dans nos clients, c’est assez simple. Il y a 80% d’utilisateurs métiers, 20% d’utilisateurs intermédiaires. Et l’utilisateur avancé ou modeleur de données. chez nous, si on fait 80 plus 20, on se rend compte qu’il reste 0%. Ce n’est pas complètement vrai, mais en gros, c’est une poignée de gens. Ce sont les personnes qui vont préparer les données. Donc là, on est plutôt effectivement sur des métiers de data scientist, data analyst, etc. Donc, des gens qui vont être beaucoup plus proches de la donnée et qui vont… Vraiment modeler la donnée, être capable de créer des indicateurs complexes. Donc là, on a un studio de développement dans lequel il y a un peu de ML, mais pas beaucoup. C’est-à-dire qu’on s’arrête à faire trois grands types d’activités en IA qui vont vraiment être très pertinents pour le business. Le premier, c’est la catégorisation. J’ai une variable de sortie, par exemple le chiffre d’affaires. On va prendre quelque chose de simple que tout le monde peut comprendre. Et je veux savoir les produits qui se comportent de la même manière par rapport à ce chiffre d’affaires. Il peut y avoir plein d’autres paramètres, mettons que ce soit ça. Et donc, je vais catégoriser les produits qui, dans 3, 5, 10 groupes, qui vont se comporter de la même manière. C’est de l’auto-classification, quelque part. 

Marc 00:15:25 – 00:15:27 : Qui vont partager la saisonnalité. 

Antoine 00:15:27 – 00:16:14 : Par exemple, ça peut être ça. Deuxième chose, c’est sur les séries temporelles. C’est un cas assez classique quand on fait de l’analyse financière ou autre. J’ai effectivement une série temporelle, comment elle va se prolonger ? C’est la prédiction de la série temporelle. Ça, c’est assez classique, ça peut être… La régression polynomiale, ça peut être même simple régression linéaire dans les cas les plus simples, mais donc des cas assez simples. Et puis, troisième élément, c’est ce qu’on appelle les key influencers. Je prends toujours mon exemple de Genva, de sortie, le chiffre d’affaires, et je veux savoir dans l’ensemble des dimensions que je vais parcourir, alors je ne sais pas si je suis vendeur automobile, j’ai peut-être la couleur de ma voiture, j’ai peut-être la taille, les sièges que je mets, la qualité du cuir, etc. Quel est l’influenceur qui fait que ça a plus vendu ? Donc ça, c’est un cas aussi typique business qui va nous permettre de donner quelques insights sur ce que font les gens avec leur data. 

Marc 00:16:14 – 00:16:30 : Chercher des liens de causalité entre des événements. C’est ça. Ok. Très intéressant. Alors, quels sont maintenant les obstacles que vous rencontrez qui ne sont pas les obstacles techniques ? Quels sont les obstacles à l’utilisation de l’outil DigDash ? 

Antoine 00:16:30 – 00:17:56 : Pour nous, c’est principalement la conduite du changement. On a des organisations qui ne sont pas toujours des organisations très matures en data. Leur faire comprendre comment ça marche de mettre en place une solution de data, c’est l’obstacle le plus grand. Sachant qu’on a quand même un rôle d’éducation auprès des entreprises, donc de leur apprendre les bonnes manières de faire. Par exemple, nous, on a une opinion assez forte sur le fait de séparer des rôles comme le rôle du designer par rapport au rôle de l’analyste. Le designer, c’est la personne qui, globalement, va mettre des couleurs sur les tableaux de bord, si je dois le résumer un petit peu de manière simple. Et en général, c’est assez orthogonal avec l’esprit d’un analyste. Et quand on est dans des produits autres, alors je vais citer Excel pour être le plus simple, la plupart des autres produits de BI, y compris Power BI, etc., on va laisser la possibilité à l’analyste de non seulement construire ses tableaux, mais en plus d’éditer la charte graphique de ses tableaux. Nous, on pense que c’est une connerie. On a quand même une option pour activer ça, mais par défaut, dans DigDash, on peut désactiver ça. Donc on peut rendre la charte graphique complètement indépendante de la production  des analystes. Donc on a essayé, enfin on essaye nous de faire passer des messages, c’est pas toujours très simple, on parlait des difficultés, on essaye de faire passer ce message-là parce qu’on pense que d’un point de vue organisationnel, c’est beaucoup plus intéressant de faire ça. Notamment parce que si j’ai 25 BU différentes, si chacun commence à faire des chartes graphiques différentes dans son coin, quand on va réunir les données et les productions de chacune de ces BU, c’est compliqué d’avoir quelque chose d’homogène. 

Marc 00:17:56 – 00:18:02 : Plus de travail, peut-être qu’on s’habitue à une… Une signification, des légendes, ce genre de choses. 

Antoine 00:18:02 – 00:18:04 : Exactement, c’est ça. 

Marc 00:18:04 – 00:18:06 : Ça parpie un peu, quoi. 

Antoine 00:18:06 – 00:18:28 : Alors, il existe des normes. Par exemple, il y a le professeur Richard, en Allemagne, qui a essayé de mettre en place une méthodologie autour de la normalisation de ces graphiques-là. Je n’irai pas jusqu’à cet extrême-là, moi. Ce n’est pas forcément le but. Mais l’idée, c’est que dans une entreprise, on essaie d’adopter une charte commune pour laquelle la plupart des utilisateurs, effectivement, soient contents de cette charte et donc soient capables, effectivement, d’avoir des productions qui sont homogènes dans l’ensemble de l’organisation. 

Marc 00:18:29 – 00:18:37 : Ok, c’est intéressant. Alors qu’est-ce que disent des gens qui veulent tout standardiser comme ça ? Quelles sont les grandes recommandations qui en sortent ? 

Antoine 00:18:37 – 00:19:40 : Alors, encore une fois, on parlait de difficulté d’adoption jusqu’à maintenant et c’est plutôt aujourd’hui une difficulté. C’est-à-dire que nous, on pousse ça parce qu’on pense que c’est le modèle intéressant à faire et qu’effectivement, au niveau de l’organisation, ça fait du sens. Mais par contre, au niveau de l’utilisateur, c’est parfois un peu un frein. Parce que l’utilisateur, il aime bien aller bidouiller ses couleurs, son épaisseur de trait. Et donc, c’est un peu ça, quand on parlait de frein tout à l’heure, qui est compliqué à mettre en œuvre. Donc, D’un point de vue organisationnel, clairement, quand il y a l’adoption, après, c’est top. Mais ce petit passage, il est compliqué pour les utilisateurs à comprendre. Pourquoi ce que je pouvais faire avant dans une autre solution, dans NICDA, je ne peux pas le faire ? En fait, on peut lui activer la fonction, c’est juste qu’on ne conseille pas de le faire. Oui. Et du coup, ce qui est intéressant, c’est que nous déjà, on propose à travers notre Professional Services d’accompagner les entreprises à créer leur propre charte graphique BI. On va s’appuyer sur la charte graphique de communication qui existe déjà, mais on va effectivement implémenter dans le tableau de bord une charte graphique qui va être utilisée par tous. Au long terme, effectivement, hyper intéressant d’un point de vue rationalisation des usages. 

Marc 00:19:41 – 00:19:53 : Et comment on existe en tant que petit acteur français au milieu des monstres de la BI, que sont Microsoft Power BI, comme tu le citais, et tous les autres ? 

Antoine 00:19:53 – 00:21:39 : Compliqué. On s’en sort encore une fois, on a un argument fort. L’argument fort, c’est la souveraineté de données. La souveraineté de données, c’est quoi ? C’est s’extraire de deux lois américaines, la loi FISA et la loi Cloud Act. La loi FISA qui d’ailleurs va probablement se renforcer encore. Je rappelle juste que ces deux lois permettent globalement au gouvernement américain d’aller piocher dans les données de n’importe quelle entreprise américaine. Donc que les données soient hébergées aux États-Unis ou en France, ça ne fait pas de différence. Donc sans concerner les hyperscalers qu’on connaît tous, Amazon Web Services, Google Cloud Platform, Microsoft Azure, à partir du moment où vous mettez des données dessus, elles sont potentiellement accessibles par le gouvernement américain. Donc ce qui, à notre sens, est un problème parce que lors de nos entreprises, la valeur de nos entreprises, c’est quand même leurs données, c’est leur asset. Donc si on n’est pas capable de les protéger, c’est un vrai problème. Alors ils essayent d’avoir des réponses, ces hyperscalers, en disant, il y a un terme qui s’appelle « bring your own key », donc vous pouvez encrypter effectivement les disques avec votre propre clé d’encryptage. On sait aujourd’hui que ces clés d’encryptage, le gouvernement américain sait les casser très facilement. Donc c’est un miroir aux alouettes, si je dois dire. En tout cas, ce n’est pas réellement une vraie sécurité à mon sens. Donc nous, cet aspect souveraineté, je pense que c’est important. Alors il y a quand même le gouvernement, surtout en France, on essaie dans d’autres pays européens d’avoir la même approche. Et c’est vrai que c’est un peu moins perçu en Espagne, même s’il commence à y avoir un petit éclairage là-dessus. Mais je pense qu’en France, on est assez en avance finalement d’un point de vue gouvernemental sur cette problématique de la sécurité des données. Alors probablement à cause de fuites, probablement à cause d’attaques, probablement aussi à cause de polémiques qu’il y a eu autour du Health Data Hub à une époque qui était hébergé par Microsoft. Donc tout ça a contribué au fait que le gouvernement français se pose les bonnes questions sur la sécurisation de permettre de donner. 

Marc 00:21:40 – 00:21:44 : Oui, sur quelques déconvenues aussi face au protectionnisme américain. 

Antoine 00:21:44 – 00:21:53 : Exactement. Aujourd’hui, la problématique, c’est qu’on est sur des enjeux géopolitiques. Et on ne sait pas de quoi l’avenir est fait pour les États-Unis. Peut-être qu’on aura Donald Trump. C’est déjà arrivé, c’est ça qu’on est en train de dire. 

Marc 00:21:56 – 00:22:05 : Quelles erreurs est-ce que tu peux nous partager pour nous faire gagner du temps lors d’un setup de dashboard BI en général ? 

Antoine 00:22:05 – 00:23:32 : Il y a plusieurs choses. On voit souvent des gens qui disent « j’ai des données, je vais faire un tableau de bord ». Pour moi, ce n’est pas la bonne approche. La bonne approche, c’est de dire de quoi je vais avoir besoin d’un point de vue indicateur et tableau de bord, puisque le but de la business intelligence, c’est de rendre les gens plus intelligents au niveau de leur business. D’ailleurs, on appelle ça intelligence d’affaires au Canada. Le terme se traduit vraiment. Donc, l’idée, c’est de poser la question au métier. de savoir de quoi ils ont besoin pour piloter leur activité ou pour aller plus loin dans l’exploitation de leur activité. Ce n’est pas de dire « j’ai des données, je vais en faire quelque chose », ça ne sert à rien. C’est de dire de quoi vous avez besoin. Est-ce que j’ai des données pour bâtir de quoi moi j’ai besoin ? Et ce n’est pas toujours le cas. Parfois, on se rend compte « non, je n’ai pas la donnée ». Donc quand on n’a pas de données, qu’est-ce qu’on fait ? On peut soit venir rajouter dans son CRM des champs supplémentaires, on peut activer d’autres éléments pour capturer cette donnée. Notamment dans DigDash, on a un module de saisie de données qui permet de créer des interfaces qui vont complémenter les données manquantes de ce dont aurait besoin un utilisateur. Donc ça, ça fait partie vraiment aussi de notre cœur business. On considère qu’aujourd’hui, il y a la donnée qui provient des outils corporate, le CRM, le RP ou que sais-je. Et puis il y a de la donnée complémentaire qui a besoin d’être intégrée. Parfois, c’est compliqué d’aller bouger les lignes d’un SAP ou de produits comme ça. Donc nous, sur le côté, on va rajouter une petite base qui va venir complémenter effectivement les données et rajouter une information supplémentaire et utile pour le pilotage de l’entreprise, voire même la data com ou la data exploration. 

Marc 00:23:32 – 00:23:42 : Donc parfois, ce dont on a besoin, ce n’est pas de construire le dashboard lui-même, mais de développer un petit outil pour extraire les données de là où elles sont. C’est un peu ça, finalement. 

Antoine 00:23:42 – 00:24:24 : Ça peut être ça ou, encore une fois, parfois, elles n’existent même pas, ces données. Je ne sais pas si je n’ai pas le champ… C’est idiot ce que je veux dire parce que j’ai probablement ce champ-là, mais si je n’ai pas un champ dans ma base qui me dit si mon client est prêt à acheter ou pas… il faut peut-être que je le mette ailleurs pour savoir dans mon pipeline d’achat à quel niveau il est. C’est un exemple bête, mais on a des exemples un peu plus complexes que ça. C’est un peu ça. l’idée, c’est de dire tout ce qui n’existe pas dans mes services clés, comment je fais pour venir compléter ça ? Donc effectivement, ça peut être un fichier Excel sur le côté qui est maintenu, dans lequel on va intégrer, mais ça peut être aussi une interface qui est développée dans DigDash avec un vrai formulaire qui a du sens et qui se relie aux données existantes pour dire, tiens, pour ce client-là, je n’ai pas cette information, est-ce qu’on peut la compléter ? 

Marc 00:24:24 – 00:24:29 : Vous produisez vous-même du sur-mesure, des ajustements pour vos clients à votre logiciel ? 

Antoine 00:24:29 – 00:25:20 : Ce ne sont pas des ajustements parce que l’interface utilisateur permet à n’importe quel client de créer son propre formulaire lui-même. On a vraiment un truc drag and draw qui permet de créer un formulaire. Il pourrait le faire lui-même s’il a la formation pour le faire. On a quand même du professional services, donc on a effectivement une activité de service pour accompagner nos clients qui n’ont pas forcément ni les ressources ni le temps pour faire ces choses-là. Mais on travaille surtout avec un réseau de partenaires assez vaste qui mettent en place la solution DigDash. Notre but en tant qu’éditeur, ce n’est pas d’accompagner un client sur plusieurs mois, plusieurs années, ce n’est pas de faire de la maintenance de son application, mais c’est plutôt de lui donner des éléments techniques précis. Donc notre activité de Professional Services, elle est plutôt orientée sur le fait d’accompagner sur des points techniques sur une durée relativement courte. Donc on a plein de petits projets sur des durées courtes, puis après on passe ça effectivement en exploitation chez des partenaires si jamais le client a besoin. 

Marc 00:25:21 – 00:25:30 : Ok. Alors quels sont les gros obstacles que vous avez résolus pour construire cet outil de dashboarding ? Les obstacles techniques cette fois-ci. 

Antoine 00:25:31 – 00:27:45 : Alors techniques, il y en a plusieurs. Nous, notre volonté, c’était d’avoir quelque chose qui est… Je l’ai dit tout à l’heure, très rapide en termes d’exécution. Donc la première chose, ça a été de construire une base d’analyse. Alors pourquoi on n’a pas utilisé une base marché ? Il y a des bases vectorielles qui existent. Parce qu’en fait, on avait plusieurs contraintes. Et à l’époque, nous, on l’a construit. Digdash est assez ancien. On en a parlé tout à l’heure. On existe depuis 2007. A l’époque où on voulait construire ça, il n’y avait pas de base qui répondait à l’ensemble des critères de ce que nous, on voulait. C’est qu’un, il y ait la scalabilité, c’est-à-dire la capacité à se diffuser sur un cluster. Quand j’ai des milliards de lignes, ce n’est pas une seule machine qui va travailler, mais ça peut être distribué sur un cluster. J’ai une base, mais qui est distribuée sur ce cluster. Deux, qui est cette capacité à fonctionner aussi en mode offline. L’idée, c’est de dire je peux prendre une partie de mes données. Alors, bien sûr, je ne parle pas de millions de lignes, mais je vais partir avec une partie de mes données. Par exemple, je prends 100 000 ou 200 000 lignes et ça continue à marcher dans mon navigateur. Il y a aussi cette contrainte-là. C’est un peu moins le cas maintenant, mais à l’époque, on avait pas mal de gens qui disaient « moi j’ai pas mal de contraintes business, quand je voyage dans l’avion, je veux continuer à analyser mes données, comment ça marche ? ». Sachant qu’on a une application web, donc on ne déploie rien sur le poste client. Donc on utilise vraiment le offline storage du navigateur, du javascript pour faire toute cette computation dans le navigateur. Et puis, dernier point sur cette base d’analyse, la capacité à la maîtriser à 100%. Donc être capable de l’optimiser aux petits oignons par rapport à nos besoins. Et quand on est sur un produit tiers, c’est compliqué à faire. Là, on sait clairement qu’elle répond à l’attente d’un outil décisionnel et pas à 25 autres usages. Donc ça, c’est notre objectif. Ça, ça a été une des barrières assez importantes. Après, nous, notre objectif, c’était aussi d’être dans un monde de l’entreprise. Dans le monde de l’entreprise, la cybersécurité, c’est hyper important. Donc, répondre à des exigences en termes de normalisation. Nous, on est normalisé ISO 27001. Donc, ça veut dire qu’effectivement, dans nos… dans nos manières de développer le logiciel, dans nos manières d’héberger la solution, etc. On est audité, on est suivi, donc c’est pas mal de contraintes. C’est des gros dossiers à remplir, c’est du suivi à faire, mais c’est un besoin pour répondre effectivement au type d’entreprise à laquelle on s’adresse. Ça, c’est une barrière d’entrée supplémentaire, on va dire, sur la création de DigDash. 

Marc 00:27:45 – 00:27:53 : Alors, quelles sont les bonnes pratiques quand on fait un tableau de bord avec DigDash, par exemple ? 

Antoine 00:27:53 – 00:29:26 : Alors les bonnes pratiques, moi je dirais que ça dépend de l’organisation. Il y a différents types d’organisation et c’est encore vrai aujourd’hui. Il y a des organisations qui peuvent être plutôt, il y a un terme qui s’appelle data mesh aujourd’hui qu’on entend beaucoup parler. Chaque zone de données a un responsable de zone de données. Donc je m’occupe du marketing d’un côté, je m’occupe de la logistique de l’autre, je m’occupe de la finance de l’autre. Et chacun a un peu un périmètre fonctionnel autonome qui va lui permettre effectivement de gérer ses données et donc d’être organisé autour de ses données. Ça, c’est un premier mode de fonctionnement. Ça marche assez bien. Pourquoi ça marche bien? ? Parce que le fonctionnel est mêlé avec le technique. C’est-à-dire qu’on a toujours quelqu’un qui connaît le métier et qui va savoir quoi faire des données. Mais on a aussi des organisations qui sont organisées en mode centralisé. Donc il y a un espèce de gros ensemble de données. On peut l’appeler Data Lake, on peut l’appeler comme on veut. Data Warehouse, c’est un peu différent, ou en tout cas Data Mart, c’est un peu différent parce qu’on est plus proche du Data Mesh. C’est un nom différent du Data Mart. Pour moi, c’est l’ancêtre du Data Mesh. J’avais des Data Mart spécifiques pour des usages spécifiques. Mais en tout cas, quand on est en mode centralisé, l’erreur à ne pas commettre, c’est de ne pas impliquer les métiers. Parce que ce n’est pas une personne qui va décider pour les métiers qu’est-ce qui est bien à voir, qu’est-ce qui est bien à analyser. Donc, quel que soit le mode de fonctionnement, que ce soit en mode centralisé ou en mode décentralisé de la donnée, il faut impliquer les métiers. Et ça, c’est l’erreur qu’on voit dans pas mal de sociétés où j’ai un organe central qui gère la donnée et qui produit des choses dont personne ne se sert. Parce que les métiers n’ont pas été impliqués. 

Marc 00:29:26 – 00:29:29 : Est-ce que tu as une anecdote à nous partager ? 

Antoine 00:29:29 – 00:30:02 : Alors, anecdote, on parlait de LLM tout à l’heure. Nous, on a fait assez tôt des analyses pour voir ce que ça pourrait nous apporter, ce qu’on pourrait en faire. C’est aussi notre rôle en tant qu’éditeur. On allait explorer un peu toutes les technos. Il y a eu plein de choses pour lesquelles on a dit « on ne va même pas regarder, pour nous, ça n’a pas d’intérêt ». Par exemple, je pense au Metaverse ou des choses comme ça. On se dit qu’on ne voit pas l’application business, même si Meta le voyait, nous, on ne le voyait pas. Et je crois qu’on a eu raison, in fine, de ne pas voir d’application business. parce que j’ai l’impression qu’aujourd’hui, après 2-3 ans, il y a eu grand-chose qui se soit passé de ce côté-là. 

Marc 00:30:02 – 00:30:05 : En tout cas, pas dans la business intelligence. 

Antoine 00:30:05 – 00:32:26 : Pas dans la business intelligence, en tout cas. Il y a eu un produit. À l’époque, effectivement, où le Metaverse est sorti, je me souviens sur le salon Big Data, il y a un ou deux ans, des gens qui étaient avec des lunettes de réalité virtuelle en train de regarder des graphiques. Oui. Je pense qu’on n’a pas mis la techno d’un point de vue hardware, parce que j’ai pas envie de porter un casque sur la tête toute la journée pendant des heures, c’est juste pas possible. Peut-être qu’un jour ça viendra, mais aujourd’hui la techno fait que c’est juste pas possible. C’est trop lourd, c’est trop encombrant, c’est pas efficace, ça apporte rien. Donc si ça apporte rien, quelle est la valeur ajoutée ? Je vois pas de cas d’usage. Donc nous on a décidé de passer là-dessus, on a passé sur d’autres trucs. On a passé sur la blockchain par exemple, alors pas la crypto en général, mais même la blockchain. Il y a des usages et des applications de la blockchain. Nous, on a considéré que c’était un peu trop loin de notre métier principal pour qu’on fasse vraiment des efforts de R&D autour de la blockchain. Par contre, on avait déjà investi pas mal dans l’IA, etc. On a vu effectivement à l’arrivée de ChatGPT l’intérêt du LLM. Je pense qu’avant ChatGPT, c’était un peu compliqué de comprendre l’intérêt du LLM. La fameuse deuxième partie, le instruct, j’ai un modèle de données, mais quand je lui donne des instructions, il est capable vraiment de répondre à des choses. Là, on s’est dit, tiens, il y a quand même un cas d’usage d’une application possible. Encore une fois, notre réponse ici, c’est de dire, chaque éditeur logiciel devrait être capable de fournir son propre jeu d’instruct, donc d’étendre un LLM existant pour pouvoir y apporter quelque chose de grand. On était sur l’anecdote, j’ai un peu divergé. Donc l’anecdote du LLM, c’est qu’à l’époque où on commençait à regarder LLM, il y a un petit moment, on pouvait commencer à poser des questions à chat GPT assez intéressantes. Donc lors d’un salon Big Data, il y a deux ans, je pense, un de nos commerciaux qui   a demandé, tiens, Fais-moi une description de DigDash. Il a posé cette question. Décris-moi DigDash, la chat GPT. Donc, il y avait tout un ensemble de paramètres. C’est très bien foutu, parce qu’effectivement, il capture l’ensemble du web. Il y a le web courrier, etc. Donc, c’était assez bien foutu. Et au milieu de toute cette information, il y avait DigDash qui a été racheté par Tableau en 2021. Enfin, un truc assez précis, quoi. Alors que c’est absolument faux, bien évidemment. Donc là, on voit tout le biais cognitif aussi. C’est assez intéressant de dire qu’on ne maîtrise pas complètement ce que ça fait, ces modèles de LLM. Non, ça dit des bêtises. Voilà. Il faut faire très attention à ces aspects biais cognitifs aussi quand on utilise des LLM. C’est pour ça qu’il faut vraiment les contraindre dans un usage spécifique. 

Marc 00:32:26 – 00:32:41 : Je pense à la fonctionnalité de JetGPT, de code d’interpréteur, où on lui donne des données et il va faire des analyses lui-même. Est-ce qu’il y a des choses dans cette thématique que vous avez explorées, qui vous paraissent utiles ? 

Antoine 00:32:41 – 00:33:50 : Oui, on a un vrai projet autour de ça. Effectivement, quand je parlais de la fameuse partie Instruct, c’est un peu ça. Alors, ce n’est pas donner la masse complète des données parce que ça n’a aucun sens. Tous les modèles de LLM sont limités en termes de nombre de tokens qui sont capables de regarder globalement. Certains à assez haut, ça peut aller jusqu’à 100 000, mais en fait, 100 000, quand on regarde des données, c’est rien. Je pense que ça a un intérêt de regarder sur l’interprétation de petits volumes de données, etc. Après, il faut bien être conscient qu’il y a aussi d’autres techniques existantes et que je ne vais pas déployer un LLM pour qu’ils me disent « tiens, la donnée a varié en 2022 ». Il y a des techniques beaucoup plus simples d’analyse qui permettent d’accéder exactement au même résultat et avec une valeur sûre, et pas un truc dont peut-être il s’est trompé. Parce que je rappelle que l’objectif de tout ça, c’est que derrière le LLM, il faut être capable de contrôler la qualité de ce qui a été produit. Donc là, il y a tout un système important de mise en œuvre. Un vrai produit de data pour lequel la cohérence de l’information qui est produite, la qualité de l’information qui est produite, elle est clé. Donc on ne peut pas se dire que 2 x 3 égale 7, ce n’est pas bon. Alors qu’un LLM peut être capable de produire ça, parce que non, peut-être plus maintenant, mais à une époque, c’était encore le cas. 

Marc 00:33:50 – 00:33:51 : Oui, il n’est pas bon en calcul. 

Antoine 00:33:51 – 00:33:54 : Voilà, c’est ça. Donc il faut faire attention à ce genre de choses-là. 

Marc 00:33:54 – 00:33:57 : Ok, est-ce que tu as une opinion à nous partager ? 

Antoine 00:33:57 – 00:34:40 : J’en ai déjà partagé plusieurs, je crois, sur à la fois notre avis assez tranché sur la manière de déployer une solution de BI en entreprise. J’en ai déjà évoqué, donc je ne vais pas revenir dessus. Sur l’utilisation du LLM, je peux en revenir encore là-dessus ? Mon opinion qui est assez tranchée, c’est de se dire attention à ne pas le déployer juste parce que c’est la mode. Ce serait bête de tuer ce truc qui est un truc merveilleux parce qu’on a été trop vite à faire des choses qui n’ont pas de sens pour les entreprises. Il y a vraiment un vrai potentiel à exploiter dans le futur. Il ne faut pas que les gens se disent « moi j’ai essayé de l’utiliser, je n’ai pas réussi à faire quelque chose » et que dans deux ans, ça passe complètement à la trappe parce que je pense qu’il y a un vrai potentiel d’exploitation de cette chose-là. 

Marc 00:34:41 – 00:34:48 : Alors, si c’était à refaire en 2007, qu’est-ce que tu changes dans le déroulé ? 

Antoine 00:34:48 – 00:36:04 : Moi, j’ai presque envie de dire rien. Ce n’est pas qu’on ait fait un parcours parfait, mais on a choisi notre parcours. Alors, je ne l’ai pas expliqué en introduction, mais Digdash a été financé par ses dirigeants. Donc, on n’a pas d’actionnaire externe. C’est un choix. Donc, on est plutôt sur…. Je crois qu’il y a pas mal de concours qui s’appellent « fast growth » ou quelque chose comme ça. Nous, on n’est pas du tout là-dedans, on est plutôt sur du « slow growth », mais on maîtrise notre périmètre, on sait ce qu’on veut amener à nos clients, on sait la valeur qu’on leur apporte. Et notre objectif, ce n’est pas forcément d’être les plus gros, les plus importants en termes de volume, mais c’est d’être les plus précis, les plus respectueux, avoir une qualité aussi de vie au travail qui est importante. Pour nous, la partie RSE, responsabilité sociale et environnementale, ce n’est pas du « greenwashing », c’est quelque chose qui est dans nos gènes, parce que les actionnaires, parce que les gens qui prennent partie à cette aventure DigDash ont cette perspective-là depuis le début. Donc le respect des employés, etc. C’est quelque chose qui est important pour nous. Donc je ne sais pas si je referais quelque chose différemment. Ça a été long, depuis 2007, on existe. On aurait pu aller beaucoup plus vite. Je suis assez content de ce développement assez graduel et évolutif de la solution Digdash. 

Marc 00:36:04 – 00:36:06 : Et vous êtes resté au soleil aussi, il faut le mentionner. 

Antoine 00:36:06 – 00:36:11 : Et on est resté au soleil effectivement avec Saint-Provence, même si aujourd’hui il pleut et je suis content d’être à Paris. 

Marc 00:36:11 – 00:36:16 : Alors c’est quoi les prochaines étapes pour vous ? 

Antoine 00:36:16 – 00:37:20 : Alors les prochaines étapes, encore une fois on est très orienté entreprise, donc il y a un mouvement assez massif actuellement dans les entreprises, il y a beaucoup de gens qui ont encore des vieux systèmes décisionnels, on parlait tout à l’heure de Cognos et Business Objects, il y a une vraie interrogation sur ce que va faire SAP autour de Business Objects, parce qu’il y a des statements pour 2025 qui vont dire que globalement ils vont… effacer un certain nombre de produits existants et recréer un produit différent. donc là on a des vraies opportunités nous aujourd’hui pour capturer ce marché. là parce que je pense qu’on est beaucoup plus mature que l’offre de business object actuellement. donc nous on veut vraiment se diriger vers la continuité de services pour les entreprises qui s’appuient sur du business object. c’est pas être dépendant et tributaire d’une plateforme qui sap va être maintenant. C’est ça leur objectif. À la base, Business Objects était très ancien, déploiement en primaire, etc. Mais donc, on contrôlait un petit peu là où pouvait être la donnée. Le futur de SAP, c’est un peu moins clair sur ces sujets-là. Donc, on continue vraiment sur cet aspect. souveraineté de données. C’est un des points importants pour nous. 

Marc 00:37:20 – 00:37:27 : Ok. Mais alors, est-ce que tu as un invité à nous recommander pour un prochain épisode de Data Driven 101 ? 

Antoine 00:37:27 – 00:37:47 : Alors on a autour d’Aix une petite ESN qui est assez smart et qui publie une newsletter autour de l’AI, enfin tout ce qui est génération de modèles, etc. Et elle s’appelle Alger, et je pense qu’il y a des gens assez smart là-bas qui peuvent peut-être avoir un intérêt à passer dans ce podcast. Super, merci Antoine. 

Marc 00:37:47 – 00:37:50 : Merci. Vous venez d’entendre Antoine Buat, dirigeant de DigDash sur Data Driven 101.