Logistique et chaîne d'approvisionnement

Logiciel de gestion de l'ouverture de théâtre et du soutien

Par Équipe d'ingénierie Corvus Intelligence · À propos de l'équipe →

24 juin 2026 10 min de lecture

L'ouverture de théâtre est la phase la plus exigeante sur le plan logistique de tout déploiement de force majeur. Avant que la première unité de combat puisse être engagée dans les opérations, un volume considérable de personnel, d'équipements, de carburant, de munitions et de stocks de soutien doit transiter par un ensemble limité de points d'entrée stratégiques — ports et aérodromes — vers un théâtre qui peut disposer d'infrastructures limitées, d'un espace aérien contesté et d'un adversaire cherchant activement à perturber la montée en puissance. Le logiciel qui gère ce flux détermine si une force arrive prête au combat ou arrive de manière dispersée, sous-équipée et opérationnellement vulnérable.

Le logiciel de gestion du soutien en théâtre n'est pas un ERP commercial habillé en tenue militaire. Il doit gérer la gestion des manifestes de fret et le débit aux ports de débarquement où des centaines de conteneurs arrivent chaque jour, planifier un réseau de distribution qui n'existe pas encore au début des opérations, arbitrer entre les modèles logistiques push et pull à mesure que la situation opérationnelle évolue, et assurer la visibilité sur tous les échelons d'un théâtre pouvant s'étendre sur des centaines de kilomètres. Cet article décrit l'architecture des systèmes logiciels capables de gérer chaque phase de ce défi.

Logistique d'ouverture de théâtre : du navire à la première ligne

L'ouverture de théâtre englobe la réception, la mise en attente, le mouvement ultérieur et l'intégration (RSOI) des forces et de leurs approvisionnements de soutien dans un théâtre opérationnel. Chaque phase impose des exigences distinctes au système d'information de soutien.

La réception se produit au port de débarquement — le port maritime (SPOD) ou l'aérodrome (APOD) où le transport stratégique livre la force. Dans un port maritime, les navires ro-ro (roll-on/roll-off) déchargent les véhicules à roues et les engins chenillés directement sur le quai ; les porte-conteneurs déchargent des boîtes ISO par grues vers les zones de regroupement. Sur un aérodrome, les avions C-17, C-130 ou les aéronefs de transport alliés se garent sur les aires pour un déchargement rapide avant que la vague suivante n'ait besoin de l'espace. La réception est limitée par le nombre de postes à quai, la capacité des grues, le stationnement sur les aires et les taux de dédouanement — que le logiciel de soutien doit modéliser comme paramètres de capacité.

La mise en attente consiste à regrouper le fret déchargé dans la zone de mise en attente portuaire en attendant le mouvement ultérieur. Les véhicules arrivant sans équipages, les conteneurs arrivant avant leur unité mère et les équipements en attente d'inspection douanière s'accumulent en zone de mise en attente. Une mauvaise gestion de cette phase — zone insuffisante, responsabilité peu claire, suivi inadéquat — crée la congestion portuaire qui a historiquement retardé les ouvertures de théâtre de plusieurs jours ou semaines. Un logiciel qui suit chaque unité de chargement dans la zone de mise en attente avec RFID ou code-barres, et qui signale les dépassements de temps de séjour, est le principal outil pour prévenir cette congestion.

Le mouvement ultérieur est le déplacement en convoi, par voie ferrée ou aérienne du fret mis en attente depuis le POD vers la zone d'assemblage tactique (TAA) où les unités se regroupent avant leur engagement dans les opérations. Le mouvement ultérieur est planifié selon la séquence du TPFDD (Time-Phased Force and Deployment Data) — les unités ayant des engagements opérationnels antérieurs ont la priorité pour le mouvement ultérieur indépendamment du moment où leur fret arrive au port.

L'intégration est la phase finale, où les équipements, munitions, carburant et rations arrivés séparément sont mariés avec leurs unités mères dans la TAA afin que l'unité puisse procéder aux inspections de disponibilité et se déclarer disponible pour les opérations.

L'exigence logicielle critique couvrant les quatre phases est un enregistrement unique pour chaque TCN (Transportation Control Number) — l'identifiant DoD pour une unité de chargement — qui suit son état tout au long du pipeline RSOI. Sans cela, le commandement de soutien en théâtre ne peut pas répondre à la question la plus fondamentale : où se trouve le fret X et quand atteindra-t-il l'unité Y ?

Logiciel de gestion du port de débarquement

Le logiciel de gestion du port de débarquement gère la phase de réception au point d'entrée. Ses fonctions principales sont la gestion des manifestes de fret, le suivi du débit, le suivi RFID et la gestion des douanes et des matières dangereuses.

La gestion des manifestes de fret ingère le manifeste de fret du navire ou de l'aéronef, le compare avec le TPFDD et crée un enregistrement TCN pour chaque unité de chargement. L'intégration des manifestes doit gérer la réalité que ceux-ci arrivent sous plusieurs formats : les chargements étiquetés RFID produisent des listes TCN automatisées via le système ITV (In-Transit Visibility) ; le fret plus ancien peut arriver avec des manifestes papier nécessitant une saisie manuelle. Le logiciel doit gérer les deux sans créer d'enregistrements TCN en double.

Un enregistrement TCN typique dans le système de gestion du POD contient :

{
  "tcn":          "T2AABC1234567",
  "unit_id":      "1-68AR",
  "nsn":          "2350-01-523-5947",
  "description":  "TANK, COMBAT, FULL TRACKED: M1A2 SEPv3",
  "quantity":     1,
  "unit_of_issue":"EA",
  "gross_weight_kg": 62000,
  "hazmat_class": null,
  "tpfdd_arrival": "2026-06-24T06:00:00Z",
  "actual_arrival": "2026-06-24T08:14:00Z",
  "rsoi_state":   "STAGING",
  "staging_area": "YARD-BRAVO",
  "staging_since": "2026-06-24T10:30:00Z",
  "priority":     1,
  "onward_destination": "TAA-NORTH"
}

Le suivi du débit mesure le taux de traitement réel du port par rapport au taux prévu issu du TPFDD. Si le plan exige 5 000 tonnes courtes par jour transitant par le SPOD pour respecter le calendrier de fermeture de la force, et que le débit réel est de 3 800 tonnes par jour, le logiciel doit faire remonter cet écart et projeter le retard résultant sur la fermeture de la force afin que le commandement de soutien en théâtre puisse prendre des mesures correctives — ajouter des équipes de grue, demander des ressources de camionnage supplémentaires ou ajuster les séquences de priorité des unités.

Le suivi RFID au POD utilise des portiques de lecture RFID UHF passifs (ISO 18000-6C, EPC Gen 2) installés aux points de passage clés du port. Chaque unité de chargement étiquetée — conteneur, palette ou véhicule — est lue automatiquement lorsqu'elle passe par les zones de déchargement par grue, les portails de la zone de mise en attente et les portails de sortie du port. La lecture du portique génère un événement horodaté qui fait avancer l'état RSOI du TCN dans la base de données sans aucune saisie manuelle. Les TCN résiduels non lus (ceux dont les étiquettes ont été endommagées ou non lues lors d'un dysfonctionnement du portique) sont traités par lecture manuelle à la fin de chaque équipe.

Le traitement des matières dangereuses et des douanes ajoute un flux de travail parallèle : les conteneurs contenant des marchandises de classe 1 (explosifs), classe 3 (liquides inflammables) ou classe 9 (matières dangereuses diverses) nécessitent des zones de mise en attente séparées et des autorisations de manutention spéciale. Le logiciel applique les affectations de zones de mise en attente selon la classe HAZMAT et génère la documentation HAZMAT requise pour les autorités douanières du pays hôte.

Planification du réseau de distribution

Une fois le fret sorti de la zone de mise en attente portuaire, il doit transiter par un réseau de distribution que le commandement de soutien en théâtre construit en parallèle avec l'arrivée de la force opérationnelle. Le réseau de distribution relie le POD aux points d'approvisionnement avancés par une série de nœuds logistiques intermédiaires, chacun détenant des stocks appropriés à son échelon.

L'architecture standard de distribution en théâtre utilise trois nœuds de niveau échelon :

Nœud	Échelon	Capacité typique	Classes d'approvisionnement principales
Theater Distribution Base (TDB)	Théâtre	30–90 jours	I, II, III, IV, V, VIII, IX
Combat Sustainment Support Bn (CSSB)	Division	7–15 jours	I, III, V, IX haute demande
Brigade Support Bn (BSB)	Brigade	3–5 jours	I, III, V charges prescrites

Transport longue distance vs transport local est la décision fondamentale de planification de la distribution à chaque frontière d'échelon. Le transport longue distance est le mouvement en vrac depuis le dépôt de théâtre vers la zone de soutien divisionnaire en utilisant des actifs de camionnage longue distance dédiés (PLS flat-rack, HET pour les équipements lourds). Le transport local est la livraison finale depuis la zone de soutien divisionnaire vers les points d'approvisionnement de brigade en utilisant le transport organique des unités. Les actifs de transport longue distance sont rares et doivent être programmés pour maximiser les tonnes-kilomètres par véhicule par jour ; le transport local est limité par la densité de camions organiques des unités soutenues et par les considérations de sécurité des itinéraires tactiques.

Le logiciel de planification du réseau de distribution modélise les itinéraires de transport entre les nœuds comme un graphe orienté avec des attributs de capacité et de temps de trajet. Le modèle de réseau permet au logiciel de calculer :

# Vérification de capacité d'itinéraire (pseudo-code)
def check_route_capacity(route_id, planned_tons_per_day):
    route = network.get_route(route_id)
    constraints = [
        route.bridge_classification,    # MLC pour franchissement
        route.surface_type,             # MSR, ASR, piste
        route.current_status,           # OUVERT / RESTREINT / FERMÉ
        route.max_tons_per_day          # capacité de contrôle du trafic
    ]
    available_capacity = min(
        c.effective_capacity() for c in constraints
    )
    utilization = planned_tons_per_day / available_capacity
    if utilization > 0.85:
        raise CapacityWarning(
            f"Itinéraire {route_id}: {utilization:.0%} de la capacité."
            " Itinéraire alternatif requis."
        )
    return utilization

Les décisions de positionnement des BSA, CSA et ASA — où placer les nœuds logistiques à mesure que la situation tactique évolue — sont éclairées par l'analyse de sensibilité du modèle de réseau. Déplacer une BSA de 20 km vers l'avant peut réduire les temps de transport local mais augmente sa vulnérabilité et nécessite un nouveau segment de transport longue distance. Le logiciel doit permettre aux planificateurs d'évaluer des positions de nœuds alternatives en mettant à jour les coordonnées de nœuds et en recalculant le modèle de coût du réseau, révélant les compromis en termes de délai de livraison, de distance d'itinéraire et d'utilisation des véhicules avant que les positions ne soient confirmées.

Modèles de soutien push vs pull

Le choix entre logistique push et pull n'est pas binaire — c'est une politique dynamique qui évolue selon la classe d'approvisionnement, la phase de l'opération et la maturité du réseau de distribution. Le logiciel de soutien en théâtre doit implémenter les deux modèles et prendre en charge la transition entre eux.

La logistique push envoie des ensembles préconfigurés d'approvisionnements aux unités selon un calendrier sans que celles-ci aient besoin de soumettre des réquisitions. Lors de l'ouverture de théâtre, le push est la norme pour les classes I (rations), III(B) (pétrole en vrac) et l'eau, car le système d'approvisionnement de l'unité peut ne pas encore être opérationnel, les communications radio peuvent être limitées et les taux de consommation standard sont suffisamment prévisibles pour planifier des stocks pré-positionnés. Une liste de charge prescrite (PLL) pour un bataillon mécanisé spécifie les quantités standard de pièces de rechange de classe IX ; un ensemble push pour un bataillon nouvellement arrivé est construit à partir de cette PLL et expédié à mesure que l'unité arrive dans sa TAA.

La logistique pull est axée sur la demande : les unités soumettent des réquisitions pour des articles spécifiques et le système d'approvisionnement traite et expédie contre ces réquisitions. Le pull est plus précis que le push — il répond à la consommation réelle plutôt qu'estimée — mais nécessite des systèmes de communication fonctionnels et une structure d'administration des approvisionnements au niveau de l'unité. Le pull devient le modèle dominant une fois la force établie et le système de distribution en régime établi.

Le logiciel de chaîne d'approvisionnement de défense doit implémenter push et pull comme des flux de travail distincts mais intégrés. Les ensembles push sont planifiés au niveau du commandement de soutien et expédiés sans action des unités ; les réquisitions pull proviennent du niveau de l'unité et remontent le système d'approvisionnement. Une approche hybride — pousser automatiquement le lot quotidien de classe I mais exiger des réquisitions pull pour les pièces de rechange de classe IX — est la pratique standard dans la plupart des plans opérationnels de théâtre.

La fonctionnalité logicielle critique pour gérer la transition push vers pull est un mécanisme de suivi de la consommation qui détecte quand la consommation réelle de classe IX diverge des hypothèses de l'ensemble push. Si les unités tirent des pièces de rechange au double du taux prévu, la quantité de l'ensemble push est insuffisante et l'écart doit être comblé par des réquisitions pull réactives. Le logiciel doit signaler cette divergence automatiquement, sans s'appuyer sur l'analyse manuelle de l'officier d'approvisionnement.

Contrôle du flux de soutien : la COP logistique de théâtre

La situation tactique commune logistique de théâtre (LCOP) est l'affichage intégré qui donne au commandement de soutien en théâtre une visibilité sur l'ensemble du flux de soutien — depuis le fret encore à bord des navires en mer, à travers le POD, à travers le réseau de distribution, jusqu'aux jours d'approvisionnement au niveau de l'unité. C'est le principal outil de contrôle du flux : identifier où le pipeline de soutien est congestionné et rediriger les actifs pour éliminer la congestion.

La plateforme de visibilité logistique militaire qui sous-tend la LCOP intègre des données de plusieurs sources :

Système ITV (In-Transit Visibility) — données de suivi RFID et GPS pour tous les actifs étiquetés dans le pipeline de distribution
Système de débit POD — débit journalier du port, taux de remplissage de la zone de mise en attente, temps de séjour
Rapports de statut d'approvisionnement des unités — jours d'approvisionnement disponibles par classe, soumis quotidiennement par les sections S4 des unités
Statut des actifs de distribution — disponibilité des camions, taux d'utilisation des PLS et HET
Statut des itinéraires — itinéraire ouvert/restreint/fermé, mis à jour à partir de la COP et des rapports de reconnaissance d'itinéraire

La LCOP présente ces données sur un affichage géospatial avec une symbologie spécifique à la logistique (symboles logistiques MIL-STD-2525 pour les points d'approvisionnement, les zones de maintenance, les installations médicales) et un ensemble de couches de statut d'approvisionnement qui codifient par couleur les emplacements des unités selon les jours d'approvisionnement — vert pour un stock adéquat, orange pour marginal, rouge pour une pénurie critique. Le personnel J4 peut voir d'un coup d'œil quelles unités risquent une défaillance du soutien et quels itinéraires de distribution sont disponibles pour les atteindre.

Les actions de contrôle du flux effectuées via la LCOP comprennent : la re-priorisation des sorties de camions pour soutenir les unités en pénurie critique, la déviation du fret en transit d'un itinéraire congestionné vers un itinéraire alternatif, la mise en œuvre du réapprovisionnement aérien (élingage CH-47 ou UH-60) pour atteindre les unités coupées de la distribution terrestre, et l'ajustement du calendrier des ensembles push pour éviter de dépasser la capacité journalière du système de distribution.

Intégration avec les systèmes de mobilité stratégique

Le logiciel de soutien en théâtre n'opère pas de manière isolée — il reçoit le plan de déploiement des systèmes stratégiques et leur renvoie les données d'exécution. Les points d'intégration clés sont JOPES, TCAIMS-II et LOGFAS pour les partenaires de coalition.

JOPES (Joint Operation Planning and Execution System) est la source faisant autorité pour le TPFDD — la séquence de déploiement spécifiant quelles unités se déplacent quand, avec quel équipement, sur quel transport stratégique. Le logiciel de soutien en théâtre ingère le TPFDD pour construire le calendrier d'arrivée prévu au POD. Lorsque les arrivées réelles dévient du TPFDD (navires retardés par la météo, aéronefs déviés), le système calcule l'impact sur la date de disponibilité opérationnelle de l'unité et le signale pour évaluation J4.

TCAIMS-II (Transportation Coordinator's Automated Information for Movements System II) gère la fonction de contrôle des mouvements : attribution des transports stratégiques aux unités, gestion des autorisations de convois et suivi des demandes de mouvement jusqu'à leur exécution. Le logiciel de soutien en théâtre s'interface avec TCAIMS-II pour recevoir les autorisations de convois approuvées et signaler la réalisation effective des convois, bouclant ainsi la boucle de contrôle des mouvements.

LOGFAS (Logistics Functional Area Services) est l'équivalent coalition pour les alliés européens. Les normes de rapport logistique de l'OTAN que LOGFAS implémente utilisent des modèles de données différents des transactions US DLMS — numéros de stock OTAN versus NSN, différentes conventions d'unité d'émission et différents formats de message. Un système de soutien en théâtre de coalition doit implémenter une couche de traduction qui convertit entre les formats de transaction logistique US (DLMS 856 avis d'expédition avancé, DLMS 832 catalogue prix/ventes) et leurs équivalents LOGFAS. La couche de traduction doit préserver l'équivalence sémantique — pas seulement la correspondance de champs mais l'interprétation correcte des conventions de quantité, d'unité d'émission et de classification entre partenaires de l'alliance.

# Comparaison arrivée TPFDD vs réelle
SELECT
    t.tcn,
    t.unit_id,
    t.tpfdd_arrival::date          AS planned_arrival,
    t.actual_arrival::date         AS actual_arrival,
    (t.actual_arrival - t.tpfdd_arrival)
        / INTERVAL '1 day'        AS variance_days,
    t.priority,
    t.onward_destination
FROM tcn_records t
WHERE t.rsoi_state IN ('POD_ARRIVED','STAGING')
  AND t.actual_arrival IS NOT NULL
ORDER BY ABS(
    EXTRACT(EPOCH FROM (t.actual_arrival - t.tpfdd_arrival))
) DESC
LIMIT 50;

Métriques de soutien et rapports de disponibilité opérationnelle

Le commandement de soutien en théâtre rend compte quotidiennement au personnel logistique interarmées (J4) du statut de soutien du théâtre. Ces rapports sont le principal mécanisme permettant au commandant opérationnel d'évaluer si la base de soutien peut prendre en charge les opérations planifiées. Les générer manuellement à partir de sources de données disparates — journaux de débit portuaire, messages de statut d'approvisionnement des unités, rapports d'achèvement des convois — est chronophage et source d'erreurs. Le logiciel de soutien en théâtre automatise cette génération de rapports à partir de données continuellement mises à jour.

Les métriques de soutien critiques sont :

Taux de débit portuaire — tonnes courtes évacuées du POD par jour, mesurées par rapport au taux planifié requis pour respecter la fermeture de la force. L'écart par rapport au plan se cumule : un port fonctionnant à 80 % du débit planifié pendant cinq jours accumule un déficit équivalent à la cargaison d'un navire complet, retardant la fermeture de la force d'un cycle de déchargement entier.

Délai de réponse d'approvisionnement (SRT) — temps écoulé depuis la soumission d'une réquisition d'unité jusqu'à la disponibilité de l'article au point d'approvisionnement de l'unité. La décomposition du SRT — en séparant le temps de traitement des réquisitions, le temps d'émission, le temps de transport et le temps de réception — identifie quel composant de la chaîne de livraison constitue le goulot d'étranglement. Un long temps de transport peut indiquer des actifs de camionnage insuffisants ; un long temps d'émission peut indiquer un point d'approvisionnement opérant sans gestion automatisée des entrepôts.

Remplissage du pipeline par classe d'approvisionnement — la quantité totale de chaque classe d'approvisionnement actuellement dans le pipeline de distribution (en transit mais pas encore à une unité). Le remplissage du pipeline détermine quelle marge existe entre la position disponible actuelle et une pénurie. Un remplissage du pipeline inférieur à cinq jours pour la classe III(P) (pétrole conditionné) au niveau BSA indique un risque lors d'opérations à tempo élevé pouvant dépasser les cycles de livraison.

Jours d'approvisionnement (DOS) disponibles — la métrique de soutien la plus largement rapportée, calculée par unité et par classe d'approvisionnement à partir du rapport de statut d'approvisionnement quotidien de l'unité. Le commandement de soutien exige de chaque unité qu'elle maintienne un seuil minimum de DOS (typiquement 3 DOS pour les classes I et III au niveau compagnie, 5 DOS au niveau bataillon) — les unités en dessous du seuil génèrent des actions de réapprovisionnement automatiques.

Le rapport d'estimation de soutien automatisé agrège ces métriques avec des lignes de tendance et génère un briefing quotidien structuré :

ESTIMATION DE SOUTIEN EN THÉÂTRE — 24 JUN 2026 / 0600L
─────────────────────────────────────────────────────
STATUT POD (SPOD ALPHA)
  Débit (dernières 24h):   4 840 T  [Plan: 5 200 T  ▼ −7%]
  Remplissage zone att.:    68% / 100% capacité
  Fret séjour > 24h:        142 TCN   ← ACTION REQUISE
  Navires à quai:           3 (USNS Gilliland, ARC Endurance, MV Resolve)
  Navires en rade:          1 (ETA poste 25 JUN 0200L)

PIPELINE DE DISTRIBUTION
  Classe I (Rations):      4,2 DOS moyenne sur BCTs   [Vert]
  Classe III(B) (Vrac):    5,1 DOS au TDB; 3,8 DOS BSB   [Orange]
  Classe V (Munitions):    Remplissage pipeline 8,5K T    [Vert]
  Classe IX (Pièces):      SRT moy 38h   [Plan: 24h  ▼ +58%]

ITINÉRAIRES DE DISTRIBUTION
  MSR IOWA:      OUVERT (confirmé 0400L)
  ASR COLUMBIA:  RESTREINT (réparation pont, MLC 50 max)
  ASR DECKER:    OUVERT

UNITÉS À RISQUE (< 3 DOS sur toute classe):
  2-7 CAV (Classe III): 2,1 DOS — réapprovisionnement d'urgence expédié
─────────────────────────────────────────────────────

L'alerte de séjour de fret dans l'exemple ci-dessus — 142 TCN en zone de mise en attente depuis plus de 24 heures — serait invisible dans un système manuel jusqu'à ce qu'un inventaire physique découvre le fret bloqué. Dans les opérations POD gérées par logiciel, l'alerte apparaît dans les minutes suivant le franchissement du seuil de séjour, permettant à l'OIC du port d'enquêter et d'éliminer le goulot d'étranglement avant qu'il ne se transforme en congestion générale de la zone de mise en attente.

Principe de conception : Le logiciel de soutien en théâtre doit rendre visible l'exception, pas la norme. Le personnel J4 ne doit pas perdre de temps à lire des rapports de routine pour découvrir que le débit est conforme au plan et que les DOS sont adéquats — le système doit présenter uniquement les écarts par rapport au plan, les unités à risque et les actions spécifiques requises. Un tableau de bord de soutien bien conçu est principalement vert, avec des éléments orange et rouge qui déclenchent une action immédiate. L'objectif est de réduire le temps de cycle décisionnel au niveau du commandement de soutien, et non de générer des rapports exhaustifs pour leur propre intérêt.

Discuter de votre projet

Nous développons des logiciels de logistique militaire — gestion du soutien en théâtre, planification de la distribution et systèmes de débit POD pour les organisations de défense.

Logiciels logistiques → Développement C2 →

Cette analyse a été préparée par les ingénieurs de Corvus Intelligence qui développent des logiciels critiques pour les organisations de défense et gouvernementales. En savoir plus sur notre équipe →

Questions fréquemment posées

Quelle est la différence entre un port d'embarquement et un port de débarquement dans la logistique militaire ?

Un port d'embarquement (POE) est le point d'origine où les forces et les équipements sont chargés sur du transport stratégique — aéronefs ou navires de transport maritime — pour commencer le déplacement vers un théâtre d'opérations. Un port de débarquement (POD) est le point de destination où les forces et les équipements arrivent dans le théâtre et sont déchargés pour le mouvement ultérieur vers les zones tactiques. La gestion du POD est le point de passage critique pour l'ouverture de théâtre car l'ensemble de la force et ses approvisionnements de soutien doivent transiter par un nombre limité de points d'entrée portuaires ou aéroportuaires. Le logiciel de soutien en théâtre doit modéliser la capacité du POD et déconflictualiser la séquence d'arrivée pour prévenir la congestion qui ralentit la montée en puissance.

Quelles données de manifeste de fret le logiciel de soutien en théâtre doit-il capturer au POD ?

Au minimum : le numéro de contrôle de transport (TCN) pour chaque unité de chargement, le numéro de stock national (NSN) ou l'identifiant de ligne d'article, l'unité d'émission et la quantité, l'unité propriétaire et la priorité, le poids brut et le volume, la classification des matières dangereuses (classe HAZMAT pour les munitions, le carburant et les produits chimiques), la sensibilité à la température (pour les articles médicaux de classe VIII) et la destination prévue du mouvement ultérieur. Les données du manifeste doivent être recoupées avec la base de données de déploiement (JOPES TPFDD) afin que le fret arrivant au POD puisse être comparé à ce qui était planifié, avec les écarts automatiquement signalés au CARGO-OIC pour résolution.

Comment fonctionne le suivi RFID dans un port militaire de débarquement ?

Des étiquettes RFID UHF passives (ISO 18000-6C / EPC Gen 2) sont appliquées aux unités de chargement, conteneurs et palettes avant le départ du POE. Des portiques de lecture RFID fixes sont installés à l'entrée du portail du POD, au point de déchargement par grue, aux limites de la zone de mise en attente et aux portails de sortie. À mesure que le fret étiqueté passe par chaque point de lecture, le TCN est enregistré avec horodatage et emplacement et envoyé au système de visibilité des actifs de théâtre. La séquence de lectures établit une chaîne de garde et génère des mises à jour de statut automatisées sans saisie manuelle. Les taux de lecture RFID aux portiques actifs atteignent généralement 99,8 % pour les charges UHF correctement étiquetées ; les 0,2 % résiduels sont récupérés par lecture manuelle.

Quelle est la différence entre une BSA, une CSA et une ASA dans la distribution en théâtre ?

Une Brigade Support Area (BSA) est le hub logistique d'une équipe de combat de brigade, contenant les actifs de distribution, maintenance, médicaux et transport du bataillon de soutien de brigade. Un Combat Sustainment Support Battalion (CSSB) au niveau division opère depuis une Division Support Area (DSA). Un Theater Sustainment Command (TSC) ou une Brigade de soutien opère des points d'approvisionnement aérien (ASP) ou des zones de soutien aux services de combat (CSSA) au niveau théâtre pour les munitions et le carburant. Le logiciel de soutien en théâtre doit modéliser les relations et la capacité de débit de chaque nœud afin que les demandes de réapprovisionnement soient acheminées vers l'échelon approprié et que les actifs de distribution ne soient pas engagés dans des trajets contournant inutilement les échelons intermédiaires.

Quand un système logistique de théâtre doit-il utiliser la logistique push plutôt que pull ?

La logistique push est la plus appropriée lors de l'ouverture de théâtre, lorsque les unités rejoignent le théâtre et n'ont pas encore établi des communications fiables pour le traitement des réquisitions, et pour les classes I (rations) et III (carburant en vrac) où les taux de consommation journaliers standard sont bien compris. La logistique pull est appropriée une fois les unités établies, les données de consommation disponibles et le réseau de distribution fonctionnel. Un modèle hybride est la norme : push pour les classes I et III, pull pour les classes IX (pièces de rechange) et VIII (médical), avec les classes II et IV gérées en push lors de la montée en puissance initiale et en transition vers le pull à mesure que la continuité des officiers d'approvisionnement s'améliore.

Que présente une situation tactique commune logistique de théâtre ?

La COP logistique de théâtre intègre la localisation des actifs, le statut des approvisionnements et le statut du réseau de distribution sur un seul affichage géospatial. Les couches clés comprennent : les emplacements des nœuds logistiques et leur statut opérationnel, les pistes des actifs en transit avec TCN et heure d'arrivée estimée, le statut d'approvisionnement des unités par classe (jours d'approvisionnement disponibles ou en route), les évaluations des itinéraires de distribution (ouvert, restreint, fermé avec motif), le statut de débit aux nœuds clés et le remplissage du pipeline — la quantité totale de chaque classe d'approvisionnement dans le réseau de distribution entre le POD et les unités avancées. La COP logistique doit échanger des données avec la COP tactique afin que les planificateurs logistiques connaissent la sécurité des itinéraires et que les commandants tactiques sachent quand les convois de soutien se déplacent dans leur zone d'opérations.

Comment JOPES s'intègre-t-il au logiciel de soutien en théâtre ?

JOPES (Joint Operation Planning and Execution System) contient le TPFDD (Time-Phased Force and Deployment Data), qui spécifie quelles unités se déplacent dans quelle séquence et sur quel transport stratégique. Le logiciel de soutien en théâtre ingère le TPFDD pour construire la séquence d'arrivée prévue au POD : quels navires ou aéronefs arrivent quand, quels TCN sont à bord de chacun et quelles unités possèdent le fret. Lorsque les arrivées réelles dévient du TPFDD — navires en avance ou en retard, manifestes modifiés — le logiciel de soutien signale les écarts afin que le commandement de soutien en théâtre puisse ajuster les priorités de réception et de mise en attente et évaluer l'impact sur les dates de disponibilité opérationnelle des unités.

Quelles métriques de débit le logiciel de soutien en théâtre doit-il suivre dans un port maritime de débarquement ?

Les métriques de débit critiques comprennent : les tonnes courtes déchargées par heure de grue (utilisation des grues), le total de tonnes courtes évacuées du port par jour (taux de débit portuaire), le temps de séjour par unité de chargement (temps entre le déchargement et le départ de la zone de mise en attente), le temps de rotation des conteneurs (temps écoulé depuis le levage par grue jusqu'à la sortie du portail), le taux d'utilisation des postes à quai (pourcentage de jours de poste planifiés avec des navires à quai) et le taux de remplissage de la zone de mise en attente (pourcentage de la capacité de la zone de mise en attente occupée). Ces métriques alimentent l'estimation de soutien logistique quotidienne et permettent au commandant du port d'identifier si le goulot d'étranglement est la capacité des grues, la disponibilité des camions, le traitement de la documentation ou l'espace de la zone de mise en attente, et de diriger les ressources en conséquence.

En quoi l'intégration de coalition LOGFAS diffère-t-elle de l'intégration JOPES uniquement américaine ?

LOGFAS (Logistics Functional Area Services) est utilisé par les alliés européens pour les opérations de coalition, couvrant la coordination des mouvements, la gestion du carburant et des approvisionnements, et la planification du soutien médical. Tandis que JOPES est l'outil américain pour la planification et l'exécution du déploiement des forces, LOGFAS couvre les contributions alliées. Le logiciel de soutien en théâtre dans un environnement de coalition doit s'interfacer avec les deux : les unités américaines transitent par JOPES/GCSS-Army, tandis que les alliés européens saisissent les données de soutien via les modules LOGFAS. Le défi de l'interface est l'alignement des modèles de données — LOGFAS utilise des numéros de stock OTAN et des conventions d'unité d'émission différentes des transactions US DLMS — nécessitant une logique de couche de traduction plutôt qu'un simple échange de messages.

Qu'est-ce que le délai de réponse d'approvisionnement et comment est-il mesuré dans le soutien en théâtre ?

Le délai de réponse d'approvisionnement (SRT) est le temps écoulé depuis la soumission d'une réquisition d'approvisionnement par une unité jusqu'à la livraison de l'article ou sa disponibilité au point d'approvisionnement désigné. C'est la principale métrique orientée client pour la performance du système de distribution. Le SRT comporte plusieurs composantes : le temps de traitement des réquisitions, le temps de préparation et de prélèvement au point d'approvisionnement, le temps de transport depuis le point d'approvisionnement jusqu'au point d'approvisionnement de l'unité demandeuse, et le temps de réception et de documentation. Le logiciel de soutien en théâtre mesure chaque composante séparément pour identifier si les retards se situent dans le système d'approvisionnement, le réseau de distribution ou à l'unité de réception — permettant des actions correctives ciblées plutôt que des ajouts de ressources généralisés.