Architecture de Narrative Shield : Détection réactive, influence proactive et évaluation des effets

Narrative Shield est la plateforme de soutien à la décision StratCom augmentée par l'IA de Corvus Intelligence — une console unifiée pour les opérations du domaine cognitif couvrant l'intégralité du cycle des effets de communications stratégiques. Contrairement aux outils ponctuels qui ne traitent que la détection ou la seule génération de contenu, Narrative Shield est organisé autour de trois flux opérationnels imbriqués : un flux réactif pour la surveillance permanente des menaces, un flux proactif pour les opérations d'influence planifiées, et un flux d'évaluation pour l'analyse après action. Cet article présente l'architecture technique de chaque flux ainsi que les décisions d'ingénierie backend et frontend qui les sous-tendent.

La plateforme est construite sur .NET 8 / ASP.NET Core pour l'API backend, React 18 avec TypeScript et Vite en frontend, et intègre l'API Anthropic Claude pour toutes les tâches de raisonnement augmenté par l'IA. Le déploiement est basé sur Docker avec une API REST conforme à OpenAPI 3, et le système s'intègre avec OpenTAKServer pour la livraison sur le terrain des produits StratCom approuvés.

Flux réactif : pipeline de surveillance narrative permanente

Le flux réactif constitue l'épine dorsale de surveillance continue de Narrative Shield. Il s'exécute en tant que service d'arrière-plan persistant dans le backend .NET, interrogeant les sources de signaux configurées à un intervalle configurable (par défaut : 5 minutes) et faisant passer chaque signal ingéré par un pipeline de traitement multi-étapes avant de remonter les détections qualifiées vers la file d'attente de l'opérateur.

Les étapes du pipeline sont : ingestion et normalisation, correspondance avec la taxonomie de mots-clés, scoring de sévérité à 5 facteurs, construction du graphe de chaîne de propagation, génération de Courses of Action et insertion dans la file d'attente de l'opérateur. Chaque étape est implémentée en tant que service indépendant avec une interface définie, ce qui permet de remplacer ou d'étendre des étapes individuelles sans affecter le reste du pipeline.

L'algorithme de scoring de sévérité à 5 facteurs

Le scoring de sévérité est l'étape quantitative centrale du flux réactif. Chaque narratif détecté est évalué selon cinq dimensions indépendantes :

Portée — l'audience estimée exposée au narratif au moment de la détection, dérivée du nombre d'abonnés des comptes, de la duplication inter-plateformes et du taux d'amplification organique estimé. La portée est normalisée en logarithme pour éviter que les comptes à grand nombre d'abonnés ne dominent les scores sur toutes les dimensions.

Vélocité — le taux de propagation mesuré comme le gradient de la portée sur la fenêtre d'observation des 6 dernières heures. Un narratif qui a doublé son audience en deux heures obtient un score de vélocité plus élevé qu'un narratif ayant atteint la même audience absolue sur 48 heures. La vélocité est le signal d'alerte précoce le plus fiable pour les comportements inauthentiques coordonnés.

Polarité de sentiment — le degré d'hostilité ou de nuisance dirigé contre l'entité surveillée, scoré par l'API Claude sur une échelle de -1,0 à +1,0, avec la magnitude de polarité mappée sur 0–100 pour la contribution à la sévérité. Le prompt de l'API inclut le contexte de l'entité afin que le langage politique ambigu soit évalué par rapport au sujet surveillé spécifique plutôt que de manière générique.

Alignement sur l'audience cible — dans quelle mesure la distribution observée du narratif correspond aux profils démographiques et psychographiques des audiences prioritaires définies de l'entité surveillée. Ce facteur utilise les cartes de segments d'audience configurées dans le panneau de cartographie des audiences et croise les données de distribution géographique de la couche d'ingestion.

Crédibilité de la source — un score d'autorité composite pour les comptes d'origine et les principaux comptes d'amplification, tiré du Registre de sources maintenu par les opérateurs et mis à jour en continu à partir des signaux comportementaux. Les comptes ayant un historique établi de comportements inauthentiques coordonnés reçoivent des ajustements négatifs de crédibilité.

Les cinq scores de dimension sont combinés en un indice de sévérité unique de 0 à 100 à l'aide de pondérations configurables par sujet. Par défaut, les pondérations sont égales (0,2 par facteur). Les administrateurs de sujets peuvent ajuster les pondérations via le panneau de configuration du scoring ; un sujet de protection des forces, par exemple, pourrait augmenter le poids de l'alignement sur l'audience cible et de la crédibilité de la source, tandis qu'un sujet narratif de niveau stratégique pourrait augmenter le poids de la portée et de la vélocité.

Construction du graphe de chaîne de propagation avec Cytoscape.js

Une fois qu'un narratif dépasse le seuil de sévérité, le flux réactif construit un graphe de chaîne de propagation pour visualiser comment le contenu s'est diffusé des sources d'origine via les réseaux d'amplificateurs jusqu'à atteindre les audiences. Le graphe est rendu en frontend à l'aide de Cytoscape.js, choisi pour ses performances avec les grands graphes creux et son support des algorithmes de disposition personnalisés adaptés aux visualisations de flux d'information dirigés.

La construction du graphe commence par les nœuds d'amorçage du Registre de sources : les comptes adverses connus et les clusters de coordination associés au sujet de veille. Les données de relations de la couche d'ingestion — chaînes de réponses, arborescences de reposts, schémas de co-publication inter-plateformes — sont utilisées pour étendre le graphe à partir des nœuds d'amorçage, en connectant les amplificateurs intermédiaires et les nœuds d'audience terminaux. Les poids des arêtes encodent le volume de contenu circulant entre les nœuds et la séquence temporelle des étapes de propagation.

Le graphe résultant sert deux objectifs opérationnels. Pour le flux réactif, il aide les opérateurs à identifier la topologie réseau de la campagne détectée — si le contenu provient d'un petit cluster coordonné ou a émergé de façon organique, et quels nœuds amplificateurs sont structurellement critiques pour la chaîne de propagation. Pour le flux d'évaluation, la même structure de graphe devient la base pour mesurer si les actions de contre-narratif ont effectivement perturbé la propagation, en comparant les métriques de topologie de graphe avant et après l'action.

Génération de Courses of Action via l'API Claude

Pour les détections qui dépassent le seuil d'alerte, le flux réactif génère automatiquement trois Courses of Action (CoA) structurées à l'aide de l'API Claude. Chaque CoA est un objet structuré contenant : un type d'action recommandée (publication de contre-narratif, contestation de l'attribution de la source, signalement d'abus de plateforme, engagement des leaders clés, silence/attente), un bref argumentaire avec une chaîne de raisonnement explicite, une contre-réaction prédite de la part des acteurs adverses, un score de risque d'escalade et un score de risque d'attribution le cas échéant.

Générer trois CoA plutôt qu'une seule recommandation est une décision de conception délibérée : elle préserve l'autonomie de l'opérateur en présentant l'espace de décision plutôt qu'en le réduisant à une seule recommandation de l'IA. Les traces de raisonnement sont exposées dans l'interface opérateur aux côtés de chaque CoA, et non cachées derrière le résultat. Les opérateurs peuvent déployer la trace pour voir le raisonnement en chaîne de pensée de l'API Claude avant d'accepter ou de rejeter un cours d'action.

Flux proactif : cartographie des segments d'audience et génération de campagnes

Là où le flux réactif répond aux menaces détectées, le flux proactif est initié par l'opérateur : à partir d'un objectif de communication défini, il génère un plan de campagne structuré avec plusieurs variantes et des effets cognitifs prédits. Le flux proactif est approprié pour les activités d'information planifiées — soutenir une publication d'affaires publiques, prépositionnner des contre-narratifs avant une opération adverse anticipée, ou coordonner la messagerie alliée sur plusieurs canaux gouvernementaux.

Le flux proactif commence par la cartographie des segments d'audience. Les opérateurs définissent les segments cibles à l'aide de l'interface géospatiale Leaflet / OpenStreetMap — en traçant des frontières géographiques sur une carte, en sélectionnant les profils démographiques et psychographiques applicables dans la bibliothèque de segments, et en étiquetant les attributs de langue et de contexte culturel. La définition du segment pilote à la fois la génération de campagne et les étapes d'adaptation du contenu qui suivent.

La génération de variantes de campagne est gérée par l'API Claude contre un modèle de prompt structuré qui inclut l'objectif de communication, le segment d'audience défini, l'environnement narratif actuel (tiré des détections actives du flux réactif pour les sujets de veille pertinents) et les contraintes spécifiées par l'opérateur (restrictions de contenu, thèmes de messagerie approuvés, affirmations prohibées). L'API génère trois variantes de campagne, chacune avec un cadrage primaire distinct, un ensemble de points d'argumentation de soutien et des effets cognitifs prédits ventilés par sous-segment d'audience.

Le modèle d'effets cognitifs prédits s'appuie sur les profils de segments d'audience pour estimer comment différents cadrages sont susceptibles d'être reçus par différentes sous-populations — non pas en tant que modèle prédictif précis, mais en tant que résultat de raisonnement structuré que les opérateurs peuvent évaluer et interroger. Les prédictions sont clairement étiquetées comme des évaluations générées par l'IA, et non comme des prévisions empiriques.

L'adaptation du contenu produit du contenu brouillon ciblé sur l'audience en trois variantes de registre pour chaque campagne : grand public (langage accessible, cadrage émotionnel approprié au profil d'audience), médias (factuel, citable, structuré pour un usage journalistique) et gouvernements alliés (formel, précis, aligné sur les conventions diplomatiques). Tout le contenu brouillon est conservé dans la file d'examen de l'opérateur et nécessite une approbation explicite avant toute livraison en aval.

Flux d'évaluation : corrélation d'engagement et analyse après action

Le flux d'évaluation clôt le cycle des effets en mesurant si les actions StratCom ont effectivement atteint leurs effets cognitifs visés. C'est le composant le plus souvent absent des outils d'opérations informationnelles — les plateformes qui génèrent du contenu fournissent rarement des mécanismes rigoureux pour mesurer ce que ce contenu a accompli.

La corrélation d'engagement est le mécanisme de mesure principal. Pour chaque produit StratCom approuvé et diffusé, le flux d'évaluation suit les signaux d'engagement (portée, réponse de sentiment, contre-amplification, partage secondaire) et les corrèle avec les métriques du graphe de propagation du narratif cible. Le moteur de corrélation compare la part narrative — la proportion de la discussion totale de l'audience capturée par le narratif surveillé par rapport aux contre-narratifs — avant et après l'intervention, en contrôlant la tendance de référence.

Le suivi de la part narrative est implémenté comme une métrique de séries temporelles stockée par sujet de veille, mise à jour à chaque cycle de scrutation par le pipeline du flux réactif. Le tableau de bord d'évaluation visualise la part narrative sous forme de courbe de tendance, avec les horodatages d'intervention superposés afin que les opérateurs puissent identifier quelles actions ont été corrélées avec des variations de part. La corrélation est observationnelle, non causale — la plateforme n'affirme pas qu'un contre-narratif a causé une réduction de la part narrative, seulement que la corrélation existait dans la fenêtre de mesure.

Conception de l'API backend .NET 8

Le backend est organisé comme une Web API ASP.NET Core avec une architecture de services modulaire. Les trois flux opérationnels sont implémentés en tant que services d'arrière-plan indépendants enregistrés avec l'hôte générique .NET, partageant une couche d'accès aux données commune mais opérant sur des files d'attente et des magasins d'état séparés. Cette séparation signifie qu'un délai ou une défaillance dans la génération de campagne du flux proactif ne bloque pas le pipeline de détection du flux réactif.

L'API REST est conforme à OpenAPI 3 et est documentée via Swashbuckle. Chaque endpoint est typé de bout en bout — les modèles de requête et de réponse sont partagés entre le backend et le frontend React via un client TypeScript généré, éliminant la classe de bogues d'intégration causés par la dérive de schéma entre le serveur API et le consommateur. L'API est authentifiée via des jetons bearer JWT avec un contrôle d'accès basé sur les rôles appliqué au niveau du contrôleur.

Le journal de décision — l'enregistrement immuable de chaque sortie générée par l'IA, action de l'opérateur, approbation et diffusion — est implémenté comme une table en ajout seul. Les opérations d'écriture dans le journal de décision utilisent la concurrence optimiste pour éviter les entrées dupliquées lors d'écritures concurrentes, et les lectures sont paginées et indexées par sujet de veille, opérateur et horodatage pour une récupération efficace après action.

Frontend React 18 avec TypeScript

Le frontend est une application monopage React 18 construite avec Vite et TypeScript, stylisée avec Tailwind CSS. La gestion d'état utilise React Query pour l'état serveur (files de détection, données d'évaluation, variantes de campagne) et le contexte React pour l'état UI (sujet de veille sélectionné, panneau actif). L'architecture évite un magasin côté client global pour les données serveur — le comportement d'invalidation de cache et de rechargement en arrière-plan de React Query est mieux adapté à la nature à forte interrogation du flux réactif qu'un magasin Zustand ou Redux manuel ne le serait.

Le rendu de graphe Cytoscape.js est isolé dans un composant dédié avec un wrapper React personnalisé qui gère l'initialisation du graphe, les mises à jour des données et le recalcul de la disposition en dehors du cycle de rendu de React — Cytoscape.js mute directement un élément canvas, et la réconciliation de cela avec le DOM virtuel de React nécessite une gestion soigneuse des frontières. Le recalcul de la disposition est mis en attente et effectué hors du thread principal lorsque le support du navigateur le permet.

Le composant géospatial Leaflet suit le même schéma : initialisé une fois, mis à jour impérativement via des refs, et encapsulé dans un composant React qui expose une interface déclarative pour définir les frontières de segment affichées et superposer les cartes thermiques de distribution narrative.

Intégration OpenTAKServer pour la livraison sur le terrain

Les produits StratCom approuvés sont livrés aux unités de terrain via une intégration OpenTAKServer. Lorsqu'un opérateur approuve une action de diffusion, le backend envoie un package de mission CoT (Cursor on Target) à l'instance OpenTAKServer configurée via son API REST. Les unités de terrain exécutant des applications compatibles TAK reçoivent le package sur leurs appareils sans nécessiter un canal de communication séparé ni de relais manuel de la part de l'équipe StratCom.

L'intégration est configurée dans le panneau d'administration de Narrative Shield : les opérateurs spécifient l'endpoint OpenTAKServer, les identifiants d'authentification et les groupes TAK qui doivent recevoir les packages pour chaque sujet de veille. Le contenu du package est formaté comme du texte structuré adapté à l'affichage sur le terrain — non pas des rapports de renseignement bruts, mais des points de discussion approuvés par l'opérateur et un résumé situationnel dans un format approprié pour l'audience tactique.

Pour une discussion plus large sur la manière dont les logiciels de défense gèrent les contraintes d'architecture mission-critique, notamment la tolérance aux pannes et le fonctionnement en mode dégradé, consultez notre vue d'ensemble de l'architecture. L'article sur les considérations de pipeline CI/CD pour les logiciels de défense couvre la discipline de build et de déploiement qui sous-tend le processus de publication de Narrative Shield.

Comment configurer un nouveau sujet de veille narratif dans Narrative Shield

Les étapes suivantes décrivent la configuration complète d'un nouveau sujet de veille, de la définition initiale de la taxonomie jusqu'à la revue après action de la première période opérationnelle.

Étape 1 : Définir le sujet de veille et la taxonomie de mots-clés. Accédez à Administration > Sujets de veille et créez un nouveau sujet. Saisissez un libellé descriptif et construisez la taxonomie de mots-clés couvrant les termes principaux, les expressions apparentées et les hashtags adverses connus. La taxonomie prend en charge les opérateurs booléens et les correspondances par caractère générique. Commencez large et affinez en fonction des 48 premières heures de résultats scorés.

Étape 2 : Configurer les pondérations du scoring de sévérité pour ce sujet. Ouvrez le panneau de configuration du scoring du sujet. Ajustez les curseurs de pondération des cinq facteurs pour refléter les priorités opérationnelles. Les modifications de pondération prennent effet lors des prochains cycles de scoring et ne rescorèrent pas rétroactivement les détections historiques.

Étape 3 : Définir le seuil de sévérité pour les alertes opérateur. Dans le panneau d'alerte, définissez le seuil d'indice de sévérité au-dessus duquel une détection déclenche une notification immédiate de l'opérateur. Le seuil par défaut de 65/100 convient à la plupart des sujets. Configurez le canal de notification et l'affectation de l'officier de permanence pour ce sujet de veille.

Étape 4 : Amorcer le graphe de propagation avec les comptes sources connus. Ajoutez les comptes adverses connus, les réseaux d'amplification et les clusters de coordination au Registre de sources du sujet. Ces nœuds d'amorçage initialisent le graphe de propagation Cytoscape.js lorsqu'une nouvelle détection se produit. Le registre accepte les identifiants de compte directs et peut être importé en masse via CSV.

Étape 5 : Cartographier le segment d'audience cible pour ce sujet. Ouvrez le panneau de cartographie des audiences, tracez une frontière géographique sur la carte Leaflet, sélectionnez les profils démographiques et psychographiques applicables, et associez le segment au sujet de veille. Cette définition de segment est utilisée à la fois par le flux réactif (scoring d'alignement sur l'audience cible) et par le flux proactif (génération de variantes de campagne).

Étape 6 : Activer le sujet et valider avec une détection de test. Définissez le statut du sujet sur Actif. Utilisez l'outil d'injection de test pour soumettre un signal synthétique correspondant à votre taxonomie de mots-clés, confirmez que le graphe de propagation s'initialise correctement et vérifiez qu'une alerte se déclenche si le score de sévérité synthétique dépasse votre seuil configuré.

Étape 7 : Examiner l'analyse après action au terme de la première période opérationnelle. Après 24 à 72 heures d'opération en direct, ouvrez le tableau de bord d'évaluation pour ce sujet. Examinez les graphiques de corrélation d'engagement, analysez les taux de faux positifs et ajustez la taxonomie ou les seuils en conséquence. Exportez le rapport après action et réintégrez les résultats dans la configuration du sujet de veille pour améliorer la précision du scoring futur.

Foire aux questions

+Quelle est la différence entre les flux réactif et proactif de Narrative Shield ?

Le flux réactif est une surveillance permanente : il ingère des signaux, score les narratifs détectés selon un modèle de sévérité à 5 facteurs, construit des graphes de chaîne de propagation et génère des Courses of Action structurées pour qu'un opérateur humain les examine. Le flux proactif est initié par l'opérateur : à partir d'un objectif de communication, il cartographie géospatialement les segments d'audience cible, génère plusieurs variantes de campagne avec des effets cognitifs prédits et produit du contenu adapté à l'audience — le tout avant qu'une menace ne se soit matérialisée.

+Comment fonctionne l'algorithme de scoring de sévérité à 5 facteurs ?

Chaque narratif détecté est évalué sur cinq dimensions indépendantes : la portée (audience estimée exposée), la vélocité (taux de propagation sur les plateformes et dans le temps), la polarité de sentiment (degré d'hostilité ou de nuisance envers l'entité surveillée), l'alignement sur l'audience cible (dans quelle mesure le narratif correspond aux populations cibles adverses connues) et la crédibilité de la source (score d'autorité des comptes d'origine et d'amplification). Les cinq scores de dimension sont pondérés et combinés en un indice de sévérité unique de 0 à 100. Les pondérations sont configurables par sujet de veille pour refléter les priorités opérationnelles.

+Narrative Shield remplace-t-il les officiers StratCom humains ?

Non. Narrative Shield est conçu explicitement autour d'une supervision humaine à chaque point de décision. La plateforme génère des Courses of Action et du contenu brouillon, mais aucun résultat n'est diffusé sans l'approbation de l'opérateur. Chaque sortie générée par l'IA est accompagnée d'une trace de raisonnement visible afin que les opérateurs puissent évaluer la logique sous-jacente, pas seulement la conclusion. Les horodatages de décision et les enregistrements d'approbation sont écrits dans un journal d'audit immuable.

+Comment fonctionne l'intégration avec OpenTAKServer ?

Narrative Shield expose un endpoint webhook qui envoie les produits StratCom approuvés — résumés de situation, points de contre-narratif et mises à jour des consignes — vers une instance OpenTAKServer sous forme de packages de mission CoT (Cursor on Target). Les unités de terrain reçoivent ces produits sur leurs appareils TAK sans nécessiter un canal de communication séparé ni de relais manuel. L'intégration utilise l'API REST standard d'OpenTAKServer et est configurée via le panneau d'administration de Narrative Shield.

+Quel cadre de conformité Narrative Shield suit-il pour l'utilisation de l'IA ?

Narrative Shield est conçu pour se conformer aux principes d'IA de l'OTAN : contrôle humain à chaque point de décision, transparence du raisonnement (toutes les sorties de l'API Claude incluent des traces de chaîne de pensée visibles), fiabilité grâce à des pipelines de scoring déterministes qui ne font pas varier les résultats pour une même entrée, sécurité grâce à la journalisation de toutes les actions et approbations, et responsabilité grâce à une provenance complète des décisions depuis l'ingestion du signal jusqu'à la diffusion approuvée.

Lectures complémentaires : Pour les concepts d'architecture fondamentaux qui sous-tendent le backend de Narrative Shield, consultez Architecture logicielle mission-critique pour la défense. L'ingénierie de déploiement et de pipeline derrière ce type de plateforme est couverte dans Construire un pipeline CI/CD renforcé pour les logiciels de défense. Pour le contexte sur les considérations générales de sélection de fournisseur lors de l'acquisition de plateformes StratCom ou de défense cognitive, consultez Comment choisir un fournisseur de développement de logiciels de défense.