Sur mesure
Reprendre une application existante : audit, maintenance ou refonte ?
Prestataire disparu, développeur parti, technologie vieillissante : comment reprendre une application existante, ce que révèle l'audit, et comment choisir entre maintenir, moderniser et refondre.
4 min de lecture
L'essentiel
- Première priorité : récupérer le nom de domaine, l'hébergement et le code source.
- L'audit reconstitue la connaissance et produit la documentation manquante.
- La modernisation progressive est souvent plus sûre qu'une refonte totale.
Le prestataire qui a développé votre application a fermé, ne répond plus, ou le développeur interne est parti. L'outil fonctionne encore, mais personne n'ose y toucher, et chaque mise à jour devient un pari. C'est une situation bien plus fréquente qu'on ne le croit, et elle se règle. Voici comment reprendre une application existante, étape par étape.
Les signes qu'il est temps d'agir
- Plus personne ne sait comment l'application fonctionne, ni comment la déployer.
- Les technologies utilisées ne sont plus maintenues : plus de correctifs de sécurité.
- Chaque petite évolution prend des semaines et casse autre chose.
- Vous ne savez pas exactement qui détient les accès : code, serveur, nom de domaine.
- L'application tombe en panne et personne n'est capable d'intervenir rapidement.
Étape 1 : récupérer les accès
C'est la priorité absolue, avant même de regarder le code. Listez et récupérez :
- le nom de domaine : vérifiez qu'il est bien au nom de l'entreprise ;
- l'hébergement : comptes d'administration des serveurs et des services ;
- le code source, idéalement avec son historique ;
- les bases de données et leurs sauvegardes ;
- les services tiers : envoi d'emails, paiement, API, certificats, comptes des magasins d'applications.
Votre contrat avec l'ancien prestataire précise en général la propriété du code et les obligations de restitution : c'est votre premier appui.
Étape 2 : l'audit
L'audit permet de savoir précisément à quoi on a affaire. Il examine :
- l'architecture : comment l'application est construite et où elle tourne ;
- les technologies et leurs versions : sont-elles encore maintenues ?
- la sécurité : failles connues, gestion des mots de passe, accès, exposition des données ;
- la qualité du code : lisibilité, tests, dette technique ;
- les données : structure, volume, qualité ;
- l'exploitation : sauvegardes, supervision, procédure de déploiement.
L'audit produit aussi la documentation qui manquait. À lui seul, il réduit déjà fortement le risque.
Étape 3 : sécuriser
Avant toute évolution, on met l'application à l'abri : sauvegardes vérifiées, correctifs de sécurité urgents, supervision, procédure de déploiement fiable. L'objectif est de pouvoir à nouveau intervenir sereinement.
Étape 4 : choisir la suite
| Option | Quand la choisir | Avantages |
|---|---|---|
| Maintenir | Le code est sain, les technologies encore maintenues | Le moins coûteux, aucune rupture |
| Moderniser progressivement | Une base correcte, mais des parties vieillissantes | Des améliorations continues, sans « big bang » |
| Refondre | Technologies abandonnées, code impossible à faire évoluer, besoin qui a beaucoup changé | Repartir sur des bases saines |
La refonte totale est tentante, mais rarement la meilleure première réponse : elle coûte cher, prend du temps et fait courir le risque d'oublier des règles que l'ancienne application appliquait sans que personne ne s'en souvienne. La modernisation progressive, partie par partie, est souvent plus sûre.
Ne pas revivre la situation
- Les accès appartiennent à l'entreprise, avec au moins deux personnes habilitées.
- Le code est versionné, documenté et vous appartient.
- Le contrat prévoit la réversibilité.
- Les technologies choisies sont standards et répandues.
Pour aller plus loin
La reprise d'applications fait partie de nos solutions sur mesure : on commence par un audit, puis on sécurise et on fait évoluer l'existant. Pour l'exploitation au quotidien, découvrez notre infogérance, et notre guide sur le contrat d'infogérance.