Le système tourne toujours. Plus personne ne sait comment.

Ce qui est urgent n'est pas ce qui est intéressant

Le réflexe naturel consiste à chercher à comprendre le système : ce qu'il fait, comment il est construit, s'il est récupérable. C'est le travail long, et ce n'est pas le travail urgent.

Le travail urgent consiste à s'assurer que vous ne perdrez pas l'accès. Comprendre un système prend des semaines et peut attendre. Perdre un nom de domaine, un compte d'hébergement ou une base de données prend une nuit, et parfois une seule échéance de paiement non honorée sur une carte bancaire expirée.

Les trois premières étapes ci-dessous se font dans la semaine. Les suivantes peuvent prendre le temps qu'il faut.

Étape 1 : établir ce que vous détenez réellement

Faites la liste par écrit, et vérifiez chaque ligne au lieu de la supposer. C'est ici que se découvrent les mauvaises surprises, et il vaut mieux les découvrir maintenant.

1. 01Le code source : où il se trouve, qui y a accès, et s'il existe ailleurs que sur le poste de quelqu'un.
2. 02L'hébergement : au nom de quelle personne ou de quelle société, payé par quel moyen, et jusqu'à quand.
3. 03Les noms de domaine : chez quel registrar, au nom de qui, avec quelle date d'expiration.
4. 04La base de données : où elle est, comment on s'y connecte, et s'il existe une sauvegarde qui a déjà été restaurée avec succès.
5. 05Les comptes de service tiers : messagerie, paiement, cartographie, envoi de documents, et à quelle adresse ils sont rattachés.
6. 06La documentation, s'il y en a, y compris sous forme de courriels et de comptes rendus.

Le point de blocage le plus fréquent n'est pas le code : c'est un compte au nom d'une personne partie, rattaché à une adresse électronique désactivée, dont la récupération demande un dialogue avec un support et parfois des justificatifs de société.

Commencez par celui-là, car c'est celui qui prend du temps calendaire et non du temps de travail.

Étape 2 : sauvegarder avant de comprendre

Une copie complète de la base de données et du code, sortie du système d'origine et déposée dans un endroit que vous contrôlez. C'est la seule action réellement urgente de toute cette démarche.

Deux précisions qui font la différence entre une sauvegarde et une illusion de sauvegarde. Une copie qui n'a jamais été restaurée n'est pas une sauvegarde : il faut vérifier au moins une fois qu'elle se relit. Et une copie qui vit sur le même hébergement que le système disparaîtra avec lui.

Cette étape ne demande pas de comprendre quoi que ce soit au fonctionnement de l'application. Elle peut être faite par un prestataire technique en quelques heures, sans engagement sur la suite.

Si vous ne deviez retenir qu'une seule chose de cette page : faites cette copie cette semaine, avant de décider quoi que ce soit d'autre.

Étape 3 : établir ce que le système fait encore tout seul

Un système abandonné n'est pas un système à l'arrêt. Il continue d'agir, et c'est ce qui le rend risqué.

Cherchez précisément ce qui sort vers l'extérieur sans qu'un humain le déclenche : des messages envoyés à vos clients, des factures ou relances émises, des commandes transmises à des fournisseurs, des données poussées vers un autre système, des paiements prélevés, des fichiers déposés quelque part.

Ce qui sort vers l'extérieur sans surveillance est votre premier sujet, avant même la question de savoir si le système est récupérable. Un traitement automatique qui se met à échouer silencieusement, ou pire à réussir avec des données fausses, produit des conséquences chez vos clients et vos fournisseurs avant de produire un signe chez vous.

Listez aussi les utilisateurs réels : qui ouvre encore l'outil, pour quelle tâche, et ce qu'ils feraient s'il s'arrêtait demain matin. La réponse est souvent plus courte, ou beaucoup plus longue, que ce que la direction imagine.

Étape 4 : évaluer si la reprise est raisonnable

Trois questions, et le critère de décision n'est pas celui qu'on croit.

1. 01Le code est-il lisible par quelqu'un d'autre que son auteur ? On le sait en faisant regarder deux ou trois fonctions centrales par un développeur extérieur, en une demi-journée.
2. 02Les données sont-elles saines ? Structure cohérente, doublons maîtrisés, historique conservé, champs qui veulent dire ce que leur nom indique.
3. 03Les règles métier sont-elles retrouvables ? Dans le code, dans une documentation, ou dans la tête de quelqu'un qui travaille encore chez vous.

Le critère de décision n'est pas la qualité du code. C'est la valeur des données et la clarté des règles.

Du code médiocre au-dessus de données saines et de règles connues se remplace tranquillement, morceau par morceau, sans interrompre l'activité. Du beau code au-dessus de données douteuses et de règles que plus personne ne sait énoncer est un piège, parce que vous ne saurez jamais si le remplacement produit le même résultat que l'original.

Ce qui coûte cher dans une reprise n'est jamais la réécriture. C'est la découverte : reconstituer ce que le système fait et pourquoi. Ce travail est à faire quelle que soit la décision, ce qui est une raison de plus de ne pas la précipiter.

Étape 5 : reprendre, entourer, ou remplacer

Trois issues, et elles ne se choisissent pas au même endroit du raisonnement.

Reprendre convient quand le code est abordable et les règles retrouvables. On stabilise, on documente, on remet en état ce qui doit l'être, et on repart de là. C'est la voie la moins spectaculaire et souvent la moins chère.

Entourer consiste à laisser le système en place pour ce qu'il fait correctement, et à construire autour de lui la couche qui manque : les contrôles, la consolidation, ce qui doit être ajouté. On ne touche pas au cœur, on l'encadre. C'est la bonne réponse quand le système fonctionne mais qu'il est illisible, et elle permet de le remplacer plus tard, sans urgence.

Remplacer s'impose quand les données sont saines mais que le système ne peut plus évoluer, ou quand personne ne peut plus expliquer ce qu'il fait. La condition préalable est d'avoir écrit les règles avant de commencer, sans quoi vous rejouerez exactement l'échec précédent.

Ce qu'il faut exiger pour ne pas y revenir

La situation que vous vivez a une cause simple, et elle n'est pas le départ du prestataire : c'est que rien n'avait été prévu pour ce départ. Quatre éléments l'évitent, et ils se demandent au moment du contrat, jamais après.

1. 01Le code source livré chez vous en continu, dans un dépôt dont vous êtes propriétaire, et pas seulement à la fin.
2. 02Les accès critiques à votre nom : hébergement, domaines, base, comptes de service, dès le premier jour.
3. 03Une documentation d'exploitation qui dit comment on démarre, arrête, sauvegarde et restaure, écrite pour quelqu'un qui découvre.
4. 04Ce qui se passe précisément si la relation s'arrête, écrit dans le contrat plutôt que promis en réunion.

Ces quatre points ne coûtent presque rien à mettre en place au début, et ils déterminent entièrement ce que vous vivez le jour où quelqu'un s'en va. Nous les intégrons à nos projets pour cette raison, et nous les écrivons au contrat, parce qu'un engagement énoncé ailleurs n'a pas de valeur.