Aller au contenu

des dizaines de migrations

Java, Python, COBOL et VB6 réécrits en Go, Rust et TypeScript en 30 jours

Pas seulement le mainframe. Un monolithe Java étalé sur huit serveurs, du Python bloqué par le GIL, un service Node qui avale la mémoire plus vite qu'il ne sert de requêtes — tout cela devient du Go et du Rust, et la facture d'infrastructure baisse avec. Et aussi COBOL sur z/OS, RPG sur l'AS/400, VB6 et Delphi sur le poste de travail, ColdFusion et PHP sur le web, Perl, PL/SQL, Fortran et ABAP. Notre plateforme lit toute la base de code et la réécrit, nos ingénieurs prennent les endroits où se tromper coûte cher, et l'ancien système continue de tourner pendant tout ce temps.

Quatre écrans, une dizaine de minutes. Un ingénieur les lit et revient avec un périmètre, une date et un prix — sans démo ni séquence commerciale.

30
jours, le plafond de tout projet
20
stacks legacy que nous migrons
10+
ans passés dans les systèmes des autres
1M+
lignes dans une seule réécriture

Tous les systèmes que nous débranchons du respirateur

Des dizaines de migrations, sur tous les stacks ci-dessous — du monolithe Java qui brûle huit serveurs au COBOL que personne n'a compilé depuis 2011. Chacune passe en production en trente jours. Trouvez le vôtre et voyez ce que le déplacement implique.

Un vrai graphe de dépendances

C'est un service Go en production, avec les noms de packages remplacés par M01 à M45 et la structure laissée telle quelle. Faites glisser le curseur pour passer de l'état actuel du code à son découpage le long des frontières de domaine. La classe de chaque nœud sort du graphe lui-même : un module qui tient dans un seul domaine se réécrit mécaniquement, et un module que quatre domaines retiennent demande un ingénieur pour couper la frontière à la main.

État actuel

Réécriture mécanique60%

Frontière coupée par un ingénieur29%

Candidat à la suppression11%

45 modules, 167 dépendances et 45,990 lignes réparties sur 7 domaines. Graphe réel d'un service en production, noms de packages retirés, aucune autre retouche. Les trois classes sont comptées à partir de la structure du graphe elle-même.
Le même graphe en tableau
Trié par taille. Un module est mécanique quand il tient dans un seul domaine, il part chez un ingénieur quand trois domaines ou plus en dépendent ou qu'il est pris dans un cycle, et il devient candidat à la suppression quand rien ne l'importe et qu'il n'est pas un point d'entrée.
ModuleLignesImporté parImporteDomaineClasse
M01326loc010S01Réécriture mécanique
M02142loc03S02Réécriture mécanique
M0355loc03S02Réécriture mécanique
M0489loc03S02Réécriture mécanique
M055,194loc315S03Frontière coupée par un ingénieur
M06239loc51S03Frontière coupée par un ingénieur
M07884loc200S03Frontière coupée par un ingénieur
M08485loc46S03Réécriture mécanique
M099,835loc47S03Frontière coupée par un ingénieur
M10514loc20S03Réécriture mécanique
M11677loc15S03Réécriture mécanique
M12236loc411S03Frontière coupée par un ingénieur
M13187loc33S04Frontière coupée par un ingénieur
M14454loc11S05Réécriture mécanique
M1558loc31S05Réécriture mécanique
M16356loc42S05Réécriture mécanique
M17247loc42S05Réécriture mécanique
M1859loc31S04Frontière coupée par un ingénieur
M19139loc00S04Candidat à la suppression
M20330loc132S04Frontière coupée par un ingénieur
M21414loc11S06Réécriture mécanique
M221,670loc33S06Réécriture mécanique
M231,218loc180S06Frontière coupée par un ingénieur
M242,574loc153S06Frontière coupée par un ingénieur
M25163loc41S04Frontière coupée par un ingénieur
M26251loc25S04Réécriture mécanique
M27161loc12S04Réécriture mécanique
M2899loc20S04Réécriture mécanique
M2945loc00S04Candidat à la suppression
M3025loc00S04Candidat à la suppression
M311,417loc240S04Frontière coupée par un ingénieur
M3282loc10S04Réécriture mécanique
M3330loc41S04Frontière coupée par un ingénieur
M34141loc31S03Réécriture mécanique
M3579loc11S03Réécriture mécanique
M363,036loc310S03Réécriture mécanique
M37173loc11S03Réécriture mécanique
M382,501loc19S03Réécriture mécanique
M391,452loc34S03Réécriture mécanique
M4050loc11S03Réécriture mécanique
M412,148loc09S01Candidat à la suppression
M42167loc01S01Candidat à la suppression
M434,873loc215S07Réécriture mécanique
M442,241loc110S07Réécriture mécanique
M45474loc213S07Réécriture mécanique

sous le capot

Un million de lignes, c'est la taille normale

Notre plateforme lit toute la base de code d'un coup — chaque langage de l'arbre, en parallèle — et la reconstruit en système moderne plutôt qu'en translittération de l'ancien. Le comportement reste celui de l'original et se vérifie sur votre trafic enregistré. L'architecture, non : vous obtenez des services, un vrai schéma et un déploiement à la hauteur de la façon dont on écrit du logiciel aujourd'hui.
  • Tous les langages de l'arbre, en même temps

    Un système n'est jamais écrit dans un seul langage. Le COBOL appelle du JCL, le JCL lance un utilitaire C, un script Perl corrige le fichier avant que PL/SQL ne le charge. La plateforme lit tout en parallèle et tient un seul graphe sur l'ensemble : rien ne tombe entre les langages.

  • Moins de machines pour la même charge

    Un service Java ou Python réécrit en Go demande le plus souvent une fraction de la mémoire et une fraction des instances, et un noyau Rust transforme une fenêtre de batch en pause café. C'est toute la raison de déplacer du code qui n'est pas cassé : le même comportement sur une facture plus petite, et de la marge que vous n'avez plus à acheter.

  • Un million de lignes et au-delà

    C'est la taille sur laquelle nous calons le plan, pas un plafond. Au-dessus, nous découpons l'estimation et chiffrons la première partie seule. L'échelle est ici une question de planning, pas de faisabilité.

  • Même comportement, architecture neuve

    Un banc de comparaison rejoue votre trafic de production enregistré sur l'ancien et le nouveau et compare au centime. Ce qui change, c'est la forme : des services avec des responsables, un schéma lisible, des tests nés avec le code, et un déploiement sans fenêtre de maintenance.

  • Air gap, sur votre matériel ou le nôtre

    Pour les environnements régulés, les modèles viennent de nous et tournent dans votre périmètre, sans aucune connexion sortante. Si vous n'avez pas les machines pour les porter, nous vous louons les nôtres et elles restent chez vous. Rien de votre code n'a besoin de sortir du bâtiment.

Votre cloud, votre centre de données, un VPN client, ou une salle sans réseau du tout — chacune de ces options a un montage qui tourne, et le détail passe dans le contrat.

Comment le travail se déroule

Quatre étapes, les mêmes sur un million de lignes de COBOL que sur un monolithe PHP. Les deux premières sont l'audit, et la carte vous reste dans tous les cas.
  1. 01

    Accès en lecture

    Une copie en lecture seule du dépôt, les scripts de build, et les runbooks qui ont survécu. Nous signons votre NDA d'abord si c'est ainsi que votre société fonctionne.

  2. 02

    La carte

    La plateforme analyse l'ensemble et rapporte ce qui s'y trouve vraiment : les modules et leurs dépendances, le code que plus rien n'appelle, les tâches planifiées que personne n'a documentées, et l'endroit où le build ne marche que sur une machine. Cela arrive avant toute réécriture.

  3. 03

    Réécriture par tranches

    Un module borné à la fois, avec des tests écrits d'après le comportement de l'original. L'ancien et le nouveau tournent sur les mêmes entrées jusqu'à ce que les sorties coïncident, puis le trafic bascule. Rien ne change de main à une date unique.

  4. 04

    Passation

    Vos ingénieurs reçoivent le dépôt, les tests écrits en chemin, et la carte tenue à jour. Nous répondons aux questions ensuite, et nous ne gardons aucune clé que vous ne puissiez révoquer.

Demandez la carte d'abord

La carte est la chose la moins chère que nous vendons et la seule base solide pour chiffrer le reste. Dites-nous ce que vous faites tourner et nous revenons avec ce qu'il y a dedans, ce que demande une réécriture et ce qu'elle coûte.

Le formulaire arrive chez nous, pas dans une séquence commerciale. Vous n'avez pas à subir une démo pour obtenir une réponse.