Reprendre un projet sans tout réécrire

Commencer par les usages

Un code que l’on découvre paraît souvent plus compliqué que le code que l’on aurait écrit soi-même. Ce décalage ne suffit pas à justifier une réécriture. Avant de choisir une nouvelle architecture, je propose de comprendre le travail que l’application permet de réaliser et les contraintes auxquelles elle répond.

Prenons la validation d’une demande. En déroulant ce parcours avec une personne qui connaît le métier, on peut repérer une saisie que l’interface oblige à refaire ou une erreur qui bloque le travail. Ces observations donnent un contexte aux fichiers et aux composants que l’on lira ensuite.

• Identifier un utilisateur et la tâche qu’il cherche à terminer.
• Dérouler le parcours dans un environnement adapté, avec des données de test.
• Noter les dépendances : API, traitements différés, services externes et droits d’accès.
• Repérer ce qui est certain, ce qui reste à vérifier et qui peut répondre.

Sécuriser un parcours avant de le modifier

Une première protection utile consiste à décrire le comportement observé. Que doit-il se passer lorsqu’une demande est valide ? Que voit l’utilisateur si un service ne répond pas ? Un test ciblé, une procédure de vérification ou une capture de référence peuvent aider à rendre ce comportement explicite. Le choix dépend du risque et des outils déjà présents dans le projet.

Il faut aussi savoir comment lancer le projet, produire une version et revenir à la précédente. Si ces étapes dépendent d’un savoir oral, les documenter constitue déjà une contribution. Une correction minuscule reste difficile à livrer lorsqu’on ne sait pas vérifier son résultat ou identifier la version en service.

Choisir une première étape limitée

Je privilégie ensuite une intervention dont le résultat est facile à vérifier. Si une erreur réseau efface la demande en cours, conserver la saisie et permettre un nouvel essai fournit un premier périmètre. Cette correction oblige à comprendre le formulaire et à vérifier son comportement en cas d’échec, avec un changement assez petit pour rester lisible.

const premiereEtape = {
  parcours: "Valider une demande",
  probleme: "Une erreur réseau ne permet pas de réessayer",
  changement: "Conserver la saisie et proposer un nouvel essai",
  verification: "Simuler un échec puis une réponse valide",
};

Cette première livraison peut révéler qu’il manque un moyen de simuler l’erreur réseau. Préparer ce cas devient alors une tâche pour la suite, avec une raison précise de s’en occuper. La correction aide ainsi à identifier ce qui ralentit réellement le travail sur ce projet.

Garder la réécriture comme une décision à étayer

Une réécriture peut devenir pertinente lorsque des contraintes précises l’exigent. Elle mérite alors une comparaison explicite avec une évolution progressive : quels usages faut-il préserver, comment migrer les données, quelles parties peuvent coexister et comment vérifier le résultat ? Comprendre l’existant aide aussi à répondre à ces questions.

Pour démarrer, choisissez un parcours avec la personne qui l’utilise et notez le comportement à préserver avant de toucher au code. La première correction donnera des éléments pour décider de la suite.