La publication multiplateforme semble simple jusqu'à ce qu'il soit découvert que les plateformes vivent leur propre vie. YouTube peut renvoyer une erreur de serveur pendant quelques minutes, Telegram peut temporairement restreindre un bot, VK peut demander une réauthentification du token d'administrateur de la communauté précisément au moment où la vidéo devait être publiée simultanément sur trois canaux. La question n'est pas de savoir si une telle panne se produira, mais ce que le système fera lorsqu'elle se produira.
L'approche la plus naïve de l'auto-publication est de la considérer comme une opération atomique : soit le matériel est publié partout en même temps, soit il ne l'est pas du tout, et en cas de panne partielle, tout doit être refait manuellement. En pratique, c'est le scénario le plus désagréable : la vidéo est déjà publiée sur YouTube avec le bon titre et la bonne miniature, tandis que la publication sur Telegram et VK est suspendue en raison de l'indisponibilité temporaire de la plateforme — et maintenant, il faut se débrouiller manuellement pour savoir ce qui a été publié et ce qui ne l'a pas été, afin de ne pas dupliquer la publication.
Nous avons délibérément intégré dans Telematic une logique qui considère la panne partielle de publication non pas comme une exception, mais comme un scénario de travail attendu — et qui le traite automatiquement.
//Qu'est-ce que la publication partielle
Lorsque le matériel est publié simultanément sur plusieurs plateformes, le système considère chaque plateforme comme une tentative distincte dans le cadre d'une seule publication, et non comme une étape atomique unique. Si, par exemple, YouTube et Telegram acceptent le matériel, mais que VK renvoie une erreur à ce moment-là — la publication n'est considérée ni entièrement réussie, ni entièrement échouée. Elle obtient le statut partiellement publié : une partie des canaux a déjà été publiée, une autre attend son tour.
C'est une différence fondamentale par rapport à l'approche "tout ou rien". Cela évite d'avoir à annuler des publications déjà réussies simplement parce qu'une plateforme a échoué, et en même temps, cela empêche le système de considérer silencieusement le matériel comme "publié", si en réalité seule une partie des canaux a été publiée.
//Relance automatique sur les canaux restants
Après qu'une publication ait été marquée comme partielle, le système ne laisse pas le problème à la discrétion de l'homme. Il entreprend automatiquement des tentatives répétées sur les plateformes qui n'ont pas fonctionné du premier coup, sans qu'il soit nécessaire que quelqu'un se connecte manuellement à la fiche de contenu, vérifie ce qui n'a pas été publié, et clique sur "publier" à nouveau uniquement pour les canaux nécessaires.
C'est particulièrement important pour les pannes temporaires : limitation de fréquence des requêtes sur la plateforme, indisponibilité temporaire de l'API, token expiré qui va bientôt être mis à jour. Dans la plupart de ces cas, une nouvelle tentative après un certain temps réussit sans aucune intervention — le système rattrape lui-même les canaux restants, et le matériel atteint progressivement le statut de complètement publié.
//Républication régulière programmée pour l'ensemble du projet
Un niveau de protection distinct — non pas un rattrapage ponctuel d'une seule publication, mais une vérification régulière au niveau de l'ensemble du projet : le système examine selon un calendrier les publications qui sont restées partielles plus longtemps que prévu, et tente de fermer les canaux restants. C'est une sécurité au cas où des pannes plus longues se produiraient — par exemple, si la plateforme était indisponible non pas pendant cinq minutes, mais pendant plusieurs heures, et que le rattrapage automatique habituel n'avait pas encore eu le temps de fonctionner dans le premier cycle.
Pour cette républication, il est important que le projet ait un calendrier de publications actif configuré — c'est lui qui détermine le rythme auquel le système revient aux publications inachevées et vérifie leur état. Sans calendrier, les publications partielles seront tout de même visibles dans l'interface, mais le rattrapage automatique régulier sera limité.
//Notre expérience : le jour où l'un de nos canaux a été désactivé
Un jour, l'un de nos canaux a été désactivé pendant plusieurs heures — la plateforme effectuait des travaux techniques planifiés de son côté, dont nous n'avons été informés qu'à travers les erreurs qui revenaient. Pendant ce temps, plusieurs publications étaient passées en pilote automatique, qui devaient être publiées simultanément sur plusieurs plateformes.
Si le système avait fonctionné selon le principe "tout ou rien", chacune de ces publications aurait dû être reconstruite manuellement et renvoyée sur tous les canaux — risquant de dupliquer le matériel là où il avait déjà été publié correctement. Au lieu de cela, nous avons simplement vu dans l'interface plusieurs publications avec le statut "partiellement publié" : sur les plateformes opérationnelles, le matériel a été publié à temps, tandis que sur le canal inaccessible, l'enregistrement attendait honnêtement son tour.
Lorsque la plateforme a été rétablie quelques heures plus tard, la républication régulière programmée a automatiquement pris en charge les publications restantes sans aucune intervention manuelle de notre part — nous avons simplement consulté le calendrier le lendemain et avons vu que tout s'était fermé tout seul. C'est le cas où la fiabilité opérationnelle fonctionne discrètement : le problème était là, mais il ne nous a pas créé de travail.
//Que signifie cela en pratique
Si vous voyez dans le projet une publication avec le statut "partiellement publiée", ce n'est pas une raison de se précipiter pour vérifier manuellement et dupliquer la publication sur les canaux manquants — il y a de fortes chances que le système ait déjà mis une nouvelle tentative en attente et s'en occupera de lui-même lors du prochain cycle. L'intervention manuelle n'a de sens que lorsque le statut partiel persiste anormalement longtemps — c'est un signal que le problème du côté de la plateforme est plus sérieux qu'une simple panne temporaire, et nécessite une attention particulière (par exemple, une autorisation réellement expirée qui doit être mise à jour manuellement).
Il est également important de s'assurer que le projet a un calendrier de publications actif configuré — il ne détermine pas seulement quand le nouveau contenu est publié, mais établit également le rythme auquel le système revient aux publications inachevées. Un projet sans calendrier actif perd une partie de la protection automatique en cas de pannes prolongées des plateformes.
En fin de compte, l'idée de publication partielle et de rattrapage automatique est simple : la panne d'une plateforme ne doit pas devenir un problème pour l'ensemble de la publication, et encore moins se transformer en travail manuel pour une personne qui voulait simplement que la vidéo soit publiée partout où elle devait l'être.