Blog
Notes techniques sur le développement FileMaker
Ce blogue porte sur l'architecture FileMaker. Il s'adresse aux développeurs FileMaker.
Il s'agit d'une tentative de dériver, à partir de contraintes architecturales, un modèle cohérent pour construire des systèmes qui demeurent prévisibles, compréhensibles et maintenables dans le temps.
Les idées présentées ici ne sont pas nouvelles dans la communauté FileMaker. Je ne prétends pas les avoir inventées. Elles reflètent le travail de nombreux développeurs qui ont contribué, au fil des années, à notre savoir collectif. Elles sont présentées ici à travers le modèle architectural développé tout au long de cette série.
Les idées explorées ici sont ancrées dans des systèmes en production. Cette série développe et formalise une architecture qui continue d'évoluer au contact de projets réels.
La réflexion se nourrit de la discussion. Les questions, les critiques constructives et les points de vue différents sont toujours les bienvenus.
— Karim Hanafi
24 juin 2026
Systèmes FileMaker maintenables · Article 10 sur 18
Modèle d'exécution : rôles
Une enveloppe de requête porte une adresse. Quelque chose doit la lire. L'espace entre l'enveloppe et la méthode n'est pas vide — il a une forme définie.
15 juin 2026
Systèmes FileMaker maintenables · Article 9 sur 18
Les contrats : la surface de communication
Une méthode sans contrat est une unité de comportement sans surface. L'architecture a défini la méthode. Elle n'a pas encore défini comment la méthode communique.
9 juin 2026
Systèmes FileMaker maintenables · Article 8 sur 18
Les méthodes : l'unité contractuelle
La structure n'a plus d'endroit où cacher le comportement. Ce qui reste n'est pas un choix de conception. C'est la seule chose qui n'a jamais été exclue.
6 juin 2026
Systèmes FileMaker maintenables · Article 7 sur 18
Le graphe, le nommage et le schéma comme surfaces contrôlées
L'article 6 permettait les lectures interface. L'article 7 contraint ce que ces lectures peuvent signifier. Trois surfaces observables — graphe, nommage, schéma — sont placées sous la même discipline d'application.
26 avril 2026
Systèmes FileMaker Maintenables · Article 6 sur 18
Construire le squelette
La structure physique est connue. Cet article lui donne forme. Trois types de fichiers, chacun avec un rôle, chacun avec des contraintes qui découlent de ce rôle.
16 avril 2026
Systèmes FileMaker Maintenables · Article 5 sur 18
Un fichier n'est pas une architecture
Aucune contrainte architecturale ne peut être appliquée dans un espace d'exécution partagé. La frontière de fichier est le seul mécanisme structurel qui change cette condition. Cet article en établit la preuve.
10 avril 2026
Systèmes FileMaker Maintenables · Article 4 sur 18
La structure que les contraintes exigent
Les contraintes n'excluent pas seulement des comportements. Elles exigent une structure. Cette structure peut être décrite. Elle ne peut pas encore être garantie.
7 avril 2026
Systèmes FileMaker Maintenables · Article 3 sur 18
Comment les solutions FileMaker s'effondrent sous leur propre logique
Les défaillances ne sont pas aléatoires. Chacune est la conséquence prévisible d'une contrainte violée. Une fois le mécanisme vu, on ne peut plus ne pas le voir.
31 mars 2026
Systèmes FileMaker Maintenables · Article 2 sur 18
Ce que des décennies de génie logiciel peuvent apprendre à un développeur FileMaker
Les défaillances qui tuent les systèmes FileMaker ne sont pas des problèmes FileMaker. Ce sont des problèmes de systèmes — et le génie logiciel les a résolus il y a longtemps.
24 mars 2026
Systèmes FileMaker Maintenables · Article 1 sur 18
Développer avec FileMaker — Au-delà du simple "ça fonctionne"
Les limites du modèle natif FileMaker — pourquoi un système peut fonctionner tout en restant fragile.