Reprendre les données d'une structure qui vivait sous tableur
Vincent
Co-fondateur, direction technique
En bref
Comment migrer les données d'une association qui gérait tout dans des fichiers Excel ?
En traitant le tableur comme une source de vérité partielle et non comme une base de données. La reprise ne consiste pas à importer des colonnes mais à reconstituer des règles qui n'ont jamais été écrites : ce qu'est un adhérent actif, à quoi correspond une case colorée, pourquoi deux lignes portent le même nom. Le travail est d'archéologie autant que de technique, et il se fait avec la personne qui tenait le fichier.
Sur les déploiements de Vibe-it dans des écoles de danse, le développement n’est jamais la partie risquée. La reprise des données l’est.
Chaque structure arrive avec le même patrimoine : un classeur Excel tenu depuis des années, un onglet par saison, des couleurs qui veulent dire quelque chose, et une personne qui sait le lire. Ce fichier fonctionne. Il contient l’histoire de la structure. Et il ne se convertit pas en base de données par un import.
Voici ce que nous avons appris à faire, et dans quel ordre.
Le tableur n’est pas une base de données mal rangée
C’est l’erreur d’attitude initiale, et elle coûte cher parce qu’elle fait perdre la confiance de l’interlocuteur dès la première réunion.
Un tableur tenu pendant huit ans encode des règles métier réelles. Une case en jaune signifie « cotisation réglée mais chèque pas encore déposé ». Une ligne en italique, « a arrêté en cours d’année ». Une colonne « OK » avec une croix, « certificat médical fourni ». Un nom suivi d’un astérisque, « famille en difficulté, tarif ajusté par le bureau ».
Ces conventions ne sont écrites nulle part. Elles sont pourtant plus fiables que beaucoup de bases de données, parce qu’une seule personne les applique et qu’elle est rigoureuse.
La bonne posture est donc : ce fichier a raison, c’est à nous de comprendre ce qu’il dit. Elle change complètement la nature des réunions de reprise.
Les quatre passes
Nous procédons toujours dans le même ordre, et nous ne sautons aucune étape.
Passe 1 — lire sans importer. Avant tout script, nous parcourons le fichier avec la personne qui le tient, onglet par onglet. On note ce que signifie chaque colonne, chaque couleur, chaque convention. On note surtout les incohérences apparentes, qui ont presque toujours une explication : « ah oui, cette année-là on a changé le mode de calcul ».
Cette passe dure une demi-journée. Elle est de loin la plus rentable, et c’est celle qu’on propose de sauter quand le planning se tend. C’est une mauvaise idée : tout ce qu’on n’apprend pas ici se découvre en recette, quand c’est dix fois plus cher à corriger.
Passe 2 — qualifier, sans transformer. On charge les données telles quelles dans une zone de travail, et on mesure : combien de lignes sans e-mail, combien de dates impossibles, combien de doublons apparents, combien de valeurs hors référentiel.
Le but n’est pas de nettoyer mais de produire un état des lieux chiffré. C’est ce document qui permet de décider, avec le client, ce qu’on reprend et ce qu’on abandonne — décision qui lui appartient et qu’il ne peut prendre que sur des chiffres.
Passe 3 — décider explicitement. Chaque anomalie reçoit une règle écrite. Une adhérente présente deux fois avec deux orthographes : fusion, et selon quel critère ? Une date de naissance au 01/01/1900 : valeur inconnue, et que fait-on des catégories d’âge qui en dépendent ? Une cotisation sans montant : reprise à zéro, ou non reprise ?
Ces règles sont validées par le client, pas par nous. Nous ne sommes pas légitimes à décider qu’une adhérente n’existe plus.
Passe 4 — importer, et pouvoir recommencer. L’import est un script rejouable, jamais une opération manuelle. Il tourne autant de fois que nécessaire, sur une base remise à zéro, et produit systématiquement un rapport : lignes traitées, lignes rejetées avec le motif.
Ce point est non négociable. Une reprise réussit rarement du premier coup, et si l’import n’est pas rejouable, chaque correction devient une intervention chirurgicale sur une base déjà en service.
Photo : domaine public (CC0).
Ce qu’on ne reprend pas
Décision structurante, et souvent mal reçue : nous ne reprenons pas tout.
L’historique complet des huit dernières saisons a une valeur sentimentale forte et une valeur d’usage faible. Personne ne consultera la liste des inscrits de 2019 dans le nouvel outil. En revanche, le reprendre implique de faire tenir dans le nouveau modèle des règles qui n’ont plus cours — anciens tarifs, anciennes catégories, anciennes disciplines — et donc de complexifier le modèle pour des données mortes.
Notre règle : on reprend l’état courant et la saison précédente. Le reste est archivé tel quel, sous forme du fichier d’origine, conservé et accessible. L’information n’est pas perdue ; elle n’est simplement pas convertie.
Cet arbitrage se présente clairement, avec sa raison. Quand il est posé comme un choix — coût et complexité contre consultation rare — il est presque toujours accepté.
Photo : domaine public (CC0).
La recette de reprise, distincte de la recette applicative
Dernier point, souvent oublié dans les plannings.
Vérifier que l’application fonctionne et vérifier que les données sont justes sont deux exercices différents, faits par des personnes différentes. Le second ne peut être mené que par quelqu’un qui connaissait le fichier d’origine.
Nous prévoyons donc une session dédiée, avec un protocole simple : la personne qui tenait le tableur choisit elle-même une vingtaine de cas — un adhérent ordinaire, une famille nombreuse, quelqu’un qui a arrêté en cours d’année, un cas litigieux dont elle se souvient — et vérifie chacun dans le nouvel outil.
Vingt cas choisis par la bonne personne valent mieux que mille lignes contrôlées automatiquement. Ils portent précisément sur les situations où les règles implicites ont pu se perdre.
Photo : domaine public (CC0).
Ce que le tableur contient et que personne ne pense à reprendre
Quatre choses vivent en dehors des cellules, et se perdent en silence lors d’une reprise.
Les commentaires. Ils portent souvent la raison d’une valeur inhabituelle — un accord commercial, une dérogation, une correction. Une fois la donnée migrée, cette justification n’est plus nulle part, et la valeur devient incompréhensible.
Les mises en forme conditionnelles. Une ligne en rouge signifie quelque chose. Ce quelque chose est une règle métier que personne n’a écrite, et qu’il faut recueillir avant de migrer.
Les onglets masqués. Presque tous les fichiers en ont un : des paramètres, une table de correspondance, un historique. Ils n’apparaissent pas dans un export automatique.
L’historique des versions. Le fichier a des états antérieurs, parfois utiles. Après bascule, la seule trace restante est la dernière version.
Ma règle : ouvrir le fichier avec la personne qui le tient, onglet par onglet, avant d’écrire la moindre ligne de reprise. Une heure, et elle évite les trois quarts des mauvaises surprises.
Après la bascule : garder le tableur en lecture seule
Une précaution que je recommande systématiquement, et qui coûte presque rien.
Le fichier d’origine est figé, daté, et conservé dans un endroit consultable — pas supprimé, pas laissé modifiable. En lecture seule, parce qu’un tableur qui reste éditable continue d’être édité : les équipes y reviennent au premier irritant, et les données divergent sans que personne ne s’en aperçoive avant des mois.
Cette copie sert deux fois : pour trancher un désaccord sur une valeur reprise, et pour retrouver ce qui n’avait pas été migré. Passé un an sans consultation, on peut l’archiver.
Ce qu’il faut retenir
Si vous remplacez un outil interne par une application, budgétez la reprise comme un chantier à part entière, avec ses réunions, sa recette et ses arbitrages — pas comme une ligne technique en fin de projet.
Et prévoyez la disponibilité de la personne qui tenait le fichier. Sans elle, la reprise est techniquement faisable et fonctionnellement fausse, ce qui est la pire des deux situations : tout paraît en place, et personne ne fait confiance au résultat.