Un fichier n’est pas une architecture

L’application des contraintes est impossible dans un espace d’exécution partagé. Cet article en fait la démonstration — et identifie ce qui change cette condition.

L’article 4 a dérivé une structure. Trois rôles. Trois couches. Des chemins interdits entre elles. Ce point est établi.

Dériver n’est pas garantir.

Ce n’est pas un détail. C’est ce qui reste à résoudre. Une structure qui ne peut pas être garantie n’est pas une structure — c’est une intention. Et l’intention est exactement ce que les contraintes ont été conçues pour remplacer.

Cet article identifie la raison pour laquelle l’application des contraintes est impossible à l’intérieur d’un fichier FileMaker unique, et introduit le seul mécanisme structurel qui change cette condition.

Nouveaux concepts introduits

• Espace d’exécution partagé
• Frontière de fichier
• Système contrôlable

Un espace d’exécution partagé

Un fichier FileMaker unique n’est pas simplement un endroit où les responsabilités se mélangent. C’est un espace d’exécution partagé.

Ce terme est précis. Il signifie : le contexte est partagé, l’état est partagé, le graphe d’appels est partagé, et l’accès en écriture est partagé. Chaque partie du système opère à l’intérieur de la même frontière, avec une visibilité sur tout le reste et un accès à tout le reste.

De cette topologie découlent cinq conditions structurelles — non pas comme des erreurs, non pas comme des cas limites, mais comme des permanences.

Le contexte implicite est toujours possible. N’importe quel script peut être appelé depuis n’importe quel modèle. Il n’existe aucun mécanisme à l’intérieur d’un fichier pour vérifier que le modèle fournissant le contexte est celui que le script suppose. L’appel réussit que le contexte soit correct ou non. Le script ne peut pas faire la différence.

La mutation non contrôlée est toujours possible. N’importe quel script peut écrire dans n’importe quelle rubrique dans les limites de ses privilèges. FileMaker ne fournit aucun mécanisme pour restreindre les écritures selon le rôle architectural ou le chemin d’exécution. Si un script peut atteindre une rubrique, il peut y écrire. Il n’existe rien dans l’espace partagé qui rende un auteur d’écriture autoritaire et un autre illégitime.

Le couplage implicite est toujours possible. Les scripts peuvent appeler d’autres scripts depuis n’importe quel endroit du fichier. Il n’y a pas de déclaration de dépendance. Il n’y a pas de frontière à franchir. Un script qui en appelle un autre crée un couplage qui est invisible jusqu’à ce que cet appel échoue ou que la dépendance change.

L’état ambiant est toujours possible. Les variables globales sont visibles par tous les scripts et tous les modèles à l’intérieur d’un fichier. Elles peuvent être définies depuis n’importe quel point de l’exécution. Rien ne gouverne le moment où elles sont définies, ce qu’elles contiennent, ni ce qui les lit. Une valeur placée par un script est immédiatement disponible — et silencieusement disponible — pour tous les autres.

La fuite de logique d’interface est toujours possible. Rien dans un espace d’exécution partagé n’empêche un script d’interface de contenir une règle métier. Il n’existe pas de surface structurelle qui rendrait la violation visible avant qu’elle soit déjà intégrée.

Le point critique n’est pas que ces choses se produisent. C’est qu’elles sont toujours disponibles. Elles n’exigent pas d’erreur. Elles exigent seulement qu’aucune frontière n’existe pour les empêcher.

La limite absolue

Voici la phrase pour laquelle cet article existe :

Aucune contrainte architecturale ne peut être appliquée dans un espace d’exécution partagé.

Pas : difficile à appliquer. Pas : exige une discipline rigoureuse. Pas : fonctionne si l’équipe est prudente.

Impossible à appliquer — de façon fiable, structurelle, permanente.

Une contrainte ne s’applique pas par intention. Elle exige un mécanisme. Un mécanisme soit empêche une violation, soit il ne le fait pas. Dans un espace d’exécution partagé, aucun mécanisme n’empêche l’une des cinq conditions listées ci-dessus. Elles sont disponibles à tout moment, depuis tous les points du système.

La discipline n’est pas un mécanisme. C’est une propriété d’une personne à un moment donné. Elle se dégrade sous la pression du temps. Elle est absente quand un développeur différent touche le code. Elle ne survit pas à une réécriture. Elle ne laisse aucune trace quand elle échoue. Une contrainte qui dépend de la discipline n’est pas une contrainte — c’est un espoir.

Les contraintes établies dans l’article 2 ne peuvent pas être appliquées par la discipline. Elles exigent un mécanisme qui tient indépendamment de qui construit, de ce qu’il se rappelle, et du temps dont il dispose.

À l’intérieur d’un fichier FileMaker unique, un tel mécanisme n’existe pas.

Ce qui ressemble à un mécanisme

Avant d’identifier ce qui change l’espace d’exécution, les alternatives doivent être éliminées — parce qu’elles sembleront suffisantes et ne le sont pas.

Les conventions de noms. Un script nommé DATA_WriteRecord et un script nommé UI_ShowRecord sont deux scripts à l’intérieur d’un espace d’exécution partagé. Les noms sont des étiquettes. Ils n’appliquent rien. N’importe quel script peut appeler l’un ou l’autre. N’importe quel modèle peut invoquer l’un ou l’autre. Le nom est de la documentation. La documentation n’est pas une application des contraintes.

L’organisation en dossiers. FileMaker permet d’organiser scripts et modèles en dossiers. Un dossier est un regroupement visuel. Il ne restreint pas l’accès. Il n’isole pas l’exécution. Il n’empêche pas un script dans un dossier d’appeler un script dans un autre, ni d’écrire dans une table associée à une couche différente. Un dossier n’applique rien architecturalement.

Le regroupement de scripts. Regrouper des scripts liés — que ce soit par dossier, préfixe de noms ou en-tête de commentaire — produit le même résultat que l’organisation en dossiers. Le regroupement est organisationnel. L’organisation n’est pas de l’isolation.

Les jeux de privilèges. Le modèle de sécurité de FileMaker contrôle ce à quoi les utilisateurs peuvent accéder. Les jeux de privilèges peuvent restreindre les tables qu’un utilisateur peut lire, les modèles vers lesquels il peut naviguer, les scripts qu’il peut exécuter. C’est du contrôle d’accès. Le contrôle d’accès et l’application des contraintes architecturales ne sont pas la même chose. Un jeu de privilèges qui empêche un utilisateur d’accéder à une table n’empêche pas ce même utilisateur d’exécuter un script avec des privilèges d’accès complet qui y accède. La restriction s’applique à l’utilisateur. Elle ne s’applique pas au chemin d’exécution. Les jeux de privilèges appliquent des frontières de sécurité. Ils ne sont pas alignés avec la séparation des couches. Ils n’empêchent pas un script d’interface de se comporter comme un script de logique, ni un modèle d’interface de contenir une règle métier.

Aucun de ces mécanismes ne modifie la topologie. L’espace d’exécution reste partagé. Les cinq conditions de défaillance restent disponibles. Les contraintes restent inapplicables.

Le seul mécanisme structurel

FileMaker n’impose pas de contraintes architecturales. Ce n’est pas une critique — c’est une description de ce qu’est la plateforme. FileMaker fournit de la flexibilité. L’application des contraintes n’est pas son rôle.

Mais FileMaker fournit un mécanisme structurel qui est pertinent ici : la frontière de fichier.

Une frontière de fichier n’est pas organisationnelle. Elle est topologique. Elle change la forme de l’espace d’exécution.

Quand le contexte, l’état, le graphe d’appels et l’accès en écriture sont répartis entre des fichiers, ils ne sont plus partagés. Un script dans un fichier ne peut pas être appelé par un script dans un autre fichier sans qu’une référence explicite à ce fichier soit définie. Un modèle dans un fichier n’a pas accès aux tables d’un autre fichier à moins qu’une relation ne soit explicitement établie. Une variable globale dans un fichier n’est pas visible par les scripts s’exécutant dans un autre fichier.

La frontière de fichier fait trois choses que les conventions de noms, les dossiers et les jeux de privilèges ne peuvent pas faire :

Elle isole la portée. Le contexte d’exécution est contenu dans le fichier dont il est originaire. Il ne franchit pas la frontière.

Elle force les références explicites. Pour qu’un fichier accède à un autre, une connexion doit être déclarée. Ce qui était implicite dans un espace partagé exige ici un acte délibéré.

Elle élimine la co-localisation. Les scripts, modèles et tables qui existent dans des fichiers différents ne peuvent pas interagir par proximité. La proximité était la condition par défaut du couplage dans un fichier unique. À une frontière de fichier, la proximité disparaît.

L’espace d’exécution partagé est remplacé par des espaces d’exécution séparés qui ne peuvent communiquer qu’à travers des connexions déclarées et visibles.

Ce qui change

Le changement n’est pas d’incorrect à correct. Le changement est de non contraint à contrôlable.

Dans un espace d’exécution partagé, les violations sont implicites et gratuites. Dans un espace d’exécution séparé, les violations exigent une action explicite.

C’est la loi structurelle qu’établit la frontière de fichier. Tout ce qui suit en dépend.

À l’intérieur d’un fichier unique, une violation est gratuite. Elle n’exige aucune action explicite. Un script écrit dans une table qu’il ne devrait pas posséder — c’est disponible par défaut. Un modèle invoque un comportement qu’il ne devrait pas contenir — c’est disponible par défaut. Une variable globale est lue sans être passée — c’est disponible par défaut. Les violations ne s’annoncent pas. Elles n’exigent pas d’intention.

Après la séparation par fichiers, une violation exige un câblage explicite. Pour franchir une frontière, une connexion doit être définie. Cette définition est visible. Elle est délibérée. Elle peut être examinée. Elle peut être bloquée.

Le système ne devient pas correct. Il devient contrôlable.

C’est le changement. Un système où les violations sont gratuites ne peut pas être gouverné. Un système où les violations exigent une action explicite le peut. La frontière de fichier n’écrit pas les règles. Elle crée la surface sur laquelle les règles peuvent être écrites et — pour la première fois — maintenues.

La condition qui existe maintenant

Le problème soulevé à la fin de l’article 4 était : la structure existe mais ne peut pas être garantie.

Cette condition a changé.

La séparation par fichiers supprime le chemin par défaut de chaque condition de défaillance. Le contexte partagé qui rendait le couplage implicite gratuit n’est plus implicitement disponible — y accéder exige un acte délibéré et déclaré. L’accès en écriture partagé qui faisait de la mutation non contrôlée une capacité par défaut n’est plus librement disponible — franchir la frontière exige un câblage explicite. L’état ambiant qui était visible par l’ensemble du système depuis n’importe quel point n’est plus accessible sans connexion définie.

Ces propriétés ne sont pas imposées par FileMaker. Ce sont des contraintes architecturales que la séparation par fichiers rend possible d’imposer — et possible, pour la première fois, de maintenir.

L’application des contraintes est maintenant possible.

Elle n’est pas encore implémentée. Ce que les espaces séparés doivent contenir, comment ils doivent interagir, et quelles règles gouvernent ces interactions — c’est le travail qui commence à l’article 6. La frontière crée la précondition. Elle n’effectue pas l’application.

La structure peut maintenant être appliquée. Elle ne l’est pas encore.

C’est là que commence le prochain article.

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.