Ian Leysen, PDG et cofondateur de Datadobi – Série d’interviews

Ian Leysen, PDG et cofondateur de Datadobi, est un dirigeant technologique avec plus de trois décennies d’expérience en génie logiciel, assurance qualité et gestion des données d’entreprise. Il a cofondé Datadobi en 2009 après avoir passé huit ans chez EMC en tant que Senior Manager de l’Assurance Qualité, précédés de postes de direction chez Mediagenix et Wave Research. Tout au long de sa carrière, Leysen s’est fortement concentré sur la construction d’organisations d’ingénierie logicielle de haute qualité, ayant créé trois équipes d’assurance qualité à partir de zéro. Chez Datadobi, il supervise une société dont l’objectif est d’aider les grandes entreprises à gérer, gouverner, migrer et protéger les données non structurées sur des environnements sur site, cloud et hybrides. L’entreprise a évolué au-delà de ses racines dans la migration de données à grande échelle pour proposer StorageMAP, une plateforme neutre vis‑à‑vis du fournisseur conçue pour offrir aux organisations une visibilité et un contrôle accrus sur des ensembles de données non structurées complexes, y compris la préparation des données d’entreprise pour les initiatives d’IA.

Datadobi aide les entreprises à obtenir une visibilité et un contrôle accrus sur les volumes de données non structurées qui croissent rapidement. Son logiciel peut analyser des milliards de fichiers pour identifier les données obsolètes, les doublons, les lacunes de propriété et les risques potentiels, tout en appliquant des métadonnées et des balises de classification qui soutiennent la gouvernance et les politiques automatisées d’archivage, de suppression et de rétention. Cela est devenu de plus en plus important à mesure que les organisations préparent leurs données d’entreprise pour l’IA générative, où des informations mal comprises ou périmées peuvent introduire du bruit, des problèmes de conformité et des risques de sécurité. Datadobi permet également aux sociétés d’identifier les ensembles de données potentiellement précieux, de les organiser pour une utilisation en aval, et de déplacer les informations sélectionnées vers des lacs de données ou des lakehouses tout en conservant la traçabilité et la gouvernance. La plateforme fournit en outre des informations sur les coûts de stockage et l’impact carbone, aidant les organisations à prendre des décisions plus éclairées sur les données à conserver et où elles doivent résider.

Vous avez passé huit ans à diriger l’assurance qualité chez EMC avant de co-fonder Datadobi en 2010. Qu’avez‑vous observé dans les environnements de stockage et de données d’entreprise à grande échelle qui vous a convaincu qu’il était possible de créer une société, et comment cette vision originale a‑t‑elle évolué alors que les données non structurées sont devenues de plus en plus importantes pour l’IA ?

Chez EMC, j’ai passé des années à observer les entreprises investir massivement dans l’infrastructure de stockage tout en n’ayant pratiquement aucune visibilité sur ce qui y était réellement stocké. Nous étions excellents pour aider les clients à stocker et protéger les données, mais personne ne posait la question plus difficile : de quoi s’agit‑il, qui en est propriétaire, quelqu’un en a‑t‑il encore besoin, et quelle en est la valeur ? Cet écart entre la capacité de l’infrastructure et la compréhension des données était l’opportunité. Nous avons créé Datadobi pour aider les organisations à déplacer et gérer les données non structurées de manière intelligente, pas simplement à les transférer d’un tableau à un autre.

Ce qui a changé, ce sont les enjeux. Il y a quinze ans, un partage de fichiers non géré était un problème de coût et de conformité. Aujourd’hui, ce même partage de fichiers non géré devient une responsabilité dès que quelqu’un pointe un modèle ou un agent d’IA dessus. Les données non structurées sont passées d’un simple élément que les organisations stockaient à l’élément qui détermine si leurs initiatives d’IA réussissent ou échouent. Notre idée de départ, selon laquelle l’infrastructure de stockage à elle seule ne peut pas vous dire ce que vos données signifient pour l’entreprise, n’a pas changé. Elle est simplement devenue urgente d’une manière jamais vue auparavant.

Vous avez soutenu que l’IA générative n’a pas créé le problème des données d’entreprise, mais a plutôt exposé et accéléré des problèmes qui existent depuis des décennies. Quelles sont les principales faiblesses que l’IA révèle aujourd’hui dans la façon dont les organisations ont historiquement géré leurs données ?

Les organisations ont du mal à comprendre leurs données d’entreprise depuis des décennies. L’IA n’a pas créé cette difficulté, elle a simplement éliminé les lieux où elle se cachait. Lorsque les données restaient tranquillement sur un partage de fichiers ou dans une archive, personne n’était tenu de répondre de ce qu’elles contenaient. Dès que vous pointez un grand modèle de langage ou un pipeline RAG dessus, chaque faiblesse devient visible et conséquente.

Le principal défi est que la plupart des organisations gèrent le stockage, pas les données. Elles savent où se trouvent leurs volumes et leurs seaux, mais pas ce qu’ils contiennent : quels fichiers sont obsolètes, quels contiennent des informations sensibles ou réglementées, quels sont dupliqués des dizaines de fois dans l’environnement, et qui y a réellement accès. L’IA expose également à quel point la propriété est fragmentée. Les données s’accumulent sur des systèmes sur site, plusieurs clouds et dépôts SaaS, et personne ne possède la vision d’ensemble. Ce ne sont pas de nouveaux problèmes. L’IA a simplement rendu le coût de les ignorer immédiat et visible.

Les organisations concentrent souvent leurs investissements en IA sur des modèles plus puissants, des GPU et l’infrastructure. Pourquoi davantage de calcul ou de stockage ne résout‑il pas le problème sous‑jacent de la préparation des données, et où les entreprises devraient‑elles investir à la place ?

Plus de puissance de calcul fait arriver plus rapidement une mauvaise réponse. Cela ne rend pas la réponse précise, sûre ou conforme. Les GPU et l’infrastructure de stockage exécutent des décisions qu’ils ne prennent pas. Si vous alimentez un modèle puissant avec des données obsolètes, dupliquées, mal autorisées ou sensibles, vous obtenez un modèle puissant qui produit à grande échelle des résultats peu fiables ou risqués, et ce, rapidement.

Nous pensons que le marché a atteint un point d’inflexion important : historiquement, les organisations optimisaient le stockage ; de plus en plus, elles doivent optimiser les données. Cela implique d’investir dans la discipline qui se situe au‑dessus de la couche d’infrastructure, la capacité de voir l’ensemble de votre patrimoine de données, de comprendre ce que chaque donnée est réellement et qui en est responsable, de décider ce qui doit être conservé, déplacé, archivé ou supprimé, puis d’exécuter cette décision de manière cohérente. Dépenser pour l’infrastructure sans cette discipline signifie simplement que les organisations peuvent faire la mauvaise chose plus rapidement.

C’est précisément le problème que notre plateforme de gestion des données non structurées a été conçue pour résoudre. Elle offre aux organisations une vue unique sur le stockage sur site, cloud et SaaS, classe les données grâce à des balises et à l’analyse des métadonnées afin que les équipes puissent identifier ce qui est redondant, obsolète ou réellement précieux, puis exécute les décisions – migration, archivage ou suppression – via des flux de travail pilotés par des politiques qui fonctionnent en continu plutôt que comme un projet ponctuel. Cette combinaison de visibilité, de classification et d’exécution cohérente transforme « nous avons beaucoup de données » en « nous savons exactement ce que nous possédons et ce qu’il faut en faire ».

« Données prêtes pour l’IA » est devenu une expression courante dans l’industrie. Selon vous, qu’est‑ce qui rend réellement les données non structurées prêtes pour l’IA, et quels critères les organisations devraient‑elles appliquer avant d’autoriser des données dans une IA générative, une génération augmentée par récupération (RAG) ou un pipeline d’entraînement ?

Les données prêtes pour l’IA sont des données qu’une organisation a déjà validées, pas simplement des données qu’elle possède. En pratique, cela signifie que l’organisation peut répondre avec confiance à une série de questions avant que ces données n’atteignent un modèle ou un pipeline : ces données sont‑elles exactes et à jour, ou sont‑elles restées inactives pendant des années ? Sont‑elles dupliquées ailleurs d’une manière qui fausserait ou contredirait les résultats ? Contiennent‑elles des informations sensibles, réglementées ou personnelles qui ne devraient pas être exposées ? Qui est autorisé à y accéder, et cela correspond‑il toujours à qui devrait pouvoir le faire ? Apportent‑elles réellement une valeur métier au cas d’usage, ou ne sont‑elles que du bruit ?

Sans réponses à ces questions, injecter des données dans une IA générative ou un pipeline RAG ne fait que déplacer votre problème de gouvernance en aval, vers un système qui met en évidence ce qu’il trouve bien plus efficacement que vos partages de fichiers ne l’ont jamais été. La préparation des données pour l’IA est une discipline d’intelligence des données, pas une case à cocher que l’on coche une fois avant le lancement d’un projet.

Les entreprises peuvent disposer de milliards de fichiers répartis sur des infrastructures sur site, plusieurs clouds, des archives et des unités métier. Comment peuvent‑elles déterminer quelles données contiennent une valeur métier significative et lesquelles sont redondantes, obsolètes, triviales ou simplement du bruit pouvant dégrader les performances de l’IA ?

À cette échelle, personne ne répondra à cette question fichier par fichier, et la revue manuelle n’est pas une stratégie viable. Les organisations ont d’abord besoin d’une visibilité à l’échelle de l’entreprise : une vue unique et précise sur les dépôts sur site, cloud et SaaS, car on ne peut prendre de décision sur des données qu’on ne voit pas. Ensuite, il s’agit d’appliquer l’intelligence des données pour classer ce qui se trouve réellement dans l’environnement, afin que les données ROT (redondantes, obsolètes et triviales) soient identifiées et séparées des données qui apportent réellement une valeur métier.

C’est à ce moment que la discipline doit aller au‑delà de la simple visibilité. Voir vos données est nécessaire mais pas suffisant. Les organisations doivent progresser en comprenant ce que ces données sont et signifient, en décidant ce qu’il faut en faire – conserver, déplacer, archiver, supprimer ou les utiliser pour alimenter l’IA – puis en exécutant cette décision de façon cohérente sur des milliards d’objets. Passer directement de la visibilité à l’ingestion par l’IA est exactement la façon dont le bruit finit par dégrader les performances du modèle et comment les données réellement précieuses se retrouvent enfouies dedans.

La sécurité et la gouvernance deviennent particulièrement importantes lorsque les systèmes d’IA peuvent mettre en évidence des informations qui étaient auparavant difficiles à découvrir pour les employés. Comment les organisations doivent‑elles évaluer les permissions, les informations sensibles, la propriété et les risques réglementaires avant d’exposer les données d’entreprise aux systèmes d’IA ?

C’est l’un des domaines où l’IA a le plus modifié le calcul des risques. Un fichier avec des permissions excessives ou obsolètes était auparavant une exposition théorique, car en pratique, une personne aurait dû savoir qu’il existait et le chercher. Un système d’IA avec un accès étendu peut mettre ce même fichier à la disposition de quiconque pose la bonne question, instantanément. L’obscurité n’a jamais été un véritable contrôle, mais l’IA a éliminé le dernier filet de protection qu’elle offrait par inadvertance.

Avant que des données ne soient exposées à un système d’IA, les organisations ont besoin d’une vision claire de qui y a accès et si cet accès reste pertinent, des informations sensibles ou réglementées qu’elles contiennent, de qui en est propriétaire et responsable, ainsi que des obligations réglementaires qui y sont liées – résidence des données, conservation et exigences de confidentialité, entre autres. Cette évaluation ne peut pas être un audit ponctuel avant le lancement. Les données d’entreprise évoluent en continu, de sorte que les permissions, la propriété et les risques doivent être revus de façon permanente, et non seulement au moment où un projet d’IA est mis en production.

Datadobi préconise de déplacer la conversation de la gestion de l’infrastructure de stockage vers la gestion des données en tant qu’actif métier. À quoi ressemble cette transition en pratique, et comment modifie‑t‑elle la relation entre les équipes IT, les équipes data, les responsables de la sécurité et les unités métier ?

En pratique, cela signifie que la conversation ne porte plus sur la capacité, le tiering ou la disponibilité, mais sur les résultats : réduction des coûts, réduction des risques, conformité réglementaire et habilitation de l’IA. Ces objectifs étaient auparavant traités comme des initiatives distinctes, chacune avec ses propres outils et responsables. Nous estimons que cette vision devient de plus en plus obsolète. Elles dépendent toutes de la compréhension des mêmes données d’entreprise sous‑jacentes, et ce dont il faut, c’est un nouveau modèle opérationnel centré sur les données qui les relie, plutôt que de traiter chaque initiative comme dépendante d’un système séparé et isolé. Notre plateforme est la façon dont nous mettons ce modèle opérationnel en pratique.

Cela change naturellement les participants à la discussion. L’IT n’est plus le seul propriétaire de la conversation, car les décisions concernant les données à conserver, déplacer ou exposer à l’IA sont des décisions métier, éclairées par l’intelligence des données, et non des décisions d’infrastructure. Les responsables de la sécurité et de la conformité ont besoin de visibilité sur le même paysage de données que celui géré par l’IT. Les unités métier ont besoin d’une voix sur les données qui comptent réellement pour leurs résultats. La gestion des données cesse d’être une fonction de back‑office IT et devient une discipline opérationnelle partagée où IT, sécurité et métier prennent des décisions à partir des mêmes informations.

Un des défis de l’IA d’entreprise est que les données évoluent constamment. La préparation des données pour l’IA est‑elle quelque chose que les organisations peuvent atteindre une fois pour toutes, ou nécessite‑t‑elle un processus continu de découverte, classification, gouvernance, archivage et déplacement des données au fur et à mesure de leur évolution ?

C’est un processus continu, point final. Les données d’entreprise évoluent en permanence, de nouveaux fichiers sont créés, les permissions changent, les employés arrivent et partent, les réglementations évoluent, de sorte que la gestion des données doit devenir une capacité opérationnelle continue plutôt qu’une suite de projets indépendants. Considérer la préparation des données pour l’IA comme un nettoyage ponctuel avant le lancement d’un projet revient à déclarer un bâtiment sécurisé après une unique visite de serrurier et ne plus jamais vérifier les portes.

Ce dont les organisations ont besoin, c’est d’une discipline opérationnelle qui passe continuellement par la visibilité, la compréhension, la décision et l’exécution, en découvrant les données existantes, en les classifiant et les comprenant, en décidant ce qu’il faut en faire, puis en agissant sur cette décision de façon récurrente. Les organisations qui surpassent leurs concurrentes seront celles capables de traverser ce cycle de façon continue et à l’échelle de l’entreprise, et non celles qui traitent la préparation des données pour l’IA comme un projet à date de fin.

À mesure que les entreprises déploient de plus en plus d’agents IA capables de rechercher à travers les systèmes et d’effectuer des actions autonomes, la gestion des données non structurées devient‑elle encore plus importante ? Quels nouveaux risques apparaissent lorsqu’un agent IA peut accéder à des informations disséminées dans l’organisation plutôt que de simplement répondre à une requête utilisateur ?

Cela devient nettement plus important, car un agent modifie la nature de l’exposition. Un chatbot qui répond à une seule requête est limité à ce qu’une personne demande et voit. Un agent capable de rechercher à travers les systèmes et d’agir de façon autonome peut parcourir beaucoup plus d’environnement qu’un employé individuel ne le ferait habituellement, et il peut agir sur ce qu’il trouve – déplacer, partager ou utiliser des données – sans qu’un humain ne revoie nécessairement chaque étape.

Cela introduit un risque qui dépasse la simple découverte. Si un agent a accès à des données qu’il ne devrait pas (fichiers mal autorisés, enregistrements sensibles obsolètes, informations qui auraient dû être archivées ou supprimées il y a des années), il peut agir sur ces données à la vitesse et à l’échelle d’une machine, pas seulement les mettre à la disposition d’un utilisateur curieux. Les organisations qui déploient les agents avec le plus de succès sont celles qui ont considéré la gouvernance des données comme une condition préalable, et non comme une réflexion tardive, car un agent exploitera fidèlement les lacunes existantes dans votre intelligence des données.

Pour une entreprise qui a accumulé des décennies de données non structurées et qui souhaite faire évoluer ses initiatives d’IA, quelles étapes pratiques recommandez‑vous de suivre en premier, et quelles erreurs les dirigeants doivent‑ils éviter lorsqu’ils commencent à maîtriser leur patrimoine de données ?

Commencez par la visibilité. Vous ne pouvez pas prendre de bonnes décisions sur des données que vous ne voyez pas, donc la première étape pratique consiste à obtenir une image précise et à l’échelle de l’entreprise de ce qui existe dans les environnements sur site, cloud et SaaS. À partir de là, passez à la compréhension, en classifiant ces données afin de savoir ce qui est précieux, ce qui est sensible et ce qui n’est que du bruit, avant de prendre des décisions concernant la rétention, la migration, l’archivage ou la suppression.

Il existe également une réalité budgétaire que les dirigeants ne peuvent ignorer. La plupart des DSI ne disposent pas d’un budget IA séparé et illimité ; ils travaillent avec un pool de fonds fixe qui voit désormais l’IA concurrencer tout le reste nécessaire au bon fonctionnement de l’entreprise. L’instinct de financer l’IA en réduisant les investissements dans l’infrastructure existante est une mauvaise décision, car cette même infrastructure – stockage, pipelines de données, gouvernance – est exactement ce dont l’IA dépend pour réussir. La voie la plus durable consiste à créer de la marge au sein du patrimoine existant : améliorer la visibilité et réduire le gaspillage de stockage grâce au type d’optimisation des données pour lequel StorageMAP a été conçu libère un vrai budget, sans toucher à la capacité dont les initiatives IA auront réellement besoin.

La plus grande erreur que je constate est que les organisations passent directement à l’exécution, en pointant l’IA sur leur patrimoine de données, ou lancent un projet de nettoyage, sans d’abord construire cette base de visibilité et de compréhension. La deuxième erreur consiste à considérer cela comme une initiative ponctuelle plutôt qu’une capacité opérationnelle ; les données évoluent constamment, la discipline doit donc être continue. La troisième erreur est de la réduire à un exercice purement technique. Les organisations qui réussissent traitent cela comme une décision métier, avec les parties prenantes IT, sécurité et métier alignées sur la valeur des données et sur ce qui doit en être fait, et non comme un simple projet de migration ou de stockage confié uniquement à l’IT.

Merci pour cette excellente interview, les lecteurs qui souhaitent en savoir plus devraient visiter Datadobi.