Logiciel de gestion de flotte pour véhicules militaires : architecture et exigences

La gestion de flotte militaire est un problème fondamentalement différent de la gestion de flotte commerciale. Une entreprise de logistique commerciale suit des camions sur des autoroutes avec une connectivité cellulaire continue. Un groupement militaire suit des véhicules blindés, des camions-citernes et des équipements du génie sur un terrain avec une connectivité intermittente ou nulle, sous des contraintes EMCON (contrôle des émissions électromagnétiques), tandis que l'adversaire tente activement de localiser et de frapper l'infrastructure de données elle-même qui rend le suivi possible.

L'architecture logicielle pour la gestion de flotte militaire de la DGA doit tenir compte de ces contraintes dès le début — pas comme des ajouts tardifs à une plateforme commerciale. Cet article couvre le suivi des véhicules dans des environnements contestés, la gestion de la maintenance et de la disponibilité opérationnelle, la surveillance de la consommation de carburant, l'intégration avec les chaînes logistiques et l'architecture offline-first qui permet au système de fonctionner lorsque les communications tombent en panne.

Suivi de véhicules sous EMCON

Le signalement de position est la base de la gestion de flotte, mais le suivi des véhicules militaires ne peut pas simplement transmettre des fixes GPS continus. Les procédures EMCON limitent les transmissions radio pour empêcher l'ennemi de localiser les véhicules par leurs émissions radio. Un système de gestion de flotte nécessitant des transmissions fréquentes pour maintenir la précision de position forcerait les commandants à choisir entre la conscience situationnelle et la protection de la force.

La solution architecturale est le reporting store-and-forward avec des intervalles de reporting variables. Chaque véhicule porte une unité embarquée (OBU) — typiquement un ordinateur durci avec GPS, navigation inertielle et interface radio tactique — qui enregistre en continu la position, la vitesse, le cap et la télémétrie du véhicule. La transmission se produit selon un calendrier ou sur commande : toutes les 15 minutes pendant les opérations normales, toutes les 5 minutes pendant les mouvements actifs, ou entièrement supprimée sous EMCON strict.

Le format des données de position importe. Les systèmes de suivi de flotte militaire encodent la position en utilisant MGRS (Military Grid Reference System) ou WGS-84 avec une précision appropriée à l'échelle opérationnelle. Les rapports de position suivent généralement le format de piste NFFI ou CoT XML pour l'interopérabilité avec les systèmes C2 qui affichent les icônes de véhicules sur l'image opérationnelle commune.

Architecture de l'unité embarquée

L'OBU exécute une base de données locale (typiquement SQLite) qui stocke le journal de position, le dossier de maintenance du véhicule, les données de consommation de carburant et le manifeste de fret. Toutes les données sont d'abord enregistrées localement ; la transmission au serveur de gestion de flotte est secondaire. Cette conception offline-first signifie que l'OBU continue de fonctionner comme un enregistrement au niveau du véhicule même si le serveur de gestion de flotte est inaccessible pendant des jours.

Lorsque la connectivité est rétablie — par radio, modem satellite ou transfert de données physique dans un dépôt de maintenance — l'OBU se synchronise avec le serveur de gestion de flotte en utilisant une stratégie de réplication sans conflit. L'OBU fait autorité pour les données de son propre véhicule ; le serveur agrège les données de toutes les OBU du groupement.

Suivi de la maintenance et de la disponibilité opérationnelle

La disponibilité opérationnelle du véhicule — qu'il soit disponible pour les opérations, en maintenance planifiée, en attente de pièces ou immobilisé — est le paramètre qui intéresse le plus les commandants. Un commandant de bataillon doit savoir non seulement combien de véhicules sont dans le groupement, mais combien sont opérationnels à tout moment.

Le suivi de la maintenance dans le logiciel de gestion de flotte militaire suit le modèle de données TAMMS ou son équivalent OTAN. Chaque véhicule dispose d'un dossier de maintenance comprenant : les intervalles de service planifiés (basés sur les compteurs kilométriques ou d'heures), l'historique des pannes, le statut opérationnel actuel (FMC — entièrement opérationnel, PMC — partiellement opérationnel, ou NMC — non opérationnel) et les pièces commandées.

Surveillance de la consommation de carburant

Le carburant est la ressource militaire la plus consommée. Un bataillon mécanisé menant des opérations soutenues brûle des milliers de litres de diesel par jour dans toute sa flotte de véhicules. Suivre la consommation de carburant par véhicule, réconcilier avec les émissions de carburant des points d'approvisionnement et projeter les besoins futurs en carburant sont des fonctions essentielles de gestion de flotte.

La surveillance du carburant OBU s'intègre au bus CAN J1939 du véhicule, qui expose les paramètres du moteur, notamment le taux de consommation de carburant, la consommation totale de carburant depuis le dernier service et le niveau du réservoir. Le backend de gestion de flotte agrège la consommation de carburant par véhicule pour calculer les taux de consommation au niveau du groupement, réconcilier avec les dossiers d'approvisionnement et projeter les besoins en ravitaillement.

Intégration avec les systèmes de chaîne d'approvisionnement

Le logiciel de gestion de flotte ne fonctionne pas de manière isolée. Il doit échanger des données avec la chaîne logistique plus large : le système d'approvisionnement en pièces de rechange, le système de commande de maintenance qui initie les bons de travail et le système C2 logistique de niveau supérieur qui alloue des équipes de maintenance et des véhicules de récupération dans tout le groupement.

L'intégration utilise des formats de données logistiques militaires standard où disponibles — transactions DLMS pour les demandes et réceptions de pièces, messages logistiques NFFI pour les rapports de statut de véhicule aux échelons supérieurs. Là où les formats standard ne sont pas disponibles, l'intégration utilise des API REST avec des charges utiles JSON.