Reprenez le contrôle d'une application web développée par un autre prestataire

Nous corrigeons les bugs critiques, mettons à jour les dépendances de sécurité et mettons en place un environnement de développement propre. L'application continue de fonctionner pendant cette phase. La dette technique la plus urgente est traitée en priorité pour que les évolutions suivantes ne soient plus freinées.

Nous documentons l'architecture, les processus métier et les API. Nous ajoutons des tests automatisés pour sécuriser les évolutions futures et détecter les régressions.

Un audit technique complet avec rapport et plan d'action chiffré se situe entre 5 et 12 k€ selon la taille de la codebase. La phase de stabilisation et de refactoring qui suit démarre autour de 20 à 40 k€ pour une application de taille moyenne, et peut monter à 80-150 k€ pour des systèmes plus larges. La bonne approche est souvent de moderniser plutôt que refondre, ce qui coûte deux à trois fois moins cher qu'une réécriture complète.

L'audit prend 2 à 4 semaines selon la taille du projet. La phase de stabilisation initiale (mises à jour critiques, correctifs sécurité, environnement propre) dure 4 à 8 semaines. Ensuite, la modernisation progressive se fait module par module au rythme qui vous convient, sans bloquer le service. Pour les cas très dégradés, on peut aussi envisager un cadrage de refonte pour comparer les deux options chiffrées.

Oui, c'est le cœur de cette prestation. La reprise d'une application web développée par un autre prestataire suit un protocole rodé : récupération des accès (dépôt de code, hébergement, base de données, services tiers), gel d'un état de référence, puis audit avant toute modification. Si l'ancien prestataire est joignable, nous organisons une passation ; s'il a disparu, nous reconstituons la connaissance par reverse engineering. Dans les deux cas, votre application reste en service pendant toute la transition.

La reprise de code garde l'application existante et l'améliore pièce par pièce, sans rupture de service. La refonte garde l'idée et les données mais change la stack et l'architecture. La réécriture repart de zéro avec un nouveau code. La reprise est presque toujours le meilleur choix dans un premier temps : moins coûteuse, moins risquée, et elle permet de juger ensuite si une refonte est réellement nécessaire ou si l'architecture actuelle peut vivre plusieurs années encore.