La Grosse Conf 2025 - 30 % plus rapide : notre recette GenAI pour moderniser le patrimoine analytique de votre entreprise

Retour d’expérience de Jean-Baptiste Larraufie, Data Architect chez OCTO

Photo de Jean Baptise Larraufie

Depuis des années, les projets de modernisation analytique figurent sur les feuilles de route de nombreuses directions data. Ils sont jugés nécessaires, souvent stratégiques, mais ils restent à l’état d’intention. Pourquoi ? Parce qu’ils sont complexes, massifs, et perçus comme coûteux, risqués ou trop longs.

Lors de La Grosse Conf, Jean-Baptiste Larraufie, Data Architect chez OCTO, a partagé les enseignements d’un projet ambitieux : utiliser l’IA générative pour accélérer concrètement la migration de code décisionnel vers des plateformes analytiques modernes.

Comprendre le point de départ

Le diagnostic est bien connu : les systèmes décisionnels reposent encore largement sur des technologies vieillissantes, souvent propriétaires, comme SAS, avec un écosystème de procédures stockées, de SQL custom, et de scripts métier qui se sont accumulés sur parfois plus de vingt ans. Ces systèmes souffrent à la fois d’obsolescence, de dépendance à certains éditeurs, et d’un écart croissant entre les compétences requises pour les maintenir et celles disponibles sur le marché.

La raison d'être de ces programmes de modernisation : Obsolescence technologique Perte de confiance envers l'éditeur Dynamisme sur le marché des plateformes data Renouvellement des compétences Industrialisation de l'open sourceCréation de valeur et modernisation

Dans ce contexte, les entreprises ont tout à gagner à faire évoluer leur patrimoine analytique vers des langages ouverts (Python, SQL) et des plateformes modernes (data warehouses cloud, outils open source). Mais la bascule est loin d’être triviale. Elle implique de transformer des milliers de scripts, souvent critiques pour les métiers, tout en garantissant une parfaite équivalence fonctionnelle, de bonnes performances, de la maintenabilité, et une adoption réelle des nouveaux outils.

La réalité d’un chantier de migration

Migrer un seul programme, ce n’est pas juste le traduire ligne à ligne. Il faut le comprendre, le re-documenter, le réécrire dans une nouvelle stack, le tester à plusieurs niveaux, le faire valider, l’intégrer dans les nouvelles plateformes, et assurer la transition sans rupture pour les utilisateurs.

Multiplié par plusieurs milliers de programmes, le défi devient vite hors de portée si on ne change pas d’approche.

La démarche de migration : Analyser S'approprier Concevoir Coder Documenter

Première étape : réduire le périmètre

Avant même de penser IA, l’enjeu principal est de réduire le volume à migrer. Jean-Baptiste explique comment OCTO s’y est pris : en posant des sondes d’usage sur les systèmes existants pour identifier les programmes réellement utilisés, modifiés, ou en doublon. Ce travail permet déjà de passer d’une vision théorique du patrimoine à une vision active, vivante.

Mais ce n’est pas suffisant. Il faut ensuite embarquer les métiers dans cette réflexion. Les responsabiliser sur les choix. Leur montrer que migrer un programme a un coût, et qu’il est utile de se poser la question de sa pertinence actuelle. Ce double filtre, technique puis fonctionnel, permet une réduction drastique du périmètre. Dans un cas client évoqué, 95 % du code initialement recensé a été écarté, ramenant le volume à migrer à un niveau soutenable.

Deuxième étape : automatiser ce qui peut l’être

Une fois le patrimoine rationalisé, reste à le transformer. C’est ici que l’IA générative entre en jeu. Pas comme une solution magique, mais comme un levier d’accélération — à condition de l’utiliser avec méthode.

Jean-Baptiste commence par une expérience simple : traduire un script SAS de 1000 lignes via un prompt sur ChatGPT. Le résultat est un code Python réduit à 200 lignes, mais rempli de trous, de placeholders, de commentaires ambigus. Inexploitable tel quel.

L’intuition suivante est de découper le code en plusieurs blocs, traduits séparément, avec une attention portée à la continuité. Le résultat est meilleur : un code complet, sans lacunes, mais très linéaire, difficilement maintenable, et pas du tout adapté à la plateforme cible (lecture de CSV, usage massif de Pandas…).

L’approche évolue : il interroge l’IA pour obtenir des suggestions d’amélioration du code, centrées sur la lisibilité, la modularité, la documentation. Il les applique de façon incrémentale, en modifiant uniquement les parties concernées. Le code devient structuré, plus propre, plus réutilisable.

Mais il reste générique. Il ne tient pas compte des contraintes de la cible : un cloud data warehouse, une stack Spark ou Snowflake, des systèmes d’authentification spécifiques. En ajoutant dans les prompts un contexte technique détaillé (plateforme cible, outils disponibles, méthodes recommandées), le code généré devient bien plus idiomatique : usage de Snowpark, requêtes BigQuery natives, intégration Spark… L’IA ne code pas "dans le vide", elle code "pour" votre architecture.

Injecter de la connaissance : le rôle clé du RAG

Dernier verrou : certaines instructions SAS trop spécifiques ne sont jamais bien traduites. Là aussi, il y a une réponse. OCTO utilise une technique appelée RAG (Retrieval-Augmented Generation), qui consiste à enrichir les prompts avec des documents ou extraits externes. En injectant la documentation officielle SAS, ou les conventions de nommage et d’architecture internes de l’entreprise, les traductions gagnent encore en précision. L’approche peut s’étendre à tout type de contenu : guides d’authentification, snippets validés, bonnes pratiques d’ingénierie. On fournit à l’IA un terrain de jeu mieux balisé, et elle produit des résultats plus fiables.

Trois enseignements clés

Ce retour d’expérience met en lumière plusieurs points structurants.

  1. D’abord, l’IA générative est influençable. Si on l’alimente bien, elle devient un assistant efficace. Mais cela suppose de construire un environnement riche, avec du contexte, des exemples, des consignes concises et des opinions.

  2. Ensuite, la transparence est essentielle. Il ne suffit pas que le code "fonctionne". Il faut pouvoir expliquer comment il a été produit, pourquoi telle décision a été prise. Exposer les mécanismes de raisonnement (chain-of-thought) aux utilisateurs permet “d’ouvrir la boîte noire”, de redonner de la confiance.

  3. Enfin, l’expérience utilisateur est centrale. Trop de projets GenAI restent coincés dans un terminal. En travaillant sur les interfaces, en intégrant des designers, des experts produit, on élargit le public, on ouvre la porte aux retours, et on améliore l’utilisabilité. Ce n’est pas une option : c’est un levier.

En conclusion

Moderniser le patrimoine analytique, ce n’est pas une utopie. Mais ce n’est pas une tâche simple non plus. En combinant un travail rigoureux de rationalisation, une approche outillée de la traduction, et une utilisation maîtrisée de l’IA générative, on peut viser des gains très significatifs. Jean-Baptiste évoque 30 % de temps gagné — un chiffre réaliste, à condition d’avoir les bons ingrédients, et les bonnes personnes autour de la table.