Faut-il réécrire son application ou la moderniser progressivement ?

Commencer par une liste de blocages vérifiables

« Le système est vieux » décrit un âge, pas un obstacle. Il faut nommer ce qu’il empêche : mettre à jour une dépendance, isoler des données, absorber un volume précis ou faire évoluer une règle métier sans risque disproportionné. Chaque blocage doit être relié à une observation et à une conséquence.

L’équipe peut ensuite distinguer les limitations locales des contraintes fondamentales. Un composant très couplé peut parfois être isolé progressivement. Un modèle de données incompatible avec le nouveau métier peut exiger un changement plus profond. Cette distinction demande une analyse, pas un vote entre personnes favorables ou opposées à la refonte.

Il faut également décrire ce qui fonctionne et doit être préservé. Les interfaces partenaires, les rapprochements métiers et les routines d’exploitation représentent souvent une connaissance importante. Leur stabilité est un actif, même lorsque le code qui les porte est peu agréable à lire.

Reconnaître les cas où une réécriture mérite d’être étudiée

Une réécriture peut devenir pertinente lorsqu’un périmètre ne peut plus évoluer dans des conditions raisonnables, que les dépendances fondamentales sont sans issue ou que le modèle métier doit être profondément changé. Elle peut aussi porter sur une partie bien délimitée plutôt que sur tout le produit.

La justification doit expliquer pourquoi des solutions moins larges seraient insuffisantes. Elle doit préciser les preuves disponibles, les hypothèses et les coûts qui restent à évaluer. Une équipe plus à l’aise avec une autre technologie peut proposer une solution viable, mais sa préférence seule ne démontre pas la nécessité du remplacement.

Un critère essentiel est la capacité à vérifier l’équivalence ou les différences voulues. Si personne ne sait décrire les comportements importants, une reconstruction complète devient particulièrement risquée. Une phase d’apprentissage de l’existant peut alors être nécessaire avant de choisir la stratégie.

Évaluer le coût caché du système neuf

Le nouveau produit doit souvent rattraper des fonctions peu visibles : exports, règles d’arrondi, permissions, reprises d’erreur et exceptions utilisées occasionnellement. Ces éléments peuvent sembler secondaires jusqu’au jour où leur absence bloque une opération importante. Leur identification doit faire partie de la préparation.

Pendant le chantier, l’ancien système continue généralement à recevoir des corrections et des évolutions. La nouvelle version poursuit donc une cible qui bouge. Il faut définir comment les changements sont reportés, quelles fonctions sont gelées et qui arbitre les écarts. Sans cette organisation, le retard peut croître même si la nouvelle équipe livre régulièrement.

La formation des utilisateurs, les outils de support et les procédures d’exploitation font aussi partie du changement. Une application techniquement prête n’est pas nécessairement prête à remplacer celle dont dépend l’activité. La décision doit considérer ce coût de transition complet.

Tester la faisabilité d’une modernisation progressive

La progression consiste à remplacer ou améliorer des périmètres successifs tout en maintenant le service. Elle demande des frontières suffisamment claires, une stratégie de données et des critères de bascule. Elle ne se résume pas à écrire du nouveau code à côté de l’ancien en espérant les réunir plus tard.

Un premier périmètre doit être représentatif sans être le plus dangereux. Il sert à vérifier les interfaces, les procédures de livraison et la capacité de retour arrière. Si cette étape révèle que chaque changement touche tout le système, la trajectoire doit être revue plutôt que poursuivie par habitude.

La coexistence a un coût. Deux modèles, deux outils et des échanges supplémentaires peuvent alourdir l’exploitation. Une stratégie progressive devient intéressante lorsqu’elle réduit le risque global et permet d’apprendre ; elle n’est pas automatiquement moins chère ni plus rapide.

Traiter les données comme un chantier de premier plan

Les données portent des incohérences, des historiques et des règles qui ne sont pas toujours visibles dans les écrans. Une migration demande de comprendre les identifiants, les relations, les formats et les usages en aval. Les transformations doivent être testées sur des données représentatives et protégées.

Il faut préciser qui écrit pendant la transition et quelle version fait autorité. Une double écriture introduit des risques de divergence ; une interruption planifiée peut être plus simple mais incompatible avec certains usages. Le choix dépend des contraintes de continuité et des possibilités de rattrapage.

Construire une comparaison honnête des scénarios

Présentez au moins le maintien sécurisé, une modernisation ciblée et le remplacement envisagé lorsque ces options sont plausibles. Pour chacune, décrivez les problèmes traités, les limites restantes, les prérequis, le risque de transition et les engagements difficilement réversibles.

Les estimations doivent partager le même périmètre. Comparer une réécriture sans migration ni exploitation à une modernisation qui inclut tous les risques conduit à une conclusion trompeuse. Les inconnues doivent apparaître séparément et faire l’objet d’investigations ciblées si elles peuvent changer la décision.

La capacité de l’équipe est une contrainte réelle. Un plan qui mobilise toutes les personnes expérimentées peut fragiliser le support du produit existant. Il faut donc examiner les disponibilités et les responsabilités pendant toute la transition, y compris en cas d’incident.

Définir les points d’arrêt avant de commencer

Un chantier de remplacement peut accumuler des engagements qui rendent son abandon émotionnellement difficile. Des points de contrôle explicites permettent de revenir aux faits : périmètre réellement repris, comportement vérifié, migration répétable et capacité d’exploitation. Ils peuvent conduire à poursuivre, réduire ou réorienter le projet.

Les critères de bascule doivent être compréhensibles par les métiers. « Tous les développements sont terminés » ne garantit pas que les opérations critiques fonctionnent. La validation doit inclure les scénarios d’erreur, les cas peu fréquents mais importants et les procédures de support.

Le retrait de l’ancien système est lui aussi une décision. Vérifier les consommateurs restants, les besoins de conservation et les accès évite de conserver indéfiniment deux produits. Une modernisation achevée doit clarifier les responsabilités au lieu de les superposer.

Les questions à poser avant de signer

Demandez qui recensera les comportements à conserver, comment les écarts seront arbitrés et qui validera la migration des données. Précisez ensuite ce qui arrivera aux évolutions demandées pendant le chantier : seront-elles intégrées aux deux versions, reportées ou limitées à un périmètre ? Enfin, demandez une description de la bascule et du scénario de repli. Ces réponses peuvent rester provisoires au cadrage, mais leur absence doit apparaître dans le niveau d’incertitude du projet. Une estimation qui ne couvre pas ces travaux ne doit pas être comparée comme si elle représentait le coût complet du remplacement. La question centrale reste la continuité de l’activité pendant et après le changement.

Faire relire la proposition avant l’engagement

Lorsqu’une agence propose de tout refaire, demandez une justification du périmètre, une comparaison d’alternatives et un plan de transition. Ces questions ne remettent pas en cause sa compétence ; elles permettent d’évaluer l’engagement demandé à l’entreprise.

Un avis indépendant peut examiner les hypothèses, les risques de données et les conditions de continuité. Il peut conclure qu’une réécriture est justifiée, qu’un périmètre plus limité suffit ou que les informations disponibles ne permettent pas encore de décider.

Trame accompagne cette comparaison et la préparation d’une trajectoire de modernisation. Le cabinet ne vend pas le développement retenu, ce qui permet de discuter le volume de travaux sans intérêt commercial dans son augmentation.