On peut reprendre une application sans documentation. Ce qui bloque vraiment une reprise, c'est l'absence d'accès au code, à l'hébergement ou à la base de données. Tout le reste se reconstruit, à condition d'accepter une méthode et un peu de temps : c'est le premier chantier de toute reprise de maintenance applicative.
Pourquoi la documentation manque presque toujours, et pourquoi ce n'est pas bloquant
Lors de la reprise de l'application métier de Fit Doors, le point de départ était un code qui ne démarrait pas, sans aucun test, avec des failles ouvertes. C'est un cas extrême, mais le dossier technique d'une application reprise tient rarement sur plus d'une page, quand il existe. La documentation est la première chose sacrifiée quand le budget se tend, et la première chose à devenir fausse quand le logiciel évolue. Un document de conception rédigé en 2022 décrit rarement l'application telle qu'elle tourne en 2026.
Le logiciel lui-même contient l'information qui manque. Le code dit ce que l'application fait. L'infrastructure dit ce qui tourne réellement. Les journaux disent ce qui se passe au quotidien. Les utilisateurs disent pourquoi. La rétro-documentation consiste à lire ces quatre sources dans l'ordre et à écrire ce qu'on y trouve.
Prenons un exemple type : un logiciel de gestion des devis développé sur mesure par un indépendant. Le développeur a cessé de répondre, aucun document n'existe, et l'équipe commerciale vit avec un bug de calcul de remise qu'elle corrige à la main sur chaque devis. Si le dépôt de code et l'accès au serveur sont disponibles, la reprise est possible. Si le code n'a jamais quitté le portable du développeur, il faudra reconstruire l'application.
Les quatre accès sans lesquels aucune reprise n'est possible
Avant de parler méthode, il faut sécuriser quatre choses. Sans elles, aucun mainteneur sérieux ne s'engagera.
- Le code source, idéalement dans un dépôt Git avec son historique. Une archive sans historique reste acceptable, mais on perd la chronologie des changements.
- L'hébergement : accès administrateur au serveur, au compte cloud ou à la plateforme d'hébergement, avec la main sur le nom de domaine et les certificats.
- La base de données : identifiants, emplacement des sauvegardes, et le droit de faire une copie complète.
- Les comptes tiers : services d'envoi d'e-mails, paiement, cartographie, signature électronique, API de modèles IA, stockage de fichiers. Chacun de ces comptes porte une clé, une facture et parfois une date d'expiration.
Le point le plus souvent oublié est le dernier. Cas fréquent : une application de gestion d'interventions dont les SMS aux techniciens passent par un compte au nom personnel de l'ancien prestataire. Le compte finit fermé pour impayé après la fin de la relation, et les SMS cessent un vendredi soir. La liste des comptes tiers fait donc partie du premier livrable, avant même la lecture du code.
Si l'un de ces quatre éléments manque, il faut le récupérer avant tout. Un courrier au prestataire précédent, en rappelant que le contrat prévoit la remise du code et des accès, suffit dans la plupart des cas. Le sujet de la propriété du code se règle mieux en amont, comme nous l'expliquons dans notre article sur le risque de dépendre d'un seul développeur.
Lire le code comme un plan, module par module
Une fois le dépôt en main, le mainteneur ne lit pas le code ligne à ligne. Il le cartographie. L'objectif est d'obtenir rapidement une vue d'ensemble : quels sont les grands modules, comment les données circulent entre eux, et de quoi l'application dépend.
Cela passe par trois lectures successives.
La structure. L'arborescence du projet, les fichiers de configuration, le fichier de dépendances (package.json, requirements.txt, composer.json ou équivalent). On y apprend le langage, le framework, la version, et l'âge des bibliothèques utilisées. Une bibliothèque abandonnée depuis trois ans est une dette à inscrire immédiatement.
Les points d'entrée. Les routes de l'application, les tâches planifiées, les écouteurs d'événements, les points d'API exposés à d'autres systèmes. On les liste tous, on note ce que chacun déclenche.
Le modèle de données. Le schéma de la base, les tables, les relations. C'est le squelette de l'application. Un mainteneur qui comprend le modèle de données comprend l'essentiel du métier sans avoir lu une seule règle de gestion.
L'historique Git, quand il existe, complète cette lecture. Les messages de commit racontent l'histoire de l'application : les urgences, les correctifs de dernière minute, les fonctionnalités ajoutées puis abandonnées.
À la fin de cette étape, le livrable est un schéma d'architecture d'une page et une liste des dépendances avec leur état de maintenance. Ce document est la base de tout le reste, et c'est aussi ce que nous produisons lors d'un audit de dette technique quand la question est de savoir s'il faut reprendre ou refaire.
Ce que l'infrastructure et les journaux révèlent vraiment
Le code dit ce que l'application peut faire. L'infrastructure dit ce qu'elle fait vraiment. Les deux ne coïncident jamais tout à fait.
Sur le serveur, on trouve les processus qui tournent, les tâches planifiées, les variables d'environnement, les scripts de déploiement quand il y en a, et surtout les choses que personne n'a documentées parce qu'elles ont été faites à la main un soir de mise en production.
Les journaux applicatifs et les journaux du serveur web sont la source la plus honnête. Leur analyse permet de savoir :
- quelles fonctionnalités sont utilisées et à quelle fréquence, ce qui permet d'ignorer les modules morts ;
- quelles erreurs se produisent régulièrement sans que personne ne les signale, parce que les utilisateurs ont appris à contourner ;
- quels appels à des services tiers échouent, et depuis quand ;
- quelles requêtes en base sont lentes et dégradent l'expérience aux heures de pointe.
Sur un logiciel de gestion des devis comme celui décrit plus haut, les journaux peuvent montrer qu'une tâche nocturne de synchronisation avec le logiciel de comptabilité échoue une nuit sur trois. La comptable relance alors la synchronisation à la main chaque matin sans le dire à personne. Les journaux le révèlent.
C'est aussi à cette étape que la supervision est mise en place. Un mainteneur qui reprend une application commence par mettre en place une supervision continue de la disponibilité, des erreurs, des temps de réponse, de l'espace disque et de l'expiration des certificats. À partir de là, les incidents sont détectés avant que les utilisateurs ne les signalent, et chaque nouvel incident enrichit la documentation.
Reconstituer les règles métier avec les utilisateurs, pas seulement avec le code
Le code contient les règles métier, mais il ne dit pas pourquoi elles existent. Une condition qui applique une remise de 3 % aux clients dont le code commence par « GR » a une raison. Elle est peut-être toujours valable. Elle est peut-être le vestige d'un accord commercial terminé en 2021. Seul un humain peut le dire.
La rétro-documentation inclut donc des entretiens courts avec les personnes qui utilisent l'application au quotidien. Pas les managers, les utilisateurs. On leur montre la cartographie des fonctionnalités, on leur demande ce qu'ils font chaque jour, chaque semaine, chaque fin de mois, et surtout ce qu'ils contournent.
Ces entretiens font remonter trois types d'informations que le code ne contient pas :
- les usages détournés, quand un champ prévu pour une chose sert à autre chose depuis des années ;
- les procédures manuelles qui compensent une fonctionnalité manquante ou cassée ;
- les périodes critiques, comme la clôture mensuelle ou la période de forte activité, pendant lesquelles aucune intervention ne doit avoir lieu.
Sur un portail de planification, un entretien avec la responsable d'agence peut révéler qu'un bouton « recalculer » est cliqué deux fois de suite par tout le monde, parce que le premier clic ne prend jamais en compte les absences. Connu de tous, documenté nulle part, ce comportement explique un pic de charge que les journaux montrent sans l'expliquer.
Écrire le manuel d'exploitation de l'application
Le manuel d'exploitation, que les équipes techniques appellent runbook, est le document opérationnel. Il ne décrit pas l'application, il décrit comment on la fait vivre. Il doit permettre à un ingénieur compétent qui n'a jamais vu le projet d'intervenir en autonomie.
Un runbook complet couvre au minimum :
- Démarrer : comment lancer l'application sur un poste de développement, avec quelles versions, quelles variables, quel jeu de données de test.
- Déployer : la procédure de mise en production, étape par étape, avec les vérifications avant et après, et la procédure de retour arrière si quelque chose se passe mal.
- Sauvegarder : ce qui est sauvegardé, où, à quelle fréquence, combien de temps c'est conservé, et comment vérifier que la sauvegarde est exploitable.
- Restaurer : la procédure complète de remise en service à partir d'une sauvegarde, testée au moins une fois. Tant qu'une sauvegarde n'a pas été restaurée au moins une fois, rien ne prouve qu'elle fonctionne.
- Diagnostiquer : où sont les journaux, quels sont les incidents connus et leur résolution, qui contacter chez les fournisseurs tiers.
Le runbook vit dans le dépôt de code, à côté de l'application, et il est mis à jour à chaque intervention. Un runbook que personne ne relit se périme aussi vite que la documentation initiale.
Les zones d'ombre à assumer et comment on les traite dans le contrat
Une rétro-documentation honnête laisse des zones d'ombre. Un module que personne n'utilise mais qu'on n'ose pas supprimer. Une intégration avec un service tiers dont le contrat a été signé par quelqu'un qui n'est plus là. Une fonctionnalité qui marche sans que personne ne comprenne pourquoi.
Il faut les écrire noir sur blanc plutôt que de faire semblant de tout maîtriser. Le livrable de fin de reprise contient une liste des points non élucidés, classés par risque : ce qui peut casser sans prévenir, ce qui coûte de l'argent chaque mois sans justification, ce qui pose un problème juridique potentiel.
Cette liste alimente directement le contrat de maintenance. Un mainteneur s'engage sur ce qu'il connaît. Sur les zones d'ombre, il s'engage à investiguer dans un délai convenu, pas à réparer dans l'heure. Les engagements de réactivité et de résolution sont écrits, définis au contrat une fois l'audit terminé, et ils distinguent le périmètre maîtrisé du périmètre à risque.
C'est le cadre dans lequel nous proposons la reprise de maintenance applicative : un audit de reprise applicative qui produit la cartographie, le runbook et la liste des zones d'ombre, puis un contrat dont le périmètre et les engagements découlent de ce qui a été trouvé, pas d'une grille générique.
Ce que change une documentation reproductible pour une équipe support sans développeur
Beaucoup de PME et d'ETI ont une équipe support ou un responsable informatique compétent, mais pas de développeur. La rétro-documentation change ce que cette équipe peut faire seule.
Avec un runbook testé, le support interne peut redémarrer un service, vérifier une sauvegarde, lire un journal d'erreur et qualifier un incident avant d'appeler le mainteneur. Il distingue une panne d'hébergement d'un bug applicatif, et les sollicitations urgentes qui restent arrivent avec les bonnes informations.
Pour le dirigeant, le bénéfice est d'un autre ordre. L'application cesse d'être une boîte noire dont dépend une équipe. Elle devient un actif documenté, transférable, dont on connaît les dépendances, les coûts récurrents et les risques. Le code, les accès et la documentation restent chez l'entreprise, ce qui rend le rapport de force avec n'importe quel prestataire beaucoup plus sain.
C'est aussi ce qui rend possible une maintenance applicative qui couvre les briques d'intelligence artificielle, avec ce qu'il faut surveiller après la mise en production d'une IA : un agent ou un modèle intégré à une application métier ne se maintient pas sans savoir précisément d'où viennent ses données, comment il est appelé et ce qu'il coûte à chaque appel. La rétro-documentation est le préalable.
Reprendre une application sans documentation demande un travail de lecture méthodique, dont le résultat se vérifie : à la fin, un ingénieur extérieur doit pouvoir démarrer, déployer et restaurer l'application en suivant le runbook. Si ce test passe, la reprise est faite. Sinon, elle n'est pas finie.
