Nouvelles fonctionnalités, améliorations et corrections dans Social Hub.
Connectez un blog SiteHub, transmettez les articles validés comme brouillons dans son éditeur et importez plans et brouillons via le serveur MCP Social Hub. La publication WordPress reste disponible.
Connectez un site de l'entreprise avec son identifiant SiteHub. Les articles validés deviennent des brouillons dont la structure Markdown est lisible dans l'éditeur SiteHub ; l'action ouvre ce brouillon pour la dernière vérification et la publication.
Des jetons d'API propres à chaque entreprise permettent à Claude d'importer des sujets du plan et de courts brouillons via le serveur MCP Social Hub. Une validation humaine reste nécessaire avant publication.
Un média envoyé dans le composer arrivait sur WordPress sous sa clé de stockage — une chaîne illisible comme « bc53e6be-….webp » — à la fois comme nom de fichier et comme titre dans la bibliothèque de médias. Il garde désormais son propre nom, et un nouveau champ « Texte alternatif » permet de décrire l'image pour les lecteurs d'écran et les moteurs de recherche ; les deux voyagent avec lui jusqu'à WordPress.
Un fichier envoyé depuis votre ordinateur arrive désormais sur WordPress sous son propre nom — « kit-incendie.webp » plutôt que la clé de stockage interne — et l'attachement dans la bibliothèque de médias est titré à partir de ce même nom au lieu d'afficher la clé brute.
La carte média du composer gagne un champ optionnel « Texte alternatif » décrivant ce que montre l'image. Il se publie comme description de l'image sur WordPress et LinkedIn — utile pour les lecteurs d'écran et la recherche d'images, et laissé vide, il n'a aucun effet, exactement comme avant.
Une catégorie ou une étiquette dont le nom contient une apostrophe ou un « & » s'affiche désormais correctement dans le composer, au lieu de montrer son encodage HTML brut — et surtout, choisir une telle étiquette parmi les suggestions réutilise désormais celle qui existe déjà à la publication, au lieu d'en créer en silence un doublon orthographié avec l'encodage.
Rouvrir un post enregistré portant un média joint bloquait jusqu'ici le composer — la bascule Écrire/Aperçu et la validation ne répondaient plus, et la miniature du média ne s'affichait pas. Un défaut présent depuis la toute première version, désormais corrigé.
L'éditeur Markdown de l'article comprend désormais les tableaux et les images, rendus à l'identique dans l'aperçu du composer, l'aperçu de validation et l'article publié sur WordPress. Le volet Article gagne aussi une section FAQ optionnelle, publiée en bloc FAQ Yoast avec les données structurées FAQPage. Par ailleurs, une correction : un média envoyé directement depuis votre ordinateur se publie désormais correctement comme image mise en avant WordPress ; Facebook et Instagram redirigent ces envois vers l'action manuelle en attendant un stockage public pour ces fichiers.
L'éditeur Markdown du volet Article rend désormais les tableaux GFM (colonnes séparées par `|`) et les images (``), avec le même résultat dans la bascule Écrire/Aperçu, l'aperçu de validation et l'article une fois publié sur WordPress.
Le volet Article gagne une section FAQ optionnelle et répétable (jusqu'à 20 questions) sous les champs SEO. À la publication, elle devient un bloc wp:yoast/faq-block en fin d'article, porteur des données structurées FAQPage. Le validateur voit les questions et réponses remplies dans l'aperçu de validation, à l'endroit exact où elles apparaîtront sur la page.
Un média envoyé directement depuis votre ordinateur se publie désormais comme image mise en avant sur WordPress, comme attendu. La publication Facebook et Instagram a besoin d'une adresse publique pour aller chercher le fichier, ce qu'un envoi direct n'a pas encore — ces deux plateformes redirigent maintenant le post vers l'action manuelle au lieu d'échouer en silence.
Un article sort désormais du composer prêt pour la production : choisissez la catégorie WordPress dans la vraie liste du site, ajoutez des étiquettes (créées sur le site si nouvelles, réutilisées sinon), et définissez l'expression clé Yoast — le titre SEO et la méta description que vous rédigez remplissent automatiquement les champs Yoast quand le site le permet. Validé de bout en bout contre un WordPress réel : catégorie assignée, étiquettes créées sans doublon, analyse Yoast au vert au lieu de vide.
Le volet article lit en direct les catégories et les étiquettes les plus utilisées du site connecté, propose un sélecteur de catégorie et une saisie d'étiquettes en pastilles, et préremplit les étiquettes depuis les mots-clés du sujet quand l'article vient du plan éditorial. À la publication, les étiquettes existantes sont réutilisées (jamais dupliquées) et les nouvelles sont créées ; un site qui refuse la création d'étiquettes ne fait pas échouer la publication.
Quand le site WordPress expose les champs Yoast à l'API (un petit réglage unique côté site), le titre SEO, la méta description et l'expression clé voyagent avec l'article — et l'article WordPress garde son titre éditorial, le titre SEO ne vivant que dans Yoast. Sur un site sans ce réglage, la publication se comporte exactement comme avant.
Une case à cocher dans le volet article du composer envoie l'article vers WordPress en brouillon : il arrive dans wp-admin sous « Brouillons », invisible du public, et ne devient en ligne que lorsqu'un humain le publie là-bas. Le validateur voit un badge explicite « Brouillon WordPress » avant de décider. Validé de bout en bout contre un site WordPress réel.
Cochez la case dans le volet article et tout le circuit reste identique — rédaction, relecture, approbation, planification — sauf l'appel final à WordPress qui porte « brouillon » au lieu de « publié ». Rien n'apparaît sur le site, dans les flux ni dans le plan de site ; l'article attend dans wp-admin un dernier regard humain. Les posts existants et les articles non cochés se comportent exactement comme avant.
Une nouvelle section « Suivi » ferme la boucle du contenu : mots-clés suivis avec leurs positions, un backlog d'opportunités, l'ensemble des prompts IA suivis avec citations par fournisseur et un classement des marques, et les résultats à 28 jours par article publié. Les sujets de plan de type blog peuvent, en option, référencer un mot-clé suivi et un prompt IA visé — le calendrier affiche alors leur performance en ligne. Réservé au contenu blog : les posts sociaux et les reels gardent leur propre boucle d'engagement. Un agent d'analyse externe alimente les chiffres via l'API avec deux nouvelles portées de jeton.
Quatre vues reprennent le tableau de pilotage éditorial : le registre des mots-clés (requête → page → position, impressions, clics, verdict), un backlog d'opportunités priorisé avec « Créer un sujet », l'ensemble des prompts IA suivis avec la dernière lecture cité/rang par fournisseur et le classement de visibilité des marques, et les cartes de résultats à 28 jours par article.
Un sujet blog peut référencer le mot-clé suivi qu'il vise et le prompt IA par lequel il veut être cité — les deux optionnels, et la section n'existe tout simplement pas sur les posts sociaux et les reels, qui n'ont pas de page à positionner. Quand une requête est déjà couverte par une autre page, la boîte de dialogue signale la cannibalisation (« rafraîchir plutôt que créer ? ») sans jamais bloquer.
Deux nouvelles portées de jeton (lecture/écriture du suivi) permettent à un agent d'analyse externe de pousser relevés de mots-clés, mesures de citation IA, instantanés de marque et résultats à 28 jours — de façon idempotente : un envoi rejoué ne duplique jamais une lecture. Sept outils MCP exposent la même surface à Claude, dont un contrôle de cannibalisation que l'agent de planification consulte avant de proposer un sujet. L'ingestion écrit des chiffres ; elle ne peut toujours rien approuver, planifier ni publier.
Une série de corrections révélées par un test de bout en bout de l'application : le composer bloque désormais l'envoi d'un contenu invalide au lieu de le laisser passer, un validateur voit le corps complet de l'article avant de décider, « Créer le contenu » depuis un sujet de plan conserve ses canaux et ses mots-clés, un lecteur ne voit plus d'actions qui échoueraient en silence, le calendrier hebdomadaire est lisible sur téléphone, les écrans Comptes et File d'attente affichent le bon état, et l'API producteur refuse les champs mal nommés et pagine correctement.
L'envoi en relecture applique désormais la même validation que le bouton d'enregistrement : un post trop long ou sans cible ne peut plus se glisser dans la file de validation. « Créer 3 déclinaisons » les numérote et les garde distinctes au lieu de produire trois copies identiques.
« Créer le contenu » depuis un sujet reporte désormais ses canaux cibles et ses mots-clés dans le brouillon, et le sujet ne passe à « En relecture » qu'une fois le brouillon réellement soumis, plus à l'instant de sa création.
L'écran de validation affiche désormais l'article de blog complet que le validateur approuve, avec un aperçu fidèle. Un lecteur ne voit plus de boutons créer/soumettre qui échoueraient en silence — ces actions sont masquées pour les rôles en lecture seule.
Le calendrier hebdomadaire n'écrase plus sept colonnes hors écran sur téléphone. L'écran Comptes supprime le panneau vide redondant et met la bannière d'expiration en accord avec la carte en dessous ; les comptes expirés restent visibles dans le tableau des règles de validation, et un échec de file d'attente liste désormais chaque cible en échec au lieu d'une seule.
Envoyer un post avec un mauvais nom de champ (par exemple « target » au lieu de « targetAccountIds ») renvoie désormais une erreur 422 claire au lieu d'une valeur ignorée en silence, et les outils MCP paginent le plan et les posts au lieu de toujours renvoyer la première page.
/parametres reçoit un panneau d'administration des jetons de service — créez un jeton sht_ à portée limitée, affiché une seule fois, qui permet à un outil externe ou un agent IA de créer des sujets de plan et des brouillons via l'API, mais jamais d'approuver, planifier ou publier. /approbations gagne une sélection multiple avec barre d'action persistante pour l'approbation par lot (avec espacement des dates) et le refus par lot (une note pour tous), des motifs de refus réutilisables par entreprise, et un diff mot à mot contre la version précédemment soumise. Un serveur MCP compagnon permet à Claude ou ChatGPT de se connecter avec ce même jeton.
Les administrateurs créent un jeton sht_ depuis une nouvelle section « Jetons d'API » : un nom, des autorisations cochées une à une (lire/écrire le plan, lire/écrire les posts), et le secret — affiché une seule fois, puis irrécupérable. Un jeton ne peut jamais approuver, planifier, supprimer ni publier, quelles que soient ses autorisations ; tout ce qu'il crée est marqué comme rédigé par une IA et suit la validation humaine habituelle. Un jeton révoqué reste visible dans la liste, grisé et daté, pour l'historique.
Une case à cocher sur chaque carte, plus « Tout sélectionner », ouvre une barre d'action persistante qui propose les deux mêmes verdicts appliqués à toute la sélection. L'approbation par lot ne demande une date que pour les posts qui n'en ont pas, avec un espacement au choix entre eux (même heure, 15, 30, 60 ou 120 minutes) — les posts déjà planifiés gardent la date choisie par leur auteur, sauf à cocher « Remplacer la date ». Le refus par lot envoie une seule note à tous les auteurs concernés. Aucun des deux ne s'arrête au premier échec : le résultat détaille quels posts ont échoué et pourquoi, et ceux-ci restent sélectionnés pour un nouvel essai en un clic.
La boîte de dialogue de refus — seule ou par lot — affiche désormais les motifs enregistrés par l'entreprise sous forme de pastilles cliquables au-dessus du champ de note ; cliquer sur l'une d'elles pré-remplit le texte, et « Enregistrer comme motif type » ajoute la note en cours à la liste, jusqu'à douze motifs par entreprise.
Chaque carte de /approbations peut afficher ce qui a changé depuis la version soumise avant un refus — les mots retirés apparaissent barrés, les mots ajoutés soulignés — pour ne plus avoir à repérer à l'œil les deux mots modifiés dans un post corrigé. Une première soumission n'a aucune version précédente à comparer.
Un jeton de service permet aussi de connecter Claude ou ChatGPT à Social Hub via un serveur MCP dédié, pour qu'un assistant lise le plan éditorial et rédige des brouillons directement — les lecteurs techniques trouveront le contrat complet dans docs/specs/socialhub-producer-api.md.
Une nouvelle page /plan remplace le tableur externe : chaque sujet à rédiger, son brief, ses mots-clés et son échéance, suivis à travers un parcours qui va d'Idée à Mesuré. Une vue Liste regroupe par étape, une vue Calendrier place les sujets sur leur date cible, et « Créer le contenu » transforme un sujet en brouillon lié dans le composer en un clic — le sujet suit ensuite ce post automatiquement, jusqu'à Publié.
Un nouveau sujet enregistre un titre, un type (article, post social ou reel), un brief, des mots-clés, une intention, une URL cible, des indications de canaux et une date cible. La vue Liste regroupe les sujets par étape du parcours éditorial — Idée, Brieffé, Génération, En relecture, Planifié, Publié, Mesuré — avec un compteur par statut et des filtres par type qui gardent leurs compteurs même une fois appliqués. La vue Calendrier place les sujets datés sur leur jour cible et liste séparément ceux qui n'ont pas encore de date, puisque ce sont justement les sujets qui attendent une décision.
Depuis un sujet sans post lié, « Créer le contenu » crée un brouillon pré-rempli à partir du brief et l'ouvre dans le composer. Le sujet suit ensuite ce post automatiquement : à mesure qu'il passe de brouillon à planifié puis publié, le sujet avance de lui-même d'En relecture à Planifié puis Publié — le statut ne peut avancer que dans un seul sens, de sorte qu'un sujet marqué Mesuré à la main y reste même si son post est republié.
Les éditeurs, approbateurs et administrateurs peuvent créer, modifier et supprimer des sujets ; les autres rôles voient la même liste et le même calendrier, et peuvent ouvrir un sujet pour en lire le brief, mais le bouton de création ainsi que les actions de modification et de suppression n'apparaissent pas pour eux.
Cibler WordPress ou le blog SiteHub ouvre désormais un volet Article dans le composer : un éditeur Markdown avec aperçu en direct, et un extrait, un slug et un titre/description SEO facultatifs. Cet article peut ensuite donner naissance en un clic à des brouillons courts pré-remplis pour les autres plateformes, et la file d'attente garde le parent et ses déclinaisons groupés.
Dès que WordPress ou le blog SiteHub fait partie des cibles, un volet Article apparaît sous le texte de base : un corps en Markdown avec une bascule Écrire/Aperçu rendue par le même moteur que celui utilisé pour publier sur WordPress, et une section repliable « Extrait & référencement » pour l'extrait, le slug (proposé à partir du titre, puis jamais réécrit ensuite), le titre SEO et la description SEO, chacun avec un indicateur de nombre de caractères conseillé. Retirer la dernière destination blog conserve le contenu de l'article et affiche un message posé expliquant qu'il ne sera publié nulle part tant qu'un blog n'est pas ciblé à nouveau.
Quand un post porte un article, son corps Markdown devient le HTML de l'article WordPress, et l'extrait, le slug et le titre SEO l'accompagnent. Un post sans article continue de publier son texte court exactement comme avant.
« Créer les dérivés » transforme un article en 1 à 5 brouillons courts, pré-remplis à partir de son extrait et sans plateforme choisie — à vous de décider où chacun part. Chaque déclinaison reste liée à son article et affiche une pastille « Dérivé de … » qui y renvoie ; elle se planifie, se soumet et s'approuve indépendamment, et la relation ne va qu'à un seul niveau — une déclinaison ne peut pas à son tour créer des déclinaisons. Une déclinaison créée à partir d'un article rédigé par une IA hérite de cette origine IA.
La file d'attente imbrique une déclinaison sous son article parent quand les deux sont dans le même onglet, et affiche une pastille « Dérivé de … » quand le parent se trouve dans un autre onglet ou a déjà quitté la liste. Les cartes du calendrier pour une déclinaison portent le même indicateur.
WordPress quitte le flux manuel pour devenir une véritable destination de publication : connectez un site avec son adresse, un nom d'utilisateur et un mot de passe d'application, et Social Hub vérifie les identifiants avant de les enregistrer. Par ailleurs, chaque compte connecté affiche désormais le temps qu'il lui reste, Instagram se renouvelle automatiquement avant expiration, et un compte qui a réellement besoin d'une intervention humaine reçoit une action « Reconnecter » claire et posée plutôt qu'un échec silencieux.
Connecter un site WordPress depuis /comptes demande désormais son adresse, un nom d'utilisateur et un mot de passe d'application, puis vérifie ces identifiants auprès du site avant de les enregistrer — un mot de passe erroné, un site injoignable ou une API REST absente sont signalés en français clair, pas par une erreur générique. Une fois connecté, la publication envoie d'abord le média, puis crée l'article en le rattachant, en découpant le texte en paragraphes aux lignes vides ; un média trop volumineux est refusé avec un message explicite plutôt qu'un envoi qui échoue.
L'accès Instagram est désormais renouvelé automatiquement par le planificateur, bien avant que l'accès en cours ne s'épuise — aucune action requise tant que le renouvellement réussit.
/comptes affiche désormais « Expire dans X jours » sur chaque compte qui a encore une échéance, avec un avertissement ambré en dessous de 7 jours restants. Un compte réellement expiré affiche une action « Reconnecter » bien visible, accompagnée d'un texte clair — et pour LinkedIn, un rappel que se reconnecter tous les 60 jours environ est normal, pas le signe d'une panne.
Social Hub publie désormais une politique de confidentialité et des conditions d'utilisation, consultables sans être connecté. Elles précisent ce que l'application stocke, ce qu'elle ne fait jamais des données des plateformes, et comment en demander la suppression — ce sont aussi les adresses fournies à LinkedIn et Meta lors de l'enregistrement de l'application.
Une page publique détaillant les données collectées (identifiants de comptes, jetons OAuth, contenus des posts, résultats de publication et statistiques), les finalités, les durées de conservation, les destinataires, ainsi que l'engagement explicite de ne jamais vendre de données ni entraîner de modèles d'IA sur les données issues des API des plateformes. Sa section « Suppression des données » décrit la marche à suivre — déconnecter un compte efface ses jetons immédiatement, et une suppression complète peut être demandée à [email protected].
Une page publique précisant qui peut accéder à Social Hub, la responsabilité attachée à la connexion d'un compte social, l'obligation de respecter les règles propres à chaque plateforme, et les limites du service — aucun engagement de niveau de service, et une publication tributaire d'API tierces.
Les liens « Confidentialité » et « Conditions » du pied de page du changelog pointaient vers /privacy et /terms, deux routes qui n'ont jamais existé dans cette application. Ils renvoient désormais vers les vraies pages.
Une plateforme dont les identifiants OAuth sont absents sur ce serveur affiche désormais un état sobre « Non configuré » sur /comptes, au lieu d'un bouton mort ou d'une erreur. Et quand une tentative de connexion échoue ou expire, la raison (refus du fournisseur, lien expiré, réponse incomplète…) s'affiche maintenant dans un bandeau lisible en haut de la page plutôt que dans une erreur de redirection brute.
Un post peut désormais indiquer que son texte a été rédigé par une IA. Il porte alors une pastille « IA » discrète partout où les posts sont listés — composer, file d'attente, approbations et calendrier — et il ne peut pas être planifié directement : le seul chemin vers une publication programmée passe par « Soumettre à validation », puis l'approbation d'une personne. Cela vaut pour tous les rôles, approbateurs compris, et s'applique même si l'entreprise a désactivé les validations partout. L'origine du contenu est enregistrée une fois, à la création, et n'est plus modifiable ensuite — dupliquer un post IA produit un autre post IA.
Une version purement liée au déploiement : Social Hub s'appuie désormais sur une base de données PostgreSQL auto-hébergée plutôt qu'un fournisseur externe. Aucun changement visible côté utilisateur.
Un changement d'infrastructure sans effet sur l'apparence ou le comportement de Social Hub pour ses utilisateurs.
Le calendrier gagne une vue Liste en plus de Semaine et Mois, une bascule « Meilleurs créneaux », un compteur de posts par jour et un raccourci « Planifier » au survol. Le composer adapte désormais ses actions au statut réel du post (brouillon, planifié, en attente, publié) et permet de repasser un post planifié en brouillon. Corrigés au passage : la barre latérale qui pouvait disparaître en SSO réel, et les miniatures média cassées — et Social Hub apparaît maintenant dans le lanceur Hub et la console plateforme.
Une nouvelle vue Liste rejoint Semaine et Mois. Une bascule « Meilleurs créneaux » met en évidence les créneaux suggérés, chaque jour affiche un badge de compteur, et survoler un créneau libre fait apparaître un raccourci « + Planifier ». La replanification par glisser-déposer est conservée.
Le composer affiche désormais une bannière de statut et verrouille les champs une fois le post sorti du brouillon (planifié, en attente d'approbation ou publié). Une nouvelle action « Repasser en brouillon » dé-planifie un post ; la date se choisit maintenant via le datepicker calendrier et un sélecteur d'heure par créneaux, les messages d'erreur et avertissements sont mieux positionnés, une planification passée ou incomplète est bloquée avant envoi, et vous êtes redirigé vers le calendrier une fois le post planifié.
La barre latérale (logo, menu Hub et liste Actions) pouvait disparaître entièrement une fois connecté via le SSO réel. Corrigé.
Une miniature qui ne se charge pas affiche désormais un aperçu de repli propre, au lieu de l'icône d'image cassée du navigateur.
Social Hub apparaît désormais avec son icône et son nom dans le lanceur Hub inter-applications et dans la console plateforme.
LinkedIn, Facebook et Instagram passent de la simulation à un véritable chemin de publication, prêt à être activé ; les autres plateformes continuent de tourner en simulation complète ou en flux manuel assisté. Cette version ajoute aussi les pages publiques Changelog et Documentation que vous consultez actuellement.
La publication automatique sur LinkedIn, Facebook et Instagram est prête à être activée — plus de copier-coller sur ces trois plateformes une fois l'activation faite. Les cinq autres continuent de tourner contre la simulation complète ou le flux manuel assisté, sans migration nécessaire le jour où elles seront branchées à leur tour.
Une page /changelog liste chaque version en langage clair, et une page /docs explique comment utiliser Social Hub de bout en bout — toutes deux accessibles depuis le pied de la barre latérale.
Première version de Social Hub : un composer qui adapte un même post à huit plateformes, un calendrier et une file d'attente pour le planifier et le suivre, une étape d'approbation optionnelle, et un flux manuel assisté (installable en PWA) pour les plateformes qui n'en ont pas. À ce stade, la publication elle-même tournait contre une simulation complète sur les huit plateformes.
Rédigez une fois, ciblez n'importe quelle combinaison de comptes connectés parmi Facebook, Instagram, LinkedIn, X, Threads, TikTok, WordPress et le blog SiteHub — puis personnalisez le texte, le média ou le titre par plateforme quand ses contraintes (limite de caractères, format d'image, titre requis) l'exigent.
Un calendrier semaine/mois affiche chaque post planifié avec replanification par glisser-déposer, et la file d'attente liste ce qui est à venir, publié ou en échec — avec relance, duplication et replanification en un clic.
Les comptes peuvent être configurés pour exiger une approbation avant publication ; les approbateurs disposent d'une file dédiée avec aperçu par cible, approbation en un clic et note obligatoire au refus.
Pour X, Threads, TikTok et WordPress, /actions vous guide dans le geste manuel irréductible — copier la légende, partager ou télécharger le média, ouvrir la plateforme — puis confirmer la publication ou la signaler en échec. Installable en PWA pour un usage mobile.
Connectez plusieurs comptes par plateforme (par ex. deux pages LinkedIn), visualisez leur statut en un coup d'œil et reconnectez-les en un clic en cas d'expiration.