Quand vous héritez d'un système sans code source ni documentation — Procédure pratique pour l'exploiter et le maintenir sans interruption

« L’entreprise qui l’a développé n’existe plus. » « La personne qui l’a créé a quitté l’entreprise et nous n’arrivons plus à la joindre. » « Il y a bien un exécutable et une base de données sur le serveur, mais ni code source ni cahier des charges nulle part. » Voilà une situation loin d’être rare dans les consultations sur les systèmes métier des PME. Et pourtant, le système continue de tourner aujourd’hui, et l’activité en dépend.

Dans cette situation, le pire choix serait de se lancer, faute de comprendre, dans des modifications à tâtons ou des changements d’environnement improvisés. Un système sans code source n’offre aucune garantie qu’on pourra le réparer s’il tombe en panne. À l’inverse, conclure d’emblée « on ne peut rien faire, il faut tout reconstruire » serait également prématuré. Il existe des moyens de reconstruire les spécifications même sans cahier des charges, et il est parfois possible de lire le contenu même sans code source. Cet article présente, dans l’ordre où on les mettrait réellement en œuvre, les étapes permettant de passer de rien du tout à une exploitation et une maintenance opérationnelles.

1. La conclusion, d’abord

• La première chose à faire n’est pas la modification, mais la préservation de l’état actuel. L’environnement de production en fonctionnement est lui-même votre actif le plus important. Effectuez une sauvegarde par image disque (par exemple en le transformant en machine virtuelle avec Disk2vhd) et une sauvegarde de la base de données, et vérifiez que vous pouvez réellement les restaurer avant de passer à la suite.¹
• Vous pouvez reconstruire les spécifications même sans documentation. Les principaux matériaux sont les entretiens avec les utilisateurs du système, les écrans et les états imprimés, le schéma de la base de données, les journaux, et l’observation du comportement réel avec Process Monitor.²
• Le degré de récupération possible du code source dépend fortement de la pile technologique. Pour .NET, des décompilateurs comme ILSpy permettent d’aller très loin ; pour du code natif comme VB6 ou C++, il ne faut réalistement pas s’attendre à en récupérer grand-chose.³⁴
• La décompilation soulève des questions juridiques. L’article 30-4 de la loi sur le droit d’auteur est compris comme autorisant en principe l’usage à des fins d’investigation et d’analyse, mais vérifier le contrat (les conditions de licence) est indispensable.⁵
• N’attendez pas d’avoir « tout compris » avant d’agir. Donnez la priorité à la compréhension des parties dont l’arrêt bloquerait l’activité et de celles qui auront probablement besoin de changements prochainement, et procédez par petits changements, un à la fois, et réversibles.
• Un contrat de mandat quasi-délégué est le modèle de base pour la maintenance. Vous ne pouvez pas promettre une obligation de résultat (contrat d’entreprise) pour l’investigation d’un système dont on ne connaît pas les rouages internes. Séparez le contrat en une phase d’investigation et une phase de modification.

2. Pourquoi une situation de « rien du tout » se produit-elle ?

Avant de réfléchir à la réponse à apporter, il est utile de déterminer dans quel schéma se trouve votre propre cas : cela donne une idée des indices qui pourraient subsister.

Le dernier schéma est facile à négliger, mais il doit, en pratique, être traité de la même manière que « il n’y a pas de code source ». Un échec classique consiste à traiter une ancienne copie du code source comme faisant autorité et à la modifier, pour découvrir ensuite que l’exécutable en production comportait en réalité des années de correctifs que ce code source n’avait jamais vus. Même si vous retrouvez un arbre de sources, ne lui faites pas confiance tant que vous ne l’avez pas compilé et comparé le résultat à l’exécutable en production.

Quel que soit le schéma dans lequel vous vous trouvez, il vaut la peine de rechercher d’abord le contrat, les bordereaux de livraison et les procès-verbaux de recette. Si la titularité du droit d’auteur ou une obligation de livraison du code source y est précisée, cela devient la base de toute négociation ou analyse juridique ultérieure.

3. Ce qu’il faut faire la première semaine — préserver l’état actuel et faire l’inventaire

3.1 Gel des changements

Jusqu’à la fin de l’investigation, la règle est de ne pas toucher aux serveurs et postes concernés. « Autant mettre à jour l’OS pendant qu’on y est » ou « nettoyons les fichiers qui n’ont pas l’air utilisés » sont exactement le genre de choses qui peuvent être fatales. Sans code source, il n’y a pas d’option « on répare » si quelque chose casse. Il vaut aussi la peine d’envisager de reprendre le contrôle du calendrier des mises à jour, pour que les mises à jour automatiques (Windows Update, changements de comportement de l’antivirus) ne modifient pas silencieusement l’environnement de leur propre initiative.

3.2 Sauvegarde — dupliquer l’environnement lui-même comme un actif

Une sauvegarde au niveau des fichiers seule ne suffit pas. Dans ce type de système, les paramètres de l’OS, le registre, le runtime, et même l’emplacement de déploiement peuvent tous faire partie des raisons pour lesquelles « ça fonctionne » ; c’est pourquoi on préserve l’image disque complète.

En pratique, Disk2vhd de Sysinternals est l’outil le plus couramment utilisé pour cela. Il permet de convertir un système en fonctionnement, tout en restant en ligne, en un VHD/VHDX cohérent grâce à un cliché de volume (VSS), ce qui fournit la base d’un environnement de vérification que l’on peut démarrer comme machine virtuelle Hyper-V.¹ L’avantage est de pouvoir traiter en même temps le risque de vieillissement du serveur physique et l’obtention d’un environnement de vérification (notez que la licence d’un Windows OEM peut ne pas autoriser le passage à un environnement virtuel, il est donc nécessaire de vérifier le type de licence¹).

Parallèlement, sauvegardez la base de données avec la méthode standard propre au SGBD. Et l’étape la plus importante entre toutes est de réellement restaurer à partir de la sauvegarde et de vérifier qu’elle démarre. Une sauvegarde qui n’a jamais été soumise à un test de restauration n’est qu’une assurance que l’on croit avoir. Cela dit, comme l’image restaurée conserve intactes les chaînes de connexion et les tâches planifiées de production, effectuez toujours ce premier démarrage dans un environnement isolé du réseau (détails au chapitre 7). Si vous le démarrez par mégarde en restant connecté, ce qui devait être un environnement de test peut finir par mettre à jour la base de données de production ou ses partenaires d’intégration.

3.3 Inventaire — dresser la liste de tout ce qui tourne

Ensuite, recensez mécaniquement les composants du système. C’est un travail d’exhaustivité, pas de flair.

Si vous ne savez pas où se trouve un fichier de configuration ou une destination de sortie, observer l’accès aux fichiers et au registre du processus avec Process Monitor est le moyen le plus rapide : les chemins que l’application lit et écrit réellement apparaissent directement dans la liste.²

4. On peut reconstruire les spécifications même sans documentation

Une fois que l’inventaire vous dit « ce qui est là », l’étape suivante consiste à reconstruire « ce que ça fait ». Les matériaux sont tous disponibles.

• Interroger les utilisateurs du système — La meilleure spécification que vous trouverez se trouve dans la tête de la personne qui utilise le système tous les jours. Parcourez les processus métier quotidiens, mensuels et annuels, en demandant ce qui est saisi sur quel écran et ce qui en ressort. En particulier, le traitement annuel (clôture comptable, inventaire de fin d’année, bascule d’exercice) est quelque chose que même le responsable peut avoir oublié, et c’est un point de défaillance fréquent lors de la première occurrence après la transmission.
• Écrans et états imprimés — Cataloguez tous les écrans et tous les états imprimés avec des captures d’écran et des exemplaires réels. La seule correspondance entre les champs de saisie et les champs de sortie révèle déjà une bonne partie du squelette du traitement.
• Schéma et données de la base de données — Les définitions de tables, les contraintes et les données réelles derrière les valeurs codées sont des fossiles des règles métier. Une observation comme « ce drapeau ne prend jamais que trois valeurs » vous renseigne sur des spécifications que vous ne verriez jamais depuis les écrans.
• Journaux et journal d’événements — Les journaux propres à l’application, s’ils existent, révèlent le déroulement du traitement, et le journal d’événements Windows révèle les tendances d’erreurs passées.
• Observer le comportement réel — Enregistrer les accès aux fichiers, au registre et au réseau avec Process Monitor permet de confirmer des relations entrée/sortie — « ce traitement de fin de mois lit un CSV dans ce dossier partagé et communique avec ce serveur de base de données » — sans aucun code source.² Cela dit, Process Monitor ne montre que le partenaire de communication ; il ne montre pas quelles tables ont été mises à jour, ni comment. Au-delà de ce point, il faut recourir aux fonctions de traçage/audit propres au SGBD (comme les événements étendus de SQL Server), ou comparer le contenu de la base de données avant et après l’exécution d’un traitement.

Ce qui compte ici, c’est de ne pas essayer de documenter toutes les fonctionnalités de manière égale. L’objectif est la continuité de l’exploitation, pas une encyclopédie ; donnez donc la priorité aux « traitements qui bloquent l’activité s’ils s’arrêtent », aux « traitements qui génèrent des erreurs » et aux « zones qui vont bientôt nécessiter des changements », en construisant à partir de là le registre de ce que vous avez investigué.

5. Ce qui est techniquement possible sans code source

Jusqu’où on peut espérer « lire les rouages internes » dépend largement de la technologie avec laquelle le système a été construit. Estimez la pile technologique à partir des propriétés de l’exécutable et de la composition des DLL, et ajustez vos attentes en conséquence.

Pour une application .NET déployée au format IL classique, la situation est plutôt bonne : le code C# obtenu par décompilation est suffisamment pratique pour comprendre le traitement. Cela dit, comme la documentation officielle elle-même le précise, les commentaires, les noms de variables locales, les espaces et autres informations non nécessaires au moment de la compilation sont perdus ; il faut donc le considérer comme une ressource pour comprendre le comportement, et non comme un substitut au code source d’origine.³ Il existe aussi des exceptions : si une obfuscation a été appliquée, la difficulté de décodage augmente fortement, et un binaire publié en Native AOT ne contient aucun IL, si bien que l’hypothèse « c’est du .NET, donc c’est lisible » ne tient pas. Lors de l’évaluation de la pile technologique, vérifiez le format de déploiement autant que le langage de développement.

Si un PDB (fichier de symboles) subsiste à côté de l’exécutable, il est parfois possible de récupérer les noms de fonctions, voire le code source d’origine lui-même s’il est intégré. Ce qu’un PDB peut et ne peut pas apporter est détaillé dans « Qu’est-ce qu’un PDB (Program Database) ? ».

Considérations juridiques — « vérifier d’abord » avant de décompiler

Être techniquement capable de faire quelque chose et être autorisé à le faire sont deux choses différentes. La rétro-ingénierie, y compris la décompilation, soulève des questions relevant du droit d’auteur. En vertu de l’article 30-4 de la loi sur le droit d’auteur (introduit par la réforme de 2018, couvrant « l’usage non destiné à jouir des pensées ou sentiments exprimés dans une œuvre »), la reproduction ou l’adaptation à des fins d’investigation et d’analyse d’un programme est comprise comme étant autorisée en principe, dans la limite jugée nécessaire. Cependant, l’article comporte la réserve selon laquelle cela « ne s’applique pas lorsque cela porterait atteinte de manière déraisonnable aux intérêts du titulaire du droit d’auteur », si bien que, par exemple, utiliser les résultats de l’analyse pour construire un produit concurrent pourrait être apprécié différemment.⁵

Il reste également la question contractuelle distincte de savoir comment traiter les cas où un contrat de licence d’un logiciel packagé ou d’un livrable interdit l’analyse. Avant toute intervention, vérifiez les conditions de licence du logiciel concerné ainsi que le contrat de développement d’origine (la clause sur la titularité du droit d’auteur), et consultez un avocat en cas de doute. Si votre propre entreprise détient le droit d’auteur sur le livrable, cette question devient nettement plus simple. Pour savoir comment lire ce type de contrat, voir aussi « Comment structurer un contrat de développement sous-traité ou d’exploitation-maintenance ? ».

6. Prolonger la vie du système, l’encapsuler, ou tout reconstruire

Une fois que vous avez combiné la compréhension acquise pendant l’investigation avec les réalités du côté métier, il est temps de fixer une orientation. Là encore, la réponse n’est ni « reconstruction complète, sans discussion » ni « on laisse tel quel, sans discussion » — clarifiez-la avec un tableau de décision.

Les facteurs de décision sont les quatre suivants : les années d’utilisation restantes, la fréquence et la concentration des demandes de changement, l’impact sur l’activité en cas d’arrêt, et le niveau de compréhension récupéré pendant l’investigation. Passer à une reconstruction complète avec un faible niveau de compréhension risque de faire perdre les particularités de l’ancien système — « personne ne peut l’expliquer, mais c’est le comportement correct pour l’activité ». Même si vous choisissez une reconstruction, le registre des spécifications reconstruit au chapitre 4 devient la base de votre définition des exigences ; l’investissement dans l’investigation n’est donc jamais perdu. Au moment de la migration, l’approche standard consiste à faire fonctionner l’ancien et le nouveau système en parallèle pendant une période donnée et à recouper mécaniquement les sorties (états imprimés, agrégats, fichiers) pour une même entrée.

Pour des décisions de prolongation et de migration spécifiques à certaines technologies, « Prolongation et migration des applications métier VB6 / Access » traite en détail de VB6 et Access, et « Guide pour sortir de la dépendance au mode IE » traite des systèmes web internes dépendants du mode IE.

7. Exploiter et maintenir le système après la transmission

Si l’orientation retenue est « continuer à l’exploiter pour le moment » — ce qui décrit, en pratique, la plupart des cas — respecter les schémas suivants réduit les incidents.

• Disposer d’un environnement de vérification — mais toujours isoler le premier démarrage du réseau — Démarrer l’image disque créée en 3.2 en tant que machine virtuelle fournit un environnement de vérification correspondant à la configuration de la production. Mais cette image conserve intactes les chaînes de connexion, les identifiants, les tâches planifiées et les services à démarrage automatique de production. La démarrer en étant connectée au réseau expose au risque qu’un traitement par lots nocturne s’exécute deux fois et mette à jour la base de données de production, que des e-mails soient renvoyés, ou que des API externes soient appelées. Effectuez toujours le premier démarrage avec la carte réseau virtuelle retirée ou sur un réseau isolé, arrêtez les tâches planifiées et les services à démarrage automatique, réécrivez les cibles de connexion pour le test, et n’autorisez la connectivité que pour le périmètre réellement nécessaire, une fois cela fait.
• Effectuer les changements un par un, de façon réversible — Qu’il s’agisse d’un changement de configuration ou de l’application d’une mise à jour Windows, faites une seule chose à la fois. Conservez l’image antérieure au changement, et revenez en arrière si quelque chose ne va pas. Associez cela à un enregistrement de ce qui a été changé (un registre des changements).
• Faire grandir la documentation comme sous-produit de l’investigation — Plutôt que de lancer un projet visant à rédiger la spécification parfaite, ajoutez au registre ce que vous apprenez à chaque incident traité ou changement effectué. Au bout d’un an d’exploitation, la documentation se remplit, en commençant par les points les plus importants pour l’activité.
• Mettre en place une surveillance — Surveillance de disponibilité, espace disque restant, journaux d’erreurs, et détection du cas où « le fichier censé sortir à chaque fois n’est pas sorti ». Même si l’on ne voit pas l’intérieur de la boîte noire, on peut surveiller ses entrées et ses sorties.
• Séparer investigation et modification dans des contrats distincts — Lorsqu’on externalise la maintenance, on ne peut pas promettre une obligation de résultat pour l’investigation d’un système dont on ne connaît pas les rouages internes ; il est donc sain de découper le contrat par phase : investigation et maintenance en mandat quasi-délégué, et modifications individuelles, une fois la spécification stabilisée, en contrat d’entreprise (ou en mandat quasi-délégué axé sur le résultat).

8. Résumé

• Si vous héritez d’un système sans code source ni documentation, la préservation de l’état actuel précède toute modification. Prenez une image disque (par exemple avec Disk2vhd) et une sauvegarde de la base de données, et vérifiez que vous pouvez réellement les restaurer.
• Faites l’inventaire des exécutables, des éléments à démarrage automatique, des tâches planifiées, de la configuration, des partenaires d’intégration et des comptes, afin d’obtenir une vue d’ensemble complète du système.
• Les spécifications peuvent être reconstruites à partir des entretiens avec les utilisateurs, des écrans, des états imprimés, du schéma de la base de données, des journaux et de l’observation du comportement réel avec Process Monitor. Donnez la priorité aux points ayant le plus d’impact sur l’activité, pas à toutes les fonctionnalités.
• Le degré de récupération des rouages internes dépend de la pile technologique. .NET est assez lisible par décompilation, mais cela ne remplace pas le code source d’origine. Vérifiez l’esprit de l’article 30-4 de la loi sur le droit d’auteur, ainsi que les conditions de licence et les contrats, avant de procéder.
• Choisissez entre prolongation, encapsulation, reconstruction partielle et reconstruction complète en fonction des années d’utilisation restantes, de la fréquence des changements, de l’impact sur l’activité et du niveau de compréhension. Quelle que soit la voie choisie, les spécifications reconstruites pendant l’investigation deviennent un actif.
• En phase d’exploitation, le schéma de base repose sur un environnement de vérification, des changements un par un, un registre des changements, la surveillance des entrées et sorties, et un contrat de mandat quasi-délégué.

Articles connexes

• Qu’est-ce qu’un PDB (Program Database) ? — Comprendre les informations de débogage, les symboles et Source Link
• Guide pratique de Process Monitor
• Prolongation et migration des applications métier VB6 / Access — Un tableau de décision garder / encapsuler / remplacer
• Guide pour sortir de la dépendance au mode IE
• Comment structurer un contrat de développement sous-traité ou d’exploitation-maintenance ? — Mandat quasi-délégué et contrat d’entreprise, selon le « contrat type de transaction » de l’IPA
• Externalisation et développement sur mesure d’une application Windows : ce qu’il faut clarifier avant de se lancer

Domaines de conseil associés

Chez Komura Software LLC, nous prenons en charge l’investigation de l’état actuel des systèmes métier sans code source ni documentation subsistants (analyse des exécutables, des bases de données et du comportement observé), la reconstruction des spécifications à partir du comportement, la clarification d’une stratégie de prolongation ou de migration, ainsi que l’exploitation et la maintenance qui en découlent. Nous accueillons volontiers les consultations qui partent de « je ne sais même pas par où commencer ».

• Valorisation et migration des actifs existants
• Modification et maintenance de logiciels Windows existants
• Investigation de bugs et analyse des causes
• Conseil technique et revue de conception
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Peut-on demander une maintenance ou des modifications sur un système sans code source ?

Oui, c'est possible. Mais la démarche diffère d'une maintenance classique. L'approche réaliste consiste à d'abord préserver et sauvegarder l'environnement en fonctionnement, puis à mettre en place une phase d'investigation qui reconstruit les spécifications à partir de l'analyse des écrans, des états imprimés, de la base de données, des journaux et des exécutables, avant de passer aux modifications ou au développement de fonctionnalités périphériques dans les limites de la compréhension acquise durant cette phase. Comme une investigation ne peut pas garantir son résultat à l'avance, elle est généralement menée dans le cadre d'un contrat de mandat quasi-délégué plutôt que d'un contrat d'entreprise engageant une obligation de résultat.

La décompilation d'un exécutable (rétro-ingénierie) est-elle illégale ?

Pas de manière uniforme. En vertu de l'article 30-4 de la loi japonaise sur le droit d'auteur, introduit par la réforme de 2018, les usages « non destinés à jouir des pensées ou sentiments exprimés dans une œuvre » — comme l'investigation et l'analyse d'un programme — sont considérés comme autorisés en principe, dans la limite jugée nécessaire. Cela dit, l'article exclut les cas où cela « porterait atteinte de manière déraisonnable aux intérêts du titulaire du droit d'auteur », et la question de l'effet d'une clause contractuelle interdisant l'analyse dans un contrat de licence reste posée. Avant toute intervention, vérifiez les conditions de licence et le contrat de développement d'origine, et consultez un avocat ou un autre spécialiste en cas de doute.

L'entreprise de développement a fait faillite et nous ne pouvons pas récupérer le code source. Que faire ?

Commencez par vérifier les contrats passés et les livrables. Si le contrat de développement précise la titularité du droit d'auteur ou une obligation de livraison du code source, cela constitue une base pour l'obtenir ou l'utiliser. S'il reste des personnes joignables ayant été impliquées, il vaut la peine d'explorer une négociation pour l'obtenir. Mais en pratique, il est important de ne pas s'arrêter sur un « nous n'avons finalement pas pu l'obtenir » : en partant du principe que vous ne l'obtiendrez pas, il est recommandé de démarrer en parallèle la préservation et la sauvegarde de l'environnement en fonctionnement, ainsi que la reconstruction des spécifications à partir du comportement observé et de la base de données.

Il n'existe aucune documentation. Par où commencer ?

Avant toute modification, commencez par préserver l'état actuel. Prenez une image disque de l'environnement de production en fonctionnement et une sauvegarde de la base de données, puis vérifiez que ces deux éléments peuvent réellement être restaurés. Ensuite, réalisez l'inventaire des exécutables, des éléments à démarrage automatique, des tâches planifiées, de la configuration, des intégrations externes et des comptes, afin d'obtenir une vue d'ensemble complète du système. Sur cette base, l'approche classique consiste à interroger les utilisateurs métier et à observer les écrans, les états imprimés et le schéma de la base de données, en documentant les spécifications en se concentrant sur les points les plus importants pour l'activité.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.