Reprendre le RUN d'une application qu'on n'a pas écrite

On nous appelle souvent dans la même situation : le prestataire historique n’est plus là, ne répond plus, ou a été remercié. L’application tourne, elle est critique, et personne ne sait plus comment elle fonctionne.

C’est un exercice que nous pratiquons régulièrement, et il a une règle d’or : ne jamais s’engager sur un délai de rétablissement avant d’avoir prouvé qu’on sait déployer.

Le seul critère qui décide vraiment

Avant de parler de qualité de code, d’architecture ou de dette, une seule question compte : combien de temps nous faut-il pour corriger une virgule et la mettre en production ?

Si la réponse est « une journée », tout le reste est négociable. Le code peut être laid, la dette importante, l’architecture discutable : nous pouvons nous engager, et améliorer progressivement.

Si la réponse est « nous ne savons pas », aucun engagement de service n’est tenable — quelle que soit la beauté du code. J’ai vu des applications impeccablement écrites qu’on ne pouvait pas déployer parce que la procédure vivait dans la tête de quelqu’un qui était parti.

Photo : Lenharth Systems — licence CC0.

Les cinq étapes de l’audit

1. Reconstruire l’application depuis zéro

Sur une machine vierge, à partir du dépôt et de la documentation fournis, sans aide de personne. C’est le test le plus dur et le plus révélateur.

Ce qu’on découvre régulièrement : des fichiers de configuration absents du dépôt, une variable d’environnement non documentée, une dépendance installée à la main sur le serveur en 2022, un certificat généré une fois et jamais reproduit.

Tant que ce test échoue, tout le reste est théorique.

2. Déployer en préproduction

Reconstruire ne suffit pas : il faut mettre en ligne. Cela suppose des accès, un environnement comparable à la production, et une procédure reproductible.

C’est aussi le moment où l’on découvre s’il existe une préproduction. Quand la réponse est non, le premier chantier est identifié : on ne corrige pas en aveugle une application critique.

3. Inventorier les dépendances et les failles connues

Quelles bibliothèques, quelles versions, lesquelles ne sont plus maintenues, lesquelles portent des vulnérabilités publiées. Cet inventaire s’automatise et prend quelques heures.

Le résultat détermine l’urgence. Une application dont le socle n’a pas été mis à jour depuis trois ans demande un chantier de remise à niveau avant toute évolution fonctionnelle — et ce chantier doit être budgété séparément, sinon il ne sera jamais fait.

4. Mesurer la couverture de tests réelle

Pas le pourcentage affiché : ce qui est réellement couvert sur les chemins critiques. Une couverture de 70 % concentrée sur les fonctions utilitaires ne protège de rien.

Cette mesure conditionne la vitesse à laquelle nous pourrons intervenir. Sans filet, chaque modification demande une recette manuelle — donc des délais plus longs et des engagements plus prudents.

5. Alors seulement, s’engager

Avec des délais fondés sur ce que nous avons mesuré, et non sur ce que le client espère entendre. Un engagement pris sans les quatre étapes précédentes est une promesse, pas un engagement.

Les cinq signaux qui nous font refuser

Nous déclinons rarement, mais il y a des cas.

Aucun accès au code source. Cela paraît absurde et arrive : le prestataire précédent ne l’a jamais cédé. Sans droits d’exploitation, il n’y a pas de reprise possible — il y a un sujet juridique à traiter d’abord.

Une base de données sans schéma explicite. Quand les contraintes d’intégrité n’existent que dans le code applicatif, on ne peut pas garantir la cohérence après intervention. C’est réparable, mais cela doit être annoncé comme un chantier, pas comme de la maintenance.

Des données de production dans les environnements de test. Le sujet est réglementaire avant d’être technique. Nous demandons que ce soit traité avant de commencer.

Une application dont l’auteur affirme qu’elle « ne doit surtout pas être redémarrée ». Cela signifie qu’un état non reproductible vit en mémoire ou sur le disque du serveur. C’est une bombe à retardement, et le premier chantier consiste à la désamorcer.

Un client qui refuse l’audit. « Prenez la maintenance, on verra bien. » C’est compréhensible — l’audit a un coût et paraît redondant. Mais s’engager sans savoir revient à vendre une assurance sans connaître le risque. Nous ne le faisons pas.

Photo : The World is a Stage — licence CC0.

Photo : domaine public (CC0).

Les trente premiers jours

Une fois la reprise décidée, l’ordre du premier mois compte plus que le contenu, parce qu’il détermine ce qu’on saura faire en cas d’incident.

Semaine 1 — reprendre la main sur les accès. Serveurs, base de données, noms de domaine, certificats, comptes des services tiers, dépôt de code. Tant qu’un accès manque, on ne peut rien garantir. C’est aussi l’étape où l’on découvre le plus souvent qu’un élément critique appartient encore à un prestataire précédent ou à un ancien salarié.

Semaine 2 — vérifier les sauvegardes en restaurant. Pas en lisant la documentation : en restaurant réellement sur un environnement séparé et en vérifiant que l’application démarre dessus. C’est le test le plus révélateur qui existe, et il échoue plus souvent qu’on ne l’imagine.

Semaine 3 — installer une supervision minimale. Disponibilité, erreurs, temps de réponse, espace disque, expiration des certificats. Cinq mesures suffisent à ne plus apprendre les incidents par les utilisateurs.

Semaine 4 — reconstruire l’environnement à partir de zéro. C’est l’épreuve de vérité : si l’on sait remonter l’application sur un serveur neuf, on saura la sauver. Sinon, on a identifié exactement ce qui manque, et c’est le premier chantier.

Ce que nous demandons au client, de son côté

Une reprise n’est pas un transfert à sens unique, et deux éléments doivent venir du client.

Un interlocuteur métier disponible. Le code dit ce que l’application fait, jamais pourquoi. Une règle de calcul incompréhensible a toujours une raison, et cette raison vit dans la tête de quelqu’un. Sans cet interlocuteur, on répare à l’aveugle.

Une liste ordonnée de ce qui est critique. Toutes les fonctions n’ont pas le même poids. Si l’application tombe un samedi matin, il faut savoir ce qu’on remet en service en premier — et cette décision appartient au métier, pas à nous.

Ce que la reprise apporte, au-delà du dépannage

Un audit de reprise produit un effet secondaire souvent plus précieux que la maintenance elle-même : il rend l’application compréhensible à nouveau.

À la fin, le client dispose d’une procédure de reconstruction, d’un inventaire de dépendances, d’une cartographie des chemins critiques et d’un état des lieux honnête de la dette. Ces documents lui appartiennent.

Concrètement, cela veut dire qu’il n’est plus captif — de nous compris. C’est exactement la situation dans laquelle un client devrait toujours se trouver, et c’est ce qui nous oblige à rester bons.