Reprendre un projet informatique existant : méthode, risques et premières étapes

Reprendre un projet informatique existant arrive rarement dans un contexte confortable. Le prestataire historique n’est plus disponible, un développeur clé est parti, les délais dérivent, la production devient fragile ou la direction ne sait plus exactement ce qui a été livré. Pourtant, l’application continue souvent de faire tourner une partie essentielle de l’activité.

La priorité n’est pas de promettre une refonte rapide. Elle consiste à retrouver de la maîtrise : comprendre ce qui existe, sécuriser les accès, distinguer les urgences réelles des irritants et construire un plan que l’entreprise peut financer et piloter.

Dans quels cas faut-il organiser une reprise de projet ?

Une reprise ne concerne pas seulement les projets en échec. Elle est également nécessaire quand le logiciel fonctionne encore, mais que personne ne peut expliquer sereinement comment le maintenir ou le faire évoluer.

• Le prestataire ou l’équipe d’origine ne peut plus assurer la maintenance.

• Les évolutions prennent du retard et les estimations ne sont plus fiables.

• Les incidents se répètent sans analyse durable de leurs causes.

• Le code, l’hébergement ou les comptes techniques dépendent d’une seule personne.

• La documentation ne correspond plus à la réalité de la production.

• Une modernisation est envisagée, mais le périmètre et les risques restent flous.

Ces signaux ne signifient pas nécessairement que tout est à jeter. Ils indiquent surtout que les décisions sont prises avec trop peu d’informations.

Le premier risque : commencer à modifier avant de comprendre

Sur un existant fragile, une correction apparemment locale peut casser une règle métier, une intégration ou un traitement planifié. La connaissance du système est souvent répartie entre le code, la base de données, les habitudes des utilisateurs et des scripts peu visibles.

Avant toute évolution importante, il faut donc établir une photographie exploitable. L’objectif n’est pas de documenter chaque ligne de code, mais d’identifier ce qui pourrait interrompre l’activité, perdre des données ou empêcher un retour arrière.

Les cinq vérifications à mener dès les premiers jours

1. Reprendre les accès et la propriété des actifs

L’entreprise doit savoir qui contrôle le dépôt de code, l’hébergement, les domaines, les certificats, les sauvegardes, les comptes cloud, les bases de données, les outils de déploiement et les services tiers. Les comptes nominatifs partagés et les secrets stockés dans le code doivent être recensés puis corrigés avec méthode.

2. Vérifier la production et les sauvegardes

Une sauvegarde déclarée n’est pas nécessairement restaurable. Il faut vérifier sa fréquence, sa rétention, son emplacement et tester le chemin de restauration. Les journaux, alertes et procédures d’incident montrent aussi si l’équipe peut comprendre rapidement une panne.

3. Cartographier les usages métier critiques

Les utilisateurs savent quelles opérations ne peuvent pas s’arrêter : commandes, facturation, production, interventions, stock ou échanges avec des partenaires. Cette cartographie permet de relier les composants techniques à leur impact réel et d’éviter un audit uniquement centré sur le code.

4. Évaluer la capacité à livrer

Il faut reconstruire l’application, exécuter les tests disponibles et comprendre comment une version passe du poste d’un développeur à la production. Un projet impossible à compiler ou à déployer de manière reproductible doit être stabilisé avant d’engager une évolution ambitieuse.

5. Clarifier le périmètre contractuel et humain

La propriété intellectuelle, les licences, les engagements de support, les dépendances externes et les responsabilités doivent être explicites. Une reprise réussie dépend aussi de la disponibilité des utilisateurs clés et de la qualité du transfert avec l’ancienne équipe.

Quels livrables attendre d’un audit de reprise ?

Un audit utile ne se termine pas par une longue liste d’anomalies. Il doit aider la direction à décider et l’équipe à agir.

• Une cartographie simple de l’application, de ses données et de ses intégrations.

• Un registre des risques classés par impact métier et probabilité.

• La liste des accès manquants, dépendances critiques et actions de sécurisation.

• Un diagnostic de maintenabilité : construction, tests, déploiement, supervision et documentation.

• Une feuille de route priorisée avec coûts, dépendances et critères de réussite.

Un plan réaliste pour les 30, 60 et 90 premiers jours

1. Jours 1 à 30 : reprendre les accès, sécuriser les sauvegardes, rendre le build reproductible, observer la production et traiter les risques immédiats.

2. Jours 31 à 60 : documenter les flux critiques, ajouter les tests les plus utiles, corriger les incidents récurrents et fiabiliser le déploiement.

3. Jours 61 à 90 : livrer un premier lot métier visible et arbitrer la trajectoire entre maintien, modernisation progressive et remplacement ciblé.

Ce découpage doit s’adapter au niveau d’urgence. Il évite néanmoins deux extrêmes fréquents : passer des mois à auditer sans livrer, ou lancer une refonte avant d’avoir sécurisé l’exploitation.

Faut-il conserver, moderniser ou réécrire ?

La décision se prend composant par composant. Une partie stable, bien comprise et rarement modifiée peut rester en place. Un module qui concentre les incidents peut être isolé puis remplacé. Une interface peut être modernisée sans migrer immédiatement toute la base de données.

La réécriture complète devient pertinente lorsque l’architecture empêche réellement toute évolution, que les technologies ne sont plus exploitables ou que le métier a profondément changé. Même dans ce cas, une bascule progressive réduit généralement le risque. Pour approfondir cet arbitrage, consultez notre méthode de migration d’application legacy.

Les erreurs fréquentes lors d’une reprise

• Dévaloriser l’ancien système avant d’avoir compris les règles métier qu’il contient.

• Promettre un délai ou un budget définitif après une lecture superficielle du dépôt.

• Changer simultanément l’équipe, l’architecture, l’hébergement et les fonctionnalités.

• Reporter les sujets de sauvegarde, sécurité et supervision après les nouveautés.

• Ne parler qu’aux décideurs et ignorer les utilisateurs qui connaissent les cas limites.

Reprendre le contrôle sans repartir de zéro

Une bonne reprise produit rapidement deux résultats : moins de risque immédiat et davantage de visibilité sur la suite. Elle ne masque pas les difficultés, mais les transforme en décisions ordonnées et compréhensibles.

Kodeva accompagne les PME et éditeurs pour auditer un existant, sécuriser la transition et remettre le projet en mouvement. Découvrez notre approche de la reprise de projet informatique ou contactez-nous pour cadrer un premier diagnostic.