proposition-technique

Proposition technique : système d’orchestration marketing IA (V1)

1. Compréhension du besoin

Le systeme est un module intégrable à un ERP B2B existant (~100 clients, scalable à 1000+). Chaque entreprise cliente pourra, depuis l’ERP :

2. Stack technique et pourquoi ces choix

Stack retenue :

Pourquoi TypeScript et pas du Python ou du JavaScript brut :

Le coeur du système repose sur de l’IA générative, qui par nature est probabiliste et non déterministe. Le risque principal d’un tel système c’est de perdre le contrôle sur ce que le LLM produit. TypeScript avec son typage strict permet d’encadrer ça :

En gros : TypeScript permet de calculer et contrôler l’arbitraire du LLM, pas de faire du 100% créatif. Le LLM génère, le code valide et encadre.

Pourquoi Node.js côté backend :

Pourquoi Next.js côté frontend :

Pourquoi GPT-4o pour la rédaction :

Pourquoi Whisper pour le speech-to-text :

3. Canaux de diffusion : ce qu’on peut faire, ce qu’on peut pas, et pourquoi

3.1 Facebook (pages)

Ce que je peux automatiser via l’API officielle (Graph API) :

Ce qu’on ne peut PAS faire :

Contournement possible (hors MVP) : Pour les groupes et profils personnels, il existe une approche via agent IA avec navigateur automatisé (Puppeteer/Playwright). L’agent se connecte au compte du client et publie comme un humain. C’est lent (~30s par publication), il y a un risque de ban si mal calibré, et ça coûte plus cher en serveur. Je recommande de ne pas l’inclure en V1 mais c’est techniquement faisable comme évolution.

Prérequis : l’app Meta doit passer une business verification (2-5 jours) pour obtenir les permissions pages_manage_posts et pages_read_engagement.

3.2 Instagram

Ce que je peux automatiser via l’API officielle (Instagram Graph API) :

Ce qu’on ne peut PAS faire :

Impact pour le système : avec 100 clients qui publient 1-3 contenus/jour, on est très loin de la limite de 25. Aucun risque de saturation. Le rate limit des appels API en général (200/h/utilisateur) est partagé entre lecture et écriture, à monitorer mais pas bloquant.

3.3 LinkedIn

Ce que je peux automatiser via l’API officielle (Community Management API v2) :

Ce qu’on ne peut PAS faire :

Point critique : tokens expirants. Le token d’accès LinkedIn expire en 60 jours. Le refresh token dure 365 jours. Passé ce délai, le client doit se ré-authentifier manuellement. Le systeme doit gérer ça proprement : un cron vérifie chaque semaine les tokens proches de l’expiration et notifie le client avant qu’il soit trop tard.

Rate limits : 150 appels/jour/organisation, 100/jour/membre. Largement suffisant.

3.4 X (Twitter)

Ce que je peux automatiser via l’API v2 :

Ce qu’on ne peut PAS faire :

Point d’attention majeur : le coût. X a le modèle API le plus cher de tous les canaux, et de loin :

Plan Prix Limite publication
Free 0$ 1 post/jour (inutilisable)
Basic 200$/mois 50 tweets/app/24h
Pro 5000$/mois 300 000 posts/mois

Pour un MVP avec 100 clients, le plan Basic à 200$/mois est le minimum. C’est 50 tweets/jour partagés entre tous les clients de la plateforme, soit en moyenne 0.5 tweet/jour/client. Si chaque client publie 1 tweet/jour, il faut passer au Pro à 5000$/mois.

Impact sur le business model : le coût X API est le poste le plus élevé des coûts opérationnels. Il faut soit le refacturer directement aux clients qui utilisent le canal X, soit le budgéter dans l’abonnement global. C’est une décision business à prendre tôt.

3.5 TikTok

Ce que je peux automatiser via l’API (Content Posting API) :

Ce qu’on ne peut PAS faire :

Deux contraintes importantes :

  1. Direct Post limité à 3 vidéos/jour/utilisateur (limite dure, non négociable)
  2. Direct Post nécessite que le compte ait >1000 followers (enforcement depuis Q3 2025). Pour les clients qui démarrent sur TikTok, seul le mode Upload to Inbox est disponible

Recommandation V1 : mode Upload to Inbox par défaut. C’est la solution la plus robuste car elle ne dépend pas du nombre de followers et laisse le client valider dans son app. Direct Post activable en option pour les clients éligibles.

Délai d’accès : l’app doit être approuvée par TikTok (review de 2 à 8 semaines). C’est le canal avec le plus long délai de setup.

3.6 SMS

Trois approches possibles :

Option A : numéro du client (son propre numéro)

Option B : numéro mutualisé via provider (recommandé MVP)

Option C (évolution) : un numéro par client

Réglementation SMS en France (non négociable) :

4. Système de mémoire et personnalisation IA

Mon expérience concrète sur le sujet :

J’ai developpé pour mon propre usage un assistant IA (Cortex) qui intègre un système de mémoire avancé en production. Ce truc gère :

Ce système tourne en production depuis plusieurs mois sur mon propre workflow quotidien. C’est cette expertise concrète que j’applique ici, en version simplifiée et adaptée au use case marketing.

Pour ce projet, version adaptée :

Chaque client final dispose d’un conteneur de mémoire isolé contenant :

Comment ça apprend :

  1. Le client génère un contenu
  2. Il le valide tel quel, ou le modifie, ou le rejette avec un commentaire
  3. Le système extrait la règle implicite (ex: le client a remplacé “booster” par “développer”, il préfère le vocabulaire non anglicisé)
  4. Cette règle est stockée dans sa mémoire permanente
  5. Les prochaines générations intègrent cette règle dans le prompt

Pourquoi PAS d’embeddings en V1 :

Le cahier des charges mentionne les embeddings (recherche vectorielle). Je challenge ce choix. Les embeddings sont pertinents quand on a un large corpus de documents à retrouver par similarité sémantique (des milliers de pages, une base de connaissances volumineuse). Ici, chaque client a :

Ce volume est parfaitement gérable en injection directe dans le prompt du LLM. On sélectionne les mémoires pertinentes et on les injecte dans le contexte. Ajouter un système d’embeddings aurait pour conséquences :

Mon approche : injection directe des mémoires pertinentes dans le prompt. Simple, rapide, fiable. Si un client atteint un volume qui dépasse la fenêtre de contexte du LLM (très improbable en V1 vu les volumes par client), on passera aux embeddings à ce moment-là. Mais pas avant.

5. Ce que je challenge dans le cahier des charges

5.1 Redis / BullMQ : validé

Redis + BullMQ est le bon choix pour la queue de jobs :

5.2 N8N : pas nécessaire ici

N8N est un outil d’automatisation no-code/low-code qui permet de connecter des API entre elles via une interface visuelle. C’est un outil que je connais et que j’utilise, il est excellent dans son domaine.

Quand N8N est utile : quand on connecte des API tierces dont on n’a pas la main sur le code. N8N fournit des connecteurs préfaits qui évitent de recoder l’intégation. Par exemple, connecter un CRM à un outil de mailing à un tableur. C’est fait pour ça.

Pourquoi pas ici : je développe tout le système. Chaque intégration (Facebook API, LinkedIn API, Twilio, etc.) est codée directement dans le backend en TypeScript. Passer par N8N ajouterait une couche intermédiaire inutile, un service supplémentaire à maintenir, et une dépendance à un outil tiers pour des choses que je maîtrise mieux en code natif.

Si plus tard, les clients finaux souhaitent connecter l’orchestrateur à des outils spécifiques (leur CRM, leur outil de mailing, etc.), N8N peut devenir pertinent comme pont d’intégration entre le système et ces outils tiers. Mais pour le MVP, c’est superflu et ça ajoute de la complexité sans valeur.

5.3 Embeddings : pas justifié en V1

(Détaillé en section 4)

6. Pipeline de traitement des données

[Entrée utilisateur]
    │
    ├── Texte libre (brief, instructions)
    ├── Audio (speech-to-text via Whisper)
    ├── Documents (PDF, images → extraction texte)
    ├── URLs (scraping du contenu)
    │
    ▼
[Normalisation]
    │ → Texte structuré unifié (validé par schéma Zod)
    │ → Extraction entités (sujets, tons, formats demandés)
    │ → Enrichissement via mémoire client
    │
    ▼
[Génération plan de contenu]
    │ → Calendrier éditorial proposé (30 jours)
    │ → Sujets + angles + formats par canal
    │ → Respect des contraintes (fréquence, horaires, quotas API)
    │
    ▼
[Génération contenu]
    │ → Un contenu source (le "master")
    │ → Adaptation par canal (format, longueur, ton, hashtags)
    │ → Intégration des préférences mémoire
    │ → Output validé par schéma Zod (structure garantie)
    │
    ▼
[Validation]
    │ → File d'attente de validation client
    │ → Actions : approuver / modifier / rejeter
    │ → Feedback → mémoire (boucle d'apprentissage)
    │
    ▼
[Publication]
    │ → Job BullMQ schedulé au bon moment
    │ → Publication via API du canal
    │ → Gestion des erreurs et retry automatique
    │ → Log du résultat
    │
    ▼
[Suivi performance]
    │ → Collecte métriques (reach, engagement, clics)
    │ → Dashboard simplifié

7. Hébergement : analyse comparative

7.1 IONOS VPS

Critère Évaluation
Prix VPS Linux M : ~9 EUR/mois (2 vCPU, 4GB RAM). VPS Linux L : ~15 EUR/mois (4 vCPU, 8GB)
Bande passante Illimitée (incluse)
Scalabilité Verticale (upgrade de plan) + possibilité d’ajouter des serveurs
Datacenters EU (Allemagne, France, Espagne, UK). Certifiés ISO 27001
Maturité United Internet AG, fondé en 1988, coté en bourse. 38 ans d’existence
SLA Inclus de base
RGPD Conforme, données en EU
Risque faillite Quasi nul (groupe coté, profitable)

Avantage clé : bande passante illimitée et SLA inclus de base. Pas de surprise sur la facture.

7.2 Hetzner Cloud

Critère Évaluation
Prix CPX22 : ~8 EUR/mois (2 vCPU, 4GB RAM). CPX32 : ~15 EUR/mois (4 vCPU, 8GB)
Bande passante 20 TB inclus (largement suffisant)
Scalabilité Même principe, upgrade ou ajout serveurs
Datacenters EU (Allemagne, Finlande) + US (Ashburn)
Maturité Fondé en 1997, 29 ans d’existence. Entreprise allemande, profitable
SLA Pas de SLA formel
RGPD Conforme, données en EU
Risque faillite Quasi nul

Avantage clé : le prix le plus bas du marché pour les performances offertes. Très populaire dans la communauté dev. Par contre, pas de SLA formel, ce qui peut être un point de discussion si on a besoin de garanties contractuelles.

7.3 Fly.io (mentionné par l’autre développeur)

Critère Évaluation
Prix ~14-28$/mois pour une config équivalente, + bande passante facturée à 0.02$/GB
Scalabilité Multi-région automatique
Maturité Fondé en 2017, startup VC-funded (~115M$ levés, valorisée 397M$). ~60 personnes. Pas profitable confirmé
Fiabilité 565 incidents tracés depuis juin 2022. Temps moyen de résolution : ~5h. En avril 2026 : problèmes TLS (17/04), panne réseau de 24h (15/04), latence élevée (12/04), instabilité Postgres (10/04)
SLA Pas inclus. Disponible avec support payant (29$/mois minimum)
RGPD Régions EU disponibles mais pas de garantie de résidence exclusive des données

Mon analyse : Fly.io est une plateforme intéressante pour des apps temps réel distribuées mondialement (jeux, chat, collaboration). C’est son use case idéal. Pour un système de batch marketing avec des publications planifiées et des utilisateurs concentrés en France/Europe, c’est surdimensionné et mal adapté.

Les vrais problèmes :

7.4 AWS (EC2 + RDS + ElastiCache)

Critère Évaluation
Prix 150-400 EUR/mois pour une charge équivalente
Scalabilité Illimitée (auto-scaling natif)
Maturité Amazon, leader mondial depuis 2006

Verdict : surdimensionné pour la V1. L’auto-scaling AWS se justifie quand la charge est imprévisible et massive. Ici, la charge est prévisible (publications planifiées = batch). La complexité de configuration AWS et le coût ne se justifient pas avant 10 000+ utilisateurs.

7.5 Recommandation

Pour le MVP (0-100 utilisateurs) : IONOS VPS Linux M ou Hetzner CPX22. Budget à prévoir : ~40 EUR/mois (serveur + Redis + backups + marge). Tout tient sur un seul serveur.

Pour le scale (100-1000 utilisateurs) : VPS plus puissant (4-8 vCPU, 8-16GB RAM). Budget : ~60-120 EUR/mois. La charge reste modeste : 1000 utilisateurs qui publient 3 contenus/jour = 3000 jobs/jour = ~2 jobs/minute. Un seul serveur gère ça sans effort.

Pour le futur (1000+) : réévaluer. Potentiellement séparer workers et API sur deux serveurs. Toujours pas besoin d’AWS ou Fly.io à cette echelle.

Je recommande IONOS pour la bande passante illimitée et le SLA inclus. Si le prix est le facteur décisif, Hetzner est environ 10% moins cher mais sans SLA formel.

8. Modèle de coûts et refacturation

8.1 Coûts opérationnels estimés par utilisateur actif

Estimation basée sur un client qui génère 30 contenus/mois, publie sur 3 canaux, envoie 50 SMS/mois :

Poste Coût/mois/utilisateur (base 100 users)
Hébergement (mutualisé) ~0.40 EUR
IA génération contenu (GPT-4o, ~5000 tokens/contenu, 30 contenus) ~1.50 EUR
IA speech-to-text (Whisper, ~10 min audio/mois) ~0.06 EUR
SMS (50 SMS à ~0.07 EUR) ~3.50 EUR
X/Twitter API (quote-part du Basic 200$/mois) ~1.80 EUR
Redis (mutualisé) ~0.05 EUR
Total coût brut ~7.30 EUR

Note : le poste X/Twitter est le plus cher proportionnellement. Si certains clients n’utilisent pas X, leur coût brut tombe à ~5.50 EUR/mois.

8.2 Modèles de facturation possibles

Option A : abonnement fixe par paliers (recommandé pour le MVP)

Avantage : prévisible pour le client, marge confortable (x6-7 sur le coût brut). Simple à comprendre et à vendre.

Option B : pay as you go

Avantage : pas de barrière à l’entrée. Inconvénient : revenus imprévisibles, difficile à budgéter pour le client.

Recommandation : option A pour le MVP. Un dashboard qui montre la consommation en temps réel permet de préparer une migration vers un modèle hybride si besoin.

9. Système de validation et contrôle qualité

  1. File de validation : chaque contenu généré arrive dans une file d’attente avec statut “en attente”
  2. Actions possibles : approuver (publie au moment programmé), modifier (éditeur inline), rejeter (avec commentaire qui alimente la mémoire)
  3. Validation par lot : possibilité d’approuver plusieurs contenus d’un coup
  4. Auto-publication (optionnel) : un client peut activer la publication automatique après N contenus validés consécutifs (confiance acquise). Désactivable à tout moment

10. Sécurité et isolation des données

11. Planning prévisionnel

Le développement se fait intégralement en local. La mise en production intervient en dernière phase.

Phase Contenu Durée estimée
1 UI/UX client (intégration Figma, parcours utilisateur, composants) 1-1.5 semaine
2 Architecture BDD (schema PostgreSQL, multi-tenancy, migrations) 0.5 semaine
3 Module génération & planification de contenu (pipeline IA, plan éditorial, batch processing) 1-1.5 semaine
4 Module diffusion (intégation canal par canal : Facebook, Instagram, LinkedIn, X, TikTok, SMS) 1-1.5 semaine
5 Module mémoire & feedbacks (conteneurisation par client, boucle d’apprentissage) 0.5-1 semaine
6 Module analytics (collecte métriques, dashboard simplifié) 0.5 semaine
7 Tests, optimisations, documentation 0.5 semaine
8 Formation 0.5 semaine
9 Mise en production 0.5 semaine
Total 5-7 semaines