Sortir d'un legacy suit un déroulé assez stable, qu'il s'appelle SAS, tourne sur un mainframe, ou soit un ETL maison codé il y a quinze ans. Sur une mission récente, ce déroulé a porté sur une migration SAS vers Altair, cent soixante-dix programmes écrits en quinze ans. Voici comment chaque étape s'est passée concrètement, et ce qui, une fois généralisé, vaut pour n'importe quel legacy.
Cadrage et audit de l'existant
Le cadrage commence rarement par un schéma d'architecture. Il commence par une question plus simple : qui sait encore pourquoi ce programme tourne ?
Sur la plupart des systèmes en place depuis dix ou quinze ans, une partie du code ne sert plus à grand-chose. Un batch qui recalcule une marge mensuelle depuis 2011, personne ne sait s'il alimente encore un reporting ou s'il tourne par habitude.
L'inventaire technique, le nombre de lignes, de PROC, de macros, est la partie facile. La partie utile de l'audit consiste à croiser ce code avec ses consommateurs réels : quel tableau de bord, quel export, quelle équipe l'attend chaque mois. Le nom de l'outil ne change rien : les mêmes questions se posent face à un job COBOL ou un pipeline abandonné.
Cet inventaire fait apparaître des poids très inégaux. Une part du code est critique et active, elle doit passer sans erreur le jour J. Une autre tourne encore sans que personne ne s'alarme pour un écart de calcul d'un centime. Et il y a ce qu'on découvre mort en creusant : du code qu'on migrerait pour rien, puisque plus personne ne le consulte. Ignorer cette dernière catégorie, c'est payer pour migrer du code que personne ne lira jamais.
Cet audit se construit à plusieurs : un développeur qui connaît le code, un référent métier qui sait à quoi sert le résultat, une personne côté data qui tranche sur ce qu'on arrête et ce qu'on garde. Réunis dès la première semaine, pas ajoutés en cours de route.
Dimensionnement : calibrer le calcul et le calendrier
Altair vend sa promesse en chiffres : son compilateur SLC couvre autour de 92 à 95 % de la syntaxe SAS, et l'outil d'analyse de code sort, ligne par ligne, la liste des instructions non supportées. Sur un périmètre de grande taille, l'éditeur annonce des migrations bouclées en trois à six mois.
Le dimensionnement ne se résume pas à calibrer un serveur ou une capacité de calcul. Il consiste à découper les cent soixante-dix programmes en vagues, et à décider quelle vague part en premier sans dépendre d'une autre qui n'a pas encore basculé. Un programme qui lit la sortie d'un autre programme pas encore migré, c'est un blocage qu'on découvre en semaine six si on ne l'a pas anticipé en semaine un.
C'est aussi le moment de dimensionner le temps humain que prendra la vérification, développeurs et métier compris. Un programme qui produit un fichier plat de dix colonnes se contrôle en une heure. Un moteur de scoring qui alimente huit tableaux de bord en aval demande une semaine de recoupement, pas parce que le code est compliqué, mais parce qu'il faut réunir plusieurs personnes autour du même fichier de résultats.
Pilotage des équipes dev : code review, recette technique et apport de l'IA
Le chiffre annoncé par Altair se lit au niveau de la ligne de code, pas au niveau du programme. Sur ces cent soixante-dix programmes, ça ne veut pas dire qu'une partie passe telle quelle pendant qu'une autre est intégralement à réécrire. Ça veut dire que la quasi-totalité des programmes contient, quelque part, une poignée de lignes non supportées : une macro, une option de procédure, une syntaxe ancienne. Il faut donc repasser sur chaque programme, pas seulement sur une poignée mise de côté.
Ces lignes demandent des développeurs qui connaissent à la fois SAS et Altair, et qui comprennent ce que fait le code avant de le corriger. Savoir qu'une ligne ne compile pas ne dit rien de ce qu'elle calcule, ni si la correction change le résultat final. C'est ce travail d'expertise qui a pris le plus de temps sur cette mission, pas l'écriture de code neuf.
C'est là que l'IA a le plus concrètement aidé : proposer une première traduction pour une macro ou une procédure signalée, que le développeur valide, ou générer un premier jet de scénario de test à partir du rapport de compatibilité, que l'équipe complète plutôt que d'écrire de zéro. McKinsey chiffre ce type d'usage sur la modernisation applicative à 40 à 50 % de délai en moins, un ordre de grandeur proche de ce qu'on a observé sur la réécriture. La relecture finale, celle qui confirme que la correction est juste, reste entre les mains d'un développeur qui connaît le code.
Avant que le métier n'intervienne, les développeurs mènent déjà leur propre validation. Un PROC COMPARE systématique entre l'ancien et le nouveau résultat contrôle la volumétrie, le nombre de lignes, et les agrégats, les sommes et totaux par colonne. Cette étape élimine la plupart des écarts d'exécution avant que quiconque côté métier n'ouvre un fichier.
Validation métier et recette fonctionnelle
Le PROC COMPARE valide la structure du résultat, pas son sens. Il confirme que les volumes et les totaux se retrouvent, pas qu'un chiffre a une signification correcte pour le métier. C'est là que commence la validation métier, qui suit un rythme différent, pas parce qu'elle est plus complexe, mais parce qu'elle dépend d'une disponibilité rare : le temps d'une personne qui connaît le métier assez bien pour juger si un résultat est correct.
Valider un traitement migré, ce n'est pas relire du code. C'est faire tourner l'ancien et le nouveau côte à côte, sortir les deux résultats, et vérifier chiffre par chiffre qu'ils racontent la même histoire.
Un score de risque, une marge, un segment client, une note de performance sportive : peu importe le domaine, le mécanisme de contrôle est identique. Il repose sur quelqu'un qui a, à côté de la migration, son activité courante : les achats, la clôture comptable, le plan marketing du trimestre, le suivi de la performance d'une équipe. Ça vaut pour une migration SAS comme pour n'importe quel legacy : le code se vérifie techniquement, le résultat se valide humainement.
Deux choses ont bien fonctionné sur ce chantier. Associer le métier au recoupement dès le dimensionnement, pas au moment de la recette, pour que sa disponibilité soit un chiffre du planning au même titre que la capacité de calcul du serveur.
Et livrer des comparatifs déjà pré-remplis, ancien résultat, nouveau résultat, écart calculé, plutôt que de demander au métier de reconstruire lui-même la vérification. Le rôle de l'IA s'arrête là où commence le jugement métier : personne ne délègue à un modèle la décision qu'un écart sur une provision est acceptable ou non, et c'est très bien ainsi.
Mise en production et conduite du changement
Quand la validation métier est bouclée, la bascule en production se déroule sans accroc. Le run en parallèle a déjà prouvé que les deux systèmes produisent la même chose. La conduite du changement, elle, n'a pas attendu la mise en production pour commencer : elle s'est jouée pendant les semaines de recoupement, quand les référents métier ont vu de leurs yeux que le nouveau calcul tenait la route.
Cette bascule de posture fait la différence entre une migration subie et une migration accompagnée. Les personnes qui ont validé les chiffres deviennent, sans qu'on ait besoin de les convaincre après coup, celles qui expliquent à leurs équipes pourquoi le changement ne casse rien.
Sur la prochaine sortie de legacy, qu'il s'agisse à nouveau de SAS ou d'un tout autre système, le cadrage, l'audit et le dimensionnement resteront la partie la plus facile à annoncer en comité de pilotage. La partie qui mérite un vrai temps dédié au planning, développeurs et métier confondus, c'est celle où l'on compare, étape par étape, l'ancien résultat et le nouveau, avec un nom et un temps réservé dès le premier comité.
Et maintenant ?
SAS n'est qu'un exemple, et Altair n'en est qu'une porte de sortie parmi d'autres. Python industrialisé, R, des moteurs de calcul cloud : le marché a plusieurs portes de sortie pour un legacy, et souvent de bonnes raisons de préférer l'une à l'autre selon le contexte.
Le sujet, c'est de garder la main sur ce qui tourne. Comme sur le choix d'un outil IA, c'est une décision d'architecture, pas de fournisseur. Un code qu'on a audité, documenté, dont on connaît les dépendances, peut changer de moteur le jour où on le décide. Un code legacy qu'on n'a jamais vraiment regardé, chaque migration en refait l'archéologie depuis zéro. La question n'est pas seulement « vers quel outil je migre aujourd'hui ? ». C'est aussi : la prochaine fois, saurai-je déjà ce que contient mon patrimoine de calcul, ou repartirai-je de zéro ?
C'est ce qu'on industrialise chez Bomzai : des audits et des migrations qui laissent derrière eux une cartographie du code et des traitements, pas seulement un système qui tourne. Sur SAS et Altair aujourd'hui, sur ce que vous choisirez demain. Pour en parler : contact@bomzai.fr.
Sources : Altair (compatibilité et migration Altair SLC) · McKinsey, via retours d'expérience de modernisation applicative assistée par IA · retour de mission Bomzai.
