C'est une situation plus fréquente qu'on ne l'avoue, et elle est traitée dans l'urgence et la colère, ce qui est le pire moment pour décider. La question n'est jamais « peut on sauver ce code » mais « qu'est ce qui, dans ce projet, avait vraiment de la valeur », et les deux réponses diffèrent presque toujours.
Les quatre questions, avant toute décision technique
Nous les posons dans cet ordre, et il arrive souvent que la troisième rende les autres sans objet.
Avez vous les accès ?
Code, serveur, nom de domaine, comptes. Sans eux, la question de la reprise ne se pose pas encore : il faut d'abord récupérer ce qui vous appartient, et c'est parfois un sujet juridique avant d'être technique.
Qu'est ce qui fonctionne aujourd'hui ?
Même un projet jugé raté contient presque toujours des parties qui tournent. Les identifier évite de tout jeter, ce qui est la réaction spontanée et rarement la bonne.
Le besoin d'origine est il toujours le bon ?
Un projet enlisé a souvent commencé il y a deux ans. L'entreprise a changé. Reprendre à l'identique un projet dont la raison d'être a évolué reproduit l'échec avec un autre prestataire.
Que se passe t il si vous ne faites rien pendant trois mois ?
Si la réponse est « rien de grave », vous avez le temps de décider correctement. Si c'est « on s'arrête », l'urgence dicte une solution provisoire assumée comme telle.
Reprendre, refaire, abandonner : ce qui départage
Il n'y a pas de règle générale, mais il y a des signaux fiables.
La reprise est raisonnable quand le code est lisible, que la base de données a du sens, et qu'une personne extérieure peut comprendre la logique en une journée. Le critère n'est pas l'élégance, c'est l'intelligibilité.
Refaire est plus sage quand la structure des données est fausse. Réparer une application posée sur un modèle de données incohérent coûte plus cher que de la refaire, et le résultat reste fragile.
Abandonner est parfois la bonne réponse, et personne ne la propose jamais. Si le besoin d'origine a disparu ou si un outil du marché le couvre aujourd'hui, la meilleure décision est d'arrêter et de récupérer les données.
L'audit de reprise est offert et rendu sous 48 heures. Il peut conclure qu'il faut arrêter, ce qui ne nous rapporte rien. Nous l'annonçons avant de commencer, parce que c'est ce qui rend le diagnostic croyable.
Les trois pièges de la reprise
Réécrire d'abord, comprendre ensuite. La tentation est forte et elle détruit de l'information : le code contient des décisions prises pour de bonnes raisons qui ne sont écrites nulle part. On lit avant de toucher, toujours.
Croire la documentation plutôt que le comportement. Sur un projet enlisé, la documentation décrit ce qui était prévu, pas ce qui tourne. La source de vérité est le système en production, et rien d'autre.
Refaire l'analyse avec les mêmes personnes et les mêmes réunions. Si le processus qui a produit l'échec est reconduit, le résultat le sera aussi. La reprise est le bon moment pour changer la manière de décider, pas seulement le prestataire.
Comment nous procédons
Une semaine de lecture, sans rien modifier. Nous cartographions ce qui existe, ce qui tourne, ce qui est mort, et où sont les données. Cette semaine produit un document que vous gardez, même si vous ne travaillez pas avec nous ensuite.
Puis une décision écrite, avec ses conséquences chiffrées, et un premier lot arrêtable. Nous refusons de nous engager sur une reprise complète avant d'avoir lu, et nous nous méfions de tout prestataire qui accepte de le faire.
Ce que vous récupérez, quoi qu'il arrive
Vos données, exportables dans un format ouvert. La cartographie de l'existant. Et la liste des accès à récupérer, avec qui les détient.
Ce dernier point est souvent le plus urgent et le moins traité. Un projet dont le nom de domaine est enregistré au nom d'un ancien prestataire est un projet en otage, quel que soit l'état du code.
Un projet enlisé ?
Audit de reprise offert sous 48 heures, et il peut conclure qu'il faut arrêter
Demander un audit gratuit