Une application métier de dix ans n'est pas forcément à jeter. C'est souvent le seul endroit où le fonctionnement réel de l'entreprise est écrit noir sur blanc, règles de gestion comprises. Le problème est rarement le code lui-même : c'est le socle technique qui arrive en fin de support, et la crainte parfaitement fondée de tout casser en voulant tout refaire d'un coup. L'étranglement progressif est la réponse technique à cette impasse.

Pourquoi la réécriture complète est le scénario le plus risqué

Refaire une application à l'identique suppose de savoir ce qu'elle fait. Or la documentation s'est souvent arrêtée à la mise en service, et le comportement réel du logiciel a été façonné par des années de correctifs et de cas particuliers. Une réécriture complète oblige à redécouvrir tout cela en même temps qu'on développe.

Le second problème est financier : pendant tout le chantier, l'entreprise paie le maintien de l'ancien système et la construction du nouveau, sans aucun bénéfice avant la bascule finale. Le troisième est humain : une bascule unique concentre le risque sur un week-end, et un écart de règle de gestion découvert le lundi matin n'a qu'une issue, le retour arrière, souvent impraticable dès que les utilisateurs ont saisi dans le nouvel outil.

Les échéances qui déclenchent vraiment le chantier

Une modernisation démarre rarement pour des raisons esthétiques : elle démarre parce qu'une brique du socle cesse d'être supportée. Deux échéances concernent beaucoup d'applications métier internes.

  • SQL Server 2016 : le support étendu s'est terminé le 14 juillet 2026. Microsoft propose des mises à jour de sécurité étendues (ESU) pendant trois ans au maximum, jusqu'en juillet 2029, mais elles ne couvrent que les correctifs de sécurité critiques, ni les corrections fonctionnelles ni les évolutions.
  • Windows Server 2016 : le support étendu se termine le 12 janvier 2027. Là encore, un programme ESU existe pour trois années supplémentaires, gratuit pour les serveurs exécutés dans Azure, payant pour les serveurs sur site.

Un programme ESU n'est pas une solution, c'est un délai acheté. Le piège classique consiste à souscrire l'extension, à considérer le sujet réglé, puis à se retrouver dans la même situation trois ans plus tard avec une application encore plus figée.

Le principe de l'étranglement progressif

L'idée est simple et connue des architectes logiciels sous le nom de figuier étrangleur. Plutôt que de remplacer l'application entière, on la place derrière un point d'aiguillage. À chaque itération, une fonction est réécrite dans le nouveau système, et l'aiguillage envoie désormais les demandes correspondantes vers la nouvelle implémentation. L'ancienne application continue de traiter tout le reste. Au fil des mois, elle se vide de sa substance jusqu'à ne plus rien porter, et on l'éteint.

Le risque cesse alors d'être concentré sur une date unique : il se répartit sur une série de petites bascules réversibles. Si une itération se passe mal, on remet l'aiguillage sur l'ancien chemin et l'activité continue.

La contrepartie doit être dite : pendant la transition, deux systèmes coexistent et doivent être exploités ensemble. Un étranglement abandonné à mi-chemin fige durablement ce double coût. La méthode n'a de sens que si l'entreprise s'engage jusqu'à l'extinction de l'ancien système.

Où poser la première coupe

Il faut choisir un premier morceau assez utile pour être visible, assez isolé pour être détaché sans tout démonter. Quatre points de coupe fonctionnent bien en pratique.

  • Une fonction périphérique complète : génération de documents, envoi des relances, module de réservation. Elle touche peu au coeur du modèle de données et son résultat est immédiatement visible.
  • Un écran de consultation : une vue en lecture seule reconstruite à côté, alimentée par les mêmes données. Le risque est quasi nul et le nouveau socle est validé en conditions réelles avant d'y écrire quoi que ce soit.
  • Un traitement planifié : import nocturne, export comptable. Souvent mal documenté mais bien délimité, et sa bascule ne se voit pas des utilisateurs.
  • Un canal d'entrée : un portail client ou un formulaire externe, que l'on reconstruit devant l'ancienne application plutôt que dedans.

Deux zones sont à éviter pour commencer : la gestion des droits et le coeur transactionnel, là où l'ancien système contient le plus de règles implicites et où une erreur se paie le plus cher.

Les données, le vrai point dur

Le découpage fonctionnel est la partie facile. La difficulté est de décider, pour chaque donnée, qui en est propriétaire pendant la transition. Deux systèmes qui écrivent au même endroit sans règle claire produisent des incohérences silencieuses, découvertes des semaines plus tard dans un état comptable.

La règle à poser dès le départ : une donnée n'a qu'un seul propriétaire à un instant donné. Les autres composants la lisent, éventuellement via une copie synchronisée, mais ne l'écrivent pas. Quand une fonction bascule, la propriété de ses données bascule avec elle, à une date connue et annoncée. Tant que l'on ne sait pas répondre à la question, la bascule n'est pas prête.

Cela suppose trois choses : une synchronisation dans un seul sens, plus simple à déboguer qu'un échange bidirectionnel ; des identifiants stables et partagés entre les deux mondes ; un contrôle de cohérence automatisé qui compare régulièrement les deux côtés et alerte sur les écarts.

Une méthode en quatre temps

  1. Cartographier avant de coder. Lister les fonctions réellement utilisées, leur fréquence et les données qu'elles touchent. Les journaux d'utilisation en disent plus que les entretiens : des écrans entiers n'ont parfois pas été ouverts depuis un an et n'ont donc pas à être réécrits.
  2. Installer le point d'aiguillage. Reverse proxy, passerelle applicative ou simple redirection selon l'architecture. Cette brique doit être en place et testée avant la première bascule, jamais improvisée le jour J.
  3. Basculer, stabiliser, mesurer. Chaque itération se termine par un temps d'observation. Trois indicateurs suffisent : incidents remontés, temps de traitement de l'opération concernée, nombre de retours au chemin ancien.
  4. Fixer et tenir une date d'extinction. Elle doit figurer dans le plan dès la première itération. Sans elle, le projet s'étire, les budgets se réallouent et l'ancien système survit indéfiniment.

Cinq erreurs qui font échouer un étranglement

  • Commencer par le module le plus complexe pour se prouver que c'est possible. La première itération doit servir à roder la mécanique, pas à affronter le pire.
  • Reproduire l'existant à l'identique, y compris les contournements nés d'une limite technique disparue depuis.
  • Négliger l'exploitation du couple. Supervision, sauvegardes et restaurations doivent couvrir les deux systèmes et leur synchronisation.
  • Oublier la reprise d'historique. Décider tôt entre reprise complète, reprise partielle et consultation en archive évite une mauvaise surprise en fin de parcours.
  • Laisser le chantier sans propriétaire côté métier. Un arbitrage fonctionnel par itération est nécessaire, et il ne peut pas être rendu par le prestataire.

L'étranglement progressif ne rend pas la modernisation gratuite, mais il la rend finançable par tranches, réversible à chaque étape et compatible avec une activité qui ne s'arrête pas.

Questions fréquentes

Combien de temps dure une modernisation par étranglement ?

Cela dépend du nombre de fonctions réellement utilisées, pas de l'âge de l'application. L'essentiel est de cadencer les itérations et de fixer dès le départ une date d'extinction de l'ancien système.

Peut-on moderniser une application dont on n'a plus le code source ?

Oui, dans bien des cas. On travaille autour de l'application plutôt que dedans : reconstruction des fonctions à côté, lecture de la base de données, interception des flux entrants.

Faut-il obligatoirement changer de technologie ?

Non. Le déclencheur est le plus souvent la fin de support d'un composant du socle. Changer de langage ou de cadre applicatif est une décision distincte, qui doit se justifier par la disponibilité des compétences et la durée de support de la nouvelle pile.

Que faire si le développeur d'origine a disparu ?

La priorité est de reprendre la maîtrise des accès et des sources : hébergement, noms de domaine, dépôts de code, comptes éditeurs. Un audit de reprise établit ensuite ce qui peut être maintenu et ce qui doit être remplacé en premier.

Un programme ESU suffit-il à régler le problème ?

Non. Les mises à jour de sécurité étendues achètent du temps, jusqu'à trois ans, et ne couvrent que les correctifs critiques. Elles sécurisent la période de transition, elles ne remplacent pas la modernisation.

Vous avez une application métier qui fonctionne mais que personne n'ose plus toucher, ou un socle technique en fin de support ? Parlons de votre projet : nous commençons par un état des lieux et un plan de découpe, avant toute ligne de code.