Lors du développement d'une application métier, l'accent est d'abord mis sur les tâches visibles. On crée des tables, on définit des relations, on conçoit des formulaires de saisie et on automatise les processus opérationnels. Dès que les premiers utilisateurs peuvent travailler avec la solution, une grande partie du projet semble être achevée. C’est toutefois lors de la mise en œuvre pratique que commence la phase la plus exigeante à long terme. Une application métier doit être maintenue, étendue et adaptée aux nouvelles exigences. Les modifications doivent être documentées, les nouvelles versions déployées et les données existantes transférées en toute sécurité. À cela s’ajoutent les différents droits d’accès des utilisateurs, les sauvegardes de données, les analyses d’erreurs et la question de savoir si la solution doit être exploitée en local, sur un serveur dédié ou dans le cloud.
De nombreuses plateformes de développement se concentrent principalement sur la création de l'application proprement dite. Pour les mises à jour, la documentation, le déploiement et l'exploitation, des outils supplémentaires et des procédures spécifiques viennent s'ajouter par la suite. Au fil du temps, il en résulte un environnement technique composé de nombreux éléments distincts, que seul un effort considérable permet de maintenir cohérent. SchallOS adopte donc une approche plus globale. La plateforme est conçue pour accompagner une application métier non seulement lors de sa création, mais aussi tout au long de son cycle de vie : du développement à l'exploitation continue, en passant par la documentation et le déploiement, ainsi que les mises à jour.
Dernières actualités concernant SchallOS Studio
12.08.2026: Le développement de SchallOS se poursuit. Entre-temps, la Couche d'IA et de connaissances La plateforme est en grande partie achevée et profondément intégrée à l'environnement de développement. SchallOS dispose ainsi d'une couche de connaissances auto-apprenante qui intègre les expériences issues du développement pratique et peut s'adapter au fil du temps au style de programmation et aux solutions privilégiées par chaque développeur.
Grâce à un système d'adaptateurs ouvert, il est possible de connecter n'importe quel modèles d'IA locaux et basés sur le cloud intégrer. Pour un fournisseur ou un modèle, il est possible d'enregistrer plusieurs identifiants d'accès ou clés API. Plusieurs modèles peuvent être utilisés en parallèle et sélectionnés pour différentes tâches en fonction de leurs capacités, de leur vitesse et de leurs résultats antérieurs. Le choix du modèle s’effectue automatiquement via le Composer intégré : le développeur n’a donc pas à se soucier, pendant le développement, de déterminer quel modèle convient à quelle tâche. Les solutions déjà connues et éprouvées peuvent être réutilisées à partir de la couche de connaissances, ce qui évite de devoir traiter chaque tâche à nouveau dans son intégralité par un modèle d’IA.
Disponible directement dans SchallOS Studio agents IA spécialisés pour différentes missions de développement. Parmi celles-ci, on trouve notamment un Agent de formule pour les calculs et les formules, un Agent de conteneur de fonctions pour la programmation de conteneurs de fonctions ainsi qu'un Agent de mise en page pour le travail sur les interfaces utilisateur. Les conteneurs de fonctions peuvent en outre être modifiés directement via leurs objets de mise en page et programmés à l'aide de l'IA. Un élément de niveau supérieur Agent système peut coordonner les agents spécialisés, par exemple lorsqu'il s'agit de développer des modules entièrement nouveaux ou des fonctionnalités plus complexes.
La couche d'IA est complétée par le Adapter-Studio dans SchallOS Control. Cela permet aux développeurs de créer leurs propres adaptateurs réseau et de données, par exemple pour la connexion à des systèmes ERP externes, à des bases de données ou à des plateformes d'entreprise telles que SAP et Oracle. Les connaissances, les profils de modèles et l'expérience spécifique aux solutions nécessaires à cet effet sont gérés par version au sein de l'architecture des connaissances. SchallOS évolue ainsi progressivement d’un environnement de développement classique vers une plateforme sur laquelle les développeurs, la couche de connaissances et différents modèles d’IA collaborent à la création d’une solution logicielle.
Une couche de connaissances également destinée aux utilisateurs et aux connaissances de l'entreprise
Le domaine des connaissances ne se limite toutefois pas au développement de logiciels. Il s'étend également à Niveau « Solution » Les applications peuvent disposer de leurs propres agents d'IA, qui assistent l'utilisateur dans ses tâches quotidiennes, par exemple lors de la création de factures, de l'analyse de données ou d'autres tâches récurrentes au sein d'une solution logicielle. Une solution peut ainsi développer ses propres connaissances et les mettre à la disposition de ses agents.
Ce domaine devrait être considérablement élargi à l'avenir. Il est notamment prévu d'intégrer des connaissances provenant de différentes sources externes, par exemple des systèmes de messagerie électronique, des documents et des données d'entreprise, ainsi que via des formats d'échange standardisés tels que l'Open Knowledge Format (OKF) de Google et des graphes de connaissances comme Neo4j. De cette manière, les connaissances d’une solution SchallOS devraient, à long terme, provenir non seulement de sa base de données, mais aussi de différentes sources d’informations au sein d’une entreprise.
De la migration FileMaker vers notre propre plateforme
À l'origine, SchallOS avait pour objectif la migration des solutions FileMaker existantes. Depuis des décennies, FileMaker a fait ses preuves en tant qu'environnement performant pour les applications de bases de données personnalisées. Le lien étroit entre le modèle de données, la mise en page et la logique du programme, en particulier, permet un développement rapide et adapté aux besoins concrets.
Une solution FileMaker bien établie ne se limite toutefois pas à des tables et à des masques visibles. Elle comprend des calculs, des scripts, des droits d'utilisateur, des mises en page d'impression, des interfaces et de nombreux cas particuliers liés à l'exploitation. Une plateforme de remplacement viable doit pouvoir intégrer ces interdépendances et les gérer ensuite de manière autonome.
À partir de cette mission, SchallOS s'est progressivement transformé en une plateforme autonome. Les solutions FileMaker existantes doivent pouvoir être migrées, tandis que de nouvelles applications peuvent être développées directement dans SchallOS. Une fois la migration terminée, FileMaker ne sera plus nécessaire pour l'exploitation en production.
Le développement, l'exécution et l'exploitation restent distincts
La plateforme de développement SchallOS se compose de plusieurs domaines aux missions bien définies.
- SchallOS Studio Il s'agit de l'environnement de développement. C'est là que sont créés les structures de données, les mises en page, les formules, les fonctions, les langages et les versions. L'assistant de migration pour les solutions FileMaker existantes fait également partie du Studio.
- SchallOS Runtime exécute les applications publiées. Elle fournit l'interface utilisateur et la logique de programme nécessaire, sans pour autant mettre automatiquement à disposition tous les outils de développement.
- SchallOS Control gère les cibles de déploiement, les connexions aux bases de données, les profils d'exécution, les mises à jour et les contrôles techniques.
- SchallOS Cloud fournit des applications sous forme de service en ligne géré de manière centralisée. L'objectif n'est pas de créer un format cloud distinct. Les installations locales, sur serveur et dans le cloud utilisent toutes la même architecture de base.
Cette séparation empêche que le développement, l'exploitation et l'administration ne s'entremêlent de manière incontrôlée. Dans le même temps, tous ces domaines restent techniquement coordonnés entre eux.
Une solution adaptée à différents modèles d'exploitation
Une application d'entreprise peut démarrer à petite échelle puis évoluer par la suite. Au début, un poste de travail local unique peut suffire. Par la suite, d'autres collaborateurs, un serveur central ou plusieurs sites viendront s'ajouter. SchallOS doit donc pouvoir fournir la même solution de base pour différents modes de fonctionnement : en local dans un navigateur, en tant qu’application Windows ou macOS, avec SQLite ou PostgreSQL, ainsi qu’en tant que solution SaaS dans le cloud.
Toutes les configurations d'exploitation ne présentent pas les mêmes caractéristiques techniques. Une base de données locale impose des exigences différentes de celles d'un système centralisé multi-utilisateurs. Il est toutefois essentiel que les mises en page, les fonctionnalités et le modèle de données n'aient pas à être entièrement repensés pour chaque cible.
Le cycle de vie fait partie intégrante de l'architecture
Avec SchallOS, la documentation, les journaux d'événements et les mises à jour ne sont pas simplement ajoutés a posteriori à une application déjà finalisée. Ils font partie intégrante de l'architecture de base. La structure et les données opérationnelles sont gérées séparément. Les modifications apportées au cours du développement peuvent être consignées et regroupées en versions. Les mises à jour peuvent être vérifiées, déployées et, en cas de problème, annulées de manière contrôlée. L'IA intégrée facilite non seulement l'utilisation des formules et des fonctions, mais aussi la documentation et la communication avec les clients.
SchallOS fait ainsi le lien entre des domaines qui, dans les projets classiques, sont souvent traités séparément. Le développement d'une application ne marque plus la fin du processus technique, mais constitue la première étape d'un cycle de vie planifié à long terme.
SSC et SSD en tant que conteneurs portables de structures et de données
De nombreuses applications de bases de données stockent la structure, l'interface utilisateur, la logique du programme et les données opérationnelles au sein d'une entité étroitement liée. Si cela s'avère pratique au départ, cela complique toutefois les mises à jour ultérieures, les migrations et les différents modes de fonctionnement. Dès que plusieurs clients, des volumes de données plus importants ou des extensions personnalisées viennent s'ajouter, le remplacement d'un fichier d'application complet devient rapidement problématique.
C'est pourquoi SchallOS sépare systématiquement la description d'une solution de ses données métier. Une application se compose essentiellement de deux conteneurs associés : le SSC pour la structure et le SSD pour les données de production.
Ces deux conteneurs constituent ensemble la solution complète, mais remplissent des fonctions différentes. Le SSC décrit la structure et le fonctionnement de l'application. Le SSD contient les contenus générés lors de son utilisation.
Le SSC décrit son utilisation
Le fichier SSC est le conteneur de structure portable d'une solution SchallOS. Il contient notamment :
- Définitions des tables et des champs
- Relations
- Mises en page et objets de mise en page
- Formules et fonctions personnalisées
- Conteneur fonctionnel
- Déclencheurs et navigation
- Informations sur la langue et la traduction
- Documentation
- Informations sur la version et la mise à jour
Le SSC ne contient donc pas les clients, les articles, les commandes ou les factures eux-mêmes. Il définit quelles structures de données existent, comment elles sont représentées et quelles fonctions les exploitent. La signification sémantique d’une solution fait également partie de ce conteneur. Outre son nom technique, un champ peut comporter une description métier, des traductions, des règles de validation et des indications destinées à la couche d’IA. La structure devient ainsi non seulement lisible par machine, mais aussi plus compréhensible pour les développeurs, la documentation et la migration.
Le SSC constitue ainsi un modèle d'application portable, qui peut être perfectionné et publié indépendamment d'un ensemble de données particulier.
Le SSD contient les données opérationnelles
Le fichier SSD est le conteneur de données de la solution. Il contient les enregistrements générés au cours de l'activité quotidienne, tels que les clients, les devis, les commandes, les factures, les mouvements de stock ou les rendez-vous. De plus, il permet de stocker des historiques métier et des événements liés aux données. Il s'agit notamment des changements de statut, des validations, des importations ou des modifications apportées à des champs particulièrement importants. Le terme « SSD » ne désigne pas ici un support de données physique, mais la couche logique de données de l'application. La manière dont ces données sont techniquement stockées dépend du déploiement et de l'adaptateur de base de données choisis.
Pour un poste de travail local, il est possible d'utiliser IndexedDB. Une application de bureau peut fonctionner avec SQLite, tandis que les applications multi-utilisateurs de plus grande envergure ont recours à PostgreSQL. Dans tous les cas, le SSD reste le conteneur de données fonctionnel, même si le mode de stockage technique diffère.
Deux conteneurs doivent clairement aller ensemble
La séparation entre la structure et les données ne doit pas conduire à combiner n'importe quels conteneurs entre eux. SchallOS doit pouvoir vérifier si un SSC et un SSD appartiennent bien à la même solution et si leurs versions sont compatibles entre elles. Pour cela, il est possible d'utiliser des identifiants de solution, des identifiants de conteneur, des versions de structure, des sommes de contrôle et des signatures. Avant le démarrage ou une mise à jour, cela permet de vérifier si la combinaison est valide et si les migrations de données nécessaires ont déjà été effectuées.
Ce contrôle empêche, par exemple, d'ouvrir par inadvertance le conteneur de structure d'une autre application contenant un ensemble de données en production. Il empêche également l'activation d'une nouvelle version de SSC alors que le SSD n'a pas encore été préparé pour la structure de données requise.
Portabilité entre différents types d'exploitation
La séparation SSC/SSD permet d'exploiter une application dans différents environnements. Il n'est pas nécessaire de redévelopper les mises en page, les formules et la logique fonctionnelle pour chaque adaptateur de base de données.
Une solution peut commencer localement avec IndexedDB, puis migrer vers SQLite et, si le nombre d'utilisateurs augmente, vers PostgreSQL. Il est également possible de passer à un environnement cloud.
Une telle migration reste une opération technique maîtrisée. Chaque base de données possède ses propres possibilités et contraintes. C'est pourquoi les données ne sont pas simplement transférées vers un autre système d'un simple clic. Le transfert, la vérification et, le cas échéant, la restauration doivent être effectués de manière explicite.
L'architecture garantit toutefois qu'un changement de modèle de stockage des données n'implique pas automatiquement la refonte complète de l'application.
Mises à jour sans échange de données clients
L'un des principaux avantages de cette séparation apparaît clairement lors de la mise en place de nouvelles versions. Les modifications concernent souvent la mise en page, les formules, les fonctions ou le modèle de données. Les données métier existantes doivent quant à elles être conservées.
Un développeur peut donc publier une nouvelle version du SSC tout en conservant le SSD du client sur le site d'exploitation. Si de nouveaux champs ou de nouvelles tables sont nécessaires, ceux-ci sont ajoutés au moyen d'étapes de migration définies. Avant la mise à jour, l'état actuel peut être sauvegardé. La structure, la migration des données et le bon fonctionnement sont ensuite vérifiés. Ce n'est que lorsque le SSC et le SSD présentent à nouveau un état cohérent que la mise à jour est considérée comme terminée.
Cette capacité de mise à jour n'est pas réservée à SchallOS uniquement. Elle est également disponible pour les solutions clients développées avec SchallOS.
Les variantes spécifiques aux clients restent traçables
Les logiciels de gestion sur mesure évoluent souvent de manière différente selon les clients. Un client a besoin de champs personnalisés, un autre de mises en page supplémentaires ou d'une interface spécifique. Sans structure claire, cela conduit rapidement à des copies complètes qui divergent les unes des autres et qui deviennent difficiles à gérer conjointement. Au sein du SSC, en revanche, les composants généraux du produit et les extensions spécifiques aux clients peuvent être versionnés et documentés de manière traçable.
L'architecture ne détermine pas à la place du développeur quelles modifications doivent être intégrées au produit global. Elle garantit toutefois que l'origine et les dépendances d'une modification restent visibles.
Associés aux protocoles de développement et aux versions, ils permettent, lors des mises à jour ultérieures, d'identifier plus facilement les éléments qui doivent être remplacés, complétés ou conservés.
Le multilinguisme fait partie intégrante de la structure portable
La couche linguistique est également intégrée au SSC. Les libellés ne sont pas uniquement stockés de manière fixe dans des objets de mise en page individuels, mais peuvent renvoyer à des entrées sémantiques comportant plusieurs versions linguistiques.
Un champ tel que „ Numéro de facture “ peut ainsi être affiché dans différentes langues sans qu'il soit nécessaire de créer une mise en page entièrement nouvelle pour chaque langue. Une solution FileMaker migrée peut être automatiquement rendue multilingue et traduite pendant la migration.
La traduction automatique ne remplace pas une vérification par un expert. Les termes juridiques et spécifiques à un secteur d'activité, en particulier, doivent être vérifiés. L'architecture du système garantit toutefois que le multilinguisme fasse partie intégrante de la solution dès le départ et ne doive pas être intégré laborieusement dans chaque masque par la suite.
Les bases d'une maintenabilité à long terme
À première vue, les modèles SSC et SSD semblent n'être qu'une simple distinction entre l'application et les données. En réalité, ils constituent toutefois la base de la portabilité, des mises à jour, des différents adaptateurs de base de données, des sauvegardes distinctes et des divers modèles d'exploitation.
Le SSC décrit ce qu'est une solution et comment elle fonctionne. Le SSD contient ce qui est généré au cours de son utilisation et qui doit être conservé de manière permanente pour l'entreprise concernée.
Grâce à cette séparation claire, l'application peut évoluer sans qu'il soit nécessaire de remplacer l'ensemble de la base de données à chaque nouvelle version. Parallèlement, la structure technique des données peut s'étendre ou changer sans qu'il soit nécessaire de refondre entièrement les mises en page et la logique métier.
SchallOS Studio en tant qu'environnement de développement intégré
SchallOS Studio est la partie de la plateforme où sont développées les nouvelles applications métier et où les solutions FileMaker existantes sont migrées ou perfectionnées. C'est là que sont gérés, au sein d'un environnement commun, les tables, les champs, les relations, les mises en page, les formules, les fonctions, les langues et les versions.
Pour les développeurs FileMaker, le mode de fonctionnement de base devrait leur sembler familier. Les modifications ne sont pas apportées exclusivement dans des fichiers de code source abstraits, mais restent liées aux éléments visibles de l'application. Un développeur peut modifier une mise en page, sélectionner un champ, modifier ses propriétés et vérifier immédiatement l'impact de cette modification sur l'application.
SchallOS ne cherche toutefois pas à reproduire intégralement FileMaker. Ce sont surtout les principes fondamentaux qui ont fait leurs preuves qui sont repris : développement rapide, retour d'information immédiat et lien étroit entre le modèle de données, l'interface utilisateur et la logique métier. La base technique, en revanche, est réorganisée et orientée vers des structures portables, la programmation assistée par l'IA, la documentation et des publications contrôlées.
Mises en page, objets et propriétés
Le mode « Layout » constitue un élément essentiel de SchallOS Studio. C'est là que sont créés les formulaires de saisie, les listes, les boîtes de dialogue, les zones de navigation et les autres interfaces d'une solution.
Parmi les objets de mise en page possibles, on trouve notamment des champs, des textes, des boutons, des objets de liste, des onglets, des popovers, des conteneurs et des éléments de navigation. Ces objets peuvent être sélectionnés, positionnés et configurés à l'aide d'un inspecteur.
Un objet de mise en page ne contient pas seulement des informations relatives à sa taille, à sa position et à son affichage. Il peut également être associé à des sources de données, des déclencheurs, des formules, des fonctions et des libellés sémantiques. Un objet de champ, par exemple, fait référence à un champ du modèle de données, peut recevoir une étiquette spécifique à la langue et déclencher certaines fonctions lorsqu'on y accède ou qu'on en sort.
Chaque objet faisant partie intégrante du SSC, les modifications d'agencement peuvent être versionnées, documentées, puis déployées de manière ciblée via une mise à jour. L'interface utilisateur ne reste donc pas un niveau graphique isolé, mais constitue un élément structuré de l'application dans son ensemble.
Modèle de données et descriptions sémantiques
Les tables, les champs et les relations sont également créés et modifiés dans SchallOS Studio. De nouvelles applications peuvent y être entièrement développées. Lors d'une migration FileMaker, l'assistant de migration reprend les structures existantes dans la mesure du possible et les met ensuite à disposition pour la suite du traitement.
Dans SchallOS, un champ ne se compose pas uniquement d'un nom technique et d'un type de données. Il peut également comporter une description fonctionnelle, des règles de validation, des valeurs par défaut, des traductions et des remarques de documentation.
Ces informations ont plusieurs utilités. Elles permettent aux autres développeurs de mieux comprendre la solution, facilitent la documentation automatique et fournissent un meilleur contexte à l'IA intégrée. Au lieu de se contenter de reconnaître qu’un champ s’intitule „ Statut “, la plateforme peut, par exemple, savoir s’il s’agit d’un statut de commande, d’un statut de paiement ou d’un état de traitement interne.
Il est également possible de décrire les relations entre les tables et de les documenter dans leur contexte métier. Ainsi, une partie moins importante des connaissances reste enfermée dans l'esprit du développeur d'origine.
Formules avec calcul en temps réel
SchallOS dispose de son propre environnement de formules. Les formules sont créées dans l'éditeur de formules et calculées en temps réel pendant leur édition. Les modifications apportées à une expression peuvent ainsi être vérifiées immédiatement à l'aide de valeurs de test appropriées ou de l'ensemble de données actuel.
Le langage de formule prend en charge les calculs courants requis dans les applications professionnelles. Cela inclut les opérations mathématiques, le traitement de texte, les calculs de date et d'heure, les conditions logiques, les références de champ, les variables et les expressions imbriquées.
L'ensemble des commandes disponibles est, dans un premier temps, plus restreint que l'ensemble des fonctionnalités de FileMaker, qui s'est enrichi au fil des décennies. SchallOS n'a pas pour objectif de reproduire à l'identique chaque commande historique de FileMaker. Il est plus important de disposer d'un environnement de formules clairement structuré et extensible.
Des commandes supplémentaires pourront être ajoutées ultérieurement si elles s'avèrent nécessaires pour certaines solutions ou migrations. L'IA intégrée peut également aider à transposer un calcul existant ou à développer une fonction manquante adaptée à l'architecture SchallOS.
Fonctions personnalisées pour des calculs réutilisables
Outre les commandes intégrées, SchallOS prend en charge les fonctions personnalisées. Celles-ci acceptent des paramètres, effectuent un calcul défini et renvoient un résultat. Elles permettent ainsi de gérer les règles récurrentes à partir d'un emplacement centralisé. On peut citer comme exemples les calculs de prix, la détermination des délais, la mise en forme, la vérification des séries de numéros ou le traitement des valeurs importées.
Les fonctions personnalisées sont également calculées en temps réel et peuvent être testées immédiatement dans l'éditeur de formules. Si une fonction est corrigée ou étendue ultérieurement, toutes les formules qui l'utilisent en bénéficient.
De plus, il est possible de décrire et de documenter ses propres fonctions. Les paramètres, la valeur de retour, les exemples et les cas d'erreurs connus restent ainsi clairement identifiables. L'ensemble des fonctions d'une solution se transforme ainsi en une bibliothèque réutilisable, au lieu d'être constitué de nombreux calculs individuels copiés.
Conteneurs de fonctions pour des processus plus complexes
Dans SchallOS, les processus métier plus complexes sont organisés en conteneurs de fonctions. Ceux-ci permettent, par exemple, de créer des enregistrements, de vérifier des valeurs, de contrôler des boîtes de dialogue, de générer des documents ou d'interagir avec des interfaces externes. Un conteneur de fonctions ne contient pas seulement le code exécutable. Il comprend également une description fonctionnelle, des paramètres d'entrée, des valeurs de retour, des dépendances, les capacités autorisées et les opérations expressément exclues.
Plusieurs objets de mise en page peuvent utiliser le même conteneur de fonctions. Il n'est donc pas nécessaire de recréer une fonction permettant de générer une facture pour chaque bouton ou chaque mise en page.
Dans le cas de solutions migrées, les scripts FileMaker existants peuvent être conservés en arrière-plan à des fins d'apprentissage et de référence. Ils permettent de comprendre l'intention initiale et le déroulement des opérations jusqu'à présent. Le nouveau code exécutable est toutefois généré en fonction de l'architecture de SchallOS.
Migration et nouveau développement dans le même environnement
SchallOS Studio n'est pas uniquement destiné aux solutions FileMaker existantes. De nouvelles applications peuvent être entièrement développées au sein de la plateforme.
Lors d'une migration, l'assistant commence par récupérer les tables, champs, relations, mises en page et autres éléments identifiables existants. Les développeurs peuvent ensuite vérifier et nettoyer la structure importée, puis la transférer progressivement vers la nouvelle architecture fonctionnelle.
Il ne s'agit pas pour autant de reproduire à l'identique toutes les particularités antérieures. Les détours hérités de l'histoire peuvent être réexaminés et remplacés par des structures plus claires. Dans le même temps, le savoir-faire technique de la solution existante est préservé.
Les applications nouvelles et celles qui ont été migrées utilisent ensuite les mêmes outils, conteneurs et canaux de publication.
Les modifications font l'objet de versions contrôlées
Une modification effectuée en studio ne se traduit pas automatiquement par une mise à jour productive. Au cours du développement, il peut y avoir des mises en page inachevées, des formules provisoires ou des fonctionnalités qui n'ont pas encore été testées.
Les modifications liées entre elles peuvent donc être saisies dans des « Change Sessions » et attribuées ultérieurement à une version. Ce n'est qu'après vérification et validation qu'une version SSC publiée en résulte.
Outre la nouvelle structure, une version peut également inclure les migrations de données nécessaires, les informations de version, les dépendances, les étapes de contrôle et la documentation. De cette manière, le développement proprement dit reste clairement distinct de la mise en production sur les instances d'exécution.
SchallOS Studio n'est donc pas seulement le lieu où une application est conçue et programmée. Il réunit le développement visuel, le modèle de données, les formules, les fonctions, la documentation et la publication au sein d'un environnement unique.
La proximité familière entre le développeur et l'application visible est préservée. Parallèlement, cela permet de créer une base technique sur laquelle les solutions peuvent être développées de manière à être portables, compréhensibles et faciles à maintenir à long terme.
L'IA au cœur de la création des formules et des fonctions
Dans de nombreux environnements de développement, l'intelligence artificielle est jusqu'à présent principalement proposée via une fenêtre de chat supplémentaire. Le développeur décrit un problème, copie du code source ou des formules dans le chat, puis réintègre le résultat dans le projet. Or, le modèle linguistique manque souvent d’informations importantes concernant les tables, les champs, les relations et la signification métier de l’application.
C'est pourquoi SchallOS intègre directement l'IA dans les outils de développement. Elle est disponible là où l'on modifie les formules, les fonctions personnalisées et les conteneurs de fonctions. Ainsi, elle ne reçoit pas seulement une question isolée, mais dispose également du contexte actuel de la solution.
Dans l'éditeur de formules, l'IA connaît par exemple l'expression en cours de traitement, les champs disponibles et le type de résultat attendu. Au sein d'un conteneur de fonctions, elle peut en outre accéder à sa description, à ses paramètres, à ses capacités et à ses dépendances.
L'IA ne devient donc pas un programme auxiliaire distinct, mais fait partie intégrante de l'environnement de développement proprement dit.
Aide dans l'éditeur de formules
Les formules pilotent de nombreux processus d'une application métier. Elles calculent les prix, vérifient les conditions, déterminent les délais ou influencent l'affichage des objets de mise en page. Dans l'éditeur de formules, l'IA intégrée permet notamment :
- expliquer une formule existante
- analyser les erreurs éventuelles
- Compléter les conditions
- simplifier une expression
- transposer une formule FileMaker
- ou établir un nouveau calcul à partir d'une description technique.
Un développeur pourrait, par exemple, spécifier que les commandes dépassant une certaine valeur nette nécessitent une validation supplémentaire, à moins qu'un contrat-cadre ne soit en vigueur. L'IA peut alors générer une formule à partir de ces critères en s'appuyant sur les champs disponibles dans la solution. Le résultat reste visible sous la forme d’une formule normale. Il peut être consulté, modifié et calculé en temps réel. L’IA ne génère donc pas de processus caché dont le fonctionnement serait difficile à comprendre.
Si une commande nécessaire fait défaut, l'IA peut également aider à créer une fonction personnalisée adaptée ou une extension de l'environnement de formules. L'ensemble de commandes de SchallOS, initialement restreint, reste ainsi évolutif.
Fonctions personnalisées issues des spécifications métier
Les calculs récurrents peuvent être gérés de manière centralisée sous forme de fonctions personnalisées. L'IA est capable de générer, à partir d'une description, une fonction dotée de paramètres uniques, d'une valeur de retour et d'un comportement documenté.
Une telle fonction pourrait, par exemple, calculer les délais d'escompte, vérifier les séries de numéros ou harmoniser les valeurs importées. Outre l'impression proprement dite, il est également possible de générer des valeurs de test, des exemples et des cas d'erreurs possibles.
Cela ne facilite pas seulement la programmation initiale. En cas de modification ultérieure, l'IA est capable de reconnaître la signification de la fonction et les endroits où elle est utilisée.
Un calcul anonyme devient ainsi un élément documenté et réutilisable de la solution.
Conteneur de fonctions en tant que logique de programme décrite
Dans SchallOS, les processus plus complexes sont organisés à l'aide de conteneurs de fonctions. Un conteneur de fonctions peut, par exemple, créer des enregistrements, vérifier des saisies, contrôler des boîtes de dialogue, générer des documents ou appeler des interfaces externes. Il repose sur une description structurée. Celle-ci peut définir :
- quelle est la fonction de cette fonction
- quels paramètres sont transmis
- quel résultat est attendu
- les tables et les champs auxquels l'accès est autorisé
- quelles autres fonctions sont utilisées
- et quelles opérations sont expressément exclues.
Sur la base de ces spécifications, l'IA programme le code exécutable du conteneur de fonctions. Le développeur n'a ainsi plus besoin de composer le déroulement exclusivement à partir de nombreuses étapes de script individuelles. Sa tâche consiste désormais davantage à décrire précisément la fonction souhaitée, ses limites et la vérification qui s'ensuit.
Le code généré reste toutefois visible. Il peut être lu, testé, modifié et comparé entre différentes versions. Les versions antérieures peuvent également être conservées et restaurées si nécessaire. L'IA se charge ainsi de la programmation, mais pas de la responsabilité technique.
Les scripts FileMaker comme support pédagogique
Dans le cas des solutions FileMaker migrées, les scripts existants contiennent souvent une grande partie de la logique métier développée au fil des années. Ils indiquent quels champs ont été modifiés, quelles conditions ont été vérifiées et quelles autres procédures ont été appelées.
Ces scripts ne sont pas intégrés de manière permanente dans SchallOS en tant que couche d'exécution. Cela aurait pour effet de simplement transférer de nombreuses dépendances techniques et contournements antérieurs vers le nouveau système. Au lieu de cela, le script FileMaker d’origine peut être conservé en arrière-plan du conteneur de fonctions correspondant. Il sert de couche d’apprentissage, de référence et de compréhension pour l’IA.
L'IA peut ainsi déduire l'intention fonctionnelle du processus existant. Elle programme ensuite le nouveau code en l'adaptant à l'architecture de SchallOS. Les éléments hérités, tels que les changements fréquents de mise en page, les champs globaux ou les scripts d’aide contextuels, ne doivent pas nécessairement être repris tels quels. Ils ne sont conservés que s’ils sont réellement nécessaires au processus métier proprement dit.
Le script d'origine reste néanmoins une source d'informations. En cas de questions ultérieures, il permet de comprendre comment un processus a été initialement mis en œuvre dans la solution FileMaker.
Les capacités et les limites sont clairement définies
Un conteneur de fonctions ne doit pas pouvoir accéder à n'importe quelle partie de l'application sur la seule base d'une description générale. C'est pourquoi il est possible de définir explicitement les capacités autorisées et les exclusions.
Une fonction peut, par exemple, être autorisée à lire et à modifier des enregistrements dans une table donnée, sans pour autant pouvoir effectuer des suppressions ou apporter des modifications à la configuration du système. Si le code généré utilise une capacité non autorisée, SchallOS peut le détecter et bloquer son exécution ou sa publication.
La description d'un conteneur de fonction ne sert donc pas uniquement à des fins de documentation. Elle fait partie intégrante du modèle de vérification et de sécurité. Cette limitation est particulièrement importante dans le cas du code généré par l'IA. Le modèle linguistique dispose d'une marge de manœuvre clairement définie, tandis que la plateforme vérifie si la fonction générée reste dans ce cadre.
Un contexte adapté améliore les résultats
La qualité d'une fonction générée par l'IA ne dépend pas uniquement de la taille du modèle linguistique utilisé. Ce qui est déterminant, c'est que le modèle reçoive les informations nécessaires. SchallOS peut reconstituer le contexte à partir de plusieurs niveaux :
- la question du moment
- dans l'éditeur ouvert
- le champ ou le conteneur de fonctions sélectionné
- les tables et les relations concernées
- formules et fonctions existantes
- descriptions sémantiques
- Documentation et historique des modifications
- ainsi que, dans le cadre des migrations, le script FileMaker d'origine.
Cela permet à l'IA de fonctionner de manière nettement plus précise que dans le cas d'une requête isolée dans un chat général.
Par ailleurs, il n'est pas nécessaire de fournir la solution complète pour chaque exercice. Le contexte peut se limiter aux informations réellement nécessaires à la fonction concernée.
Des modèles interchangeables plutôt qu'un engagement à vie
La couche d'IA ne doit pas dépendre de manière permanente d'un seul modèle ou fournisseur. Les différentes tâches imposent des exigences variées en matière de qualité, de rapidité, de coûts et de protection des données.
Une migration complexe peut nécessiter un modèle particulièrement performant. Une simple explication ou une adaptation de formule peut éventuellement être réalisée à l'aide d'un modèle plus petit. Pour les environnements sensibles ou fermés, il est également possible d'utiliser à long terme des modèles exploités en local.
La base de connaissances permanente ne réside donc pas dans le modèle linguistique, mais dans la solution SchallOS : dans les descriptions, les structures, les références de scripts, le code, les tests et la documentation. Le modèle d'IA reste un outil interchangeable qui génère, à partir de ce contexte, du code exécutable ou des suggestions compréhensibles.
Développement transparent basé sur l'IA
SchallOS associe le travail direct sur des applications métier à la programmation assistée par l'IA. Les formules peuvent être expliquées et générées directement. Les fonctions personnalisées sont créées à partir de spécifications métier réutilisables. Les conteneurs de fonctions associent des descriptions sémantiques à du code visible et vérifiable.
Dans le cas des solutions migrées, les scripts FileMaker sont conservés en tant que couche d'apprentissage supplémentaire. Ils permettent de comprendre les processus métier existants sans perpétuer indéfiniment les dépendances techniques antérieures.
Le rôle du développeur n'en disparaît pas pour autant. Il évolue. La définition précise des exigences, une architecture pertinente, les tests et le contrôle technique prennent le pas sur la saisie manuelle de chaque étape du programme. Cette responsabilité reste indispensable, en particulier pour les logiciels critiques pour l'activité.
Dernière enquête sur l'utilisation des systèmes d'IA locaux
Documentation et journaux d'événements intégrés à l'application
La documentation d'une application métier n'est souvent rédigée qu'une fois le développement terminé. Sous la pression des délais, le travail se concentre dans un premier temps sur les nouveaux champs, les mises en page, les formules et les fonctions. La description des modifications est prévue pour plus tard.
Cependant, plus le temps passe, plus il devient difficile de retracer les décisions initiales. Souvent, on ne sait plus exactement pourquoi une fonction donnée a été ajoutée, quels objets étaient concernés et quels cas particuliers devaient être pris en compte. C'est pourquoi SchallOS ne considère pas la documentation comme une tâche supplémentaire à réaliser a posteriori. Les modifications pertinentes sont enregistrées dès la phase de développement sous forme d’événements et associées aux composants concernés de la solution.
Ces informations permettent ensuite de générer de la documentation technique, des notes de mise à jour, des rapports clients ou des rapports de performance. La documentation ne repose donc pas uniquement sur des souvenirs ou des notes prises à la main, mais sur les modifications effectivement apportées.
Événements à plusieurs niveaux
Une solution SchallOS ne repose pas uniquement sur un seul protocole général. La plateforme distingue différents niveaux d'événements, chacun ayant ses propres tâches.
- Le site Protocole de structure enregistre les modifications apportées au SSC. Il s'agit notamment de nouveaux tableaux et champs, de mises en page modifiées, de formules modifiées ou de nouveaux conteneurs de fonctions.
- Le site Journal des événements liés aux données Fait partie du SSD. C'est là que sont consignés les événements pertinents sur le plan technique survenant pendant l'utilisation en production, tels que les changements d'état, les validations, les annulations ou les modifications d'enregistrements importants.
- À cela s'ajoutent Événements d'exploitation issus de Runtime et de SchallOS Control. Il s'agit notamment des déploiements, des mises à jour, des contrôles, des sauvegardes et des opérations de restauration.
Ces domaines restent distincts, mais peuvent être reliés entre eux. Un journal de développement ne doit pas devenir confus à cause des modifications quotidiennes apportées aux fiches clients. À l'inverse, les détails techniques internes n'ont pas automatiquement leur place dans l'historique fonctionnel d'une facture ou d'une commande.
Le protocole de structure montre l'évolution de la solution
Les modifications apportées aux tables, aux champs, aux mises en page, aux formules et aux conteneurs de fonctions peuvent être enregistrées sous forme d'événements structurés. Une entrée peut indiquer quel objet a été modifié, quel était son état antérieur et quel est son nouvel état. Il est également possible de saisir le développeur, la date et l'heure, la justification métier, l'ordre associé et la version de mise à jour prévue.
Si, par exemple, un nouveau processus de validation des commandes est ajouté, cela peut entraîner plusieurs modifications techniques. Un champ de statut est créé, une mise en page est étendue, une formule est adaptée et un nouveau conteneur de fonctions est programmé.
Le journal des structures conserve ces événements individuels. Parallèlement, ceux-ci peuvent être regroupés sous une tâche métier commune. Cela permet de voir clairement que plusieurs modifications techniques forment ensemble un nouveau processus métier.
Les « Change Sessions » regroupent des travaux liés entre eux
Une tâche de développement se compose souvent de nombreuses petites étapes. Une simple liste chronologique des différentes modifications ne permettrait pas de rendre compte de manière satisfaisante du contexte réel.
SchallOS peut donc regrouper les tâches liées entre elles dans des « Change Sessions ». Une « Change Session » décrit une tâche, une extension ou une correction de bogue spécifique et rassemble tous les événements qui s'y rapportent. Elle peut par exemple contenir :
- la description des missions techniques
- tables et modèles concernés
- formules et fonctions modifiées
- tests effectués
- points en suspens
- ainsi que l'affectation à un client ou à une commande.
Plusieurs sessions de modification peuvent être associées ultérieurement à une version. Cela permet d'établir un lien clair entre la demande de développement, les modifications techniques et la version publiée.
L'IA présente les événements techniques de manière compréhensible
La couche de documentation est reliée à l'IA intégrée de SchallOS. Cela permet de traiter automatiquement les événements enregistrés en fonction des différents publics cibles.
Un rapport technique de développement nécessite des informations différentes de celles d'une communication destinée aux clients. Alors que le développeur souhaite voir les noms de champs concrets, les conteneurs de fonctions et les migrations de données, le client s'intéresse avant tout à la fonction qui a été ajoutée et aux avantages qu'elle apporte. L'IA peut donc résumer les mêmes événements sous différentes formes :
- en tant que documentation technique interne
- sous forme d'informations claires destinées aux clients
- sous forme de notes de mise à jour
- sous forme de rapport de projet
- ou comme justificatif de paiement d'une facture.
Les textes ne sont pas générés librement à partir d'une description générale. Ils sont dérivés des « Change Sessions », des descriptions sémantiques des objets et des modifications structurelles effectives.
Le texte généré reste ainsi lié à ses sources. Le développeur peut vérifier sur quels événements repose une affirmation et corriger ou valider la formulation avant son utilisation.
Rapports de performance destinés aux développeurs et aux clients
Pour les développeurs de logiciels sur mesure, la documentation revêt également une importance économique. Les prestations doivent être expliquées de manière compréhensible au client et sont souvent facturées à l'heure ou par lot de travail.
Dans la pratique, ces relevés de prestations ne sont souvent établis que peu avant la facturation. Il faut alors passer au crible les e-mails, les notes et les rappels.
SchallOS peut attribuer les événements de développement effectivement enregistrés à un client, un projet ou une commande. L'IA génère à partir de ces données des entrées adaptées pour un rapport d'activité. Plusieurs modifications techniques peuvent, par exemple, être regroupées en une seule prestation claire :
Extension de la gestion des commandes par l'ajout d'un processus de validation en deux étapes, comprenant la vérification du statut, les droits d'utilisateur et la personnalisation du formulaire de saisie.
Les processus techniques sous-jacents restent consultables. La description fournie au client ne constitue qu'un résumé compréhensible. Le choix final revient au développeur. Tous les événements techniques ne sont pas automatiquement facturables, et les essais ou corrections internes ne doivent pas nécessairement figurer individuellement sur une facture.
Événements au niveau des données
Même en production, tous les événements liés aux données prévus peuvent être consignés. Cela inclut la création et la modification d'enregistrements, les changements d'état, les validations, les importations, les exportations ou les processus exécutés automatiquement. Une entrée peut consigner :
- quel utilisateur ou processus a déclenché l'action
- quel enregistrement était concerné
- quelles valeurs ont été modifiées
- quelle fonction a été exécutée
- et si l'opération s'est déroulée avec succès.
C'est la solution choisie qui détermine quels événements sont enregistrés et à quel niveau de détail. Une simple correction dans un texte n'a pas la même importance que la modification d'une facture déjà validée. Le journal des événements constitue ainsi l'historique fonctionnel du SSD. Il facilite l'assistance technique, l'analyse des erreurs et la traçabilité des processus métier importants.
Un tel protocole peut également servir de base aux exigences d'audit. Il convient toutefois de vérifier, au cas par cas, s'il permet de respecter l'ensemble des exigences légales ou spécifiques au secteur concerné.
La documentation accompagne également les versions et les mises à jour
Les événements de développement enregistrés sont intégrés simultanément dans le pipeline de publication et de mise à jour. Lorsqu'une nouvelle version est publiée, SchallOS peut automatiquement recenser les fonctionnalités ajoutées, les bogues corrigés et les structures de données modifiées. Cela permet de générer des listes de modifications techniques, des notes destinées aux utilisateurs et des informations de migration.
Une fois l'installation terminée, il est possible de savoir quelle version a été déployée sur une instance d'exécution donnée et quelles modifications elle contenait.
Les événements opérationnels tels que les sauvegardes, les contrôles ou une éventuelle restauration sont également documentés. Cela permet non seulement de déterminer ultérieurement ce qui a été développé, mais aussi quand une modification a été mise en production et avec quel résultat.
Une base de connaissances en constante expansion
La combinaison du journal des événements, des descriptions sémantiques et de l'assistance par l'IA permet de constituer, à long terme, une base de connaissances couvrant l'ensemble de la solution. En cas de modification ultérieure, il ne suffit pas de se contenter d'examiner le code actuel. Il est également possible de déterminer quand une fonctionnalité a été introduite, quelle était la raison métier qui la sous-tendait et quels autres domaines étaient concernés à l'époque.
Ces informations sont d'autant plus cruciales pour les applications métier qui ont évolué au fil des années. Un cas particulier apparemment superflu peut avoir une raison historique importante. Sans documentation, il risque d’être supprimé par inadvertance lors d’une refonte ultérieure. C’est pourquoi SchallOS conserve non seulement les états techniques, mais aussi l’historique du développement et les décisions qui y sont liées.
La documentation devient ainsi un élément actif de l'application. Elle facilite le développement, la communication avec les clients, la facturation, l'assistance, les mises à jour et la maintenabilité à long terme, en s'appuyant sur les événements qui se sont réellement produits dans le système.
Un pipeline de mise à jour à l'échelle du système pour la plateforme et les applications
Les logiciels d'entreprise restent rarement inchangés pendant une longue période. De nouvelles exigences, des modifications législatives, des corrections de bogues et des évolutions techniques donnent régulièrement lieu à de nouvelles versions. Dans ce contexte, il ne suffit pas de se contenter d'échanger des fichiers. Avant chaque mise à jour, il faut vérifier quelle version est concernée, si les structures de données doivent être adaptées et comment l'état précédent peut être restauré en cas d'erreur.
Dans de nombreuses applications personnalisées, ces procédures ne sont mises en place qu’a posteriori. Les mises à jour sont alors déployées à l’aide d’instructions manuelles, de copies de sauvegarde et de scripts spécifiques au client. À chaque nouvelle installation, le risque de voir apparaître des versions différentes et des solutions spécifiques augmente.
SchallOS considère donc les mises à jour comme une fonctionnalité de la plateforme à l'échelle du système. C'est via ce même pipeline de base que sont mis à jour aussi bien SchallOS lui-même que les solutions clients développées avec la plateforme.
Un développeur n'a donc pas besoin de concevoir lui-même une procédure de mise à jour pour une nouvelle application. La gestion des versions, les tests, la distribution et la journalisation font partie intégrante de l'architecture commune dès le départ.
La séparation entre SSC et SSD protège les données de production
La possibilité de mise à jour est directement liée à la séparation entre la structure et les données. Le SSC contient les mises en page, les formules, les conteneurs de fonctions, les définitions de langage et le modèle de données de l'application. Le SSD contient les données métier opérationnelles de l'entreprise concernée.
Lors d'une mise à jour, l'application dans son intégralité, y compris toutes les données clients, n'est donc pas remplacée. À la place, un nouveau SSC peut être publié, tandis que le SSD existant reste en place sur le site.
Si la nouvelle structure nécessite des champs supplémentaires, des tables ou des formats de données modifiés, des étapes de migration expressément définies à cet effet sont exécutées. Les données de production sont adaptées à la nouvelle structure de manière contrôlée et ne sont pas remplacées à l'insu de l'utilisateur par un autre ensemble de données.
Cette séparation claire permet de continuer à développer les applications pendant de nombreuses années sans avoir à transférer l'ensemble des données métier vers un nouveau fichier complet à chaque mise à jour.
Du stade de développement à la mise en production
Toutes les modifications apportées à SchallOS Studio ne sont pas nécessairement prêtes à être utilisées en production. Au cours du développement, il peut y avoir des mises en page provisoires, des fonctionnalités incomplètes ou des formules qui n'ont pas encore été testées.
Les modifications liées entre elles sont donc d'abord enregistrées dans des « Change Sessions » et affectées à une version prévue. Ce n'est qu'après vérification et validation qu'elles donnent lieu à une version publiée. Une version peut notamment contenir :
- un numéro de version unique
- le SSC mis à jour
- migrations vers des SSD nécessaires
- conditions techniques requises
- Dépendances liées à l'environnement d'exécution ou aux adaptateurs
- Étapes de contrôle et d'essai
- Notes de mise à jour
- ainsi que des informations concernant une éventuelle restauration.
La couche de documentation en constitue la base. À partir des événements de développement consignés, il est possible de générer automatiquement des listes de modifications techniques et des instructions claires à l'intention des utilisateurs.
Une version ne se compose donc pas uniquement de fichiers modifiés. Elle décrit également les modifications apportées, les conditions préalables requises et la manière dont l'installation doit être vérifiée.
SchallOS Control gère la répartition
SchallOS Control se charge de la gestion opérationnelle des mises à jour. L'interface permet de visualiser les instances existantes, les versions qui ont fait l'objet d'un « installier » et les mises à jour disponibles. Avant l'installation, Control peut notamment vérifier :
- si l'entité cible est accessible
- quelle version du Runtime et du SSC est utilisée
- quel adaptateur de base de données est actif
- s'il est possible de créer une sauvegarde appropriée
- et si toutes les conditions préalables à la mise en production sont remplies.
Cela permet d'éviter qu'une mise à jour ne soit effectuée sur une installation techniquement inadaptée ou qui n'a pas été correctement préparée.
De plus, une mise à jour ne doit pas nécessairement être déployée simultanément sur tous les systèmes. Elle peut d'abord être mise en œuvre dans un environnement de test ou sur certaines installations sélectionnées. Ce n'est qu'après des tests concluants que le déploiement à plus grande échelle a lieu.
À cette fin, différents canaux de mise à jour peuvent être prévus, par exemple des versions stables en production, des versions préliminaires, des tests internes ou des versions spécifiques aux clients.
Signatures et numéros de version uniques
Les paquets de mise à jour peuvent être accompagnés de sommes de contrôle et de signatures numériques. SchallOS Control peut ainsi vérifier si un paquet est complet, s'il provient bien de la source prévue et s'il a été modifié depuis sa publication.
On vérifie également si la version appartient bien à la solution concernée. Un nouveau SSC ne doit pas être associé par erreur au SSD d'une autre application.
Des identifiants de solution uniques, des versions de structure et des versions de modèle de données garantissent la traçabilité de l'état actuel. Les étapes intermédiaires nécessaires peuvent également être identifiées. Une installation ne peut par exemple pas passer directement d’une version très ancienne à la version la plus récente si une migration de données nécessaire doit être effectuée au préalable.
Sauvegarde, migration et vérification
Avant toute mise à jour structurelle, l'état actuel est sauvegardé. La méthode de sauvegarde dépend de l'adaptateur de base de données utilisé. Une installation locale d'IndexedDB ou de SQLite nécessite des procédures différentes de celles d'un serveur PostgreSQL.
Le pack de mise à jour est ensuite vérifié, la nouvelle structure install est mise en place et la migration des données, si nécessaire, est effectuée. L'activation est suivie d'une vérification. À cette occasion, SchallOS peut par exemple contrôler :
- si toutes les tables et tous les champs attendus sont présents,
- si la migration des données a été entièrement effectuée,
- si le nombre d'enregistrements et les sommes de contrôle sont corrects,
- et si les fonctions importantes sont exécutées correctement.
Ce n'est qu'une fois ces tests réussis que la mise à jour est considérée comme validée (1TP12). Un simple transfert de fichiers ne suffit donc pas. Il est essentiel que la structure, les données et l'environnement d'exécution retrouvent ensuite un état cohérent et opérationnel.
Restauration en cas d'échec des mises à jour
Malgré une préparation minutieuse, une mise à jour peut échouer. Des données héritées inattendues, une migration défaillante ou une dépendance non prise en compte peuvent empêcher l'activation en toute sécurité d'une nouvelle version. Dans de tels cas, la procédure de mise à jour prévoit une restauration. Celle-ci consiste à rétablir la version antérieure du SSC, l'état sauvegardé du SSD et la configuration précédente.
Cependant, toutes les mises à jour ne peuvent pas être annulées indéfiniment. Si, après l'installation, de nouvelles données de production ont déjà été traitées selon les nouvelles règles, un retour complet peut s'avérer problématique. Une version doit donc préciser dans quelles conditions une annulation est possible.
Dans certains cas, il est plus judicieux de procéder à une mise à jour corrective que de restaurer un ensemble de données antérieur. La plateforme fournit le cadre technique nécessaire, mais la décision concrète dépend de la modification en question et de son importance sur le plan métier.
SchallOS utilise lui-même ce pipeline
Le pipeline de mise à jour n'est pas uniquement destiné aux solutions clients. SchallOS Studio, Runtime, Control et d'autres composants de la plateforme sont également mis à jour via ces mêmes mécanismes de base. Les nouvelles versions de la plateforme peuvent inclure des extensions de l'environnement de formules, des améliorations de la couche d'IA, de nouveaux adaptateurs de bases de données ou des correctifs de sécurité. Là encore, les numéros de version, les dépendances, les signatures et les vérifications sont nécessaires.
Ainsi, l'infrastructure est utilisée et testée en continu dans le cadre de l'exploitation courante de la plateforme. Les applications développées avec SchallOS bénéficient des mêmes procédures.
Le développeur ne dispose donc pas d'une simple fonctionnalité de mise à jour théorique, mais d'un pipeline qui fait partie intégrante à la fois de l'exploitation et du développement continu de l'ensemble du système.
Une piste envisagée pour les futures versions
La force du pipeline de mise à jour ne réside pas uniquement dans la distribution automatique des nouveaux fichiers. Ce qui est déterminant, c'est l'intégration du développement, de la documentation, de la sauvegarde, de la migration, des tests et de la restauration au sein d'un processus commun.
SchallOS lui-même et les applications développées à partir de celui-ci utilisent la même infrastructure de base. La séparation entre SSC et SSD permet à la structure de continuer à évoluer, tout en garantissant la protection des données de production et leur adaptation contrôlée.
Une solution développée avec SchallOS dispose ainsi, dès le départ, d'une voie prévue pour les versions futures. En particulier pour les logiciels d'entreprise destinés à être utilisés pendant de nombreuses années, cette capacité de mise à jour n'est pas une fonctionnalité supplémentaire, mais une condition essentielle à une maintenabilité durable et à un fonctionnement fiable.
Runtime, Control et Cloud pour différents modèles d'exploitation
Un environnement de développement doit offrir des possibilités étendues. Les développeurs doivent pouvoir modifier des structures, concevoir des mises en page, éditer des formules et publier de nouvelles fonctionnalités. En revanche, ces outils ne sont généralement pas nécessaires dans le cadre de l'exploitation quotidienne d'une application métier aboutie.
SchallOS sépare donc le développement, l'exécution et la gestion en différents domaines. SchallOS Studio est dédié au développement. SchallOS Runtime exécute les applications publiées. SchallOS Control gère leur déploiement technique. SchallOS Cloud propose la même architecture de base sous la forme d'un service en ligne géré de manière centralisée.
Cela ne donne pas lieu à la création d'applications indépendantes les unes des autres. Tous les domaines utilisent les mêmes structures SSC et SSD. Le mode de fonctionnement est défini via le déploiement, l'adaptateur de base de données et le profil d'exécution.
SchallOS Runtime exécute les solutions publiées
SchallOS Runtime relie le SSC d'une application au SSD correspondant et met à disposition les mises en page, formules et fonctions qui y sont définies. Le runtime comprend notamment l'affichage et l'utilisation des schémas, la lecture et la modification des enregistrements, le calcul des formules et des fonctions personnalisées, l'exécution des conteneurs de fonctions, la navigation et le contrôle des boîtes de dialogue, le multilinguisme ainsi que la connexion à l'adaptateur de base de données prévu.
Le Runtime ne contient toutefois pas automatiquement tous les outils de SchallOS Studio. Il ne permet pas de créer de nouvelles paires de solutions SSC/SSD et ne dispose pas d'assistant de migration pour les solutions FileMaker.
Ainsi, une application client déployée reste clairement séparée de l'environnement de développement proprement dit.
Les profils déterminent les capacités d'un environnement d'exécution
Toutes les installations ne nécessitent pas les mêmes fonctionnalités. Une application destinée uniquement aux utilisateurs finaux peut ne devoir exécuter que des modèles et des processus métier publiés. Une installation interne peut, quant à elle, nécessiter des fonctions supplémentaires d'administration ou de diagnostic.
Pour cela, SchallOS utilise des profils d'exécution et de capacités. Ceux-ci définissent les capacités techniques dont dispose une instance donnée.
Un profil peut, par exemple, déterminer si le mode de mise en page est disponible, si les données peuvent être importées ou exportées, si les boîtes de dialogue d'administration s'affichent, si les paramètres locaux peuvent être modifiés ou si certaines interfaces peuvent être utilisées.
Ces profils complètent les droits d'utilisateur au sein de la solution proprement dite. Les droits d'utilisateur déterminent ce qu'une personne est autorisée à faire sur le plan fonctionnel. Le profil d'exécution, quant à lui, définit les possibilités techniques que l'installation concernée met en principe à disposition.
Cela permet d'utiliser la même base d'exécution pour différents groupes de clients et différents cas d'utilisation, sans avoir à développer une version distincte du programme pour chaque variante.
Du poste de travail local à l'exploitation sur serveur
Une solution SchallOS peut être déployée selon différents modes de fonctionnement. Pour un poste de travail local unique, le SSD peut par exemple être stocké dans IndexedDB. Une application de bureau à architecture install peut utiliser SQLite. Pour les solutions multi-utilisateurs de plus grande envergure, une base de données centrale telle que PostgreSQL est prévue.
Ces modèles d'exploitation présentent des caractéristiques différentes. IndexedDB est particulièrement adapté aux applications de navigateur locales. SQLite constitue une base éprouvée pour les applications locales et les installations de taille modérée. PostgreSQL est quant à lui idéal pour les systèmes centralisés multi-utilisateurs avec une gestion professionnelle des serveurs.
SchallOS ne considère pas ces technologies comme des emplacements de stockage parfaitement interchangeables. Le changement d'adaptateur nécessite un transfert contrôlé des données, une vérification et, le cas échéant, une restauration. L'architecture commune SSC/SSD garantit que les schémas, les formules et la logique métier n'ont pas à être entièrement redéveloppés pour chaque adaptateur de base de données.
Applications de bureau et utilisation du navigateur
Les solutions SchallOS doivent pouvoir fonctionner aussi bien dans un navigateur que sous forme d'applications déployables sur Windows et macOS. Un runtime de bureau peut s’intégrer plus étroitement au système d’exploitation concerné, utiliser les fichiers locaux de manière contrôlée et, avec une configuration appropriée, fonctionner temporairement hors ligne. Il peut stocker ses données localement avec IndexedDB ou SQLite, ou accéder à une base de données PostgreSQL centrale.
Dans le navigateur, l'application est affichée via le moteur d'exécution SchallOS. Cela ne nécessite ni le serveur FileMaker ni FileMaker WebDirect. Une solution FileMaker migrée ne s'exécute donc plus en arrière-plan à partir d'un fichier FileMaker après la migration. Les mises en page, les formules et la logique fonctionnelle sont exécutées au sein de l'architecture SchallOS.
SchallOS Control gère les instances
SchallOS Control constitue le centre de contrôle opérationnel de la plateforme. C'est là que l'on gère les solutions exploitées sur chaque système cible ainsi que les conditions techniques requises. Control permet notamment d'afficher :
- quelles paires SSC/SSD ont été mises à disposition
- Quelle est la version du Runtime installiert ?
- quel adaptateur de base de données est utilisé
- quel profil de capacité s'applique
- quelles mises à jour sont disponibles
- et la date de la dernière vérification d'une instance.
Une cible de déploiement peut être, par exemple, une application Windows locale, un environnement d'exécution macOS, un serveur PostgreSQL dédié, un environnement de test ou une instance cloud.
Les informations opérationnelles telles que les adresses de serveurs, les accès aux bases de données, les licences ou les associations d'appareils locaux n'ont pas leur place dans le SSC portable. Elles sont gérées dans la configuration protégée de l'instance concernée.
Solutions signées et distribution contrôlée
Les conteneurs de solutions portables ne doivent pas permettre de modifier n'importe quelle application à volonté ni de la lancer sur des systèmes non prévus à cet effet. Les paquets SSC/SSD publiés peuvent donc être associés à des identifiants de solution, des sommes de contrôle, des signatures et des informations d'instance. Au démarrage, le moteur d'exécution peut vérifier si le SSC est inchangé et signé de manière valide, si le SSD appartient bien à la bonne solution, si les deux versions sont compatibles entre elles et s'il existe un profil de déploiement valide.
Selon le modèle de licence, un déploiement peut être lié à une instance, à un serveur, à un appareil ou à un ensemble d'utilisateurs défini. SchallOS Control gère également les modifications nécessaires, telles qu'un changement de serveur, une réactivation ou la restauration d'une installation.
SchallOS Cloud en tant que modèle d'exploitation SaaS
SchallOS Cloud met à disposition des applications sous forme de service en ligne géré de manière centralisée. Le cloud n'utilise toutefois pas de format de solution propre et distinct. Une application développée dans SchallOS Studio peut être affectée à une instance cloud et mise à disposition via le navigateur. L'environnement d'exécution, la base de données, les sauvegardes, la surveillance et les mises à jour sont gérés de manière centralisée. Il en résulte un modèle SaaS pour les développeurs et les clients, sans qu'il soit nécessaire de redévelopper l'application spécialement pour une plateforme cloud distincte.
La portabilité de base est préservée. Une solution peut être transférée ultérieurement vers un serveur propre à l'entreprise ou vers un autre mode d'exploitation pris en charge, dans la mesure où le volume de données, les fonctionnalités et les conditions techniques le permettent. Ce changement reste une migration contrôlée, mais ne nécessite pas la refonte complète de l'application.
Une solution capable d'évoluer en fonction de vos besoins
Une nouvelle application peut dans un premier temps être développée en local et testée avec un petit ensemble de données. Par la suite, elle peut être déployée en tant qu’environnement d’exécution interne, migrée vers SQLite ou PostgreSQL, puis finalement publiée sous forme de solution serveur ou cloud. Les tables, les mises en page, les formules, les conteneurs de fonctions, les traductions et la documentation font toujours partie de la même structure de solution.
Tous les prototypes ne se transforment pas en application d'entreprise à grande échelle sans adaptations. Le fonctionnement multi-utilisateurs, la sécurité, les performances et la sauvegarde doivent continuer à faire l'objet d'une planification minutieuse. La plateforme évite toutefois que la croissance n'implique inévitablement un changement complet de technologie.
Runtime, Control et Cloud permettent ainsi de combiner différents modèles d'exploitation au sein d'une architecture commune. L'application est développée une seule fois, puis déployée de manière contrôlée en fonction de l'utilisation prévue : en local, sur un serveur dédié ou en tant que SaaS dans le cloud.
Avec plaisir. Je placerais cette section juste après le chapitre consacré à l'IA ou en complément du chapitre 4. Elle aborde une idée importante : l'IA n'est pas liée de manière rigide à un fournisseur, mais est considérée, à l'instar des adaptateurs de bases de données, comme une infrastructure interchangeable.
Des adaptateurs IA plutôt qu'une dépendance vis-à-vis d'un fabricant
SchallOS sépare délibérément la couche d'IA proprement dite des modèles linguistiques utilisés. La plateforme ne fonctionne pas exclusivement avec un seul fournisseur ou un environnement d'exécution spécifique. Au contraire, différents adaptateurs d'IA peuvent être configurés et gérés de manière centralisée.
Ces adaptateurs assurent la liaison entre SchallOS et les modèles linguistiques utilisés. Ainsi, l'environnement de développement proprement dit reste le même, que la requête soit envoyée à un modèle local ou à un service cloud.
L'IA devient ainsi un composant interchangeable de la plateforme, à l'instar des adaptateurs de base de données pour IndexedDB, SQLite ou PostgreSQL.
Gestion centralisée dans SchallOS Control
La configuration de l'IA s'effectue de manière centralisée via SchallOS Control. Ce dernier permet de créer et de gérer un nombre illimité d'adaptateurs IA. Les modèles locaux et les services cloud sont tous deux pris en charge.
Les modèles locaux peuvent, par exemple, être intégrés via Ollama ou LM Studio. Pour de nombreuses tâches de développement, un modèle local compact, s'exécutant entièrement sur votre propre ordinateur, suffit amplement.
Il est également possible de configurer des modèles cloud tels que ChatGPT, Claude ou d’autres services compatibles. Chaque adaptateur dispose de sa propre configuration, comprenant notamment les identifiants d’accès, les points de terminaison, les noms de modèles ou d’autres paramètres techniques. Cela permet d’obtenir une vue d’ensemble centralisée de tous les systèmes d’IA disponibles au sein d’une installation SchallOS.
Configuré une fois, accessible partout
L'un des grands avantages de cette architecture réside dans le fait qu'un adaptateur IA, une fois configuré, n'est pas limité à un seul usage. Dès qu'un adaptateur a été configuré dans SchallOS Control, il est accessible à l'ensemble de la plateforme. Il peut par exemple être utilisé :
- dans l'éditeur de formules
- au sein des conteneurs de fonctions
- pour la documentation automatique
- lors de la migration des solutions FileMaker
- dans Adapter Studio
- ou dans les futurs outils de développement basés sur l'IA.
Le développeur n'a donc pas besoin de configurer plusieurs fois les identifiants d'accès ou les modèles. La gestion s'effectue de manière centralisée, tandis que les différents composants se contentent de sélectionner l'adaptateur souhaité.
Le modèle adapté à chaque tâche
Toutes les tâches de développement ne nécessitent pas la même puissance de calcul. Pour expliquer brièvement une formule, un petit modèle local suffit souvent. En revanche, les migrations de grande envergure ou les tâches de programmation complexes peuvent tirer parti d'un modèle cloud plus performant.
SchallOS permet donc de choisir différents adaptateurs en fonction du cas d'utilisation. Un développeur peut, par exemple, définir que les documentations simples soient systématiquement créées en local, tandis que les tâches particulièrement volumineuses soient confiées à un modèle externe. Cela permet de mieux concilier rapidité, protection des données et coûts.
Ouvert aux futurs modèles
Les progrès dans le domaine de l'intelligence artificielle sont extrêmement rapides. De nouveaux modèles apparaissent à un rythme soutenu, tandis que les systèmes existants sont constamment améliorés. C'est pourquoi SchallOS ne s'enferme pas durablement dans la dépendance d'un seul fournisseur. Ce n'est pas le nom d'un modèle particulier qui est déterminant, mais l'interface d'adaptation standardisée.
De nouveaux systèmes d'IA locaux ou basés sur le cloud pourront ainsi être ajoutés ultérieurement sans avoir à modifier l'environnement de développement proprement dit. Cette ouverture correspond à l'architecture fondamentale de SchallOS. À l’instar des adaptateurs de bases de données, les adaptateurs d’IA doivent également rester interchangeables, tandis que Studio, Runtime et l’application proprement dite peuvent continuer à fonctionner sans modification.
L'intelligence artificielle devient ainsi une fonctionnalité intégrée de manière permanente à la plateforme, quels que soient les modèles ou les fournisseurs qui s'imposeront sur le marché dans les années à venir.
Une couche d'IA à apprentissage automatique plutôt que des invites statiques
L'une des avancées majeures de SchallOS réside dans le fait que l'IA intégrée ne fonctionne plus exclusivement à partir de consignes système statiques. On assiste plutôt à l'émergence d'une couche d'IA auto-apprenante qui améliore en permanence son fonctionnement en s'appuyant sur des projets de développement réels.
Chaque exécution d'un conteneur de fonctions peut, si le développeur le souhaite, fournir des données de qualité anonymisées. De plus, des tests de performance reproductibles sont disponibles, dans le cadre desquels les conteneurs de fonctions réels d'une solution sont automatiquement testés avec différents modèles d'IA locaux et dans le cloud. SchallOS évalue non seulement la vitesse, mais surtout la qualité des résultats générés, les erreurs détectées, les cycles de réparation et le respect des contrats de programmation définis.
À partir de ces données, des profils de modèles, des « learning patterns » et des « anti-patterns » sont automatiquement générés et versionnés. La plateforme apprend ainsi non seulement quelle instruction fonctionne le mieux, mais aussi quelles stratégies ont réellement fait leurs preuves pour certaines familles de modèles, certaines tâches et certaines situations d'erreur.
Niveaux de qualification en IA, de L1 à L4
SchallOS met en place un système de qualification à plusieurs niveaux pour les modèles d'IA utilisés. Au lieu de classer chaque modèle de manière globale comme „ adapté “ ou „ inadapté “, l'évaluation s'effectue en fonction de différents domaines d'application. Un modèle peut, par exemple, atteindre le niveau de qualification le plus élevé pour les migrations FileMaker, tandis qu’il n’est dans un premier temps recommandé que de manière limitée pour les nouveaux développements sémantiques. Cette classification ne repose pas sur les informations fournies par les fabricants, mais exclusivement sur des tests de performance reproductibles et des cycles de production réels.
Cela permet à SchallOS de déterminer automatiquement quel modèle offre les meilleures chances de réussite pour une tâche donnée et à quel moment il serait judicieux d'utiliser un modèle plus puissant ou alternatif.
Des profils de modèles intelligents plutôt que des invites classiques
À l'avenir, chaque modèle d'IA pris en charge disposera de son propre profil de modèle, avec un numéro de version. Celui-ci décrit non seulement les instructions proprement dites du système, mais contient également les enseignements tirés de l'utilisation pratique de ce modèle précis.
À l'avenir, SchallOS fera notamment la distinction entre les profils destinés à :
- conteneurs de fonctions sémantiques
- Migrations FileMaker
- migrations ultérieures vers Microsoft Access, 4D ou Oracle
- ainsi que d'autres systèmes sources
Ces profils sont complétés par des textes de base modifiables, que le développeur peut adapter ou perfectionner grâce à des campagnes d'optimisation automatiques. SchallOS peut ainsi tester différentes variantes pendant la nuit et adopter automatiquement les stratégies les plus efficaces.
Les « Solution Capabilities » : une interface métier intelligente
Outre les capacités techniques de la plateforme, SchallOS introduira à l'avenir des « capacités de solution ». Celles-ci décrivent les capacités métier d'une application concrète et constituent l'interface publique entre l'IA et la logique métier. On peut citer comme exemples des fonctions telles que :
- Créer un client
- Établir un devis
- Accepter la commande
- Créer une facture
- Comptabiliser le paiement
L'IA ne peut interagir avec une solution qu'au moyen de ces capacités autorisées. L'accès direct aux conteneurs de fonctions internes est délibérément exclu. Cela permet de savoir à tout moment quelles actions une IA est effectivement autorisée à effectuer.
Le développeur peut facilement définir et gérer les versions de ses propres « Solution Capabilities ». Celles-ci sont stockées avec la solution dans le SSC et sont mises à la disposition tant de l'IA de développement que, par la suite, des utilisateurs finaux.
Apprendre à partir de projets concrets
Le moteur de benchmark intégré ne fonctionne pas avec des exemples de programmes artificiels, mais utilise, sur demande, de véritables conteneurs de fonctions de la solution concernée comme base de test. Il en résulte pour chaque application une évaluation IA personnalisée, parfaitement adaptée au style de programmation propre à l'utilisateur, aux objets métier utilisés et aux conteneurs de fonctions existants.
Plus une solution est utilisée et perfectionnée, plus ses schémas d'apprentissage s'enrichissent, et plus SchallOS est en mesure de sélectionner avec précision les modèles adaptés, d'éviter les erreurs et de générer automatiquement de nouvelles fonctionnalités.
L'intelligence proprement dite ne réside donc plus exclusivement dans le modèle linguistique lui-même, mais de plus en plus dans la solution et dans son savoir empirique qui ne cesse de s'enrichir.
Adapter Studio, une plateforme d'intégration universelle
Avec le nouvel adaptateur Studio, SchallOS évolue vers une plateforme d'intégration ouverte. À l'avenir, les systèmes externes pourront être intégrés via des adaptateurs standardisés, qu'il s'agisse de bases de données, de services cloud, d'interfaces REST ou de systèmes d'IA.
Cela permet d'éviter les intégrations rigides et propriétaires. Les développeurs peuvent ainsi connecter n'importe quel système externe à leur application via les « Solution Capabilities ». Même les solutions hybrides complexes, dans lesquelles plusieurs systèmes ERP fonctionnent en parallèle, peuvent ainsi être orchestrées avec élégance. L’IA accède exclusivement aux capacités définies et n’a pas besoin de connaître ni les structures de données internes, ni les détails techniques des systèmes connectés.
Le savoir devient le véritable capital
Avec SchallOS, le centre de gravité du développement logiciel moderne se déplace considérablement. Ce n'est plus le code source proprement dit qui constitue la principale valeur d'une application, mais les connaissances structurées qui s'y rapportent. SchallOS prend également en charge le nouveau Format OKF, publié par Google en juin 2026, afin de pouvoir ultérieurement intégrer ou partager ces connaissances de manière portable.
Les conteneurs de fonctions, la couche de connaissances, les modèles d'apprentissage, les contrats de capacités, les résultats d'analyses comparatives et les profils optimisés par modélisation font tous partie intégrante de la solution et peuvent être transférés, versionnés et développés en continu avec celle-ci.
Ainsi, chaque application SchallOS développe au fil du temps ses propres compétences en IA, qui ne cessent de s'améliorer et restent directement associées à la solution.
De la migration FileMaker à la plate-forme logicielle indépendante
SchallOS est né d'une collaboration de longue date avec FileMaker. De nombreux principes fondamentaux de la plateforme s'appuient sur l'expérience acquise avec des solutions individuelles de bases de données et d'ERP, qui ont évolué au fil des ans pour s'adapter aux besoins opérationnels de l'entreprise.
FileMaker présente des atouts particuliers en matière de développement rapide. Le modèle de données, les mises en page et la logique du programme sont étroitement liés ; les modifications sont immédiatement visibles et les premières solutions fonctionnelles peuvent être mises en place relativement rapidement.
Cette proximité entre les développeurs, les données et l'interface utilisateur doit être préservée dans SchallOS. La base technique sera toutefois entièrement repensée. SchallOS utilise son propre moteur d'exécution, ses propres conteneurs de structure et de données, une couche fonctionnelle basée sur l'IA ainsi qu'une infrastructure dédiée à la documentation, au déploiement et aux mises à jour.
FileMaker reste donc un point de départ important et une source potentielle de solutions existantes. Il n'est toutefois plus nécessaire pour l'exploitation ultérieure.
La migration ne se limite pas à l'importation d'une mise en page
Une solution FileMaker bien rodée ne se résume pas à des tables, des champs et des masques visibles. Une grande partie de son savoir-faire métier réside dans les formules, les scripts, les déclencheurs, les relations, les listes de valeurs et de nombreux cas particuliers.
Une migration efficace doit prendre en compte ces interdépendances et les transposer dans une nouvelle architecture. Les tables, les champs, les relations et les mises en page peuvent ainsi être repris de manière largement structurée. Les formules et les fonctions personnalisées sont transférées vers l'environnement de formules de SchallOS ou adaptées.
En ce qui concerne les scripts FileMaker, l'accent est d'abord mis sur la compréhension de leur rôle technique. Ils peuvent être conservés en tant que couche d'apprentissage et de référence en arrière-plan des nouveaux conteneurs de fonctions. Le code exécutable est toutefois reprogrammé par l’IA afin de s’adapter à l’architecture SchallOS. Il n’y a donc pas d’environnement d’exécution FileMaker au sein d’un nouveau système. La solution existante devient progressivement une application SchallOS autonome.
Fonctionnement autonome après la migration
Une fois la migration terminée, ni FileMaker Pro, ni FileMaker Server, ni WebDirect ne sont nécessaires. La nouvelle application utilise SchallOS Runtime, le SSC comme conteneur de structure et le SSD pour les données de production. Les formules, les conteneurs de fonctions, le multilinguisme, la documentation, les journaux d'événements et les mises à jour sont fournis par la plateforme SchallOS.
En fonction des besoins, la solution peut être exploitée en local, sous forme d'application Windows ou macOS, sur un serveur dédié ou en tant qu'offre SaaS dans SchallOS Cloud.
Cela met fin à la dépendance vis-à-vis d'un environnement d'exécution propriétaire unique. Les dépendances techniques ne disparaissent toutefois pas complètement : tout logiciel moderne nécessite des systèmes d'exploitation, des bases de données et des services serveur. La structure, la logique métier et les données restent cependant portables et peuvent être exploitées via des adaptateurs et des voies de déploiement documentés.
De nouvelles possibilités pour les développeurs FileMaker
Pour les développeurs FileMaker, SchallOS ne doit pas représenter une rupture totale avec les méthodes de travail habituelles. Les connaissances en matière de modèles de données, de conception de mise en page et de processus opérationnels restent précieuses.
C'est surtout la mise en œuvre de la logique du programme qui évolue. Les longues chaînes de scripts sont remplacées par des conteneurs de fonctions décrits de manière sémantique. L'IA programme le code exécutable sur la base de tâches, de paramètres et de limites définis. Le développeur vérifie le résultat et reste responsable de l'architecture et de l'exactitude technique.
L'historique du développement est également mieux pris en compte. Les modifications peuvent être automatiquement enregistrées, documentées et regroupées dans des versions. Le même pipeline de mise à jour, utilisé pour mettre à jour SchallOS lui-même, est également disponible pour les solutions personnalisées des clients.
Le travail passe ainsi en partie de la saisie manuelle d'étapes de programme individuelles à la description, à la vérification et à la structuration précises des processus métier.
Pas uniquement pour les applications migrées
La migration FileMaker reste un élément important de SchallOS, mais ce n'est pas sa seule finalité. De nouvelles applications peuvent être entièrement développées dans SchallOS Studio.
À long terme, d'autres systèmes sources pourraient également être pris en charge. Une telle extension nécessite toutefois, dans chaque cas, des procédures d'analyse et de migration spécifiques. Les différentes plateformes de développement ont leurs propres concepts, qui ne peuvent pas être reproduits de manière satisfaisante par une importation universelle superficielle.
L'expérience acquise lors de la migration FileMaker constitue une base solide à cet effet. L'objectif premier de SchallOS réside toutefois dans le développement et l'exploitation d'applications métier indépendantes.
Lancement prévu à l'automne 2026
Le lancement public de SchallOS est prévu pour l'automne 2026. D'ici là, les principaux modules de la plateforme continueront d'être intégrés, testés et préparés pour les premiers cas d'utilisation en production. Toutes les fonctionnalités prévues à long terme ne seront pas encore entièrement développées dès le lancement. L’essentiel est de disposer d’un noyau robuste sur lequel d’autres adaptateurs de bases de données, fonctions d’IA, options de migration et modèles d’exploitation pourront s’appuyer de manière contrôlée.
Dans un premier temps, on procède à la Logiciel ERP gFM-NEXT de gofilemaker.de devrait être publié sur la nouvelle plateforme SchallOS en septembre 2026. Le lancement de la plateforme de développement SchallOS, prévu un peu plus tard à l'automne 2026, ne marquera donc pas la fin du développement, mais le début de sa mise en œuvre pratique.
Le cycle de vie complet d'une application
SchallOS est né d'une réflexion sur la manière dont les solutions FileMaker existantes pouvaient être transposées dans un environnement moderne. Il en est résulté une plateforme qui prend en compte non seulement la migration et le développement, mais aussi la documentation, le déploiement, la gestion des données, les mises à jour et l'exploitation à long terme. Studio, Runtime, Control et Cloud assument des tâches clairement distinctes au sein d’une architecture commune. L’objectif n’est donc pas simplement de remplacer FileMaker par un autre outil de développement. SchallOS vise à allier la proximité éprouvée entre le développeur, les données et l’interface utilisateur à des conteneurs portables, à une programmation assistée par l’IA et à un modèle d’exploitation de bout en bout.
L'ADN FileMaker constitue le point de départ. L'objectif est de créer une plateforme indépendante sur laquelle les applications métier existantes et nouvelles pourront être développées, exploitées et maintenues à long terme.
Foire aux questions
- Qu'est-ce que SchallOS exactement, et en quoi diffère-t-il d'une application de base de données classique ?
SchallOS est une plateforme dédiée au développement, à l'exécution et à la gestion de logiciels métier personnalisés. Elle comprend non seulement des tableaux, des mises en page et des fonctions, mais aussi la programmation assistée par IA, la documentation, les journaux d'événements, le déploiement et les mises à jour. SchallOS Studio sert au développement, Runtime exécute les applications finies, Control gère les installations et Cloud fournit des solutions en mode SaaS. La plateforme accompagne ainsi une application depuis sa création jusqu'à son exploitation à long terme. - À quels développeurs et entreprises s'adresse SchallOS ?
SchallOS s'adresse tout particulièrement aux développeurs FileMaker, aux éditeurs de logiciels et aux développeurs d'applications métier personnalisées. Les entreprises disposant déjà de solutions FileMaker ont également la possibilité de migrer progressivement leurs applications vers un environnement indépendant. De plus, de nouvelles solutions peuvent être entièrement développées au sein de SchallOS. Pour les dirigeants et les responsables techniques, l’aspect le plus intéressant réside dans le fait que le développement, l’exploitation, la documentation, les mises à jour et les différentes formes de déploiement sont organisés au sein d’une plateforme commune. - SchallOS est-il principalement destiné à remplacer FileMaker ?
FileMaker constitue un point de départ important, mais ne représente pas la base technique durable de SchallOS. Les concepts éprouvés, tels que le développement visuel et l'intégration étroite entre les données, les mises en page et les fonctionnalités, sont repris. Le moteur d'exécution, la gestion des données, la logique fonctionnelle et l'infrastructure de mise à jour sont toutefois développés de manière indépendante. SchallOS permet de migrer les solutions FileMaker existantes, mais convient également aux nouvelles applications. Une fois la migration terminée, FileMaker n'est plus nécessaire pour l'exploitation en production. - Ma solution FileMaker actuelle peut-elle être migrée de manière entièrement automatique ?
Les tables, les champs, les relations, les mises en page et autres structures définies peuvent être reprises de manière largement automatisée. Toutefois, en cas de logique métier complexe, une vérification supplémentaire s'impose. Les scripts FileMaker contiennent souvent des changements de mise en page, des variables globales, des plugins ou des cas particuliers hérités du passé. L'IA peut analyser ces processus et créer de nouveaux conteneurs de fonctions à partir de ceux-ci. Une solution complète doit néanmoins être vérifiée par un développeur et, le cas échéant, corrigée. La migration réduit considérablement la charge de travail manuel, mais ne remplace pas la compréhension technique de l'application. - Qu'advient-il des scripts FileMaker existants après la migration ?
Les scripts peuvent être conservés en arrière-plan des nouveaux conteneurs de fonctions, en tant que couche d'apprentissage et de référence. Ils ne sont toutefois pas exécutés tels quels. L'IA analyse la tâche métier qu'un script remplit, les champs qu'il utilise et les conditions qu'il vérifie. Elle programme ensuite le nouveau code exécutable en l'adaptant à l'architecture SchallOS. Le script d'origine est conservé comme source de connaissances historique et peut continuer à être pris en compte en cas de questions ou d'extensions ultérieures. - Que sont les SSC et les SSD, et pourquoi une solution nécessite-t-elle deux conteneurs ?
Le SSC contient la structure de l'application, notamment les tables, les zones, les mises en page, les formules, les conteneurs de fonctions, les langues et la documentation. Le SSD contient les données opérationnelles telles que les clients, les articles, les commandes ou les factures. Ces deux conteneurs vont de pair, mais ont des rôles différents. Cette séparation permet de créer de nouvelles versions de la structure vers 1TP12 sans avoir à remplacer l'ensemble de la base de données. De plus, la gestion des données, les sauvegardes et les modèles d'exploitation peuvent être modifiés sans avoir à redévelopper entièrement l'application. - Quels sont les avantages de la séparation entre la structure et les données ?
Les mises à jour, les sauvegardes et les migrations peuvent ainsi être effectuées de manière beaucoup plus contrôlée. Un nouveau SSC peut être publié tout en conservant le SSD contenant les données des clients. Les modifications structurelles nécessaires sont mises en œuvre via des migrations de données définies. Le SSC peut en outre être analysé ou transmis à un autre développeur sans contenir de données commerciales confidentielles. Le passage d’IndexedDB à SQLite, PostgreSQL ou au cloud est également facilité, car il n’est pas nécessaire de recréer les mises en page et la logique fonctionnelle. - Cette solution peut-elle fonctionner à la fois en local, sur un serveur et dans le cloud ?
En principe, oui. Une solution SchallOS peut être exploitée localement dans un navigateur, sous forme d'application Windows ou macOS, avec SQLite, sur un serveur PostgreSQL ou en tant que SaaS dans SchallOS Cloud. L'application métier reste la même dans tous les cas. Cependant, les différents modes d’exploitation ont leurs propres exigences en matière de fonctionnement multi-utilisateurs, de sauvegarde, de performances et d’administration. La transition s’effectue donc de manière contrôlée, via un transfert et une vérification des données. L’architecture SSC/SSD évite de devoir gérer un projet entièrement nouveau pour chaque cible. - Une fois la migration réussie, ai-je encore besoin de FileMaker ou de FileMaker Server ?
Non. Une fois la migration terminée, l'application est exécutée par SchallOS Runtime. Le fonctionnement en mode navigateur ne nécessite pas non plus de serveur FileMaker ni de WebDirect. L'ancien système FileMaker peut être conservé à titre de référence ou d'archive, mais il ne constitue pas une condition préalable à l'exploitation en production. Les mises en page, les formules, les fonctions, l'accès aux données, les mises à jour et le déploiement sont pris en charge par SchallOS. Les dépendances d'exécution FileMaker existantes pour l'application migrée sont ainsi supprimées. - Comment l'intelligence artificielle est-elle intégrée à SchallOS ?
L'IA est directement disponible dans l'éditeur de formules, dans les fonctions personnalisées, les conteneurs de fonctions et dans la couche de documentation. Elle connaît non seulement la question actuelle, mais aussi les champs, tables, descriptions et dépendances concernés. Pour les solutions migrées, le script FileMaker d’origine peut en outre servir de base de connaissances. L’IA est capable d’expliquer des formules, de générer du code, d’analyser les erreurs et de rédiger de la documentation. Les modèles doivent en principe rester interchangeables afin de pouvoir prendre en compte la qualité, les coûts et la protection des données. - L'IA programme-t-elle réellement le code des conteneurs de fonctions ?
Oui. Le développeur décrit la tâche, les paramètres, le résultat attendu et les capacités autorisées. Sur cette base, l'IA génère le code exécutable. Celui-ci reste visible, vérifiable et peut faire l'objet d'un contrôle de version. Le développeur peut demander des modifications, effectuer des tests et comparer ou restaurer des versions antérieures. L’IA prend ainsi en charge une grande partie du travail de programmation, mais pas la responsabilité technique. En particulier dans le cas de processus critiques pour l’entreprise, les exigences, les droits et les effets secondaires potentiels doivent continuer à être contrôlés avec soin. - Quelles sont les fonctionnalités offertes par l'éditeur de formules ?
L'éditeur de formules prend en charge les calculs mathématiques, logiques et textuels courants, ainsi que les calculs de date et d'heure. Les formules et les fonctions personnalisées sont évaluées en temps réel et peuvent être testées immédiatement. L'ensemble initial de commandes est plus restreint que le répertoire de fonctions de FileMaker, qui s'est enrichi au fil des années. L'environnement de formules est toutefois extensible. Les fonctions manquantes peuvent être ajoutées ou remplacées par des fonctions personnalisées. Dans ce contexte également, l'IA intégrée peut transposer des formules FileMaker existantes ou développer de nouveaux calculs. - Quels éléments SchallOS enregistre-t-il automatiquement ?
Au niveau structurel, les modifications apportées aux tables, aux champs, aux mises en page, aux formules et aux conteneurs de fonctions sont enregistrées. Au niveau des données, les modifications d'enregistrements, les changements de statut, les validations, les importations et d'autres événements métier peuvent être consignés. À cela s'ajoutent les événements opérationnels tels que les déploiements, les mises à jour et les sauvegardes. Les travaux de développement connexes peuvent être regroupés dans des « sessions de modification » et attribués ultérieurement à une version. Il en résulte un historique traçable de l'application, plutôt qu'une simple collection de notes rédigées a posteriori. - SchallOS peut-il générer des rapports sur les clients et les prestations à partir de ces données ?
Oui. L'IA intégrée peut générer, à partir des événements enregistrés, de la documentation technique, des rapports clients, des notes de mise à jour ou des rapports de performance. Plusieurs modifications techniques peuvent ainsi être regroupées en une description claire des avantages commerciaux. Les événements sous-jacents restent consultables, ce qui permet au développeur de vérifier les formulations. Toutes les modifications ne sont pas automatiquement facturables. La sélection, l'évaluation et la validation du relevé de prestations définitif restent donc du ressort du développeur. - Comment fonctionne le processus de mise à jour ?
Les modifications sont d'abord regroupées dans des « Change Sessions », puis consolidées en une version. Une version peut contenir un nouveau SSC, les migrations SSD nécessaires, les prérequis, les signatures, les contrôles et les informations de restauration. SchallOS Control vérifie l'instance cible, effectue une sauvegarde, puis exécute la mise à jour. Une fois l’installation terminée, un contrôle est effectué pour vérifier si la structure, les données et les fonctions essentielles correspondent à l’état attendu. Ce même pipeline de base est utilisé pour SchallOS lui-même et pour les solutions clients développées à partir de celui-ci. - En quoi les termes « Runtime », « Control » et « Cloud » diffèrent-ils les uns des autres ?
SchallOS Runtime exécute les applications publiées et met à disposition les mises en page, les formules et les conteneurs de fonctions. SchallOS Control gère les instances, les adaptateurs de base de données, les profils d'exécution, les mises à jour et les contrôles techniques. SchallOS Cloud propose l'environnement d'exécution et le stockage des données sous la forme d'un service SaaS géré de manière centralisée. SchallOS Studio reste l'environnement de développement proprement dit. Tous ces modules utilisent les mêmes structures de base SSC et SSD, mais assument des tâches clairement distinctes les unes des autres au sein du cycle de vie d'une application. - Comment les droits, les installations et les données sensibles sont-ils protégés ?
Les droits d'utilisateur déterminent les actions métier qu'une personne est autorisée à effectuer au sein de la solution. Les profils d'exécution et de capacités définissent en outre les fonctions techniques dont dispose réellement une installation. Les paquets SSC et SSD peuvent être protégés par des identifiants, des sommes de contrôle et des signatures. Le contexte de l’IA peut également être limité, de sorte que toutes les données clients ne soient pas traitées automatiquement. Pour les environnements particulièrement sensibles, il est possible d’utiliser des serveurs dédiés ou, à l’avenir, des modèles d’IA locaux. La configuration de sécurité concrète dépend du cas d’utilisation concerné. - Quand SchallOS sera-t-il disponible ?
Le lancement public est prévu pour l'automne 2026. Dans un premier temps, l’accent sera mis sur Studio et Runtime, la séparation entre SSC et SSD, la migration des structures FileMaker existantes, les formules, les fonctions personnalisées, les conteneurs de fonctions programmés par IA, la documentation, les journaux d’événements, le déploiement et les mises à jour. SchallOS Control jouera également un rôle central dans la gestion des installations. Toutes les fonctionnalités prévues à long terme ne doivent pas nécessairement être entièrement développées dès le lancement. L’essentiel est, dans un premier temps, de disposer d’un noyau robuste pour les premières applications en production.
