Bonjour à tous, je m'appelle Christopher Pillsbury et je suis ravi d'être parmi vous aujourd'hui. Je vais vous expliquer comment nous avons créé un cadre qui aide les équipes R&D à concrétiser leurs idées en associant AWS, Snowflake et JMP.
Dans cette session, nous verrons comment les données expérimentales sont collectées et analysées en temps réel, et comment cette architecture permet aux scientifiques de prendre des décisions plus rapides et plus fiables. Quel que soit votre rôle en R&D, en science des données ou en opérations, mon objectif est de vous montrer le cheminement des données brutes vers l'analyse et comment l'analyse évolutive peut transformer la façon dont les équipes innovent et collaborent.
Aujourd'hui, je commencerai par vous présenter les étapes clés de la mise en œuvre de notre instance JMP Live. Nous explorerons le parcours des données, de l'expérimentation brute à la prise de décisions concrètes, et nous discuterons des impacts de la mise à l'échelle de la génération de données. Je présenterai le processus d'architecture d'IDEXX Data Solutions, en montrant comment l'ingestion, l'organisation des données et l'analyse interagissent pour donner plus d'autonomie aux utilisateurs de la R&D. Nous examinerons des exemples concrets de tableaux de bord et de rapports en action et leur impact mesurable sur la prise de décision et l'efficacité.
Enfin, je conclurai avec les principaux points à retenir et les leçons tirées de la création d'un système d'analyse en temps réel évolutif en R&D. Mais avant cela, permettez-moi de vous expliquer en quoi consiste mon rôle.
Un architecte de solutions de données n'est pas un simple rôle. C'est un mélange de plusieurs disciplines qui s'unissent pour rendre les données exploitables, fiables et percutantes. Cela inclut la gouvernance et la sécurité, qui garantissent la conformité, la confidentialité et les contrôles d'accès pour que les données restent fiables et sécurisées. L'ingénieur de données, quant à lui, veille à ce que les données circulent là où elles doivent aller, en créant des pipelines, des intégrations et des transformations pour que les données brutes deviennent exploitables.
DevOps gère l'infrastructure, les plateformes cloud, l'automatisation et assure la sécurité et la résilience de l'ensemble. Architecture des données : conception de modèles, définition des structures et garantie de l'évolutivité des fondations. Analyste de données : traduction des données en informations, tableaux de bord, visualisations et récits qui orientent les décisions. Analyste métier : connexion entre l'aspect technique et la problématique métier, collecte des exigences, compréhension du contexte et garantie de résolution des problèmes pertinents.
Enfin, je suis administrateur de bases de données, axé sur la performance, l'optimisation, la fiabilité et, dans le monde actuel, sur les coûts. L'ensemble de ces perspectives constitue le rôle d'architecte de solutions de données. Mon rôle consiste à combiner les différentes fonctions et à proposer des solutions qui connectent les personnes et les équipes afin de créer des pipelines de données jusqu'aux informations métier.
Maintenant que vous me connaissez un peu et que vous connaissez mon rôle, parlons un peu de notre parcours JMP Live jusqu'à présent. Comme tout bon projet, nous avons commencé par des échanges avec le service informatique de l'entreprise, afin de définir un plan de déploiement cloud first et les étapes à suivre. Leurs conseils nous ont aidés à configurer un serveur Azure et les comptes de service nécessaires, établissant ainsi la base sécurisée nécessaire à l'automatisation.
Le 31 juillet 2024, Alex m'a aidé à installer et à mettre en service JMP Live. Un peu plus d'une semaine plus tard, le 9 août, nous avons publié notre premier rapport entièrement automatisé à partir d'une vue Snowflake. Au cours de la première année de notre projet pilote, nous avons repoussé les limites de notre instance JMP Live en testant la charge des graphiques SPC automatisés avec 7 millions d'enregistrements et plus de 20 colonnes, actualisés toutes les 5 minutes. Nous avons également déployé des tableaux de bord pour répondre aux différents besoins métier et nous avons veillé à ce que cette architecture puisse évoluer tout en fournissant des informations en temps réel aux équipes qui l'utilisent au quotidien.
Sur le papier, notre mise en œuvre est très simple. Cependant, le parcours global, de l'idée à la décision, et le chemin vers les données, ne le sont pas. Quiconque a travaillé avec des expériences, des données et des rapports sait qu'il y a de nombreuses étapes cachées. C'est pourquoi, avant d'aborder l'évolutivité et les systèmes, je souhaite nous ancrer dans le processus que nous partageons tous. Que vous soyez en R&D, en science des données ou en opérations, le cheminement d'une idée à une décision concrète suit un schéma similaire.
Le chemin vers une idée est une façon simple mais efficace de décrire comment nous passons de la curiosité à la décision. Tout commence par une question ou une hypothèse. Vous êtes peut-être en R&D et testez un nouveau concept de produit, ou vous explorez et analysez un vaste ensemble de données. Tôt ou tard, une idée mérite d'être testée. À partir de là, des expériences sont menées, des lots sont fabriqués, voire du code est développé.
C'est ici que le travail commence réellement. Les données de sortie issues des instruments, de l'enregistrement manuel des données ou des ensembles de données générés par code sont stockées, parfois localement, parfois dans le cloud, mais à ce stade, elles sont encore brutes. Vient ensuite la phase critique : la structuration, le nettoyage et l'analyse des données. C'est là que nous appliquons des méthodes statistiques, testons nos hypothèses et commençons à révéler les tendances cachées dans les résultats.
Enfin, les informations sont communiquées. Cela peut prendre la forme d'une présentation, de la rédaction des résultats dans ELN ou de la communication d'une étape importante du développement. Souvent, ces informations suscitent la série de questions suivantes et le cycle recommence.
À un niveau supérieur, vous avez fait le travail. Vous avez mené l'expérience, collecté les données, les avez triées, effectué votre analyse, et félicitations ! Vous avez trouvé une idée. Maintenant, naturellement, vous souhaitez partager vos résultats. Quelle est la prochaine étape ? Vous prenez votre fidèle PowerPoint, vous copiez les graphiques, vous ajoutez éventuellement une ou deux zones de texte, puis vous présentez le tout en réunion. À ce moment-là, vous avez atteint votre objectif. Vous avez généré des données qui étayent une décision.
Mais voici la question qui mérite réflexion : à quel prix ? Combien de temps avez-vous mis à mettre en forme les données ? Combien d’étapes manuelles avez-vous dû effectuer ? Combien de fois avez-vous dû réexporter, reformater ou mettre à jour en cas de changement ? C’est ce que j’appelle la taxe cachée sur la connaissance. Le coût du passage des données brutes à la prise de décision.
En réalité, les données que vous générez ne s'intègrent pas parfaitement dans JMP ou tout autre système. La plupart du temps, elles sont brutes, fragmentées et incohérentes. Cela signifie que vous ou votre équipe passez des heures à localiser, nettoyer, structurer et manipuler manuellement ces données avant même de pouvoir commencer à les analyser.
Une fois que vous avez enfin obtenu un tableau exploitable, que se passe-t-il ensuite ? Vous devrez peut-être ajouter des calculs. Vous pourrez peut-être créer quelques colonnes dérivées. JMP est idéal pour cela. Mais parfois, on se rabat sur Excel, car il paraît plus simple. Cela demande un investissement en temps considérable, surtout lorsque l'analyse est réalisée de toutes pièces, même pour des expériences produisant le même résultat.
Mais voilà le piège. Même avec des processus standardisés, tout est statique. C'est figé. Vous avez fait le travail, mais pour l'expérience suivante, il faut tout recommencer. C'est là le fardeau. Une vision acquise une fois, mais au prix d'un travail manuel important, sans moyen simple de l'actualiser ou de la réutiliser.
Que se passe-t-il lorsque l'on essaie de se développer ? Voyez les choses ainsi. On n'attend pas des ingénieurs de données qu'ils comprennent la science pour gérer les données. Il va de soi qu'on ne devrait pas s'attendre à ce que les scientifiques deviennent des ingénieurs de données pour gérer la science. Leur expertise réside dans l'expérimentation, la découverte et l'interprétation. C'est là que leur temps est le plus précieux. Plus ils passent de temps à nettoyer des feuilles de calcul ou à se débattre avec des formats, moins ils consacrent de temps à la science. L'évolutivité repose sur des systèmes qui évoluent sans s'effondrer sous l'effet de davantage de personnes, de davantage de données ou d'une complexité accrue.
Prenons le chemin d'une idée et appliquons-la à une équipe qui génère des données. Dès que l'on ajoute des personnes au processus, on introduit un tout nouveau défi : la variation. Chaque personne possède des compétences en traitement de données, des habitudes et des méthodes de formatage et de structuration des résultats qui lui sont propres. Plus on se rapproche des données brutes, plus la variation est importante.
Et ce n'est pas tout. Cette variation se poursuit tout au long de l'analyse et jusqu'au reporting. Résultat : le partage des données n'est pas simple et les analyses ne sont pas toujours cohérentes. Et les présentations ? Eh bien, elles peuvent se transformer en une véritable aventure : « Que signifie ce graphique ? » « Ah, ça ? J'aime bien la mise en page de tel ou tel, alors j'ai copié son style. »
Que se passe-t-il ? Les équipes consacrent un temps considérable, invisible, à aligner les emplacements de stockage, les définitions de colonnes, à nettoyer, formater et à assurer la continuité. Cet effort caché se multiplie à mesure que les données sont générées. Si ce scénario se présente pour une seule équipe, imaginez que cela puisse s'étendre à un service entier.
De nombreuses équipes génèrent des données, chacune avec ses propres approches. Soudain, d'innombrables heures sont consacrées à manipuler ces données et à essayer de les mettre en forme. Mais le problème principal reste la variation. Interprétations, analyses, calculs, formats de sortie différents : toutes ces différences nuisent à l'efficacité.
Et à grande échelle ? Cela ne ralentit pas seulement les projets individuels, mais peut aussi freiner la progression globale. C'est là le véritable fardeau organisationnel. Lorsque chaque équipe réinvente la roue, les informations manquent de cohérence, l'alignement prend du temps et la dynamique s'essouffle. Le défi, et l'opportunité, réside dans la mise en place de systèmes permettant à chaque groupe de se concentrer sur ses points forts tout en collaborant harmonieusement.
Chez IDEXX, nous avons pris conscience de ce défi et nous nous efforçons de reconstruire la relation de nos collaborateurs avec les données. Nous avons repensé nos systèmes, nos équipes et nos processus afin que, au lieu de se débattre avec les données, chacun puisse se concentrer sur leur utilisation. Cela implique de définir clairement les tâches, de créer des automatisations utiles et de créer un accès sans code ou low code aux systèmes Big Data que nous mettons en place. Car devenir une organisation axée sur les données ne se résume pas à la technologie. Il s'agit de comprendre où se situent réellement les difficultés et les gaspillages. Il s'agit de savoir ce qui peut être concrètement enseigné aux collaborateurs et ce qui est mieux résolu grâce à la technologie.
En combinant les forces de nos collaborateurs avec celles des bons outils, AWS, Snowflake et JMP, nous supprimons les obstacles à la compréhension et permettons aux équipes d'avancer plus rapidement avec cohérence et confiance.
En résumé, dans le paysage actuel de la R&D, les systèmes évolutifs ne sont plus une option. La science progresse à un rythme plus rapide que jamais. Le volume de données que nous générons ne cesse de croître. Si nos systèmes ne sont pas évolutifs, ils ne peuvent pas suivre. Nous nous retrouvons avec des goulots d'étranglement, des incohérences et des efforts inutiles. L'évolutivité est ce qui nous permet de transformer rapidement la science en solutions. Elle fait la différence entre passer des semaines à analyser des données et pouvoir prendre des décisions en temps réel. C'est pourquoi il est crucial de repenser notre approche des données. Car la rapidité, la cohérence et la confiance dans nos connaissances se traduisent directement par des progrès en R&D.
Dans les prochaines minutes, nous allons explorer les détails de l'architecture des solutions de données, qui s'articule autour de deux grandes catégories. La première est le routage et l'ingestion des données, où les données brutes sont collectées, migrées et gérées. La seconde est le data lakehouse et l'analytique, où se trouve notre architecture de données et d'analyse.
Dans notre environnement de R&D, les données peuvent provenir de multiples sources. Certaines sont collectées manuellement par les scientifiques, tandis que d'autres sont générées automatiquement par des instruments et des machines lors d'expériences. Une fois les données disponibles, notre service de migration cloud intervient. Il surveille en permanence les répertoires désignés à la recherche de nouveaux fichiers et, lorsqu'il les détecte, les transfère automatiquement vers le stockage AWS. Ainsi, toutes les données entrantes sont capturées dans un emplacement centralisé et sécurisé, prêtes pour le traitement et l'analyse en aval.
Une fois les données migrées vers AWS, elles entrent dans la couche d'architecture des données. Tous les fichiers y sont collectés et stockés de manière sécurisée, ce qui nous permet de disposer d'un stockage de données brutes évolutif et fiable. Ensuite, les données sont ingérées dans Snowflake via les notifications SNS et Snowpipes, permettant ainsi un transfert en temps réel d'AWS vers notre plateforme de données.
Dans Snowflake, les processus ETL automatisés nettoient, normalisent et transforment les données brutes en modèles standardisés, prêts à être analysés. Nous exploitons également les fonctionnalités avancées de Snowflake, telles que les vues et les tables dynamiques, qui permettent aux analystes et aux scientifiques d'interroger et de combiner plusieurs sources de données de manière fluide, offrant ainsi une base cohérente et efficace pour l'analyse en aval dans JMP Live.
Enfin, nous atteignons la couche d'architecture analytique. C'est là que les modèles de données standardisés de Snowflake sont transformés en vues de données exploitables, conçues pour répondre à des cas d'usage métier et scientifiques spécifiques. Nous proposons des points d'accès personnalisés, adaptés aux besoins des différentes parties prenantes et à leurs workflows analytiques, afin que les utilisateurs puissent se concentrer sur l'analyse plutôt que sur le traitement des données.
Essentiellement, cette couche fait le lien entre les données brutes et la prise de décision, en alignant les structures de données sur les rapports, la visualisation et les objectifs métier globaux. C'est l'étape qui transforme les données structurées en informations pertinentes en temps réel dans JMP Live.
À un niveau élevé, tout commence par la génération des données et la création d'un package de données. Une fois les données créées, notre service de migration cloud surveille en permanence les répertoires concernés et déplace les nouveaux fichiers vers le stockage AWS. Ensuite, la couche d'architecture des données prend le relais. Les données sont ensuite ingérées dans Snowflake depuis AWS via les notifications SNS et Snowpipe.
Dans la couche d'architecture analytique, nous transformons les données brutes en modèles standardisés, puis en vues de données exploitables qui prennent en charge des cas d'utilisation scientifiques spécifiques.
Enfin, la publication de rapports et de données dans JMP Live permet une automatisation en libre-service. En résumé, ce flux, de la génération de données à l'analyse en passant par l'architecture, transforme les données expérimentales brutes en informations qui orientent les décisions.
J'aimerais maintenant m'arrêter un instant. Tous les diagrammes d'architecture et organigrammes que nous avons vus sont importants. Ils démontrent le fonctionnement du système. Ils ne prouvent pas leur valeur intrinsèque. La véritable valeur apparaît lorsque les utilisateurs du système, nos scientifiques, peuvent immédiatement accéder aux informations dont ils ont besoin pour prendre des décisions.
Lorsqu'un scientifique déclare : « C'est exactement ce dont j'ai besoin », c'est à ce moment-là que le système a eu un réel impact. C'est précisément ce que nous allons explorer ensuite : les cas d'utilisation concrets et les impacts mesurables qui illustrent comment cette architecture se traduit en résultats pour la R&D.
Pour préparer le terrain, nous disposons d'un lecteur de plaques de microtitration qui génère un fichier journal comportant deux variantes, comme vous pouvez le voir ici. Lors d'un cycle d'étalonnage et de contrôle, les instruments génèrent ces fichiers journaux. Ils contiennent des résultats d'étalonnage et de contrôle importants, intégrés dans des tableaux directement au sein du fichier.
Une équipe de MPD s'est vivement intéressée à ces données et a créé un processus de reporting permettant de suivre l'état des équipements en fonction des résultats de ces analyses. Comme souvent, les données ne se sont pas simplement collectées auprès des laboratoires de R&D, mais ont également été extraites du terrain. Le hic : tout cela était effectué manuellement. Ce qui n'était au départ qu'une simple curiosité s'est progressivement transformé en un processus répétitif et chronophage.
Chaque mois, les équipes collectaient des centaines de fichiers journaux, copiant et collant manuellement les données dans des tables inutiles et générant des rapports. C'était un travail colossal, répété mois après mois. Un parfait exemple d'une tâche à forte valeur ajoutée ralentie par le travail manuel.
En étroite collaboration avec cette équipe, nous avons mis en place un pipeline de données DSA pour automatiser l'ensemble du processus. Au lieu de collecter manuellement les fichiers, nous les avons saisis par programmation dès leur création et les avons diffusés vers le stockage AWS. Une fois dans Snowflake, les données ont été traitées, nettoyées et standardisées. Nous avons ensuite créé des vues servant de points d'accès aux rapports JMP Live, comme illustré ici dans la capture d'écran. Le résultat est un tableau centralisé et bien organisé, transformant des données autrefois manuelles et désordonnées en une ressource structurée et fiable, utilisable instantanément par les scientifiques pour leurs analyses et leurs prises de décision.
Désormais, le rapport dans JMP Live est automatiquement mis à jour dès qu'un nouvel étalonnage ou contrôle est terminé. Les instruments sont regroupés par identifiant et emplacement, et chaque événement d'étalonnage ou de contrôle est clairement suivi par date. Cela offre une visibilité en temps réel sur l'état du système, aidant ainsi les équipes R&D et les laboratoires de référence à détecter les problèmes de maintenance potentiels avant qu'ils ne se produisent. Autrement dit, nous avons non seulement éliminé les tâches manuelles répétitives, mais nous avons également créé un rapport interservices. Une source unique de données fiables et actualisées.
Ce processus manuel, autrefois chronophage, est désormais entièrement automatisé. Chaque étape du workflow, de la génération des données à la mise à jour du rapport, est réalisée en environ 20 minutes après la fin de l'événement. Cette rapidité d'exécution permet à l'équipe de disposer d'une visibilité en temps réel sur ses données, ce qui permet une prise de décision plus rapide et une gestion plus proactive des expériences et de l'état des instruments.
Mais la valeur du système ne se limite pas à son existence, elle change la façon dont les scientifiques interagissent avec les données. Lorsqu'ils cessent de se demander comment ces données sont arrivées jusqu'ici et commencent à se demander ce qu'elles signifient, c'est la preuve que nous avons apporté une réelle valeur concrète. Dans de nombreux domaines, nous avons transformé des processus manuels chronophages en workflows automatisés en temps réel.
Dans le domaine de l'étalonnage et de la surveillance sur le terrain, un seul scientifique collectait autrefois les données de centaines d'instruments. Désormais, la collecte automatisée à l'échelle du réseau offre une visibilité en temps réel sur l'état du système. Pour l'accès aux données de commercialisation et la mise au point de nouvelles plateformes, l'équipe R&D traitait auparavant manuellement les données des microplaques. L'automatisation fournit désormais des ensembles de données prêts à l'analyse quelques minutes après la lecture de la plaque, accélérant ainsi la prise de décision.
Lors du développement de nouveaux instruments et consommables, nous supprimons le besoin de collecte manuelle de données attendue en établissant une ingestion automatisée, offrant aux équipes un accès quasi instantané aux résultats après l'exécution.
Enfin, dans la fabrication des données SPC, les analyses lentes et répétitives ont été remplacées par des graphiques SPC en temps réel accessibles 24h/24 et 7j/7 via les tableaux de bord JMP Live, permettant une prise de décision plus rapide basée sur les données au sein des équipes.
Quels sont les principaux enseignements ? Les données brutes des instruments sont automatiquement ingérées depuis les laboratoires vers AWS et Snowflake. Cela réduit les délais et garantit aux scientifiques de travailler avec des ensembles de données complets et précis dès le départ. Snowflake offre une plateforme unique et sécurisée pour stocker et structurer toutes les données expérimentales. Finis les silos et les feuilles de calcul fragmentées, place à des données claires et prêtes à être interrogées, accessibles à toutes les équipes. Avec JMP et JMP Live, les scientifiques peuvent créer des tableaux de bord et des analyses réutilisables qui s'actualisent automatiquement avec les nouvelles données, économisant ainsi des heures de travail manuel et permettant une surveillance continue.
Les tableaux de bord s'actualisent au fur et à mesure de la réalisation des expériences, offrant aux décideurs un aperçu en temps réel de la progression, des résultats et des tendances émergentes. Plus besoin d'attendre des rapports statiques.
Les résultats peuvent être facilement partagés entre les équipes de R&D, d'assurance qualité, de fabrication et de direction, ce qui permet d'aligner les priorités et d'accélérer le développement produit. Globalement, ce système transforme la façon dont les équipes accèdent aux données, les analysent et les exploitent, transformant les résultats expérimentaux bruts en informations exploitables et pertinentes, moteurs de l'innovation.
Comme nous l'avons vu aujourd'hui, le passage des données expérimentales brutes aux informations exploitables n'est pas forcément lent ou manuel. En combinant AWS, Snowflake et JMP Live, nous avons créé un système qui capture, structure et analyse automatiquement les données, transformant ainsi ce qui était autrefois un travail fastidieux en informations fiables et en temps réel.
Nous avons démontré plusieurs impacts clés : un accès plus rapide à des données de haute qualité, une architecture évolutive et centralisée, des analyses reproductibles et automatisées, une aide à la décision en temps réel et une visibilité transversale favorisant la collaboration. La véritable mesure du succès réside dans l'expérience utilisateur. Les scientifiques ne se demandent plus comment les données sont arrivées, mais ce qu'elles signifient.
Ce passage d'une question de processus à une question d'analyse est la preuve ultime de la valeur ajoutée du système. À terme, cette approche jette les bases d'une innovation continue. Les équipes peuvent consacrer moins de temps à analyser les données et davantage de temps à les exploiter pour résoudre les problèmes, prendre des décisions et accélérer le développement produit.
Merci pour votre temps aujourd'hui et j'espère que cela vous a donné une idée claire de la manière dont l'analyse évolutive automatisée peut transformer une organisation.
