Comment Deutsche Börse a créé un outil d'IA générative pour gérer la migration à grande échelle des notebooks Zeppelin vers Databricks

Chez Deutsche Börse Group, notre plateforme StatistiX fournit environ 95 % de toutes les données de compensation et de négociation du groupe, permettant l'analyse en libre-service pour des centaines d'utilisateurs professionnels. Garder ces données accessibles et exploitables est au cœur de tout ce que nous faisons.

Pendant des années, cela signifiait des notebooks Zeppelin fonctionnant sur Cloudera, avec un accès aux systèmes de données HDFS et Oracle. La plateforme nous a bien servi, mais le paysage a changé. Cloudera désaffecte complètement Zeppelin en 2027, nos charges de travail d'analyse migrent vers le cloud, et Databricks a été sélectionné comme notre nouvelle plateforme d'analyse unifiée. Cette combinaison a créé un défi de migration que la plupart des organisations sous-estiment : plus de 2 000 utilisateurs et un grand nombre de notebooks, dont beaucoup sont profondément intégrés dans les flux de travail quotidiens, le tout devant être migré.

Réécrire tout manuellement prendrait des années. Nous avons donc décidé de construire un meilleur chemin sur Databricks.

Le problème de la migration des notebooks

Les migrations d'infrastructure retiennent beaucoup l'attention. Les migrations de notebooks ont tendance à ne pas en retenir, ce qui est une raison majeure pour laquelle elles ralentissent les équipes.

Nos notebooks Zeppelin n'étaient pas de simples scripts. Ils contenaient une logique SQL et Python complexe, des interpréteurs personnalisés, des références Oracle et HDFS, des visualisations, des widgets et une logique de planification construits au fil des ans. Chacun reflétait la connaissance institutionnelle des équipes métier qui s'y fiaient. La diversité de l'ensemble du paysage des notebooks rendait un moteur de réécriture basé sur des règles impraticable, car la logique était tout simplement trop hétérogène et trop spécifique à l'entreprise pour que des règles automatisées puissent la gérer de manière fiable.

Cette contrainte nous a conduits à une idée de conception plus claire : séparer la structure de la logique et appliquer le bon outil à chacune. La conversion structurelle (mapper le format des paragraphes Zeppelin aux cellules Databricks, traduire la syntaxe de l'interpréteur, reformater les métadonnées) est déterministe et automatisable, tandis que la reconstruction de la logique ne l'est pas. Heureusement, les LLM sont excellents pour cette partie de la conversion structurelle.

Construire le convertisseur sur les applications Databricks

Avec ce principe de conception en main, nous avons construit le convertisseur de notebooks Zeppelin vers Databricks, une application Databricks conçue spécifiquement pour notre flux de travail de migration.

L'application gère le côté structurel de la conversion : les paragraphes Zeppelin deviennent des cellules Databricks, les mappages d'interpréteurs sont appliqués (%python, %sql, %pyspark et d'autres sont traduits dans leurs équivalents Databricks), et les métadonnées du notebook sont reformatées en JSON .ipynb valide. Le contenu original est préservé exactement. Nous ne réécrivons pas la logique à ce stade, nous la préparons simplement pour la prochaine étape.

Cette prochaine étape est Genie. Pour chaque notebook téléchargé, l'application génère automatiquement une invite contextuelle qui inclut des détails spécifiques sur notre environnement Zeppelin. Pensez à nos interpréteurs personnalisés, nos sources de données et nos modèles de configuration. L'invite donne à Genie le contexte dont il a besoin pour reconstruire la logique avec précision d'une manière native à Databricks.

Le flux de travail pour un utilisateur professionnel est simple :

1. Exporter un notebook Zeppelin au format JSON
2. Le télécharger dans l'application Databricks
3. Cliquer sur Convertir
4. Télécharger le fichier .ipynb converti
5. Ouvrir Databricks, télécharger le notebook, lancer Genie et coller l'invite générée
6. Genie pose des questions clarifiantes et reconstruit le notebook

L'application elle-même a été construite avec un frontend shadcn UI. À l'origine, nous avions créé un prototype Streamlit, mais nous avons estimé que shadcn nous offrait une interface plus professionnelle et évolutive. L'expérience de développement des applications Databricks a permis une expédition rapide sans avoir à mettre en place une infrastructure distincte.

Ce que nous avons choisi de ne pas automatiser

L'une des décisions de conception les plus importantes a été de déterminer ce que l'outil devait intentionnellement laisser de côté.

Le convertisseur ne réécrit pas la logique SQL, la logique Python, les visualisations, les widgets, les références Oracle et HDFS, la logique de planification ou le code personnalisé spécifique à l'entreprise. Tout ce contenu est préservé dans le notebook converti, intact, car sa réécriture automatique introduirait des erreurs et saperait la confiance dans le résultat. Ce sont précisément les éléments qui varient le plus d'un notebook à l'autre et qui portent la logique la plus critique pour l'entreprise. Ils appartiennent à Genie, qui peut interpréter le contexte, poser des questions clarifiantes et prendre des décisions que les règles ne peuvent pas.

Cette approche hybride consistant à automatiser la partie déterministe et à déléguer la partie variable nous permet d'éviter la fragilité des systèmes basés sur des règles et de tirer parti de l'IA là où elle fonctionne réellement bien.

Le résultat : des heures aux minutes

En combinant la conversion structurelle avec la reconstruction de logique assistée par IA, nous avons réduit le redéveloppement de notebooks de plusieurs heures d'efforts manuels à 15 à 20 minutes par notebook, selon la complexité. Pour une migration à grande échelle de cette nature, couvrant plusieurs domaines d'activité, cette approche transforme ce qui aurait été une entreprise coûteuse en ressources et longue en un flux de travail évolutif et répétable qui prendra beaucoup moins de temps.

Le gain de vitesse change également la nature du travail. Les utilisateurs professionnels n'ont pas besoin d'une expertise approfondie de Databricks pour migrer leurs propres notebooks. Ils suivent une courte séquence d'étapes, obtiennent une invite, et laissent Genie faire la reconstruction. L'outil est suffisamment accessible pour que la migration ne nécessite pas une équipe d'ingénierie dédiée.

Ce que nous avons appris

Quelques principes sont ressortis de ce projet que nous appliquerions à tout effort similaire.

• Évitez la sur-ingénierie. Notre première tentative a utilisé une architecture agentique plus complexe qui a ajouté de la surcharge sans résoudre le problème principal. Une interface utilisateur simple et un backend propre se sont avérés exactement suffisants.
• La réécriture basée sur des règles n'est pas évolutive pour un contenu hétérogène. La diversité de la logique dans nos notebooks rendait les règles impraticables. Les LLM sont essentiels pour gérer cette variabilité et la clé est de concevoir la transition entre l'automatisation et l'IA de manière réfléchie.
• Le contexte fait la différence entre une bonne invite et une excellente invite. Les invites Genie génériques produisent des résultats génériques. Investir dans une invite qui encode la connaissance de notre environnement spécifique – interpréteurs, sources de données, modèles de configuration – est ce qui a rendu le résultat réellement utilisable.
• Impliquez votre équipe de plateforme tôt. Notre collaboration avec l'équipe Databricks tout au long du développement nous a aidés à rester alignés et à éviter les retouches.

Prochaines étapes

Bien que le développement initial de notre outil de conversion soit terminé, nous procédons maintenant à des tests à grande échelle dans le monde réel. Nos priorités immédiates comprennent la finalisation des définitions d'invites pour améliorer la précision, la validation de l'outil avec des notebooks de plusieurs entités commerciales et de l'informatique, et la préparation de l'intégration des utilisateurs.

L'implication plus large est ce qui nous enthousiasme le plus. Ce projet a démontré que la migration assistée par IA n'est pas une capacité future, elle est disponible dès maintenant ! En combinant les applications Databricks avec l'IA générative, nous avons construit un flux de travail répétable qui transforme l'un des problèmes les plus difficiles de la transformation cloud en un processus rapide et évolutif.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original