Gestionnaire de réseaux sociaux automatisé : du brief créatif à la publication programmée

Un social media manager automatisé doit faire plus que rédiger des légendes ou remplir un calendrier. Il doit accompagner une campagne depuis son brief d’origine jusqu’à une publication fiable, en passant par des créations fidèles à la marque, des versions adaptées à chaque canal et une étape de validation. L’objectif n’est pas d’écarter les humains du travail créatif, mais de réduire la coordination répétitive tout en gardant le jugement humain là où il compte.

Voici comment nous l’abordons chez Dika Design et dans Dika Studio. Dika Studio est notre espace de production pour les briefs, les kits de marque, les médias de référence et les éléments de campagne modifiables. Nos automatisations peuvent déjà s’exécuter selon un calendrier, générer du texte, appliquer des conditions et envoyer des notifications. Les publications programmées sur les réseaux sociaux figurent encore sur notre feuille de route et ne sont pas encore disponibles. Dans cet article, nous décrivons le flux dont un tel système a besoin, nous disons clairement ce qui fonctionne aujourd’hui et ce qui arrive, et nous traitons l’approbation des plateformes comme une étape à part.

Ce que gère réellement un social media manager automatisé

Un social media manager coordonne une chaîne de décisions, pas simplement une suite de prompts de génération de texte. Quelqu’un définit l’objectif, choisit l’audience, décide de ce que le public doit comprendre ou faire, crée les visuels et les textes adaptés, vérifie chaque version, obtient la validation, puis publie sur le bon compte au bon moment. Chaque passage de relais peut introduire des erreurs : un lien périmé, une allégation non validée, le mauvais compte, une image obsolète ou une publication qui rate sa fenêtre de lancement.

L’automatisation peut rendre ces passages de relais visibles et reproductibles. Elle peut transmettre les faits validés, réclamer les informations manquantes, préparer des variantes, vérifier les limites et prévenir le bon relecteur. Elle peut aussi conserver une trace de ce qui a été exécuté et de la version approuvée. En revanche, elle ne doit pas faire autorité sur la stratégie de marque, les allégations juridiques ou l’opportunité de publier un contenu. Ces décisions exigent des responsables et des règles clairement identifiés.

La bonne question n’est pas « L’IA peut-elle écrire un post ? », mais « Une équipe peut-elle faire passer de façon fiable un contenu de campagne validé du brief à la publication sans perdre le contexte ? ». Cette question change la façon de concevoir le workflow : le brief, les ressources sources, la connexion au compte, l’état de validation, l’heure programmée et le résultat de la diffusion font tous partie d’un même processus traçable.

Partir d’un brief qui contient des décisions

Dans notre processus de production, le brief donne à l’automatisation quelque chose de concret à préserver. « Écris un post sur notre nouveau produit » laisse le système deviner l’audience, le bénéfice produit, l’objectif de la campagne, l’action souhaitée et le ton. Un brief plus utile précise l’objectif de campagne, l’audience, le message clé, les preuves, l’appel à l’action, l’URL de destination, le canal, le format, le calendrier et les contraintes. Il indique aussi ce qui ne doit pas changer : caractéristiques produit, allégations validées, prix, mentions légales ou dates d’embargo.

Le brief n’a pas besoin de devenir un long formulaire que personne ne veut remplir. Quelques champs structurés suffisent à rendre les informations importantes vérifiables. Par exemple, un brief de lancement peut nommer le produit, la cible, un bénéfice principal, deux faits à l’appui, la landing page validée, la date de lancement, les formats sociaux demandés et la personne chargée de la relecture. Si un champ n’est pas pertinent, l’équipe peut le marquer « sans objet » plutôt que de laisser le workflow deviner.

Un contexte structuré permet aussi de définir des règles de validation utiles. Si une annonce exige une URL de destination et qu’aucune n’est fournie, le workflow peut s’arrêter et la réclamer. Si la demande porte sur une vidéo sans fichier vidéo ni direction de production, il peut renvoyer la campagne pour clarification. Si un brief contient une allégation sensible, il peut imposer un relecteur compétent. Ces contrôles sont bien plus fiables que de demander à un modèle de langage de deviner ce que le responsable de campagne voulait dire.

Distinguez le contexte de marque durable de l’orientation propre à une campagne. Un kit de marque décrit l’identité et la voix dans la durée. Le brief explique pourquoi cette campagne existe et ce qu’elle doit accomplir. Dans Dika Studio, une marque contient des champs comme le ton, l’archétype, les messages clés, les mots à utiliser ou à éviter, les couleurs, la typographie et les éléments de marque. Ces champs orientent la création, mais ne remplacent pas l’audience, l’offre ou les faits validés de la campagne.

Transformer un brief en plan de campagne

Avant de générer chaque livrable, transformez le brief en un petit plan de campagne qu’une personne peut examiner. Il peut définir un message central, quelques arguments, le rôle de chaque publication, les formats nécessaires et les canaux visés. Une version peut présenter la campagne, une autre répondre à une question fréquente, une troisième clarifier l’offre et la prochaine étape. Vous obtenez ainsi une variété utile, au lieu de plusieurs légendes qui disent toutes la même chose.

Le plan permet aussi au workflow de repérer les éléments manquants avant le début du travail créatif. La campagne a-t-elle une page de destination définitive ? Les dates de lancement et les embargos sont-ils clairs ? Le nom du produit est-il cohérent ? L’équipe a-t-elle fourni une image source exploitable dans chaque format demandé ? Une audience ou un canal appelle-t-il une formulation différente ? Répondre à ces questions en amont réduit les corrections tardives et évite des générations inutiles.

Le manager peut alors rattacher chaque version au même contexte de campagne tout en lui donnant son propre texte, ses médias, sa plateforme, son compte et son état de validation. Si une légende Instagram change, cette modification ne doit pas écraser en silence la version LinkedIn. Si un visuel est refusé sur un canal, l’équipe doit pouvoir le remplacer sans perdre le texte validé ni le calendrier des autres versions.

Utiliser le contexte de marque pour guider des choix concrets

Le contexte de marque fonctionne mieux lorsqu’il influence des décisions concrètes. Un guide de ton peut orienter la longueur des phrases, le vocabulaire et le degré de franchise avec lequel un post s’adresse à son lecteur. Les messages clés fournissent des différenciateurs validés. Une liste de mots à éviter empêche des formules connues mais hors marque de s’infiltrer dans chaque campagne. La palette, la typographie, le logo et les images de référence aident à garder des visuels cohérents d’un lot de ressources à l’autre.

Une bonne automatisation a quand même besoin d’une frontière entre les faits et le langage généré. Elle peut suggérer une accroche, proposer d’autres appels à l’action, raccourcir une légende ou adapter un message à une autre audience. Elle ne doit pas inventer un résultat produit, une garantie, un prix, un témoignage client ou une allégation de performance. Un bon système garde les faits sources à portée de main, demande au modèle de travailler dans ce cadre et signale les affirmations non étayées pour relecture au lieu de les tenir silencieusement pour vraies.

La voix de marque ne doit pas imposer un texte identique partout. « Utilise un langage direct et chaleureux ; évite les promesses exagérées ; rends la prochaine étape claire » donne une vraie direction à un rédacteur. Le brief fixe l’intention de la campagne, le contexte de marque définit la palette de ton, et chaque plateforme impose ses propres contraintes. Le résultat doit être un brouillon propre à chaque canal qui respecte les trois.

Adapter chaque version à sa plateforme

Dans notre flux créatif, réutiliser un design sur plusieurs réseaux n’est efficace que si le visuel est adapté. Le format d’image, les zones de sécurité, les exigences médias, les limites de texte et les attentes du public varient. Notre tutoriel sur les publications sociales montre comment créer un design de base, le dupliquer, redimensionner les copies et ajuster leur mise en page. Il précise que modifier la taille du canevas ne réorganise pas automatiquement chaque élément. Un visuel redimensionné doit donc toujours être vérifié avant l’export ou la publication.

Le texte demande la même attention. Un post court qui fonctionne sur un réseau peut avoir besoin de plus de contexte sur un autre. Un carrousel doit avoir une première slide compréhensible isolément. Une légende vidéo doit correspondre au contenu parlé et à l’image de fin. Si le workflow connaît les limites actuelles du réseau cible, il peut signaler une légende trop longue ou un fichier média inadapté avant que le relecteur ne considère la version comme finale.

Un système de design peut accélérer l’adaptation sans prétendre que tous les formats sont interchangeables. Une équipe peut établir une base carrée, une variante verticale pour les stories et une option paysage, puis ajuster espacements, hiérarchie et placement du texte sur chaque copie. L’original reste intact pendant que l’équipe prépare les alternatives. C’est un workflow de production utile dès aujourd’hui, que la publication finale se fasse à la main ou via une future intégration.

Utiliser l’automatisation pour faire avancer le travail

Dans Dika Studio, une automatisation est un graphe composé d’un déclencheur relié à des actions, des étapes d’IA et de la logique. Le catalogue de nœuds comprend des déclencheurs programmés, Générer du texte, des conditions, des filtres, des délais, des notifications et des activités de calendrier. Certaines entrées du catalogue ne sont pas encore reliées à un exécuteur, et nous les signalons comme telles : chaque historique d’exécution montre ce qui s’est réellement passé, y compris lorsqu’une étape a été ignorée.

Les équipes de Dika Design peuvent lancer la préparation au rythme de leur choix grâce à un flux programmé. Celui-ci peut rédiger une série d’idées, mettre en forme un message de relecture ou rappeler à l’équipe de vérifier une campagne avant son lancement. Les déclencheurs acceptent des calendriers par intervalle, quotidiens, hebdomadaires et cron, avec un fuseau horaire IANA comme Europe/Istanbul. Une équipe peut tester un graphe, examiner son exécution, puis activer une version publiée une fois le résultat juste.

Ces fonctionnalités rendent un workflow utile sans en faire un outil de publication sociale. Le graphe d’automatisation peut préparer le travail, appliquer des conditions et prévenir un relecteur. On ne peut pas supposer qu’il envoie une publication vers un réseau externe simplement parce qu’il possède un déclencheur horaire ou une action de calendrier. Un calendrier de workflow et un calendrier de publication sociale correspondent à deux tâches différentes et exigent des données et un suivi de statut distincts.

Les étapes d’IA ont aussi leurs dépendances. Générer du texte s’exécute avec une clé de fournisseur d’IA connectée et enregistre une étape ignorée si aucune clé n’est disponible. Le nœud de génération d’images exige une clé de fournisseur compatible ; le nœud de génération vidéo est indiqué comme ignoré plutôt que relié à un fournisseur. Un processus de campagne de bout en bout ne doit donc pas laisser croire que chaque visuel ou vidéo peut déjà être généré, programmé et publié par un seul graphe automatisé.

Un contrôle explicite et versionné

La relecture doit être un véritable état du workflow, pas un commentaire noyé dans une conversation. Un relecteur doit voir ensemble le brief de campagne, le texte final, le visuel, le compte cible, l’heure prévue et les options propres à la plateforme. L’approbation doit porter sur une version précise d’un livrable. Si quelqu’un modifie ensuite le texte, l’image, la destination ou les options de publication, ce changement doit être visible et peut nécessiter une nouvelle approbation.

Toutes les publications ne suivent pas le même parcours. Une mise à jour à faible risque basée sur un modèle pré-approuvé peut passer par une relecture légère. Un lancement de produit, une prise de parole publique, une offre ou une allégation réglementée peuvent exiger un approbateur nommé avant publication. Un workflow peut aiguiller le travail selon le type de campagne ou la catégorie de risque, mais la règle sous-jacente doit être définie par l’équipe. L’automatisation doit appliquer une décision, pas en inventer une.

Dans le système de publication sociale que nous construisons, l’état « en attente de relecture » est tenu à l’écart des états publiables. Avant qu’un élément puisse être promu automatiquement après une échéance, le système enregistre d’abord que le relecteur a été notifié. C’est un mécanisme de sécurité utile : si une règle autorise la promotion automatique après une échéance, le système doit vérifier que le relecteur prévu a bien été prévenu. Cette file de relecture fait partie de la publication programmée à venir, ce n’est pas encore une fonctionnalité utilisable.

Un calendrier de workflow n’est pas un calendrier de publication

Un calendrier de workflow répond à la question : « Quand ce graphe doit-il démarrer ? ». Un calendrier de publication sociale répond à : « Quel contenu validé ce compte connecté doit-il publier, et à quelle heure ? ». La seconde question exige un enregistrement de publication durable, un compte cible, une heure de publication tenant compte du fuseau horaire, un texte et des médias validés, des options propres à la plateforme et un état de diffusion. Un événement de calendrier ou un simple déclencheur cron ne fournit rien de tout cela.

Les publications programmées figurent sur notre feuille de route en tant que fonctionnalité prévue. En attendant leur arrivée, planifiez le calendrier vous-même et publiez en dehors de l’application. La programmation des flux existe déjà, mais publier une publication sociale à heure fixe depuis Dika Studio n’est pas encore possible.

Ce n’est pas une petite nuance de formulation. Les équipes prennent des décisions opérationnelles selon que les publications partiront ou non pendant leur absence. Un déclencheur programmé qui lance un flux à 9 h ne prouve pas qu’une publication sera envoyée à 9 h sur Instagram, LinkedIn ou un autre réseau. Pour tenir cette promesse, le produit doit proposer le flux de publication, valider la connexion du compte, préserver le contenu approuvé et rapporter le résultat renvoyé par la plateforme.

Distinguer l’architecture du statut de déploiement

Nous construisons la publication programmée sur des connexions de comptes propres à chaque marque, des jetons chiffrés, un adaptateur distinct par plateforme, des états de relecture, des enregistrements de publication durables et un worker de publication programmée. Les premières plateformes pour lesquelles nous concevons sont LinkedIn, Facebook, Instagram, X et TikTok. Chaque publication conserve ses références d’éléments, ses tentatives de publication et l’identifiant renvoyé par le réseau. Rien de tout cela n’est encore activé pour les utilisateurs, et chaque plateforme doit aussi approuver notre application avant sa mise en service.

Ce que nous construisons et ce que vous pouvez utiliser aujourd’hui sont deux questions différentes. Nous concevons en fonction de la direction du produit, mais vous devriez planifier en fonction de ce qui est disponible aujourd’hui. Nous annoncerons la publication programmée dans notre feuille de route et notre documentation dès sa sortie ; d’ici là, considérez-la comme à venir. Chaque réseau social exigera aussi sa propre connexion de compte et son approbation avant de pouvoir être utilisé.

Le tableau ci-dessous distingue ce que vous pouvez utiliser aujourd’hui de ce que nous construisons encore. Les approbations des plateformes sont des étapes à part, qu’un graphe de flux ne peut pas accorder.

L’approbation des plateformes est un chantier à part

Les intégrations sociales dépendent de règles de plateforme qui peuvent changer à tout moment, indépendamment de nous. LinkedIn distingue la publication par un membre de la publication par une organisation, et les actions d’organisation dépendent de règles d’accès et de rôles de page éligibles. Sa documentation de la Posts API liste les autorisations et les restrictions de rôle. Un flux de connexion peut réussir alors qu’une opération sur une page entreprise reste indisponible pour cette application ou ce membre.

Pour Facebook, nous développons la publication pour les Pages, pas pour les profils personnels, et nous la validerons avec l’application approuvée et les autorisations actuelles avant sa sortie. La publication sur Instagram dépend aussi du type de compte : la documentation de l’API Instagram de Meta décrit la publication pour les comptes professionnels. Nous concevons pour les comptes professionnels et les autorisations de publication ; l’application, les autorisations et le parcours de validation exacts dépendront du mode de connexion que nous publierons.

TikTok rend la frontière d’audit particulièrement claire. Son guide de configuration de l’API Content Posting indique que les publications issues de clients non audités sont limitées à une visibilité privée, et que le client doit réussir un audit pour lever cette restriction. Un code capable de soumettre une requête n’équivaut pas à l’autorisation de publier publiquement. Un produit doit signaler cette différence clairement plutôt que de considérer un envoi de test réussi comme la preuve d’un accès public.

X demande aussi une décision opérationnelle, pas seulement une intégration technique. Notre conception inclut un garde-fou explicite sur les coûts, et la X Developer Platform décrit une facturation de l’API à l’usage. Avant d’activer un canal, une équipe doit comprendre comment l’usage est facturé, décider qui en supporte le coût et fixer des limites raisonnables. Les prix et les politiques des fournisseurs peuvent changer : toute affirmation chiffrée sur les coûts doit être revérifiée avant publication.

Pour une application gérée, l’approbation du fournisseur relève de la plateforme et de la configuration de l’application, pas du workflow du client. Avec une application apportée par le client, celui-ci peut fournir ses propres identifiants développeur, mais il lui faut tout de même un type de compte pris en charge, des périmètres valides et l’approbation requise pour l’opération souhaitée. Dans les deux cas, une authentification OAuth réussie ne garantit pas que tous les formats de médias ou types de publication soient autorisés.

Concevoir la publication pour qu’elle échoue sans danger

Publier crée un effet de bord externe. Une plateforme peut clairement accepter une publication, clairement la rejeter, expirer avant de la traiter, ou l’accepter sans que la réponse n’atteigne jamais l’application. Ces issues appellent des traitements différents. Relancer après un échec de validation clair et corrigeable peut être raisonnable. Relancer après un délai dépassé sans vérifier la destination peut créer un doublon si la première requête a abouti.

Notre worker de publication réserve les publications arrivées à échéance avant de les publier et enregistre chaque tentative. Il relance avec prudence : les échecs ordinaires peuvent être retentés jusqu’à une limite configurée, tandis qu’un résultat incertain chez le fournisseur n’est pas relancé automatiquement. C’est plus sûr que de privilégier l’apparence d’une automatisation sans interruption. Si la livraison est incertaine, affichez la publication comme à rapprocher, conservez les informations de tentative et laissez une personne vérifier la destination avant tout nouvel envoi.

Un visuel programmé doit rester stable après validation. C’est pourquoi nos publications programmées conservent des références d’éléments durables : modifier le design d’origine ne remplace pas en silence l’élément associé à une publication en file d’attente. L’utilisateur peut volontairement mettre à jour la version programmée et soumettre ce changement à relecture. Le planificateur ne doit pas interpréter chaque modification ultérieure du projet source comme une autorisation de publier un nouveau contenu.

Un contrôle de pause est tout aussi important. Si la connexion d’un compte expire, si la plateforme change une règle ou si une campagne est retirée, l’équipe doit pouvoir arrêter les nouvelles publications sans effacer l’historique. La documentation d’automatisation décrit déjà les tests, l’activation, la pause, l’historique d’exécution et les journaux par étape pour les workflows. Une fonctionnalité de publication livrée doit offrir la même clarté au niveau de chaque publication : heure programmée, événements de relecture, tentatives, réponse du fournisseur et éventuel identifiant de publication distant.

Mesurer la qualité et la fiabilité opérationnelle

Un bon manager doit rendre compte de bien plus que le nombre de brouillons produits. Les équipes ont besoin de savoir combien de temps il faut pour passer du brief à l’approbation, où les relectures s’enlisent, quelles étapes sont ignorées, à quelle fréquence le texte doit être retravaillé et combien de tentatives de publication échouent ou demandent un rapprochement manuel. Ces mesures permettent de distinguer un vrai gain de temps d’un travail simplement déplacé vers une file moins visible.

Les mesures de qualité comptent aussi. Chaque version a-t-elle conservé le message principal ? A-t-elle utilisé la bonne ressource et le bon compte de destination ? La légende respectait-elle le format demandé ? Le relecteur a-t-il apporté des modifications importantes ? Un taux de révision élevé peut révéler un brief faible, des faits sources manquants, une charte de marque floue ou un décalage entre le résultat demandé et le modèle. Le retour d’expérience n’est utile que si l’équipe le traite comme un indice pour améliorer le workflow, et non comme un score à optimiser aveuglément.

Les journaux d’exécution et les journaux de publication répondent à des questions différentes. Une vue d’activité d’automatisation peut montrer si un graphe s’est exécuté et quel nœud a réussi, échoué ou été ignoré. Un enregistrement de publication doit montrer si une publication a été approuvée, mise en file, tentée, acceptée, rejetée ou laissée dans l’incertitude par un délai dépassé. Sans ces deux niveaux, une organisation peut savoir que son workflow s’est terminé sans savoir si son audience a vu la publication.

Ce que les équipes peuvent utiliser dès maintenant

Dans Dika Studio, vous pouvez déjà créer et tester des automatisations, programmer des déclencheurs de flux, générer du texte avec une clé de fournisseur d’IA connectée, appliquer des conditions et des filtres, et consulter l’historique d’exécution. Vous pouvez aussi concevoir des visuels de publications sociales, les dupliquer, les redimensionner puis exporter le résultat. Ces fonctionnalités soutiennent déjà la production créative et la coordination des campagnes, pendant que la publication se fait en dehors de Dika Studio.

Les publications programmées ne sont pas encore disponibles : elles sont prévues, et d’ici là nous recommandons de planifier le calendrier vous-même et de publier en dehors de l’application. Connecter vos comptes sociaux, respecter les limites de chaque plateforme et obtenir l’approbation de son application sont des étapes distinctes sur ce chemin.

Cette distinction permet aux équipes de planifier sans trop promettre. Elles peuvent utiliser les fonctionnalités de design et d’automatisation existantes, garder les éléments de campagne organisés et bâtir un processus de relecture autour des outils disponibles aujourd’hui. Elles peuvent aussi préparer, le cas échéant, les identifiants de plateforme et les demandes d’approbation. La programmation et la publication automatiques des publications sociales arriveront avec une version future, et nous l’annoncerons dès sa sortie.

Un chemin concret du brief à la publication

Lorsque vous planifiez avec Dika Design, commencez par une seule campagne et un objectif ciblé. Complétez le brief, joignez les faits sources et les éléments créatifs, et décidez qui valide les versions finales. Utilisez un flux pour préparer le texte ou prévenir le relecteur uniquement là où les nœuds disponibles répondent au besoin. Testez le graphe, examinez son activité et gardez une personne dans la boucle pour toute affirmation ou tout visuel qui demande du jugement. Pour publier sur les réseaux, utilisez votre méthode actuelle en dehors de Dika Studio jusqu’à la sortie des publications programmées.

Lorsque la programmation sociale sera disponible publiquement, pilotez une plateforme et un type de compte à la fois. Vérifiez l’application OAuth, le périmètre demandé, le type de compte, le transfert des médias, les limites de légendes, la gestion des fuseaux horaires, l’annulation, le renouvellement des jetons et la remontée des échecs. Testez la vraie règle de relecture, y compris ce qui se passe quand un relecteur ne répond pas. Confirmez que la ressource approuvée reste figée après une modification du design source. Ne passez à l’échelle qu’une fois l’approbation du fournisseur et les contrôles opérationnels du produit en place.

Enfin, rendez le passage de relais compréhensible pour les personnes qui font le travail. Indiquez si un contenu est un brouillon, en attente de relecture, prêt, en file d’attente ou publié. Rendez l’heure programmée et le fuseau horaire visibles. Expliquez pourquoi un élément s’est arrêté ou a échoué. Conservez la version du contenu et l’historique des tentatives. Un social media manager automatisé bien conçu doit réduire l’incertitude, pas faire de la publication une boîte noire.

La direction de bout en bout est simple : traduire un brief créatif en contenus prêts pour chaque plateforme, conserver le contexte de marque et de campagne, envoyer les bonnes versions en relecture, ne programmer que lorsque le produit et le fournisseur le permettent, puis enregistrer ce qui s’est passé. Aujourd’hui, Dika Studio couvre les étapes créatives et de flux. La publication sociale programmée est une fonctionnalité distincte que nous construisons encore. Garder cette limite visible fait partie de la confiance que l’on peut accorder à l’automatisation elle-même.

Questions fréquentes

1. Qu’est-ce qu’un social media manager automatisé ?

Il coordonne les éléments d’entrée d’une campagne, la création de contenu, la relecture et les étapes de publication. Ses capacités exactes dépendent des fonctionnalités réellement livrées et de l’accès aux fournisseurs.

2. Les automatisations de Dika Studio peuvent-elles programmer des publications sociales aujourd’hui ?

Pas encore. Les publications programmées sont prévues sur notre feuille de route. Le calendrier d’une automatisation lance un flux ; ce n’est pas un calendrier de publication sociale.

3. Une automatisation peut-elle générer des légendes pour les réseaux sociaux ?

Oui. Le nœud Générer du texte peut rédiger un brouillon lorsqu’une clé de fournisseur d’IA compatible est connectée. Une personne doit vérifier l’exactitude du texte généré et sa cohérence avec la marque.

4. Dika Studio peut-il redimensionner un design social pour différentes plateformes ?

Oui. Vous pouvez dupliquer un design et le redimensionner pour différents formats. Le redimensionnement ne réorganise pas automatiquement chaque élément du design : chaque version doit donc être vérifiée visuellement.

5. La file de relecture sociale est-elle disponible pour les utilisateurs ?

Pas encore. Les états de relecture et la notification avant promotion font partie de la publication programmée que nous construisons.

6. Pour quels réseaux développez-vous ?

LinkedIn, Facebook, Instagram, X et TikTok. Aucun n’est encore disponible ; chacun exige sa propre connexion et l’approbation de la plateforme.

7. Pourquoi toutes les plateformes ne peuvent-elles pas être lancées en même temps ?

Les plateformes diffèrent par l’éligibilité des comptes, les permissions, les approbations d’application, les audits, les règles médias et le coût. Chaque intégration nécessite ses propres vérifications avant déploiement.

8. Pourquoi une publication programmée doit-elle conserver un instantané de sa ressource ?

Cela évite que des modifications ultérieures du design source ne remplacent en silence la création qui a été relue et mise en file d’attente.

9. Une requête de publication expirée doit-elle être relancée automatiquement ?

Pas si la plateforme a pu accepter la publication. La réaction la plus sûre consiste à conserver la tentative et à rapprocher la livraison avant de relancer.

10. Que faut-il vérifier avant d’activer une plateforme ?

Vérifiez l’approbation du fournisseur, le type de compte, les périmètres, les contraintes de médias et de légendes, l’exposition aux coûts, la règle de relecture, le renouvellement des jetons, l’annulation et la gestion des échecs.