Reprendre ou réécrire ? Comment décider quoi faire d'une application web en difficulté

Points clés

• La plupart des applications web en difficulté devraient être reprises progressivement, pas réécrites de zéro. Les réécritures complètes prennent plus de temps que prévu et perdent le savoir que l'ancien système contient sans le dire.
• Une réécriture se justifie quand les fondations elles-mêmes sont mauvaises (technologie abandonnée, modèle de données incapable de représenter l'activité, code que personne ne peut modifier sans risque), pas simplement parce que le code est laid.
• Commencez par un diagnostic : impossible de bien décider sans savoir ce que contiennent réellement le code et la production.
• Le remplacement progressif, pièce par pièce derrière des interfaces stables, apporte l'essentiel des bénéfices d'une réécriture pour une fraction du risque.
• Une reprise type commence par un diagnostic de 2 semaines puis 1 à 3 mois de stabilisation, pour 15 000 à 50 000 € HT au total : en général une fraction du coût d'une réécriture complète du même système.

Une reprise d'application est la remise en état progressive d'une application existante : la stabiliser, ajouter des filets de sécurité et la restructurer étape par étape, au lieu de la remplacer d'un seul coup. Toute équipe qui porte un produit fragile finit par se poser la même question : réparer ce que nous avons, ou tout jeter et recommencer ? La réécriture séduit parce qu'elle promet une page blanche. La reprise est moins excitante, mais généralement plus sûre. Ce guide vous donne une méthode concrète pour décider.

Les signes que votre application a besoin d'attention

Pas besoin de lire le code pour savoir que quelque chose ne va pas. Les symptômes se voient dans l'activité :

• Chaque modification casse quelque chose d'autre. De petites fonctions prennent des semaines parce que personne ne peut prévoir les effets de bord.
• Le système ralentit ou tombe quand l'usage augmente. Les problèmes de performance apparaissent sous charge réelle.
• On ne peut pas se fier aux données. Les rapports se contredisent, des enregistrements sont en double ou incohérents, et chacun garde ses propres tableurs « au cas où ».
• Le savoir repose sur une seule personne, ou sur un ancien développeur ou une agence qui n'est plus là.
• Les mises à jour de sécurité sont repoussées parce que mettre à jour les dépendances semble trop risqué.
• Les incidents se répètent. La même panne ou le même bug revient après avoir été « corrigé ».

Ces symptômes disent qu'il y a un problème. Ils ne disent pas si la réponse est une reprise ou une réécriture.

Pourquoi les réécritures complètes sont plus risquées qu'elles n'en ont l'air

Les réécritures échouent de façon prévisible :

• L'ancien système en sait plus que quiconque. Des années de corrections et de cas particuliers vivent dans le code, souvent sans documentation. Une réécriture doit tous les redécouvrir, en général en production.
• L'activité ne s'arrête pas. Pendant la construction du nouveau système, l'ancien a toujours besoin de corrections et de fonctions. Vous finissez par maintenir deux systèmes, ou par geler le produit.
• Le périmètre gonfle. « Tant qu'on y est » transforme une réécriture en refonte. Fred Brooks a décrit une version de ce phénomène, l'effet second système (en anglais), dans The Mythical Man-Month : la tendance à sur-concevoir le remplaçant.
• Rien n'est livré tant que tout n'est pas livré. Une réécriture « big bang » n'apporte aucune valeur avant le jour de la bascule, qui est aussi le jour où le risque est maximal.

L'essai bien connu de Joel Spolsky, Things You Should Never Do (en anglais), défend ce point de vue à partir de l'expérience. L'argument est ancien et reste valable pour la plupart des produits.

Quand la réécriture est le bon choix

Les réécritures se justifient, mais pour des raisons précises :

• La technologie est une impasse. Le framework ou la plateforme n'est plus maintenu, n'est pas sûr ou ne permet plus de recruter, et la mise à jour revient de toute façon à une réécriture.
• Le modèle de données ne peut pas représenter l'activité. Si la structure même de vos données est fausse, tout ce qui est bâti dessus hérite du problème.
• Le produit a fondamentalement changé. Ce dont vous avez besoin aujourd'hui n'a plus grand-chose à voir avec ce qui a été construit.
• Le code est assez petit pour que le réécrire coûte moins cher que le comprendre.

Même dans ces cas, une réécriture n'a presque jamais besoin d'être faite d'un bloc. Elle peut être progressive.

Une grille de décision simple

Si la plupart des réponses tombent dans la colonne de gauche, reprenez. Si les réponses sur la technologie ou le modèle de données tombent clairement à droite, planifiez un remplacement, idéalement progressif.

Comment fonctionne une reprise progressive

Une bonne reprise suit toujours le même ordre :

1. Diagnostiquer. Lire le code, l'infrastructure et le processus de déploiement. Identifier ce qui est risqué, ce qui mérite d'être gardé et ce qui provoque activement des incidents. Un audit technique en est souvent la première étape.
2. Stabiliser. Corriger d'abord ce qui cause des pannes, corrompt des données ou expose à des failles de sécurité. Ajouter de la supervision pour voir les problèmes avant que les clients ne les signalent.
3. Poser des filets de sécurité. Ajouter des tests autour des comportements les plus importants, pour que les changements suivants ne les cassent pas en silence.
4. Restructurer étape par étape. Améliorer les pires parties une à une, chaque étape étant déployable seule.
5. Remplacer là où c'est nécessaire. Les composants qui doivent vraiment être reconstruits sont remplacés derrière une interface stable pendant que le reste du système continue de tourner. Martin Fowler appelle cela le motif du figuier étrangleur (en anglais) : le nouveau système grandit autour de l'ancien jusqu'à ce que ses parties puissent être retirées.

L'activité continue de livrer pendant tout ce temps, et chaque étape réduit le risque au lieu de le concentrer à la fin.

Les données méritent une attention particulière. Des données incohérentes sont souvent le symptôme d'une logique qui les autorise. Corriger les enregistrements sans corriger la logique les laisse dériver à nouveau.

Les questions à se poser avant de décider

• Quels sont les trois problèmes qui nous coûtent le plus aujourd'hui, en temps, en chiffre d'affaires ou en risque ?
• Quelles parties du système sont stables, et lesquelles provoquent la plupart des incidents ?
• Que savons-nous du système qui n'est écrit nulle part ?
• Que perdrions-nous à geler les nouvelles fonctions pendant six mois ?
• Qui sera responsable du système ensuite, et pourra-t-il le comprendre ?

Questions fréquentes

Une nouvelle équipe peut-elle reprendre un code écrit par quelqu'un d'autre ? Oui. Elle commence par lire attentivement le code et l'environnement de production, puis stabilise avant toute modification importante. C'est le cœur de notre offre de reprise d'application.

Combien de temps dure une reprise, et combien coûte-t-elle ? Une reprise type commence par un diagnostic de 2 semaines (à partir de 5 000 € HT), puis 1 à 3 mois de stabilisation, pour 15 000 à 50 000 € au total. Dans les reprises que nous avons menées, les premières corrections des incidents les plus pénalisants sont généralement livrées dans les 10 premiers jours ouvrés. Les améliorations de structure se poursuivent ensuite en parallèle des évolutions normales, si bien que vous voyez des résultats tôt au lieu d'attendre une date de bascule. À titre de comparaison, reconstruire de zéro une application métier moyenne coûte généralement 40 000 à 90 000 € (voir notre guide des prix).

Et si le développeur d'origine n'est plus disponible ? C'est fréquent, et c'est l'une des raisons de documenter le système pendant la reprise : pour ne plus jamais dépendre d'une seule personne.

Notre site a été piraté. Est-ce une reprise ou une réécriture ? Ni l'un ni l'autre, dans un premier temps. Une compromission demande une investigation et un nettoyage avant tout le reste, car les attaquants laissent souvent des mécanismes de persistance. Voir notre offre de réponse aux incidents et notre retour sur une infection de spam SEO sous WordPress (en anglais).

---

Si votre produit vous paraît fragile et que vous envisagez une réécriture, parlez-nous-en d'abord. Nous regarderons ce que vous avez et vous donnerons une recommandation honnête, même si elle consiste à en garder l'essentiel. Si vous voulez d'abord un regard indépendant sur le code, lisez ce que comprend un audit technique.

Sources

• Joel Spolsky, Things You Should Never Do, Part I, 2000 (en anglais)
• Martin Fowler, StranglerFigApplication (en anglais)
• Frederick P. Brooks Jr., The Mythical Man-Month, 1975 ; résumé de l'effet second système (en anglais)