Open WebUI
dans votre projet Git.

À quoi ça sert

Prévoir une interface web de conversation avec un modèle privé ; livraison actuellement bloquée.

Cette recette compose des capacités réutilisables. Votre code et vos personnalisations restent dans votre dépôt ; les paramètres publiés décrivent comment construire et exécuter le projet.

Ce qui a été vérifié

0.11.2 préparée, construite et testée, puis refusée au scan ; aucune application servie. Cible 0.11.3 préparée seulement.

• Création bloquée au scan ; mise à jour seulement testée en unité
  0.11.2 construite → 0.11.3 préparée
  Testé en unité

• CréationBloqué

  0.11.2 : préparation, construction et tests réussis, puis scan bloquant ; aucune release promue ni application servie.

• Mise à jourTesté en unité

  0.11.2 → 0.11.3 préparé, conservation et opérations testées en unité seulement ; aucune exécution dans le projet client.

• RestaurationNon vérifié

  Aucune installation disponible pour qualifier sauvegarde ou restauration.

• La preuve historique relève 11 vulnérabilités critiques et 107 élevées ; ces chiffres ne proviennent pas d’un nouveau scan.
• Des avis de dépendances relevés n’offraient pas de version corrigée ; la reprise requiert un candidat admis par les contrôles.
• Tests unitaires et construction ne qualifient ni accès utilisateur, ni inférence depuis l’application, ni mise à jour dans le projet.
• Aucune promotion, installation partiellement servie ou disponibilité générale déduite.
• Restauration non qualifiée.

Prérequis et composition

Un projet autorisé, le code complet avec ses dépendances verrouillées, et la configuration de la recette compatible avec la version retenue.

• N1-PYTHON · Python
• N1-NODE · Node.js
• N1-STATIC · Fichiers statiques
• N1-COMPOSE · Composition
• N1-PERSIST · Persistance
• N2-INFERENCE · Inférence privée

Les ressources N0 sont résolues via les capacités ci-dessus. Les services et bindings requis dépendent de la recette ; un fournisseur existant n’implique pas la création d’un nouveau serveur par application.

Les données persistantes et identités initiales se préparent avant le premier déploiement. Les secrets se gèrent dans le projet, sans les écrire dans Git.

Choisir le parcours adapté

Le statut actuel ne permet pas d’annoncer un parcours complet. Consultez le blocage ou les opérations partielles avant de préparer une installation.

Cette fiche n’annonce pas de bouton d’installation en un clic pour une recette non mise à disposition dans votre projet.

Livrer depuis Git

1. Récupérez la configuration complète publiée pour la recette et sa version ; adaptez uniquement ses paramètres autorisés.
2. Versionnez le code complet, les dépendances et paas.toml dans le dépôt relié à l’application.
3. Poussez sur la branche de livraison configurée. Le commit exact passe par construction, tests, scan, inventaire logiciel, signature et admission.
4. Vérifiez la version servie et un usage métier. Pour une mise à jour, contrôlez aussi l’identité et la conservation des données.

# Depuis le dépôt déjà relié à votre projet, sur sa branche de livraison
git add paas.toml
git commit -m "Configure la recette applicative"
git push paas main

L’exemple suppose que le remote paas et la branche main correspondent à votre projet. Le code client et les verrous de dépendances doivent eux aussi être versionnés.

Personnaliser et aller plus loin

Paramètres, thèmes, plugins et code métier évoluent dans le même projet. Une version ou une option compatible réutilise le module existant ; une responsabilité absente exige une évolution de capacité avec ses propres tests.

Chaque personnalisation repasse les contrôles. Un plugin supplémentaire n’hérite pas de la qualification de cette fiche. Les versions, opérations et paramètres du contrat restent consultables dans le détail du module.

Prochaines étapes

Une configuration connue et compatible suit le parcours déterministe, sans appel de modèle. Une configuration manquante ou un échec réparable ouvre une correction bornée ; les changements restent visibles dans Git.