> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/powershell-universal/fr/applis/custom-frontends.md). # Interfaces frontales personnalisées Créez des interfaces frontales personnalisées pour PowerShell Universal avec React, Vue ou du HTML et du CSS simples, puis hébergez-les comme dossiers publiés et appelez les terminaux d'API PSU. ## Interfaces frontales personnalisées Les interfaces frontales personnalisées sont des applications web statiques que vous créez avec des outils web standards et que vous hébergez avec PowerShell Universal. Elles sont utiles lorsque vous souhaitez utiliser un framework JavaScript, réutiliser un système de conception existant ou avoir un contrôle total sur l'expérience côté client. PowerShell Universal n'a pas besoin de compiler ou de comprendre le code source de votre interface frontale. Créez l'application avec les outils de votre choix, publiez les fichiers générés avec un [dossier publié](/powershell-universal/fr/plateforme/published-folders.md), et appelez les API PowerShell Universal depuis le navigateur. Cela diffère des [applis statiques](/powershell-universal/fr/applis/static-apps.md), qui sont créées à partir des définitions d'applis PowerShell Universal. Les interfaces frontales personnalisées utilisent directement du HTML, du CSS et du JavaScript standards. ## Utilisation des bibliothèques JavaScript Vous pouvez utiliser React, Vue, Angular, Svelte ou toute autre bibliothèque frontale qui produit des fichiers statiques. PowerShell Universal sert la sortie compilée, comme un dossier `dist`, `build` ou `wwwroot`. Un flux de travail typique est le suivant : 1. Créer le projet d'interface frontale avec les outils du framework. 2. Configurer la compilation pour utiliser le chemin de requête que vous publierez dans PowerShell Universal. 3. Compiler l'interface frontale. 4. Publier la sortie de compilation comme dossier publié. Lorsque vous hébergez l'application sous un chemin tel que `/dashboard`, configurez le chemin de base de votre bundler afin que les URL JavaScript, CSS, d'images et de polices se résolvent correctement. Évitez `/portal`, car il entre en conflit avec le Portal PowerShell Universal intégré. Pour les applications basées sur Vite, définissez l'option `base`. ```typescript import { defineConfig } from 'vite' export default defineConfig({ base: '/dashboard/' }) ``` Pour les applications Angular, définissez le base href lors de la compilation. ```powershell ng build --base-href /dashboard/ ``` Si l'application utilise le routage côté client, configurez le routeur pour qu'il utilise le chemin de requête publié. Vous pouvez également utiliser un routage basé sur le hachage lorsque vous ne voulez pas que le serveur gère directement les liens profonds. Pendant le développement, vous pouvez exécuter le serveur de développement local du framework et appeler les API PowerShell Universal depuis le navigateur. Si le serveur de développement s'exécute sur une origine différente de celle de PowerShell Universal, configurez [CorsHosts](/powershell-universal/fr/config/settings.md#corshosts) ou utilisez la fonctionnalité de proxy du serveur de développement frontal. En production, préférez les URL relatives afin que les appels reviennent à la même instance PowerShell Universal qui a servi l'interface frontale. ## Utilisation des frameworks CSS Vous pouvez utiliser des frameworks CSS tels que Tailwind CSS, Bootstrap, Bulma ou des bibliothèques de composants propres à un framework. Incluez le CSS de la même manière que dans toute application web statique. Pour la plupart des applications, installez le framework CSS au moyen de votre gestionnaire de paquets et incluez-le dans le bundle. Cela garde l'application autonome et évite de dépendre de CDN externes. ```powershell npm install bootstrap ``` ```javascript import 'bootstrap/dist/css/bootstrap.min.css' ``` L'interface frontale personnalisée est indépendante de la console d'administration et du PowerShell Universal App Framework. Incluez tous les styles, polices et actifs dont votre application a besoin dans la sortie de compilation ou servez-les à partir d'un autre dossier publié. ## Appel des API PSU Les interfaces frontales personnalisées peuvent appeler à la fois des terminaux d'API personnalisés et l'API de gestion PowerShell Universal. Utilisez des [terminaux d'API personnalisés](/powershell-universal/fr/api/endpoints.md) pour les données et les actions propres à l'application. C'est l'approche recommandée pour la plupart des interfaces frontales personnalisées, car vous contrôlez la route, la validation des entrées, la forme de la réponse, l'authentification et les exigences en matière de rôles. ```powershell New-PSUEndpoint -Url '/frontend/profile' -Method Get -Authentication -Endpoint { [PSCustomObject]@{ UserName = $User.Identity.Name ServerTime = Get-Date } } ``` Depuis l'interface frontale, appelez le terminal avec `fetch`. ```javascript const response = await fetch('/frontend/profile', { credentials: 'same-origin' }) if (!response.ok) { throw new Error(`Request failed: ${response.status}`) } const profile = await response.json() ``` Pour les requêtes JSON, envoyez l'en-tête `Content-Type` et analysez le corps dans le terminal ou utilisez un bloc `param`. ```powershell New-PSUEndpoint -Url '/frontend/tickets' -Method Post -Authentication -Endpoint { $Ticket = ConvertFrom-Json $Body [PSCustomObject]@{ Id = [guid]::NewGuid() Title = $Ticket.Title Created = Get-Date } } ``` ```javascript await fetch('/frontend/tickets', { method: 'POST', credentials: 'same-origin', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ title: 'Reset development environment' }) }) ``` L'API de gestion est disponible sous `/api/v1` et est destinée aux opérations administratives. Utilisez-la lorsque vous créez une interface frontale administrative et que l'utilisateur connecté possède les permissions requises. Pour les flux de travail destinés aux utilisateurs, envisagez d'exposer un plus petit terminal d'API personnalisé qui effectue uniquement l'opération dont l'interface frontale a besoin. Évitez de créer des URL de terminaux personnalisés qui entrent en conflit avec les URL internes de l'API de gestion. Consultez [Terminaux d'API](/powershell-universal/fr/api/endpoints.md) et [Sécurité des API](/powershell-universal/fr/api/security.md) pour plus de détails. ## Documenter les API avec OpenAPI La documentation [OpenAPI](/powershell-universal/fr/api/openapi.md) est utile lors de la création d'interfaces frontales personnalisées, car elle décrit le contrat d'API dans un format standard. Les développeurs et les agents d'IA peuvent l'utiliser pour comprendre les routes, les méthodes HTTP, les paramètres, les exigences d'authentification, les corps de requête, la forme des réponses et les codes d'état avant d'écrire le code frontal. Créez une définition de documentation de terminal pour l'API utilisée par votre interface frontale et assignez-lui les terminaux connexes. ```powershell New-PSUEndpointDocumentation -Name 'Dashboard API' -Url '/dashboard-api' -Description 'APIs used by the custom dashboard.' New-PSUEndpoint -Url '/frontend/tickets' -Method Get -Authentication -Documentation 'Dashboard API' -Endpoint { <# .SYNOPSIS Returns tickets displayed by the custom dashboard. .DESCRIPTION Returns the ticket list for the signed-in user. Operators receive assigned tickets and administrators receive all tickets. .OUTPUTS 200: Description: Ticket list returned successfully. 401: Description: The user is not authenticated. #> Get-Ticket | Select-Object Id, Title, Status, AssignedTo } ``` Les définitions OpenAPI apparaissent dans le tableau de bord Swagger intégré. ```http http://localhost:5000/swagger/index.html ``` Utilisez l'aide basée sur les commentaires dans les scripts de terminal pour documenter l'objectif du terminal et ses paramètres. Pour des contrats d'API plus riches, définissez les types d'entrée et de sortie dans la définition de documentation de terminal et référencez-les depuis les sections `.INPUTS` et `.OUTPUTS`. Cela aide les clients générés, les outils de test et les agents d'IA à produire des requêtes plus précises. Lorsque vous travaillez avec un agent d'IA, fournissez le document OpenAPI ou l'URL Swagger ainsi que les exigences de l'interface frontale. L'agent peut utiliser le contrat pour générer des clients d'API typés, des assistants de requête, des formulaires, la validation, les états de chargement et la gestion des erreurs qui correspondent aux terminaux réels. ## Authentification Les dossiers publiés et les terminaux d'API peuvent exiger une authentification et des rôles de façon indépendante. Pour exiger que les utilisateurs se connectent avant de charger les fichiers de l'interface frontale, activez l'authentification sur le dossier publié. ```powershell New-PSUPublishedFolder -Name 'Dashboard' -Path 'C:\Apps\Dashboard\dist' -RequestPath '/dashboard' -DefaultDocument 'index.html' -Authentication -Role 'Operator' ``` Pour protéger les données et les actions, activez l'authentification sur les terminaux d'API appelés par l'interface frontale. ```powershell New-PSUEndpoint -Url '/frontend/admin-data' -Method Get -Authentication -Role 'Administrator' -Endpoint { Get-Date } ``` Lorsque l'interface frontale est servie depuis la même instance PowerShell Universal, l'authentification par témoin fonctionne naturellement pour les utilisateurs connectés. Utilisez `credentials: 'same-origin'` avec `fetch` afin que les identifiants du navigateur soient inclus dans les requêtes vers les terminaux authentifiés. Les jetons d'application sont utiles pour l'automatisation, les intégrations externes et les appels de serveur à serveur. N'intégrez pas de jetons d'application dans le JavaScript du navigateur, ne les stockez pas dans le stockage local et ne les versionnez pas avec le code source de l'interface frontale. Si une interface frontale doit effectuer une opération qui exige des permissions élevées, créez un terminal d'API personnalisé avec l'authentification, les vérifications de rôles et la logique côté serveur appropriées. Lorsque vous devez appeler des API avec un jeton d'application depuis un client de confiance, envoyez-le dans l'en-tête `Authorization`. ````http Authorization: ****** Universal also supports the `X-PSU-Authorization` header for scenarios where a reverse proxy needs to use the standard `Authorization` header for another purpose. See [App Tokens](/pages/ybubDKrhYyjSXn4SbSJH) for token management guidance. ## Hosting Static Assets Use [published folders](/pages/7K71tKGBkFetUzIPmCdd) to host the compiled frontend files. The published folder maps a local file system path to a request path on the PowerShell Universal web server. ```powershell New-PSUPublishedFolder -Name 'Dashboard' -Path 'C:\Apps\Dashboard\dist' -RequestPath '/dashboard' -DefaultDocument 'index.html' ```` Après la publication, les utilisateurs peuvent ouvrir l'interface frontale au chemin de requête. ```http http://localhost:5000/dashboard ``` Le paramètre `-DefaultDocument` sert `index.html` lorsque l'utilisateur demande la racine du dossier. C'est important pour les applications monopages. Pour les liens directs vers des routes imbriquées côté client, utilisez un routage basé sur le hachage ou assurez-vous que votre chemin d'hébergement peut retourner le point d'entrée de l'interface frontale pour ces routes. Publiez uniquement le dossier de sortie compilé. Ne publiez pas de dossiers sources contenant des fichiers de configuration, des métadonnées de paquet, des fichiers d'environnement ou tout autre contenu qui ne devrait pas être téléchargeable. Les actifs statiques tels que les images, les polices et les fragments JavaScript générés peuvent se trouver dans le même dossier de sortie de compilation. Si vous devez partager des actifs entre plusieurs interfaces frontales ou applis, publiez un dossier distinct tel que `/assets` et référencez-le depuis l'interface frontale. ## Création avec des agents d'IA Les agents de codage IA peuvent aider à générer l'ossature d'une interface frontale personnalisée et à l'améliorer par itérations, surtout si vous fournissez d'emblée les contraintes de PowerShell Universal. Donnez à l'agent le chemin de requête, le framework, les routes d'API, les attentes en matière d'authentification et la commande de compilation que vous prévoyez utiliser. Les compétences PowerShell Universal peuvent fournir aux agents d'IA des instructions, des scripts et des références réutilisables propres à PSU. Devolutions maintient une collection de ces compétences dans le dépôt [powershell-universal-skills](https://github.com/Devolutions/powershell-universal-skills). Ces compétences suivent le format Agent Skills et peuvent aider les agents à effectuer des tâches PowerShell Universal courantes avec un contexte plus spécifique au produit. Par exemple, le dépôt comprend une compétence `install-sandbox-psu` pour installer PowerShell Universal dans un environnement bac à sable à des fins de test et de développement. Vous pouvez installer la collection avec la CLI des compétences. ```powershell npx skills add devolutions/powershell-universal-skills ``` Une fois installées, les agents de codage pris en charge peuvent utiliser les compétences automatiquement lorsqu'une tâche PowerShell Universal pertinente est détectée. Cela peut être utile lorsque vous voulez qu'un agent crée une interface frontale personnalisée et configure aussi une instance PSU locale, configure des ressources de soutien ou valide l'interface frontale par rapport à un environnement bac à sable. Par exemple : ``` Build a React and Vite frontend for PowerShell Universal. It will be hosted at /dashboard from a published folder. Configure the Vite base path for /dashboard/. Use relative fetch calls to /frontend/profile and /frontend/tickets with same-origin credentials. Do not store app tokens in the browser. Include loading, error, and empty states. ``` Voici des détails utiles à inclure dans les invites : * Le framework et le gestionnaire de paquets à utiliser. * Le chemin de requête du dossier publié. * Les URL des terminaux d'API attendues et les formes JSON. * Le document OpenAPI ou l'URL Swagger pour les API de l'interface frontale. * Si l'interface frontale est publique ou nécessite une authentification. * Le comportement propre aux rôles que l'interface utilisateur devrait afficher ou masquer. * Le dossier de sortie de compilation qui sera publié. * Toute compétence d'agent PowerShell Universal installée que l'agent devrait utiliser. Une fois que l'agent a créé l'interface frontale, examinez la configuration de compilation, exécutez la compilation de production et publiez uniquement le dossier de sortie généré avec `New-PSUPublishedFolder` ou **Build > Published Folders**. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.devolutions.net/powershell-universal/fr/applis/custom-frontends.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.