Réécrire votre legacy
avec l'IA,
preuve à l'appui
Des agents réécrivent vos applications legacy module par module. Chaque module est jugé contre les sorties réelles de l'ancienne application, et ne bascule en production qu'à divergence nulle.
La règle
L'ancienne application fait foi. Le modèle propose les entrées de test ; seule l'application d'origine produit les sorties attendues, bugs compris. Chaque écart part chez le métier, qui tranche.
Legacy 10x pour les directions SI
Le problème
Vos règles métier dorment dans du code Java EE, .NET Framework, AngularJS, PHP ou WinDev. Ceux qui l'ont écrit sont partis, la documentation date de la mise en production, et les fins de support tombent.
Ce qui coince
Un convertisseur ligne à ligne recopie la dette dans un nouveau langage. Un modèle qui écrit lui-même les valeurs attendues de ses tests valide ses propres erreurs. Dans les deux cas, rien ne prouve que la nouvelle application fait ce que faisait l'ancienne.
La réponse SFEIR
Les agents extraient les règles, le métier les valide, la réécriture part de la spécification. L'ancienne application fournit les sorties de référence, et chaque module bascule derrière un feature flag, l'ancien restant prêt pour un retour arrière.
Les fins de support sont datées.
10 nov. 2026
Fin du support de .NET 8, selon la politique de support de Microsoft.
31 déc. 2026
Fin des correctifs de sécurité de PHP 8.2, selon php.net.
12 janv. 2027
Fin du support de .NET Framework 4.6.2, selon le cycle de vie publié par Microsoft.
Depuis 2022
AngularJS n'a plus de support : Google l'a arrêté le 31 décembre 2021.
Banque, assurance
L'article 8, paragraphe 7, du règlement DORA impose aux entités financières, hors microentreprises, une évaluation du risque lié aux TIC sur tous leurs systèmes hérités, au moins une fois par an. L'audit du patrimoine en fournit la matière.
Une décision à chaque étape
Vous pouvez vous arrêter à la sortie de chaque étape, en gardant ce qu'elle a produit. Le référentiel de règles validées garde sa valeur même si la réécriture ne démarre pas.
Diagnostic 10x
30 minutes, sans engagement
Les applications en jeu, leurs échéances (fins de support, DORA) et un premier avis.
À la sortie : Lancer ou non l’audit.
Audit du patrimoine
2 à 4 semaines, au forfait
Inventaire et carte des modules par agents, part de code mort, verdict par application (migrer, moderniser sur place, geler ou retirer), chiffrage en livrables.
À la sortie : Choisir le module du Projet Preuve.
Projet Preuve
8 semaines, moins de 40 k€
Un module réécrit, prouvé par golden master inversé et basculé en production.
À la sortie : Fixer le prix par module du programme.
Programme
Module par module, engagement de résultats
Modules basculés à divergence nulle, données migrées, extinction de l’ancienne application.
À la sortie : Run repris par AI for IT ou par vos équipes.
Les agents exécutent, les humains tiennent les gates
Chaque module suit les six étapes de la Software Factory 10x, avec trois gates tenues par des humains : le métier valide les règles (Define), l'architecte valide le plan (Plan), l'équipe autorise la bascule sur preuve d'exécution (Ship). Les leçons de chaque module sont réinjectées dans le suivant.
Comprendre
Étapes 1 et 2 : audit, extraction des règles
Les agents
Inventaire, graphe du code, code mort, règles métier extraites en scénarios Gherkin.
Les humains
Le métier répond aux questions et valide les règles (gate Define).
Livrables
inventaire.md, un fichier .feature par module, questions ouvertes.
Spécifier
Étape 3 : spécifications
Les agents
spec.md et plan.md par module : architecture cible, lots, cohabitation avec l’ancien.
Les humains
L’architecte et le tech lead valident et choisissent la stack (gate Plan).
Livrables
spec.md, plan.md, matrice règle, test, code.
Réécrire
Étape 4 : réécriture par agents
Les agents
Claude Code écrit le code depuis la spécification, le plan et le jeu de référence ; quatre revues parallèles (code, sécurité, tests, performance).
Les humains
Le binôme pilote et relit, refuse toute nouvelle fonctionnalité, remonte les écarts au métier.
Livrables
Code du module, code mort supprimé, écarts à arbitrer.
Prouver et basculer
Étapes 5 et 6 : golden master inversé, bascule
Les agents
Le modèle propose les entrées de test ; migrations de données à blanc avec rapport de conformité.
Les humains
Le QA construit le golden master, l’Ops prépare la bascule, autorisée à divergence nulle (gate Ship).
Livrables
golden_master.json, rapport de comparaison, score de mutation, procédure de retour arrière.
L'équivalence, inscrite au contrat
Les critères d'équivalence figurent au contrat dès le Projet Preuve, et le programme se vend en engagement de résultats. Nous comptons en livrables (règles validées, modules spécifiés, modules basculés), jamais en jours-homme.
Ce que l'offre écarte
- les convertisseurs ligne à ligne ;
- les runtimes propriétaires qui vous enferment ;
- les multiplicateurs de productivité sans mesure publiée ;
- les tests dont le modèle écrit lui-même les valeurs attendues.
Équivalence mesurée
Un module ne bascule qu'à divergence nulle au shadow run, sur une période représentative. Le score de mutation de la suite de tests accompagne chaque module.
Connaissance restituée
Règles validées, spécifications, golden master et graphe du code vous appartiennent.
Code sans dépendance
Stack standard, code lisible, aucun runtime propriétaire : vos équipes maintiennent l'application sans SFEIR.
Données et modèles maîtrisés
Agents confinés, données de production anonymisées, modèles au choix (Claude, Gemini), exécutés là où votre politique de sécurité l'autorise.
Les applications d'entreprise
- Java EE
- .NET Framework
- AngularJS
- PHP
- WinDev
- Access
- Oracle Forms
- Delphi
- COBOL
SFEIR développe des applications d'entreprise depuis près de vingt ans, en Java d'abord, et travaille avec Google depuis 2008 (notre histoire). Nos ingénieurs connaissent les stacks d'origine.
Une stack standard, sur votre cloud
- Java et Spring
- .NET
- TypeScript
- Python
- PostgreSQL
- API et serveurs MCP
La stack cible se décide à la gate Plan, avec votre architecte. Chaque module réécrit expose ses API, et des serveurs MCP quand vos agents doivent s'en servir.
Six produits, un programme
AI for IT →
Le champ de l’offre : l’IA appliquée au SI lui-même. Reprend le run après chaque bascule.
Diagnostic 10x →
La porte d’entrée, en 30 minutes.
Software Factory →
Exécute le cycle sur le SDLC à onze phases, avec un binôme de Product Engineers et une brigade d’agents.
Conseil IA stratégique →
Arbitre le portefeuille et le business case quand l’audit couvre des dizaines d’applications.
AI Cyber →
Revoit la sécurité du code réécrit et confine les agents qui lisent votre code.
Entreprise Conversationnelle →
Fixe la cible : chaque module réécrit expose ses API, et des serveurs MCP à la demande.
Les mêmes indicateurs pour chaque module
Règles extraites et validées, taux de divergence au shadow run, score de mutation, Rework Rate, itérations de correction, délai et coût. Vous les recevez avec chaque module. Cette page ne publiera que des chiffres mesurés sur nos modules, avec leur méthode de mesure.
Questions fréquentes
L’IA peut-elle convertir toute une application d’un coup ?
Non. Les agents lisent le code, extraient les règles et réécrivent un module à la fois, depuis une spécification que le métier a validée. Une application entière donnée d’un bloc à un modèle produit du code qu’aucune preuve ne relie à l’ancien. Le golden master inversé juge chaque module avant qu’il ne bascule.
Faut-il toujours réécrire ?
Non. L’audit du patrimoine rend un verdict par application : migrer, moderniser sur place (montée de version outillée, sans réécriture), geler ou retirer.
Mon code et mes données sortent-ils de chez moi ?
Ils restent dans l’environnement que votre politique de sécurité autorise. Les agents sont confinés, les données de production servant au golden master sont anonymisées, et vous choisissez les modèles (Claude, Gemini) et l’endroit où ils s’exécutent.
Combien de temps faut-il ?
Le Diagnostic 10x dure 30 minutes, l’audit du patrimoine 2 à 4 semaines, le Projet Preuve 8 semaines pour un module basculé en production. Le programme se chiffre ensuite par module, à partir du coût mesuré pendant le Projet Preuve.
Que veut dire « 10x » ?
C’est le nom de la doctrine de production de SFEIR (Software Factory 10x), pas un gain promis. Nous ne publierons sur cette page que des chiffres mesurés sur nos modules, avec leur méthode de mesure.
À qui appartiennent les livrables ?
À vous : règles validées, spécifications, golden master, graphe du code et code réécrit. La stack est standard, sans runtime propriétaire : vos équipes maintiennent l’application sans SFEIR.
Quelle application réécrire en premier ?
Donnez-nous le nom de l'application qui vous inquiète le plus. En 30 minutes, nous vous dirons ses échéances, le verdict probable et le module qui ferait un bon Projet Preuve.
Réserver un Diagnostic 10x