Application métierMéthodeSur-mesurePMETarification
Migrer une base FileMaker vers une application web : quand le faire, et comment
11 min de lecture
Il faut migrer une base FileMaker vers une application web quand elle dépasse ce pour quoi elle a été conçue : des clients ou partenaires à connecter, un nombre d'utilisateurs qui fait grimper les licences, des intégrations qui se compliquent, ou un seul développeur qui connaît la base. Trois voies existent : rester sur la plateforme Claris en ouvrant la base au navigateur avec WebDirect, ajouter une application web qui dialogue avec FileMaker, ou reconstruire entièrement en application web. Le chantier principal n'est pas l'interface, mais la reprise des scripts, des calculs et des fichiers stockés dans la base.
Cet article s'adresse au dirigeant qui doit décider. Il ne dénigre pas FileMaker : c'est un excellent outil pour construire vite une base métier, et beaucoup d'entreprises le font évoluer avec succès depuis des années. La question est de savoir si la vôtre en a atteint les limites.
Pourquoi les entreprises quittent FileMaker
FileMaker, édité par Claris, a souvent été construit par un passionné en interne, puis enrichi au fil des besoins. Ce modèle fait sa force : la base colle exactement au métier. Il devient une contrainte dans cinq cas.
- Des clients ou partenaires doivent y accéder : suivi de commande, dépôt de documents, prise de rendez-vous. Ouvrir une base interne à l'extérieur pose des questions de sécurité et de licences.
- Le nombre d'utilisateurs augmente : la facture de licences suit, utilisateur par utilisateur.
- Les intégrations se multiplient : comptabilité, site web, ERP, signature électronique. Elles sont possibles avec FileMaker, mais demandent un savoir-faire spécifique.
- Une seule personne maîtrise la base, souvent celle qui l'a créée. Le vivier de développeurs FileMaker est plus étroit que celui du web.
- L'expérience mobile ou web est limitée : WebDirect et FileMaker Go rendent des services réels, mais l'ergonomie reste celle d'une base de données plus que d'une application grand public.
Ce que coûte FileMaker aujourd'hui
Claris vend FileMaker par abonnement. Sur sa page de tarifs (relevé du 07/11/2026), l'offre FileMaker Cloud se décline en deux formules facturées à l'année :
| Formule Cloud | Prix affiché | Nombre d'utilisateurs |
|---|---|---|
| Starter | 22 dollars US par utilisateur et par mois | 5 à 10 uniquement |
| Max | 45 dollars US par utilisateur et par mois | 5 à 99, au-delà sur devis |
FileMaker Server, pour un hébergement sur vos propres machines, fait l'objet d'une offre séparée. Ces prix sont indicatifs, hors taxes et susceptibles d'évoluer : vérifiez votre propre contrat. Ce qui compte pour la décision, c'est la mécanique : un coût proportionnel au nombre d'utilisateurs, chaque année, pour toujours. Une application sur mesure inverse la logique : un coût de développement, puis un hébergement et une maintenance qui ne dépendent pas du nombre de comptes.
Quand il vaut mieux rester sur FileMaker
Une migration n'a de sens que si elle résout un vrai problème. Restez sur FileMaker si :
- la base sert une petite équipe interne, sans accès extérieur ;
- un développeur FileMaker compétent et disponible la fait évoluer ;
- l'usage sur iPad avec FileMaker Go convient à vos équipes terrain ;
- le coût des licences reste raisonnable au regard du service rendu ;
- personne ne réclame de fonction que FileMaker rend difficile.
Dans ce cas, investissez dans la solidité : version à jour, sauvegardes testées, documentation des scripts principaux, second développeur qui connaît la base.
Les trois voies, comparées
| Voie | Ce qui change | Avantages | Limites |
|---|---|---|---|
| Rester sur Claris, ouvrir par WebDirect | Accès navigateur aux modèles existants | Aucune réécriture, mise en place rapide | Licences par utilisateur, ergonomie de base de données, plafond de connexions |
| Application web à côté de FileMaker | Un portail ou un module web lit la base par API | FileMaker reste pour l'interne, le web pour l'extérieur | Deux systèmes à maintenir, dépendance à Claris conservée |
| Application web sur mesure | Navigateur, base standard, API documentées | Accès partout, coût indépendant du nombre d'utilisateurs, intégrations | Réécriture complète, reprise des scripts et des conteneurs |
| Autre outil low-code ou logiciel du marché | Vous changez de plateforme | Rien ou peu à développer | Nouvelle dépendance, vos règles doivent tenir dans l'outil |
Ouvrir la base au navigateur avec WebDirect
WebDirect affiche vos modèles FileMaker dans un navigateur, sans réécriture. C'est rapide et suffisant pour des collaborateurs qui travaillent de chez eux. Claris précise, dans sa documentation WebDirect, qu'une machine serveur accepte en général jusqu'à 100 connexions simultanées. Pour un portail ouvert à vos clients, cette voie montre vite ses limites : licences, ergonomie pensée pour l'écran d'un poste, contrôle fin des droits plus délicat.
Ajouter une application web qui dialogue avec FileMaker
FileMaker Server et FileMaker Cloud exposent les données par API, notamment par le protocole OData décrit dans le guide de Claris. Une application web peut donc lire et écrire dans la base, par exemple pour un portail client, pendant que l'équipe interne garde ses écrans FileMaker. C'est souvent la première étape d'une migration progressive : le web prend l'extérieur, puis récupère les modules internes un à un.
Reconstruire en application web
Une application dans le navigateur, une base comme PostgreSQL, des interfaces de programmation pour les échanges. C'est la voie qui ouvre le plus de possibilités et supprime la dépendance à une plateforme propriétaire. C'est aussi un vrai projet de développement, qui commence par comprendre ce que la base fait réellement. Le même raisonnement vaut pour d'autres outils du même genre : voir migrer Access vers une application web et les limites d'Airtable.
Ce qui se migre mal, et comment s'y prendre
Les scripts
Une base FileMaker mûre compte souvent des centaines de scripts. Ils enchaînent des actions sur des modèles : aller à un modèle, rechercher, trier, définir une rubrique, imprimer. Cette logique n'existe pas telle quelle sur le web. Le rapport de conception de la base, que FileMaker Pro sait produire, permet de les inventorier. On les classe ensuite : règles métier à réécrire, automatismes d'interface à repenser, scripts morts à supprimer.
Les champs calculés et le graphe de relations
FileMaker calcule beaucoup à la volée : totaux, statuts, rubriques récapitulatives. Le graphe de relations multiplie les occurrences de tables pour afficher les bonnes données au bon endroit. Dans une application web, ces calculs deviennent des requêtes ou du code, et les relations un vrai modèle de données. C'est l'occasion de le remettre à plat, plutôt que de recopier les détours accumulés.
Les champs conteneurs
Photos, PDF, plans, contrats : FileMaker stocke souvent les fichiers dans la base, parfois en externe. Leur extraction se prévoit tôt, car le volume peut être important et les noms de fichiers incohérents.
Les modèles d'impression
Devis, factures, étiquettes, fiches d'intervention : chaque modèle imprimé se refait, en PDF généré par l'application.
Les droits d'accès
Les jeux de privilèges FileMaker règlent qui voit quoi, parfois jusqu'à l'enregistrement. Ils se transposent en rôles et en règles dans la nouvelle application, et se testent avec chaque profil d'utilisateur.
Les données
Doublons, dates saisies en texte, listes de valeurs qui ont changé au fil des années : la reprise demande un nettoyage et des migrations de test validées par le métier. La méthode est détaillée dans la reprise de données lors d'une migration de logiciel.
Migrer par étapes
- Inventaire : tables, scripts, modèles réellement utilisés, par qui. Une partie ne sert plus.
- Choix du premier module : souvent ce que FileMaker fait mal, comme le portail client ou l'accès mobile terrain.
- Prototype validé par les utilisateurs avant tout développement.
- Cohabitation : le module web lit et écrit dans FileMaker par API, ou dans une nouvelle base synchronisée.
- Bascule module par module, avec retour arrière prévu, jusqu'à l'arrêt de la base FileMaker et de ses licences.
Pour un logiciel accessible sur téléphone, voir aussi application web, PWA ou native.
Combien coûte une migration FileMaker
Le coût dépend du nombre de scripts et de modèles réellement utilisés, de la complexité des calculs, du volume des conteneurs, des intégrations et de l'état des données. Les postes de coût sont détaillés dans le prix de la refonte d'un logiciel métier.
Pour comparer honnêtement, posez les deux colonnes sur cinq ans. Côté FileMaker : licences au nombre d'utilisateurs, hébergement, développeur. Côté sur-mesure : développement, hébergement, maintenance. Le mode de paiement change aussi l'équation : un forfait à prix fixe, ou un abonnement qui évite de payer le développement d'avance, comme l'explique abonnement ou forfait pour une application.
Les erreurs fréquentes
- Recopier chaque modèle FileMaker à l'identique, alors qu'une partie ne sert plus et que d'autres se fondent en un seul écran.
- Oublier les conteneurs, et découvrir à la bascule des gigaoctets de fichiers à reprendre.
- Sous-estimer les scripts, qui portent l'essentiel des règles métier.
- Couper FileMaker le jour de la mise en service, sans période de cohabitation.
- Laisser partir le créateur de la base avant d'avoir écrit ce qu'il sait.
La check-list du dirigeant
- Combien d'utilisateurs paient une licence aujourd'hui, et combien dans trois ans ?
- Qui, à l'extérieur, devrait accéder au logiciel ?
- Combien de scripts et de modèles servent chaque semaine ?
- Où sont stockés les fichiers : dans la base ou à côté ?
- Quelles intégrations sont indispensables ?
- Qui peut valider les règles métier de la nouvelle application ?
- Où sera-t-elle hébergée ? Voir l'hébergement d'une application métier en France.
Par où commencer
Rassemblez des captures des modèles les plus utilisés, la liste des scripts importants et, si possible, un export de la structure. Un premier échange suffit alors à dire si WebDirect, une application à côté ou une reconstruction vous convient.
Chez LPR Studio, cet échange débouche sur un prototype visuel gratuit du premier module web, présenté en visio sous 5 jours ouvrés : vos équipes voient leur futur écran avant toute décision. La démarche est expliquée dans voir son logiciel avant de le payer.