Réparez le système que vous avez. Gardez l'activité en marche.
Des mises en production lentes, des pannes mystérieuses, un seul développeur qui sait où tout se trouve. Nous reprenons des applications legacy, les rendons sûres à modifier, et les modernisons une étape vérifiée à la fois.
« On réécrit tout » est la phrase la plus coûteuse du logiciel. Ça paraît propre, ça prend deux fois plus de temps que prévu, et pendant ce temps l'ancien système a quand même besoin d'être réparé. Dans presque tous les cas, une application legacy peut être comprise, stabilisée et modernisée sur place, l'activité continuant tout du long.
Nous commençons par rendre le système observable et testable, puis refactorons le long des coutures qui comptent : les chemins critiques, les parties qui bloquent les nouvelles fonctionnalités, celles qui réveillent les gens la nuit. Les frameworks sont mis à jour, les bases de données migrées sans interruption, et la facture cloud redevient rationnelle. Chaque étape est vérifiée avant la suivante.
Comprendre, stabiliser, puis moderniser.
Audit et cartographie des risques
Deux semaines à lire le code, la base de données et l'infrastructure. Vous obtenez une carte de ce qui est fragile, de ce qui coûte cher et de ce qui va bien, avec un plan priorisé.
La stabilisation d'abord
Logs, supervision, sauvegardes que vous pouvez restaurer, health checks qui ne mentent pas, et les deux ou trois correctifs qui éteignent l'incendie hebdomadaire.
Tests de caractérisation
Des tests qui figent ce que le système fait aujourd'hui, pour que chaque refactoring soit vérifié par rapport à la réalité plutôt qu'à la mémoire de quelqu'un.
Refactoring incrémental
Motifs strangler, extraction de modules, mises à jour de dépendances et nettoyage le long des chemins que vous modifiez réellement, jamais une branche big-bang.
Migrations de frameworks et de bases de données
Sauts de version PHP et Laravel, montées de version Node.js, MySQL vers PostgreSQL, passage du monolithe aux services seulement là où ça se justifie. Le zéro-interruption comme discipline.
Passer à une configuration cloud saine
D'un serveur unique ou d'un compte monté à la main vers des conteneurs, une infrastructure en code et du CI/CD, en gardant l'application inchangée là où elle n'a pas besoin de changer.
Ce que vous obtenez
- Un audit écrit avec les risques classés par impact et un plan de modernisation étape par étape
- Supervision, sauvegardes et tests en place avant tout changement significatif
- Du code refactoré et mis à jour dans votre dépôt, chaque étape relue et déployable
- Documentation et notes d'architecture qui mettent fin à la dépendance à un seul développeur
- Un processus de mise en production prévisible, qui se mesure en minutes, pas en week-ends
C'est fait pour vous si
- Les mises en production sont rares et angoissantes, et chaque changement semble casser quelque chose sans rapport
- Le développeur ou l'agence d'origine est parti, et plus personne ne comprend vraiment le système
- Un prestataire vous a proposé une réécriture complète, et vous aimeriez un second avis avant de dépenser ça
Comment se déroule une mission
Vous obtenez un ingenieur senior qui livre comme une petite equipe — avec un taux horaire transparent, un reporting hebdomadaire et sans frais d'agence. Ajustez les heures a la hausse ou a la baisse selon les besoins du projet.
- 01Audit — accès en lecture seule, deux semaines, une cartographie des risques écrite et un plan que vous pouvez présenter à n'importe qui.
- 02Stabiliser — observabilité, sauvegardes, tests et correctifs urgents ; l'incendie s'arrête avant que la rénovation commence.
- 03Refactorer — des incréments hebdomadaires le long des chemins qui comptent, chacun livré et vérifié en production.
- 04Moderniser — montées de version des frameworks, de la base de données et du cloud une fois le système sûr à modifier, puis transmission ou support continu.
Les questions qu'on nous pose avant chaque mission
Sommes-nous vraiment sûrs de ne pas avoir besoin d'une réécriture ?
Rarement. Une réécriture se justifie quand le modèle de domaine est fondamentalement faux ou que la plateforme est morte. Dans la plupart des cas, nous pouvons moderniser sur place plus vite et avec moins de risque. L'audit répond à cette question honnêtement, y compris quand la réponse est « oui, réécrivez cette partie ».
Quelles technologies prenez-vous en charge ?
PHP et Laravel de tout âge, Node.js, Python, React et d'anciens front-ends JavaScript, MySQL et PostgreSQL, ainsi que des applications qui tournent sur un serveur unique, sur des comptes AWS montés à la main ou sur d'autres clouds. Si c'est autre chose, demandez ; nous vous dirons rapidement si ça correspond.
Est-ce possible pendant que nous continuons à livrer des fonctionnalités ?
Oui, et c'est même souhaitable. Refactorer le long des chemins que vous modifiez déjà est le type de refactoring le moins coûteux. Nous planifions le travail pour que la livraison de fonctionnalités continue, le refactoring rendant chaque fonctionnalité suivante plus facile.
Combien de temps cela prend-il ?
L'audit prend deux semaines. La stabilisation, généralement un à deux mois. La modernisation dépend du système et de l'ampleur du changement souhaité ; nous la planifions par jalons, pour que vous puissiez vous arrêter à n'importe lequel d'entre eux avec un système meilleur qu'avant.
Et si nous avons juste besoin que l'incendie s'arrête ?
Alors nous faisons l'audit et la stabilisation, et nous nous arrêtons là. Beaucoup de clients nous gardent ensuite pour quelques heures par mois ; d'autres transmettent le système à leur propre équipe, avec la documentation que nous laissons derrière nous.
Notre point de vue
Comment nous sauvons et refactorisons : une plateforme migrée hors d'un outil low-code, un an après
En 2025, un client américain nous a confié une plateforme métier qui fait tourner son programme de partenaires : intégra...
septembre 2026
AI Won't Fix Your Broken App
Par Ion Anghel · Avril 2026 Un CTO m'a appelé le trimestre dernier. Son pitch, en gros : « On est en retard sur l'IA. Je...
avril 2026
Les health checks qui mentent : six façons pour votre service de dire « prêt » quand il ne l'est pas
Un health check est un contrat entre votre application et la chose qui lui route le trafic. Le routeur demande « peux-tu...
septembre 2026Un système qui a besoin d'être sauvé ?
Missions flexibles horaires / time-and-materials, 100% remote, B2B. Communication directe avec l'ingenieur qui fait le travail — sans intermediaires, sans discours commercial.