Reprise des données FileMaker : comment migrer sans rien perdre

Dans un projet de migration FileMaker, une crainte revient plus que toutes les autres : « Et nos données ? » Quinze ans de clients, de commandes, de factures, de documents scannés et de notes saisies au fil de l'eau. Perdre une partie de cet historique, ou découvrir trois mois après la bascule que des montants ne correspondent plus, est un risque que personne ne veut courir.

La bonne nouvelle, c'est que la reprise des données est une opération très maîtrisable, à condition de la traiter comme un chantier à part entière et non comme une formalité de dernière minute. Voici comment nous procédons, étape par étape, et les points d'attention propres à FileMaker.

En bref

• La reprise se fait avec un programme de migration automatisé, rejoué plusieurs fois avant la bascule.
• Les points délicats propres à FileMaker : conteneurs, rubriques calculées et globales, rubriques à répétitions, clés et liens, dates.
• Chaque passage est vérifié : comptages, totaux, échantillons contrôlés par vos équipes.
• Le jour J, on gèle les saisies, on joue une dernière migration déjà répétée, et on contrôle.

1. Faire l'inventaire

Tout commence par une carte précise de ce qui existe : chaque table, chaque rubrique, son type, son volume, et surtout son usage réel. Dans une base qui a vécu, on trouve toujours des tables d'import oubliées, des rubriques « Remarque2 » ou « Ancien_statut » qui n'ont plus servi depuis des années, des fichiers FileMaker séparés reliés entre eux.

Cet inventaire, mené pendant l'audit, sert à décider pour chaque élément : on le reprend tel quel, on le transforme, on l'archive ou on l'abandonne. L'IA nous aide à analyser la structure et à repérer les rubriques vides ou jamais utilisées, mais la décision se prend avec vous.

2. Extraire les données

Il existe plusieurs façons de sortir les données d'une base FileMaker, et nous les combinons souvent :

• Les exports FileMaker (CSV, tabulé, Excel, XML) : simples, disponibles partout, adaptés aux tables de taille raisonnable. Attention au jeu de caractères choisi à l'export et au format des dates, qui dépend des réglages du poste.
• ODBC/JDBC : une base hébergée sur FileMaker Server ou FileMaker Cloud peut être interrogée en SQL par un programme externe, à condition d'activer le privilège correspondant et d'installer le pilote. C'est la voie la plus pratique pour extraire de gros volumes de façon répétable.
• La FileMaker Data API : une API REST qui renvoie les enregistrements au format JSON, et qui donne accès aux fichiers des conteneurs par un lien de téléchargement. Elle est très utile pour automatiser, en tenant compte des limites de volume de transfert prévues par la licence Claris. Les versions récentes proposent aussi une API OData.

Le choix dépend de votre version, de votre hébergement et de vos volumes. Dans tous les cas, nous travaillons sur une copie de la base : votre application de production n'est jamais modifiée.

3. Traiter les particularités de FileMaker

C'est ici que se joue la qualité d'une reprise. FileMaker a des concepts qui n'ont pas d'équivalent direct dans une base relationnelle classique.

Les rubriques calculées. Une rubrique de calcul non stockée n'est pas une donnée : c'est une formule. On ne la reprend pas, on la réécrit dans l'application, puis on vérifie qu'elle donne le même résultat qu'avant sur des milliers d'enregistrements. Les calculs stockés et les rubriques statistiques (totaux, moyennes) sont traités de la même manière : on reprend parfois la valeur à titre de contrôle, mais la règle est recodée.

Les rubriques globales. Elles ne contiennent pas de données métier : leur valeur est partagée et propre à chaque session. Elles servent souvent à mémoriser un filtre ou un paramètre. On identifie leur rôle, et elles deviennent des paramètres de l'application ou disparaissent.

Les rubriques à répétitions. Héritage des anciennes versions, elles stockent plusieurs valeurs dans une seule rubrique (par exemple cinq lignes de tarif). On les éclate en lignes d'une table dédiée, ce qui rend enfin ces données interrogeables.

Les liens et les clés. Les relations de FileMaker reposent parfois sur des clés fragiles : un nom de client, un numéro saisi à la main, une clé composée par calcul. Nous créons des identifiants techniques fiables, conservons les anciens numéros pour la traçabilité, et vérifions que chaque commande retrouve bien son client. Les enregistrements orphelins sont listés et traités un par un avec vous.

Les listes de valeurs. Statuts, catégories, modes de règlement : ces listes deviennent des tables de référence. C'est le moment de fusionner « Livré », « livre » et « LIVRE » en une seule valeur.

4. Reprendre les conteneurs

Les rubriques Conteneur stockent des PDF, des photos, des plans, des documents signés. Elles peuvent représenter l'essentiel du volume de la base. Selon les cas, les fichiers sont intégrés dans la base FileMaker ou stockés à l'extérieur, gérés par FileMaker.

Nous extrayons chaque fichier avec son nom d'origine, le rattachons au bon enregistrement, et le déposons dans un stockage de fichiers adapté (stockage objet hébergé en Europe), la base PostgreSQL ne conservant que la référence. On contrôle ensuite le nombre de fichiers, leur taille totale, et on ouvre un échantillon pour s'assurer qu'aucun n'est corrompu.

5. Nettoyer sans trahir l'historique

Une migration est l'occasion idéale de faire le ménage, mais le nettoyage doit rester traçable :

• Doublons : fiches clients en double, contacts saisis deux fois. Nous les détectons automatiquement et vous proposons des fusions, que vous validez.
• Formats : dates saisies en texte, téléphones dans tous les formats, montants avec des espaces. Tout est normalisé, et les valeurs impossibles à interpréter sont listées plutôt que devinées.
• Encodages : accents abîmés par d'anciens imports, caractères spéciaux. Tout passe en UTF-8, et les textes suspects sont signalés.
• Dates et heures : FileMaker stocke des dates sans fuseau horaire et affiche selon les réglages du poste ; on fixe une convention claire et on vérifie les cas limites (29 février, changements d'heure, dates à zéro).
• Historique : rien n'est supprimé par défaut. Les données très anciennes peuvent être archivées dans une table à part, consultable, plutôt que mélangées aux données actives.

6. Répéter : les migrations à blanc

Le secret d'une bascule sereine, c'est la répétition. Le programme de migration est rejoué de bout en bout sur une copie fraîche de votre base, plusieurs fois pendant le projet : souvent trois à cinq migrations à blanc. Chaque passage révèle quelques cas particuliers, que l'on corrige dans le programme, jamais à la main dans les données.

Ces migrations à blanc alimentent aussi l'environnement de recette : vos utilisateurs testent la nouvelle application sur leurs propres dossiers, ce qui permet de repérer très tôt une donnée mal reprise. Nous expliquons la place de la recette dans l'ensemble du projet dans les 6 étapes d'une migration FileMaker réussie.

7. Contrôler, chiffres à l'appui

« Ça a l'air bon » ne suffit pas. À chaque passage, des contrôles automatiques comparent la source et la cible, et un rapport est produit.

Le contrôle le plus parlant pour un dirigeant reste souvent le plus simple : le chiffre d'affaires facturé par année, le nombre de clients actifs, le solde des factures impayées. Si ces totaux sont identiques au centime près dans FileMaker et dans la nouvelle application, la confiance s'installe vite.

8. Le jour J : gel des saisies et migration finale

Le jour de la bascule, il ne reste plus qu'à appliquer une procédure déjà rodée :

1. annonce de l'horaire aux équipes, quelques jours avant ;
2. gel des saisies dans FileMaker (passage en lecture seule) ;
3. extraction depuis la base à jour et migration finale ;
4. contrôles automatiques et vérification d'un échantillon par un référent de votre équipe ;
5. ouverture de la nouvelle application.

Pour une application métier, la migration finale prend généralement de quelques dizaines de minutes à quelques heures selon le volume de conteneurs. FileMaker reste consultable en lecture seule pendant quelques semaines : en cas de doute, on peut toujours comparer.

Combien de temps, et quel budget ?

La reprise des données représente en général autour de 15 % du budget d'une migration, davantage si la base est ancienne, très volumineuse ou peu structurée. Pour une application métier, comptez une à trois semaines de travail, réparties pendant le développement. Les ordres de grandeur complets sont détaillés dans combien coûte une migration FileMaker vers le web.

En résumé

Migrer des données FileMaker sans rien perdre repose sur une méthode simple : un inventaire précis, une extraction adaptée à votre configuration, un traitement soigneux des particularités de FileMaker (conteneurs, calculs, globales, répétitions, clés), un nettoyage traçable, des migrations à blanc répétées et des contrôles chiffrés à chaque passage. Le jour J n'est alors qu'une répétition de plus.

Vous vous demandez dans quel état sont les données de votre base ? Notre audit gratuit de votre application FileMaker inclut une première analyse de la structure et des volumes. Découvrez notre offre de migration FileMaker ou parlez-nous de votre projet.