Content Extend est le nom de travail du modèle de projet intégré Extend Platform — Stream + Content Ops d'OpenTechnologyApp — une couche de suivi et de contrôle pour les outils qui tournent réellement sur vos machines : OBS, ComfyUI, Blender, Krita, NodeCG, et la pile Docker/Postgres/Redis qui les soutient.
Il est déjà disponible aujourd'hui comme l'un des cinq modèles intégrés de l'application — choisissez-le dans le sélecteur de modèles à la création d'un projet, sans import JSON ni configuration requise.
Ce qui est suivi
Douze files, une par domaine :
| File | Ce qui s'y trouve |
|---|---|
| Machines & Bridges | Une ligne par hôte — ce qui est installé, son état de santé, sa dernière remontée |
| Tool & Service Inventory | Statut d'installation, version et santé par outil (OBS, ComfyUI, Blender, Krita, NodeCG, Docker, et plus) |
| Health Checks | Chaque métrique surveillée comme élément suivi, groupée par niveau et statut d'exécution |
| Control Commands | Actions autorisées (changements de scène, redémarrages de service) avec une machine à états approbation/bail/exécution |
| Stream Scenes & Sources | État souhaité vs. réel des scènes et sources OBS |
| Content Workflows | Définitions de workflows ComfyUI/Blender versionnées |
| Content & Render Jobs | Un élément par passage de rendu, groupé par étape du pipeline, les échecs sont marqués automatiquement |
| Asset & Model Library | Checkpoints, overlays et autres assets de sortie avec métadonnées de licence/attribution |
| Incidents | Post-mortems, reliés au health check qui les a détectés |
| Daily Reports / Weekly Reports | Un élément de synthèse par cycle |
| Setup & Change Runs | Historique d'installation/mise à jour avec notes de rollback |
Des vérifications sur trois niveaux
- T1 — Broadcast : vérifications continues pendant que vous êtes en direct (indicateurs vitaux du stream, graphismes de diffusion)
- T2 — Pipeline : profondeur de la file de rendu, pression GPU/VRAM, échecs de tâches
- T3 — Infra : services de support, stockage, dérive de version des outils
Chaque élément de vérification porte un niveau et un statut d'exécution (Pass / Flagged / Error / Not Run / Disabled), si bien qu'une passe de tri est une vue de file filtrée, pas un tableur.
Ce qui est déjà automatisé aujourd'hui
Le modèle est livré avec quatre automatisations — modestes, mais bien réelles :
- Un health check signalé passe automatiquement en priorité haute
- Une commande de contrôle terminée se marque elle-même comme faite
- Un incident critique passe en urgent
- Une tâche de rendu échouée passe en priorité haute
Aucune orchestration plus poussée n'est encore câblée — pas de règle de mise en pause automatique du rendu en direct, pas de notification Slack sortante. Ce sont des suites logiques à construire avec l'éditeur d'automatisations une fois que vous vous en servez pour de vrai ; le modèle vous donne le registre et les champs sur lesquels les accrocher, pas un livre de règles terminé.
La partie que vous construisez vous-même : le bridge
Tout ce qui précède vit dans OpenTechnologyApp. Faire entrer des données en direct et renvoyer des commandes vers OBS, ComfyUI ou Blender nécessite un petit processus bridge sur chaque machine — uniquement sortant, afin de pouvoir interroger les événements de contrôle et pousser la télémétrie sans ouvrir de port entrant. Les données d'exemple du modèle supposent explicitement cette séparation : OpenTechnologyApp conserve l'état et émet les commandes autorisées ; le bridge est ce qui parle réellement à vos outils.
Ce bridge n'est pas aujourd'hui un script livré et fonctionnel. Un prototype antérieur existe dans le paquet content-management de ce blog, mais c'est une ébauche de référence — il journalise les appels OBS/ComfyUI qu'il ferait plutôt que de les faire réellement. Si vous voulez connecter cela à du matériel réel, prévoyez d'écrire cette pièce vous-même ; le suivi côté application est la partie réellement terminée.
Playbooks
Contrairement à d'autres modèles intégrés (IT Device Audit en livre cinq), Extend Platform n'est pas encore fourni avec des playbooks. Si vous êtes du genre d'équipe qui veut un guide vérifié pour la mise en place du bridge ou le triage des incidents, c'est pour l'instant un manque que vous devrez combler vous-même — la structure de files et de champs est là pour en accrocher un.
Comment l'obtenir
Nouveau projet → Extend Platform — Stream + Content Ops depuis le sélecteur de modèles sur opentechnologyapp.com. Vous aurez les douze files, les quatre automatisations et trois tableaux de bord (Operations Overview, Stream & Health Monitor, Content & Assets) — la couche de suivi est prête. Le bridge qui la relie à vos machines réelles est la prochaine chose à construire.