Reprise de projet informatique bloqué

Un projet informatique bloqué n’a pas toujours besoin d’être réécrit. Il a d’abord besoin d’une carte fiable : ce qui fonctionne, ce qui manque, qui possède les accès et pourquoi plus personne ne livre.

Nous reprenons des logiciels déjà engagés lorsque l’équipe historique est partie, que le prestataire ne répond plus, que la production est fragile ou que le métier a perdu confiance.

Les situations dans lesquelles nous intervenons

• Les mises en production sont arrêtées ou imprévisibles
• Le développeur principal ou le prestataire historique est parti
• La documentation est absente ou ne correspond plus au système
• Les incidents reviennent sans analyse de cause
• Le code existe, mais personne ne sait quelle version tourne
• Une réécriture totale est proposée sans diagnostic préalable
• La direction ne peut plus expliquer le coût ni le calendrier

Notre méthode de reprise

1. Geler sans paralyser

Nous séparons les urgences réelles des nouvelles demandes. L’objectif est d’éviter que le périmètre continue à bouger pendant que l’équipe cherche la cause du blocage.

2. Récupérer les éléments contrôlables

Dépôts de code, DNS, cloud, base de données, sauvegardes, secrets, licences, pipeline et comptes techniques. Nous ne contournons aucun accès. Si un élément manque, il entre explicitement dans le plan de récupération.

3. Cartographier le système réel

Nous identifions les composants actifs, les dépendances, les environnements et les parcours métier utilisés. La carte doit être lisible par la direction comme par la future équipe technique.

4. Sécuriser le minimum vital

Comptes partagés, secrets exposés, sauvegardes non vérifiées et droits trop larges passent avant une nouvelle fonctionnalité. Pour un dossier sensible, un accord de confidentialité peut être signé avant les accès.

5. Rétablir un chemin de test et de livraison

Nous choisissons un parcours métier important, posons le filet de tests nécessaire et remettons en place une recette, un déploiement reproductible et un retour arrière.

6. Livrer avant de moderniser

Un premier résultat visible permet de vérifier que la reprise fonctionne. Les migrations et changements d’architecture viennent ensuite, uniquement lorsqu’ils répondent à un risque ou à un coût démontré.

Ce que vous recevez

• Une cartographie du code, des environnements, des données et des accès
• Les risques classés par impact et urgence
• Les actions immédiates de sécurisation
• Un plan de reprise sur 90 jours
• Une estimation du coût de remise en production et du run
• Une recommandation : corriger, reprendre progressivement, remplacer ou arrêter
• Une documentation utilisable par l’équipe qui prendra la suite

Et si la documentation n’existe plus ?

Nous repartons du réel : dépôt, journaux, base, infrastructure et échanges avec les utilisateurs. L’absence de documentation ralentit le travail, mais elle ne rend pas la reprise impossible. La documentation reconstruite fait partie du livrable.

Et si le prestataire actuel ne coopère pas ?

Nous inventorions d’abord ce que votre organisation possède déjà. Les contrats, comptes cloud, noms de domaine et sauvegardes permettent souvent de distinguer un problème d’accès d’un problème de code. Les éléments qui exigent une action juridique ou contractuelle sont signalés ; ils ne sont jamais contournés techniquement.

Faut-il tout réécrire ?

Pas par défaut. Une réécriture complète ajoute un second projet au projet déjà bloqué : migration des données, coexistence, recette et bascule. Elle devient pertinente lorsque la base ne peut plus être sécurisée, que sa technologie n’est plus maintenue ou que chaque modification coûte davantage qu’un remplacement progressif.

Délai et prix

La première étape est le diagnostic IT. La plupart de nos diagnostics restent sous 2 000 €. Après un premier échange, nous annonçons le périmètre, les accès nécessaires, le forfait et la durée. Une application isolée n’exige pas le même travail qu’un SI composé de plusieurs applications.

La mission de reprise est chiffrée séparément. Elle peut s’arrêter après le retour en production, se poursuivre par un transfert à votre équipe ou devenir une TMA lisible.

Consultez également notre cas de plateforme métier remise en production et le guide sur l’audit d’un projet informatique.