Les pipelines CG modernes sont distribués : les artistes travaillent sur différentes machines, les fermes de rendu traitent des milliers d’images en parallèle, et les outils de pipeline doivent coordonner en même temps une multitude d’éléments mobiles.
Un compositing a besoin de savoir quand un planification (shot) termine son rendu. Chaque processus en aval doit réagir immédiatement lorsqu’un actif est approuvé. Le superviseur ne devrait pas devoir l’apprendre trois heures plus tard, lorsque le rendu échoue à l’image 847.
Pourtant, de nombreux studios s’appuient encore sur des systèmes qui vérifient les mises à jour à intervalles réguliers, rafraîchissent manuellement les tableaux de bord ou dépendent du fait qu’un artiste avertisse un collègue lorsqu’une tâche est terminée, introduisant ainsi des erreurs humaines là où l’automatisation devrait faire le travail.
Dans cet article, nous passerons en revue cinq modèles de communication en temps réel : polling, webhooks, WebSockets, Server-Sent Events (SSE) et WebRTC. Pour chacun, vous verrez ce que c’est, comment cela s’applique à un contexte de pipeline CG, et où cela aide ou nuit. À la fin, vous disposerez d’une matrice de décision claire pour choisir la bonne technologie pour le bon problème.
Pourquoi le temps réel est important pour les pipelines CG
La communication en temps réel n’est pas un luxe dans les pipelines de production.
L’utilisation du matériel dépend de boucles de retour rapides. Une ferme de rendu qui tourne à vide parce que des tâches en aval attendent une mise à jour dont l’arrivée est retardée est un coût direct. Si un job de compositing ne peut pas démarrer tant qu’il n’a pas la confirmation que toutes les couches de rendu sont terminées, et que cette notification met cinq minutes à arriver à cause d’un décalage lié au polling, vous perdez cinq minutes de capacité de traitement potentielle par planification (shot). À l’échelle de centaines de plans et de plusieurs fermes, cela peut rapidement s’accumuler en des jours de capacité gaspillée.
La vitesse d’itération des artistes est également limitée par la réactivité des outils. Lorsqu’un artiste soumet un job de cache et doit rafraîchir manuellement un panneau pour vérifier l’avancement, il perd le fil et le contexte. Les outils qui poussent les mises à jour instantanément permettent aux artistes de rester dans le contexte, de détecter les échecs tôt et de planifier du travail de suivi sans changer constamment de cadre mental.
Enfin, les pipelines automatisés se dégradent sans une propagation fiable des événements. Un pipeline où l’étape B doit se déclencher automatiquement après la fin de l’étape A n’est aussi fiable que ce qui les relie. Si cette connexion est fragile, lente ou sujette aux pertes, l’automatisation se brise et les humains doivent combler le manque. Les technologies de communication en temps réel sont le tissu conjonctif des pipelines automatisés, et choisir la mauvaise technologie introduit des bugs subtils, coûteux à corriger. C’est pourquoi nous avons écrit cet article.
1. Polling
Le polling est le moyen le plus simple d’implémenter un système en temps réel : un client demande à un serveur, à intervalle fixe, « avez-vous quelque chose de nouveau pour moi ? »
Le client envoie une requête, le serveur répond avec l’état actuel ou avec toutes les mises à jour, et le client attend le prochain intervalle pour redemander.
Dans un pipeline CG, un exemple typique est un script de « render watcher » qui interroge une API de gestion de rendu toutes les 30 secondes pour vérifier si le statut d’un job a changé.
Le script n’attend pas que la ferme « prenne l’initiative » de se manifester. Il demande proactivement, analyse la réponse et met à jour un tableau de bord local ou déclenche une action en aval.
Avantages pour les pipelines CG
- Le polling est facile à mettre en œuvre. Tout outil capable d’effectuer une requête HTTP peut faire du polling, ce qui signifie qu’il fonctionne avec pratiquement tous les langages et frameworks de pipeline sans infrastructure spécifique. C’est un choix pragmatique pour les petits studios ou les outils internes rapides lorsque le coût de mise en place d’une infrastructure orientée événements n’est pas justifié.
- Le polling est également sans état côté serveur. Le serveur n’a pas besoin de maintenir une connexion persistante ni de savoir qui écoute. Pour les API de gestion de rendu déjà construites comme des services REST, le polling ne nécessite aucun changement côté serveur.
Inconvénients pour les pipelines CG
- Le polling est inefficace. Comme le client vérifie selon une planification, que quelque chose ait changé ou non, la majorité des requêtes ne renvoie aucune nouvelle information. Un soir calme où aucun job ne se termine pendant deux heures, un script de monitoring effectue des centaines de requêtes inutiles. À grande échelle, cela ajoute une charge inutile à des API déjà sous pression.
- Le polling introduit aussi une latence proportionnelle à l’intervalle. Un intervalle de 30 secondes signifie qu’une fin de job peut prendre jusqu’à 30 secondes avant d’être prise en compte. Pour les pipelines où les jobs en aval sont placés dans la file juste après la complétion en amont, ce délai est intégré à chaque passage de relais. Des intervalles plus courts réduisent ce décalage, mais augmentent le volume de requêtes, rendant le compromis difficile à ajuster à grande échelle.
2. Webhooks
Un webhook inverse le modèle du polling pour la communication machine-à-machine. Au lieu qu’un serveur Web demande quelque chose à un autre serveur de manière répétée, le serveur appelle le client lorsqu’un événement se produit. Le client enregistre un point d’extrémité d’URL (endpoint de webhook), et le serveur poste une notification sur cette URL dès qu’un événement pertinent survient.
Dans un pipeline CG, un exemple concret est un système de publication qui déclenche un webhook vers un bot Slack ou un orchestrateur de pipeline au moment où un actif est publié avec le bon statut. Lorsqu’un « lighter » approuve un actif de lookdev et que le système de gestion des actifs enregistre cette approbation, il envoie immédiatement un HTTP POST à l’endpoint webhook de l’orchestrateur avec l’ID de l’actif et le nouveau statut. L’orchestrateur déclenche ensuite la construction du rendu d’éclairage en aval sans qu’il y ait du polling dans la boucle.
Avantages pour les pipelines CG
- Les webhooks sont pilotés par les événements, ce qui signifie qu’il n’y a pas de trafic « perdu ». Le serveur n’envoie des données que lorsqu’un événement survient réellement, et le client ne fait du travail que lorsqu’il reçoit un appel. Pour les pipelines où les événements sont relativement rares mais doivent être traités rapidement, c’est un gain d’efficacité significatif par rapport au polling.
- Les webhooks découplent aussi proprement les services. Le système de gestion des actifs n’a pas besoin de savoir ce que l’orchestrateur fait de la notification ; il déclenche et « oublie ». Cela facilite l’ajout de nouveaux consommateurs d’événements de pipeline sans modifier le système source, ce qui compte dans les studios où différents outils sont gérés par différentes équipes.
Inconvénients pour les pipelines CG
- Les webhooks nécessitent que le service receveur soit accessible publiquement ou, au minimum, joignable via le réseau depuis l’émetteur. Dans des environnements de studio avec des topologies réseau complexes, des VPN et des pare-feu, ce n’est pas toujours simple. Une ferme de rendu fonctionnant dans un sous-réseau privé ne peut pas facilement envoyer des webhooks vers une machine locale d’un développeur pendant les tests.
- Les webhooks sont aussi, par défaut, « fire-and-forget ». Si l’endpoint receveur est indisponible au moment où l’événement se déclenche, la notification est perdue à moins que le système émetteur ne mette en place une logique de nouvelles tentatives avec backoff exponentiel et une dead-letter queue (file des lettres mortes). Construire cette couche de fiabilité ajoute de la complexité. Pour un pipeline qui ne peut pas se permettre de manquer un événement de fin de job, une simple intégration de webhook ne suffit pas sans l’infrastructure qui l’accompagne.
3. WebSockets
Les WebSockets établissent une connexion persistante, bidirectionnelle, entre un client et un serveur. Contrairement à un HTTP classique, qui ferme la connexion après chaque cycle requête-réponse, une connexion WebSocket reste ouverte. Chaque partie peut envoyer des messages à tout moment, sans attendre que l’autre initie.
Dans un pipeline CG, les WebSockets sont parfaitement adaptés aux tableaux de bord de monitoring de rendu en direct. Lorsqu’un artiste ou un superviseur ouvre une page d’avancement d’un planification (shot), le navigateur établit une connexion WebSocket avec le backend de gestion de rendu. Au fur et à mesure que des complétions d’images, des erreurs et des changements d’état de job se produisent sur la ferme, le serveur pousse directement ces mises à jour vers la connexion ouverte. Le tableau de bord se met à jour en temps réel sans que le navigateur doive effectuer une nouvelle requête.
C’est ce que nous utilisons pour gérer les événements dans Kitsu.
Avantages pour les pipelines CG
- Les WebSockets éliminent la surcharge liée au polling tout en offrant une latence plus faible que les webhooks pour les outils interactifs. Comme la connexion est persistante, il n’y a pas de coût de handshake TCP par mise à jour. Pour des tableaux de bord affichant des dizaines de jobs simultanés et qui doivent refléter les changements en quelques millisecondes, les WebSockets apportent la réactivité que le polling ne peut pas garantir.
- La nature bidirectionnelle des WebSockets permet aussi des outils de pipeline interactifs. Une interface de soumission où un artiste configure un job de rendu, le soumet, puis voit immédiatement un retour d’avancement en direct dans la même interface devient possible avec les WebSockets. Le client peut envoyer des paramètres de job et recevoir un flux de mises à jour d’état sur la même connexion, sans changer de protocole.
Inconvénients pour les pipelines CG
- Les WebSockets introduisent des connexions avec état que le serveur doit gérer. Si un serveur de gestion de rendu traite des milliers de connexions WebSocket concurrentes depuis des nœuds de ferme et des tableaux de bord de monitoring, la surcharge en mémoire et en descripteurs de fichiers devient un vrai sujet d’ingénierie. Mettre à l’échelle un serveur WebSocket horizontalement nécessite un broker de messages partagé comme Redis ou Kafka pour diffuser les messages entre instances, ce qui ajoute de la complexité d’infrastructure.
- Les WebSockets sont aussi plus fragiles que HTTP dans des environnements avec des proxys agressifs ou des load balancers. Certaines infrastructures réseau réseau de studio plus anciennes ne gèrent pas correctement les mises à niveau WebSocket, ce qui provoque des connexions qui chutent silencieusement ou échouent entièrement. La logique de reconnexion côté client est essentielle, mais elle est souvent insuffisamment implémentée dans les bibliothèques standard.
4. Server-Sent Events (SSE)
Les Server-Sent Events (SSE) constituent une alternative plus simple aux WebSockets pour les cas où la communication est unidirectionnelle : le serveur pousse des mises à jour vers le client, mais le client n’a pas besoin de renvoyer de messages. SSE utilise une connexion HTTP standard que le serveur maintient ouverte, en diffusant des événements au fil de l’eau dans un format texte simple.
Dans un pipeline CG, SSE est bien adapté au streaming de logs. Lorsqu’un artiste lance une simulation et veut observer la sortie du solveur en temps réel, un endpoint SSE sur le serveur du pipeline peut diffuser chaque ligne de log au moment où elle est écrite. Le navigateur ouvre une seule connexion HTTP et reçoit un flux continu de texte sans polling, sans complexité WebSocket, et sans bibliothèque client spécifique.
Avantages pour les pipelines CG
- SSE est beaucoup plus simple à mettre en œuvre que les WebSockets pour les cas d’usage serveur-vers-client. Il fonctionne sur du HTTP « pur », ce qui signifie qu’il passe à travers la plupart des proxys et des load balancers sans changements de configuration. Pour un studio où les outils internes sont construits à partir de stacks web standard, ajouter un endpoint SSE à un service API existant est assez direct.
- SSE gère aussi la reconnexion automatiquement. L’API native EventSource du navigateur se reconnecte si la connexion tombe et reprend à partir de l’ID de l’événement reçu le plus récemment si le serveur le permet. Pour un outil de streaming de logs qui doit survivre à un court incident réseau sans perdre la sortie, cette fiabilité intégrée est précieuse sans nécessiter de code personnalisé.
Inconvénients pour les pipelines CG
- SSE est unidirectionnel. Si le client a besoin de renvoyer des données au serveur pendant le flux, il doit faire une requête HTTP séparée sur un canal différent. Pour de simples lecteurs de logs, c’est acceptable, mais pour des outils interactifs SSE peut prendre du retard et une connexion WebSocket est plus appropriée.
- SSE est aussi limité par le pool de connexions du navigateur dans certains environnements. Les navigateurs plus anciens plafonnent le nombre de connexions SSE concurrentes vers la même origine à six, ce qui peut devenir problématique si un tableau de bord de pipeline ouvre plusieurs flux SSE indépendants en même temps. En pratique, ce n’est que rarement un problème bloquant pour les outils internes, mais il est utile de le savoir avant de concevoir un système reposant sur de nombreux flux concurrents depuis une même page.
- SSE ne gère pas non plus nativement les messages binaires. Bien entendu, vous pouvez encoder des fichiers binaires en texte, mais la surcharge de taille est importante par rapport à un équivalent WebSocket.
5. WebRTC
WebRTC (Web Real-Time Communication) est un protocole de communication pair-à-pair conçu pour transférer des données avec une faible latence et un haut débit directement entre clients, en contournant le serveur pour le canal de données lui-même. Il est surtout connu pour le streaming vidéo et audio dans des applications web, mais il prend aussi en charge le transfert de données binaires arbitraires via ses canaux de données.
Dans un pipeline CG, WebRTC a des cas d’usage « de niche », mais puissants, comme le streaming d’aperçu en direct, la messagerie (chat) ou les transferts P2P. Lorsqu’un artiste itère sur l’ombrage (shading) ou l’éclairage dans un poste de travail GPU distant et veut voir le rendu du viewport dans un navigateur local sans faire d’allers-retours via un serveur, un canal de données WebRTC peut diffuser directement le tampon de pixels depuis la machine GPU vers le navigateur avec une latence de l’ordre de quelques millisecondes (single-digit millisecond latency). C’est ce que la plupart des solutions de visioconférence web utilisent.
Avantages pour les pipelines CG
- WebRTC offre la latence la plus faible atteignable pour le streaming basé navigateur, car les données circulent en pair-à-pair plutôt que par l’intermédiaire d’un serveur. Pour un streaming interactif du viewport où l’utilisateur s’attend à ce que l’image se mette à jour en réponse au mouvement de sa souris, sans latence perceptible, WebRTC est la seule option native du navigateur qui atteigne ce niveau.
- WebRTC utilise aussi un encodage binaire efficace et un contrôle de congestion intégré, ce qui le rend bien adapté au streaming de gros volumes de données image dans des conditions réseau variables. Le protocole adapte dynamiquement son débit (bitrate), ce qui est mieux qu’une implémentation naïve de WebSocket qui enverrait des images en pleine résolution indépendamment de la bande passante disponible.
Inconvénients pour les pipelines CG
- WebRTC est probablement le modèle le plus complexe de cette liste à implémenter et à exploiter. Établir une connexion pair-à-pair nécessite un serveur de signalisation pour échanger les descriptions de session et les candidats réseau, et nécessite souvent un serveur relais TURN dans les environnements où les connexions pair-à-pair directes sont bloquées par des règles NAT ou de pare-feu. Les réseaux de studio, avec leurs VPN, leurs proxys et leurs sous-réseaux segmentés, sont précisément le type d’environnement où les connexions pair-à-pair directes échouent souvent et où les serveurs TURN deviennent obligatoires.
- WebRTC est aussi conçu principalement pour les environnements navigateur, même si des bibliothèques client existent pour des langages de programmation côté serveur. Si le consommateur du flux de données est un autre processus serveur ou une application native plutôt qu’un navigateur, WebRTC ajoute de la complexité sans offrir son principal avantage d’efficacité pair-à-pair. Dans ces cas, un flux binaire WebSocket plus simple est généralement mieux adapté.
Conclusion
Les cinq technologies abordées dans cet article se situent à différents endroits sur un spectre :
- Le polling est le point de départ : facile à mettre en œuvre, compatible universellement, mais inefficace et lent. Il convient aux contrôles peu fréquents où la précision en temps réel n’est pas requise, comme un générateur de rapport nocturne qui vérifie si tous les dailies ont été rendus.
- Les webhooks sont le bon outil lorsqu’un serveur doit notifier un ou plusieurs services externes à propos d’événements discrets, sans maintenir de connexion persistante. Les workflows d’approbation d’actifs, les déclencheurs de publication et les intégrations entre systèmes sont des cas d’usage naturels.
- Les WebSockets sont utiles quand vous avez besoin d’une communication bidirectionnelle à faible latence dans un outil interactif, par exemple un tableau de bord de rendu en direct qui accepte aussi des commandes utilisateur pour mettre en pause ou changer la priorité des jobs.
- SSE est une alternative plus simple lorsque le serveur doit pousser un flux continu de données vers un client et que le client n’a pas besoin de répondre, comme un outil de « tail » de logs ou un flux d’avancement pour un processus de pipeline qui dure longtemps.
- WebRTC est la solution quand vous avez besoin de transferts de données pair-à-pair avec la latence la plus faible possible, en particulier pour le streaming interactif du viewport ou pour l’aperçu en direction d’un navigateur.
Aucune de ces approches n’est universellement supérieure : les studios qui construisent des pipelines à la fois plus réactifs et plus fiables sont ceux qui comprennent chaque outil suffisamment bien pour l’associer précisément au problème à résoudre.
Commencez par auditer un endroit dans votre pipeline actuel où les artistes attendent une information que votre système possède déjà. Choisissez le modèle adapté, implémentez-le et mesurez la différence.
