Comment reprendre une application développée par un autre prestataire

Une reprise d’application est d’abord un problème de connaissance, ensuite seulement un problème de code. Le système produit déjà de la valeur, mais plus personne ne sait exactement comment ni pourquoi. Tant que cette connaissance n’est pas reconstituée, toute estimation de durée ou de coût reste une estimation de devinette.

Pourquoi une reprise devient critique

Les situations qui déclenchent une reprise se ressemblent : la personne qui connaît le système n’est plus joignable, les accès sont dispersés, la documentation n’a jamais existé ou a été perdue, et les versions utilisées ne sont plus maintenues.

Le symptôme le plus coûteux n’est pas la panne. C’est l’impossibilité de décider. Sans savoir quelles zones sont risquées, on ne peut pas arbitrer entre une correction de deux heures et une reprise de six mois. Les décisions sont donc repoussées, et la dette technique continue de croître en arrière-plan.

Ce qu’il faut sécuriser avant toute intervention

Modifier une application dont on ne maîtrise pas l’état est le meilleur moyen de perdre la seule version qui fonctionne. Cette phase ne produit rien de visible, et c’est pourtant elle qui rend la suite possible.

1. Une sauvegarde vérifiée. Elle doit exister, être récente, et sa restauration doit avoir été testée au moins une fois. Une sauvegarde jamais restaurée n’est pas une sauvegarde.
2. Les accès à jour. Dépôts, serveur, base de données, DNS, hébergeur, CDN et outil de suivi. Les identifiants qui fonctionnaient il y a deux ans sont souvent le premier obstacle réel.
3. Un dépôt Git propre. Tout le code accessible, un seul point de vérité, des branches identifiables. Si le code vit dans un dossier partagé ou sur un poste, c’est le premier chantier.
4. Une copie de la production. Un environnement reproductible, capable de reproduire un incident sans toucher au service réel.
5. Les journaux. Logs applicatifs, logs serveur et journaux d’accès des dernières semaines : ils racontent souvent ce que le code ne dit pas.

Reconstituer la carte de l’application

Une cartographie utile répond à des questions concrètes. Elle n’a pas besoin d’être exhaustive pour être opérationnelle, mais elle doit permettre de savoir par où commencer.

La méthode la plus rapide consiste à croiser trois sources : le code, les journaux de production et les usages réels. Une zone d’activité peut être invisible dans le code et très visible dans les logs. L’écart entre ces sources révèle précisément les parties que personne ne maintient plus.

Évaluer la dette technique sans exagérer

La dette technique est souvent présentée comme une note globale, ce qui n’aide à rien. Ce qui aide, c’est de distinguer une dette qui coûte cher maintenant d’une dette qui coûtera cher plus tard.

• Dette bloquante : l’application ne peut plus évoluer en sécurité sur un sujet donné, parce que personne ne sait comment le faire. C’est la seule catégorie qui justifie une priorité immédiate.
• Dette risquée : le code fonctionne, mais une dépendance non maintenue ou une version obsolète peut casser la production lors d’une mise à jour de sécurité. Elle se traite de façon planifiée.
• Dette de confort : le code est imparfait mais lisible et stable. Elle n’a aucune urgence, et la réécriture n’y apporte généralement aucun gain mesurable.

La plupart des situations qui me sont présentées ne relèvent pas de la première catégorie. Elles relèvent d’un mélange de risque et de confort, ce qui se traite très bien par étapes, sans interrompre la production.

Stabiliser avant d’accélérer

Une fois la carte établie, on ne répare pas tout. On traite d’abord ce qui menace la continuité, avec un moyen de retour arrière pour chaque changement.

1. Corriger les failles de sécurité ouvertes et les dépendances critiques abandonnées.
2. Réparer ce qui produit des erreurs en production, en commençant par les plus fréquentes.
3. Réduire la surface de rupture : des petits changements fréquents plutôt que des livraisons regroupées.
4. Documenter au passage. Chaque zone traitée devient une zone que l’entreprise peut maintenir seule.

Réécrire ou moderniser : les critères de décision

La réécriture complète est régulièrement proposée parce qu’elle est plus facile à vendre qu’un diagnostic. Elle n’est pourtant justifiée que dans un petit nombre de situations.

Erreurs qui coûtent cher

• Démarrer la reprise sans une sauvegarde restaurée et testée.
• Refondre l’interface avant d’avoir stabilisé les données et les flux.
• Confondre dette technique et manque de fonctionnalités : ce sont deux chantiers distincts.
• Remettre la documentation à plus tard, en considérant qu’elle viendra une fois le code stabilisé.
• Accepter une estimation de charge avant d’avoir vu l’existant.

Comment se déroule une reprise réussie

Une reprise bien menée avance par niveaux de confiance. Chaque étape produit un document ou une capacité que l’entreprise conserve, même si l’intervenant change.

Accès et sauvegardes vérifiés
        ↓
Code remis dans un dépôt exploitable
        ↓
Carte de l'application : code, données, flux, intégrations
        ↓
Stabilisation des risques immédiats : sécurité, incidents
        ↓
Feuille de route : maintien, refactorisation, migration
        ↓
Maintenance et documentation transmises

Quand faire appel à un spécialiste

Il est pertinent d’intervenir rapidement lorsque l’un de ces signaux est présent :

• Les accès critiques ne sont plus maîtrisés par l’entreprise.
• La production subit des incidents que personne ne sait expliquer ni reproduire.
• Une évolution prévue doit être réalisée sans savoir si elle est réalisable.
• Le prestataire actuel ne peut plus garantir la continuité du projet.
• Une reprise est envisagée et personne ne sait dire ce que l’application fait réellement.

L’objectif d’un diagnostic n’est pas de produire un rapport volumineux, mais de répondre à une question précise : qu’est-ce qui bloque, et par quoi commencer. Pour la partie Laravel du sujet, le guide d’audit d’application Laravel existante détaille la lecture du code, des requêtes et de la production.

• Reprise d’application
• Dette technique
• Audit