Migration FileMaker : big bang ou migration progressive ?

Une fois la décision prise de quitter FileMaker, une question de méthode arrive très vite : faut-il tout basculer d'un coup, ou migrer l'application morceau par morceau ? Les deux approches existent, elles ont chacune leurs partisans, et aucune n'est bonne dans l'absolu. Le bon choix dépend de la taille de votre base, de la façon dont vos équipes l'utilisent et du risque que votre activité peut supporter le jour de la bascule.

Dans cet article, nous comparons honnêtement le « big bang » et la migration progressive, nous expliquons comment choisir, puis comment faire cohabiter proprement FileMaker et la nouvelle application pendant la transition, ce qui est le vrai point technique de l'approche progressive.

En bref

• Big bang : une seule bascule, un projet plus court et plus simple, mais tout le risque se concentre sur un jour. Idéal pour les petites applications.
• Migration progressive : plusieurs mises en service, module par module ou équipe par équipe. Risque réparti et bénéfices plus rapides, mais une période de cohabitation à organiser.
• La cohabitation repose sur trois règles : une synchronisation fiable, une seule source de vérité par donnée, et une date de fin fixée dès le départ.

Le big bang : tout basculer en une fois

Le principe est simple : on développe la nouvelle application en entier, on la teste, on reprend les données, et un jour donné, souvent un lundi matin après un week-end de reprise, tout le monde passe sur le nouvel outil. FileMaker est mis en lecture seule, puis arrêté.

Ses avantages sont réels.

• Pas de double système : aucune synchronisation à développer ni à surveiller, aucune question sur « où se trouve la bonne donnée ».
• Un projet plus court et donc souvent un peu moins cher : tout l'effort porte sur la nouvelle application.
• Une rupture nette : les équipes savent qu'à partir de telle date, on travaille autrement. Pas de période floue.

Ses risques aussi.

• Tout se joue le jour J. Un calcul oublié, une règle métier mal comprise, un import qui échoue : le problème touche toute l'entreprise en même temps.
• Un effet tunnel : pendant des mois, les utilisateurs ne voient rien. Les retours arrivent tard, quand corriger coûte plus cher.
• Une formation massive : tout le monde doit apprendre le nouvel outil la même semaine, en continuant à faire tourner l'activité.

La migration progressive : module par module

Ici, on découpe l'application en morceaux cohérents et on les met en service les uns après les autres. Pendant la transition, une partie de l'activité tourne sur la nouvelle application, le reste sur FileMaker, et les deux échangent les données dont elles ont besoin.

Ce que vous y gagnez :

• Un risque réparti. Chaque mise en service touche un périmètre limité. Si un problème survient, il est circonscrit et vite corrigé.
• Des bénéfices plus tôt. Le module qui fait le plus mal (souvent celui que l'on veut ouvrir sur mobile ou aux clients) peut être en ligne en quelques semaines.
• Des retours réels. Les utilisateurs du premier module influencent la conception des suivants. L'application s'améliore en chemin.
• Un budget étalé, au rythme des mises en service.

Ce que cela coûte :

• La cohabitation demande un développement spécifique (la synchronisation), qui sera jeté une fois FileMaker arrêté. Comptez en général quelques jours à quelques semaines de travail selon le nombre de données partagées.
• Une complexité temporaire : deux outils, des règles de synchronisation à respecter, une vigilance sur la cohérence des données.
• Le risque de l'entre-deux qui dure. Sans date de fin, on peut se retrouver deux ans plus tard à payer les licences FileMaker et l'hébergement de la nouvelle application.

Comment choisir ?

Il n'y a pas de règle mathématique, mais quelques repères tirés de nos projets.

Le big bang est généralement le bon choix quand :

• l'application est petite (moins de 15 tables) et le projet dure quelques semaines ;
• les données sont très imbriquées : tout dépend de tout, et la découper créerait plus de synchronisation que d'application ;
• les utilisateurs sont peu nombreux et peuvent être formés ensemble en une demi-journée ;
• il existe une période creuse naturelle (fermeture estivale, fin d'exercice) pour basculer sereinement.

La migration progressive s'impose plutôt quand :

• l'application est une application métier ou critique, avec plusieurs modules et des dizaines d'utilisateurs ;
• l'activité ne peut pas s'arrêter, même une journée ;
• des équipes distinctes utilisent des parties distinctes de la base (commerciaux, atelier, comptabilité) ;
• un besoin urgent justifie de livrer vite une partie (un portail client, une application terrain).

Dans les faits, la plupart de nos projets d'application métier sont progressifs, avec deux à quatre étapes. Pour les petites applications, le big bang reste souvent le plus raisonnable : la cohabitation coûterait plus cher qu'elle ne rapporterait. Nous détaillons le déroulé complet d'un projet dans les 6 étapes d'une migration FileMaker réussie.

Découper : par module ou par équipe ?

Une migration progressive se joue d'abord sur le découpage. Deux logiques sont possibles, souvent combinées.

Par module fonctionnel : on migre d'abord les devis, puis les commandes et la production, enfin la facturation. C'est le découpage le plus naturel quand les modules sont assez indépendants. Bon réflexe : commencer par un module visible et peu risqué, qui apporte un gain rapide sans toucher au cœur financier de l'entreprise.

Par équipe ou par site : une équipe (ou une agence) passe entièrement sur la nouvelle application, les autres restent sur FileMaker. C'est efficace quand les équipes travaillent sur des données séparées, par exemple deux agences avec chacune leurs clients. C'est plus délicat quand elles partagent les mêmes fiches.

Dans tous les cas, l'objectif est le même : qu'à un instant donné, chaque utilisateur travaille dans un seul outil pour une tâche donnée. Demander à quelqu'un de saisir une commande dans la nouvelle application puis d'aller vérifier le stock dans FileMaker, c'est le meilleur moyen de faire rejeter le projet.

Faire cohabiter FileMaker et la nouvelle application

C'est la partie technique de l'approche progressive. Bonne nouvelle : FileMaker offre plusieurs portes de sortie standard pour échanger des données.

Les moyens de synchroniser

• Les API de FileMaker Server. La FileMaker Data API et l'API OData permettent à la nouvelle application de lire et d'écrire dans la base FileMaker par des requêtes web standard. C'est la solution la plus courante pour une synchronisation planifiée (toutes les cinq minutes, toutes les heures) ou déclenchée par un événement. Vérifiez au passage les conditions de votre licence, qui encadrent le volume de données échangées par ces API.
• ODBC / JDBC. FileMaker peut être interrogé comme une base SQL par un pilote ODBC ou JDBC. C'est pratique pour des lectures en masse, moins pour des écritures fréquentes.
• ESS (External SQL Sources). Dans l'autre sens, FileMaker sait afficher et modifier des tables d'une base SQL externe (SQL Server, MySQL, Oracle, entre autres) comme si elles étaient les siennes. C'est une option élégante : les écrans FileMaker restants travaillent directement dans la nouvelle base, sans copie. Elle demande toutefois de vérifier la compatibilité avec votre version de FileMaker et la base choisie, et de surveiller les performances.

Le choix dépend du volume, de la fraîcheur attendue des données et de votre version de FileMaker. Pour la plupart des PME, une synchronisation par API toutes les quelques minutes suffit largement.

Une seule source de vérité par donnée

C'est la règle qui évite les catastrophes. Pour chaque type de donnée (clients, articles, commandes, stock), on décide quel outil en est le maître pendant la transition. Les clients et les devis sont créés et modifiés dans la nouvelle application ; FileMaker en reçoit une copie en lecture. Le stock reste géré dans FileMaker tant que le module n'a pas migré ; la nouvelle application le consulte.

Ce qu'il faut éviter à tout prix : que la même fiche client puisse être modifiée des deux côtés. Les conflits de synchronisation (qui a raison quand deux personnes ont changé la même adresse ?) sont la principale source de données corrompues dans les migrations mal préparées. Ce sujet rejoint celui de la reprise des données FileMaker, qui doit être pensée dès le début du projet.

Une date de fin, fixée dès le départ

La cohabitation est un échafaudage : utile pendant les travaux, elle doit disparaître ensuite. Fixez dès le lancement la date à laquelle FileMaker sera arrêté, par exemple au plus tard douze mois après la première mise en service, et suivez-la comme un jalon du projet. Chaque mois de cohabitation supplémentaire, c'est un mois de licences FileMaker, de synchronisation à maintenir et de double vigilance. C'est aussi le moment où le gain financier de la migration commence vraiment, comme nous le détaillons dans combien coûte une migration FileMaker.

Un exemple type

Prenons une PME de négoce de 25 salariés, avec une base FileMaker d'une trentaine de tables : devis, commandes, stock, facturation. Les commerciaux veulent accéder aux devis depuis leur téléphone ; l'entrepôt et la comptabilité sont satisfaits de l'existant.

Un découpage raisonnable serait le suivant : étape 1, les clients et les devis, accessibles sur mobile, en service au bout de deux mois ; la synchronisation recopie les clients et les devis acceptés vers FileMaker, où les commandes continuent d'être traitées. Étape 2, les commandes et le stock, deux à trois mois plus tard. Étape 3, la facturation et l'export comptable, puis l'arrêt de FileMaker. Au total, un projet d'application métier dans la fourchette de 12 à 30 k€, étalé sur l'année, avec un premier bénéfice visible dès le deuxième mois.

Avec le développement assisté par IA, chaque étape va nettement plus vite qu'il y a quelques années, ce qui rend le découpage encore plus intéressant : les mises en service se rapprochent et la période de cohabitation raccourcit. En revanche, l'IA ne décide pas du découpage ni des règles de synchronisation : ce sont des choix métier, que nous faisons avec vous.

En résumé

Le big bang est simple et efficace pour une petite application aux données imbriquées. La migration progressive est le choix le plus sûr pour une application métier utilisée par plusieurs équipes, à condition de bien la cadrer : un découpage où chaque utilisateur travaille dans un seul outil, une synchronisation fiable, une seule source de vérité par donnée et une date de fin tenue.

Vous hésitez entre les deux pour votre base ? Notre audit gratuit de votre application FileMaker inclut une proposition de découpage et un calendrier de migration. Découvrez notre offre de migration FileMaker ou parlez-nous de votre projet.