↑↓ choisir · ENTER ouvrir · ESC fermer

Reprise de projet

Audit, réparation et reprise après un autre développeur

Comprendre un code inconnu, identifier les causes profondes, corriger le chemin critique et établir un plan sûr pour la suite.

En quoi consiste ce travail

Quand un projet en production est fragile, lent ou abandonné, je reproduis les problèmes et corrige les causes par ordre de priorité. Une réécriture complète n’est envisagée que si les faits la justifient.

Pour qui

  • Propriétaires d’un système qui fonctionne mais qu’il semble risqué de modifier
  • Entreprises après le départ d’un prestataire ou d’un développeur
  • Équipes qui ont besoin d’un second regard sur l’architecture et les risques

Questions réglées avant le début de la réalisation

  • Qu’est-ce qui fonctionne, et qu’est-ce qui échoue ?
  • Quels processus sont critiques pour l’activité ?
  • Que sait-on des décisions passées et de la dette technique ?
  • Quel budget est disponible pour réparer plutôt que réécrire ?

Déroulement du travail

  1. Diagnostic

    Lancer le système, examiner sa structure et reproduire les défaillances.

  2. Prioriser

    Distinguer les correctifs urgents, ce qui peut attendre et les zones à ne pas toucher.

  3. Modifier avec prudence

    Apporter des corrections ciblées et tester les processus liés.

  4. Transmettre

    Documenter ce qui a changé, ce qui reste et comment poursuivre.

Limites et règles de travail

  • Ne réécrire que si c’est réellement plus sûr et moins coûteux
  • Diagnostiquer avant de budgéter
  • Tester les changements sur des processus réels
Me contacter

Un projet à discuter ?

Commencez par ScopeMap ou décrivez ce qui se passe aujourd’hui et ce qui devrait se passer à la place. Je vous proposerai une première étape sûre.