---
title: "Projet mal codé : refonte progressive ou repartir de zéro ? (guide de décision) | Orange Bleu"
canonical_url: "https://orangebleu.be/blog/reprendre-projet-mal-code"
last_updated: "2026-08-26T15:30:01.626Z"
meta:
  description: "Votre application est fragile, votre prestataire a disparu, chaque évolution casse quelque chose. Comment décider entre reprise, refonte partielle et réécriture, par une agence qui reprend des projets."
  "og:description": "Votre application est fragile, votre prestataire a disparu, chaque évolution casse quelque chose. Comment décider entre reprise, refonte partielle et réécriture, par une agence qui reprend des projets."
  "og:title": "Projet mal codé : refonte progressive ou repartir de zéro ? (guide de décision) | Orange Bleu"
---

[![Orange Bleu](https://orangebleu.be/_ipx/q_80&s_55x48/assets/ob-logo.png)Accueil Orange Bleu](https://orangebleu.be/) [** Prendre RDV **](https://cal.com/antoine-gowie/meeting)

# **Projet mal codé : refonte progressive ou repartir de zéro ? (guide de décision)**

Votre application est fragile, votre prestataire a disparu, chaque évolution casse quelque chose. Comment décider entre reprise, refonte partielle et réécriture, par une agence qui reprend des projets.

Par Antoine Gowie, mis à jour le 26 août 2026

Le développeur ne répond plus. Chaque nouvelle fonctionnalité casse deux choses ailleurs. Le code n'est pas documenté, et vous n'osez plus y toucher. D'abord, ce n'est pas de votre faute : évaluer la qualité d'un code sans être un expert est presque impossible, c'est précisément pour ça que le problème est si répandu. Ensuite, tout n'est pas à jeter, et la pire décision serait de trancher sans diagnostic.

## Les trois issues possibles (et leurs vrais coûts)

**1. La reprise progressive.** Le code a des défauts mais les fondations tiennent. On documente, on stabilise, on corrige module par module tout en continuant à livrer de la valeur. La moins chère, la moins risquée, quand elle est possible.

**2. La refonte partielle.** Certaines parties tiennent, d'autres non. On garde ce qui marche (souvent la base de données et la logique métier validée) et on réécrit ce qui bloque. Le cas le plus fréquent chez nous.

**3. La réécriture complète.** Parfois inévitable : stack abandonnée, architecture irrécupérable, dette telle que corriger coûte plus cher que refaire. Mais c'est la décision la plus souvent prise à tort, sous le coup de la frustration, pas du diagnostic. Réécrire, c'est aussi rejouer tous les bugs déjà corrigés et toutes les décisions métier déjà tranchées dans l'ancien code.

## Comment on décide : l'audit technique

Avant toute recommandation, on audite l'existant : architecture, qualité du code, sécurité, dette, documentation, dépendances. Concrètement, on cherche des réponses à trois questions : qu'est-ce qui est récupérable ? qu'est-ce qui est dangereux ? qu'est-ce qui bloque vos évolutions ?

Vous recevez un état des lieux en langage clair (pas un rapport de quarante pages en jargon), avec une recommandation argumentée et chiffrée. L'objectif : repartir sur des bases saines **sans tout jeter**.

## Les signaux qui orientent la décision

**Plutôt reprise ou refonte partielle si** l'application est utilisée et rend service, que les bugs sont localisés dans certains modules, que les données sont propres et que la stack est encore maintenue.

**Plutôt réécriture si** la stack n'est plus maintenue ou introuvable sur le marché, que chaque modification coûte plus cher que la précédente, que la sécurité est compromise structurellement, ou que le produit doit évoluer dans une direction que l'architecture interdit.

**Le facteur qu'on oublie :** le code capture des années de décisions métier. Un formulaire bizarre cache souvent une règle apprise à la dure. Réécrire sans comprendre, c'est réapprendre en production.

## Et la relation avec l'ancien prestataire ?

Trois situations classiques. **Il a disparu :** on vérifie que vous avez les accès (code, serveurs, base de données, nom de domaine, souvent le vrai problème) et on récupère ce qui peut l'être. **La relation est tendue :** on organise une passation minimale et factuelle. **Il est de bonne volonté mais dépassé :** la transition se passe bien plus souvent qu'on ne croit.

Dans tous les cas, vérifiez dès maintenant, contractuellement, que le code et les accès vous appartiennent. C'est votre levier.

Si la question derrière la vôtre est surtout « à qui confier la suite » : [agence, freelance ou développeur interne](https://orangebleu.be/blog/agence-freelance-ou-developpeur-interne). Et si l'application en question a été générée avec des outils IA, la reprise a ses particularités : [créer une app avec l'IA, jusqu'où ça va](https://orangebleu.be/blog/creer-une-app-avec-l-ia).

## **Questions fréquentes **

- ### **Combien coûte une reprise de projet ?**

  L'audit d'abord, quelques jours, qui chiffre la suite. Une refonte partielle coûte typiquement 30 à 60 % d'une réécriture. La majorité de nos projets, reprise comprise, se situent entre 20 000 et 50 000 €.
- ### **Peut-on continuer à utiliser l'application pendant la refonte ?**

  Oui, c'est même le principe de la reprise progressive : l'application vit, on remplace les organes un par un.
- ### **Comment éviter que ça se reproduise ?**

  Code documenté, architecture claire, et propriété contractuelle du code et des accès. On livre systématiquement de quoi être repris, y compris par quelqu'un d'autre que nous. C'est le test à faire passer à votre prochain prestataire.
- ### **Mon ancien prestataire refuse de donner le code, que faire ?**

  Vérifiez votre contrat, en particulier la clause de propriété intellectuelle. Si le code vous appartient, un rappel formel de vos droits suffit souvent. On peut aussi évaluer ce qui est récupérable sans lui.

## **Vous voulez un chiffre pour votre projet ?**

Premier échange de 30 minutes, gratuit et sans engagement. On vous donne une fourchette honnête, même si la réponse est « ne faites pas de sur mesure ».

[**Prendre RDV **](https://cal.com/antoine-gowie/meeting)