🗃️ FileMaker (Claris) — RAD Desktop/Web pour PME

FileMaker (Claris) — overview “densifié” (mental model + stack + décisions)

Mental model (à retenir)

Data-centricl’app se structure autour des tables/relations + écrans (layouts)

Layoutsécrans UI : listes, formulaires, tableaux, fiches, navigation

Scriptsautomatisation : règles, workflow, import/export, opérations batch

Privilege setsRBAC : qui voit quoi, qui écrit quoi, sur quels objets

ClientsDesktop / Mobile / Web (WebDirect) selon le besoin

IntégrationsREST (Data API), OData, Admin API

Pourquoi les PME adorent

Facteur	Effet	Ce que ça remplace
Time-to-CRUD	app utilisable très vite	Excel/Access + scripts “maison”
Évolutif	on ajoute écrans/règles progressivement	développement web “full stack” lourd
Métier-friendly	collab métier/dev plus fluide	spécifications longues et rigides

Le positionnement “WinDev simplifié” (très concret)

Si WinDev = RAD puissant + riche + large spectre,
FileMaker = RAD orienté "PME & data apps" :
- On va très vite sur CRUD + workflows simples
- UX correcte sans front web complexe
- Publication Desktop/Mobile/Web (WebDirect)
- Intégrations via REST/OData si besoin

FileMaker est “redoutable” quand le besoin = outil métier internalisé (ops, admin, suivi, planning, stock), pas quand tu veux un produit web public ultra sur-mesure.

Décision rapide (go / no-go)

Go si : PME, besoins CRUD + reporting + workflows, time-to-market prioritaire.
Benchmark si : UX web extrême, contraintes API-first strictes, volumétrie très élevée, microservices imposés.

1.1 Définition — ce que FileMaker sait faire “vraiment vite” (et pourquoi)

Définition “engineering”

FileMaker (Claris) est une plateforme RAD/low-code pour construire des apps data-centric : on définit le modèle de données, on construit des layouts (écrans), on automatise via scripts, et on gouverne par privilege sets. Ensuite on déploie en desktop/mobile/web selon l’hébergement.

CRUD ultra rapide

Apprentissage rapide

Web via WebDirect

REST/OData

Les “briques” à connaître

Brique	Rôle	Erreur fréquente
Tables/Relations	source de vérité	relations “magiques” non documentées
Layouts	UX + contexte de données	tout mettre sur 1 écran énorme
Scripts	logique & automatisation	copier/coller de scripts partout
Privilege sets	sécurité RBAC	dépôts en prod sans durcissement
Hosting	publier & partager	pas de runbook (backup/SSL)

Promesse (bien cadrée)

Promesse FileMaker :
- Un outil métier utilisable très vite (CRUD + recherche + reporting)
- Un cycle “itératif” : on ajoute tables/écrans/règles au fil de l’eau
- Une publication multi-canal : desktop, mobile, web (selon hosting)
- Une intégration possible avec le SI (REST/OData) quand nécessaire

Condition de réussite :
- modèle data propre
- scripts centralisés (pas spaghetti)
- droits (privilege sets) cadrés
- exploitation (backup/SSL/upgrade) maîtrisée

Sans gouvernance, FileMaker peut devenir un “Excel++” : rapide… puis fragile.

Forces (PME / SI interne)

Force	Pourquoi	Résultat
Time-to-CRUD	layouts + champs + navigation	outil interne prêt en jours
Courbe faible	concepts proches du métier	collab métier/dev fluide
Itératif	on ajoute sans “big bang”	ROI rapide
Multi-canal	desktop/mobile/web	adoption terrain
Intégrable	REST/OData + admin API	connexion au SI

Ce que tu construis “très vite”

- Base “référentiel” (clients, produits, fournisseurs)
- Gestion d’interventions (tickets, statut, planning)
- Suivi stock / inventaire (entrées/sorties)
- Back-office administratif (demandes, validations)
- Reporting simple (listes, exports)
- Portail interne web (WebDirect) pour consultation/édition

Limites / risques

Web : WebDirect est pratique, mais ce n’est pas “un framework web natif” (UX très custom = coût ↑).
Spaghetti scripts : trop de scripts dispersés = maintenance difficile.
Modèle data : relations mal pensées = bugs logiques + lenteur + incohérences.
Ops : sans runbook (backup/SSL/upgrades), tu crées un risque prod.
Lock-in : modèle et runtime liés à la plateforme (à gérer par contrats d’intégration).

Anti-pattern #1 (classique PME)

Symptômes :
- 1 fichier unique gigantesque
- scripts copiés/collés (pas de “services”)
- droits trop larges
- pas d’environnements (dev=prod)
- backups non testés

Résultat :
- bug critique = panique
- impossible de refactor

Remède

- structurer : "domain scripts" + conventions de nommage
- privilege sets stricts
- dev/test/prod (au minimum)
- runbook : backup/restore drill + SSL + upgrade plan

Décision (checklist)

Question	Si “Oui”	Sinon
App interne PME data-centric ?	FileMaker très bon choix	benchmark
Time-to-market prioritaire ?	ROI rapide	web custom possible mais + cher
Web principalement ?	WebDirect OK selon besoin	si UX extrême → framework web
SI intégrations ?	REST/OData possibles	API-first strict → architecture dédiée

Architecture & déploiement — clients, hébergement, web (WebDirect), intégrations (REST/OData)

Topologie “typique”

[Clients]
- Desktop (FileMaker Pro)
- Mobile (FileMaker Go)
- Web (WebDirect via navigateur)
        |
        v
[Hosting]
- FileMaker Server (self-hosted)
  ou
- FileMaker Cloud (managed)

Le choix clé : “où on héberge” (Server/Cloud) et “comment on accède” (desktop/mobile/web).

Pourquoi ça marche en PME

Tu peux démarrer en petit (équipe) puis ouvrir à plus d’utilisateurs via hosting.
Tu gardes une UX “app” en desktop et tu ajoutes le web si besoin (WebDirect).
Tu ajoutes des intégrations SI quand le besoin arrive (REST/OData).

Risque majeur : architecture “sans garde-fous”

- pas de séparation environnements
- pas de runbook
- pas de gouvernance scripts/droits
=> la prod devient fragile

WebDirect — “FileMaker dans un navigateur”

WebDirect permet d’interagir avec une app FileMaker via navigateur,
en hébergeant l’app sur FileMaker Server ou FileMaker Cloud.

Bon pour :
- portails internes
- consultation/édition “simple”
- déploiement rapide sans coder un site web

À cadrer :
- UX très custom = efforts CSS/JS/archi ↑
- dimensionnement serveur + SSL + monitoring

Data API (REST JSON) — lecture/écriture

Use-cases :
- synchroniser avec un SI (ERP/CRM)
- exposer des opérations à une app web externe
- automatiser import/export

Principe :
- token auth
- opérations CRUD + find
- échanges JSON via HTTP(S)

OData + Admin API (automation)

OData :
- accès “data-centric” (clients BI / outils data)

Admin API :
- automatiser tâches d’admin (selon hosting)
- utile pour ops / provisioning / monitoring

Cloud vs self-hosted (PME)

Option	Avantages	Inconvénients
Cloud	moins d’ops, rapide	moins de contrôle infra
Self-hosted	contrôle, intégrations réseau	runbook obligatoire (backup/SSL/upgrade)

CRUD ultra rapide — pourquoi FileMaker va si vite (layouts, listes, formulaires, recherche)

Le “pipeline” FileMaker (PME)

1) Créer tables + champs
2) Créer relations (si nécessaire)
3) Construire layouts :
   - Liste (list view)
   - Fiche (detail/form)
   - Recherche / filtre
4) Ajouter scripts :
   - validations
   - navigation
   - actions (create/update/close)
5) Définir droits (privilege sets)
6) Publier (Server/Cloud) + Web (WebDirect)

Le temps gagné vient du fait que l’UI “data app” est nativement prévue.

Quality gates (sinon tu paies plus tard)

Conventions : noms de tables/champs/scripts/layouts.
Scripts centralisés : éviter “20 scripts presque identiques”.
Droits : RBAC strict dès le départ (ne pas “ouvrir tout”).
Runbook : sauvegarde/restauration testées.

Astuce :
- séparer "UI scripts" (navigation)
  et "domain scripts" (règles)
=> maintenabilité ++

Courbe d’apprentissage faible — comment onboarder une PME (méthode)

Onboarding en 3 couches

Couche	Objectif	Livrable	Durée
1) Métier	définir les écrans & règles	workflow + maquettes	1–2 jours
2) Data	modèle propre	tables/relations + dictionnaire	1–2 jours
3) Build	layouts + scripts + droits	POC utilisable	2–5 jours

Standard PME (simple et efficace)

- 1 layout "LIST" par entité
- 1 layout "FORM" par entité
- 1 script "SAVE" (domain) par entité
- 1 script "NAV" (UI) commun
- privilege sets : ADMIN / MANAGER / USER / READONLY
- exports & backups planifiés

Modèle de données & relations — la base de la robustesse (design patterns)

Règle #1 : le modèle data prime sur l’UI

- champs typés + validations
- clés stables (ID)
- relations explicites (pas "magiques")
- dictionnaire de données (document)

Si ton schéma est propre, tout le reste devient simple (scripts, droits, layouts).

Le “contexte” des layouts

Un layout a un contexte (table/occurrence).
Conséquence :
- un champ affiché dépend du contexte
- les scripts doivent être disciplinés
- sinon : bugs logiques “incompréhensibles”

Patterns PME (pratiques)

Pattern 1 — Master/Detail

Client (master)
  -> Commandes (detail)
  -> Factures (detail)

Layouts :
- CLIENT_LIST / CLIENT_FORM
- CMD_LIST (portal) / CMD_FORM
Scripts :
- client.save
- cmd.save

Pattern 2 — Workflow par statuts

Ticket.status :
- NEW -> IN_PROGRESS -> DONE -> ARCHIVED

Règles :
- transitions autorisées selon rôle
- audit : qui a changé quoi
- validations : champs requis selon statut

Quality gates (anti-futur chaos)

Conventions : tables (T_), layouts (L_), scripts (S_), privilege sets (PS_).
Éviter les dépendances implicites : documenter relations & scripts.
Refactoring : 1 fois/sem (scripts communs, duplication).
Tests : scénarios métiers “golden path” + droits.

Scripts & logique métier — structurer pour éviter le “spaghetti” (PME → scale)

Architecture de scripts (recommandée)

1) Domain scripts (source de vérité)
- entity.save
- entity.validate
- entity.transition_status

2) UI scripts (navigation/UX)
- nav.open_form
- nav.go_list
- ui.toast

3) Integration scripts (imports/exports/API)
- sync.pull_from_api
- sync.push_to_api

Séparer “métier” et “UI” = le truc le plus rentable sur 12 mois.

Workflows (statuts + validations)

Approche :
- Table: T_TICKET (status, owner, due_date, ...)
- Script: ticket.transition(new_status)
  - check rights
  - check required fields
  - write audit
  - apply state change
- Layouts: list + form + admin

Contrat d’erreurs (simple PME)

- user_message : message affichable
- tech_message : logs
- code : VALIDATION | AUTH | CONFLICT | TECH
- corr_id : pour support (si possible)

But :
- support plus rapide
- moins de “bugs fantômes”

WebDirect — publier sur le web sans réécrire l’app (cadrage, bons usages, limites)

Ce que WebDirect apporte

- Accès via navigateur à une app FileMaker hébergée
- Expérience proche d’une “app” (pas juste des pages HTML)
- Déploiement rapide pour utilisateurs internes/externes contrôlés

WebDirect = accélérateur : tu n’écris pas un site web, tu publies une “app data”.

Bonnes pratiques (PME)

Prévoir des layouts “web-friendly” (simplicité, champs visibles, navigation claire).
Limiter les écrans trop chargés.
Soigner l’hébergement (SSL, dimensionnement, monitoring).
Tester : scénarios métiers + droits + performance.

Intégrations — Data API (REST), OData, Admin API (automatiser l’ops)

Data API (REST JSON) — l’essentiel

- API REST pour accéder aux bases hébergées (Server/Cloud)
- opérations : create/update/delete/get/find
- auth par token
- payloads JSON

Use-cases :
- synchroniser ERP/CRM
- app web externe (front séparé)
- automatisations (imports batch)

Conseils d’architecture

Définir un “contrat” : endpoints/objets/erreurs.
Limiter la surface d’écriture (droits + validations).
Journaliser les opérations critiques (audit).
Prévoir rate limiting côté infra si exposé.

OData — pourquoi c’est utile

OData sert souvent à brancher :
- des outils data/BI
- des clients qui parlent OData nativement

Idéal quand tu veux "consommer de la donnée"
plutôt que coder une intégration sur mesure.

Admin API — automatiser l’administration

Admin API (REST) :
- tâches d’administration FileMaker Server/Cloud (selon périmètre)
- utile pour ops : provisioning, scripts, monitoring, intégrations outillage

Patterns d’intégration (PME)

Pattern 1 — Sync “pull”

- une tâche planifiée récupère données ERP
- écrit/merge dans FileMaker
- journalise
- alerte si conflit

Pattern 2 — UI FileMaker + portail web externe

- FileMaker = back-office (ops)
- Web externe = front public
- Data API = contrat REST
- gouvernance : RBAC + audit + rate limit

Sécurité — Auth, privilege sets (RBAC), chiffrement, SSL/TLS, hardening

Carte sécurité (PME “clean”)

Authenticationcomptes, AD, OAuth (selon setup)

Privilege setspermissions par rôle (lecture/écriture/admin)

Chiffrementau repos + en transit

Hosting hardeningmise à jour, backups, logs

API securitytokens, droits, audit, rate limit si exposé

Authentication (options)

Approches (selon plateforme) :
- comptes internes
- intégration annuaire (ex: AD) ou fournisseurs OAuth
- Cloud : accès géré via comptes/identités selon politique

But :
- simplifier l’accès
- centraliser la gestion des identités

Privilege sets (RBAC) — indispensable

Exemple PME :
- PS_ADMIN     : admin + maintenance
- PS_MANAGER   : lecture/écriture + validations
- PS_USER      : écriture limitée
- PS_READONLY  : consultation

Règle :
- tout ce qui est sensible est interdit par défaut
- on ouvre seulement ce qui est requis

Chiffrement (au repos / en transit)

Objectif :
- protéger les fichiers/bases sur disque (encryption at rest)
- protéger les échanges réseau (TLS/SSL)

À cadrer :
- politiques de clés
- accès admin
- backups chiffrés si requis

SSL/TLS — non négociable si accès réseau

Bonnes pratiques :
- activer SSL/TLS
- certificat valide (ou Let's Encrypt selon setup)
- forcer TLS sur accès web / API
- documenter rotation/renouvellement

Checklist sécurité “prod”

RBAC : privilege sets définis + testés.
Auth : annuaire/OAuth si besoin, sinon comptes robustes.
Chiffrement : au repos + en transit selon exigences.
SSL/TLS activé + certificats gérés.
Backups planifiés + tests de restauration.
API : tokens + droits + audit + rate limiting si exposé.
Upgrades : plan et fenêtre de maintenance.

Ops / exploitation — backups, upgrades, monitoring, disponibilité (PME)

Runbook minimal (à avoir)

- backups : fréquence + rétention
- restore drill : test mensuel (au minimum)
- upgrades : stratégie (dev/test/prod)
- SSL : installation + renouvellement
- monitoring : disponibilité + erreurs + perf
- gestion accès admin

Le plus gros risque PME, ce n’est pas le dev : c’est l’exploitation sans discipline.

Cloud vs self-host (ops)

Point	Cloud	Self-host
Maintenance	réduite	à gérer
SSL	souvent simplifié	runbook obligatoire
Backups	cadrés	à concevoir/tester
Contrôle	moins	plus

ALM / Gouvernance — standards, environnements, releases, quality gates

DEV / TEST / PROD (même en PME)

Minimum viable :
- DEV : construction + refactor
- TEST : validation métier + droits + perf de base
- PROD : stabilité + backups + monitoring

Règle :
- jamais d’édition “directe” en prod

Standards (anti-spaghetti)

Conventions :
- Tables : T_*
- Layouts : L__LIST / L__FORM
- Scripts domain : S__SAVE / S__VALIDATE
- Scripts UI : S_UI_*
- Privilege sets : PS_ADMIN / PS_MANAGER / PS_USER / PS_READONLY

Quality gates :
- revue scripts (duplications)
- test droits
- test restore

Release simple (PME)

1) figer version DEV
2) tester (scénarios + droits)
3) sauvegarde complète PROD
4) déployer
5) smoke tests
6) monitoring post-release

Use-cases & anti-usecases — où FileMaker brille (et où il faut benchmarker)

Use-cases (PME)

Outils internes : suivi dossiers, logistique, planning, interventions, inventaires.
Back-office admin : demandes/validations, référentiels, reporting basique.
Portails internes (WebDirect) : consultation + édition contrôlée.
Prototypage rapide d’un processus métier avant industrialisation.

Anti-usecases / benchmark

Produit web public avec UX “pixel-perfect” complexe + SEO + front très custom.
API-first strict : microservices, contrats très industrialisés (possible, mais prévoir architecture dédiée).
Volumétrie extrême + exigences de performance web natives (faire un POC perf).

Règle : si “outil métier PME”, FileMaker est souvent un choix gagnant.

Tradeoffs — vitesse vs architecture, web vs desktop, lock-in vs intégrations

Tradeoffs (très concrets)

Choix	Gains	Coûts	Mitigation
Low-code rapide	time-to-app	risque spaghetti	standards + scripts centralisés
WebDirect	web sans réécrire	UX très custom = coût ↑	layouts web-friendly + POC
Plateforme	productivité	lock-in	contrats REST/OData + découplage

Quickstart POC 5 jours — “PME-ready” (data + layouts + droits + web + API + runbook)

Plan 5 jours (dense et efficace)

Jour	Objectif	Livrable	Critère
J1	Modèle data	tables + relations + dictionnaire	cohérence “métier”
J2	Layouts CRUD	6 layouts (LIST/FORM x 3 entités)	UX claire
J3	Scripts domain	save/validate + workflow statuts	règles centralisées
J4	Sécurité + Web	privilege sets + WebDirect	droit & accès ok
J5	API + Ops	Data API POC + runbook backup/SSL	prod-like minimal

Smoke tests (PME)

- créer/modifier/supprimer (3 entités)
- workflow : transitions + droits
- WebDirect : accès + édition simple
- backups : déclencher + restaurer sur un environnement de test
- API : read + write sur 1 objet, audit minimal

Cheat-sheet FileMaker — règles “anti-galère” (PME)

20 règles “prod”

Modèle data propre (ID, validations, relations documentées).
Layouts simples (pas “monolithes”).
Scripts centralisés (domain vs UI).
Conventions de nommage strictes.
Privilege sets (RBAC) dès le début.
Ne jamais accepter “admin pour tout le monde”.
DEV/TEST/PROD même en PME.
Pas d’édition directe en PROD.
Backups planifiés + restore drills (testés).
SSL/TLS activé pour accès réseau.
WebDirect : layouts web-friendly, charge contrôlée.
API : limiter surface d’écriture, auditer.
Rate limit si API exposée.
Plan d’upgrade + rollback.
Monitoring disponibilité + erreurs + perf de base.
Audit des changements de statuts (workflows).
Refactor scripts hebdo (duplications).
Documentation légère : dictionnaire data + runbook.
Support : corrId/erreurs standardisées si possible.
POC perf si volumétrie importante.

Résumé (à coller dans IDEO-Lab)

FileMaker (Claris) = RAD Desktop/Web pour PME
- ultra rapide sur CRUD + outils internes
- apprentissage facile, approche "écrans + données + règles"
- web via WebDirect (hosting Server/Cloud)
- intégrations via Data API (REST JSON), OData, Admin API
- succès = modèle data + scripts centralisés + RBAC + runbook ops

🗃️ FileMaker (Claris) — RAD Desktop/Web pour PME

FileMaker — définition + promesse

Architecture & déploiement

Ultra rapide sur CRUD

Courbe d’apprentissage faible

Modèle de données & relations

Scripts & logique métier

WebDirect (Web)

Intégrations (REST / OData / Admin API)

Sécurité (vraie)

Ops / exploitation

ALM / gouvernance

Use-cases & anti-usecases

Tradeoffs (réalistes)

Quickstart (POC 5 jours)

Cheat-sheet opérationnel