Développer avec FileMaker — Au-delà du simple “ça fonctionne”

Ce que signifie qu’un système soit correct — dans une plateforme où l’application des contraintes est la responsabilité du développeur — est la question que cet article pose.

FileMaker tient ses promesses. On peut livrer quelque chose de fonctionnel rapidement. Relier des tables, bâtir des modèles, écrire des scripts — sans architecture formelle, sans infrastructure. Le résultat fonctionne. Le client est satisfait.

Ce n’est pas un accident. C’est ce que la plateforme a été conçue pour faire. Un environnement peu contraignant, capable de transformer une idée qu’on a eue le matin en application fonctionnelle le soir.

C’est toute une force. La plateforme exécute aussi bien des implémentations rigoureuses que celles reposant sur des hypothèses implicites, sans jamais signaler la différence.

Mais cette même neutralité envoie un signal trompeur : ça fonctionne, donc c’est correct.

Ce n’est pas la même chose.

Nouveaux concepts introduits

• Système correct

Ça fonctionne — mais est-ce correct ?

Certains environnements imposent la structure. Les dépendances doivent être déclarées. Le contexte doit être explicite. La discipline est une condition d’exécution.

FileMaker ne fonctionne pas comme ça.

Il exécutera un script mal conçu avec la même neutralité qu’un script rigoureux. Il ne fait pas de distinction entre une décision de conception délibérée et une hypothèse implicite jamais remise en question.

Ce que FileMaker fait, c’est exécuter. Pas évaluer.

Un système correct est un système dont le comportement demeure prévisible même lorsque les conditions qui l’entourent changent. Il demeure prévisible, compréhensible et modifiable en toute confiance — non pas parce que rien ne change, mais parce que le changement ne remet pas en cause les hypothèses sur lesquelles il repose.

Produire le bon résultat aujourd’hui ne rend pas un système correct. Un système correct continue de produire un comportement prévisible demain — quand le contexte change, quand quelqu’un d’autre y touche, quand une hypothèse implicite cesse d’être vraie.

L’écart entre fonctionnel et correct n’est visible nulle part dans la plateforme. Il apparaît plus tard — des mois ou des années après la livraison, quand les besoins ont changé, quand quelqu’un d’autre doit comprendre ce qui a été construit, ou quand une modification en apparence anodine produit un comportement que personne n’attendait.

La longévité ne s’improvise pas. Elle exige une discipline que FileMaker n’impose pas.

C’est au développeur de la définir.

Comment la fragilité s’installe

Elle ne s’installe pas brutalement.

Un script suppose qu’il s’exécute sur un modèle précis — ça fonctionne, jusqu’à ce qu’il soit appelé depuis un autre contexte. Une variable globale définie quelque part est disponible — jusqu’à ce qu’elle ne le soit plus. Un ensemble trouvé supposé contenir les bons enregistrements les contient — jusqu’à ce qu’une modification en amont change l’ordre des opérations.

Rien n’explose. Le système ne casse pas franchement.

Il devient imprévisible.

Et l’imprévisibilité a un coût précis : on arrête de toucher au code avec confiance. Chaque modification devient un risque. On se demande est-ce que ça va casser autre chose ? sans avoir de réponse certaine.

Le problème n’est pas la compétence individuelle. Un développeur rigoureux peut gérer tout ça — être attentif au contexte, documenter les dépendances, tester les chemins d’exécution. Ça fonctionne, jusqu’à un certain point.

Mais la rigueur manuelle ne se transfère pas. Elle ne se lit pas dans le code. Elle ne survit pas au temps.

Ce que le système accumule sans le dire finit par coûter plus cher que ce qu’il a permis de construire.

Ce que cette série propose

Cette série ne documente pas FileMaker. Elle documente une façon de construire avec lui.

La distinction est importante. FileMaker n’est pas le problème. C’est plutôt l’absence de contraintes qui lui sont imposées qui l’est. Et cette absence doit être comblée par le développeur — pas par FileMaker.

Cette série raisonne à partir du comportement réel de FileMaker — le contexte implicite, l’état ambiant, l’exécution non contrainte. Elle identifie les contraintes qu’un système doit satisfaire pour rester correct dans le temps. À partir de ces contraintes, elle fait découler l’architecture nécessaire pour y répondre. Non comme une recommandation, mais comme la conséquence desdites contraintes.

Cette architecture a un coût. Elle est plus lente à mettre en place. Elle exige plus de rigueur en amont.

Mais pour un système destiné à durer, c’est — à ce stade de mon expérience — la meilleure direction que je connaisse.

Pas pour tous les contextes

Un prototype, un outil interne à usage occasionnel, une solution à durée de vie limitée — FileMaker natif suffit largement. La vitesse de développement prime. L’architecture serait du gaspillage.

Ce blog s’adresse à l’autre situation : un système destiné à durer, à évoluer, à passer entre plusieurs mains.

Je ne m’adresse pas à un type de développeur. Je m’adresse à une situation.

La vraie question n’est pas est-ce que ça fonctionne ?

C’est est-ce que ça va continuer à fonctionner ?

FileMaker exécute.

Ce que le système devient dépend des décisions prises avant que les problèmes apparaissent.

Cet article reflète ma propre expérience et ma perspective. De nombreuses idées ici ont été façonnées par des contributions venues de forums, de communautés, de blogues et de livres blancs. Des outils d'IA ont été utilisés comme assistant à la rédaction pour structurer et affiner le contenu.