Arrivés à la partie 3 de la boucle, les capteurs ont détecté, la fusion a pisté, et les opérateurs ont hiérarchisé les candidats devant eux. L'étape de désignation de la cible commence : lequel des candidats mérite d'être engagé, avec quelle priorité, sous quelles conditions, avec quelles ressources. C'est là que l'IA dans la défense est la moins mature, la plus controversée et la plus susceptible de décevoir quand on la survend. La partie 3 traite de la faire de manière crédible — construire des outils d'aide à la décision qui compriment la cognition de l'analyste sans franchir vers le ciblage autonome, avec les limites structurelles d'humain dans la boucle qu'exigent le procurement et la doctrine.
Le cadrage architectural reste la partie 1 : la boucle. L'ingénierie côté capteur est dans la partie 2. Cette partie couvre le milieu de la boucle.
Ce qu'est et n'est pas l'IA d'aide à la décision
L'expression « IA d'aide à la décision » est suffisamment large pour couvrir à la fois des capacités utiles et des dérives dangereuses. L'interprétation utile : une IA qui aide les analystes et les commandants à traiter plus d'informations, à évaluer plus d'options et à agir plus vite — tout en gardant la décision elle-même entre leurs mains. L'interprétation dangereuse : une IA qui recommande des actions d'une manière que les opérateurs acceptent sans évaluation indépendante, transférant de facto l'autorité de l'humain au modèle.
Le schéma structurel qui distingue les deux :
- L'aide à la décision utile fait remonter des preuves, hiérarchise les candidats, calcule des conséquences et présente des alternatives. L'opérateur voit le travail analytique mais exerce le jugement.
- L'aide à la décision dangereuse présente une seule recommandation avec une confiance élevée et un raisonnement exposé minimal, encourageant l'acceptation par l'opérateur sans examen.
Conséquence d'ingénierie : construire des outils qui montrent leur travail. Scores de confiance, preuves contributives, interprétations alternatives, sensibilité aux entrées. Chaque recommandation s'accompagne de la question « qu'est-ce qui changerait si l'entrée X était différente » dont l'IHM doit pouvoir donner la réponse. L'opérateur conserve l'autorité ; la plateforme conserve la transparence.
Listes d'engagements recommandés
La capacité phare d'aide à la décision dans le C2 moderne est la liste de candidats hiérarchisée — parfois appelée liste d'objectifs d'intérêt, liste d'engagements recommandés, ou sortie de priorisation de menaces selon la doctrine. L'IA classe les pistes selon un score composite et présente les N premiers aux opérateurs.
Le score composite combine plusieurs entrées : confiance de piste, certitude d'identité, correspondance à la taxonomie de priorité de menace, contexte opérationnel (dans la zone d'engagement, dans l'intention du commandant, dans les ROE), faisabilité d'engagement (disponibilité d'effecteurs, géométrie, timing) et facteurs de risque collatéral. Chaque entrée est un signal séparé calculé par un sous-système séparé ; le modèle de classement les combine en un score.
Les règles d'ingénierie qui distinguent les implémentations opérationnelles des implémentations de démonstration :
Décomposition du score. L'opérateur peut explorer le score de tout candidat et voir comment chaque composante a contribué. Un score élevé n'est pas une instruction — c'est un point de départ pour la revue de l'opérateur. Si l'opérateur écarte un candidat, le rejet alimente en retour le modèle de classement avec le raisonnement de l'opérateur s'il est fourni.
Pondération configurable. Les opérateurs (dans la limite de leur autorisation) peuvent ajuster le poids relatif des signaux d'entrée — plus de poids sur la certitude d'identité pour des environnements ambigus, plus de poids sur la priorité de menace pendant des opérations spécifiques. Les valeurs par défaut sont adaptées au rôle ; les dérogations sont journalisées.
Filtrage des pistes obsolètes. Les pistes dont l'état du cycle de vie s'estompe ou est perdu (voir Construire un système C2, partie 2) sont exclues de la liste de candidats ou visiblement signalées. Un engagement confiant contre une piste vieille de 90 secondes est exactement le type de mode de défaillance que les évaluateurs procurement cherchent spécifiquement.
Résultats négatifs visibles. La liste montre ce qui a été considéré et rejeté, pas seulement les N premiers. Si un opérateur se demande pourquoi une piste particulière n'a pas émergé, la réponse est dans la plateforme, non opaque.
Analyse de modes d'action
L'analyse de modes d'action (course-of-action, COA) au niveau des officiers d'état-major a historiquement été un processus à forte intensité de main-d'œuvre — les planificateurs proposent des options, les évaluateurs simulent les conséquences, les commandants choisissent. L'IA peut comprimer chaque étape.
Génération d'options. Étant donné une situation opérationnelle courante, générer des modes d'action candidats. Les contraintes (terrain, ROE, forces disponibles, horizon temporel) bornent l'espace de recherche. La sortie est un petit nombre d'options distinctes avec des exigences de ressources approximatives.
Simulation et évaluation. Pour chaque COA candidat, simuler les résultats face à des réponses adverses plausibles. Le Monte Carlo sur l'incertitude produit une distribution des résultats attendus. La fidélité du simulateur compte plus que son volume — un simulateur grossier qui capture les bonnes incertitudes l'emporte sur un simulateur haute fidélité qui rate les dimensions stratégiques.
Comparaison et recommandation. Classer les COA selon plusieurs critères (probabilité de succès de la mission, estimations de pertes, temps d'exécution, charge logistique, soutenabilité). La recommandation est une perspective ; l'évaluation du commandant en est une autre. La plateforme fait remonter les deux.
Réalité opérationnelle : l'IA de COA en est au stade pilote en 2026. Les simulateurs sont partiellement validés ; la génération d'options augmentée par LLM est impressionnante en démonstration et inconstante en opérations ; l'intégration au workflow d'état-major est sur mesure pour chaque plateforme. La capacité est suffisamment mûre pour être utilisée, suffisamment immature pour exiger une évaluation structurée. La vision honnête du marché est dans Paysage du marché de l'IA défense 2025.
Les LLM dans l'aide à la décision de défense
Les grands modèles de langage sont passés de l'expérimental à l'opérationnel dans des workflows analystes étroits depuis 2023. Les usages déployés de manière crédible en 2026 :
Rédaction de rapports de situation à partir d'entrées structurées. Le LLM convertit un ensemble de changements de pistes, de synthèses de renseignement et d'événements opérationnels en un récit cohérent. L'analyste révise et confirme avant publication. Plus rapide que la rédaction manuelle ; le jugement de l'analyste gouverne la publication.
Synthèse de produits de renseignement. Des collections de renseignement multi-sources (câbles, briefings, OSINT, bulletins de CSIRT partenaires) synthétisées en sorties prêtes pour le briefing. Le même schéma de revue avant publication s'applique.
Interrogation en langage naturel des entrepôts de renseignement. L'analyste tape une question ; le LLM la traduit en requête structurée contre l'entrepôt de données ; les résultats reviennent avec la chaîne des sources. La requête devient auditable, la réponse est ancrée dans des sources citables.
Traduction entre langues de coalition. Traduction spécifique au domaine pour la terminologie de défense. La sortie est vérifiée, non acceptée aveuglément.
Le schéma qui distingue l'usage opérationnel des LLM de l'usage spéculatif :
- La retrieval-augmented generation (RAG) ancrée dans des corpus vérifiés — le LLM ne peut rien dire qu'il ne puisse citer depuis le corpus.
- L'exigence de citation — chaque ligne de sortie remonte à un matériau source. Les opérateurs peuvent vérifier avant de s'appuyer dessus.
- Plafond strict sur la latitude opérationnelle — le LLM ne peut pas rédiger d'ordres de mission, de classifications ou d'autres actions opérationnelles. Il produit du texte pour revue humaine.
- Piste d'audit pour chaque artefact généré — quel prompt, quel modèle, quel corpus, quel horodatage, quel relecteur.
- Conscience des entrées adversariales — injection de prompt, tentatives de jailbreak, désinformation délibérée. Les défenses doivent être intégrées.
Le traitement d'ingénierie détaillé est dans Les LLM dans le triage du renseignement de défense.
Idée clé : une hallucination de LLM dans un contexte de service client est un embarras. Dans un contexte de défense, cela peut être un incident stratégique. L'ingénierie défensive est structurelle : retrieval-augmented generation, exigences de citation, périmètre opérationnel restreint, pistes d'audit. Tout déploiement de LLM sans ces éléments est un risque de procurement ; tout déploiement qui les inclut est un multiplicateur de capacité significatif.
Analyse de comportements (PoL) et détection d'anomalies
L'étape Décider bénéficie énormément du contexte de fond. Savoir qu'un navire particulier fait toujours escale dans trois ports spécifiques, puis dévie soudainement vers un quatrième, est une information d'aide à la décision de haute valeur. L'analyse de comportements (pattern-of-life, PoL) pilotée par l'IA fait remonter ce contexte automatiquement.
Le schéma : ingérer des données de pistes longitudinales sur des mois ou des années ; segmenter en comportements de routine par entité ; scorer les nouvelles observations par rapport à la ligne de base de routine ; faire remonter les écarts aux opérateurs. La partie difficile n'est pas l'algorithme — mélanges gaussiens, modèles de Markov cachés, classificateurs à gradient boosting fonctionnent tous — mais la curation des données, la définition opérationnelle de « anormal » et la revue éthique autour du profilage comportemental. Le traitement détaillé est dans Analyse de comportements (PoL) dans le renseignement militaire.
La valeur opérationnelle réside dans le classement — non dans la remontée des anomalies (qui sont fréquentes et le plus souvent bénignes) mais dans la priorisation qui place celles, peu nombreuses, qui comptent en tête de la file d'attente de l'analyste. Un système PoL qui fait remonter 200 anomalies par heure est inutilisable ; un qui classe les cinq premières et explique pourquoi est irremplaçable.
UX opérateur : où vit l'IA dans le workflow
L'IA d'aide à la décision vit à l'intérieur d'un workflow opérateur. Si l'IA exige que l'opérateur quitte la COP, ouvre un outil séparé et recontextualise sa pensée, l'IA perd. L'intégration doit être dans le workflow, dans le contexte, dans la bande avec le schéma existant de l'opérateur.
Les schémas qui fonctionnent en pratique :
Annotations en ligne sur la COP. Les attributs dérivés de l'IA — score de confiance, priorité recommandée, anomalie détectée — sont rendus comme des modificateurs de symboles sur l'affichage COP existant. L'œil de l'opérateur est déjà là.
Panneaux d'exploration. Un clic sur toute annotation générée par l'IA ouvre un panneau montrant les preuves sous-jacentes : données de piste d'entrée, décomposition de la confiance du modèle, signaux sources. L'opérateur peut confirmer ou écarter avec l'information complète.
Recommandations intégrées au workflow. Quand l'opérateur compose un ordre de mission, l'IA fait remonter les schémas historiques pertinents. Quand l'opérateur examine un engagement candidat, l'IA fait remonter les facteurs de risque collatéral. L'IA est présente là où le travail cognitif a lieu, pas dans un onglet séparé.
Portes de consentement explicites. Là où la recommandation de l'IA franchit un seuil (un nouvel engagement, une escalade, une action à conséquence opérationnelle), la porte est explicite et visible. L'opérateur confirme ; la plateforme enregistre.
Les principes plus larges d'UX opérateur pour les logiciels de défense, y compris les réalités des environnements durcis, sont dans UX durcie pour les opérateurs militaires.
Implications pour l'accréditation
L'IA d'aide à la décision est plus difficile à accréditer que l'IA côté capteur. La raison est la proximité avec des décisions à conséquences. Un évaluateur d'accréditation demandera : sous quelles conditions cet outil pourrait-il induire un opérateur à prendre une action qu'il ne prendrait pas autrement ? Quelles preuves démontrent que les opérateurs conservent un jugement effectif quand cet outil est actif ?
Les preuves que les évaluateurs d'accréditation jugent crédibles :
- Résultats de test opérateur-dans-la-boucle montrant des scénarios de mission réalistes avec l'outil actif et l'outil absent, comparant la qualité de décision.
- Audits de biais — l'outil favorise-t-il systématiquement certains types de cibles, certaines géographies, certains attributs d'identité ?
- Évaluation de robustesse adversariale — que se passe-t-il sous manipulation délibérée des entrées ?
- Analyse des modes de défaillance — que fait l'outil sous dérive de modèle, dégradation de capteur ou entrées hors distribution ?
- Surveillance de la dérive en déploiement opérationnel — preuve quantitative que le comportement de l'outil reste dans l'enveloppe accréditée.
La discipline de niveau procurement consistant à générer ces preuves comme effet secondaire du pipeline de développement est dans DevSecOps pour les pipelines de défense. Le cadrage plus large de ces exigences par la stratégie IA de l'OTAN est dans La stratégie IA de l'OTAN pour les logiciels de défense.
Et la suite
La partie 3 a couvert l'IA de l'étape de désignation de la cible. Listes de candidats, analyse de modes d'action, outillage analyste augmenté par LLM, analyse de comportements (PoL) comme contexte de fond, intégration UX opérateur, exigences d'accréditation. La plateforme produit désormais des sorties d'aide à la décision que les opérateurs peuvent utiliser sans perdre le jugement.
La partie 4 ferme la boucle. Comment l'IA participe à l'engagement et à l'évaluation sans franchir la ligne des effets autonomes, les limites HITL structurelles codées dans la plateforme, les réalités de doctrine et de procurement qui fixent la frontière en place, et où l'ingénierie rencontre le droit international humanitaire.