Remplacer l’ancien code pièce par pièce, sans arrêter l’application.
Quand une montée de version ne suffit pas, nous remplaçons les parties anciennes en sprints de deux semaines, chacun avec un périmètre et un prix fixés. Pas de réécriture en big bang, pas de feuille de route gelée.
Quand une montée de version ne suffit pas
Le framework n’a pas de version suivante
Zend Framework 1, symfony 1, CodeIgniter 3 ou un framework maison écrit il y a des années : il n’y a rien vers quoi monter.
Une partie bloque tout le reste
Un module écrit à une autre époque empêche la montée de version de PHP pour toute l’application.
Une réécriture complète gèle le produit
Des mois à reconstruire ce qui fonctionne déjà, pendant que les clients attendent la moindre nouveauté.
La méthode du figuier étrangleur, en clair
Le figuier étrangleur (strangler fig) pousse autour d’un vieil arbre jusqu’à tenir debout tout seul. Nous faisons la même chose avec un logiciel.
Nous plaçons une fine couche de routage devant l’ancienne application. Le nouveau code reprend une route ou un module à la fois : d’abord les rapports, par exemple, puis l’API, puis le tunnel de commande. Chaque étape passe en production séparément et peut être annulée.
Quand l’ancien code n’a plus rien à faire, nous le débranchons. Vos utilisateurs continuent de travailler pendant tout ce temps.
Déroulement
01
Roadmap
Un inventaire des modules, l’ordre des étapes, un plan de tests, les risques, et un prix ferme pour chaque étape.
02
Sprint
Un périmètre fixé, issu de la Roadmap. D’abord des tests de caractérisation sur l’ancienne partie, puis le nouveau code à côté.
03
Revue et mise en production
Une démo, les merge requests et une mise en production. Vous décidez si le sprint suivant a lieu.
04
Débrancher l’ancienne partie
Le trafic bascule vers le nouveau code. L’ancien module est supprimé dès que plus rien ne l’appelle.
Ce que vous recevez
Document de Roadmap
Étapes, ordre, risques et prix ferme pour chaque étape.
Du code qui tourne à chaque sprint
En production après chaque sprint, utilisé par vos clients.
Tests
Tests de caractérisation sur l’ancienne partie, tests classiques sur la nouvelle.
Rapport de sprint
Ce qui a basculé, ce qui vient ensuite, ce que nous avons appris sur l’ancien code.
Notes d’architecture
Comment l’ancienne et la nouvelle partie communiquent, tenu à jour.
Délais et prix
| Prix | Durée | |
|---|---|---|
| Roadmap | à partir de 1 900 € | fixée dans le devis |
| Sprint | 4 000 € | 2 semaines |
Questions sur la modernisation
Combien de sprints nous faudra-t-il ?
C’est la Roadmap qui répond, avec un prix pour chaque étape. Vous ne vous engagez pas sur toutes à la fois.
Notre équipe peut-elle continuer à développer des fonctionnalités pendant ce temps ?
Oui, c’est tout l’intérêt de la méthode. À chaque sprint, nous convenons des zones qui nous reviennent, pour ne pas travailler sur le même code.
Vers quel framework migrez-vous ?
En général Symfony, sur la version LTS actuelle. Laravel si votre équipe l’utilise déjà. La Roadmap explique le choix dans votre cas.
Pouvons-nous nous arrêter après quelques sprints ?
Oui. Chaque étape est terminée et en production en tant que telle. En vous arrêtant, vous gardez une application qui fonctionne, en partie modernisée, et non une nouvelle application à moitié construite.
Commencez par un plan chiffré
Dites-nous ce que fait le système et sur quoi il tourne. Nous vous dirons s’il faut commencer par un Code Audit ou par une Roadmap.