Skip to content
Sign in
Artwork for Decideo - Data Science, Big Data, Intelligence Augmentée
TechnologyBusinessManagement

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

Philippe Nieuwbourg

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. 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. User stories, best practices, news, software reviews, agenda, job board… are available online, and through podcast and mobile applications.

Play
Open in
  • 30 episodes
  • fortnightly
  • Avg 14 min
  • French

Episodes 30

NewestOldestLongest
All20Unplayed20In progress0Played0
Counted on this page — what you have heard stays on this device, so it is not something the list can be paged by.
  • S6 · E22
    November 2 · 9 min

    #6.22 La méthode GDR pour documenter les décisions de gouvernance des données

    Comment documenter vos décisions de gouvernance des données La méthode ADR (Architecture Decision Record) a été formalisée par Michael Nygard en 2011. Elle repose sur quelques principes simples qui permettent de formaliser la documentation des décisions d’architecture dans un système d’information. Je vous propose de l’adapter légèrement, et d’en faire le support de documentation de notre gouvernance des données. Vous verrez, c’est simplissime et très efficace. Et cela vous permettra d’entrainer une IA à intégrer vos propres décisions dans sa connaissance. L’idée centrale de la méthode ADR est de documenter les décisions d’architecture, pas l’architecture elle-même. Ce qui se perd avec le temps n’est pas le « quoi » (qui est en réalité lisible dans le code) mais le « pourquoi » : le contexte, les contraintes et les alternatives écartées. Un ADR capture ce raisonnement au moment où il est encore frais. Mettre en place une architecture de données et mettre en place une gouvernance de données reposent sur des processus très semblables : analyser, décider, formaliser. Les principes basiques de la méthode ADR Unicité. Une décision égale un document. Chaque ADR est court (entre une et deux pages), autonome, numéroté séquentiellement (0001, 0002…) et n’est jamais fusionné avec un autre. Immuabilité. Un ADR accepté ne se modifie plus. S’il devient caduc, on en écrit un nouveau qui le complète, et on marque l’ancien « Remplacé par ». La collection forme ainsi un journal historique, pas un document vivant. Cela se rapproche du concept de main-courante largement utilisé dans le domaine militaire. Proximité du code. Les ADR vivent dans le dépôt de code, et sont versionnés avec le code, comme n’importe quel changement. Écriture pour le futur lecteur. Le destinataire est le développeur qui arrivera dans deux ans et se demandera « pourquoi diable ont-ils fait ça ? ». Demain, le « lecteur » sera peut-être un agent qui aura besoin de comprendre l’architecture. L’ensemble des ADR pourra également entrainer un LLM qui répondra aux questions que se posent les utilisateurs sur les choix d’architecture. La forme d’un ADR : cinq sections regroupées dans un même document Titre : une phrase descriptive, numérotée. Statut : Proposed / Accepted / Deprecated / Superseded (by ADR-00XX). Contexte : les forces en présence, factuelles et neutres : contraintes techniques, organisationnelles, politiques, réglementaires. Décision : formulée à la voix active : « Nous allons… », qui souligne la responsabilisation des acteurs qui ont pris cette décision. Conséquences : ce qui devient plus facile et plus difficile après coup, positif comme négatif. C’est la section la plus souvent bâclée et pourtant la plus utile, en particulier pour une analyse a posteriori. Adapter l’ADR à la gouvernance des données… le GDR (Governance Decision Record) La mise en place d’une gouvernance des données, et son suivi quotidien, nécessitent de prendre des décisions, certaines mineures, d’autres structurantes, dont les effets se feront sentir dans le temps, parfois plusieurs années après. Ceux qui ont pris la décision ne sont souvent plus là, ou plus aux mêmes fonctions ; et lorsque la décision est ancienne, les raisons du choix, les arguments exposés, les débats tenus, les arguments échangés… se sont effacés des mémoires humaines, et personne à l’époque ne les avait consignés. Sur ce plan, gouvernance des données et architecture sont très proches. L’idée est donc d’appliquer la méthode ADR aux décisions liées à la mise en place de la gouvernance des données. On passe de la méthode Architecture Decision Record (ADR) à la méthode Governance Decision Record (GDR). Et finalement très peu de choses vont changer. Les principes de la méthode évoqués ci-dessus (unicité, immuabilité…) restent identiques. La forme d’un GDR reste identique à celle d’un ADR. Dans chaque fichier .md, les sections suivantes peuvent être renseignées. Comme vous le verrez dans le modèle, certaines sections sont obligatoires, d’autres facultatives : - Description du problème à résoudre et de son contexte - Facteurs de décision - Choix envisagés - Avantages et inconvénients des différentes options - Décision prise - Et toute autre rubrique que vous trouverez intéressant d’ajouter dans votre contexte Qui a en charge la rédaction des GDR ? Évidemment, c’est celui qui coordonne les tâches de gouvernance (responsable de la gouvernance des données, coordinateur du comité de gouvernance, voir data steward) qui est responsable de cette documentation. La confier à un stagiaire sera contre-productif et montrera le peu d’intérêt que vous portez à la démarche. Au-delà du « qui », la question du « quand » est importante. Il est totalement déconseillé de rédiger une GDR a posteriori de la décision. Il est donc difficile de reconstruire l’historique des décisions de gouvernance qui n’auraient pas été documentées au moment de leur mise en œuvre. Vous démarrez avec les décisions d’aujourd’hui. En effet, la documentation de la décision doit être faite pendant le processus décisionnel. Cela permet de documenter les solutions envisagées, les arguments évoqués par chacun, le contexte de chaque décision prise ; tout cela pendant les débats. C’est en cela que l’ensemble des GDR se rapproche de la notion de main courante. Quelles décisions méritent la rédaction d’un GDR ? C’est la principale question ! Si vous multipliez les GDR à chaque fois que vous changez une virgule, vous allez vous noyer sous la documentation. À l’inverse, oubliez de documenter une décision, et vous le regretterez dans le futur (ou vos successeurs le regretteront). Il est habituel de classer les décisions en deux catégories : - Décisions facilement réversibles (et peu couteuses à renverser) : un GDR n’est alors pas indispensable ; - Décisions complexes et couteuses à renverser : un GDR doit alors obligatoirement être rédigé. Utiliser les GDR pour comprendre comment une décision a été prise Bien sûr, la consultation de l’historique des GDR permettra de retrouver le contexte d’une décision prise dans le passé, les personnes impliquées, le contexte, etc. Un simple moteur de recherche permettra de retrouver, par mots clés, les décisions anciennes. Mais l’IA nous permet aujourd’hui d’imaginer d’autres formes d’utilisation. Si vous avez suivi mon conseil, et choisi de structurer vos GDR sous forme d’un bundle OKF, ce dernier peut être connecté à votre LLM interne. Posez une question dans votre LLM sur la gouvernance des données, et ce dernier saura lire l’histoire des décisions (les GDR) et rédiger une réponse. Une utilisation qui confirme le rôle central que prend le LLM dans l’interface entre un utilisateur et les différents composants du système d’information. Dans un futur plus lointain, il est également possible d’imaginer que des agents d’IA sauront lire les décisions de gouvernance prises dans le passé, et vérifier la conformité de leurs actions par rapport à ces décisions. Combien cela coute, combien cela rapporte ? Question classique liée à tout investissement en temps. Soyez honnête, créer un fichier .md pour chaque décision importante ne prendra pas très longtemps… allez.. disons une heure par décision, et je suis large. Le cout est donc minimum. En revanche, si vous cherchez à estimer le temps perdu à essayer de comprendre pourquoi et comment une décision passée a été prise ; ce sont sans doute de nombreuses heures qu’il vous faudra additionner. Le retour sur investissement est donc évident. Encore faut-il que vous soyez animé par la volonté de bien faire, et surtout par la volonté de léguer un système durable. Alors, en conclusion, si vous avez tenu jusqu’à la fin de ce podcast, j’aimerais vous solliciter au travers des commentaires. Avez-vous déjà mis en œuvre une démarche de documentation des décisions de gouvernance ? Sous quelle forme ? La structuration GDR vous donne-t-elle envie d’essayer ? Quels bénéfices et/ou difficultés y voyez-vous ?

    • Transcript
  • S6 · E21
    October 19 · 2 min

    #6.21 Qui contrôle les intelligences artificielles les plus puissantes du monde ?

    Réponse : pour l'essentiel, une association de quelques dizaines de personnes, basée aux États-Unis, qui s'appelle METR. Et qui n'a aucun pouvoir de sanction. METR teste les modèles d'OpenAI, d'Anthropic, de Google DeepMind, avant leur mise sur le marché. Sa spécialité : mesurer ce qu'une IA sait faire toute seule. Son résultat le plus cité : la durée des tâches qu'un agent peut mener à bien sans intervention humaine double tous les sept mois. Depuis six ans. Sur l'indépendance financière, le dispositif est sérieux. METR n'accepte aucun financement des entreprises d'IA. Elle ne facture pas ses évaluations. Elle refuse même les dons de leurs salariés. Et elle a levé, cet été, soixante et onze millions de dollars — auprès de fondations philanthropiques. Mais l'argent n'est pas le seul levier d'influence. Premier angle mort : OpenAI, Anthropic et xAI fournissent gratuitement les capacités de calcul dont METR a besoin pour travailler. L'organisation le reconnaît. Leur valeur n'est publiée nulle part. Deuxième angle mort, plus lourd : l'accès. Pour tester un modèle avant sa sortie, il faut que l'éditeur ouvre la porte. C'est lui qui fixe le périmètre, la durée, le calendrier. L'auditeur n'a aucun droit d'entrée. Troisième angle mort : les hommes. La fondatrice de METR, Beth Barnes, vient d'OpenAI. Un chercheur d'OpenAI siège parmi ses conseillers. C'est la condition de la compétence technique. C'est aussi un risque. Alors METR est-elle indépendante ? Financièrement, oui, autant qu'on puisse le vérifier. Structurellement, c'est autre chose. Ses rapports sont aujourd'hui la meilleure source publique disponible sur les capacités dangereuses des IA. Ce ne sont pas des certifications. Ce sont des avis d'experts, rendus dans les limites fixées par celui qu'on examine.

    • Transcript
  • S6 · E20
    October 12 · 2 min

    #6.20 Collibra rachète une start-up dans la gouvernance de l'IA

    Il y a une semaine, Collibra a racheté une start-up munichoise de trois ans d'âge. Montant non communiqué. Équipe réduite. Un tour de table d'un million et demi d'euros, pas davantage. Et pourtant, cette opération dit quelque chose d'important sur la gouvernance de l'intelligence artificielle en entreprise. Collibra, d'abord. Née à Bruxelles en deux mille huit, installée à New York depuis deux mille quinze. Plus de sept cents clients. Soixante-dix-huit entreprises du Fortune cinq cents. Historiquement, un spécialiste du catalogue de données. Aujourd'hui, elle se présente comme — je cite — « le plan de contrôle de l'intelligence artificielle d'entreprise ». Ce qu'elle achète avec trail ML, c'est trois choses. Des agents qui déterminent seuls quelle réglementation s'applique à un système d'IA. Des évaluations de conformité qui se rejouent dès que les preuves changent — et non plus une fois par an. Et surtout : la capacité de bloquer, en production, l'action d'un agent qui violerait une politique interne. Voilà le vrai basculement. Jusqu'ici, gouverner l'IA, c'était documenter. Désormais, c'est intervenir. On passe du classeur au coupe-circuit. Pour les directions de la gouvernance, deux lectures. D'un côté, une charge manuelle qui s'allège : les équipes conformité ne constitueront plus leurs dossiers de preuve à la main. De l'autre, une question nouvelle : que se passe-t-il quand l'outil bloque un traitement parfaitement légitime ? Et une mise en garde : un verdict de conformité produit par un logiciel n'exonère personne. Sous l'AI Act, la responsabilité reste chez celui qui déploie le système. Automatisez, agentisez, gouvernez. Tout ce que vous voulez, mais rien ne vous exonérera de votre responsabilité ! Reste l'ironie de l'affaire. Le marché que Collibra achète avec Trail ML, existe parce que l'Europe a écrit la loi. Collibra, elle, a quitté Bruxelles pour New York dix ans avant que ce texte n'existe.

    • Transcript
  • S6 · E19
    October 5 · 25 min

    #6.19 Valorisez vos données, vos algorithmes et autres actifs immatériels

    Dans cet épisode, je reçois Laurence Joly, co-fondatrice de Diag'n'grow, une entreprise spécialisée dans la valorisation des actifs immatériels. Ce patrimoine informationnel qui nous intéresse, données et algorithmes, est en effet proche des marques, des brevets, et autres actifs que l'on sait déjà bien valoriser. Alors, à quand les datas à l'actif du bilan ? Laurence Joly nous donne quelques pistes : - Quels sont les principaux "nouveaux" actifs immatériels que l'entreprise n'est pas habituée à évaluer ? - Alors que la valeur de ces actifs immatériels augmente de manière importante, cela impacte-t-il la différence entre la valeur "officielle" d'une entreprise et sa valeur réelle ? - Quelles sont les difficultés propres à l'évaluation des actifs immatériels et quelle méthode avez-vous développée ? - Parlons spécifiquement des données, quels sont les problèmes particuliers liés à leur évaluation ? - Entre évaluation et comptabilisation, il y a encore une étape, quand verrons nous un data warehouse à l'actif du bilan d'une entreprise ?

    • Transcript
  • S6 · E18
    September 20 · 3 min

    #6.18 Violet Pâle et le monde du futur nous semble déjà réalité !

    Le monde gouverné par Journey que nous décrit Pierre-Emmanuel Durand dans son roman d'anticipation Violet Pâle, n’est en réalité pas nouveau. Ses racines sont profondes. Elles datent de l’époque dite moderne, celle qui a débuté après la Seconde Guerre mondiale. Un monde de consommation, de plastique, et de commodités. Née en 1932, ma mère me racontait, enfant, toutes les merveilles que l’on trouvait au Salon des Arts Ménagers. Créée en 1923, cette exposition commerciale a connu son apogée dans les années 50, quand naissait cette envie de facilité, de praticité, de simplification. Vous vous souvenez également des films américains des années 60, de ces appartements équipés des dernières technologies. Le grand critique de cette époque était le cinéaste Jacques Tati. Après avoir lu Violet Pâle, il faut revoir Mon Oncle (1958) et Playtime (1967). Jacques Tati y moque dans le premier la maison ultramoderne, aseptisée et automatisée ; et dans le second, la standardisation internationale des bureaux, des aéroports et des habitudes. Il aura fallu un demi-siècle, mais, durant toutes ces années, les tendances critiquées par ce maître du cinéma n’ont fait que se transformer peu à peu en réalité. Dans Violet Pâle, Pierre-Emmanuel Durand les pousse à leurs limites. « Nous n’accepterons jamais d’aller aussi loin », répondra sans doute le lecteur… sans accepter de constater que nous y sommes déjà, ou presque. L’héroïne, Tess, découvre qu’il existe un autre monde, à l’extérieur de l’IA Journey qui a pris possession de son cerveau. « Rien n’était synchronisé, rien n’était optimisé. — C’est… trop, murmura Tess. Norah sourit. — C’est la vie. — C’est bizarre. — Oui, répondit Norah. Mais c’est réel. » Ce monde piloté par l’IA, c’est l’histoire de notre perte de souveraineté. Entre 2020 et 2031, la France a peu à peu perdu le contrôle des outils qu’elle utilisait. Vers 2035, la résistance européenne entraine, en représailles, une coupure complète par les États-Unis de l’ensemble des services auxquels les États et les citoyens sont devenus dépendants. Soixante-douze heures de blackout, qui a finalement fait capituler la France, livrant toutes ses données et celles de ses citoyens aux entreprises américaines. Heureusement, certains, comme Noah, Tess, et Yann le Corn… ont choisi de ne pas se laisser embrigader sans réagir ! Vont-ils réussir à rallier une partie importante de la population, ou la masse continuera d’obéir aux injonctions de Journey ? L’auteur, Pierre-Emmanuel Durand, connait bien l’informatique. Il y a fait toute sa carrière, depuis Capgemini et Business & Decision, jusqu’à aujourd’hui où il dirige le département informatique d’un groupe de courtage spécialisé en prévoyance individuelle. Violet Pâle est son deuxième roman, et espérons qu’il y en a d’autres en préparation ! Car pour savoir ce qui arrive à Tess, vous devez lire Violet Pâle. Éditeur ‏ : ‎ Verone éditions Date de publication ‏ : ‎ 23 juillet 2026 Langue ‏ : ‎ Français Nombre de pages de l'édition imprimée ‏ : ‎ 330 pages ISBN-13 ‏ : ‎ 979-1042316419

    • Transcript
  • S6 · E17
    September 13 · 19 min

    #6.17 Chapitre 29, un roman inspirant, sur un sujet sérieux, la vie privée

    Rencontre avec Alessandro Fiorentio, auteur de Chapitre 29, un roman historique qui nous emmène découvrir les origines de la vie privée. Nous sommes à Paris, en 2018, un universitaire décède dans des circonstances suspectes, alors qu’il travaillait sur une étude, pour le compte du Saint-Siège, sur les origines de la vie privée. Son ami et ancien élève, Francesco Libero, reprend le flambeau et, malgré les risques qu’il mesure, tente de découvrir ce qui a conduit à la disparition de son professeur. Tout comme dans l’autre succès de Dan Brown, Origine, technologie et religion s’entremêlent ; tout semble se passer comme si la religion, basée sur des croyances, craignait la découverte d’une vérité, basée sur des faits scientifiques.

    • Transcript
  • S6 · E16
    September 6 · 7 min

    #6.16 Une compagnie morte, mais des données bien vivantes et bien valorisées

    Pourquoi Google a payé 10 millions de dollars pour les archives numériques de Spirit Airlines, alors que vous me dites que vos données ne valent rien, parce que vous ne savez pas mesurer cette valeur… Spirit Airlines n’existe plus. La compagnie low cost américaine, pionnière du modèle « ultra low-cost » outre-Atlantique, avait déjà déposé le bilan une première fois en novembre 2024, après l’échec de son rapprochement avec JetBlue puis avec Frontier Airlines et l’accumulation de pertes consécutives à la pandémie de Covid-19. Une tentative de restructuration n’a finalement pas suffi : ses avions ont cessé de voler en mai 2026, et l’entreprise est désormais liquidée, ses actifs vendus les uns après les autres pour tenter de rembourser ses créanciers. Parmi ces actifs, la plupart sont matériels : avions, équipements, biens immobiliers. Mais un lot a suscité un intérêt inattendu : l’intégralité des archives numériques internes de la compagnie. Selon un document judiciaire déposé auprès du tribunal des faillites de New York et consulté par plusieurs médias américains, Google aurait remporté l’enchère pour ce lot de données pour la somme de 10 millions de dollars, en devançant Mercor, une société spécialisée dans la fourniture de données d’entraînement pour l’intelligence artificielle, qui avait proposé 7,5 millions de dollars. La vente reste soumise à l’approbation du juge en charge du dossier, mais elle nous donne des indications intéressantes sur : - Le fait que les données ont de la valeur, et que certaines entreprises l’ont mieux compris que d’autres ; - Des métriques de mesure de la valeur de ces données, en fonction des usages, dont par exemple l’entrainement des IA. Un volume de données considérable et très hétérogène Le détail du lot, rendu public via le document judiciaire, donne une idée assez précise de ce que peut représenter le patrimoine numérique d’une compagnie aérienne, après près de deux décennies d’activité. On y trouve environ 100 millions d’e-mails, 500 millions de contenus issus de Microsoft Teams, 17 millions de fichiers OneDrive et 20,5 millions de documents SharePoint. S’y ajoutent plus de 30 millions d’enregistrements d’appels au service client, 15 millions de conversations de chat, 600 000 tickets ServiceNow, ainsi que 13,7 millions d’adresses e-mail actives issues de la plateforme marketing Responsys d’Oracle… et un raton laveur (pour ceux qui ont la réf). Le lot comprend aussi des données strictement opérationnelles : plus de 763 000 vols, cinq millions d’appariements d’équipages, 1,2 million de bordereaux de carburant, les enregistrements de près de 790 000 achats de pièces détachées, et 11 millions de ventes de services Wi-Fi à bord. Un porte-parole de Google a indiqué que l’entreprise avait acquis une partie de cet ensemble de données d’entreprise afin d’améliorer ses produits et ses modèles d’intelligence artificielle, en précisant qu’aucune information personnelle ne serait reçue dans le cadre de cette opération. Selon les informations judiciaires, les données doivent en effet être anonymisées avant leur transfert. Sont explicitement exclus de la vente les profils passagers, le programme de fidélité Free Spirit, les historiques de navigation ainsi que les plaintes déposées auprès du régulateur américain des transports. Reste que l’anonymisation de plusieurs centaines de millions de documents à cette échelle n’est pas un exercice trivial, et plusieurs observateurs soulignent que le risque de fuite ou de réidentification partielle ne peut être totalement écarté. Un précédent qui n’est plus tout à fait isolé Cette opération n’est pas la première du genre. Plusieurs médias avaient déjà rapporté, au printemps 2026, que des start-up en faillite revendaient leurs archives Slack et leurs messageries internes à des sociétés d’IA en quête de données d’entraînement. Mais le rachat des données de Spirit Airlines change d’échelle : il s’agit ici d’une entreprise historique, cotée pendant des années, avec près de vingt ans d’activité et des millions de clients, et non d’une jeune pousse récente. C’est précisément ce changement d’échelle qui rend l’opération intéressante à observer du point de vue de la valorisation de la donnée. Ce que révèle cette transaction sur la valeur de la donnée La valorisation des actifs immatériels, et des données en particulier, reste un exercice notoirement difficile : il n’existe pas de marché liquide ni de méthode comptable standardisée pour évaluer un corpus de courriels d’entreprise ou un historique de vols. C’est précisément ce qui rend ce type de transaction instructif : en l’absence de modèle théorique consensuel, c’est le marché lui-même, via une procédure d’enchères judiciaires transparente, qui a fixé un prix. Plusieurs éléments de cette enchère méritent d’être retenus par celui qui s’intéresse à la question de la valorisation des données d’entreprise. Premièrement, la concurrence entre acheteurs. Le fait que deux acteurs spécialisés dans l’IA (Google et Mercor) se soient disputé ce lot, avec un écart de prix limité (10 millions contre 7,5 millions de dollars), confirme qu’il existe une demande réelle et compétitive pour ce type de corpus, et pas seulement un intérêt opportuniste isolé. Intéressant également que les enchérisseurs soient des sociétés technologiques et non d’autres compagnies aériennes. Deuxièmement, le prix payé donne des indications sur les critères de valorisation retenus par le marché. Ce n’est pas la valeur des données prises isolément qui compte, mais un ensemble de caractéristiques combinées : le volume brut (centaines de millions de documents), la diversité des formats et des sources (messagerie, visioconférence, ERP, CRM, systèmes métiers comme les appariements d’équipages ou les bordereaux de carburant), la spécificité sectorielle (des données d’exploitation aérienne difficilement reproductibles à partir du seul web public), et la profondeur temporelle du corpus, accumulé sur près de deux décennies. Troisièmement, le motif d’achat invoqué par Google (l’amélioration de ses produits et de ses modèles d’IA) illustre un déplacement de la demande de données d’entraînement : au-delà des textes disponibles publiquement sur le web qui perdent chaque année de leur valeur, car remâchés par l’IA elle-même, et déjà largement exploités, les entreprises d’IA cherchent désormais des données professionnelles réalistes, structurées autour de processus métiers concrets (échanges internes, données opérationnelles, interactions avec la clientèle), qui reflètent mieux la diversité et la complexité du travail réel. Enfin, le fait que cette donnée continue d’avoir de la valeur marchande après la disparition de l’entreprise qui l’a produite (dans le cadre d’une liquidation judiciaire où chaque actif est scruté pour maximiser le remboursement des créanciers) constitue en soi une validation forte : la donnée y est traitée comme un actif cessible au même titre qu’un avion ou un immeuble, avec un prix déterminé par une mise en concurrence réelle plutôt que par une estimation interne. Une évaluation qui reste imparfaite, mais un signal clair Il serait excessif d’en déduire une méthode de valorisation universelle : 10 millions de dollars pour l’ensemble des archives numériques d’une compagnie aérienne de taille moyenne ne disent rien, en tant que tels, du prix qu’atteindraient les données d’une autre entreprise, dans un autre secteur, avec une autre composition de corpus. La difficulté à évaluer précisément la valeur de la donnée demeure entière. Mais l’existence même de cette transaction, sa procédure d’enchères et l’écart de prix entre les deux offres concurrentes fournissent un point de repère concret et rare, dans un domaine où les repères de marché restent encore à construire.

    • Transcript
  • S6 · E15
    August 30 · 9 min

    #6.15 Et vous, êtes-vous plutôt KQL ou SQL ?

    Apprendre le langage KQL, quels apports pour l’analyste de données Depuis des décennies, SQL règne sur le monde de l’analyse de données. Avec l’essor du cloud, de la cybersécurité et du big data générés par les infrastructures modernes, un nouveau venu est arrivé dans l’écosystème Microsoft : le Kusto Query Language[1], plus connu sous son acronyme KQL. Pour un analyste de données qui doit choisir ses compétences à développer ou simplement comprendre le paysage technologique actuel, la question mérite d’être posée sans jargon inutile : que gagne-t-on, et que perd-on, à utiliser KQL plutôt que SQL? Quand doit-on utiliser les deux? Complémentarité ou concurrence? Deux langages, deux histoires SQL est né dans les années 1970 (merci au Dr Codd et à la conceptualisation de l’OLTP), conçu pour interroger des bases de données relationnelles classiques : celles qui gèrent les commandes d’un site e-commerce, les comptes clients d’une banque, ou les stocks d’un entrepôt. Sa vocation première est la gestion de données structurées et stables, avec des exigences fortes de cohérence et d’intégrité. C’est le T de OLTP, la notion de « transaction ». SQL n’a jamais été conçu comme un langage destiné au décisionnel et à l’analyse de données. KQL, lui, est beaucoup plus récent : il a été développé par Microsoft et lancé en 2017 avec le service Azure Data Explorer ; il répond à un besoin différent, apparu avec l’explosion du big data. Comment analyser rapidement des milliards de lignes de logs, ou d’événements de sécurité, générés en continu ? C’est précisément le terrain de jeu pour lequel KQL a été pensé, et on le retrouve aujourd’hui au cœur d’outils comme Azure Monitor ou Microsoft Sentinel, la plateforme de cybersécurité de Microsoft. Il peut évidemment être utilisé pour analyser d’autres types de données. On pense évidemment aux données générées par des objets connectés, ou des transactions d’un site de eCommerce, etc. Cette différence d’origine explique presque tout ce qui les sépare aujourd’hui. Les atouts de KQL pour l’analyste Une lecture plus naturelle des requêtes complexes. Là où SQL demande souvent d’imbriquer des sous-requêtes ou de lire une instruction dans un ordre qui ne correspond pas à celui de son exécution réelle, KQL fonctionne comme un enchaînement d’étapes, un peu à la manière d’une recette de cuisine : on part des données brutes, puis on filtre, puis on regroupe, puis on trie, chaque étape s’ajoutant à la précédente de façon visible. Pour un analyste qui construit une analyse pas à pas, cette logique de pipeline facilite énormément la relecture et la correction d’erreurs. Une puissance native pour l’analyse temporelle. KQL a été conçu dès le départ pour des données horodatées en grand volume : logs applicatifs, alertes de sécurité, mesures de performance. Des fonctions comme le calcul de fenêtres de temps glissantes ou la détection d’anomalies sont intégrées nativement, alors qu’elles demandent souvent des développements plus techniques en SQL classique. Une recherche de texte libre intégrée. Chercher un mot ou une expression dans de grandes quantités de données textuelles est une opération courante et simple en KQL, sans configuration préalable particulière. En SQL, ce type de recherche nécessite le plus souvent une préparation technique. SQL a été conçu exclusivement pour l’analyse de données structurées ; KQL a été pensé au moment où les données semi-structurées et non structurées sont devenues accessibles, le fameux « big data » des années 2010. Une exploration progressive des données. Parce qu’une requête KQL se construit étape par étape, un analyste peut tester une première portion, observer le résultat, puis ajouter la suite. Cette approche est particulièrement appréciable lorsqu’on découvre un jeu de données inconnu. C’est une technique d’exploration qui répond parfaitement aux besoins métier d’analyse de nouvelles données. Quels sont les défauts de KQL pour l’analyste Un langage moins répandu. SQL bénéficie d’une notoriété et d’une ancienneté que KQL est loin d’égaler. La quasi-totalité des formations en analyse de données, des offres d’emploi et des ressources pédagogiques s’appuient sur SQL. Apprendre KQL représente donc un investissement supplémentaire, sur un langage dont l’usage reste concentré dans l’écosystème Microsoft. Si vous souhaitez vous spécialiser en environnement Microsoft, c’est un bon choix d’extension de vos compétences. Pour une entreprise qui choisit la plate-forme Microsoft, le choix de KQL est assez logique. En revanche, c’est pour l’instant une étape de plus dans une dépendance à l’écosystème Microsoft. En période de réflexion sur la souveraineté… La conséquence pour une entreprise est que les ressources disponibles compétentes sur KQL sont plus rares et difficiles à trouver. Un périmètre d’usage plus restreint. SQL est le langage de référence d’une multitude de bases de données très différentes les unes des autres. KQL, à l’inverse, reste cantonné aux services Microsoft Azure conçus pour l’analyse de logs et de télémétrie. Un analyste maîtrisant KQL ne pourra pas transposer directement cette compétence à d’autres environnements, contrairement à SQL, dont les bases sont valables presque partout. Une vocation exclusivement analytique. KQL est un langage de lecture seule : il permet d’interroger des données, mais pas de les modifier, de les insérer ou de les supprimer. C’est un choix assumé, cohérent avec son usage, mais cela signifie qu’un analyste devra malgré tout recourir à d’autres outils pour toute opération de gestion des données elle-même. On ne pourra donc pas abandonner SQL pour se limiter à KQL. La connaissance de SQL reste indispensable. Pour un analyste, la compétence clef reste SQL. KQL est une compétence complémentaire. Un écosystème d’outils moins fourni. Autour de SQL s’est construit, au fil des décennies, un univers considérable d’outils de visualisation, de tableaux de bord, de connecteurs et de logiciels métiers. L’offre équivalente pour KQL existe, mais reste plus restreinte et moins mature, ce qui peut limiter les options d’un analyste selon le contexte de son entreprise. Et encore une fois, la dépendance à l’écosystème Microsoft est une donnée du problème. Un langage en open source, mais des outils d’exécution propriétaires Le cœur du langage (grammaire, analyseur syntaxique [parser], spécifications) est publié par Microsoft sur GitHub. Ce dépôt est accessible librement et sous licence open source. Donc, KQL est un langage ouvert, dans la même logique que SQL, qui n’appartient à personne. Mais dans la pratique, l’immense majorité des usages de KQL se fait via les services propriétaires de Microsoft, ce qui nuance largement la portée de cette ouverture ; contrairement à SQL, dont on trouve de nombreux moteurs open source (PostgreSQL, MySQL, SQLite, etc.) totalement indépendants de tout éditeur commercial. Faut-il choisir entre les deux? En réalité, la question se pose rarement en ces termes en entreprise. La plupart des organisations qui utilisent KQL le font en complément de SQL, et non à sa place. Un analyste de données a tout intérêt à considérer les deux langages non pas comme des concurrents, mais comme deux outils répondant à des besoins différents : SQL pour interroger des données métier structurées et stables (en lecture et en écriture), KQL pour explorer rapidement de gros volumes de logs et de données temporelles, en particulier dans un environnement Azure. Pour un professionnel de la donnée, la bonne nouvelle est que les deux langages partagent une logique de fond assez proche (tables, filtres, agrégations, jointures) ce qui rend le passage de l’un à l’autre plus accessible qu’il n’y paraît. Le véritable enjeu n’est donc pas de choisir un camp, mais de savoir reconnaître, selon la nature des données et l’outil disponible, quel langage utiliser pour poser la bonne question au bon moment. Et vous, quelle expérience avez-vous du langage KQL ? Quelles difficultés ou faiblesses avez-vous éventuellement rencontrées ? Et quels sont vos cas d’utilisation ? [1] https://learn.microsoft.com/fr-fr/kusto/query/?view=microsoft-fabric

    • Transcript
  • S6 · E14
    August 23 · 8 min

    #6.14 Des milliers d’applications à faire évoluer, du shadow IT à détecter : Paris Aéroports face à un projet d’ampleur en mars 2027

    Des milliers d’applications à faire évoluer, du shadow IT à détecter : Paris Aéroports face à un projet d’ampleur en mars 2027 Le 16 mars 2027, tous les terminaux de l’aéroport Paris Charles de Gaulle changent de numérotation! Un casse-tête informatique et organisationnel, et un plaidoyer pour la mise en place d’une gestion des données de référence. Assis dans le bus qui vous emmène du Terminal 2G au Terminal 2F, votre regard parcourt les affiches d’information collées aux vitres. Et les neurones de votre cerveau dédiés à la gouvernance des données font un bon. Le 16 mars 2027, les terminaux 2E, 2F, 2G deviendront les terminaux 5, 6 et 7. Quant aux numéros de portes, elles changent également, ainsi que la numérotation des parkings. Mon cœur se serre alors, pensant au responsable des référentiels chez ADP, à qui je dédie cet article. Il s’apprête à passer quelques mois stressants. Des mois bien préparés, car ce changement n’interviendra que dix mois, mais dix mois c’est bien court pour un impact majeur sur l’ensemble des installations, des applications, des procédures et des personnels. Des milliers d’applications informatiques Évidemment ce qui vient à l’esprit en priorité ce sont les applications informatiques. Y a-t-il une seule application opérationnelle de l’aéroport qui n’inclut pas quelque part des numéros de terminaux et des numéros de portes ? J’en doute. Chaque vol, chaque mouvement de matériel, chaque employé sont affectés à chaque instant à ce couple terminal/porte. Et ce sont des centaines, peut-être des milliers d’applications informatiques qu’il va falloir mettre à jour. Comment y sont stockées ces références ? Dans des tables propres à l’application, en dur dans le code, dans un référentiel partagé ? La dernière solution serait évidemment la plus facile à mettre à jour. Mais soyons réalistes, même si une gestion des données de référence (MDM) a été mise en place, une revue exhaustive du code de l’ensemble des applications semble indispensable. Et c’est sans compter sur les microapplications cachées, les feuilles Excel et autres documents directement créés par les utilisateurs. Chez ADP mais également chez tous ses partenaires, compagnies aériennes, services de l’État, prestataires, clients, etc. Car ce couple terminal/porte permet à tous ces intervenants de se comprendre, et aux processus de s’exécuter au bon endroit. Il s’agit donc de coordonner la mise à jour de toutes les interfaces et API avec des dizaines de partenaires du monde entier, dans un écosystème qui ne dort jamais et fonctionne 24 h/24. Une évolution coordonnée numérique et physique L’évolution informatique est une chose, mais elle s’accompagne d’une évolution physique. Toute la signalétique dans l’aéroport doit être modifiée, ni trop tôt ni trop tard. J’imagine que des panneaux temporaires seront installés, indiquant les deux dénominations avant/après. J’imagine aussi qu’une fois les habitudes prises, une nouvelle version de l’affichage fera disparaitre les traces de CDG 2E, 2F et 2G. Des milliers de brochures à réimprimer, un peu partout dans le monde, des guides aux voyageurs à mettre à jour, les plans de l’aéroport présents dans les systèmes vidéo de tous les avions des principales compagnies atterrissant à CDG, l’impact physique de ce changement de référentiel est lui aussi colossal. Des habitudes à modifier (pilotes, agents au sol…) L’accompagnement du changement est sans doute la partie la plus longue. Pendant combien de mois, ou d’années, les pilotes qui viennent ponctuellement à CDG continueront-ils de parler du 2F et non du T6 ? Ce sont des milliers de « référentiels » présents dans les cerveaux et les habitudes des employés qui passent sur le site, qu’il faut faire évoluer. Et l’on sait combien les habitudes sont difficiles à changer. Ma grand-mère a parlé pendant toute sa vie en anciens francs, alors même que sa nouvelle version était arrivée fin 1958. C’est l’accompagnement humain qui permettra de réaliser cette transition le plus rapidement possible. De l’importance d’un référentiel (où l’on parle d’ontologie et de MDM) Évidemment, l’architecture de rêve existe… sur le papier. Une seule et unique table, disponible en temps réel pour toutes les applications, qui contient la liste des terminaux et les portes associées. Une fonction d’historisation intégrée permet de préciser que jusqu’au 15/03/2027 inclus, il est question du Terminal 2G, et que le 16/03/2027 il devient le Terminal 7. Avantage de cette historisation, les comparaisons restent possibles. Le référentiel utilisera l’ancienne dénomination pour les requêtes antérieures et la nouvelle à partir de la date fixée. Aucune modification du code des applications ni des appels aux données. On invoque l’API du référentiel, et il renvoie toujours la bonne valeur. Malheureusement, c’est un rêve ! Car il existe ce que l’on appelle une « dette ». Des applications (par dizaines ou par centaines), des progiciels, des développements cachés, qui ont recopié ou recréé leurs propres tables et ne sont donc connectés à aucun référentiel central. Si ces données étaient cataloguées… cela simplifierait un peu les choses, mais le catalogue, personne n’a jamais voulu faire l’effort de le créer et de le mettre à jour. On en paye chèrement le prix ! Une donnée de référence est une donnée partagée entre plusieurs applications, dont on peut vérifier la qualité, et dont le mode de fonctionnement est stable ; parfaite définition qui colle avec notre liste de terminaux et de portes. Les gérer nécessite une base centrale ; on l’appelle MDM (Master Data Management) ou… comme on veut. Mais elle est disponible à tout instant, en temps réel, interrogeable par toutes les applications. Et cette disponibilité permet d’imposer aux applications de ne pas recopier les données dans leurs propres tables. Dérivée de l’ontologie d’entreprise, la gestion des données de référence est une discipline à acquérir. Mais lorsque des modifications d’importance surviennent, comme celles dont nous parlons aujourd’hui, les gains sont majeurs. D’ailleurs, qui a une idée du coût complet de mise à jour de cette liste des terminaux ? Face à ce chantier, quelques questions existentielles restent en suspens : - D’abord, j’aimerais connaitre la/les personnes en charge de ce projet. Pour les féliciter et leur apporter mon soutien pour les prochains mois. Bravo à vous… si tout se passe bien. - Mais je me pose aussi une question… à quelle heure ? Car l’affiche du bus ne le précise pas… Est-ce le 15 mars à minuit que les numéros changeront miraculeusement ? J’ai un vol à 1 h du matin le 16 mars, dois-je m’enregistrer au Terminal 2E porte K, mais embarquer finalement au Terminal 5 portes-D ? - Je vous avoue avoir indiqué la date dans mon agenda. Peut-être par superstition pour ne pas prendre un vol ce jour-là, mais je reconnais être également tenté de passer une journée à CDG2 pour vivre ce changement de l’intérieur. Mauvaise nouvelle, le Terminal 2G restera toujours un cauchemar, avec son bus interminable pour rejoindre le cœur de Roissy. Qu’il s’appelle Terminal 7 n’y changera rien !

    • Transcript
  • S6 · E13
    August 9 · 5 min

    #6.13 L'Assemblée nationale préconise la création de syndicats de données

    Assemblée nationale : le rapport sur la souveraineté numérique préconise la création de syndicats de données Un concept déjà largement étudié au Québec (Canada) sous le nom de fiducie de données, mais pas encore développé en France. Vous avez très certainement lu les 453 pages du rapport de la commission d'enquête de l'Assemblée nationale sur la souveraineté numérique [1], publié le 8 juillet… et donc, vous n'êtes pas passé à côté de la proposition n° 4 : créer un statut de syndicat de données… Les plus de 400 pages du rapport sont essentiellement consacrées aux centres de données et à l'environnement juridique du numérique dont on a constaté, par la force, depuis début 2025 notre dépendance. On y parle aussi de logiciel libre ; et un peu de données, sous l'angle de sa valeur, ce qui nous intéresse ici. Le rapport préconise la transposition dans la loi de la notion de fiducie de données (data trusts — tiers de confiance) sous forme de syndicats de données. L'objectif est d'organiser un marché respectueux et de ne pas confier cette tâche aux simples « brokers de données », dont le travail de collecte, d'agrégation et de croisement de données pose « des risques importants pour la sécurité intérieure et les droits fondamentaux », explique le rapport (pages 135 à 140). Le concept de fiducie de données est beaucoup plus développé au Québec qu'en France. Cela permettrait d'aligner ce rôle de tiers de confiance avec le Data Governance Act, dont le chapitre III est consacré aux « services d'intermédiation de données ». Le rapport propose que « À la suite de la recommandation du Conseil de l'intelligence artificielle et du numérique (CIANum), le gouvernement devra étudier la transposition des fiducies de données tant sur le plan juridique, qu'opérationnel, dans l'objectif d'inscrire dans la loi le statut de syndicat de données. Ces syndicats seront le support de la création d'outils de mutualisations des données d'intérêt général (données culturelles, environnementales, territoriales). Ils auront pour vocation de faire respecter les licences attachées à ces données et notamment de limiter leur usage dans un objectif privatif, en garantissant la réciprocité et la redistribution de la valeur auprès des communautés d'origine des données. Les syndicats représenteront les titulaires de droits, producteurs de données et sujets de données. Ils pourront en leur nom engager des recours en justice relatifs au non-respect des licences libres ou des conditions de réutilisation des données ». — Page 383 du rapport. Qu'est-ce qu'une fiducie de données ? Une fiducie de données (« data trust » en anglais) est un mécanisme juridique et de gouvernance qui confie la gestion de données à une entité tierce — le fiduciaire — chargée de les administrer dans l'intérêt des personnes ou organisations qui les ont apportées (les bénéficiaires), selon des règles prédéfinies. Concrètement, ce principe s'inspire du droit des fiducies (trusts) appliqué aux actifs financiers ou immobiliers, transposé aux données. Des personnes ou organisations transfèrent le contrôle (mais pas nécessairement la propriété) de leurs données à un fiduciaire, qui s'engage contractuellement à les gérer selon un mandat précis : finalités autorisées, conditions d'accès, règles de partage, obligations de sécurité. L'objectif principal est de rééquilibrer le rapport de force entre les individus (ou petites entités) et les grands acteurs qui collectent et exploitent les données, en mutualisant la négociation et le contrôle plutôt que de laisser chaque personne négocier seule les conditions d'usage de ses données. Les cas d'usage évoqués le plus souvent concernent les données de santé (mise en commun pour la recherche médicale tout en gardant un contrôle collectif), les données urbaines ou de mobilité dans les projets de villes intelligentes, les données agricoles, ou encore les données personnelles au sens large dans une logique d'autodétermination informationnelle. Le concept a notamment été popularisé par des travaux académiques (Sciences Po, Open Data Institute au Royaume-Uni) et des propositions de régulation, dont le règlement européen sur la gouvernance des données (Data Governance Act, entré en application en 2023), qui encadre les organismes intermédiaires de partage de données sans pour autant aller jusqu'à en faire une catégorie juridique unique et stabilisée (ce que propose le rapport de l'Assemblée nationale avec la création de syndicats de données). À ce jour, il n'existe pas encore de cadre légal harmonisé au niveau international. Pour en savoir plus sur les fiducies de données au Québec, lire ce qui a été écrit sur le sujet par Pwc [2], TIESS [3], et Nord Ouvert [4]. A écouter également une table ronde organisée par l'Université de Sherbrooke en mars 2023 sur le thème : Données et société, la fiducie de données, du mythe à la réalité [5]. En mars 2019, Element AI publiait un livre blanc [6] sur le sujet, qui a malheureusement disparu du web depuis leur rachat par ServiceNow. A noter également les travaux de Yan Benhamou de l'Université de Genève

    • Transcript
  • S6 · E12
    May 18 · 6 min

    #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 !

    • Transcript
  • S6 · E11
    May 4 · 7 min

    #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.

    • Transcript
  • S6 · E10
    April 20 · 21 min

    #6.10 Découvrons le context engineering avec Dataloma

    Nous recevons cette semaine les deux co-fondateurs de Dataloma, nouvel éditeur de progiciels spécialisé dans le context engineering encadrant les modèles d'IA générative : Laura Bonnafé, et Matthieu Fauchon. - Pourquoi la formalisation et la transmission d'un contexte sont indispensables pour améliorer les résultats de l'IA ? - Quelles sont les erreurs / risques diminués par la transmission d'un contexte ? - Pourquoi avoir lancé Dataloma ? Quelle stratégie souhaitez-vous déployer ?

    • Transcript
  • S6 · E9
    April 13 · 5 min

    #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 [1]. 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. [1] 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

    • Transcript
  • S6 · E8
    April 7 · 8 min

    #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).

    • Transcript
  • S6 · E7
    March 30 · 24 min

    #6.7 IA, RH et données avec José Rodriguez, Cornerstone

    Pour parler d'IA, de ressources humaines et de données, nous recevons José Alberto Rodriguez Ruiz, Délégué à la protection des données (DPO) et responsable de la gouvernance de l'IA chez Cornerstone (Chief Data Protection & AI Governance Officer). - Comment les DRH utilisent-elles l'IA en 2026 ? A quelles étapes de la relation employeur-employé ? - Les données RH sont par essence des données personnelles. Comment s'assurer d'être conforme à la réglementation ? - Quels sont les risques liés aux usages de l'IA dans le domaine des RH et comment les éluder ? (discriminations, biais, inégalités...)

    • Transcript
  • S6 · E6
    March 23 · 20 min

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

    Quelques semaines après la fermeture du Salon de l'Agriculture, une question centrale se pose : et si une partie de la réponse à la crise agricole se trouvait dans une ressource déjà produite par les exploitations, mais encore largement invisible ? Chaque jour, les fermes françaises génèrent des données sur les sols, l'eau, le climat, les cultures ou les rendements. Ces informations ont une valeur stratégique. Elles alimentent les outils d'aide à la décision, les modèles d'intelligence artificielle et les services développés par les acteurs de l'agritech. Pourtant, ceux qui produisent ces données en tirent encore très peu de bénéfices directs. Le marché de l'agriculture numérique, estimé à 23 milliards de dollars en 2025 et attendu à plus de 60 milliards d'ici 2034, est aujourd'hui largement structuré par les industriels et les plateformes. Les exploitants produisent la matière première, mais n'en maîtrisent ni l'usage ni la valeur. Cette situation freine l'adoption du numérique et pose une question structurante pour l'avenir du secteur : celle de la reconnaissance des données comme un véritable actif agricole. Au-delà de leur valeur économique, ces données permettent également de mesurer et de valoriser les services écologiques rendus par les exploitations, qui représentent jusqu'à 50% de la valeur économique des grandes cultures, et deviennent un élément déterminant pour les acteurs financiers. Experte des nouveaux paradigmes de l'innovation et de la création de valeur, nous recevons Caroline Gans Combe qui décrypte pourquoi la donnée pourrait devenir un levier économique structurant pour les agriculteurs, à condition de mettre en place des règles garantissant leur maîtrise et leur valorisation.

    • Transcript
  • S6 · E5
    March 16 · 22 min

    #6.5 Alain Garnier, Jamespot, défend une diversité souveraine

    Alain Garnier, co-fondateur de Jamespot, est un ardent défenseur de la souveraineté numérique; l'occasion d'aborder ce sujet avec lui, sans filtre, et de réfléchir ensemble aux solutions pratiques, et non-extrémistes, qui s'offrent à nous, pour faire un bout de chemin en direction d'un numérique moins dépendant de la grande puissance américaine aujourd'hui, ou peut-être chinoise demain. - Vous dites : "Nous sortons d'une approche théorique de la souveraineté numérique. Désormais, la question centrale devient : est-ce que l'organisation peut continuer à fonctionner si cette donnée ou ce système tombe"... on parle donc de résilience ? Est-ce que réfléchir à la souveraineté numérique, c'est prévoir le pire ? - La souveraineté numérique n'a en réalité pas de limite ! Doit-on re-coloniser des pays qui produisent les métaux rares dont on a besoin pour sécuriser notre approvisionnement ? Est-ce qu'on ne dépendra pas toujours de quelqu'un d'autre ? - En matière de logiciel, là encore, où met-on la limite ? Ni le plan calcul du Général de Gaulle, ni le Minitel n'ont permis à la France d'être leader dans le numérique... comment fait-on ?

    • Transcript
  • S6 · E4
    March 9 · 7 min

    #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 plateformes On 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).

    • Transcript
  • S6 · E4
    March 2 · 18 min

    #6.3 Automatisation des services comptables avec Geoffrey Nozerand, Dext

    Parlons d'automatisation, d'IA et bien sur de facturation électronique, avec Geoffrey Nozerand, directeur des partenariats de Dext, solution d'automatisation de la gestion des documents administratifs. - L'IA et la gestion des données comptables : quel impact sur l'organisation des services comptables et les prestations des experts-comptables ? - Quels sont les risques ? Qui est responsable juridiquement en cas de mauvaises données ? Comment s'organise la gouvernance ? - La facturation électronique arrive : est-ce une simplification ou une complexification ? - Elle va permettre des gains de temps et de transparence, mais un contrôle administratif plus poussé. Est-ce une avancée pour tout le monde ? - La facturation électronique, c'est surtout beaucoup de data en plus. Comment l'entreprise peut-elle valoriser ces novuelles data ?

    • Transcript
Showing 1–20 of 30 episodes