Le plan de modernisation est prêt, le budget approuvé dans les grandes lignes. Le prestataire pose sa première question : « Où est la documentation du système ? ». Il s'avère qu'il existe un wiki mis à jour pour la dernière fois il y a cinq ans, quelques schémas « quelque part sur le disque réseau » et un code qui tient lieu de documentation à lui-même. Le devis augmente d'un tiers. Parce que le prestataire ne chiffre pas le travail, mais l'incertitude.
Ce texte décrit une pratique qui retire cette incertitude de la table : avant que quiconque ne touche au code d'une vieille application, on reconstitue le savoir à son sujet. Il y a peu encore, une telle étape signifiait des semaines de travail d'analyste et rares étaient ceux qui s'y résolvaient. Aujourd'hui, l'IA effectue l'essentiel de cette analyse en quelques jours ouvrés. Et cela change l'ordre de tout le projet.
D'abord la carte, ensuite le code
Moderniser un système sans documentation à jour revient à rénover un bâtiment sans plan des installations. C'est possible, mais chaque mur abattu est une loterie : peut-être qu'il n'y a rien derrière, peut-être un tuyau dont dépend la moitié de l'étage. Dans les applications, ce tuyau est parfois l'intégration avec l'entrepôt de données dont seul l'auteur du code se souvenait, ou l'export nocturne que la comptabilité utilise en silence.
La séquence raisonnable est donc l'inverse de l'intuition. On ne commence pas par écrire du nouveau code, ni même par le chiffrage. On commence par la carte.
Ce que l'IA extrait du code, de la base et des logs
Les outils d'analyse modernes savent lire trois sources de vérité sur un système : le code source, la structure de la base de données et les logs de production. De leur croisement naît une carte du système qui couvre quatre couches.
La première, ce sont les modules : de quoi le système se compose et de quoi chaque fragment est responsable, décrits dans un langage compréhensible aussi pour les personnes hors IT. La deuxième, les flux de données : par où les données entrent, ce qui leur arrive en chemin, où elles atterrissent. La troisième, les intégrations, c'est-à-dire tous les endroits où l'application parle à d'autres systèmes : comptabilité, entrepôt, boutique, partenaires. Ce sont elles qui cassent le plus souvent lors des modifications.
La quatrième couche est la moins évidente : le code mort. L'analyse des logs montre quelles fonctions n'ont pas été appelées depuis des années et dans quelles tables personne n'écrit depuis 2019. Dans les systèmes anciens, ce lest représente souvent une part considérable de l'ensemble. Chaque ligne qu'il n'est pas nécessaire de migrer est une économie réelle dans le projet.
Ce que la carte change dans la décision « réécrire ou moderniser »
Nous avons traité la décision elle-même à part, dans un texte sur les quatre critères : le framework de décision. La carte du système donne à ces critères des données solides. Sans elle, la dette technologique s'évalue au jugé et le risque sur la base d'anecdotes. Avec elle, on voit noir sur blanc : quels modules portent la valeur business, lesquels sont morts, où se logent les intégrations qui font monter le risque de chaque modification.
Les résultats surprennent parfois dans les deux sens. Tantôt un système « à réécrire de zéro » se révèle sain aux trois quarts et il suffit de remplacer deux modules. Tantôt l'inverse : l'application a l'air inoffensive, et la carte révèle une quinzaine de connexions non documentées qui rendent la modernisation partielle plus chère que la réécriture. Dans les deux cas, la décision se prend sur des données, pas sur des émotions. Et le prestataire qui reçoit une carte au lieu d'une énigme chiffre le travail au lieu du risque.
À notre avis, la reconstitution de la carte devrait constituer une étape distincte et première du contrat de modernisation, avec une validation qui lui est propre. Même si, après cette étape, vous décidez que la modernisation sera faite par quelqu'un d'autre, ou pas du tout, la documentation reste dans l'entreprise et continue de travailler.
Comment vérifier ce que l'IA a généré
Une documentation générée automatiquement n'est pas un oracle. Il faut la vérifier. La méthode la plus efficace est simple : une revue avec la personne qui connaît le mieux le système, souvent la seule dans l'entreprise. La différence avec l'approche classique tient au rôle de cette personne. Vous ne lui demandez pas de coucher son savoir par écrit, ce que personne n'aime et ce qui traîne des mois. Vous lui demandez de relire une description toute prête, et indiquer « ici c'est juste, là non » va bien plus vite qu'écrire à partir de zéro.
Une bonne pratique consiste à parcourir de bout en bout quelques processus majeurs : commande, facture, réclamation. Si la carte décrit correctement les flux critiques et les détails vérifiés par sondage, on peut lui faire confiance pour les autres domaines. Cela peut se faire en une journée.
Ce que l'IA ne reconstituera pas
Ici, une réserve honnête : le code dit ce que le système fait, mais pas pourquoi. Une exception étrange dans le calcul d'une remise peut être un bug, ou un accord commercial de 2016 qui vaut toujours pour un gros client. Aucune analyse de code ne tranchera cela. Les intentions business d'il y a dix ans se reconstituent par entretiens : de courtes conversations avec les gens des ventes, de la comptabilité et des opérations, menées carte en main. La carte souffle les questions à poser, mais les réponses appartiennent à l'humain.
L'environnement de l'application est aussi un sujet à part : serveurs, réseau, sauvegardes. Nous avons écrit sur la documentation de cette couche dans le texte sur l'audit de la documentation d'infrastructure.
Chez ESKOM AI, nous menons l'étape de cartographie avec une équipe d'agents IA spécialisés sous la supervision d'ingénieurs expérimentés : l'analyse d'un système d'entreprise typique prend quelques jours ouvrés, et le résultat est une documentation lisible pour la direction comme pour l'équipe technique. Si la décision de moderniser est ensuite prise, la suite des travaux se déroule dans un processus automatisé de développement logiciel avec une gamme complète de tests — unitaires, d'intégration, E2E, UI, de sécurité et de performance.
Par où commencer chez vous
Choisissez un système : celui dont vous repoussez la modernisation depuis le plus longtemps, ou celui que vous craignez le plus de toucher. Commandez la reconstitution de sa carte comme une étape autonome et modeste, avant de demander à quiconque un devis de refonte. Lors d'une consultation gratuite, nous vous dirons comment planifier une telle étape et à quoi vous attendre ensuite.
Réservez une consultation gratuite via le formulaire de contact →