Modernisation d'un système vieux de 12 ans : transition progressive ou tout réécrire de zéro ?

Il y a trois ans, on a décidé de tout réécrire de zéro pour notre système logistique qui avait un volume comparable. On nous avait annoncé 6 mois : ça a duré 16 mois et le budget a presque triplé. La première semaine de mise en prod le calcul des remises buggait et on a envoyé des factures erronées à des centaines de clients. Repartir de zéro sur un système qui tourne déjà, c'est un poker énorme.

Voici la marche à suivre pour planifier une transition progressive : 1) Cartographiez les relations de l'ancienne base de données et isolez les périmètres indépendants, 2) Posez un routeur/proxy en amont pour gérer le trafic, 3) Migrez d'abord les services non critiques orientés lecture, 4) Gardez les flux centraux comme les commandes et paiements pour la toute fin.

Dans mon expérience de consultant, sur 5 systèmes d'entreprise réécrits from scratch, 4 ont dépassé la date de livraison promise d'au moins 6 mois. En revanche, sur les systèmes modernisés par étapes, les dérives budgétaires sont restées très modérées et aucun n'a subi d'interruption critique sur les commandes. La proposition de votre dev senior repose sur des bases bien plus réalistes.

La migration progressive a aussi un coût caché : pendant 18 mois, votre équipe va devoir gérer deux architectures différentes, deux modèles de données distincts et la synchronisation entre les deux. Si vous avez une petite équipe, cette double charge de maintenance risque d'épuiser vos développeurs et le projet finira quand même par bloquer.

Pour tester le plan de votre développeur, lancez la première étape sans attendre. Avant de signer un contrat à 110.000 dollars avec l'agence, donnez 2 mois à votre dev pour isoler le module le plus simple. S'il arrive à monter le nouveau service et à gérer la synchro des données sans accroc, vous pourrez ranger le devis de l'agence au placard direct.

Une agence qui prétend pouvoir réécrire de zéro un ERP complexe vieux de 12 ans en 8 mois, c'est juste qu'elle n'a pas encore découvert les remises clients sur mesure et les règles comptables non documentées cachées dans le système ; le jour de la mise en prod, vous verrez bien comment ces 8 mois vont se transformer en 20 mois.

la migration des donnees c vraiment le pire casse-tete... du coup impossible d'injecter des enregistrements corrompus ou incomplets de la vieille bdd dans un systeme tout neuf sans faire un gros nettoyage. au moins en progressif t'as l'occasion de verifier la data reelle pas a pas, avec une bascule d'un coup c'est mort.

Quelle que soit la méthode retenue, je vous conseille vivement d'intégrer au contrat une garantie d'intégrité des données ainsi qu'une procédure de rollback pour chaque étape. Il ne faut jamais perdre de vue que la continuité opérationnelle prime toujours sur l'architecture logicielle.

Je pense différemment. Si les critères d'acceptation ne sont pas écrits, la date de fin du projet est ouverte à discussion.

Le vrai problème n'est pas le chiffre, mais la base sur laquelle il est calculé. Si vous avez des questions, écrivez-moi, je répondrai au mieux.

J'écris cela pour éviter que vous ne fassiez la même erreur. Quand on essaie de tout changer en même temps, rien ne prend.

Si c'est une première, commencez petit, l'échelle viendra plus tard. Si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.

J'ai été soulagé en lisant cette réponse donc ce n'est pas seulement mon cas... Si vous obtenez trois réponses différentes sur un sujet la question est mal posée.

Avant de décider, regardez quelles données vous avez en main. Si vous avez des questions écrivez-moi, je répondrai au mieux.

J'aurais une question, sans vouloir m'éloigner du sujet. Si la propriété du code n'est pas mentionnée dans le contrat, vous perdez tout pouvoir de négociation au départ.

Essayer de faire cela seul est la voie la plus coûteuse. Je suis aussi curieux de savoir si d'autres font autrement.

Je vais résumer le sujet car plusieurs réponses différentes ont été données. L'erreur commise du côté de modernisation de système legacy est généralement réversible, mais coûteuse.

On en parle beaucoup mais chez nous cela ne s'est jamais passé ainsi. Les accès doivent être créés au nom de l'entreprise, pas avec des comptes personnels.

C'est mon avis, je ne l'écris pas comme une vérité absolue.

Je pense différemment. Prendre des notes pendant deux semaines donne de meilleurs résultats qu'une estimation de six mois.

Lors de la prise de décision, écrivez aussi le pire scénario, pas seulement le meilleur. C'est confirmé par l'expérience.

Comment avez-vous résolu ce point ? Quand on essaie de tout changer en même temps, rien ne prend.

Voilà désolé si je me suis étendu.

La discussion part dans tous les sens, je recentre. Les décisions hâtives finissent par être corrigées six mois plus tard.

Je le note au cas où.

Enregistré.