Je viens de lire une formule plus attendue dans une boutique que dans un communiqué sur des avions de combat : software sold separately. Le 17 juin, l’US Air Force a annoncé des contrats distincts pour les appareils Collaborative Combat Aircraft et leur logiciel d’autonomie de mission. La formule fait sourire; le découplage exige une architecture très sérieuse.

Une architecture de référence peut séparer logique de mission, services de plateforme et adaptateurs propres à l’appareil. Le logiciel d’autonomie demande une capacité — navigation, capteur, communication — par une interface. L’adaptateur traduit vers le matériel réel et applique ses limites.

logique de mission
  -> services d'autonomie et de données
  -> contrats d'interface / bus de mission
  -> adaptateur plateforme
  -> capteurs, communications, navigation et actionneurs

Le même code ne devient pas automatiquement sûr sur deux avions. Masse, vitesse, énergie, capteurs, latence et enveloppe de vol changent. L’adaptateur doit exprimer les capacités et refuser une commande hors limites. Les tests de contrat vérifient unités, délais, valeurs manquantes et modes dégradés avant toute intégration physique.

En janvier, l’OTAN avait utilisé Software Defined Defence dans sa stratégie numérique de l’Alliance, en reliant découplage, mises à niveau, interopérabilité et réseaux de mission. Le logiciel peut évoluer plus vite que la plateforme; il apporte aussi chaîne de compilation, bibliothèques, données, modèles, fournisseurs et accès d’administration.

Une release devient un objet de mission

Je voudrais pouvoir répondre à sept questions :

1. quel code source et quelles dépendances ont produit l’artefact?;
2. qui l’a signé et approuvé pour cette plateforme?;
3. quels tests simulation, matériel en boucle et terrain a-t-il passés?;
4. quelle configuration et quels modèles de données lui correspondent?;
5. quels appareils l’exécutent maintenant?;
6. quels indicateurs entraînent suspension ou retour?;
7. quelle version compatible reste disponible hors ligne?

L’artefact est signé; l’appareil vérifie signature, compatibilité et politique avant installation. Le déploiement peut commencer sur une plateforme d’essai, puis un groupe limité. Les journaux de version et de santé reviennent lorsque la communication le permet. Une mise à jour interrompue ne doit pas laisser un système non amorçable; deux partitions ou une image de secours permettent de revenir à une version connue.

La cybersécurité protège aussi la chaîne de livraison. Un SBOM et des versions verrouillées rendent les dépendances visibles. Les environnements de compilation sont contrôlés. Les secrets de signature sont séparés. Une vulnérabilité déclenche l’inventaire exact des plateformes touchées, pas une recherche manuelle dans des notes.

Le mode dégradé est aussi important que la nouvelle capacité. Perte de liaison, capteur contradictoire, horloge décalée ou modèle indisponible doivent mener à un comportement borné. L’autonomie ne devrait pas inventer une nouvelle mission parce que son service favori manque. L’opérateur connaît l’état et l’autorité de reprendre ou d’abandonner.

Le plan 2026-2027 de la Défense nationale relie lui aussi capacités numériques, préparation opérationnelle, assurance de mission et protection des actifs cyberdépendants.

Mon expérience directe dans ce domaine se limite à un travail d’architecture sur une solution de positionnement et de navigation liée à la défense, à Paris. Je garde les détails privés hors du texte et m’appuie autrement sur les informations publiques. Cette expérience suffit à me rendre attentif aux unités, versions, dépendances et retours.

Le logiciel n’est pas une couche TI décorative. Il fait partie de la capacité opérationnelle. Le séparer du matériel peut accélérer son évolution seulement si les contrats, preuves de test, signatures, inventaires et modes dégradés voyagent avec chaque release.