Extraire les règles métier de mon vieux système avec l'IA ?

Vous extrayez les règles métier de votre ancien système en 3 étapes : l'IA lit le code et rédige chaque règle en une phrase claire reliée à la ligne d'où elle provient, le responsable du processus la confirme ou la corrige, et vous la comparez au comportement réel du système sur de vraies factures. Un outil comme AWS Transform pour mainframe rédige les règles sous forme d'exigences vérifiables, et dans l'annonce de Thought Machine avec Amazon du 29 septembre 2026, l'extraction compte 4 étapes, la dernière étant une validation humaine. Aucun nouveau code avant confirmation des règles.

Dans la troisième partie, vous avez obtenu un inventaire et une décision provisoire pour chaque système. Les systèmes que vous avez choisi de reconstruire ou de convertir sont ceux qui ont d'abord besoin de cette étape.

Pourquoi les règles métier sont le bien le plus précieux de votre ancien système

Une règle métier est la manière dont votre entreprise calcule ou décide quelque chose : comment se calcule la remise d'un client grossiste, quand s'ajoute une pénalité de retard, qui valide un bon de commande au-delà d'un certain seuil, comment s'arrondit le montant d'une échéance. Ces règles se sont accumulées au fil d'années de modifications, et beaucoup n'ont jamais été écrites dans aucun document.

• Dans le code : des conditions et des calculs écrits il y a des années par un développeur, à la demande d'un responsable qui a depuis quitté l'entreprise.
• Dans la base de données : des grilles de prix, des taux et des seuils que quelqu'un modifie à la main sans savoir ce qui en dépend.
• Dans la tête des équipes : les exceptions que le comptable traite à la main parce que le système ne le fait pas.
• Dans les tableurs : des formules qui comblent les manques du système, comme expliqué dans quelle feuille est votre vrai système.

Si vous reconstruisez le système sans ces règles, vous obtenez un nouveau système qui calcule autrement, et vous ne le découvrez que lorsqu'un client conteste une facture. Ce sont les règles qui doivent migrer ; l'ancien langage de programmation n'est que le contenant.

Comment l'IA lit le code et rédige les règles

Extraire les règles était un long travail manuel : un développeur lisait le code ligne par ligne et notait ce qu'il comprenait. Les outils actuels lisent l'ensemble du code, suivent d'où vient chaque chiffre et où il va, puis rédigent ce qu'ils trouvent en langage clair. Un exemple : Amazon indique sur la page d'AWS Transform pour mainframe que le service extrait chaque règle métier du code source et la relie à son origine, puis génère des exigences prêtes pour le développement que votre équipe peut relire, chacune rattachée au code dont elle provient. C'est la description qu'Amazon fait de son service, pas un résultat garanti.

Le format de rédaction d'une règle compte. Un format reconnu est EARS, l'Easy Approach to Requirements Syntax, mis au point par Alistair Mavin et ses collègues chez Rolls-Royce et publié pour la première fois en 2009. Le principe : chaque règle s'écrit dans un ordre fixe, l'état, puis le déclencheur, puis ce que le système doit faire. Il compte 5 modèles de base ; voici des exemples métier à titre d'illustration :

L'intérêt de ce format est que le responsable du processus peut le lire et le juger sans savoir programmer. Une phrase par règle, et il répond oui, non ou incomplet.

Un exemple bancaire : l'intention métier, pas la traduction ligne à ligne

L'exemple récent le plus parlant vient de la banque, où les règles d'intérêts, de frais et de remboursement vivent depuis des décennies dans du code COBOL sur des mainframes. COBOL est un ancien langage de programmation qui fait encore tourner de nombreux systèmes dans la banque et l'assurance. Dans son annonce du 29 septembre 2026, Thought Machine, une entreprise de technologie bancaire, indique travailler avec Amazon sur une chaîne qui ne traduit pas le code ligne à ligne mais en extrait l'intention métier pure. Selon l'annonce, la chaîne compte 4 étapes :

1. Extraction : AWS Transform lit les anciennes applications et extrait la logique métier en spécifications rédigées au format EARS.
2. Consolidation : des centaines de variantes redondantes d'un même produit sont fusionnées en spécifications modernes et allégées.
3. Synthèse : des agents d'IA génèrent les produits financiers et leurs tests en Python.
4. Validation : une revue humaine où les équipes ingénierie et risques de la banque détiennent un pouvoir de validation explicite.

Retenez deux leçons : la consolidation montre qu'un ancien système porte de nombreuses copies d'une même règle, et la dernière étape est entièrement humaine. Ce sont les affirmations des deux entreprises sur leur chaîne, et leur exemple est bancaire, mais la méthode vaut pour toute entreprise : extraire, fusionner les doublons, puis construire, et ne rien valider avant la signature du décideur.

Pourquoi le responsable du processus doit confirmer chaque règle

L'IA lit ce que fait le code, pas ce que veut l'entreprise. C'est dans l'écart entre les deux que naissent les erreurs de modernisation :

• Du code mort : elle peut extraire une règle d'une partie inutilisée depuis des années, qui ressemble alors à une règle active.
• Un ancien bug devenu habitude : le système arrondit un montant de travers et les équipes corrigent à la main. La règle extraite reproduira le bug si personne ne dit que c'en est un.
• Une règle hors du code : l'exception que le comptable traite à la main n'apparaîtra jamais dans l'extraction.
• Des règles contradictoires : deux versions du calcul de remise à deux endroits différents. Laquelle est la bonne relève d'une décision métier, pas technique.

Donnez donc à chaque règle un responsable métier qui la signe : le directeur commercial pour les remises, le directeur financier pour les pénalités et les validations. Les règles confirmées deviennent la base du cahier des charges du nouveau système, et nous avons expliqué comment le rédiger dans notre guide du cahier des charges logiciel. Gardez à l'esprit que le code et les bases de données peuvent contenir des données de clients ou de salariés : tout outil qui les lit hors du Royaume exige l'analyse vue dans la troisième partie, avec les orientations de l'Autorité saoudienne des données et de l'IA.

Le regard d'Origami

Quand nous modernisons un ancien système, nous traitons ses règles métier comme le plus important à transférer, pas son code. Nous utilisons des outils d'IA pour lire le code et rédiger les règles en phrases claires à une vitesse impossible auparavant, mais aucune règle n'est définitive tant que le responsable du processus ne l'a pas lue et signée.

Nous testons ensuite chaque règle confirmée sur de vraies données de l'ancien système avant de construire le nouveau autour d'elle, pour que le nouveau système calcule comme l'entreprise l'attend, et non comme un outil le devine. Pour voir comment nous travaillons, consultez nos services.

L'exercice de la semaine : une règle, trois factures

Inutile d'attendre un outil pour commencer. Choisissez une règle souvent débattue, comme une remise ou une pénalité de retard, et suivez ces étapes :

1. Demandez au responsable du processus d'écrire la règle en une phrase, sous la forme : Lorsque..., le système doit...
2. Sortez du système 3 vraies factures où la règle s'est appliquée : une ordinaire, une au seuil, une avec une exception.
3. Calculez chaque facture à la main avec la phrase écrite, et comparez le résultat avec ce qu'a produit le système.

Si les trois concordent, la règle est documentée. Si l'une diffère, vous avez trouvé une règle cachée ou un ancien bug, et c'est exactement ce qu'il faut savoir avant toute modernisation.

À suivre

Vous disposez maintenant de règles confirmées pour votre système. Vient ensuite la grande décision : déplacer le système tel quel, convertir son code vers une plateforme moderne, le reconstruire autour des règles extraites, ou le remplacer par un produit du marché en ne gardant que les données ? Dans la cinquième partie, nous comparons ces voies dans un tableau : quand chacune convient, ce qu'elle préserve, ce qu'elle risque et qui doit y être associé.

Sources

• AWS Transform pour mainframe : page officielle — extraction des règles métier rattachées au code d'origine, exigences vérifiables et tests d'équivalence.
• Thought Machine et AWS : annonce du 29 septembre 2026 — les quatre étapes : extraction EARS, consolidation, synthèse et validation humaine.
• EARS : le guide officiel d'Alistair Mavin — le format, ses cinq modèles et sa première publication en 2009.
• SDAIA : protection des données personnelles.