Générer des posts LinkedIn avec l’IA pour des commerciaux multi-secteurs

Nos commerciaux couvrent chacun plusieurs secteurs, avec des cibles différentes (DSI, marketing, direction générale). J’ai construit un pipeline n8n qui leur génère chaque semaine une base de posts LinkedIn à retoucher, classés par secteur et par cible. La vraie difficulté n’était pas de brancher un LLM sur un prompt.

Le problème

Un post pertinent pour un DSI de mutuelle n’a rien à voir avec un post pour la direction marketing d’un éditeur logiciel. Personne n’a le temps de personnaliser à ce rythme en plus de la prospection, donc les posts passent à la trappe ou se limitent à des partages génériques.

L’objectif : partir de ce qu’on sait déjà (secteur et cible de chaque commercial, documentation produit) et produire une matière première qualifiée, pas un post final publiable tel quel.

Ce que j’ai construit

Tout tourne dans n8n :

• deuxData Tables natives : commercial_secteurs (~110 lignes : commercial, secteur, cible, taille d’entreprise, références clients, arguments produit) et produit_faits (~50 faits courts) ;
• unagent IA (nœud LangChain Agent) branché sur OpenRouter, avec sortie structurée forcée ;
• un nœudCode qui regroupe les posts par commercial et génère une page .html ;
• SharePoint pour héberger le fichier, Teams pour envoyer le lien en message privé.

flowchart TD
    A["Trigger hebdomadaire\nlundi 7h"] --> B["Data Tables\nfaits produit + commercial x secteur x cible"]
    B --> D{"Boucle\n1 ligne a la fois"}
    D -->|pour chaque ligne| E["Agent IA\nOpenRouter + sortie structuree"]
    E --> D
    D -->|boucle terminee| G["Regroupement par commercial\n+ fichier .html"]
    G --> I["Upload SharePoint"]
    I --> J{"Switch : quel commercial ?"}
    J --> K["Teams 1:1 par commercial"]

Trois choix comptent :

• Garder la granularité des données. Le fichier de profils commerciaux existait déjà pour le sourcing de prospects. Un même secteur y apparaît plusieurs fois selon que la cible soit IT ou marketing. J’ai résisté au réflexe de dédupliquer : ce sont des discours différents.
• Une base de faits produit comme garde-fou. J’ai extrait de la documentation une cinquantaine de faits vérifiables, injectés dans le prompt système, pour que le modèle ne brode pas sur des fonctionnalités inventées.
• Une sortie structurée plutôt que du texte libre. L’agent renvoie directement { "posts": [...] } avec 3 propositions (preuve sociale, insight sectoriel, actualité produit). Parser du texte libre pour en extraire 3 posts est fragile ; forcer un schéma JSON supprime cette classe de bugs.

Côté diffusion, certains commerciaux couvrent plus de 30 combinaisons secteur/cible : un message Teams qui listerait tout serait illisible. Le fichier va sur SharePoint, seul le lien part sur Teams, via un Switch qui route vers un nœud Teams dédié par commercial (le même pattern que mes rappels de tâches quotidiens).

Ce qui a cassé

Le champ qui disparaît après un appel API

Règle générale : un nœud qui appelle une API externe remplace les données de l’item, il ne les enrichit pas. Le correctif consiste à référencer explicitement le nœud précédent qui portait encore la valeur.

Le ton de prospection déguisée

Les premiers posts se terminaient tous par « vous voulez que je vous montre un exemple adapté à votre catalogue ? ». Corrects, mais on aurait dit un message privé à un prospect, pas un post public. La cause était dans mon prompt : il demandait une « invitation à échanger en message privé » en fin de post.

Correctif dans le prompt système : écrire à la première personne comme un vrai post (retour d’expérience, opinion), ne jamais vouvoyer un interlocuteur précis, bannir les formules de démarchage, et finir soit par une question ouverte au réseau, soit par une observation forte.

Le coût du modèle

Premier test sur un modèle « flagship » : environ 0,037 $ par appel, sur une centaine de lignes chaque semaine. Pour du copywriting court, c’était disproportionné. Un modèle nettement plus léger du même fournisseur donne une qualité perçue équivalente pour un coût divisé par plusieurs.

Limites

Pas de boucle de feedback sur les posts générés, pas de mémoire de ce qui a déjà été proposé (risque de répétition), et le gain de temps dépend entièrement de l’adoption par les commerciaux, puisque la relecture humaine reste obligatoire. Le pipeline tourne pour l’instant sur deux commerciaux en test.

À retenir

La partie IA n’a pas été la plus longue. Le temps est passé à structurer les données en amont, puis à corriger dans le prompt un biais que je n’avais pas anticipé : un ton de prospection dans un contenu censé être public.

Sur le même principe de sortie forcée, voir aussi Automatiser une variable grammaticale avec une IA.