Access, Excel : sortir d'un outil maison sans perdre l'historique

Une base Access construite quinze ou vingt ans plus tôt, par une seule personne, tient toute l'activité d'un courtier en assurances : les contrats, les renouvellements, l'historique des sinistres. La réponse courte à « comment en sortir sans tout perdre » tient en une phrase : on trie l'historique avant de couper l'ancien outil, jamais après. Le reste de cet article explique comment faire ce tri sans y passer six mois.

Ce qu'il y a vraiment dans une base construite au fil des années#

La peur est toujours la même : « si on y touche, on perd quinze ans ». Elle grandit avec l'ancienneté de l'outil, mais elle ne correspond presque jamais à ce que la base contient réellement.

Une base qui a vécu quinze ans accumule des champs ajoutés pour un besoin ponctuel et jamais retirés, des tables créées pour un test qui n'a servi qu'un mois, des colonnes renseignées à moitié parce que deux personnes ne les remplissaient pas de la même façon. Chez un courtier en assurances, l'historique utile tient souvent dans cinq ou six tables : les clients, les contrats, les renouvellements, les sinistres. Le reste a été ajouté en chemin, et personne ne s'en sert plus.

Le premier geste n'est donc pas de migrer, c'est de regarder table par table la date de la dernière ligne ajoutée. Une table qui n'a rien reçu depuis cinq ans n'est pas de l'historique à reprendre : c'est une archive à conserver telle quelle, de côté.

Trier avant de migrer : ce qui compte, ce qui ne compte pas#

Trois sortes de choses se cachent dans un outil maison, et elles ne se traitent pas de la même façon.

La deuxième colonne est celle qu'on oublie le plus souvent : une donnée ancienne reste consultable sans être activement reprise. Garder une copie de l'ancien outil, en lecture seule, coûte une licence ou un simple fichier, et évite de migrer des milliers de lignes que personne n'ira jamais chercher.

La méthode en trois gestes#

1. Exporter table par table, pas tout d'un bloc. Chaque table a son propre usage, sa propre fraîcheur et ses propres incohérences. Les traiter une par une permet de repérer les doublons et les colonnes mortes avant qu'ils n'arrivent dans la nouvelle application.
2. Garder une copie en lecture seule de l'ancien outil. Personne ne doit avoir besoin de la rouvrir pour travailler, mais quelqu'un doit pouvoir y chercher une ligne ancienne le jour où un client rappelle pour un sinistre de 2016.
3. Faire valider par la personne qui connaît la base. Avant de couper, lui demander de confirmer qu'aucune table active n'a été laissée de côté, et de dire à voix haute les règles qu'elle applique sans y penser.

Chez un courtier en assurances de taille moyenne, une base Access de dix-huit ans comptait quarante tables. Six étaient encore alimentées chaque semaine, les trente-quatre autres n'avaient pas reçu de ligne depuis au moins cinq ans. Reprendre les quarante tables aurait demandé environ trois semaines : une demi-journée par table pour comprendre son usage, nettoyer les doublons et écrire la correspondance avec la nouvelle application. En limitant la reprise active aux six tables encore utilisées, le travail tient en quatre jours. Les trente-quatre autres restent consultables dans la copie en lecture seule, le temps de vérifier qu'on ne les cherche jamais.

Ce qui ne doit jamais se perdre : ce qui n'est écrit nulle part#

Quand je pars en vacances, c'est moi qui gère tous les papiers.

Cette phrase revient souvent chez l'entreprise qui tourne autour d'un outil maison. Elle ne parle pas d'un champ manquant dans la base : elle parle d'une règle que personne n'a jamais écrite, parce que la personne qui l'applique n'a jamais eu besoin de l'écrire pour elle-même.

Avant de couper l'ancien outil, il faut faire dire ces règles à voix haute et les noter : pourquoi tel client a un tarif particulier, pourquoi telle exception existe depuis telle année, pourquoi un dossier se traite toujours dans un ordre précis. Ce n'est pas une donnée qu'on exporte, c'est une connaissance qu'on documente une fois, avant qu'elle ne parte avec la personne.

Ce qui change avec une application construite pour l'entreprise#

Une application construite pour une seule entreprise commence par reprendre l'historique vivant, table par table, avec les bons champs. Les règles non écrites, une fois mises au jour pendant l'audit, deviennent des écrans ou des alertes : le tarif particulier d'un client s'affiche directement sur sa fiche, au lieu de rester dans la mémoire d'une seule personne.

L'ancien outil reste accessible, en lecture seule, le temps que chacun prenne confiance dans le nouveau. Personne ne bascule d'un coup sur la seule promesse que « tout est repris » : la copie de sécurité reste là jusqu'à ce que plus personne n'en ait besoin.

Sortir d'un outil maison : ce qu'il faut retenir#

Le vrai risque n'est presque jamais de perdre des données : une base ancienne contient beaucoup moins d'historique actif qu'on ne le craint, et ce qui dort peut rester consultable sans être repris. Le vrai risque, c'est de perdre les règles que personne n'a jamais écrites, parce qu'une seule personne les connaît.

Trier avant de migrer, garder l'ancien outil en lecture seule, et faire dire les règles non écrites à voix haute : ces trois gestes suffisent à sortir d'un outil maison sans y laisser quinze ans de mémoire. La grille pour choisir quel outil garder pour quoi aide à décider ce qui, dans l'ancien outil, mérite d'être remplacé en premier. Et un ERP ancien n'est pas toujours le problème : parfois, c'est l'outil maison à côté qui porte le vrai risque. Ce que contient une application construite pour une seule entreprise part justement de cet historique-là, pas d'un écran vide.