Decideo - Data Science, Big Data, Intelligence Augmentée

Decideo est la communauté d’information et d’échange autour des outils et meilleures pratiques d’analyse de données (Machine Learning, Business Intelligence, Big Data, Science des Données, Entrepôts de données…). Véritable réseau social des professionnels de la donnée, Decideo est disponible en français www.decideo.fr et en espagnol www.decideo.com. Opinions d’experts, actualités, agenda, offres d’emploi, sont disponibles en ligne et sur les applications mobiles gratuites. Decideo is the leading user community of Business Intelligence, Data Science, Big Data and Analytics professionals. Decideo is a real social network of data driven economy, available in French www.decideo.fr, and Spanish www.decideo.com. User stories, best practices, news, software reviews, agenda, job board… are available online, and through podcast and mobile applications.

#6.12 Mauvaise gouvernance : Faut-il interdire ou empêcher ? 05/18/2026

#6.12 Mauvaise gouvernance : Faut-il interdire ou empêcher ? Interdire ou empêcher : deux logiques de gouvernance à l’épreuve des données et de l’IA De passage sur TikTok pour y écouter parler de philosophie (si, si, on parle de philo sur TikTok… abonnez-vous par exemple au compte de @philo_sophia_) l’algorithme m’a conduit à une comparaison argumentée entre l’interdiction et l’empêchement. Faisant le parallèle avec les contextes de gouvernance des données et de l’intelligence artificielle, qui semblent si difficiles à faire accepter aux opérationnels, il m’a semblé porteur de poser quelques réflexions sur le thème : faut-il imposer ou proposer une gouvernance des données ? Faut-il interdire ou empêcher une mauvaise, ou l’absence de gouvernance ? Une distinction conceptuelle aux implications politiques majeures La distinction entre interdire et empêcher paraît, au premier abord, triviale ; elle structure pourtant en profondeur les deux grands régimes de régulation possibles dans une société technologisée. Interdire est un acte normatif. La règle s’adresse à un sujet supposé libre, capable de comprendre la norme, d’en délibérer et, le cas échéant, d’y contrevenir. L’interdiction présuppose la possibilité matérielle de la transgression : c’est précisément cette possibilité qui ouvre l’espace de la responsabilité, du jugement, de la sanction et corrélativement de la contestation. Lawrence Lessig identifie ainsi la loi comme l’une des quatre modalités de régulation, qui contraint par la menace de la sanction, aux côtés des normes sociales, du marché et de l’architecture. Empêcher, à l’inverse, relève d’un dispositif factuel : la conduite n’est pas réprouvée, elle est rendue impossible. Aucun sujet n’a à délibérer, aucun juge n’a à trancher, aucun contrevenant n’a à répondre. Dans le cyberespace, cette modalité est portée par le code informatique lui-même. Lessig démontre que le code, et l’architecture, définissent la manière dont nous vivons le cyberespace, et détermine s’il est facile ou non de protéger sa vie privée, ou de censurer la parole. L’architecture remplace la délibération par la configuration. La portée critique de cette distinction a été remarquablement développée par Alain Supiot dans La Gouvernance par les nombres (Fayard, 2015). Il y montre comment la loi cède la place au programme et la réglementation à la régulation, dans un imaginaire institutionnel où l’on viserait la réalisation efficace d’objectifs mesurables plutôt que l’obéissance à des lois justes. L’enjeu, pour Supiot, n’est pas seulement technique : en envisageant les hommes comme des ordinateurs programmables, la gouvernance par les nombres sape le règne de la loi et fait ressurgir un système d’allégeance quasi féodal. Là où la loi suppose un sujet juridique responsable, le programme suppose un comportement à conditionner. Mon opinion : pour une primauté de l’interdiction sur l’empêchement Au terme de cette analyse, je défends la thèse suivante : dans la gouvernance des données et de l’IA, l’interdiction doit être première, l’empêchement instrumental. Mais c’est à vous de me dire dans les commentaires si vous êtes en accord avec cette vision… ou pas. Cette hiérarchie repose sur trois raisons. D’abord, une raison de principe démocratique. L’interdiction émane d’une délibération publique ; elle peut être discutée, amendée, abrogée. L’empêchement, lorsqu’il est inscrit dans le code, échappe à cette publicité : il est défini par les concepteurs, souvent privés, et son fonctionnement est opaque pour la majorité. Substituer systématiquement le dispositif à la norme, c’est déplacer la souveraineté politique vers les architectes techniques, ce que Supiot identifie comme une régression institutionnelle majeure. Ensuite, une raison anthropologique. L’interdiction maintient ouvert l’espace dans lequel l’agent peut choisir d’obéir ou de transgresser, et donc peut être tenu pour responsable. Un monde de pure prévention technique est un monde sans sujets moraux. Or, comme le rappellent Rouvroy et Berns, sans cet espace, c’est la possibilité même de la subjectivation politique qui s’efface et avec elle, paradoxalement, toute critique du système. Big Brother et George Orwell ne sont plus très loin… Enfin, une raison d’efficacité réflexive. Les dispositifs techniques sont faillibles, biaisés, contournables, et leurs erreurs se diffusent à grande échelle. La norme, parce qu’elle s’applique à des cas concrets via le jugement, conserve une plasticité que le code ne possède pas. Réserver à la loi le rôle de fixer ce qui doit être interdit, et au dispositif celui de rendre cette interdiction matériellement effective lorsque les asymétries d’échelle l’exigent, permet de cumuler les avantages des deux régimes sans en payer tous les coûts. Cela ne signifie pas qu’il faille rejeter l’empêchement technique. Face au passage à l’échelle des systèmes d’IA, à la rapidité des traitements automatisés, à l’asymétrie d’information entre opérateurs et personnes concernées, l’interdiction seule serait souvent purement déclaratoire. Le RGPD et l’AI Act ont raison de combiner les deux registres. Mais l’ordre de priorité importe : le dispositif doit servir la norme, et non la remplacer. Concrètement, cela impose trois critères à tout empêchement by design : Traçabilité juridique : le dispositif doit pouvoir être référé à une norme publique, débattue et amendable. Contestabilité effective : la personne empêchée doit pouvoir comprendre qu’elle l’est, savoir pourquoi, et disposer d’un recours humain réel, au sens de l’article 22 du RGPD. Réversibilité politique : aucun dispositif ne doit verrouiller à un degré tel qu’un changement démocratique de la règle deviendrait techniquement impraticable. Sans ces garde-fous, l’empêchement par le code n’est pas le prolongement de l’État de droit : il en est la sortie silencieuse ! /episode/index/show/decideo/id/41317260

#6.11 Intelligence Artificielle, comment redéfinit-elle le métier de directeur financier 05/04/2026

#6.11 Intelligence Artificielle, comment redéfinit-elle le métier de directeur financier Intelligence artificielle : comment redéfinit-elle le métier de directeur financier Clôtures accélérées, prévisions en temps réel, détection de fraude, assistants conversationnels embarqués dans l’ERP : l’intelligence artificielle n’est plus un horizon lointain pour les directions financières. Selon Deloitte, 87 % des DAF estiment qu’elle sera « extrêmement ou très importante » pour leur fonction en 2026. Ce que l’IA apporte vraiment Il faut commencer par distinguer deux familles de technologies. L’IA dite « traditionnelle » repose sur l’apprentissage machine : elle apprend à partir de données historiques pour classer, prédire ou détecter des anomalies. L’IA générative, popularisée depuis 2022 grâce à ChatGPT, produit du texte, du code, des synthèses et alimente désormais des « agents » capables d’orchestrer des tâches. Les deux se combinent pour offrir quatre apports majeurs à l’entreprise. L’automatisation intelligente des tâches répétitives d’abord. Saisie et rapprochement de factures, lettrage comptable, contrôle de cohérence, extraction de données depuis des PDF ou des images : ce que l’automatisation des processus faisait déjà de façon rigide devient adaptatif, capable de gérer les exceptions. L’analyse prédictive ensuite, qui permet de modéliser l’évolution de la trésorerie, d’anticiper des impayés ou de simuler des scénarios budgétaires. La détection d’anomalies et la lutte contre la fraude, historiquement l’un des cas d’usage les plus matures dans la banque, étendue aujourd’hui aux dépenses internes et aux notes de frais. Et enfin l’assistance conversationnelle : copilotes intégrés aux ERP qui rédigent des synthèses, expliquent un écart ou génèrent un premier jet de commentaire de clôture. Quelle traduction concrète pour la fonction finance Pour le directeur financier, ces technologies se déclinent sur l’ensemble du cycle. En comptabilité fournisseurs, l’IA scanne, classe et pré-comptabilise les factures : les premiers retours d’expérience publiés par Deloitte font état d’une automatisation avancée au-delà du simple couple OCR/RPA. En clôture, les tableaux de bord s’actualisent en continu, les anomalies remontent automatiquement et le délai de clôture mensuelle peut être sensiblement raccourci, à condition, comme le rappellent les praticiens réunis aux Journées DAF 2026, d’avoir préalablement standardisé les processus. En planification financière, les modèles apprennent à partir des données historiques et externes pour produire des prévisions glissantes plus fiables que les traditionnels budgets annuels. En trésorerie, l’IA permet un pilotage quasi-temps réel de la position de trésorerie. En conformité enfin, elle automatise les contrôles KYC, la détection d’opérations suspectes et la préparation des déclarations fiscales, ce qui représente un atout considérable dans le contexte de généralisation de la Facture Normalisée Électronique. Un avertissement toutefois : selon Gartner, seuls 36 % des DAF se disent aujourd’hui confiants dans leur capacité à tirer un impact mesurable de l’IA, essentiellement à cause de l’absence ou de la faiblesse de la gouvernance des données. La supervision humaine reste la règle sur tous les processus critiques. Quelles tendances pour les prochaines années Trois mouvements vont structurer le paysage. Premièrement, la montée de l’IA agentique. Selon Gartner, les agents autonomes prendront en charge 15 % des décisions quotidiennes et alimenteront 33 % des applications d’entreprise à l’horizon 2028. Deloitte observe déjà que plus d’un DAF sur deux (54 %) fait de leur intégration une priorité de transformation pour 2026. Deuxièmement, la convergence IA-données-cloud. L’IA ne produit des résultats fiables que si elle s’appuie sur des données propres, structurées et accessibles. Cela pousse à accélérer la migration vers des ERP modernes et à formaliser une véritable gouvernance de la donnée. Troisièmement, une régulation qui se structure. Les DAF devront intégrer ces cadres nationaux, les lois régionales sur la protection des données et les exigences comme l’AI Act européen. Après la gouvernance des données, c’est la gouvernance de l’IA que les DAF devront superviser. Proposition d’un plan d’action en 5 points pour votre DAF 1. Cartographier les cas d’usage à fort ROI. Lister les processus les plus consommateurs de temps (saisie de factures, rapprochements bancaires, relances clients, reporting de clôture, contrôles TVA) et sélectionner deux ou trois chantiers pilotes. L’objectif à six mois : prouver la valeur, sans chercher à couvrir tout le périmètre. Avancer par petits pas, très opérationnels. 2. Fiabiliser les fondations avant d’automatiser. Un ERP à jour, des référentiels tiers propres et des API stables : sans cela, l’IA amplifiera les erreurs existantes ! 3. Mettre en place une gouvernance IA et données. Définir qui peut déployer un modèle, sur quelles données, avec quel niveau de validation humaine. Documenter chaque usage, tracer les décisions automatisées et s’aligner sur la stratégie nationale du pays d’exploitation ainsi que sur la loi locale de protection des données personnelles. Se former et se faire accompagner sur le sujet est indispensable. 4. Former l’équipe et recruter les profils hybrides. La réussite dépend moins de l’outil que de l’appropriation. Prévoir un parcours de formation pour les contrôleurs de gestion et comptables, recruter ou développer en interne des profils « data-finance ». 5. Mesurer, sécuriser, itérer. Définir pour chaque pilote des KPI clairs (délai de clôture, taux d’automatisation des factures, écart de prévision, coût par transaction) et un cadre de cybersécurité adapté, car l’exposition d’un ERP connecté à un modèle d’IA crée de nouveaux risques. Réviser le dispositif tous les six mois pour passer progressivement du pilote à l’industrialisation. L’intelligence artificielle n’est ni une mode ni une menace pour le métier de DAF : c’est une extension de ses capacités. Les directions financières qui sauront articuler ces trois dynamiques (technologie, conformité, talents) ne se contenteront pas de gagner en productivité : elles s’imposeront comme co-pilotes stratégiques de la croissance de leur entreprise. /episode/index/show/decideo/id/41125180

#6.10 Découvrons le context engineering avec Dataloma 04/20/2026

#6.9 Catalogue de données, LLM et MCP 04/13/2026

#6.9 Catalogue de données, LLM et MCP Le LLM va-t-il devenir l’interface unifiée de la gouvernance des données ? Récemment j’évoquais les raisons principales d’échec du déploiement de nombreux catalogues de données. En première ligne, l’absence d’adoption suffisante par les utilisateurs métiers. Doit-on refondre les interfaces utilisateurs ? Une nouvelle voie apparait : abandonner l’interface utilisateur ! Et la confier à un LLM qui interrogera, via un serveur MCP, la base de données du catalogue. L’habitude d’interroger un moteur de recherche pour obtenir une réponse a changé. Le réflexe, en particulier dans la dernière génération, est maintenant de poser toutes ses questions à une IA générative. Le phénomène ChatGPT est devenu une évidence quotidienne. Arrivés dans l’entreprise, les futurs juniors reproduiront ce comportement. Il sera difficile de leur imposer l’usage du moteur de recherche de l’intranet, ou d’apprendre l’interface utilisateur de dizaines d’applications. L’idée est donc de dissocier la base, contenant les métadonnées qui constituent le catalogue, et l’outil d’interrogation qui devient le LLM. Comment interroger le catalogue central via le LLM ? En choisissant un catalogue compatible avec le nouveau protocole MCP. Ce protocole MCP (Multi-Cloud Protocol) est un cadre technique conçu pour faciliter l’interopérabilité, la portabilité et la gouvernance des données entre différents environnements cloud (publics, privés, hybrides). Il vise à standardiser les échanges de données, les métadonnées et les politiques de sécurité. Il a été développé par Anthropic en 2024. Il s’agit d’un standard ouvert, développé en collaboration avec la communauté et hébergé par la fondation Linux, qui permet une intégration standardisée entre les applications d’IA et les sources de données ou outils externes. Plusieurs implémentations, SDK et serveurs MCP sont disponibles en open source sur des plateformes comme GitHub, encourageant ainsi l’interopérabilité et l’innovation collaborative. Alation, Atlan, DataHub, Datadog (liste non exhaustive) ont déjà annoncé une compatibilité MCP de leurs catalogues de données. Un pari risqué pour les éditeurs de catalogues de données Sur le papier, cette nouvelle architecture est séduisante, même pour les éditeurs de logiciels. L’éditeur n’a plus à se préoccuper de l’interface utilisateur métier. Il peut se concentrer sur sa cible privilégiée, le département informatique en charge de la mise en place. L’interface d’administration subsiste ; celle des usages est déléguée au LLM. Mais il y a un revers à la médaille, la disparition du catalogue de données dans les couches cachées accédées par le LLM. Le catalogue devient invisible ! C’est très bien me répondrez-vous ? Peut-être… sauf pour son éditeur. A la question : « quel est votre outil de catalogage de données ? » posée à un utilisateur métier, ce dernier répondra sans doute « Euh… je ne sais pas… c’est Copilot, Mistral, ChatGPT… ? ». Car pour lui, le catalogue aura disparu, noyé dans son LLM utilisé quotidiennement. Conséquences pour les éditeurs : une perte de valeur visible et une plus grande interchangeabilité. Car si mon catalogue est une simple base de données, sans interface utilisateur, accédée de manière standard via un serveur MCP, je peux facilement le remplacer par un autre ; et cela sans que l’utilisateur n’en ait conscience. Du point de vue de l’éditeur, le risque est grand de voir sa valeur perçue réduite à peau de chagrin. Autre question, celle de la responsabilité en cas de réponse erronée. L’utilisateur fera-t-il la part des choses entre les erreurs dans le catalogue, et celles générées par le LLM ? Si l’information de base est correcte dans le catalogue, mais que le LLM répond mal à la question posée par l’utilisateur… à qui la faute ? Et à qui la perception de la faute ? En conclusion La standardisation des catalogues de données, accédées par les LLM au travers de serveurs MCP semble donc une évidente amélioration. Pas le LLM standard que vous utilisez à titre personnel, mais un LLM sur mesure, personnalisé et entrainé pour votre organisation, comme va le proposer Mistral avec son offre Forge . Le LLM deviendra peu à peu l’outil quotidien de chaque employé, qui l’utilisera pour poser toutes ses questions. Le LLM ira alors piocher, via des serveurs MCP, dans les différentes sources de données, catalogue, entrepôt de données, lac de données, applications métier. Le navigateur web était devenu depuis une vingtaine d’années l’interface standard des applications qui migraient vers le cloud. Le LLM sera sans doute la prochaine étape. Cette évolution ne se fera pas instantanément, ni sans conséquences, mais reparlons-en d’ici cinq ans, elle sera sans doute devenue une évidence. https://www.usine-digitale.fr/intelligence-artificielle/mistral-ai/mistral-ai-lance-forge-un-service-de-creation-de-modele-dia-sur-mesure-pour-les-grandes-entreprises.NFBAALPLMNEO7ECP62HMAC35JY.html /episode/index/show/decideo/id/40811660

#6.8 Un catalogue de données social et orienté utilisateurs 04/07/2026

#6.8 Un catalogue de données social et orienté utilisateurs Un catalogue social de données, orienté utilisateurs Il y a quelques mois, j’ai travaillé pour une grande entreprise sur la formalisation des caractéristiques du catalogue de données idéal. « Social et orienté vers ses utilisateurs » sont ressorties comme les caractéristiques essentielles d’un catalogue efficace en 2026… ou 2027. Un catalogue social, c’est-à-dire conçu comme tous les outils que nous utilisons au quotidien, qui favorisent l’interaction, la création de contenu par l’utilisateur, la simplicité d’utilisation, et l’intégration aux applications existantes. Mais surtout conçu pour ceux qui l’utiliseront et non pour ceux qui le mettront en service. Un catalogue entièrement pensé en faveur de l’expérience utilisateur. Social : au croisement de Google Maps, LinkedIn et Tinder Pensez à votre journée, aux interactions que vous menez avec l’information, à titre personnel. Et si vous n’y croyez pas, regardez ceux qui nous remplaceront dans quelques années, les fameux millénaux. Commander un Uber et lui donner une note, réserver un Airbnb pour le week-end et laisser un commentaire, sélectionner un restaurant sur Google Maps et lui attribuer des étoiles en publiant des photos, laisser un message à un collègue sur LinkedIn pour sa nomination, glisser vers la droite ou vers la gauche les profils qui apparaissent sur votre fil Tinder… et la litanie pourrait continuer longtemps. Notre vie numérique est devenue sociale. Cela a pris vingt ans, mais ces interactions sont maintenant au cœur de notre vie quotidienne. Et une fois arrivé au bureau, après avoir allumé votre PC, la consultation de votre catalogue de données ressemble à un vieux Minitel : une dizaine d’onglets, des dizaines de champs, et presque aucune interaction. Et vous vous demandez encore pourquoi vos utilisateurs ne l’adoptent pas ! Demain, votre catalogue de données, si vous souhaitez qu’il soit utilisé, devra : - Permettre de noter chaque donnée et de consulter les notes attribuées par les autres utilisateurs ; des notes et de commentaires sur l’expérience des autres : qualité, conformité, fréquence de mise à jour, intérêt… - Dialoguer avec le référent de chaque donnée, et avec ses autres utilisateurs, au travers d’un « chat » propre à chaque donnée. - Signifier votre intérêt pour cette donnée par un simple « swipe » comme dans Tinder. Nous verrons si vous « matchez » avec le data owner ! Le catalogue de données de demain sera social ou… ne sera toujours pas utilisé par les métiers ! Éditeurs de logiciels, à vous de faire en sorte qu’il soit l’application que tout data worker ouvre chaque matin et garde toute la journée sur un coin de son bureau. Choisi pour ceux qui l’utilisent, pas pour ceux qui le construisent Récemment, une grande organisation me contait son processus de choix d’un catalogue de données centralisé. Processus piloté par la direction informatique (ce qui est compréhensible), mais qui semble oublier ou minimiser les perceptions de ses futurs utilisateurs. Un catalogue de données est en effet destiné à être utilisé ! Plus les utilisateurs métiers prendront l’habitude de le consulter pour y rechercher l’information dont ils ont besoin, plus le succès sera au rendez-vous. Même si le projet est mené par la direction informatique, ce n’est pas la satisfaction des utilisateurs-informaticiens qui en sera l’indicateur principal, mais celle des utilisateurs métiers. Dans mon exemple, la direction informatique compare plusieurs solutions et sa préférence va à un outil technique, un catalogue de données en open source, mais dont l’interface utilisateur est loin d’être intuitive pour des non-informaticiens. Les départements métier, également consultés, ont eu choisi un catalogue simple, efficace, à l’interface utilisateur beaucoup plus accessible. Qui va l’emporter ? Je crains de connaître le vainqueur par avance… ainsi que la suite de l’histoire lorsqu’une année après, on reprochera au catalogue, et au responsable de la gouvernance, de ne pas être entré dans les habitudes des utilisateurs métier. Mon conseil, comparez les solutions, établissez des impératifs techniques à respecter, mais in fine, laissez ceux qui l’utiliseront au quotidien établir leur préférence. L’équipe de mise en place passera quelques mois à l’installer et le paramétrer ? Des centaines d’utilisateurs passeront des années à le consulter ! Devinez qui devrait choisir l’interface utilisateur qui lui plait le plus… Deux critères clefs pour eux : - Une interface de mise à jour simple : si vous souhaitez que l’utilisateur métier mette à jour les métadonnées dont il est le référent, il faut que cette mise à jour soit ludique ! - Proposez une recherche en langage naturel comme « quelle donnée est disponible pour évaluer le chiffre d’affaires par client ? ». Vous voulez mettre de l’IA ? C’est ici qu’elle se justifie Ni centralisé, ni décentralisé, mais fédéré. Depuis longtemps, le catalogue des métadonnées est pensé centralisé. Est-ce la bonne méthode ? S’il est si compliqué d’en faire adopter l’usage par les utilisateurs métier, c’est peut-être qu’ils s’en sentent éloignés ; qu’ils le perçoivent comme un outil de plus géré par la direction, plutôt que comme un outil destiné à leur faciliter l’accès aux données. Par ailleurs, est-il logique que les métadonnées soient centralisées, alors que les données sont de plus en plus gérées dans les départements métier ? Les métadonnées ne devraient-elles pas rester au plus proche des données ? Mais alors, si les métadonnées sont décentralisées, comment s’assurer que les différents métiers les gèrent de manière cohérente, dans un objectif de partage à travers l’ensemble de l’organisation ? Pour cela il ne faut pas passer de la centralisation à la décentralisation, mais à la fédéralisation : des métadonnées décentralisées, mais qui respectent une gouvernance centralisée. Comme dans un État fédéral, certaines compétences sont déléguées aux métiers, d’autres relèvent de décisions centralisées (prises par exemple par le comité de gouvernance des données). Pour creuser cette idée de maille de métadonnées, lisez ce qu’a publié Ole Olesen-Bagneux sur le thème du Meta Grid : et son livre Fundamentals of metadata management (). Interopéré par des contrats de données Aimez-vous faire plusieurs fois la même chose ? Non, et c’est normal. Alors, pourquoi ne pas essayer de profiter d’un travail pour en réaliser plusieurs ? Vous réalisez des interfaces entre applications, entre utilisateurs de données. Ces interfaces incluent un schéma de données. Vous pourriez utiliser cette description d’interface pour alimenter partiellement, mais automatiquement votre catalogue de données. C’est toujours cela de pris, et cela avance le travail du référent données. Pour cela, vous devez formaliser vos contrats d’interface, en utilisant des contrats de données (data contracts), et vous avez de la chance. Jean-Georges Perrin et l’équipe de volontaires de Bitol (membre de la fondation Linux) ont travaillé pour vous. Ils ont conçu ODCS (Open Data Contract Standard) qui permet l’interopérabilité entre les outils qui y adhérent, grâce à un standard open source. En l’adoptant, vous disposerez de contrats de données qui pourront alimenter un ETL, mais aussi votre catalogue de métadonnées, ou encore l’outil d’observabilité du data steward. I had a dream… Alors non, malheureusement, ce catalogue social, compatible ODCS/OPDS, et fédéralisé des informations n’existe pas encore ! Mais ses bases sont claires. Visionnaire, certainement. Réaliste, pas encore ? Mais face aux nombreuses difficultés liées à l’implémentation des catalogues existants, il faut un « reset ». Je rêve d’un catalogue imaginé comme un produit Apple, que l’on soit fier de montrer, et non comme un produit Microsoft où il faut aller dans le menu Démarrer pour Éteindre… Pour que l’alchimie fonctionne, il faudrait que les utilisateurs manifestent de l’intérêt pour un catalogue conçu en fonction de leurs besoins ; que les informaticiens conçoivent qu’un catalogue de données est destiné à être utilisé et pas simplement construit ; et que les responsables de la gouvernance mettent en avant l’indicateur du taux d’usage et non de la complétude théorique. Quel éditeur est prêt à relever le défi ? Si vous voulez en savoir plus et expérimenter tout cela, participez aux formations sur la gouvernance des données que je donne tout au long de l’année. /episode/index/show/decideo/id/40735440

#6.7 IA, RH et données avec José Rodriguez, Cornerstone 03/30/2026

#6.6 Les agriculteurs dépossédés de leurs données, avec Caroline Gans Combe 03/23/2026

#6.5 Alain Garnier, Jamespot, défend une diversité souveraine 03/16/2026

#6.4 Observabilité : attitude et outils du data steward 03/09/2026

#6.4 Observabilité : attitude et outils du data steward L’observabilité : attitude et outil du data steward Observer vient de la racine latine observare, qui signifie « noter ou considérer », mais aussi « garder en sécurité ou protéger ». Quelle belle proximité avec la fonction de data steward ! Or aujourd’hui le rôle du data steward n’est plus simplement de se préoccuper de qualité des données, mais réellement de mettre en œuvre l’observabilité. Plutôt qu’un steward, il est plutôt d’ailleurs un contrôleur aérien de vos data. Il ne pilote pas mais surveille et organisme le trafic et reporte les incidents. À sa disposition, des outils d’observabilité, à chaque version plus complets, et demain des agents qui lui remonteront l’information. Mais avant même les outils, c’est cette attitude d’observation qu’il mettra en œuvre. Observer n’est pas faire ! Il est crucial qu’il le comprenne. Le data steward n’est pas là pour faire à la place des data owners et data consumers, mais pour apporter une supervision transverse des principes de gouvernance. C’est l’observabilité, et elle s’appuie sur les outils du même nom. Observer l’ensemble de la chaine de traitement de la donnée La data observability vise à donner une vision continue et intelligente de la « santé » des données : leur fraîcheur, leur volume, leur distribution (anomalies), les changements de schéma, les dépendances (data lineage), et la capacité à diagnostiquer rapidement les racines des incidents. On peut voir la data observability comme l’évolution du monitoring de données (alertes statiques) vers un système plus proactif, piloté par des métadonnées et des techniques analytiques. Une donnée circule ; le data steward en a une vision globale, au travers des métadonnées d’usage collectées automatiquement : les flux prévus ont-ils été honorés, l’usage des outils de sécurisation (data platform) est-il respecté, la cohérence est-elle maintenue d’un bout à l’autre du système. Dans une architecture centralisée, mais surtout dans une architecture fédéralisée autour de data products, sa mission de supervision des processus est indispensable. Si votre data mesh prévoit la mise en place de data contracts, le data steward supervisera leur exécution, et remontera les incidents. Observer plusieurs dimensions Initialement focalisé sur la qualité des données, le data steward voit ses missions évoluer. La qualité en reste le cœur, mais il lui revient d’observer l’ensemble des circulations de données. Son attention débute lors de l’entrée des données dans le système d’information. Il se préoccupera alors de vérifier que les contraintes de sécurité et de conformité des données sont respectées. Lors de chaque mouvement d’une donnée, il surveillera la traçabilité (le lineage). En cas d’alimentation d’outils d’IA, il s’assurera du respect des usages de la charte et de la règlementation. Qualité, conformité, sécurité et usages sont les principales dimensions de son action. Travaillant au plus proche des métiers, le data steward et ses outils d’observabilité permettront de remonter la température de la plateforme de données au comité de gouvernance. En cas de dérive d’un des indicateurs, il est susceptible de faire remonter l’incident pour arbitrage. Sifflet, Soda.ai… des startups qui montent Montecarlo, Acceldata, Bigeye, Validio, Metaplane, Sifflet, Soda, figurent parmi les principaux acteurs spécialisés de l’observabilité des données. Les grandes plateformes telles que Collibra, Datadog, New Relic, Splunk, Elastic, proposent également des fonctions ad hoc. Peu de solutions open source semblent disponibles à l’exception de OpenTelemetry, mais qui nécessite de gros efforts de développement. De l’observabilité des données à celle de l’IA L’IA est au service de l’observabilité, au travers des agents que les outils envoient pour capter les informations tout au long de la chaine de la donnée. Mais l’observabilité est également au service de l’IA car, tout comme les données, les modèles et usages de l’IA doivent respecter des règles de gouvernance, et donc être observés. Les meilleurs outils d’observabilité incluront donc des fonctions de suivi des modèles, de détection des biais, des discriminations, des hallucinations, des usages non éthiques ou non conformes à la politique ESG de l’entreprise. L’IA sera également mise à contribution pour détecter les usages non officiels, le shadow AI, le shadow BI, etc. Du data au AI steward Cela amènera naturellement notre data steward à élargir ses compétences. Il est passé du monitoring de la qualité à l’observabilité globale. Il passera également de la donnée à l’intelligence artificielle. Le Data & AI Steward, une fonction indispensable pour implémenter de manière pratique, et contrôler l’application des principes de gouvernance. En résumé, voici quelques idées pour comprendre comment évoluera en 2026 le marché des outils et techniques d’observabilité : - Consolidation des plateformesOn observe une tendance à intégrer les capacités de data observability dans des plateformes plus larges (analytique, gouvernance, monitoring général). Mais les solutions spécialisées et interopérables proposent plus de fonctionnalités. - Approche « AI-driven observability » Les outils intègrent des algorithmes pour automatiser la détection d’anomalies, prévoir les incidents ou suggérer des correctifs dans les modèles d’IA. - Bring-Your-Own Storage / backends interchangeables Permettre aux utilisateurs d’utiliser leurs propres lacs de données ou entrepôts comme stockage (plutôt que d’imposer un stockage « shadow ») pour réduire les silos. Attention cependant à la création de nouveaux silos qui ne respecteraient pas les règles de sécurité, de conformité et de gouvernance. - Observabilité « pipelined » (observabilité de pipelines métadonnées vs télémétries classiques) La surveillance non seulement des résultats (données) mais du comportement des pipelines eux-mêmes (durée, erreurs, retards) devient centrale. - Focus sur les coûts, l’évolutivité et le « data observability FinOps » À mesure que les volumes de données augmentent, les organisations veulent maîtriser le coût de surveillance (stockage, calcul, alertes). - Extension vers l’observabilité des modèles/IA/ML Comme les pipelines de données alimentent de plus en plus des modèles ML/IA, l’observabilité s’étend vers le suivi des performances des modèles, la dérive, etc. /episode/index/show/decideo/id/40339730

#6.3 Automatisation des services comptables avec Geoffrey Nozerand, Dext 03/02/2026

#6.2 Raffineur de données 02/23/2026

#6.2 Raffineur de données Raffineur de données : un métier indispensable à l’IA Imaginez que vous ayez conçu le meilleur moteur de voiture jamais fabriqué ! Efficient, puissant, économe, silencieux, non polluant… il a toutes les qualités, et vous allez révolutionner le monde du transport grâce à votre invention. Seul bémol, il nécessite pour fonctionner un carburant beaucoup plus pur que ce que l’on trouve aujourd’hui dans nos raffineries. Et ce carburant est indispensable à votre moteur révolutionnaire. Sans lui, votre invention n’est qu’un assemblage inutile de pièces de métal. C’est ce qui arrive aujourd’hui à la majorité des projets d’IA en entreprise. Les modèles sont surpuissants, mais restent de perpétuels adolescents face à la pauvreté des données à partir desquelles vous les alimentez. Vous n’avez pas investi suffisamment dans le raffinage de vos données. « Mais nous avons un data lake depuis plusieurs années ! », me répondrez-vous. Oui, certes, mais appelez-le plutôt un data débarras ! Vous y déversez des données brutes, sans les indexer, sans les référencer, sans les qualifier, sans les améliorer, sans les organiser… tout cela parce qu’un vendeur de data lake vous a convaincu qu’il contenait un Monsieur Propre qui allait se charger de tout. Reconnaissez que vous avez été bien naïf sur ce sujet… Et vous continuez d’ailleurs puisque vous avez cru cet autre vendeur qui vous a convaincu que l’intelligence artificielle elle-même allait savoir créer ses propres métadonnées, et rendre votre débarras miraculeusement aussi propre et documenté qu’un entrepôt de pièces détachées Airbus ! La donnée brute est devenue abondante, bon marché et disponible. Mais la donnée structurée, connectée, contextualisée, documentée, expliquée, celle qui permet l’automatisation réelle, la prédiction et la prise de décision, reste rare. Forcément, elle est plus couteuse et complexe à produire à partir de la donnée brute. Et surtout elle nécessite un effort humain… ce qui n’est pas à la mode en ces temps d’automatisation à outrance. Poursuivant notre analogie automobile, la donnée brute, c’est le pétrole sorti des gisements. La donnée raffinée, c’est le carburant, produit par les raffineries. Et plus votre modèle est avancé, plus le raffinage doit être poussé. Essayez de mettre du pétrole brut dans une voiture… ça marchera beaucoup moins bien. Car l’essence que vous utilisez est raffinée. Elle subit des procédés complexes pour : augmenter son indice d’octane, éliminer le soufre et les impuretés, ajuster sa volatilité, et améliorer sa combustion. Le raffinage nécessaire à vos modèles d’IA est encore plus complexe que la transformation de pétrole brut en essence. En matière de données, c’est exactement la même chose. Utilisez des données brutes dans un modèle, et les résultats seront standards, pas exceptionnels. Vous serez à la portée d’hallucinations et de biais, non pas dus au modèle, mais à vos données. Raffinez vos données et vos modèles pourront enfin s’y appuyer pour produire des résultats exceptionnels. La valeur n’est plus dans le modèle. Elle est dans la capacité à raffiner la donnée. Le raffineur est donc le métier le plus créateur de valeur dans la chaine de production de l’intelligence artificielle. Qui est-il ? Quelles sont ses compétences ? Quelles qualités sont nécessaires ? Je ne tomberai pas dans le piège d’inventer un nouveau métier de Data Refiner. Ce n’est pas le sujet. Tout le monde peut être ou devenir raffineur de données. Mais voici les compétences nécessaires : - Premièrement une connaissance du métier est indispensable. Le raffineur peut donc venir directement du métier, ou être un analyste d’affaires qui se spécialiserait dans l’analyse des besoins en données des modèles d’IA. On évitera un raffineur venant du département informatique, à moins qu’il ne connaisse parfaitement le métier. - Une compréhension étendue du concept de métadonnées est nécessaire. Décrire, expliquer, documenter, formaliser, structurer, organiser… cela passe par la création d’une ontologie, d’une couche sémantique commune. Toutes ces compétences sont souvent détenues par des professionnels du document électronique. Documentalistes et archivistes auront ici une carte à jouer. Et les graphes de connaissance n’ont déjà plus de secrets pour eux. - Et finalement une aptitude à écouter, faire émerger des non-dits, et retranscrire des besoins. Encore une fois, l’analyste métier est à l’aise avec ce mode de fonctionnement. Oreille externe, il cherche à comprendre, à poser les questions, à faire émerger les besoins. Exprimer les attentes de préparation des données brutes pour alimenter les modèles d’IA me semble donc un projet d’analyse métier. Les parties prenantes sont les informaticiens en charge du projet IA, les métiers demandeurs et futurs utilisateurs, le département juridique ou le DPO pour évoquer les sujets réglementaires. Et les livrables sont le projet permettant le raffinage des données brutes en données exploitables par les meilleurs modèles d’IA. C’est une spécialisation à intégrer dans une formation sur l’analyse métier ! /episode/index/show/decideo/id/40188365

#6.1 Valorisation et monétisation : quelles différences ? 02/17/2026

#6.1 Valorisation et monétisation : quelles différences ? Différences entre valorisation et monétisation Collectées, stockées et analysées depuis tant d’années, les données sont enfin adultes. Il est maintenant temps de leur permettre d’accéder à leur indépendance financière. La prochaine décennie sera celle de la valorisation et de la monétisation des données. Le phénomène a déjà commencé, il y a plusieurs années. Au travers des réseaux sociaux, nos données ont pris de la valeur, même si elle ne nous est pas toujours attribuée. Des règlements ont conduit, en particulier en Europe, à encadrer un peu l’usage de nos données personnelles. Et les techniques comptables et financières (IAS/IFRS) abordent maintenant le sujet de leur valorisation. Valoriser, c’est donner une valeur Établir la valeur d’une donnée, c’est lui adosser un chiffre et une unité de compte, qui permet de la comparer avec d’autres. L’unité de compte qui vient en premier à l’esprit c’est la monnaie, l’Euro, le dollar, le bitcoin… peu importe. Mais on pourrait en utiliser d’autres, en particulier pour mesurer des impacts sociaux ou environnementaux. Définir la valeur de quelque chose dépend fondamentalement du cadre d’analyse que l’on adopte. Il n’existe pas une définition universelle et intemporelle de la valeur, mais un ensemble de définitions cohérentes selon les disciplines, les acteurs et les usages. Une définition générale pourrait en être la suivante : l’importance relative attribuée à un objet, une action ou une ressource par un acteur donné, dans un contexte donné, au regard d’un objectif donné. En entreprise, la valeur d’un bien ou d’un service pourrait être définie de la manière suivante : la contribution mesurable ou appréciable d’un actif à l’atteinte d’objectifs économiques, opérationnels, stratégiques ou réglementaires, pour un ensemble d’acteurs identifiés. Combien valent vos données ? Combien vaut votre data warehouse ou votre data lake ? Comment les estimer, les valoriser ? C’est un sujet qui deviendra clef dans les prochaines années. Pourquoi ? … parce que pour monétiser des données, je dois les valoriser ! Monétiser c’est transformer les data de centre de coût en centre de profit La donnée est un actif, immatériel, qui a une valeur comme nous venons de le définir. Peut-on transformer cette valeur en espèces sonnantes et trébuchantes ? Oui, cela s’appelle la monétisation. Je ne vais pas vous faire vendre votre fichier client, ou vos données personnelles ! Mais croire que seules ces données ont de la valeur pour quelqu’un c’est très réducteur. Un centre commercial qui analyse ses visiteurs… quel pourcentage d’hommes et de femmes, combien ont un chapeau, des enfants, un parapluie, un sac en cuir ou un sac en plastique ? Un péage d’autoroutes qui analyse les marques et modèles de voiture qui entrent et sortent, la présence d’un coffre de toit, de vélos, d’une remorque ? Si ces analyses statistiques n’ont pas de valeur pour lui, elles en auront pour quelqu’un, qui sera prêt à les acheter ou les louer. L’open data était un premier pas, l’économie de la donnée est le second. Cela passe par des produits de données, des contrats associés, des espaces de données, et des places de marché (data products, data contracts, data spaces et data marketplaces). Nous étudierons tout cela. Monétiser c’est transformer la valorisation en réalité économique. /episode/index/show/decideo/id/40136425

#5.10 Archives, documents, données... tant de points communs ! 09/02/2025

#5.9 L'éthique de l'IA expliquée à mon fils, avec Enrico Panaï 04/23/2025

#5.8 Natalie Maroun nous parle de données et de communication de crise 04/17/2025

#5.7 Data Chain, une plateforme de données française, avec Sandra Mathieu de Adobis Group 03/28/2025

#5.6 De l'IA oui, mais pas sans Data Spaces, avec Matthias de Bièvre, VISIONS 02/28/2025

#5.5 Le nouveau SaaS, vous connaissez ? 01/02/2025

#5.5 Le nouveau SaaS, vous connaissez ? Un « nouveau » paradigme apparait, le SaaS ! Non, pas celui que vous croyez ! Vous vous dites, ça y est, on l’a perdu ! Il est resté en 1999 à la création de Salesforce ! Non, car si le SaaS est bien vivant depuis 25 ans, le nouveau SaaS pointerait le bout de son nez selon les oracles du marketing. Nous serions en train de passer du Software as a Service au Service as a Software. Que c’est beau le monde du marketing ! Allez, je vous explique. Le principe du Software as a Service a combiné depuis plus de deux décennies l’évolution technologique du cloud computing, et la migration du modèle d’achat de licences logicielles vers celui d’abonnement. Les deux éléments sont indépendants, mais en réalité ces deux évolutions ont été concomitantes. Au lieu d’acheter un logiciel, vous souscrivez à un abonnement, qui comprend le droit d’accès au logiciel, l’infrastructure technique, et les services associés. Un forfait en quelques sortes, mais payé chaque mois. À court terme, le coût en est bien plus intéressant et plus flexible, à long terme un peu moins, cependant dans un marché en évolution perpétuelle, tout le monde est gagnant. Mais voilà, l’intelligence artificielle (je ne sais pas trop ce qu’elle vient faire là), et 20 ans de SaaS ont épuisé les ressorts marketing et commerciaux. Il fallait réinventer ! Et l’on serait donc en train de remplacer le SaaS par le SaaS ! Le Service as a Software serait la combinaison d’une plate-forme technologique, et de services assurés par des humains… ou des IAs. Un bon exemple est le logiciel QuickBooks très populaire en Amérique du Nord, et qui permet à chacun de s’acquitter de ses travaux comptables et de ses déclarations fiscales. Ces dernières ne sont pas réalisées par le client, mais par un comptable, qui utilise le logiciel, complété de ses compétences. Et dans le cas de QuickBooks, le comptable pourrait être une IA. Cela fait dire à certains analystes que le développement des agents intelligents conduit cette transformation du marché. Le client ne s’abonne plus à un logiciel qu’il utilise, mais à un service que lui rend une IA, avec un peu d’humain, parfois. Si l’on reprend l’exemple de Salesforce, un commercial humain entre les données d’un nouveau client, puis les agents dans Salesforce créent automatiquement le flux d’actions de proposition, de relance, de vente. Les nouveaux SaaS remplaceraient donc certains humains chez leurs clients. Tout cela n’est pas totalement nouveau. D’abord, désolé de reparler du passé, mais cela existe depuis la nuit des temps, cela s’appelle de l’externalisation. Lorsque j’envoyais mes documents comptables à mon expert-comptable et qu’il les saisissait dans son logiciel pour ensuite réaliser mes déclarations fiscales, c’était donc déjà du Service as a Software. N’allons pas réinventer des mots qui n’apportent aucune nouveauté, juste pour être « moderne ». Tiens, clin d’œil, ils auraient pu faire comme la Modern Data Stack, et l’appeler Modern SaaS ! Plus sérieusement, la nouvelle donne vient de l’automatisation des processus. Là encore rien de nouveau, à part si cette automatisation est réalisée par des agents intelligents qui prendraient eux-mêmes, en fonction des circonstances, les bonnes décisions. Attention, pas un système expert qui se contente d’exécuter ce que l’expert a programmé – ça on le fait depuis les années 70 -, mais un véritable agent intelligent qui prendrait seul des décisions en fonction d’un entrainement à partir de données historiques. Selon Foundation Capital, cela représenterait un marché de presque 5000 milliards de dollars. Tout dépend bien sûr de ce que l’on met dedans. En tout cas, des dizaines d’entreprises sont déjà identifiées comme fournisseurs de Service as a Software. Si vous êtes un prestataire, qui réalise des travaux pour le compte de ses clients, de manière externalisée ; ne dites plus que vous faites de l’outsourcing, mais du Service as a Software, votre valorisation explosera peut-être ! Et puis, dites-moi ce que vous pensez de tout cela en commentaire. /episode/index/show/decideo/id/34697115

#5.4 Jean-Georges Perrin, Pape du Data Mesh et des Data Contracts 11/16/2024

#5.3 Cartographie des données et des systèmes avec David Bougearel de Cartographit 10/20/2024

#5.2 IA ? Et si nous parlions français ! 09/11/2024

#5.2 IA ? Et si nous parlions français ! Vous en avez assez d’entendre parler de LLM, de prompt, de text token, ou de adversarial machine learning ? Ça tombe bien, le 6 septembre dernier, le Journal Officiel de la République Française a publié, pour la rentrée des classes, la liste relative au vocabulaire de l’intelligence artificielle. La commission d’enrichissement de la langue française a retenu quatorze termes ; elle les a traduits, et définit. Ainsi, vous pourrez parler de Grands Modèles de Langage, les GML ; d’instructions génératives pour les prompts, de jeton textuel pour les text token, et d’apprentissage antagoniste pour l’adversarial machine learning. Plus aucune excuse pour truffer vos textes et vos vidéos de ces anglicismes qui ne rendent pas hommage à notre langue. Ça fait plus chic ? C’est plus court ? Tout le monde le dit ? Toutes ces excuses sont valables, mais avec un petit effort, vous verrez que vos textes en ressortiront de meilleure facture. Et ne devenez pas ces directeurs marketing que je rencontre régulièrement et qui commencent leur présentation en s’excusant des mots anglais qu’ils utiliseront… sous prétexte que, vous savez, je vis aux States depuis plusieurs années, et je ne sais plus comment on dit en français. Cinq pages du JO du 6 septembre à imprimer donc, et à garder bien visible sur votre bureau. Ah tiens d’ailleurs, il y en a un qui manque ! Je n’ai pas trouvé la traduction de RAG, Retrieval Augmented Generation. Il va falloir continuer l’enrichissement du dictionnaire. J’ai trouvé sur Internet une traduction sous forme de Génération Augmentée de Récupération. Pourquoi pas. Qu’en pensez-vous ? A tiens, amis québécois qui nous écoutez, vous qui êtes si prompts à défendre la langue française, montrez l’exemple ! Le problème c’est que nous ne sommes pas toujours d’accord sur les traductions… Ainsi l’Office Québécois de la Langue Française recommande d’utiliser le terme de « requête » pour désigner les prompts. Alors requête ou instruction générative ? Qu’en pensez-vous ? /episode/index/show/decideo/id/33004657

#5.1 Le MIT classe 777 risques potentiels liés à l'IA 09/01/2024

#5.1 Le MIT classe 777 risques potentiels liés à l'IA Le MIT a recensé 777 risques potentiels liés à l’IA dans une base de données partagée gratuitement Cet été, le MIT nous a fait un cadeau ! Le prestigieux organisme de recherche américain a publié un référentiel complet des risques liés à l’intelligence artificielle. L’objectif : vous aider à cartographier l’ensemble des risques qui pèsent sur votre entreprise afin de les mesurer, les quantifier et les mitiger par la suite. Si vous suivez mes contenus sur le thème de la gouvernance des données et de l’intelligence artificielle, vous avez déjà été sensibilisé au fait que la mise en place d’un cadre de gouvernance passe par l’identification et la cartographie des risques. Comment en effet atténuer quelque chose que l’on n’a pas référencé et mesuré ? Première tâche donc, l’identification et la cartographie des risques en matière d’intelligence artificielle. Risques liés aux données, aux modèles, aux usages, les risques sont nombreux. Et l’IA Act européen prévoit d’ailleurs l’obligation de les identifier et de les suivre, afin de classifier les modèles d’IA en fonction des risques encourus. Mais partir d’une feuille blanche et se gratter la tête en faisant le tour des bureaux n’est pas la méthode la plus efficace. Or il n’existait pas jusqu’à présent un référentiel unique, mais plusieurs référentiels, tous incomplets, et orientés. Ces derniers mois, les équipes du MIT ont réalisé un travail de compilation et d’organisation de l’ensemble des référentiels qu’ils ont pu identifier ; regroupant l’ensemble des risques dans une taxonomie commune. The AI Risk Repository est donc un travail de synthèse des risques en provenance de 43 taxonomies différentes. Au total, 777 risques ont été identifiés, regroupés et ordonnés dans la taxonomie du MIT. Ce travail de synthèse est fourni sous forme d’un fichier Excel ou Google Sheets. Avec 777 risques décrits, c’est évidemment beaucoup trop pour la très grande majorité des entreprises, et un important travail de compréhension et de sélection reste à faire. Par ailleurs chaque entreprise devra évaluer le degré de survenance de ce risque dans sa propre organisation ; ainsi que les impacts de cette survenance sur son métier. Personne ne peut faire ce travail à votre place. Mais bien sûr, remercions le MIT pour cette synthèse qui permet de partir de quelque chose, d’envisager à peu près tous les cas possibles, et ainsi de progresser dans cette cartographie des risques liés à l’IA. Le framework à déployer est donc le suivant : - Commencez par prendre connaissance de la base de données des risques du MIT ; - Sensibilisez la direction générale à l’importance, et parfois à l’obligation, de connaitre le niveau d’exposition de l’entreprise ; - Programmez des ateliers avec les différentes personnes concernées, métier et informatique, afin de sélectionner dans la base du MIT les risques applicables à l’entreprise ; - N’hésitez pas à vous faire accompagner dans cette phase afin de démarrer correctement ; un consultant spécialisé peut être un booster et un garde-fou ; - Pour chacun de ces risques, évaluez leur probabilité de survenance, et les impacts, financiers et autres, de cette survenance éventuelle ; - Reportez tout cela dans un outil spécialisé de gestion de risques ou à défaut dans une feuille Excel ; - Mettez en place les stratégies de modération de ces risques ; - Ne pas oublier de répéter ce processus, lorsque les risques changent ou au minimum une fois par an, afin de maintenir à jour cette cartographie. Alors je vous entends déjà critiquer ! Jamais je n’aurai le temps de faire cela, la DG ne nous donnera pas de budget, encore un truc qui va rester sur les étagères, bla bla bla… Vous avez raison de vous inquiéter ! Mais en même temps soyons direct, ce n’est pas un choix. Bien sûr, une PME peut choisir de prendre des risques, sans les mesurer, et en assumer par la suite les conséquences. Mais assurez-vous que cette décision de ne pas cartographier les risques liés à l’IA soit bien prise au plus haut niveau. Et un conseil, protégez vos arrières, et conservez bien la trace de cette décision. Et si votre DG est plus raisonnable, et comprend l’importance de connaitre et mesurer ces risques, allez-y progressivement. Posez les premiers jalons, et commencez les ateliers. Tiens, par exemple, commencez par les nouveaux projets ! Un nouveau POC d’IA ? Dès la phase de POC, rapprochez-vous des équipes, abordez le sujet, et cartographiez les risques à la volée. En incluant la gouvernance de l’IA dans la phase de design des projets, le fameux « Governance by design », vous rendrez le sujet beaucoup plus fluide. C’est ce que j’appelle le DevSecGovOps, penser à la gouvernance dès la phase de conception, et en faire un élément essentiel de la mise en production. /episode/index/show/decideo/id/32668527

#4.24 Gagner aux JO, est-ce une question de data ? 08/02/2024

#4.24 Gagner aux JO, est-ce une question de data ? Vous avez 23 ans, vous mesurez 1 mètre 77, et vous pesez 72 kilos ? Vous avez, contrairement à moi, le profil idéal pour remporter le 100 mètres, épreuve reine de l’athlétisme aux jeux olympiques. Si en revanche vous avez plus de 27 ans… désolé, vous êtes déjà disqualifié par l’analyse statistique. Cependant, si vous êtes un peu en surpoids, jusqu’à 108 kilos, vous pouvez tenter le lancer de poids. Les grands triompheront au lancer de disque, quant aux plus petits qu’un mètre soixante… ils n’ont que peu de chance d’obtenir une médaille en athlétisme. Non, mesdames, je ne vous oublie pas. Et les statistiques semblent se rejoindre. Si vous avez 22 ans, que vous mesurez 1 mètre 66, et que vous pesez 57 kilos, la médaille du 100 mètres est à votre portée, mathématiquement. Là encore, quelques kilos supplémentaires vous permettront de tenter le lancer de poids. Les plus grandes lanceront le disque tandis que les plus petites triompheront au 10 000 mètres et au marathon. Commandité par JeffBet, un site de paris en ligne, l’étude porte sur les données de 222 500 athlètes olympiques, collectées depuis 120 ans. Pour JeffBet, remporter une épreuve dépend certes du courage, de la volonté, de l’entrainement, mais également de caractéristiques purement physiques. Et c’est l’idée de la société de paris en ligne, qui tente de convaincre que l’on peut améliorer ses probabilités de miser sur le gagnant, sans le connaitre, mais en étudiant uniquement ses données. Le livre Money Ball de Michael Lewis, publié en 2003, nous contait déjà l’histoire controversé d’un sélectionneur de baseball qui utilisait les données pour compenser le manque de moyens de son équipe, et identifier statistiquement les meilleurs joueurs. Alors que vous soyez pro-statistiques, persuadés que le monde est régi par la mathématique et les probabilités ; ou que vous soyez convaincu que les statistiques ne sont en aucun cas déterministes, oubliez un peu les data pendant quelques semaines, passez de bonnes vacances, et retrouvez de nouvelles émissions de votre podcast Decideo dès la rentrée de septembre pour une nouvelle saison, la cinquième ! /episode/index/show/decideo/id/32396852

#4.23 Gouvernance des données orientée métier, quelques prérequis 07/09/2024

#4.23 Gouvernance des données orientée métier, quelques prérequis Gouvernance des données : quelques prérequis organisationnels Ayant l’opportunité d’accompagner de nombreuses entreprises dans la mise en place d’une gouvernance des données orientée métier, je voudrais partager avec vous aujourd’hui quelques prérequis organisationnels. Eloignés des habituels conseils sur les outils à déployer, je constate que les premiers pas à réaliser, et pas les plus faciles, sont liés aux personnes et à l’organisation. Trois questions ! Qui ? Cela peut paraitre évident, mais dans la réalité, la nomination claire et affirmée de la personne chargée de coordonner la gouvernance des données dans l’entreprise n’est pas toujours une priorité. Or, sans bénéficier de l’onction de la direction générale sur le sujet, la personne en charge rencontra sur sa route toutes les embuches posées ça et là par les personnes qui ne voient pas dans leur intérêt qu’une gouvernance vienne fixer des bonnes pratiques là où ils préfèreraient que personne ne vienne mettre son nez. Donc, la première des choses à faire est de désigner une personne, de lui donner un titre de poste qui reflète cette fonction de mise en place des actions liées à la gouvernance, et de communiquer en interne sur le sujet. Récemment, un client m’expliquait que sa direction générale ne souhaitait pas envoyer un email pour indiquer à tous les employés que cette personne était maintenant en charge de mettre en place une gouvernance des données. Je lui souhaite bonne chance dans sa mission quand même la direction générale ne lui donne pas ses lettres de crédit ! Où ? La position de cette personne dans l’organisation est beaucoup plus importante que son titre. Je peux être nommé Data Governance Manager, mais si je suis au troisième sous-sol de l’organigramme dans une sous-direction, dépendant de la direction informatique… je n’aurai jamais l’oreille du comité de direction pour arbitrer les litiges qui apparaitront ; ni la crédibilité pour imposer aux métiers un code de conduite et des bonnes pratiques qui modifieront leurs habitudes. Les Américains ont choisi de placer la gouvernance des données, et de l’intelligence artificielle, directement au sein du comité de direction, en créant le poste de CIGO — Chief Information Governance Officer. Pas toujours facile dans les pays francophones de réunir le budget, la personne compétente, et la volonté de la direction générale pour créer ce niveau de poste. Du fait de mon expérience, je déconseille toute organisation dans laquelle le responsable de la gouvernance des données serait à plus d’un échelon du comité de direction. Je déconseille également — à quelques rares exceptions près — que la gouvernance des données orientée métier soit rattachée à l’informatique. Si elle ne peut pas être autonome, elle devrait être rattachée à l’audit, à une direction data ou digital. Le plus important est que le supérieur hiérarchique du responsable de la gouvernance puisse directement porter les messages au comité de direction, et obtenir sa validation ou son arbitrage. Là encore, il faut organiser et communiquer clairement en interne sur l’organisation, afin qu’il n’y ait aucune ambiguïté. Comment ? Qu’il s’agisse de la charte de gouvernance des données, du code de conduite de l’IA, de la classification des données sensibles, du catalogue des data products, de l’ontologie d’entreprise… la gouvernance des données passe par la formalisation d’un certain nombre de livrables. Outre ses qualités relationnelles, le responsable de la gouvernance doit faire preuve d’un excellent formalisme. Rédiger, expliquer, illustrer, présenter… est son quotidien. Outre l’indispensable traitement de texte qu’il utilisera quotidiennement, il a besoin d’un outil de diffusion du contenu qu’il produit. Tout sauf des classeurs qui resteront dans une étagère ! Un simple Wiki fera l’affaire, mais il lui permettra de diffuser ses livrables, de recueillir des commentaires, des suggestions, d’échanger avec sa communauté en interne. C’est le premier outil à mettre en œuvre, avant de passer à tout logiciel complexe. Ce portail accueillera son message de nomination, la composition du comité de gouvernance, puis viendront la charte de gouvernance des données, et l’ontologie ou le glossaire métier, en fonction du niveau de profondeur souhaité. Bon courage pour ces premières étapes. Comme elles touchent l’humain et l’organisation, elles sont à la fois indispensables et parfois les plus compliquées à accomplir. /episode/index/show/decideo/id/32061997

#4.22 La donnée sous tous les angles, avec Philippe Charpentier, CTO de NetApp 07/01/2024

#4.21 IBM se lance dans le data mesh avec Data Product Hub 06/26/2024

#4.21 IBM se lance dans le data mesh avec Data Product Hub IBM se lance à son tour dans le data mesh et les data products. L’entreprise l’a annoncé cette semaine, à l’occasion d’un séminaire de présentation de son offre appelée IBM Data Product Hub. Cette tendance, le « shift left », consiste à transférer peu à peu la responsabilité des data aux utilisateurs métiers, et l’autonomie qui va avec. Que vous appliquiez à la lettre les principes du data mesh ou si vous créez simplement des data products pour remplacer vos entrepôts de données centralisés, vous allez passer par la recherche et l’installation d’une plateforme de jeux de données. Amazon, SAP, Microsoft mais également des éditeurs spécialisés comme Zeena, Meta-Analysis ou Orkestra Data se sont lancés dans la course. Nous en avons déjà parlé ici. Signe que le sujet du data mesh devient incontournable, IBM se lance à son tour. Difficile de remettre en question ses habitudes de centralisation ! IBM annonce Data Product Hub, une plateforme, centralisée, pour stocker les data products. Les sources de données sont des entrepôts de données ou des lakehouses – 57 connecteurs sont annoncés. Les jeux de données peuvent ensuite être analysés avec Tableau, Watsonx de IBM ou encore en Python via la librairie Pandas. Le plan de développement prévoit l’incorporation d’IA générative dans les prochaines versions, fin 2024 et début 2025. Les consommateurs de données peuvent envoyer des requêtes, demandant à accéder aux données qui les intéressent. Les producteurs de données peuvent personnaliser les formats de génération des jeux de données, pour s’adapter aux besoins de leurs consommateurs. La gouvernance de l’ensemble est bien sur facilitée. Si vous utilisez le catalogue de données IBM Knowledge Catalog, le Data Product Hub pourra s’y connecter. Une intégration avec Informatica est prévue fin 2024. Les jeux de données peuvent être générés et stockés, ou pourront être virtualisés à partir de fin 2024. La génération et la mise à jour des data products sera automatisée dans la version de début 2025. Point très important, des data contracts et des niveaux de service peuvent être implémentés afin de gouverner les échanges de données. Un tableau de bord de suivi est même prévu. Ces contrats « lisibles par la machine » permettront dans la version de début 2025, de mettre en place un suivi automatisé de la gouvernance. Le Data Product Hub de IBM sera disponible en version on-premise, à l’achat ou à la location, ainsi qu’en version SaaS hébergée dans le cloud IBM, ou dans d’autres grands clouds. Une version d’essai de 60 jours sera proposée par l’éditeur. La version perpétuelle sera proposée à partir de 250 000 $, ou en location à partir de 100 000 $ par an. Le Data Product Hub est un nouveau composant ajouté à la Data Fabric de IBM. Préparant le futur, et la monétisation des données, IBM inclut une fonction de place de marché – on appelle également cela un Data Space. Mais dès maintenant, les consommateurs de données peuvent l’utiliser pour rechercher un jeu de données répondant à leurs besoins. Avec toutes les difficultés que l’on constate lors des tentatives de création de catalogues de données métier, on peut espérer que les catalogues de jeux de données seront adoptés, par les producteurs et les consommateurs, et seront alors correctement catalogués ! /episode/index/show/decideo/id/31897832

#4.20 Cinq ans de prison, si vous tentez de prévoir les décisions d'un juge 06/17/2024

#4.20 Cinq ans de prison, si vous tentez de prévoir les décisions d'un juge 5 ans de prison, si vous tentez de prévoir la décision d’un juge … mais comme toujours, les lignes jaunes sont contournables, pour peu que l’on prenne le temps de comprendre la loi. Je vous parle ici d’une disposition liée à l’utilisation de l’intelligence artificielle dans le cadre de procédures judiciaires, tentant de prédire quel sera le comportement de tel ou tel juge dans une affaire, et pour les parties prenantes d’adapter leur stratégie. Aux Etats-Unis, vous l’avez certainement vu dans de nombreuses séries criminelles, la technologie est utilisée pour analyser le profil de jurés, et tenter de prévoir leur positionnement, mais également pour analyser les décisions prises par chaque juge. Rien de bien nouveau, car les prétoires ont toujours été le berceau de rumeurs et de bruits de couloir : untel donne plutôt raison aux femmes, untel n’aime pas les hispaniques, untel est contre l’autodéfense, etc. Depuis toujours, les avocats ont imaginé améliorer leur stratégie, persuadés que les juges sont biaisés… tout simplement parce qu’ils sont humains. Un peu comme on commentait au lycée les professeurs qui nous étaient affectés en début d’année, les avocats commentent les juges qui leur sont affectés en début de procès. Mais au fait, les juges qui portent des lunettes sont-ils plus sévères que ceux qui ont une bonne vue ? Et les juges aux cheveux blancs sont-ils plus tolérants avec les jeunes majeurs ? Quand aux juges qui conduisent une peugeot, sont-ils plus sévères que ceux qui conduisent une Audi, dans les cas de violence conjugale ? Questions absurdes ? Peut-être. Mais si l’apprentissage machine nous apprenait le contraire. Que l’âge, la vue, la couleur des cheveux, la voiture qu’ils conduisent présentaient une corrélation avec leurs décisions. Si cela était mathématiquement prouvé, qu’est-ce que cela prouverait justement ? Que la justice est humaine, et donc biaisée. Dans ce cas, pourquoi ne pas l’analyser, et en utiliser les résultats ? Peut-être mais avec des limites très claires. Une loi publiée en 2019 précise en effet que les données nominatives des juges ne peuvent pas être utilisées. Il est donc interdit de prévoir la décision d’un juge en particulier dans une affaire. Mais elle ne peut empêcher la prédiction basée sur des caractéristiques, tant que celles-ci ne permettent pas de remonter à la personne, au juge. Alors, les juges qui se savent analysés gardent-ils le même comportement ? Où cela va-t-il les inciter modifier leurs décisions ? Les études menées depuis 2019 semblent montrer que globalement ces caractéristiques interviennent très peu dans les décisions. En revanche, les tribunaux, par le profil des affaires qu’ils jugent et leur volume, prennent clairement des sanctions différentes. Entre Bobigny et Versailles, les peines appliquées sont clairement différentes dans certains types d’affaires ? En viendra-t-on à préférer une justice artificielle, un algorithme qui appliquerait la loi, rien que la loi, sans aucune humanité ? Un film espagnol, Justicia Artificial, devrait d’ailleurs sortir en septembre prochain sur le sujet. /episode/index/show/decideo/id/31773187

#4.19 Données CSRD et ESG avec Nicolas Letavernier Workiva 06/12/2024

#4.18 Ethique et responsabilité de l'IA : et si la clef venait des graphes, avec Nicolas Rouyer, Neo4j 06/07/2024

#4.18 Ethique et responsabilité de l'IA : et si la clef venait des graphes, avec Nicolas Rouyer, Neo4j Alors que l’évolution de l’intelligence artificielle (IA) générative se développe à une vitesse exponentielle, bouleversant tous les pans de notre société, les législateurs, en Europe comme outre-Atlantique, doivent construire à marche forcée un cadre propice à un développement éthique et responsable de la technologie. Ainsi, courant mars, le Parlement Européen a approuvé la législation sur l’IA générative qui garantit la sécurité et le respect des droits fondamentaux tout en encourageant l’innovation. Celle-ci précise notamment que l'IA générative doit être aussi transparente que possible, en décrétant que les développeurs doivent démontrer précisément le fonctionnement du modèle et les données sur lesquelles il est entraîné. Par ailleurs, il y a quelques semaines, la CNIL publiait des recommandations quant au cadre juridique et aux bonnes pratiques pour le développement d'un système d'IA vertueux. Dans un tel contexte, et à mesure que l’IA générative et les grands modèles de langage se généralisent, l'intégration de ces technologies dans les opérations des entreprises s'accompagne de deux dilemmes éthiques importants : une utilisation transparente et responsable ainsi que des résultats fiables. Les graphes de connaissances pourraient constituer un moyen d'améliorer la transparence et la confiance exigées par la loi européenne sur l'IA. « L'IA générative progresse aujourd'hui à une vitesse jamais vue. Si l'on ne peut espérer que les décideurs politiques parviennent à suivre le rythme de cette innovation, l'absence d’un cadre et de normes garants d’un développement responsable de l’IA générative pourrait empêcher la société de prendre la pleine mesure du potentiel infini de cette technologie et de la mettre au service de l’intérêt général. Pour que ces systèmes profitent à la société dans son ensemble, inspirent confiance et répondent aux normes réglementaires clés, il est essentiel de prendre en compte l'infrastructure technologique au sens large et, surtout, les systèmes de gestion de données. Les graphes de connaissances se distinguent comme la structuration de données essentielle qui améliore les solutions d'IA générative en apportant plus de précision, de transparence et d'explicabilité. En effet, les graphes de connaissances permettent des interrogations, des déductions et des raisonnements sémantiques basés sur les relations. Ils jouent donc un rôle essentiel en agissant en complément de l'IA générative, en lui permettant de modéliser le raisonnement humain à plus grande échelle. Les graphes donnent un contexte plus profond aux données qui alimentent un modèle d’IA générative, ce qui permet l’explicabilité et la pertinence, pour éviter les hallucinations. De plus, grâce à la gestion fine des rôles et des droits sur les données de graphes, les organisations peuvent gérer au plus près la sécurité et la confidentialité. », analyse , Consultant Avant-ventes Senior chez . /episode/index/show/decideo/id/31643177

#4.17 Vivatech, les data et la réalité des entreprises africaines et européennes 05/27/2024

#4.17 Vivatech, les data et la réalité des entreprises africaines et européennes La semaine dernière à Paris, c’était la grand-messe de Publicis, Vivatech. N’étant pas fan de ces grands rassemblements où l’on s’autocongratule entre soi, j’ai pris l’avion pour le Sud. Après avoir traversé la méditerranée, puis le désert du Sahara, j’ai atterri à Lomé, au Togo, où se réunissaient les directeurs financiers et de contrôle de gestion de l’Afrique de l’Ouest. Accueillis dans les locaux de la BOAD, les participants ont bien entendu parlé d’intelligence artificielle, de données, et de comment la fonction finance en entreprise allait être impactée par ces évolutions technologiques. Avaient fait le déplacement les présidents français de la DFCG, l’association des directeurs financiers, et de l’AFDCC, celle des crédit managers. Les ponts entre les financiers français et leurs pairs d’Afrique de l’Ouest sont actifs, et devraient l’être encore plus dans les années à venir. Alors bien sûr, on a parlé de magie, de ces outils miraculeux que l’on nous promet, et de la révolution sur l’emploi qu’ils vont provoquer. Mais avec réalisme on a surtout évoqué ce qui manque à beaucoup d’entreprises africaines pour exploiter cette intelligence artificielle : des données. Dans des pays où la part de l’économie informelle est importante, collecter et conserver des données semble parfois vain. J’ai eu un échange passionnant avec le directeur financier d’un groupe de distribution. Certes, il adorerait pouvoir analyser qui achète quoi, quand, avec quoi… mais ce ne sont pas les modèles d’apprentissage qui lui font défaut, ce sont les données. Pas de remontée des lignes de tickets de caisse ; pas de carte de fidélité permettant d’identifier les clients. Il manque le basique. Difficile d’aller parler d’intelligence artificielle générative quand manquent la culture nécessaire à la collecte, à la valorisation et à la gouvernance de ces données. Il serait facile de pointer du doigt le retard technologique de ces pays africains. Mais c’est également la réalité de beaucoup d’entreprises françaises. En ce moment même, je travaille avec un industriel dans le domaine de la papeterie : il envisage prochainement la mise en place, enfin, d’une gestion des données de référence ; un service social tente de mettre en place une gouvernance, et se heurte à l’absence d’architecture d’entreprise et d’ontologie des termes utilisés en interne ; et une grosse PME dans l’agro-alimentaire change enfin d’ERP et envisage son premier reporting dans un outil autre que Excel. Alors que retenir de tout cela ? Il faut bien sur des visionnaires, des rêveurs, des innovateurs et il faut un Vivatech. Mais concrètement beaucoup d’entreprises n’en sont pas là ! Elles en sont même loin. Leur faire croire qu’elles pourront bénéficier en un claquement de doigt de ces technologies magiques, ce n’est pas leur rendre service. Oui, c’est moins drôle, moins « chevere » comme dit ma fille de 17 ans, mais mettre en place une culture de la donnée, des bonnes pratiques de gouvernance, et une architecture adaptée pour collecter, conserver et par la suite analyser cette donnée, est la priorité ! Ne me parlez pas de ChatGPT tant que vous n’avez pas ces fondations. Sinon, c’est comme si vous commandiez une Ferrari, alors que vous n’avez même pas passé le permis. /episode/index/show/decideo/id/31470287

Decideo - Data Science, Big Data, Intelligence Augmentée

TOPICS