Migrer FileMaker vers le web : les 6 étapes d'un projet réussi

Quitter FileMaker inquiète souvent davantage que cela ne coûte. Votre application fait tourner l'entreprise depuis des années, elle contient des règles que personne n'a jamais écrites ailleurs, et l'idée d'une « grande bascule » fait peur. C'est normal. Une migration réussie n'a pourtant rien d'un saut dans le vide : c'est une suite d'étapes connues, avec à chaque fois un objectif clair, un livrable que vous validez et des risques que l'on sait traiter.

Voici les six étapes que nous suivons chez Coladia pour migrer une application FileMaker vers une application web sur mesure. Pour chacune : ce que nous faisons, ce que nous attendons de vous, la durée indicative pour une application métier, le livrable et le piège à éviter.

En bref

• Six étapes : audit, conception, développement, reprise des données, recette, bascule et formation.
• Pour une application métier (15 à 50 tables), comptez 1 à 3 mois au total, avec des livraisons toutes les deux semaines.
• Votre FileMaker continue de tourner pendant tout le projet : la bascule se fait sur une fenêtre courte.
• Votre implication se concentre sur trois moments : l'audit, la validation des maquettes et la recette.

Étape 1 : l'audit de l'existant

Objectif : comprendre ce que fait réellement votre application, et pas seulement ce qu'on croit qu'elle fait.

Ce que nous faisons : nous inventorions les tables, les rubriques, les scripts, les modèles (les layouts), les listes de valeurs, les comptes et les échanges avec d'autres logiciels. Les outils d'analyse et l'IA nous aident à lire rapidement des centaines de scripts et à repérer ce qui n'est plus utilisé. Puis nous passons du temps avec les personnes qui se servent de l'application au quotidien : c'est là qu'on découvre le bouton que tout le monde utilise et celui que plus personne n'ouvre.

Ce que nous attendons de vous : un accès à une copie de la base, et quelques heures avec deux ou trois utilisateurs clés, dont la personne qui « connaît la base ».

Durée indicative : 1 à 2 semaines.

Livrable : une cartographie de l'application, la liste de ce qu'on garde, simplifie ou abandonne, un chiffrage et un planning. Et parfois une recommandation honnête de rester sur FileMaker : pour une petite base stable utilisée par trois personnes, la migration n'est pas toujours rentable.

Piège à éviter : sauter l'audit pour « gagner du temps ». La logique métier cachée dans les scripts est la première source de dépassement ; nous détaillons ce sujet dans que deviennent vos scripts et modèles FileMaker.

Étape 2 : la modélisation et la conception

Objectif : dessiner la future application avant d'écrire la moindre ligne de code.

Ce que nous faisons : nous concevons le modèle de données cible dans PostgreSQL (souvent plus simple que l'original, une fois les tables techniques et les doublons de structure éliminés), puis les maquettes des écrans clés. On ne recopie pas les modèles FileMaker : on part des tâches de vos équipes. Un écran de saisie de commande qui demande aujourd'hui quatre onglets et deux fenêtres peut souvent tenir sur une seule page.

Ce que nous attendons de vous : relire les maquettes, les montrer à ceux qui s'en serviront, et trancher les questions d'organisation (qui valide un devis, qui voit les prix d'achat…).

Durée indicative : 1 à 3 semaines, en partie en parallèle de la fin de l'audit.

Livrable : le schéma de données, des maquettes cliquables des écrans principaux, la définition des profils utilisateurs et de leurs droits.

Piège à éviter : exiger une copie à l'identique de l'existant. C'est rassurant sur le moment, mais vous migreriez aussi toutes les lourdeurs accumulées depuis quinze ans.

Étape 3 : le développement, par livraisons régulières

Objectif : construire l'application par petits morceaux que vous voyez fonctionner au fur et à mesure.

Ce que nous faisons : nous développons par cycles de deux semaines. À la fin de chaque cycle, une nouvelle partie de l'application est en ligne sur un environnement de test, avec de vraies données anonymisées ou de test. Nous développons avec des assistants IA, qui produisent l'essentiel du code répétitif (écrans, formulaires, API, tests automatisés) et divisent le temps de développement par deux à trois. Ils ne remplacent ni la compréhension de votre métier, ni les décisions, ni la vérification : chaque règle de calcul est relue et testée.

Ce que nous attendons de vous : une démonstration de 30 à 45 minutes toutes les deux semaines, et des retours rapides. Un interlocuteur unique, disponible et décisionnaire, fait gagner des semaines.

Durée indicative : 4 à 8 semaines pour une application métier.

Livrable : à chaque cycle, une version utilisable et une courte note de ce qui a été livré.

Piège à éviter : attendre la fin pour regarder. Une remarque faite à la deuxième démonstration coûte quelques heures ; la même remarque après la mise en production coûte des jours.

Étape 4 : la reprise des données

Objectif : retrouver dans la nouvelle application toutes vos données, propres et cohérentes.

Ce que nous faisons : nous écrivons un programme de migration qui extrait les données de FileMaker, les nettoie (doublons, formats de dates, valeurs incohérentes), les transforme vers le nouveau modèle, puis les charge dans PostgreSQL avec les fichiers des conteneurs. Ce programme est rejoué plusieurs fois avant la bascule, avec des contrôles de comptage à chaque passage. Le jour J, il n'y a plus de surprise : c'est une répétition de plus.

Ce que nous attendons de vous : décider du sort des données douteuses (fiches clients en double, historique très ancien) et vérifier un échantillon de dossiers que vous connaissez bien.

Durée indicative : 1 à 3 semaines de travail, réparties pendant le développement.

Livrable : un programme de migration testé et un rapport de contrôle (nombre d'enregistrements, totaux, anomalies corrigées).

Piège à éviter : traiter la reprise à la fin, comme une formalité. C'est un sujet à part entière, que nous détaillons dans reprise des données FileMaker : comment migrer sans rien perdre.

Étape 5 : la recette

Objectif : vérifier, avant la mise en production, que l'application fait tout ce qu'elle doit faire, avec vos vraies données.

Ce que nous faisons : nous préparons un environnement de recette alimenté par la dernière migration à blanc, et une liste de scénarios à tester (créer un devis, le transformer en commande, facturer, éditer un avoir…). Nous comparons les résultats des calculs avec ceux de FileMaker sur des cas réels, et nous corrigeons au fil de l'eau.

Ce que nous attendons de vous : des utilisateurs qui testent vraiment, sur leurs cas du quotidien et sur les cas particuliers qu'ils sont seuls à connaître. C'est l'étape où votre implication compte le plus.

Durée indicative : 1 à 3 semaines, dont une partie en parallèle des derniers cycles de développement.

Livrable : un procès-verbal de recette, avec la liste des points corrigés et des éventuelles évolutions reportées après la mise en ligne.

Piège à éviter : une recette faite par une seule personne, en fin de journée, entre deux urgences. Bloquez du temps dans les agendas.

Étape 6 : la bascule et la formation

Objectif : passer de FileMaker à la nouvelle application sans interrompre l'activité.

Ce que nous faisons : nous choisissons avec vous une date (souvent un vendredi soir ou un début de mois calme). Les saisies sont gelées dans FileMaker, la migration finale est jouée et contrôlée, et l'application est ouverte le lendemain matin. Nous formons les utilisateurs par petits groupes, avec un guide court centré sur leurs tâches, et nous restons disponibles les premières semaines pour répondre aux questions. FileMaker reste accessible en lecture seule le temps de rassurer tout le monde, puis vous arrêtez les licences.

Ce que nous attendons de vous : annoncer le changement en interne, libérer les équipes pour la formation et désigner un ou deux référents.

Durée indicative : 1 semaine pour la bascule et la formation, puis 2 à 4 semaines d'accompagnement rapproché.

Livrable : l'application en production, les accès, la documentation utilisateur et technique, et le code source, qui vous appartient.

Piège à éviter : basculer en pleine période de clôture comptable ou de forte activité. Une bonne date de bascule vaut mieux qu'une date rapprochée.

Qui fait quoi ?

Une migration n'est pas un projet que l'on confie puis que l'on récupère clé en main. Votre rôle est limité dans le temps, mais il est décisif aux moments où il faut connaître le métier.

Et si l'on ne migre pas tout d'un coup ?

Ces six étapes peuvent s'appliquer à toute l'application, ou module par module : on migre d'abord la gestion commerciale, pendant que FileMaker continue de gérer la production, puis on enchaîne. Le budget est étalé et le risque réduit, au prix d'une période où les deux outils cohabitent et doivent échanger des données. Nous comparons les deux approches dans big bang ou migration progressive.

Côté budget, une application métier se situe généralement entre 12 et 30 k€ ; les fourchettes et les facteurs qui les font varier sont détaillés dans combien coûte une migration FileMaker vers le web.

En résumé

Une migration FileMaker réussie repose moins sur la technique que sur la méthode : un audit qui ne laisse rien dans l'ombre, une conception qui part des usages, des livraisons régulières que vous voyez fonctionner, une reprise des données répétée jusqu'à être banale, une vraie recette et une bascule préparée. Avec le développement assisté par IA, l'ensemble tient en 1 à 3 mois pour une application métier.

Vous voulez savoir à quoi ressemblerait ce parcours pour votre base ? Nous proposons un audit gratuit de votre application FileMaker, avec un plan de migration et un chiffrage. Découvrez notre offre de migration FileMaker ou parlez-nous de votre projet.