Refonte de SI
Changer de système sans arrêter l’entreprise
Une refonte échoue rarement sur la technique. Elle échoue sur la bascule : le moment où il faut passer de l’ancien au nouveau pendant que l’activité continue. C’est cette partie que nous préparons.
- Migration par étapes, jamais en une seule bascule
- Réversibilité prévue avant chaque étape
- Au forfait avec cahier des charges, ou 1 000 € par jour
- Sans engagement de durée
Le principe
Le risque n’est pas de construire, c’est de basculer
Le grand soir n’existe pas
La refonte qui consiste à développer deux ans dans son coin puis à tout remplacer un week-end est le scénario qui échoue le plus souvent. Elle cumule les défauts : on découvre les vrais besoins trop tard, l’ancien système continue d’évoluer pendant ce temps, et le jour de la bascule, il n’y a pas de retour en arrière.
Nous procédons autrement : par étapes livrées et mises en service au fil de l’eau, chacune apportant un bénéfice réel, chacune réversible. C’est plus long à décrire et plus court à vivre.
Faire cohabiter l’ancien et le nouveau
Une refonte par étapes suppose que les deux systèmes fonctionnent ensemble pendant un temps : c’est la partie technique la plus exigeante, et celle qu’on sous-estime le plus.
Concrètement, il faut décider où vit la donnée de référence pendant la transition, comment les deux systèmes se la partagent, et ce qui se passe si l’un des deux tombe. Selon les cas, une façade devant l’ancien système, une synchronisation de données, ou un découpage fonctionnel où chaque domaine bascule séparément.
La réversibilité, avant chaque étape
Avant de mettre une étape en service, une seule question compte : si cela se passe mal lundi matin, comment revient-on à l’état d’avant, et en combien de temps ? Une étape dont on ne sait pas revenir n’est pas prête, quelle que soit la qualité du travail.
Cela impose des choses concrètes : garder l’ancien chemin actif quelque temps, ne pas supprimer les données au moment de la bascule, savoir remettre le trafic sur l’ancien système sans redéploiement.
Décommissionner, vraiment
Une refonte n’est pas finie quand le nouveau système marche : elle est finie quand l’ancien est éteint. Tant qu’il reste allumé « au cas où », vous payez deux systèmes, vous les sécurisez tous les deux, et personne ne sait plus lequel fait foi.
Le décommissionnement fait donc partie du plan dès le départ : ce qui doit être archivé, ce qui doit être conservé pour des raisons légales, ce qui peut être supprimé, et à quelle date la machine s’arrête.
Le déroulement
Comment se conduit une refonte
-
Ce qui existe vraiment
Fonctions réellement utilisées, données de référence, intégrations avec l’extérieur. Une bonne partie de l’ancien système ne sert plus — le découvrir tôt réduit le périmètre d’autant.
-
Un découpage en étapes
Chaque étape apporte un bénéfice utilisable et se met en service seule. Une étape qui n’apporte rien tant que la suivante n’est pas là n’est pas une étape.
-
La cohabitation
Façade devant l’ancien système, synchronisation des données, découpage par domaine. Les deux systèmes vivent ensemble le temps de la transition.
-
La reprise des données
Le poste le plus sous-estimé. Reprise à blanc, contrôles de cohérence, rejeu — on migre les données plusieurs fois avant celle qui compte.
-
La réversibilité
Avant chaque mise en service : comment revient-on en arrière, en combien de temps, et qui décide. Une étape sans retour arrière n’est pas prête.
-
Le décommissionnement
Ce qui s’archive, ce qui se conserve pour des raisons légales, ce qui se supprime, et la date à laquelle l’ancienne machine s’arrête pour de bon.
Questions fréquentes
Refonte de SI : vos questions
Une autre question ? Le support répond directement, sans intermédiaire, de 9h à 12h et de 14h à 17h.
Comment est-ce facturé ?
Au forfait quand l’objectif est clair — « migrer notre monolithe vers des microservices en trois mois » — avec un cahier des charges détaillé établi ensemble pour éviter les dérives, et un prix fixe. Au taux journalier quand le besoin se précise en avançant : à partir de 1 000 € par jour, dégressif selon la durée, sans engagement.
Faut-il tout refaire ?
Presque jamais. Une refonte utile commence par distinguer ce qui pose réellement problème de ce qui fonctionne et qu’on remplacerait par habitude. Il arrive qu’une partie du système soit conservée telle quelle, et que le projet se réduise à deux ou trois domaines — pour un coût sans rapport avec le projet initial.
Quelle différence avec une mission d’architecture ?
L’ordre. L’architecture établit l’état des lieux, la cible et la trajectoire : elle répond à « où aller et dans quel ordre ». La refonte est l’exécution de cette trajectoire — migration, cohabitation, reprise des données, décommissionnement. Beaucoup de projets commencent par la première et enchaînent sur la seconde.
Peut-on continuer à faire évoluer l’ancien système pendant ce temps ?
Oui, et il le faut : geler l’existant pendant deux ans n’est pas tenable pour une entreprise qui vit. C’est justement l’argument pour une refonte par étapes — chaque domaine basculé cesse d’évoluer des deux côtés, ce qui réduit progressivement le sujet au lieu de le laisser grossir.
Vos équipes remplacent-elles les nôtres ?
Non, elles travaillent avec. Un système refait par un prestataire seul devient un système que vous ne maîtrisez pas — vous auriez changé de dépendance, pas résolu le problème. Nous apportons des profils seniors et un regard extérieur ; la main reste chez vous.
Un système qu’il faudrait refaire, sans savoir par où commencer ?
Décrivez-nous ce qui coince aujourd’hui. Le premier travail est de réduire le périmètre — c’est souvent là que se gagne le projet.