• Anthropic, SpaceX et la nouvelle guerre mondiale du compute IA

Le 6 mai 2026, Anthropic a annoncé un partenariat majeur avec SpaceX visant à utiliser l’intégralité de la capacité du datacenter Colossus 1.

L’annonce paraît technique au premier abord. En réalité, elle révèle un changement beaucoup plus profond dans l’industrie de l’intelligence artificielle.

Nous ne sommes plus dans une simple course aux modèles. Nous sommes désormais dans une course mondiale au compute.

Une annonce qui dépasse largement Claude

Officiellement, Anthropic communique sur : l’augmentation des limites d’utilisation de Claude ;

• l’amélioration de Claude Code ;
• et l’augmentation des quotas API Opus.

Mais ces améliorations ne sont qu’une conséquence visible d’un problème beaucoup plus structurel : la demande en puissance de calcul explose à une vitesse jamais vue.

L’élément clé de l’annonce est celui-ci :

• plus de 300 MW de capacité supplémentaire ;
• plus de 220 000 GPU NVIDIA.

Pour donner un ordre d’idée : 300 MW représente la consommation électrique d’une ville moyenne.

On change complètement d’échelle.

L’IA devient une problématique énergétique

Pendant longtemps, les limites de l’informatique étaient principalement :

• le CPU ;
• la RAM ;
• le stockage ;
• ou le réseau.

Avec l’IA générative, le facteur limitant devient désormais :

• l’électricité ;
• le refroidissement ;
• l’accès aux GPU ;
• et la densité des infrastructures.

Les modèles modernes nécessitent des clusters gigantesques :

• réseaux ultra basse latence ;
• NVLink et InfiniBand ;
• refroidissement liquide ;
• alimentation redondée ;
• stockage distribué massif.

Les annonces se comptent maintenant en gigawatts.

Anthropic mentionne notamment :

• jusqu’à 5 GW avec Amazon ;
• 5 GW avec Google/Broadcom ;
• 30 milliards de dollars de capacité Azure ;
• 50 milliards investis avec Fluidstack.

L’IA devient progressivement une industrie lourde.

Pourquoi SpaceX est un partenaire logique

L’association entre Anthropic et SpaceX peut sembler surprenante.

En réalité, elle est cohérente.

SpaceX possède :

• une capacité industrielle énorme ;
• une expertise énergétique ;
• des infrastructures réseau mondiales via Starlink ;
• et une vitesse d’exécution très supérieure aux acteurs traditionnels.

Le point le plus intéressant reste probablement la mention d’un intérêt pour du “orbital AI compute”.

Autrement dit : des infrastructures de calcul IA potentiellement déployées en orbite.

Cela peut sembler futuriste, mais plusieurs problématiques pourraient pousser dans cette direction :

• accès énergétique ;
• refroidissement ;
• résilience ;
• indépendance géopolitique ;
• connectivité mondiale.

Souveraineté et conformité deviennent critiques

Anthropic insiste également sur :

• la résidence des données ;
• les besoins des secteurs régulés ;
• et le déploiement d’infrastructures en Europe et en Asie.

Cela confirme une tendance forte : les entreprises veulent davantage de maîtrise sur :

• la localisation des données ;
• les flux IA ;
• les dépendances cloud ;
• et les contraintes réglementaires.

Pour les architectes infrastructure et cloud, cela va profondément transformer :

• les stratégies hybrides ;
• le FinOps ;
• la gestion énergétique ;
• la gouvernance des workloads IA ;
• et les architectures multi-régions.

Le compute devient une ressource stratégique

Le point central de cette annonce est probablement celui-ci :

Le compute devient une ressource stratégique mondiale.

La compétition ne se joue plus uniquement sur :

• les modèles ;
• les algorithmes ;
• ou les produits.

Elle se joue maintenant sur :

• l’énergie ;
• les GPU ;
• les chaînes d’approvisionnement ;
• les datacenters ;
• et les infrastructures réseau mondiales.

L’IA rapproche progressivement l’informatique :

• des télécoms ;
• de l’énergie ;
• et des infrastructures critiques nationales.

Nous sommes probablement au début d’une nouvelle phase de l’industrie technologique : celle de l’industrialisation massive du compute IA.

Source officielle : Anthropic – Higher usage limits for Claude and a compute deal with SpaceX

🎯 Pourquoi ce projet ?

Dans les environnements critiques (SaaS, finance, industrie…), une architecture cloud ne doit pas seulement “fonctionner”.

Elle doit être capable de :

• encaisser des pics de charge
• résister à des pannes
• sécuriser les données
• évoluer sans interruption
• être observable et pilotable

C’est exactement ce que j’ai modélisé ici : une architecture microservices haute disponibilité sur AWS, basée sur les bonnes pratiques des environnements entreprise.

---

🏗️ 1. Une architecture pensée pour ne jamais tomber

Le principe global est simple :

1. Les utilisateurs arrivent via Internet
2. Le trafic passe par une couche de protection et de distribution
3. Il est ensuite dirigé vers des services applicatifs (microservices)
4. Les données sont stockées dans plusieurs systèmes spécialisés

👉 L’objectif : éviter tout point de défaillance unique

Concrètement :

• plusieurs zones de disponibilité (data centers AWS)
• duplication des services
• bascule automatique en cas de problème

---

🌐 2. Un réseau conçu pour isoler et protéger

Le réseau est structuré en 3 niveaux :

• Public → exposé à Internet (entrée du trafic)
• Privé applicatif → les services métiers
• Privé data → les bases de données (ultra isolées)

👉 Résultat :

• les données sensibles ne sont jamais exposées
• chaque couche a des règles de sécurité spécifiques

---

💾 3. Des données réparties selon leur usage

Toutes les données ne se ressemblent pas. Donc on utilise plusieurs technologies :

• Base relationnelle → pour les transactions (ex : commandes)
• Cache → pour la performance
• Streaming → pour les événements en temps réel
• Stockage objet → pour fichiers et sauvegardes
• Base clé-valeur → pour la vitesse extrême

👉 Objectif : performance + résilience + scalabilité

---

🚀 4. Des déploiements sans interruption (et sans stress)

Le déploiement suit un principe simple :

1. Code testé automatiquement
2. Analyse de sécurité
3. Build et validation
4. Déploiement progressif

👉 Exemple concret :

• on déploie une nouvelle version sur 5% des utilisateurs
• on observe le comportement
• si tout va bien → on augmente progressivement

👉 Sinon → rollback automatique

Résultat :

• moins de risques
• plus de confiance
• plus de vitesse

---

📊 5. Une visibilité complète (observabilité)

Une plateforme fiable, c’est une plateforme que l’on comprend.

On surveille donc :

• les logs (ce qui s’est passé)
• les métriques (CPU, erreurs, latence)
• les traces (parcours complet d’une requête)

👉 Et surtout : on ne déclenche pas d’alertes “bêtes”

On utilise des SLO (objectifs de service) : → alerter uniquement quand l’expérience utilisateur est réellement impactée

---

🔐 6. Une sécurité pensée dès le départ

La sécurité repose sur plusieurs principes :

• Zero Trust → rien n’est autorisé par défaut
• Moindre privilège → chaque service a uniquement les droits nécessaires
• Chiffrement partout
• Aucune exposition inutile (pas de SSH, pas de bastion)

👉 Exemple : les accès humains passent par des systèmes sécurisés et audités → pas de “porte dérobée”

---

🔄 7. Et si toute la région tombe ?

C’est LA question que peu d’entreprises se posent vraiment.

Dans cette architecture :

• les données sont répliquées dans une autre région AWS
• une infrastructure minimale est déjà prête ailleurs
• un basculement peut être déclenché

👉 Objectif :

• perte de données quasi nulle
• reprise en ~30 minutes

---

🧭 Ce qu’il faut retenir

Une architecture cloud moderne, ce n’est pas juste : 👉 “mettre des serveurs dans le cloud”

C’est un ensemble cohérent de choix :

• disponibilité
• sécurité
• performance
• automatisation
• résilience

Et surtout : 👉 tout doit être pensé dès le départ

---

💡 Pourquoi ça intéresse les dirigeants ?

Parce que derrière la technique, il y a des enjeux business :

• éviter les interruptions de service
• protéger les données
• accélérer le time-to-market
• réduire les risques (cyber, opérationnels)
• garantir la continuité d’activité

---

🔚 Conclusion

Beaucoup d’entreprises pensent être protégées…

…jusqu’au jour où ça casse.

👉 Une architecture robuste ne s’improvise pas.

C’est exactement le type de réflexion que je mène dans mes missions : concevoir des systèmes fiables, testés, et réellement adaptés aux contraintes métier.

---

Si ces sujets vous parlent (architecture cloud, résilience, automatisation, IA appliquée aux opérations), je serais curieux d’échanger.

Architecture technique du POC

• Prometheus (LAN) : collecte les métriques système via node_exporter sur l'ensemble du parc (CPU, RAM, disque, réseau, SMART).
• Grafana (LAN) : visualisation, dashboards et gestion des alertes.
• Loki (LAN) : agrégation centralisée des logs via Promtail, indexés par labels (instance, job, level, log_type, service_name, filename).
• Alertmanager (LAN) : réception des alertes Prometheus, déduplication, routage vers le webhook n8n.
• Ollama (LAN) : serveur LLM auto-hébergé exécutant un modèle léger, dédié à l'analyse des alertes.
• n8n (DMZ) : orchestration du workflow d'enrichissement, appel au LLM et envoi des emails.

18 règles d'alerte Prometheus sont définies, organisées en fichiers thématiques couvrant les métriques système (CPU, mémoire, disque, filesystem), les services applicatifs, les sondes blackbox, le réseau et la santé SMART des disques. Ce sont les règles du groupe node (CPUHigh, MemHigh, FSDanger, FilesystemReadOnly) qui bénéficient directement de l'enrichissement dans ce POC.

Test 1 : Arrêt manuel d'un node.

Email d'alerte avant retraitement : Email de résolution avant retraitement :

Pas très clair...

Un workflow n8n initial a donc été mis en place pour intercepter les événements via webhook et reconstruire entièrement l'email. Le code JavaScript en entrée du workflow parse le payload Alertmanager, extrait les champs utiles (nom de l'alerte, instance, sévérité, durée du downtime) et les transmet à un nœud de mise en forme HTML. Ce dernier génère un email structuré avec un code couleur immédiatement lisible : rouge pour une alerte active, vert pour une résolution, avec un sujet d'email conditionnel permettant le tri en boîte de réception d'un simple coup d'œil. Ce premier palier, relativement simple à mettre en œuvre, a suffi à transformer l'expérience utilisateur côté notification.

Mail d'alerte

Mail de résolution

C'est sur cette base que s'appuient les étapes suivantes.

Workflow n8n : de l'alerte brute au diagnostic enrichi

Chaîne de traitement initiale

Le workflow recevait les alertes Alertmanager via webhook POST, extrayait les champs clés (alertname, instance, severity, status, durée), formatait un email HTML et l'envoyait. Fonctionnel, mais limité : aucun contexte, aucune aide au diagnostic.

Chaîne enrichie

Cinq nœuds ont été insérés entre le parsing de l'alerte et la mise en forme de l'email :

1. Build Queries (Code JavaScript) — Construit dynamiquement les requêtes Loki et Prometheus selon le type d'alerte. Par exemple, pour une alerte CPUHigh, la requête Prometheus calculera le pourcentage CPU réel via rate(node_cpu_seconds_total) ; pour FSDanger, elle cartographiera l'occupation de chaque point de montage. Un point d'attention a été la corrélation des labels entre Prometheus (FQDN avec port) et Loki (hostname court) : le nœud extrait automatiquement le hostname court pour interroger Loki.
2. Query Loki (HTTP Request) — Interroge l'API Loki sur une fenêtre de 15 minutes en filtrant les logs de l'instance concernée avec un pattern regex ciblant les niveaux error, critical, warn, fail, panic, oom et killed. Le label instance sert de clé de corrélation entre l'alerte Prometheus et les logs Loki.
3. Query Prometheus (HTTP Request) — Récupère la valeur en temps réel de la métrique en alerte. Le technicien voit immédiatement si le problème est toujours actif au moment de la lecture de l'email.
4. Build LLM Prompt (Code JavaScript) — Prépare le contexte pour le LLM : type d'alerte, instance concernée, sévérité et valeur actuelle de la métrique. Le prompt est volontairement concis pour garantir un temps de réponse acceptable. Ce nœud isole la construction de la requête de l'appel HTTP, ce qui s'est avéré nécessaire pour contourner les limitations du parser d'expressions n8n sur les payloads JSON complexes.
5. LLM Diagnostic (HTTP Request) — Envoie le prompt au serveur Ollama et récupère la réponse. Le modèle retourne un diagnostic en langage naturel avec des actions correctives adaptées au type d'incident.
6. Analyse et Suggestions (Code JavaScript) — Compile l'ensemble des données (Loki, Prometheus, LLM) et génère :

• Un niveau de criticité calculé dynamiquement (pas seulement la severity de l'alerte, mais aussi le volume de logs d'erreur détectés).
• La valeur temps réel de la métrique (ex : « 87.3% CPU »).
• Des commandes de remédiation directement exécutables, adaptées au type d'incident, générées par règles déterministes (switch/case selon le type d'alerte). Par exemple, pour un disque plein : identification des répertoires volumineux, purge des anciens logs journald, nettoyage des paquets obsolètes.
• Le diagnostic IA en langage naturel, présenté dans une section dédiée de l'email.

L'email final intègre désormais un tableau de synthèse, les dernières lignes de logs Loki pertinentes, une liste de commandes prêtes à l'emploi, et le diagnostic IA. La distinction visuelle entre alerte active et résolue est appliquée dès le sujet de l'email — les emails de résolution ne contiennent volontairement que le résumé, sans le bloc d'analyse complet.

Test 2 : stress-test CPU d'un node

Email d'alerte enrichie par l'IA

Email de résolution avec MTTR

Déclenchement de l'alerte pour le test Pour valider la chaîne complète, le déclenchement de l'alerte a été provoqué par un stress-test CPU volontaire sur un conteneur de test. Ce type de sollicitation manuelle permet de vérifier le bon fonctionnement de bout en bout — du déclenchement Prometheus à la réception de l'email enrichi — sans attendre un incident réel. Le mail reçu montre d'ailleurs une valeur CPU à 100%, cohérente avec la charge artificielle injectée.

Intégration du LLM : choix et contraintes

Le choix d'un LLM auto-hébergé plutôt qu'une API cloud s'est imposé pour des raisons de souveraineté des données (les alertes contiennent des informations d'infrastructure interne) et de maîtrise des coûts. Ollama a été retenu pour sa simplicité de déploiement et son support natif de plusieurs modèles open source.

Le dimensionnement a nécessité quelques itérations. Un modèle 7B de paramètres, bien que plus précis dans ses analyses, s'est avéré trop lent en inférence CPU pure (30 secondes pour une phrase simple, plusieurs minutes pour un prompt de diagnostic complet). Le passage à un modèle plus léger (3.8B paramètres) a ramené le temps de réponse à quelques secondes, avec une qualité de diagnostic tout à fait exploitable pour ce cas d'usage. La différence de pertinence se manifesterait surtout sur des corrélations complexes entre logs — ce qui n'est pas le besoin principal ici, puisque les suggestions déterministes couvrent déjà les actions de remédiation classiques.

Le modèle LLM (phi3:mini) tourne sur une lxc sans GPU Nvidia, avec 16G de Ram 8vcpu et 40G de disque. Serveur proxmox : Intel Xeon-D 2141I - 8c/16t - 2.2 GHz/3 GHz / 64 Go ECC 2133 MHz / PVE8

Bénéfices pour les équipes techniques

Même si l'analyse reste à affiner — notamment sur la pertinence des requêtes Loki selon les types d'incidents et la profondeur des diagnostics IA — le gain est déjà perceptible. Les logs corrélés et la valeur temps réel réduisent la phase initiale d'investigation manuelle. Le technicien dispose de commandes de remédiation directement exploitables depuis l'email. Le diagnostic IA ajoute une couche d'interprétation en langage naturel qui peut aider un profil moins expérimenté à comprendre la situation. Le niveau de criticité calculé automatiquement (intégrant le volume de logs d'erreur) offre une meilleure priorisation que la severity statique de l'alerte. La fenêtre de 15 minutes montre ce qui s'est passé juste avant le déclenchement — souvent plus révélateur que l'alerte elle-même. La chaîne est fonctionnelle de bout en bout ; il s'agit maintenant de l'enrichir itérativement pour gagner en précision.

Bénéfices pour les décideurs

Au-delà de l'aspect technique, ce POC démontre plusieurs points à valeur business. Le MTTR (Mean Time To Resolve) devrait diminuer quand le diagnostic arrive avec l'alerte, même si ce gain reste à mesurer sur la durée. Les suggestions de remédiation — qu'elles soient déterministes ou générées par le LLM — codifient le savoir-faire de l'équipe : même un junior ou un prestataire reçoit les bonnes pistes sans dépendre d'un expert disponible. L'ensemble repose sur des briques open source (Grafana, Prometheus, Loki, n8n, Ollama) — le surcoût est uniquement du temps d'intégration, pas de licences.

Perspectives

Ce POC constitue une base fonctionnelle. Les évolutions envisagées : l'enrichissement du prompt LLM avec des extraits de logs Loki (actuellement le modèle reçoit uniquement le type d'alerte et la valeur métrique, les logs étant présents dans l'email mais pas transmis au LLM pour des raisons de performance en inférence CPU), l'intégration de l'historique des commandes récentes (via l'audit log ou le journal systemd) afin de corréler une alerte avec une action humaine — par exemple identifier qu'un pic CPU fait suite à un stress-test volontaire ou qu'un reboot a été déclenché manuellement, ce qui changerait radicalement le diagnostic à produire. D'autres pistes incluent l'extension aux alertes applicatives via les labels Loki dédiés aux services, une escalade intelligente vers un canal de communication d'équipe ou un runbook automatisé en cas de pattern critique détecté (OOM killer, I/O errors), un feedback loop permettant aux techniciens de valider ou corriger les diagnostics pour améliorer les suggestions futures, et le passage éventuel à un modèle plus puissant si les ressources le permettent (GPU dédié ou modèle quantifié).

Pierre-Marie Esposito

Le problème que tout chercheur de logement connaît

Quiconque a déjà cherché un logement, à la location comme à l’achat, connaît cette routine rapidement chronophage : ouvrir Leboncoin, configurer la recherche, actualiser, scroller, passer à Bien'ici, recommencer, puis PAP… et répéter ce cycle plusieurs fois par jour pendant des semaines.

Les bonnes annonces partent souvent en quelques heures. Dans le même temps, les filtres proposés par les plateformes restent relativement limités : difficile, par exemple, d’exprimer des contraintes précises comme “jardin attenant d’au moins 250 m²” ou “exclure toute forme de colocation déguisée", "je cherche un jardin avec des palmiers", "je veux une salle de bain avec douche à l'italienne”.

Résultat : beaucoup de bruit, beaucoup de temps perdu, et des opportunités manquées.

Execution :

---

Concevoir un système pour automatiser la veille

Plutôt que d’optimiser marginalement cette recherche, j’ai choisi de changer d’approche : concevoir un système capable de la prendre en charge de manière autonome.

L’objectif n’était pas simplement d’agréger des annonces, mais de reproduire — et systématiser — un processus de sélection pertinent :

• surveiller plusieurs sources en continu
• filtrer rapidement ce qui est hors sujet
• analyser finement le contenu restant
• ne remonter que les annonces réellement intéressantes

---

Architecture générale

Le système repose sur un pipeline relativement simple dans sa logique, mais structuré pour être robuste et extensible :

1. Configuration des critères via une interface dédiée
2. Surveillance continue de plusieurs sources
3. Filtrage en plusieurs étapes
4. Scoring intelligent des annonces
5. Notification des résultats pertinents

---

Un filtrage en plusieurs niveaux

L’un des points clés est d’éviter de solliciter inutilement les modèles d’IA, tout en conservant un bon niveau de précision.

Pour cela, le traitement est découpé en trois étapes.

1. Pré-filtrage

Une première passe élimine immédiatement :

• les annonces vides ou incomplètes
• les “recherches de logement”
• les contenus contenant des mots interdits
• les biens hors zone géographique

Ce niveau permet de réduire fortement le volume à traiter.

---

2. Filtrage déterministe

Une seconde étape applique des règles simples :

• prix
• surface
• nombre de pièces

Ce filtrage mécanique permet d’écarter rapidement les cas non pertinents sans coût supplémentaire.

---

3. Scoring via modèle de langage

Le cœur du système repose sur l’utilisation d’un LLM (ici Anthropic via le modèle Claude Haiku).

Chaque annonce restante est analysée à partir d’un prompt généré dynamiquement en fonction des critères utilisateur.

Le modèle attribue un score de pertinence de 0 à 10, permettant de hiérarchiser les résultats.

Un point important : le prompt n’est pas statique. Il est construit automatiquement à partir des contraintes définies, ce qui permet d’adapter finement l’analyse à chaque cas.

---

Collecte des données

Le système s’appuie sur plusieurs sources immobilières, chacune avec des modes d’accès et des contraintes techniques spécifiques.

Certaines plateformes exposent encore des endpoints JSON relativement exploitables avec des paramètres structurés, tandis que d’autres reposent sur des interfaces fortement protégées, avec des mécanismes de détection d’automatisation de plus en plus avancés.

Dans la pratique, cela se traduit par différents cas de figure :

• accès via API interne avec validation des paramètres de requête
• pages HTML nécessitant une interprétation côté navigateur
• protections anti-bot reposant sur la détection d’IP, l’analyse comportementale ou l’exécution de JavaScript

👉 Tous ces éléments rendent la collecte de données non triviale, et surtout évolutive dans le temps.

---

Gestion des contraintes anti-automatisation

Les plateformes immobilières utilisent aujourd’hui des solutions spécialisées pour limiter les accès automatisés (WAF, challenges JavaScript, détection d’IP de datacenter, etc.).

Ces mécanismes introduisent des contraintes fortes :

• un comportement acceptable depuis une IP résidentielle peut être bloqué depuis une infrastructure serveur
• certaines pages nécessitent l’exécution de JavaScript pour être accessibles
• des endpoints peuvent être modifiés, restreints ou supprimés sans préavis

---

Stratégies d’adaptation

Pour garantir la robustesse du système, plusieurs approches sont envisagées selon les sources :

• utilisation de proxys adaptés pour rapprocher le trafic d’un usage réel
• recours à des navigateurs headless pour reproduire fidèlement le comportement d’un navigateur
• adaptation dynamique des patterns de requêtes et des fréquences d’appel

Chaque solution implique des arbitrages entre :

• performance
• coût
• complexité
• maintenabilité

---

Gestion des doublons et architecture

Chaque utilisateur dispose de sa propre base SQLite, ce qui permet de garantir qu’une annonce ne soit jamais envoyée deux fois.

L’ensemble est déployé dans une architecture simple mais cloisonnée :

• backend Python exposé via API REST
• exécution dans un conteneur Docker
• hébergement sur une LXC Proxmox
• interface de configuration isolée en DMZ

Stack utilisée : Python 3.12, LLM (Claude Haiku), Telegram Bot, SQLite, Docker, Proxmox, VyOS.

---

Enseignements

Après les premières itérations, plusieurs points se dégagent.

• Le scoring via LLM est très efficace, mais extrêmement dépendant de la qualité du prompt. Le calibrage est un sujet en soi.
• Introduire une “zone grise” (scores intermédiaires) permet de ne pas rater des opportunités lorsque les descriptions sont incomplètes.
• Générer dynamiquement les prompts à partir d’une interface utilisateur simplifie fortement l’usage tout en conservant de la précision.
• La modularité des scrapers est essentielle : les sources évoluent régulièrement, et chaque connecteur doit pouvoir être adapté indépendamment, notamment face aux mécanismes de protection anti-automatisation qui évoluent en permanence.

---

Un pattern applicable à d’autres cas

Au-delà du cas immobilier, ce type d’architecture correspond à un schéma plus général :

👉 veille multi-sources + filtrage progressif + scoring intelligent

Ce pattern peut s’appliquer à de nombreux contextes :

• veille concurrentielle
• sourcing de leads
• détection d’opportunités (marché, recrutement, data…)
• tri automatisé de contenus à forte volumétrie

---

Ouverture

Ce projet est avant tout un cas concret d’application de l’automatisation et des modèles de langage à un problème réel.

Il illustre surtout une approche : structurer un flux de données, réduire le bruit progressivement, et n’appliquer l’intelligence que là où elle apporte réellement de la valeur.

💬 Si vous travaillez sur des problématiques similaires (veille, filtrage, automatisation, IA), ou que vous avez besoin de concevoir ce type de système sur mesure, je serai ravi d’échanger.

1. Pipeline global

---

2. Infrastructure (self-hosted)

Stack globale

• Hyperviseur : Proxmox VE
• Conteneurisation : LXC
• Segmentation réseau : firewall (type VyOS ou équivalent)

Segmentation minimum recommandée :

• LAN : administration
• DMZ :
  • - n8n
  • - site web public
• Zone interne :
  • - Strapi
  • - SaaS (Next.js)

👉 Objectif :

• - Strapi non exposé publiquement
• - n8n exposé uniquement pour les webhooks
• - séparation stricte des flux

---

3. SaaS (Frontend de rédaction)

Stack

• Framework : Next.js
• Éditeur : recommandé → TipTap ou Slate.js

Fonction

Interface interne permettant :

• - création d’articles
• - édition riche (WYSIWYG)
• - envoi vers Strapi via API REST

Logique

1. L’utilisateur rédige un articleLe contenu est structuré (JSON ou HTML)
2. Envoi via API vers Strapi :
   • titre
   • contenu
   • image
   • statut = draft ou published

---

4. Strapi (CMS central)

Stack

• CMS : Strapi
• LXC dédiée

Rôle

Source de vérité unique

Contient :

• articles
• images
• statuts de publication
• métadonnées (tags, SEO…)

Configuration clé

a. Content Type

Créer un type Article :

• title (string)
• content (rich text)
• slug (pour le lien direct article)
• tags (relation ou string)
• labels (pour classement sur le site)

b. Webhook

Configurer un webhook :

• trigger : entry.publish
• destination : n8n (URL publique DMZ)

---

5. n8n (orchestration)

Stack

• Outil : n8n
• Déployé en DMZ

Rôle

Cœur du système :

• - réception webhook Strapi
• - transformation des données
• - enrichissement
• - validation
• - publication multi-plateformes

---

6. Workflow n8n (logique détaillée)

Étapes

a. Webhook (entrée)

• - reçoit payload Strapi
• extrait :
  • - titre
  • - contenu
  • - image

---

b. Séparation contenu (Javascript)

• texte
• image

👉 permet :

• gestion spécifique par plateforme
• optimisation formats

---

c. Enrichissement via IA

• API : OpenAI

Utilisation :

• - génération de hashtags

---

d. Validation (critique)

Envoi d’un email :

• contenu généré
• liens de validation :
  • ✅ publier
  • ❌ annuler

👉 permet de garder le contrôle humain

---

e. Publication

Après validation :

LinkedIn

• - API officielle
• - publication sur page personnelle avec commentaire engagement
• 

Facebook

• - Graph API
• - publication sur page entreprise avec commentaire engagement
• 

---

7. Intégration LinkedIn

Plateforme

• LinkedIn

Étapes

1. Créer une app LinkedIn Developer
2. Obtenir :
   • client ID
   • client secret
3. Générer un token avec scopes :

• w_member_social
• r_liteprofile
• r_emailaddress

1. Associer la page entreprise

👉 Attention : LinkedIn est restrictif → validation de l’app nécessaire

---

8. Intégration Facebook

Plateforme

• Meta

Étapes

1. Créer une app Meta Developer
2. Ajouter produit : Facebook Login
3. Générer un token long-lived

Permissions nécessaires :

• pages_manage_posts
• pages_read_engagement

1. Récupérer :

• - page ID
• - page access token
• 

---

9. Site web (blog)

Stack

• Framework : Next.js
• (ou Nest.js si API backend séparée)

Fonctionnement Publication dans le blog du site

• - récupération des articles via API Strapi
• - génération des pages (SSR ou SSG)Publication en encart en fonction des labels dans les pages dédiées

SEO

• - gestion des tags
• - slug optimisé
• - meta description

---

Conclusion Ce type d’architecture reste volontairement simple, mais pose des bases solides : centralisation du contenu, découplage et orchestration par événements.

• Elle peut ensuite évoluer vers des usages plus avancés (multi-canaux, scoring, personnalisation, automatisation SEO).
• Si vous travaillez sur ce type de sujets, je serai intéressé d’échanger sur vos architectures ou vos contraintes.

Pierre-Marie Esposito