Le prestataire ne répond plus
Les accès sont incomplets, le dépôt de code est flou, et une correction simple devient un projet.
Sur mesure
Reprise d'une application existante
Une application qui tient encore la production ne se réécrit pas par principe. On commence par ce qui casse, ce qui n'est plus compris, et ce qui empêche d'évoluer.
Situations
Chaque mise à jour est un risque
Personne ne sait ce que le changement va casser. Les évolutions s'arrêtent.
La refonte totale est brandie trop tôt
Elle rassure sur le papier et gèle le métier pendant des mois. Une reprise par étapes remet l'outil sous contrôle plus tôt.
Déroulement
- Audit
Accès, données, dettes visibles, et ce qui doit être stabilisé avant toute évolution.
- Plan court
Quelques corrections qui rendent l'outil opérable, puis seulement les chantiers de fond.
- Modernisation progressive
On remplace un morceau à la fois, pendant que l'ancien continue de servir.
Ordre de grandeur
L'audit est un cadrage payant. Le chiffrage de la reprise vient après, parce qu'un existant non documenté se laisse mal deviner.
L'estimateur applique un coefficient quand la reprise part sans documentation. Ce n'est pas une pénalité : c'est le temps de comprendre.
Questions fréquentes
Faut-il le code source ?
Oui, ainsi que les accès à l'hébergement et aux données. Sans eux, la première mission est de les récupérer, pas de développer.
Reprenez-vous aussi un site WordPress ou PrestaShop ?
Oui, sur une offre séparée : reprise de site, migration, ou maintenance. Le parcours n'est pas le même que pour une application métier.