# Pipeline de distribution vidéo > D’une vidéo source aux clips prêts à être relus dans TikTok : un workflow qui conserve sa progression, suit les livraisons et me laisse la main sur la publication. Projet personnel · Automatisation de workflow Rubrique: Outils & recherche [Ouvrir dans le portfolio interactif]() [English]() ## En bref | Indicateur | Valeur | | --- | --- | | Mon rôle | Orchestration persistante et intégration | | Technologies | Python · SQLite · FFmpeg | | Commandes | Telegram et terminal | | Traitement vidéo | 1 téléchargement + 1 encodage à la fois | | Livraison | Boîte de réception TikTok par compte | | Publication finale | Vérification et publication manuelles | ## Automatiser les étapes entre la vidéo et sa publication Préparer des clips, c’est enchaîner beaucoup de petites opérations : télécharger la source, découper les parties, produire une version verticale, choisir un compte, transférer les fichiers puis vérifier leur arrivée. À la main, il faut aussi se souvenir de ce qui a déjà été fait et de ce qui attend encore. J’ai construit une couche d’orchestration persistante autour d’un outil de rendu vertical existant. Elle prend en charge la préparation et la livraison, avec une file que je peux consulter et piloter depuis Telegram. Les clips arrivent dans la boîte de réception TikTok pour être relus avant leur publication. Une source, six étapes 1. **Ajouter une source** — Envoyer une URL YouTube dans Telegram ou l’ajouter au fichier d’entrée. L’identifiant vidéo évite les doublons dans la file. 2. **Télécharger et analyser** — Conserver la vidéo source, déterminer ses parties et lui attribuer un code court pour les commandes. 3. **Préparer les clips** — Utiliser le rendu vertical existant, qui tient compte des scènes. Garder les fichiers terminés pour la suite du traitement. 4. **Affecter et transférer** — Choisir un compte, y conserver toutes les parties et initialiser les envois dans leur ordre d’origine. 5. **Confirmer la livraison** — Suivre l’identifiant d’envoi jusqu’à la réception confirmée ou à l’échec. Gérer l’alerte Telegram différée séparément. 6. **Relire et publier** — Ouvrir TikTok, vérifier le clip et décider de sa publication. Cette décision reste manuelle. Ce parcours décrit le fonctionnement implémenté. Aucun nouvel envoi réel n’a été effectué pour cette fiche. ## Garder les bonnes vidéos sur le bon compte Avec plusieurs comptes, l’ordonnancement ne se résume plus à prendre le prochain fichier d’un dossier. Le pipeline affecte les sources selon le travail restant, puis donne la priorité au rendu selon les clips déjà prêts pour chaque compte. Un téléchargement et un encodage s’exécutent à la fois ; chaque compte dispose de ses propres traitements d’envoi et de suivi. Toutes les parties d’une même source restent liées au même compte. La suivante ne peut commencer son envoi que lorsque les précédentes ont atteint l’état de livraison requis. Si la première échoue ou reste dans un état incertain, la suite attend plutôt que de créer un trou dans la série. Les comptes sont associés à des identifiants stables plutôt qu’à leur nom d’affichage. Une pause est conservée après redémarrage. Désactiver un compte bloque les nouveaux travaux, tout en maintenant les vérifications des envois déjà acceptés. ## Reprendre sans deviner ce qui s’est passé Le cas délicat, c’est une requête qui a peut-être réussi côté serveur juste avant l’arrêt du programme. La relancer automatiquement pourrait envoyer le même clip deux fois. J’ai donc séparé l’acceptation de l’envoi, le transfert des données, la réception dans TikTok, l’échec et la publication, au lieu de tout ranger dans un seul état « terminé ». SQLite conserve la file, le découpage des clips, les tentatives d’envoi, les pauses des comptes et les notifications en attente. L’identifiant d’initialisation de l’envoi est enregistré avant le transfert. Après un redémarrage, le suivi reprend pour les identifiants connus ; une acceptation incertaine est mise en attente de vérification humaine. Les téléchargements et rendus terminés sont conservés. Des transactions réservent les tâches, et un verrou empêche deux instances du service de traiter la même file. La migration conserve aussi l’ancien état et bloque les envois historiques ambigus pour examen. > Pour les notifications, la garantie est différente : la livraison Telegram se fait « au moins une fois ». Un arrêt après l’acceptation d’une alerte par Telegram mais avant son enregistrement local peut encore provoquer un doublon. ## Garder la main depuis Telegram Telegram sert à la fois de point d’entrée et de télécommande. Après avoir associé une conversation privée au propriétaire, je peux ajouter une source, consulter la file et les comptes, mettre le traitement en pause, le reprendre, affecter une source dont l’envoi n’a pas commencé ou relancer un échec confirmé. Les codes courts évitent de recopier de longs identifiants. Les alertes ont leur propre file : un problème de notification ne demande pas de refaire le transfert vidéo. Une alerte ne peut partir qu’après confirmation de la réception dans TikTok, et au moins 15 minutes après le transfert. Une pause laisse l’opération en cours se terminer ; les vérifications continuent pour les envois déjà acceptés. > Par défaut, la règle locale autorise une initialisation d’envoi, réussie ou incertaine, par compte sur 24 heures glissantes. C’est un réglage prudent de planification, pas une mesure des quotas TikTok ni du débit réel. ## Mon travail et les outils utilisés Mon travail porte sur l’orchestration Python : état persistant, affectation des comptes, ordre des tâches, reprise après incident et commandes de contrôle. J’ai développé ce projet avec des agents de code IA, comme dans mon workflow habituel. Le projet réutilise un outil de rendu vertical existant, qui tient compte des scènes. Il s’appuie sur FFmpeg/FFprobe pour le traitement vidéo, TikTok pour l’envoi et le suivi de réception, et Telegram pour les commandes et les alertes. Ce que je présente ici, c’est l’intégration et la conception de la file, sans m’attribuer l’ensemble des composants de traitement vidéo. Python · SQLite · FFmpeg / FFprobe · API TikTok · Bot Telegram · File persistante ## Ce qui est établi et ce qui reste à vérifier en conditions réelles Le dépôt comprend des tests avec des bases SQLite temporaires et des appels réseau simulés : identité des comptes, affectation, limites séparées par compte, reprise après redémarrage, appairage, commandes rejouées, migration et nouvelles tentatives de notification. Ils n’ont pas été relancés pour cette revue du portfolio et ne prouvent pas, à eux seuls, la livraison d’un vrai clip. Cette fiche ne s’appuie pas sur un déploiement complet vérifié, un gain de temps mesuré ou des chiffres de croissance d’audience. Le service documenté tourne sur macOS et s’arrête lorsque la machine est en veille ou éteinte. Déplacer un espace de travail existant vers une autre machine demande aussi d’adapter les chemins des médias enregistrés. Ce projet montre la partie de l’automatisation qui m’intéresse le plus : déterminer ce que le système peut répéter, ce qu’il doit mémoriser et ce qui demande une décision humaine. Ici, l’objectif est de garder un workflow compréhensible même lorsqu’une étape échoue. > Le temps de développement et le volume total de vidéos ne sont pas documentés. La concurrence, le délai d’alerte et la fenêtre de planification indiqués plus haut sont des réglages, pas des performances mesurées.