proposition-technique

Proposition technique : plateforme IA de génération de contenus SEO (V1)

1. Compréhension du besoin

Le projet est une plateforme SaaS B2B multi-tenant pour la gestion éditoriale automatisée. Les clients cibles sont trois types de structures différentes avec des besoins distincts :

La plateforme doit couvrir le cycle éditorial complet :

  1. Définir la stratégie (mots-clés, intention de recherche, secteur, tone of voice)
  2. Analyser les SERP pour comprendre ce que Google et les concurrents mettent en avant
  3. Générer un brief SEO structuré (plan H1-H6, angle, questions FAQ, intention)
  4. Générer le contenu final (texte optimisé SEO, H1-H6, body)
  5. Valider le contenu (humain en boucle, export ou copier-coller)
  6. Suivre les performances (Search Console, évolutions de positionnement)

L’axe d’optimisation est le SEO classique (Google) : ranking dans les résultats de recherche, structuration du balisage HTML.

2. Stack technique et pourquoi ces choix

Stack retenue :

Pourquoi TypeScript et pas Python ou JavaScript brut :

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

Pourquoi Node.js côté backend :

Pourquoi Next.js côté frontend :

Pourquoi GPT-4o ET Claude Sonnet pour la rédaction SEO :

Les deux modèles sont pertinents pour ce cas d’usage, pour des raisons différentes :

Recommandation : démarrer avec GPT-4o par défaut, exposer le paramètre de modèle en config pour basculer sur Claude Sonnet par client ou par type de contenu. L’architecture permet de switcher sans refacto (un paramètre de config par tenant).

Pourquoi pgvector et les embeddings (justifié ici, contrairement à d’autres cas) :

Dans ce système, chaque client accumule un corpus de contenus publiés qui grossit dans le temps. Les embeddings deviennent pertinents pour deux besoins concrets :

  1. Déduplication : détecter si un sujet a déjà été traité avant de générer un nouveau contenu (recherche par similarité sémantique, pas par mots-clés exacts)
  2. Clustering thématique : grouper les sujets pour planifier les maillages internes et détecter les lacunes de couverture

Un e-commerçant avec 300 fiches catégories a besoin de ces deux fonctions. Une agence qui gère 20 clients avec 50 articles chacun aussi. Le volume et la nature du corpus justifient les embeddings ici.

Modèle utilisé : OpenAI text-embedding-3-small (~0.02 EUR/1M tokens, coût négligeable).

3. Ce que la plateforme fait

3.1 SEO Google

Ce que le système optimise :

Ce que le système ne peut PAS garantir et que je ne promets pas :

Le ranking Google dépend de plusieurs centaines de signaux dont une bonne partie est hors contrôle : autorité de domaine, backlinks, Core Web Vitals, historique du site, comportement utilisateur (CTR, temps sur page). On ne peut pas promettre de position.

Ce qu’on peut promettre : produire un contenu structurellement optimisé qui maximise les chances de ranking. C’est nécessaire mais pas suffisant.

Google Indexing API :

Google Search Console API :

Sorties du système :

3.2 Analyse SERP (optionnel)

Intégration optionnelle d’un provider de données SERP pour enrichir l’analyse concurrentielle : top 10 résultats, SERP features (featured snippets, PAA), volume de mots-clés.

Le choix exact du provider, du budget et de la profondeur d’analyse se définit au kickoff selon les besoins du client. L’impact sur le coût par contenu est variable et sera chiffré selon le volume à ce moment-là.

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

Mon expérience concrète sur le sujet :

J’ai développé pour mon propre usage un assistant IA (Cortex) qui intègre un système de mémoire avancé en production depuis plusieurs mois. Ce système gère des mémoires éphémères (tâches en cours, bloqueurs), des mémoires long terme (préférences, décisions passées), un système de “digestion” qui extrait automatiquement des mémoires à partir des interactions, et des tickets (actions recommandées par l’IA). C’est cette expertise concrète que j’applique ici, adaptée au use case éditorial.

Pour ce projet, version adaptée :

Chaque client 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, 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” = 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 les embeddings sont justifiés ici :

Contrairement à un système avec 10-50 mémoires par client, ici chaque client accumule un corpus de contenus publiés qui grossit. Un client avec 200 articles a besoin d’une recherche sémantique pour détecter la redondance, pas d’une injection brute de 200 titres dans le prompt. On utilise pgvector pour indexer les titres + résumés des contenus existants, et on fait une recherche de similarité avant chaque nouvelle génération.

5. Pipeline de traitement des données

[Brief utilisateur]
    │
    ├── Mots-clés cibles
    ├── URLs concurrents (optionnel)
    ├── Intention de recherche (informationnelle / transactionnelle / navigationnelle)
    ├── Ton de marque + règles éditoriales (depuis mémoire client)
    │
    ▼
[Analyse SERP]
    │ → Provider SERP (si activé) : top 10 résultats + SERP features (PAA, featured snippets)
    │ → Extraction : angle dominant, longueur médiane, questions récurrentes
    │ → Analyse concurrents : structure H1-H6, sujets couverts
    │
    ▼
[Génération brief SEO]
    │ → Plan structuré : H1 + H2-H6 + sections recommandées
    │ → Questions FAQ identifiées depuis PAA Google + People Also Ask
    │ → Mots-clés sémantiques à intégrer (NLP depuis SERP)
    │ → Angle recommandé + intention primaire
    │ → Vérification anti-redondance via embeddings (corpus existant du client)
    │ → Schéma Zod validé avant de passer à l'étape suivante
    │
    ▼
[Génération contenu]
    │ → Corps de l'article (GPT-4o ou Claude Sonnet selon config client)
    │ → Intégration mémoire client (ton, glossaire, règles éditoriales)
    │ → Structure : réponses directes, FAQ, H1-H6 optimisés
    │ → Génération automatique : title, meta description, alt text images
    │ → Schema.org JSON-LD (Article, FAQPage selon le type)
    │ → Output validé par schéma Zod
    │
    ▼
[Validation client]
    │ → File d'attente : statut "en attente de validation"
    │ → Éditeur inline avec aperçu
    │ → Approuver / modifier / rejeter (avec commentaire)
    │ → Feedback → extraction règle implicite → mémoire
    │ → Export HTML ou Markdown (copier-coller ou téléchargement)
    │
    ▼
[Suivi performance]
    │ → Search Console : clicks, impressions, position par URL et mot-clé
    │ → Dashboard client : évolution positionnement, contenus produits, articles consommés

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

  1. File de validation : chaque contenu généré arrive avec statut “en attente de validation”
  2. Éditeur inline : modification directe dans l’interface, avec prévisualisation du rendu HTML/markdown
  3. Actions disponibles : approuver (débloque l’export), modifier, rejeter avec commentaire
  4. Feedback → mémoire : chaque modification du client est analysée pour extraire une règle implicite (ex: remplacé “dynamique” par “efficace” → le client préfère le vocabulaire concret)
  5. Validation par lot : pour les agences qui valident plusieurs contenus d’un coup

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

8. 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 Architecture BDD + auth (schema PostgreSQL + pgvector, multi-tenancy, onboarding) 3j
2 UI/UX (parcours client, composants, dashboard) 3j
3 Module génération SEO (pipeline IA : analyse SERP → brief → contenu, schema.org, FAQ) 5 – 10j
4 Système de mémoire + planning éditorial (déduplication, suggestions de sujets, calendrier) 3 – 5j
5 Module facturation Stripe (abonnements, usage-based articles, portail client) 3j
6 Module analytics (dashboard performances) 3j
7 Tests, optimisations, mise en production 3j
Total 10 à 30 jours