--- title: "Surfaces et fiches" url: https://developers.dagio.ai/fr/surfaces/ --- # Surfaces et fiches ## Une fiche qui reste ouverte Une Surface est un contenu ou une fiche doté d’une identité stable. La fiche Atelier Nord rassemble ses informations, ses notes et ses liens dans un écran que vous pouvez lire et modifier. Elle n’impose pas d’ouvrir une grande fenêtre de formulaire pour chaque modification. Le Model détermine les Fields placés dans le contenu principal et ceux réservés aux paramètres. Une zone de texte longue apparaît comme une section : un titre et un texte éditable dessous. Un choix, une date ou un booléen conserve un contrôle adapté à sa valeur. | Élément | Contenu attendu | Interaction | | ---------- | ------------------------------------ | ----------------------------------------- | | Identité | Titre, sous-titre, avatar ou icône | Reconnaître immédiatement la fiche | | Sections | Fields, texte ou résultat de Query | Lire et modifier au bon endroit | | Paramètres | Fields de configuration | Ouvrir un formulaire ciblé | | Actions | Opérations permises dans ce contexte | Préparer une proposition, archiver | | Liens | Groupes de relations | Ouvrir un objet lié ou voir la collection | Dans la fiche Data du Builder local, les Fields se trouvent dans le panneau latéral droit, avec les relations. Le contenu documentaire garde la zone principale. Modifier un Field conserve sa validation et sa sauvegarde automatique. Sur écran étroit, le panneau suit le contenu. ## Surfaces d’extension et données liées Installer une extension ajoute ses templates illustrés à **Nouvelle Surface** dans les Spaces compatibles. Un classeur GridCraft est créé dans un Space Content et s’ouvre dans sa Surface. Son identité, ses liens, ses droits et son historique restent ceux de cette Surface. Ouvrez le panneau **Data** de la Surface pour ajouter un Data Space autorisé et choisir ses Fields. **Refresh** relit la source et remplace les cellules importées de la table liée. Modifier les cellules ne modifie pas la source. **Unlink** retire la liaison et conserve les cellules. Sauvegarde et restauration de l’historique conservent ensemble le classeur et ses liaisons. Ouvrir ou annuler le choix d’une source ne constitue pas une modification. Chaque actualisation vérifie l’accès courant à la source. Une capture déjà enregistrée suit les droits de sa Surface; elle ne donne pas le droit de relire la source. L’assistant utilise les mêmes contrôles d’accès et les commandes natives de contenu de l’extension, même lorsque l’éditeur est fermé. Les Data Sources de Queries exigent leur fournisseur natif et restent indisponibles tant qu’il n’est pas fourni. Les préférences d’extension se trouvent dans **Settings → Extensions**. Pour GridCraft, thème, langue, barre de formule et AutoComplete sont des préférences utilisateur; les paramètres de calcul restent dans le classeur. ## Concevoir une application dans le Builder local Ouvrez **Builder** depuis l’application pour configurer le contexte courant. **Model**, **Spaces**, **Workmaps**, **Chat Views** et **Links** conservent leur propre navigation. Les cartes ouvrent des réglages ciblés; l’application reste visible pendant la conception. Les changements sont enregistrés dans un brouillon de conception. Le Builder ouvert en affiche l’aperçu dans l’application. Sa fermeture retrouve la définition publiée; sa réouverture reprend le brouillon. **Publish** permet de revoir puis d’appliquer les changements à cette application. Publier une version réutilisable dans le catalogue privé est une opération distincte. Les fiches existantes et l’historique des Surfaces sont conservés. La sauvegarde inclut le Model complet et ses Instructions, avec un budget total de requête JSON de 1 Mio. Les limites des Fields et des Surfaces restent applicables. En cas d’échec, gardez le Builder ouvert et utilisez **Recheck draft** pour réessayer les changements conservés après correction de l’erreur. Dans **Model → Application settings**, choisissez **Application icon** pour ouvrir la bibliothèque dans toute la zone des réglages. Filtrez par catégorie, recherchez et utilisez les pages numérotées. Les descriptions utilisent le champ multiligne partagé, avec une poignée de redimensionnement sous sa bordure inférieure. Les layouts du Model et des Spaces ouvrent **Settings →** depuis la même rangée d’en-tête. **Add space** conserve son en-tête entre **Create a space**, **Marketplace**, le **Private Repository** Pro et les dépôts des organisations Business auxquels vous avez accès. Utilisez **Search spaces...** et les catégories Data, Knowledge et Content pour filtrer le catalogue. Ces choix conservent les droits de votre compte et de vos organisations. **Model JSON**, **Chat View JSON** et le JSON des dispositions Workmap personnalisées ouvrent un éditeur dans toute la zone de contenu du Builder : coloration, repli des blocs, recherche, complétion et diagnostics de schéma. **Format JSON** formate explicitement le texte. Les erreurs métier bloquent toujours l’admission; corrigez-les avant de revenir au Builder. Modifier un brouillon ne publie pas le Model. Dans **Workmaps → Steps → Definition**, **Completion criteria** utilise un seul éditeur Surface riche pour les titres, listes, mises en forme et liens. Les critères sont capturés à la création d’un travail et restent lisibles dans son détail et par l’assistant. Modifier le Model concerne les futurs travaux. Les critères guident la complétion; ils ne la certifient pas automatiquement. Space Layout est le point d’entrée unique vers **Space Settings**, **Space Fields**, **Space Views** et **Space Instructions**; chaque page revient au layout sans deuxième rangée d’onglets. Le bouton **Instructions** est à droite de l’en-tête du layout. Les Fields conservent leurs valeurs par défaut typées. La liste et la fiche Field sont compactes, avec **Back to Fields**. La bibliothèque d’icônes occupe toute la zone de contenu du Builder dans les réglages Field et Space, comme pour le Model. Les Instructions éditables offrent environ douze lignes initiales, des marges intérieures et une toolbar jointe à la bordure du champ. Une Action possède les cartes illustrées Definition, Instructions, Chat View et Placement, avec **Delete** sous les quatre cartes. La suppression modifie le brouillon et prend effet à sa publication. Son formulaire et son JSON personnalisé partagent un aperçu interactif. Les étapes Workmap peuvent contenir des sous-étapes et leurs propres Actions. Dans une étape, **Work documentation** démarre avec une liste vide. **Add Templates** ouvre le sélecteur : créer un template, parcourir le Marketplace, utiliser le Private Repository Pro ou un dépôt Organization Business accessible. **Custom template** crée une Page, Slide ou Board. Chaque template ouvre **Definition**, **Instructions**, **Fields** et **Contents**. Les Fields reprennent les mêmes contrôles de gestion que Space Fields. Contents ouvre l'éditeur Surface avec **View**, **Edit** et **Layout**. Un template réutilisable ne transporte pas les liaisons privées de médias ou de composants vivants. Démarrer le travail crée une Surface indépendante par template configuré, avec ses propres Fields, valeurs par défaut et instructions. Ses valeurs se modifient dans le panneau de détails **Fields**. D'autres Surfaces peuvent être ajoutées pendant le travail, avec un template choisi explicitement ou une Surface vide. Modifier le Model concerne les travaux futurs; les travaux existants gardent leurs templates capturés. Supprimer un template demande confirmation et conserve les Surfaces déjà créées. L'assistant lit les Fields et instructions lorsqu'il ouvre la Surface concernée. Une étape ouverte du Workmap propose **Delete** sous ses cartes. La confirmation retire du brouillon l'étape, ses sous-étapes et les Actions utilisées uniquement par celles-ci. Chaque parcours conserve au moins une étape principale. La publication change les travaux futurs; les travaux existants conservent leurs étapes et leurs documents capturés. **Chat Views** présente les cartes conversationnelles réutilisables. Le bouton **Add Chat View** à droite du titre ouvre un sélecteur de templates : **Information card**, **Comparison**, **Response form** ou **Custom** pour une carte vide. Choisissez un template, puis modifiez sa disposition, son contenu riche et ses questions. Décrivez quand l’assistant devrait l’utiliser. Le réglage **Chat View** d’une Action peut référencer l’une de ces cartes ou conserver sa propre vue. L’aperçu utilise les mêmes composants que l’application et la MCP App. Pendant une conversation, l’assistant peut choisir une carte déclarée ou composer une nouvelle carte avec les composants disponibles. Les cartes d’affichage peuvent contenir sections, tableaux et contrôles locaux; les formulaires attendent la réponse de l’utilisateur. Les cartes affichent les données reçues : une information externe exige un outil de données connecté. Soumettre une réponse n’approuve pas une opération métier. L’app locale possède ses threads; une conversation dans ChatGPT ou un autre hôte MCP reste chez cet hôte. L’hébergement distant et la qualification réelle des hôtes restent distincts du Builder local. Le moteur de conversation local transmet les instructions Surface et ses outils disponibles à chaque étape. Avec un compte connecté et un modèle autorisant la recherche web, l’assistant peut chercher des informations actuelles et les afficher dans une carte. Les liens des sources restent dans la conversation enregistrée. Si le fournisseur refuse la recherche, le chat indique cette limite. La disposition d’une carte ne confère aucun accès aux données. Pour une question sur votre travail, l’assistant local peut découvrir l’application ou le Space personnel courant, puis lire ses instructions explicites et les entrées Knowledge pertinentes. Il charge ces documents au besoin. Le manuel système Surface EN/FR est inclus avec l’application; l’usager n’a rien à installer. En développement, activez **Developer mode** et **System Knowledge view** dans **Settings → Developer**, puis choisissez **Open System Knowledge**. Le manuel utilise la même vue Knowledge Space, en lecture seule. Le chat local et les assistants MCP peuvent chercher et lire le même manuel au besoin. Les connexions MCP reçoivent aussi un minimum d’instructions de navigation Surface. Le manuel décrit l’usage du produit; les outils disponibles et les droits déterminent toujours ce que l’assistant peut faire. Les éléments liés précisent les Spaces, les libellés réciproques et les cardinalités. Les Links entre applications associent des Fields exacts et s’appliquent dès leur sauvegarde. Dans **Application settings**, activer **Working guide** crée un Knowledge nommé **Working Guide**. Il reste visible dans les Spaces de l’application, où vous pouvez le renommer et modifier ses instructions et ses notes. Placez-y vos conventions, méthodes et critères de qualité. Activer **Application memory** crée un Knowledge interne distinct; il apparaît dans Spaces uniquement en développement. L’assistant y conserve des leçons concises et réutilisables et les corrections explicites, avec une référence et un statut d’incertitude. Il cherche avant d’écrire, consolide les leçons existantes et archive celles qui deviennent obsolètes. La mémoire ne doit contenir ni secrets, ni conversations brutes, ni état d’exécution temporaire. Votre Working Guide prime sur la mémoire apprise; aucun des deux ne confère de permissions. Le chat et les assistants MCP découvrent ces rôles et chargent uniquement les instructions et entrées pertinentes au besoin. Un salut ne charge pas leur contenu. Désactiver un rôle conserve son Space et ses notes; désactiver la mémoire bloque aussi ses outils dédiés de lecture et d’écriture. La réactivation réutilise le même Space. Publiez les changements du Builder pour les appliquer à l’application. L’assistance AI du Builder exige encore son host conversationnel compatible. ## Vues de collection dans l’Application Builder local Le Model peut déclarer Table, Kanban, Calendar, Timeline, Gantt et un Canvas de fiches pour la même collection Data. Configurez les noms et les Fields dans **Spaces → Data → Views**. Kanban utilise un Field de choix, Calendar une date, et Timeline des dates de début et de fin. Chaque carte ou élément planifié ouvre la fiche originale. Filtres et recherche conservent la même Query. Les déplacements Kanban utilisent le writer de la fiche avec contrôle de version. Gantt demande des mappings explicites de durée, progression et jalon, en plus des dates. Ses dépendances fin-vers-début et son chemin critique utilisent une Query complète bornée; les valeurs absentes restent visibles au lieu de devenir zéro. Canvas organise les fiches de la page courante et leurs Links associés; **Save layout** conserve la disposition partagée. Cette vue est distincte du contenu Canvas natif destiné au dessin. La Surface universelle est native dans Data, Knowledge et Content; les réglages du Model ne proposent aucune activation Canvas. **Add Surface** crée la même composition pour les textes, formes, images et pages. Document est un composant de texte riche à l’intérieur de cette composition. Les Models conservent leurs restrictions d’objets et de ressources. Sauvegarde, objets protégés et restauration des révisions utilisent le cycle de contenu partagé. Les images conservent des références immuables; une police qualifiée ou une source d’image manquante est signalée. Les sources de composants réutilisables, données visuelles, exports natifs et hôte distant restent des intégrations distinctes. Les vues paginées indiquent leur couverture bornée. Gantt refuse une capture incomplète ou trop grande plutôt que d’afficher un chemin critique partiel. Ces ajouts concernent le Builder local; l’intégration MCP App distante est distincte. ## Modifier sans perdre le contexte Sélectionnez la valeur à modifier et saisissez votre changement. Les validations liées au Field s’appliquent au moment prévu par l’opération. Une valeur en cours de saisie reste distincte d’une mise à jour distante. Si une autre modification concerne la même valeur, l’interface vous permet d’examiner le conflit au lieu d’effacer votre saisie. Pour archiver, supprimer ou restaurer un contenu, examinez d’abord les effets proposés et les descendants concernés. Le reçu distingue les contenus changés de ceux laissés inchangés. Ces opérations conservent les références et l’historique; elles ne constituent pas une purge physique des données. Une restauration conserve la référence à son opération d’origine, consultable dans les détails. ## Classer avec des Tags Le panneau **Tags** distingue le contenu entier d'une section déclarée. Enregistrez d'abord les modifications du contenu avant de préparer un ajout ou un retrait. La lecture seule permet de consulter les Tags et leur historique, sans les modifier. Pour réutiliser un Tag, sélectionnez-le depuis une ressource accessible, ouvrez la destination, puis examinez la proposition. Une confirmation dont le résultat reste inconnu se reprend comme la même demande. Si le Tag est enregistré mais que l'actualisation échoue, rouvrez le panneau pour relire son état, sans répéter la modification. Changer la langue conserve vos libellés, votre saisie et la section sélectionnée; les références exactes restent consultables dans les détails. ## Lire les liens Le panneau latéral regroupe les relations par type. Pour Atelier Nord, il peut présenter **Soumissions**, **Travaux associés** et **Documents**. Chaque groupe montre un aperçu limité, puis **Voir tout** ouvre la collection complète avec son contexte et ses filtres. ## Exemple La section **Besoins du client** contient le texte éditable. Le Field **État** propose Prospect, Actif ou Inactif. Le bouton **Paramètres** contient les options de suivi. Le panneau **Soumissions** affiche les propositions liées. Tous ces éléments décrivent la même fiche. ## Actions contextuelles dans le Builder local Dans **Spaces → Actions**, déclarez un nom, un workspace et des instructions pour l’AI. Les fiches Data, entrées Content/Knowledge et détails Workmap enregistrés affichent le menu Actions correspondant. **Prepare action** lit la cible enregistrée et la révision exacte du Model. Enregistrez d’abord les modifications en attente. La préparation n’exécute aucun Flow, n’appelle aucun modèle payant et ne change pas l’avancement. Les modifications conservent les contrôles de droits et de révision. L’envoi de cette UI locale vers la conversation exige un host MCP App connecté. La même déclaration choisit les emplacements : élément complet, texte sélectionné, une ligne ou plusieurs lignes. Les sélections utilisent le document enregistré ou jusqu’à 100 révisions exactes de fiches Data. Les cases de sélection conservent la navigation normale vers les fiches. Une vue interactive facultative déclare des champs texte ou choix et se prévisualise dans le Builder. MCP `action_view` ouvre cette vue dans un host conversationnel compatible; `action_respond` valide sa réponse avant la continuation. Cette validation ne modifie aucune donnée métier et ne fait pas avancer le Workmap. La qualification réelle dans ChatGPT et l’authentification distante restent distinctes des essais locaux. ## Exemples appliqués : Notes visibles, réglages accessibles Placez le suivi dans la Surface et le courriel dans les paramètres, en conservant les mêmes Fields. ### Configuration Fragment à placer dans `presentation.recordProfiles[].detail.sections`. [Propriétés et valeurs admises](https://developers.dagio.ai/fr/reference/workspace-record-profile/). ```json [ { "kind": "fields", "key": "follow-up", "label": "Suivi du client", "fieldPaths": ["fields/notes", "fields/status"] } ] ``` ### Variante et raccordement Fragment à placer dans `presentation.recordProfiles[].detail.settings`. [Propriétés et valeurs admises](https://developers.dagio.ai/fr/reference/workspace-record-profile/). ```json { "fieldPaths": ["fields/email"] } ``` ### Exemple de disposition UI La disposition illustrative ci-dessous situe cette configuration dans l’app Clients/Soumissions. Chaque fragment s’insère à l’emplacement indiqué; ses références aux Fields, Queries et Actions correspondent aux déclarations du Model. 1. Identité du client 2. Notes et suivi 3. Paramètres 4. Soumissions liées ## Exemples appliqués : Notes visibles, réglages accessibles Placez le suivi dans la Surface et le courriel dans les paramètres, en conservant les mêmes Fields. ### Configuration Fragment à placer dans `presentation.recordProfiles[].detail.sections`. [Propriétés et valeurs admises](https://developers.dagio.ai/fr/reference/workspace-record-profile/). ```json [ { "kind": "fields", "key": "follow-up", "label": "Suivi du client", "fieldPaths": [ "fields/notes", "fields/status" ] } ] ``` ### Variante et raccordement Fragment à placer dans `presentation.recordProfiles[].detail.settings`. [Propriétés et valeurs admises](https://developers.dagio.ai/fr/reference/workspace-record-profile/). ```json { "fieldPaths": [ "fields/email" ] } ``` ### Exemple de disposition UI La disposition illustrative ci-dessous situe cette configuration dans l’app Clients/Soumissions. Chaque fragment s’insère à l’emplacement indiqué; ses références aux Fields, Queries et Actions correspondent aux déclarations du Model. 1. Identité du client 2. Notes et suivi 3. Paramètres 4. Soumissions liées