Que deviennent vos scripts et modèles FileMaker après la migration ?

Les données, on comprend assez vite comment les transférer. Mais le reste ? Les centaines de scripts écrits au fil des années, les boutons qui calculent un tarif, les déclencheurs qui vérifient une saisie, le script lancé chaque nuit sur le serveur, les modèles d'impression des devis… C'est là que se trouve la vraie valeur de votre application FileMaker : votre façon de travailler, traduite en règles. Et c'est souvent ce qui inquiète le plus les dirigeants au moment d'envisager une migration.

Disons-le tout de suite : les scripts FileMaker ne se convertissent pas automatiquement en code web, et c'est une bonne chose. Ce qui se conserve, c'est la logique métier. Elle est inventoriée, documentée, triée, puis réécrite proprement dans la nouvelle application, avec des tests qui garantissent qu'elle donne les mêmes résultats. Voici comment.

En bref

• Aucune règle métier n'est perdue : chaque script est inventorié et classé (à garder, à simplifier, à abandonner).
• Une bonne partie des scripts sert à naviguer entre les modèles : ils disparaissent naturellement dans une application web.
• Les règles importantes deviennent du code côté serveur, testé automatiquement.
• Les modèles (layouts) ne sont pas copiés : les écrans web sont repensés à partir de l'usage réel.

Lire avant de réécrire : l'inventaire des scripts

La première étape est de savoir précisément ce que contient votre base. FileMaker propose deux outils précieux pour cela :

• le Database Design Report (DDR), qui produit un rapport HTML ou XML décrivant les tables, les rubriques, les liens, les modèles et les scripts ;
• la fonction « Save a Copy as XML » (enregistrer une copie au format XML), disponible depuis FileMaker Pro 18, qui exporte une représentation XML complète de la structure, des modèles et des scripts. Elle nécessite un accès complet à la base.

Ces exports sont la matière première de l'audit. C'est là que l'IA change la donne : elle lit en quelques heures des centaines de scripts, résume ce que fait chacun, repère les appels entre scripts, les rubriques utilisées et le code mort. Ce qui demandait des jours de lecture fastidieuse devient une documentation claire et navigable. L'IA ne décide pas pour autant : chaque résumé est relu, et les règles ambiguës sont discutées avec les personnes qui utilisent l'application.

Garder, simplifier, abandonner

Une fois l'inventaire fait, chaque script est classé dans l'une de trois catégories.

À garder : les scripts qui portent une vraie règle métier. Calcul d'un prix selon la remise client et la quantité, numérotation des factures, contrôle d'un stock avant validation d'une commande, génération d'un échéancier. Ce sont eux qui font la valeur de l'application. Ils sont réécrits fidèlement.

À simplifier ou fusionner : les scripts qui font la même chose avec de petites variantes (« Imprimer devis », « Imprimer devis v2 », « Imprimer devis client export »), ou les longues séquences de contournement écrites pour pallier une limite de FileMaker. Une seule règle claire, paramétrable, les remplace.

À abandonner : les scripts de navigation (aller à tel modèle, trier, revenir à la liste), les scripts d'affichage, les traitements ponctuels lancés une fois il y a dix ans, les imports d'un logiciel disparu. Dans une application web, la navigation est assurée par l'interface elle-même : ces scripts n'ont tout simplement plus de raison d'être.

Cette répartition est souvent une bonne surprise : la masse de « code » qui effraie au départ contient en réalité un noyau de règles métier bien plus réduit.

De FileMaker à l'application web : les correspondances

Chaque mécanisme de FileMaker a son équivalent, souvent plus robuste, dans une application web moderne.

Les scripts métier deviennent des règles côté serveur

Dans FileMaker, une règle est souvent attachée à un bouton : si quelqu'un modifie l'enregistrement autrement, la règle ne s'applique pas. Dans l'application web, les règles métier vivent sur le serveur, à un seul endroit. Qu'une commande soit créée depuis l'écran, depuis une API ou par un import, la même vérification s'applique. Chaque règle importante est couverte par des tests automatisés, que nous écrivons à partir de cas réels tirés de votre base : même client, même quantité, même remise, même résultat qu'avant.

Les workflows deviennent des statuts explicites

Un devis qui passe à « accepté », puis devient une commande, puis une livraison, puis une facture : dans FileMaker, ce circuit est souvent dispersé entre plusieurs scripts et rubriques. Nous le modélisons comme un workflow explicite, avec des statuts, des transitions autorisées selon les profils, et un historique de qui a fait quoi et quand.

Les déclencheurs deviennent des événements

Les déclencheurs de script (à l'ouverture d'un modèle, à la validation d'un enregistrement, à la modification d'une rubrique) deviennent des événements dans l'application : contrôles de saisie dans le formulaire, vérifications côté serveur lors de l'enregistrement, actions automatiques après un changement de statut. Le comportement est le même, mais il ne dépend plus de l'écran par lequel on passe.

Les scripts serveur planifiés deviennent des tâches programmées

Les planifications de scripts sur FileMaker Server (relances nocturnes, imports, sauvegardes, calculs de statistiques) deviennent des tâches programmées sur le serveur de l'application, supervisées : en cas d'échec, une alerte est envoyée au lieu d'un silence qu'on découvre trois semaines plus tard.

Calculs, impressions et e-mails

Les rubriques calculées deviennent des calculs dans le code ou dans la base, vérifiés sur vos données réelles. Les modèles d'impression (devis, factures, bons de livraison) deviennent des PDF générés automatiquement à partir de gabarits soignés, à votre charte. Les envois d'e-mails, souvent dépendants du logiciel de messagerie du poste dans FileMaker, passent par un service d'envoi professionnel, avec des modèles de messages et une traçabilité des envois.

Les modèles deviennent des écrans pensés pour l'usage

Dans FileMaker, les écrans s'appellent des modèles (les layouts dans la version anglaise). Avec le temps, une base en accumule souvent des dizaines, voire des centaines : un modèle pour la saisie, un pour la liste, un pour l'impression, un pour tel utilisateur, un autre pour l'ancien format…

Nous ne les reproduisons pas un par un. Nous partons des tâches de vos équipes : « traiter une demande client », « préparer les livraisons du jour », « suivre les impayés ». Pour chacune, nous concevons un écran qui réunit ce dont l'utilisateur a besoin, avec recherche instantanée, filtres, actions groupées, et une interface qui fonctionne aussi sur tablette et sur téléphone. Les maquettes sont validées avec vous avant le développement, comme nous le décrivons dans les 6 étapes d'une migration FileMaker réussie.

Les droits suivent la même logique : les jeux de privilèges FileMaker deviennent des profils utilisateurs (commercial, comptable, direction, technicien terrain), qui déterminent ce que chacun voit et peut modifier, écran par écran et action par action.

Ce changement d'interface demande un petit temps d'adaptation, c'est vrai. Mais les utilisateurs retrouvent leurs repères métier, avec moins de clics, et la formation se concentre sur les tâches et non sur les menus.

Et les données derrière tout ça ?

Les scripts et les modèles ne vivent pas sans les données qu'ils manipulent. Rubriques calculées, rubriques globales, listes de valeurs et conteneurs demandent un traitement particulier au moment de la reprise ; nous détaillons ce volet dans reprise des données FileMaker : comment migrer sans rien perdre.

Côté budget, la logique métier cachée dans les scripts est le premier facteur d'incertitude d'une migration, et la principale raison pour laquelle nous commençons toujours par un audit. Les fourchettes de prix sont détaillées dans combien coûte une migration FileMaker vers le web.

En résumé

Vos scripts et vos modèles FileMaker ne sont pas copiés, ils sont compris. Chaque script est inventorié, documenté avec l'aide de l'IA, puis gardé, simplifié ou abandonné. Les règles métier deviennent du code serveur testé, les déclencheurs des événements, les planifications des tâches supervisées, les impressions des PDF générés, et les modèles des écrans conçus pour l'usage réel. Votre façon de travailler est préservée ; ce sont ses lourdeurs qui disparaissent.

Vous voulez savoir ce que contient vraiment votre base ? Notre audit gratuit de votre application FileMaker inclut un premier inventaire des scripts et des modèles. Découvrez notre offre de migration FileMaker ou parlez-nous de votre projet.