Comment automatiser la rédaction de rapports SEO mensuels avec un MOE local ?

ID Interactive, agence digitale basée à Vannes, produit chaque mois des rapports de positionnement Google pour ses nombreux clients. Ces rapports, basés sur les exports Semrush, sont un livrable essentiel : ils montrent l'évolution des positions sur les mots-clés stratégiques, expliquent les progressions, alertent sur les reculs, et orientent les actions du mois suivant.

Pendant longtemps, chaque rapport a été rédigé manuellement. Pour un client, cela représentait environ 30 minutes d'analyse et de rédaction par mois. À l'échelle de l'ensemble du portefeuille clients sur 12 mois, la charge cumulée représentait plusieurs centaines d'heures annuelles consacrées à une tâche répétitive et à faible valeur ajoutée intellectuelle.

Avec l'arrivée des modèles de langage locaux capables de tourner sur notre propre infrastructure, la question s'est imposée : peut-on automatiser cette rédaction sans compromettre la qualité ni faire sortir les données de nos clients ? Ce retour d'expérience raconte les trois semaines d'itérations qui nous ont conduits à un workflow stable et validé, désormais en production sur l'ensemble de nos comptes.

L'infrastructure IA de l'agence

Pourquoi le local plutôt que le cloud

Une infrastructure IA locale est préférable au cloud pour les agences traitant des données client sensibles pour deux raisons déterminantes : la confidentialité (les données ne quittent jamais les serveurs de l'agence) et le coût marginal quasi nul par requête une fois l'infrastructure amortie, contre des centaines d'euros mensuels en tokens pour un volume de production comparable.

Le cœur matériel : la DGX Spark

Nous avons investi dans une NVIDIA DGX Spark.

La NVIDIA DGX Spark est une station de travail IA compacte lancée en 2025, conçue pour l'inférence de grands modèles de langage en environnement local. Elle intègre le SoC Grace Blackwell GB10 d'NVIDIA et propose 128 Go de mémoire unifiée partagée entre CPU et GPU, ce qui la distingue des configurations GPU classiques où la VRAM est limitée à 24 ou 32 Go.

Pour nos usages (rédaction, analyse de documents, génération de contenu long), c'est la configuration qui offre le meilleur rapport capacité/encombrement du marché en 2026.

La couche logicielle : Ollama + OpenWebUI

Ollama est un moteur d'inférence open source, disponible sous licence MIT, qui permet de faire tourner des grands modèles de langage (LLM) localement sur Mac, Linux et Windows. Il gère le téléchargement, la quantification et l'exposition d'une API compatible OpenAI sur localhost:11434.' Une commande suffit pour installer un nouveau modèle : ollama pull qwen3:32b.

OpenWebUI est l'interface web qui habille Ollama. Elle offre une expérience comparable à ChatGPT : conversations organisées par dossier, prompts système par modèle, upload de documents, et, surtout pour nous, un système de fonctions Python appelables depuis le chat, qui a été déterminant pour notre workflow final.

Le choix du modèle

Nous avons testé plusieurs candidats : Mistral Small 3.1 (24B), GPT OSS 20B, Qwen3-30B-A3B (MoE) et Qwen3-32B dense. Les trois premiers ont montré leurs limites sur cette tâche précise. Le modèle qui a fini par s'imposer est Qwen3-32B dense, pour une raison structurelle : ses 32 milliards de paramètres sont tous activés à chaque token, contrairement aux modèles MoE (Mixture of Experts) qui n'en activent qu'une fraction. Cette différence est cruciale pour les tâches de comptage conditionnel, omniprésentes dans un rapport SEO (« combien d'expressions en Top 3 à fort volume ? »).

Qwen3:30B-A3B est un modèle d’intelligence artificielle open source développé par Alibaba Cloud. Il appartient à la troisième génération des modèles Qwen et utilise une architecture Mixture of Experts (MoE). Le modèle possède environ 30 milliards de paramètres, mais seulement 3 milliards sont activés lors de chaque requête, ce qui améliore fortement l’efficacité et réduit les besoins matériels. Qwen3:30B-A3B est particulièrement adapté au raisonnement, à la génération de code, aux assistants IA et aux tâches multilingues. Il peut fonctionner localement avec des outils comme Ollama, vLLM, LM Studio ou Hugging Face sur des configurations GPU modernes.

Le terme MoE signifie Mixture of Experts (« mélange d’experts »). Il s’agit d’une architecture utilisée dans certains modèles d’intelligence artificielle pour améliorer les performances tout en réduisant les coûts de calcul. Au lieu d’activer l’ensemble du réseau neuronal à chaque requête, le système sélectionne uniquement quelques sous-modèles spécialisés appelés “experts”. Chaque expert est optimisé pour certains types de tâches, comme le raisonnement, le code ou le langage naturel. Un mécanisme de routage choisit quels experts utiliser selon l’entrée reçue. Cette approche permet d’obtenir des modèles très puissants, rapides et économes en mémoire par rapport aux architectures denses classiques.

Les objectifs du workflow

Avant de plonger dans les itérations, posons clairement ce que nous cherchions à atteindre.

• Réduire le temps de rédaction par rapport de 30 minutes à moins de 5 minutes.
• Maintenir une qualité de livrable client professionnelle : prose fluide, structure claire, tonalité adaptée au mois.
• Garantir 100% de fiabilité sur les chiffres (KPI SEO, positions, variations), aucune hallucination tolérée.
• Construire un workflow scalable aux 100 clients de l'agence sans modification du code pour chaque nouveau client.
• Rester 100% local : aucune donnée client ne sort de l'infrastructure de l'agence.
• Documenter le processus pour qu'un collaborateur non-développeur puisse l'utiliser en autonomie.

Cette dernière exigence est celle qui a le plus pesé sur nos choix d'architecture. Un workflow brillant mais utilisable uniquement par son concepteur n'a aucune valeur en agence. Il fallait que les consultants SEO puissent, en deux clics, produire un rapport fiable sans comprendre ni Python ni les paramètres d'Ollama.

Le cheminement : sept phases d'itérations

Le workflow final cache trois semaines d'allers-retours, de fausses pistes et de corrections. Voici le parcours complet, phase par phase.

Phase 1 - Le constat d'échec avec Mistral Small et GPT OSS 20B

Les hallucinations des modèles LLM sur données tabulaires proviennent rarement du prompt : dans cette expérience, 80 % des erreurs avaient des causes infrastructurelles identifiées, découpage RAG par défaut d'OpenWebUI, fenêtre de contexte Ollama limitée à 2 048 tokens par défaut, et inadéquation du modèle à la tâche de comptage conditionnel. Optimiser l'infrastructure a eu un impact bien supérieur à réécrire le prompt dix fois.

Notre premier réflexe a été logique : charger le rapport Semrush du mois (au format markdown, 32 blocs d'expressions clés) dans OpenWebUI, écrire un prompt système qui explique ce qu'on veut, et laisser le modèle rédiger.

Les résultats ont été catastrophiques. Sur un rapport de référence avec 17 expressions en Top 3, le modèle en annonçait 12 ou 23. Les volumes de recherche étaient inventés. Les variations de position étaient systématiquement inversées. Certaines expressions n'apparaissaient jamais, d'autres étaient citées trois fois.

Le diagnostic a pris du temps. Nous avons d'abord cru à un problème de prompt, trop d'instructions ouvertes, pas assez de contraintes. Nous avons réécrit le prompt système plusieurs fois, ajouté des règles anti-hallucination explicites, défini des seuils chiffrés pour les qualifications. Sans effet significatif.

Le vrai problème était ailleurs, à trois niveaux :

Premier niveau : le RAG chunking d'OpenWebUI. Par défaut, OpenWebUI découpe les documents uploadés en chunks de quelques centaines de tokens pour les embedder. Cette logique, conçue pour des documents narratifs, détruit la structure d'un rapport SEO : un chunk peut contenir le nom d'une expression sans sa position, ou les positions sans le volume associé. Le modèle ne voit que des fragments décontextualisés.

Deuxième niveau : le num_ctx d'Ollama par défaut. Ollama limite par défaut la fenêtre de contexte à 2048 tokens. Un rapport de 32 expressions au format markdown verbeux pèse environ 4000 tokens. La moitié du fichier était tout simplement tronquée à l'entrée du modèle, qui voyait les 15 premières expressions et devait deviner les autres, d'où les hallucinations massives.

Troisième niveau : les limites intrinsèques des modèles 20-24B. Mistral Small 3.1 (24B) et GPT OSS 20B ont une tendance connue à boucler sur les premiers éléments d'une liste longue et à inventer pour « compléter ». Sur un exercice d'extraction et de comptage conditionnel, ils ne sont pas fiables quel que soit le prompt.

Phase 2 - Première correction structurelle : pré-calcul du tableau

Face à ces constats, nous avons radicalement changé d'approche. Plutôt que de demander au modèle d'extraire les données du rapport Semrush, nous avons écrit un script Python qui fait ce travail d'extraction en amont et produit un tableau synthétique. Le modèle ne reçoit plus qu'un tableau de 32 lignes prêt à commenter.

Cette approche a éliminé les hallucinations d'extraction. Mais elle a fait émerger un nouveau problème : Mistral Small boucle sur le format tableau markdown dès qu'il y a plus d'une dizaine de lignes. Il rédige consciencieusement la première ligne, puis la deuxième, puis recommence la première en boucle. Le prompt a beau marteler « il y a 32 expressions, tu dois toutes les traiter », le modèle décroche.

C'était le moment de changer de modèle.

Phase 3 - Passage à Qwen3 et découverte du mode thinking

La séparation extraction / rédaction est le principe architectural qui élimine 100 % des hallucinations statistiques. Un script Python calcule les KPI et produit un JSON verrouillé ; le LLM ne fait que rédiger à partir de phrases pré-validées. Le JSON agit comme un contrat : le modèle ne peut mathématiquement pas inventer un chiffre qu'il n'a pas calculé.

Nous avons basculé sur Qwen3-30B-A3B, un modèle Mixture of Experts qui paraissait idéal : 30 milliards de paramètres totaux mais seulement 3 milliards activés par token, ce qui en fait un modèle rapide et léger. Cerise sur le gâteau, Qwen3 introduit un mécanisme de basculement explicite entre deux modes : /think qui active une phase de raisonnement interne avant la réponse, et /no_think qui désactive cette phase pour une réponse directe.

Cette dualité s'est révélée précieuse. Nous avons conçu un workflow en deux étapes :

• Étape 1, mode /think : le modèle reçoit le rapport et extrait tous les KPI dans un JSON structuré. Le mode raisonnement lui permet de vérifier ses comptages en interne avant de produire le JSON.
• Étape 2, mode /no_think : le modèle reçoit le JSON validé et rédige le rapport en prose fluide. Pas de raisonnement nécessaire, juste de la rédaction cadrée.

Le JSON joue un rôle central : c'est un contrat que le modèle ne peut pas violer à l'étape 2. Les chiffres sont verrouillés. Les hallucinations statistiques disparaissent.

Phase 4 - Le piège du MoE sur le comptage conditionnel

Avec Qwen3-30B-A3B, les hallucinations grossières ont disparu, mais un problème plus subtil est apparu : le modèle se trompait régulièrement sur les comptages conditionnels. Il annonçait « 17 expressions en Top 3 dont 0 à fort volume » alors que 5 étaient à fort volume, ou encore « 4 disparitions » lorsqu’il y en avait 3.

Après plusieurs analyses, le diagnostic s’est imposé.

Les modèles MoE (Mixture of Experts) comme Qwen3-30B-A3B activent un sous-ensemble différent de paramètres pour chaque token généré. Pour une tâche de comptage conditionnel, comme « combien d’expressions sont en Top 3 avec un fort volume de recherche ? », cette activation variable peut entraîner des incohérences au fil de la liste et faire “oublier” le compteur en cours.

À l’inverse, un modèle dense comme Qwen3-32B active l’ensemble de ses paramètres à chaque token. Cette architecture s’est révélée structurellement plus fiable pour notre workflow SEO, où la cohérence des comptages devait être irréprochable sur des listes longues et fortement conditionnelles.

Nous sommes donc passés à Qwen3-32B dense. Les résultats ont été immédiats : les KPI sont devenus fiables à 100 % sur les phases d’extraction et de comptage.

Phase 5 - Le correctif infrastructure qui a tout débloqué

Deux réglages OpenWebUI peu documentés sont indispensables pour un workflow sur documents structurés : Bypass Embedding and Retrieval (désactive le découpage RAG et envoie le document brut au modèle) et Full Context Mode (garantit l'injection intégrale du document dans le contexte). Combinés à un paramètre num_ctx d'Ollama porté à 32 768 tokens, ils éliminent les problèmes de troncature et d'extraction partielle.

Phase 6 - L'architecture script Python + Qwen rédacteur

Même avec Qwen3-32B dense et le contexte complet, nous observions encore quelques variations entre rapports. Deux fois sur dix, le modèle se trompait sur un KPI mineur ou omettait une section. Pour un workflow de production, deux erreurs sur dix est inacceptable.

La dernière évolution structurelle a consisté à déplacer tout le calcul des KPI hors du modèle. Un script Python analyse le rapport Semrush et produit un JSON qui contient non seulement les chiffres bruts mais aussi des phrases pré-rédigées pour chaque KPI. Exemple de contenu produit :

"phrase_top3": "17 expressions en Top 3 dont 5 à fort volume"

"phrase_couverture": "6 de nos 9 expressions à fort volume sont en première page de Google, soit 67%"

Le modèle ne fait plus que de la rédaction à partir de phrases déjà validées. Le JSON contient également un regroupement par niveau de volume (fort / modéré / faible) prêt à l'emploi, qui structure directement les sections du rapport.

Nous avons intégré ce script Python comme un outil OpenWebUI via le mécanisme de function calling. L'utilisateur envoie son rapport Semrush, et le modèle appelle automatiquement la fonction d'extraction avant de rédiger. Le tout se déroule en une conversation fluide pour le consultant.

Phase 7 - Universalisation pour l’ensemble des clients

Une fois le workflow stabilisé, nous l'avons étendu aux autres clients. Premier problème : les volumes et structures de données étaient très différents. Un client compte 32 expressions, dont 9 à fort volume, avec peu d'alertes par mois et un pour un autre 57 expressions sont suivies, dont 36 à fort volume, et les mois difficiles comptent plus de 30 alertes critiques.

Nous avions initialement conçu le script avec un concept de « familles thématiques » propres à chaque client (zones géographiques pour Arteco, destinations pour Saona). Cette personnalisation sectorielle aurait demandé de configurer chaque nouveau client. Face à la perspective de 100 configurations à maintenir, nous avons pris une décision stratégique : abandonner les familles thématiques et structurer le rapport uniquement par volume de recherche, universel, applicable à n'importe quel secteur.

Cette décision a simplifié le script de 200 lignes. Elle a surtout rendu le workflow vraiment scalable : chaque nouveau client se configure désormais en 2 minutes en modifiant trois champs (nom, secteur en une ligne, URL) dans un prompt dossier universel.

L'architecture finale

En production chez ID Interactive, le workflow d'automatisation des rapports SEO repose sur quatre composants figés communs à tous les clients, un script Python calculant 14 KPI et 11 phrases pré-rédigées, un modèle Qwen3-32B configuré avec température 0,15 et fenêtre de contexte 20 480 tokens, un prompt système, et deux prompts de conversation, et sur seulement trois variables par client : nom, secteur en une ligne, URL.

Ce qui est figé (identique pour tous les clients)

• Un script Python d'extraction qui calcule 14 KPI, produit 11 phrases pré-rédigées et regroupe les alertes par niveau de volume.
• Un modèle Ollama personnalisé basé sur Qwen3-32B avec température 0.15, num_ctx 20480, et un repeat_penalty à 1.12.
• Un prompt système qui cadre la posture générale du modèle.
• Deux prompts de conversation (/extraction-seo et /rapport-seo) qui déclenchent les deux étapes du workflow.

Ce qui varie par client (2 minutes de configuration)

• Un prompt dossier personnalisé avec trois variables : nom du client, secteur d'activité en une ligne, URL du site.
• Un dossier OpenWebUI qui regroupe les conversations mensuelles de ce client.

Le workflow mensuel pour les consultants

• Télécharger le rapport Semrush du mois au format markdown.
• Ouvrir le dossier du client dans OpenWebUI et démarrer une nouvelle conversation.
• Charger le prompt dossier en tapant /nom-client-seo.
• Uploader le .md et taper /extraction-seo. Le script Python est appelé automatiquement, le JSON apparaît avec les KPI validés.
• Vérifier en 10 secondes que les KPI correspondent aux attentes.
• Taper /rapport-seo pour générer le commentaire client en prose.
• Relire en 30 secondes et envoyer au client.

Temps total : environ 3 minutes, contre 30 minutes auparavant. Gain de productivité mesuré : 90%.

Résultats et validations

Avant de passer en production, nous avons validé le workflow sur cinq rapports consécutifs couvrant deux clients aux profils très différents et quatre mois d'historique.

Sur l'ensemble des tests, tous les KPI sont justes. Les rapports sont publiables en moins d'une minute de relecture, contre 30 minutes de rédaction auparavant. Les seules imperfections résiduelles sont cosmétiques : une expression parfois citée deux fois entre deux sections, un « principalement fort volume » légèrement imprécis, une phrase de réassurance manquante. Rien qui ne se corrige en quelques secondes de relecture.

Dix leçons apprises

1. Les hallucinations des modèles sur données tabulaires ne sont pas une fatalité

Le premier réflexe quand un modèle hallucine est d'incriminer sa taille. Dans notre cas, 80% des hallucinations venaient de trois causes infrastructurelles (RAG chunking, num_ctx, modèle inadapté) et 20% du prompt. Ajuster l'infrastructure a eu un impact bien supérieur à réécrire le prompt dix fois.

2. Séparer extraction et rédaction élimine 100% des hallucinations statistiques

Quand le script Python calcule les chiffres et que le LLM ne fait que rédiger à partir de phrases pré-validées, il n'existe mathématiquement plus aucune possibilité d'inventer un KPI. Le JSON est un contrat que le modèle ne peut pas violer.

3. Les modèles dense sont meilleurs que les MoE pour le comptage conditionnel

Pour toute tâche qui implique de maintenir un compteur à travers une liste longue (« combien de X qui sont aussi Y ? »), un modèle dense est structurellement plus fiable. Les MoE brillent sur la vitesse et la polyvalence, pas sur la cohérence arithmétique.

4. Le format des données d'entrée compte plus que le prompt

Un rapport markdown avec 32 blocs de 7 lignes chacun fait boucler les petits modèles. Un tableau compact de 32 lignes les laisse de marbre. Avant de réécrire un prompt, demandez-vous si le format d'entrée est adapté à la taille du modèle.

5. OpenWebUI a deux réglages critiques peu documentés

Bypass Embedding and Retrieval et Full Context Mode changent radicalement le comportement du système sur des documents structurés. Activez-les pour tout workflow qui n'est pas une recherche documentaire classique.

6. Ne jamais laisser num_ctx à sa valeur par défaut

Ollama fixe num_ctx à 2048 par défaut. Pour tout document structuré de plus de quelques paragraphes, il faut passer à 16 k, 20 k ou 32 k. Oublier ce réglage revient à envoyer des documents tronqués au modèle.

7. Universel bat sectoriel pour la maintenance long terme

Nous avons été tentés de personnaliser la logique par client (familles géographiques, clusters thématiques). Cette sophistication aurait coûté des heures de maintenance par mois pour 100 clients. Un regroupement universel par volume de recherche a simplifié le code de 200 lignes et rendu le workflow vraiment scalable.

8. La relecture humaine reste indispensable

Même avec un workflow à 100% de KPI justes, 1 à 2 petites imperfections subsistent par rapport. Une checklist de relecture de 30 secondes garantit un livrable client irréprochable. Le but n'est pas de supprimer l'humain, c'est de lui faire gagner 95% de son temps.

9. Le function calling d'OpenWebUI change la donne

Transformer un script Python en outil appelable par le modèle fluidifie radicalement l'expérience utilisateur. Le consultant n'exécute plus de commandes, il a une conversation. L'IA orchestre les appels techniques en arrière-plan.

10. Itérer, mais savoir s'arrêter

Nous avons fait 25 itérations majeures sur ce projet. Au bout d'un moment, chaque nouvelle version du prompt risquait de casser ce qui fonctionnait pour gagner 1% sur un détail cosmétique. Savoir dire « c'est bon, on passe en production » est une compétence en soi.

Le retour sur investissement

Chiffrons le gain concrètement.

Grâce à ce workflow d’IA locale, le temps de rédaction d’un rapport SEO est passé d’environ 30 minutes à 3 minutes par client, soit un gain de productivité de près de 90 %.

À l’échelle d’un portefeuille de 100 clients, cela représente :

• un temps mensuel réduit de 50 heures à environ 5 heures ;
• près de 540 heures libérées par an ;
• des KPI fiabilisés à 100 % grâce au calcul automatisé via Python ;
• une confidentialité totale des données clients grâce à une infrastructure 100 % locale.

Ces centaines d’heures économisées sont désormais réinvesties dans des missions à plus forte valeur ajoutée : analyse concurrentielle, optimisation SEO, accompagnement stratégique et production de contenu.

Le workflow ne remplace pas les consultants SEO ; il automatise la partie répétitive afin de leur permettre de consacrer davantage de temps à l’expertise et au conseil.

La suite

Ce workflow n'est qu'un début. L'infrastructure DGX Spark + Ollama + OpenWebUI est désormais en place, et les enseignements tirés du projet SEO sont directement transférables à d'autres usages.

Nous travaillons actuellement sur l'extension du même principe, séparation script / LLM, JSON comme contrat, prompts universels, à d'autres livrables récurrents de l'agence : rapports Google Analytics, synthèses de campagnes SEA, analyses de performances réseaux sociaux. Le gain attendu sur ces périmètres est du même ordre que sur le SEO.

Plus largement, cette expérience nous a convaincus que le débat « IA cloud contre IA locale » n'a pas de réponse unique. Pour les agences qui traitent des données client sensibles et qui ont des cas d'usage récurrents et bien définis, une infrastructure IA locale bien configurée offre un ratio coût / contrôle / qualité que le cloud ne peut pas égaler. Pour des usages ponctuels ou des tâches nécessitant les capacités des modèles frontière, le cloud reste pertinent. Les deux approches se complètent, elles ne s'opposent pas.

Pour conclure

Ce projet SEO m'aura appris plus sur l'ingénierie des workflows IA que trois ans de veille technologique. Il m'aura surtout rappelé une évidence qu'on oublie facilement dans l'excitation des modèles frontière : l'IA en entreprise ne vaut que par l'usage qu'on peut en faire de manière fiable, reproductible et documentée. Le reste, c'est de la démonstration.

Chez ID Interactive, nous sommes désormais équipés pour intégrer l'IA locale dans tous nos processus de production qui s'y prêtent. Si vous êtes dirigeant d'agence, consultant digital ou responsable SEO et que ce retour d'expérience vous parle, n'hésitez pas à nous contacter, les retours sur ce type de projet sont toujours riches d'enseignements partagés.

Eric Doyen
Dirigeant de ID Interactive

Foire aux questions

Cas d'usage liés : la refonte SEO sur un CMS propriétaire et la reconstruction du suivi des conversions Google Ads.