Comment reprendre la maintenance d'une application dont le développeur est parti ?
Sommaire
Que faire dans les 48 heures après le départ du développeur ?
Le départ d'un développeur crée un risque d'accès avant de créer un risque technique. Un dépôt Git hébergé sur un compte personnel bloque toute reprise. Un nom de domaine enregistré au nom du prestataire expose à une expiration silencieuse. Une clé API liée à une adresse e-mail inactive coupe un service du jour au lendemain.
- Reprendre la propriété du dépôt de code, vers une organisation appartenant au donneur d'ordre et jamais vers un compte individuel.
- Récupérer les accès administrateur de l'hébergement et du serveur, puis créer des comptes nominatifs.
- Vérifier le titulaire du nom de domaine chez le registrar, ainsi que la date d'expiration.
- Lister les services tiers facturés (paiement, e-mailing, stockage, monitoring) et identifier le moyen de paiement associé à chacun.
- Sauvegarder la base de données de production en dehors de l'infrastructure actuelle.
- Révoquer les accès de l'ancien prestataire une fois les cinq points précédents traités.
L'ordre compte. Révoquer les accès avant d'avoir vérifié le registrar transforme un départ en incident.
Combien de temps faut-il pour reprendre une application existante ?
Une reprise se déroule en trois temps mesurables. L'audit de reprise dure 1 à 2 semaines selon la taille de l'application et le nombre de services externes connectés. Le premier correctif déployé en production intervient après environ une semaine de travail sur le code. Ce délai couvre la reconstitution de l'environnement, la compréhension des dépendances et la validation d'une chaîne de livraison.
Un correctif bloquant peut sortir plus tôt si l'urgence l'impose. Le donneur d'ordre assume alors un risque de régression plus élevé.
Temps nécessaire à une équipe Athenix pour atteindre son rythme de production sur du code écrit par un tiers.
L'équipe type d'Athenix sur une reprise compte deux personnes : un tech lead et un développeur. Sur les périmètres réduits, un développeur senior travaille seul. Une équipe plus large ne raccourcit pas la phase de compréhension. Elle multiplie les questions sans réponse.
Que contient un audit de reprise ?
Un audit de reprise est un inventaire technique daté. Athenix le livre sous forme d'un rapport et d'une cartographie de l'application. Cet audit ne produit aucune correction. Son objet est de rendre chiffrable ce qui suivra.
- Stack et versions réellement déployées en production, comparées aux versions encore supportées par leurs éditeurs
- Dépendances : nombre de paquets obsolètes, vulnérabilités connues, bibliothèques abandonnées en amont
- Couverture de tests automatisés, existante ou nulle
- Chaîne de livraison : build reproductible, procédure de déploiement, capacité à revenir en arrière
- Secrets en dur dans le code et dans l'historique du dépôt
- Cartographie fonctionnelle : écrans, traitements planifiés, intégrations externes
- Données : volumétrie, sauvegardes existantes, restauration déjà testée ou non
Athenix facture cet audit au forfait ou au temps passé. Les deux formats coexistent parce que les périmètres n'ont pas la même prévisibilité. Une application de gestion interne se cadre au forfait. Une plateforme e-commerce connectée à huit services externes se cadre difficilement avant de l'avoir ouverte.
Peut-on reprendre une application sans documentation ni contact avec l'ancien développeur ?
Oui. C'est le cas de figure courant, pas l'exception. L'absence de documentation allonge l'audit sans l'empêcher.
Le code exécuté en production est la seule documentation certaine. Un schéma d'architecture vieux de deux ans décrit une application qui n'existe plus. La cartographie produite pendant l'audit remplace la documentation manquante. Elle est à jour par construction.
| Source d'information | Disponible sans l'ancien développeur | Ce qu'elle apporte |
|---|---|---|
| Code source et historique Git | Oui | Chronologie des changements, zones modifiées en urgence |
| Base de données de production | Oui | Modèle de données réel, volumétrie, données orphelines |
| Logs applicatifs et serveur | Oui | Parcours réellement utilisés, erreurs récurrentes |
| Tickets et échanges du client | Oui | Intentions fonctionnelles, historique des incidents |
| Documentation d'architecture | Rarement | Contexte de conception, généralement périmé |
L'historique Git mérite une lecture attentive. Les fichiers modifiés le plus souvent sur les douze derniers mois désignent les zones fragiles de l'application. Cette lecture coûte quelques heures et oriente tout le plan de reprise.
Quels sont les cas où la reprise coûte plus cher qu'une refonte ?
La reprise n'est pas toujours la bonne décision. Le premier critère d'arbitrage est le support du langage. Au 8 septembre 2026, seules les branches PHP 8.2, 8.3, 8.4 et 8.5 reçoivent des correctifs. Le support de la branche 8.2 s'arrête au 31 décembre 2026. Une application en PHP 7.4 ou 8.0 tourne donc sans correctif de sécurité depuis plusieurs années. Côté Node.js, la version 20 a atteint sa fin de vie le 30 avril 2026.
| Critère | Reprise viable | Refonte à envisager |
|---|---|---|
| Version du langage | Branche supportée, ou montée de version documentée | Runtime en fin de vie et framework incompatible avec les versions supportées |
| Tests automatisés | Couverture partielle sur les parcours critiques | Aucun test et aucun environnement de recette |
| Dépendances | Paquets obsolètes mais maintenus en amont | Bibliothèques abandonnées sans équivalent |
| Modèle de données | Cohérent, contraintes portées par la base | Données dupliquées, intégrité gérée uniquement côté applicatif |
Un seul critère au rouge ne justifie pas une refonte. Athenix bascule l'arbitrage vers une reconstruction quand trois critères sont au rouge simultanément. À périmètre fonctionnel égal, la maintenance devient alors plus chère que la reconstruction.
Comment engager une TMA sur une application reprise ?
La TMA démarre quand l'audit est livré et le périmètre chiffré. Athenix propose deux modèles d'engagement. Le forfait mensuel prépayé inclut un volume d'heures et couvre les correctifs comme les petites évolutions. La régie s'applique aux périmètres instables, quand le volume mensuel reste imprévisible. Le choix suit la même logique que dans notre comparaison entre régie et forfait.
Les engagements de délai portent sur la prise en compte, pas sur la résolution. Sur du code écrit par un tiers, un délai de résolution ferme est une promesse invérifiable. La grille s'applique en heures ouvrées, de 9h à 18h CET.
| Niveau | Définition | Prise en compte | Contournement ou correction |
|---|---|---|---|
| P1, bloquant | Service indisponible, perte de données, paiement hors service | 2 h ouvrées | Contournement visé sous 8 h ouvrées |
| P2, majeur | Fonction métier clé dégradée, sans contournement utilisateur | 4 h ouvrées | 2 jours ouvrés |
| P3, mineur | Anomalie avec contournement existant | 1 jour ouvré | Prochain cycle de livraison |
| P4, évolution | Demande d'évolution fonctionnelle | 2 jours ouvrés | Planifiée et chiffrée au backlog |
Ces engagements démarrent à la fin de la période de reprise. Aucun prestataire sérieux ne s'engage sur un délai de correction le jour de la signature, sur une application qu'il découvre. Le décalage horaire de Madagascar à UTC+3 place l'équipe en avance sur la France. Un ticket déposé en soirée est pris en charge le lendemain matin, avant le début de la journée du client.
Le contrat prévoit un préavis d'un mois. Pendant ce préavis, Athenix transfère le dépôt, les accès et la documentation produite pendant la mission. La réversibilité se prépare au premier jour, pas au dernier. Notre offre de maintenance applicative inclut ce transfert dans le contrat initial.
Questions fréquentes
Combien de temps faut-il pour reprendre la maintenance d'une application existante ?
Comptez 1 à 2 semaines d'audit selon la taille de l'application. Le premier correctif atteint la production après environ une semaine de travail sur le code. L'équipe atteint sa vélocité nominale entre 2 et 4 semaines après le démarrage.
Peut-on reprendre une application sans le code source ?
Le code source se récupère chez l'hébergeur dans la majorité des cas, même sans accès au dépôt Git. Sans code source ni accès serveur, la reprise devient impossible. La question se déplace alors vers une reconstruction.
Que faire si l'ancien développeur détient le nom de domaine ?
Le registrar applique une procédure de contestation de titularité, sur justificatifs de propriété de la marque ou de la société. Cette procédure n'est pas immédiate. Lancez-la avant la date d'expiration du domaine, sans attendre la fin de l'audit.
L'audit de reprise est-il facturé ?
Athenix propose l'audit au forfait ou au temps passé. Le forfait convient aux périmètres cadrés. Le temps passé convient aux applications dont le nombre d'intégrations externes reste inconnu avant ouverture.
À partir de quand la nouvelle équipe s'engage-t-elle sur des SLA ?
Les SLA prennent effet à la fin de la période de reprise, soit 3 à 6 semaines après le démarrage. Avant cette date, l'équipe traite les urgences sans engagement de délai contractuel.