Gestion de configuration pour les logiciels de défense : référentiels, CCB et pistes d'audit

Dans un contexte commercial, la gestion de configuration logicielle se confond largement avec le contrôle de version. Dans les programmes de défense, le contrôle de version n'est que la moindre de vos obligations SCM. La véritable discipline englobe l'établissement formel des référentiels, un Comité de contrôle des modifications (CCB) opérationnel, des propositions de modification technique documentées, des rapports de comptabilité d'état de configuration et des audits de configuration que le représentant gouvernemental doit pouvoir contrôler. Manquer l'un de ces éléments vous expose à des constatations contractuelles, des glissements de calendrier lors de l'intégration système et des audits échoués qui bloquent les livraisons. Ce guide aborde chaque élément en séquence — sa signification, sa mise en œuvre correcte et les erreurs typiques des programmes.

Ce que signifie la gestion de configuration dans les programmes de défense

La gestion de configuration dans le contexte de la défense est une discipline de management définie par MIL-STD-973 et ses équivalents civils (EIA-649, ISO 10007). Elle repose sur quatre fonctions fondamentales : l'identification de configuration (quels sont les éléments contrôlés et leurs attributs ?), le contrôle de configuration (comment les modifications sont-elles évaluées et approuvées ?), la comptabilité d'état de configuration (quel est l'état approuvé actuel de chaque élément ?) et la vérification et l'audit de configuration (le produit correspond-il à son référentiel approuvé ?).

Le périmètre s'étend bien au-delà du code source. Les éléments de configuration (CI) d'un système de défense comprennent les assemblages matériels, les circuits imprimés, les images de firmware, les exécutables logiciels, les manuels techniques, les procédures de test, les documents de contrôle d'interface et même les équipements de soutien. Chaque CI est formellement désigné avec un identifiant unique, une discipline d'ingénierie responsable et une relation parent-enfant documentée dans l'arborescence des CI au niveau système. La modification d'un attribut d'un CI — sa spécification de performance, sa définition d'interface, son numéro de pièce — déclenche le processus de contrôle de configuration.

Pour les équipes logicielles, l'implication pratique est que la SCM n'appartient pas exclusivement au groupe logiciel. Les défis agile des logiciels de défense qui découlent du développement concurrent matériel et logiciel constituent fondamentalement un problème de gestion de configuration : lorsque des CI matériels modifient leurs spécifications d'interface, les CI logiciels doivent être notifiés et mis à jour par un processus formel, et non par un message ad hoc sur une messagerie instantanée. Le document de contrôle d'interface (ICD) est un élément contrôlé ; ses modifications nécessitent une proposition de modification technique (ECP) approuvée avant toute implémentation.

Cette étendue explique pourquoi les programmes de défense maintiennent un Bureau de gestion de configuration (CMO) dédié, doté de spécialistes, plutôt que d'attribuer les responsabilités SCM à un développeur à temps partiel. Le CMO maintient la base de données de gestion de configuration, prépare et préside le CCB, suit toutes les ECP ouvertes et prépare les audits de configuration. Sur les programmes de moins de 50 personnes, le CMO peut être une seule personne — mais ce doit être une personne, avec un temps dédié, et non un comité sans responsable clairement désigné.

Types de référentiels et leur cycle de vie

MIL-STD-973 définit trois types de référentiels formels qui marquent des jalons dans le cycle de vie du développement système. Chaque référentiel est un instantané contrôlé de la documentation technique approuvée pour le système ou un CI à un moment défini du programme.

Référentiel fonctionnel. Le FBL est établi lorsque le gouvernement accepte la spécification fonctionnelle au niveau système lors du PDR. Il capture ce que le système doit faire — performances, fonctions et exigences d'interface — sans préciser comment. Une fois clôturé, toute modification du FBL nécessite une ECP de classe I et l'accord du gouvernement. Les équipes logicielles découvrent les modifications du FBL de la manière la plus douloureuse lors des audits de configuration fonctionnelle (FCA), lorsque des exigences dont elles n'ont jamais été formellement notifiées apparaissent sur la liste de contrôle de l'audit.

Référentiel alloué. L'ABL se clôture au CDR et contrôle la façon dont les exigences système sont distribuées entre les CI. La Spécification des exigences logicielles (SRS) de chaque CI logiciel est tracée jusqu'à l'ABL. Si une exigence système est ensuite répartie différemment — par exemple, une exigence de temporisation passe d'un CI matériel à un CI logiciel — cette réaffectation constitue un changement de classe I nécessitant l'approbation du CCB et la révision de la SRS avant que l'équipe logicielle modifie une seule ligne de code. Les programmes qui autorisent une réaffectation informelle dans des conversations de couloir finissent avec une SRS qui reflète l'implémentation réelle plutôt que les exigences approuvées, ce qui échoue systématiquement lors du FCA.

Référentiel produit. Le PBL est l'aboutissement du processus de développement, établi après que l'audit de configuration physique (PCA) a confirmé que le produit livré correspond à sa configuration documentée. Le PBL comprend la spécification de construction (version source exacte, compilateur, chaîne d'outils et paramètres de construction nécessaires pour reproduire le livrable), la Description de version logicielle et la nomenclature telle que construite. Une fois le PBL établi, le produit entre en contrôle de configuration de maintien en condition opérationnelle — toute modification, aussi minime soit-elle, nécessite des ECP formelles via le CCB.

Structure et fonctionnement du CCB

Le CCB est l'organe décisionnel qui évalue les modifications proposées aux référentiels contrôlés. Ce n'est pas un comité de revue ou un groupe consultatif technique — c'est une autorité formelle dotée d'une charte documentée, d'une composition définie et de règles de vote contraignantes. Un CCB qui fonctionne de manière informelle, qui prend des décisions dans des fils de courrier électronique ad hoc plutôt que lors de réunions formelles avec des procès-verbaux enregistrés, n'est pas un CCB au sens de MIL-STD-973 et ne satisfera pas un audit gouvernemental.

Charte. La charte du CCB est un document contrôlé (lui-même géré sous SCM) qui définit : l'autorité et le périmètre du CCB ; les membres permanents et leurs suppléants ; les exigences de quorum (généralement une majorité des membres votants) ; les règles de vote pour les modifications courantes, les modifications controversées et les procédures d'urgence ; le format de soumission des ECP et les informations justificatives requises ; les délais de décision (par exemple, les ECP courantes décidées dans les 10 jours ouvrables suivant la soumission) ; et la voie d'escalade lorsque le CCB ne parvient pas à une décision.

Composition pour un programme de taille moyenne. Un CCB pour un programme de défense logicielle de 30 à 100 personnes comprend généralement :

• Président : Ingénieur en chef ou chef de programme — voix prépondérante, garant du respect de la charte
• Secrétaire : Responsable de la gestion de configuration — prépare les ordres du jour, rédige les procès-verbaux, maintient la CMDB
• Membres votants : Responsable ingénierie système, responsable logiciel, responsable matériel, responsable test, représentant ILS/Logistique
• Participants non votants : Initiateur de l'ECP, responsables de sous-systèmes concernés, analyste coût/calendrier
• Représentant gouvernemental : COTR ou chef de programme — requis pour les changements de classe I, peut assister ou fournir un accord écrit

Cadence des réunions. La plupart des programmes tiennent des réunions CCB hebdomadaires pour les modifications courantes, avec un ordre du jour type comprenant : l'état des ECP précédemment approuvées ; les nouvelles ECP soumises depuis la dernière réunion (revue initiale brève) ; les présentations complètes et votes sur les ECP prêtes à décision ; et les ratifications des modifications d'urgence. Les modifications d'urgence sont autorisées hors bande par le président du CCB (et le représentant gouvernemental pour la classe I) et ratifiées lors de la prochaine réunion CCB programmée — le procès-verbal de ratification clôture l'autorisation d'urgence.

Procès-verbaux et archives. Les procès-verbaux provisoires doivent être distribués dans les 48 heures suivant la réunion et finalisés dans les cinq jours ouvrables. Les procès-verbaux consignent : les participants, l'état du quorum, les ECP examinées avec la décision et le décompte des votes, les actions à entreprendre avec les responsables et les dates d'échéance, et tout avis dissident sur les décisions controversées. Les procès-verbaux sont des documents contrôlés déposés dans la CMDB. La régularité du secrétaire CM dans la production et le dépôt des procès-verbaux est l'un des facteurs les plus déterminants de la préparation d'un programme à un audit de configuration.

Propositions de modification technique : classe I vs classe II

Une proposition de modification technique (ECP) est le vecteur formel pour proposer, évaluer et approuver les modifications apportées à un référentiel contrôlé. Toute modification d'un élément sous contrôle de configuration qui affecterait le FBL, l'ABL ou le PBL doit être documentée dans une ECP avant le début de l'implémentation — et non après.

Classe I vs classe II. La distinction détermine qui approuve la modification et le niveau de processus requis :

• Classe I : Affecte un référentiel formellement contrôlé, un engagement contractuel, une interface approuvée (ICD), une exigence de sécurité critique ou la forme/l'ajustement/la fonction d'un livrable. Nécessite l'approbation du CCB et l'accord gouvernemental. L'implémentation est bloquée jusqu'à l'obtention de l'approbation. Exemples typiques : ajout d'une nouvelle capacité à la SRS, modification d'un champ de données ICD, modification d'une exigence de sécurité, suppression d'une procédure de test du plan de test approuvé.
• Classe II : Modification technique interne qui n'affecte aucun référentiel contrôlé, livrable contractuel ou interface approuvée. Approuvée par le CCB interne du contractant sans implication de l'acquéreur. Enregistrée pour la piste d'audit mais non soumise à la revue gouvernementale. Exemples typiques : refactorisation de la structure interne d'un module, modification d'une structure de données non interfacée, mise à jour des normes de codage internes dans un guide de style qui n'est pas un CDRL.

La frontière entre classe I et classe II est une source fréquente de désaccord. Le CMP doit définir cette frontière avec des exemples concrets. Un écueil courant est que des ingénieurs décident de manière indépendante que leur modification est de classe II alors qu'elle est en réalité de classe I — modifier le format de données interne d'un message qui franchit une frontière entre CI constitue un changement de classe I même si l'interface externe (l'ICD) semble inchangée, car le format du message est une interface implicite.

Évaluation d'impact. Chaque ECP nécessite une évaluation d'impact structurée avant de pouvoir être soumise au vote. L'évaluation couvre : le risque technique (quels problèmes peut poser la modification proposée ?) ; l'impact calendaire (combien de jours s'ajoutent au calendrier, y compris la régression de test ?) ; l'impact coûts (quel est le coût estimé en main-d'œuvre et en matériaux ?) ; l'impact sécurité (cette modification affecte-t-elle une fonction critique de sécurité ou une hypothèse d'un dossier de sécurité ?) ; et l'impact interface (quels autres CI doivent effectuer des modifications correspondantes ?). Pour les changements de classe I, l'évaluation d'impact est préparée conjointement par l'ingénieur à l'origine de la demande, l'analyste coût/calendrier et l'ingénieur système. Pour les modifications ayant un impact sur la sécurité, l'ingénieur sécurité examine et signe l'évaluation avant la soumission au CCB.

Le cycle de vie d'une ECP : l'initiateur rédige l'ECP → le secrétaire CM lui attribue un numéro et l'enregistre dans la CMDB → le CCB l'examine en réunion → le CCB vote (approuver / rejeter / reporter) → l'accord gouvernemental est obtenu pour la classe I → le statut de l'ECP est mis à jour en « Approuvée pour implémentation » dans la CMDB → l'ingénieur implémente la modification → la validation dans le système de contrôle de version est étiquetée avec le numéro ECP → les preuves de test sont liées à l'ECP dans la CMDB → l'ECP est clôturée. Cette piste d'audit complète — de l'initiation à l'implémentation et aux preuves de test — est ce que les auditeurs gouvernementaux recherchent lors du FCA et du PCA. Consultez également notre guide sur l'application des SBOM dans les pipelines de défense, qui croise la gestion des ECP pour les modifications de la chaîne d'approvisionnement logicielle.

Chaîne d'outils SCM logicielle

La chaîne d'outils SCM pour un programme de défense doit satisfaire trois contraintes qui ne s'appliquent pas au développement commercial : les outils doivent être approuvables dans le cadre de l'Autorisation de mise en service (ATO) du programme ; ils doivent prendre en charge la traçabilité formelle requise par MIL-STD-973 et toute norme d'aptitude au vol applicable ; et — pour la plupart des programmes de défense — ils doivent fonctionner dans un environnement réseau isolé (air-gapped) ou partiellement isolé.

Contrôle de version. Git est la norme de facto dans les programmes de défense non classifiés et classifiés. Pour les programmes classifiés, des serveurs Git auto-hébergés (GitLab Self-Managed, Bitbucket Data Center ou Gitea) sont déployés au sein de l'enclave accréditée. Les règles de protection de branche imposent des exigences de revue ; les commits signés assurent la non-répudiation pour la piste d'audit. Les conventions de nommage des dépôts et des branches doivent être documentées dans le CMP et appliquées via des hooks côté serveur. Pour les programmes soumis à DO-178C, le système de contrôle de version est un candidat à la qualification d'outil (TQP) — le plan de qualification doit couvrir la version spécifique du serveur, sa configuration et l'opération d'étiquetage de référentiel qui alimente la Description de version logicielle. Pour le contexte plus large de l'exécution de CI/CD dans ces environnements, consultez notre article sur le CI/CD pour la défense en environnement isolé.

Gestion des exigences. IBM Engineering Requirements Management DOORS (Classic et Next Generation) reste l'outil de gestion des exigences le plus utilisé dans les programmes de défense, en particulier ceux régis par MIL-STD-973 et DO-178C. Jama Software et PTC Windchill Requirements sont des alternatives courantes. L'outil de gestion des exigences doit prendre en charge la traçabilité bidirectionnelle (exigence → cas de test → résultat de test) et doit générer les artefacts de matrice de traçabilité requis par le SDP/SCMP en tant que CDRL. L'outil lui-même doit être exploité sous contrôle de configuration : la base de données des exigences est un élément de configuration, les modifications des exigences dans l'outil sont contrôlées, et la sortie de l'outil doit être reproductible à partir d'un référentiel étiqueté.

Base de données de gestion de configuration (CMDB). La CMDB suit le statut des CI, les associations de référentiels, les enregistrements d'ECP, les enregistrements de dérogation/déviation et les données de comptabilité d'état de configuration. Dans les grands programmes, la CMDB est souvent IBM Engineering Lifecycle Management (ELM) ou une instance Jira configurée avec un plugin CM. Les programmes plus petits utilisent parfois une combinaison Confluence + Jira structurée. Quel que soit le choix, la CMDB doit être dans le périmètre accrédité, doit disposer de contrôles d'accès empêchant toute modification non autorisée des enregistrements approuvés, et doit générer le rapport périodique de comptabilité d'état de configuration qui constitue un CDRL sur la plupart des programmes.

Configuration du serveur SCM en environnement isolé. Le serveur Git auto-hébergé et la CMDB sont déployés sur des instances RHEL durcies selon les STIG au sein de l'enclave classifiée. Aucune connexion aux services d'hébergement de dépôts publics. Les mises à jour des logiciels serveur suivent la procédure de transfert de supports du programme. Les certificats TLS du serveur sont émis par l'infrastructure à clé publique (PKI) interne du programme. Les sauvegardes sont stockées dans l'enclave en utilisant un stockage chiffré avec des procédures de récupération documentées. L'accès au serveur de contrôle de version est régi par la liste de contrôle d'accès du programme, avec des autorisations basées sur les rôles séparant l'accès en lecture, en écriture et en administration.

Audits de configuration : FCA et PCA

Les audits de configuration sont des revues formelles conduites par ou avec la participation du gouvernement pour vérifier qu'un CI ou un système satisfait ses exigences spécifiées (FCA) et que le produit est correctement documenté (PCA). Ce ne sont pas des points de contrôle facultatifs — ce sont des jalons contractuels qui conditionnent les livraisons et les paiements.

Audit de configuration fonctionnelle (FCA). Le FCA vérifie que le CI logiciel a satisfait toutes ses exigences allouées. L'équipe d'audit gouvernementale examine : la SRS approuvée (document ABL) indiquant chaque exigence ; les procédures de test qui testent chaque exigence ; les résultats de test montrant une exécution réussie ; la matrice de traçabilité reliant les exigences aux tests et aux résultats ; et les rapports de non-conformité ouverts montrant toutes les anomalies connues et leur état de résolution. Un constat d'audit fréquent est celui des exigences sans test associé — des « exigences orphelines » que les équipes d'ingénierie prévoyaient de tester mais n'ont pas formellement couvertes. Tout aussi fréquentes sont les procédures de test qui prétendent satisfaire une exigence mais testent en réalité quelque chose d'adjacent — les auditeurs lisent les procédures de test par rapport au texte des exigences de manière littérale. La préparation du FCA nécessite de générer la matrice de traçabilité à partir de l'outil de gestion des exigences 60 jours ou plus à l'avance, de la passer en revue pour identifier les lacunes, et de combler ou documenter ces lacunes avant l'audit.

Audit de configuration physique (PCA). Le PCA vérifie que le produit à livrer ou à déployer correspond exactement à sa configuration documentée. La démonstration centrale est la reproductibilité de la construction : le contractant doit démontrer qu'en partant du référentiel source contrôlé identifié dans la Description de version logicielle, il peut reproduire un binaire identique octet par octet au livrable. Cela nécessite une spécification complète de l'environnement de construction — non seulement la version du compilateur, mais chaque outil de la chaîne de construction, chaque indicateur de construction, chaque variable d'environnement qui influence le résultat. Les programmes qui ont des dépendances d'environnement de construction non documentées découvrent ce problème lors du PCA ; la solution consiste à maintenir l'environnement de construction comme une image de conteneur sous contrôle de configuration dont le contenu exact fait partie de la documentation PBL.

# Build environment specification — PBL artifact
build_environment:
  base_image: rhel9.4-build:2026.06.15
  compiler:   gcc-13.3.1
  linker:     binutils-2.41
  make:       gnu-make-4.4.1
  java:       openjdk-21.0.3
  maven:      apache-maven-3.9.8
  flags:
    CFLAGS:   "-O2 -fstack-protector-strong -D_FORTIFY_SOURCE=2"
    LDFLAGS:  "-Wl,-z,relro,-z,now"

# Baseline label (tagged in version control)
source_baseline:  csci-001-v3.2.1
svd_revision:     D

# Verification hash (SHA-256 of deliverable binary)
deliverable_hash: e3b4c7a1f9d25843...  
            

Éléments de la liste de contrôle de préparation PCA : confirmer que l'étiquette de contrôle de version correspondant au SVD existe et est signée ; générer la nomenclature à partir de la CMDB et la comparer à l'ensemble de paquets réel dans l'environnement de construction ; vérifier que toutes les dérogations et déviations approuvées sont documentées et signées ; et confirmer que la liste des éléments ouverts correspond à la section des anomalies connues du SVD. Toute divergence entre l'enregistrement CMDB et le produit physique constitue un constat d'audit qui doit être résolu avant que le PCA puisse se clôturer.

Intégration MIL-STD-973 et DO-178C

Les programmes qui produisent des logiciels embarqués doivent satisfaire à la fois MIL-STD-973 (la norme SCM d'acquisition de défense) et DO-178C Section 7 (Gestion de configuration logicielle pour la certification des logiciels embarqués). Les deux sont complémentaires mais ont des emphases et des livrables distincts.

Plan de gestion de configuration vs Plan de gestion de configuration logicielle. MIL-STD-973 requiert un CMP de niveau système en tant que CDRL. DO-178C requiert un Plan de gestion de configuration logicielle (SCMP) séparé en tant qu'élément de données du cycle de vie logiciel. Le SCMP doit décrire comment toutes les données du cycle de vie logiciel (SLCD) sont placées sous contrôle de configuration, comment les modifications sont gérées, comment les référentiels sont établis et comment fonctionne le processus de signalement de problèmes et de contrôle des modifications. Le SCMP est examiné par le DER (Représentant d'ingénierie désigné) ou l'autorité de certification dans le cadre de la revue de planification logicielle. Le CMP au niveau système et le SCMP doivent être cohérents et se référencer mutuellement, mais ce sont des documents distincts destinés à des audiences différentes.

CDRL relatifs à la gestion de configuration. Les CDRL liés à la CM d'un programme de défense typique comprennent :

• DI-CMAN-80858A — Plan de gestion de configuration : Document de processus SCM principal
• DI-CMAN-81259 — Rapport de comptabilité d'état de configuration : Résumé périodique de l'état des CI
• DI-CMAN-81000 — Proposition de modification technique : Livrable par événement de modification
• DI-MCCR-80013A — Description de version logicielle : Livrable par version
• DI-CMAN-81121 — Document de contrôle d'interface : Livrable par interface

Qualification des outils SCM. DO-178C et la norme complémentaire DO-330 exigent que les outils de développement — dont la sortie fait partie du logiciel embarqué ou dont la défaillance pourrait introduire des erreurs non détectées — soient qualifiés. Un système de contrôle de version dont le référentiel étiqueté alimente le livrable SVD est un candidat à la qualification TD3 selon DO-330. Les preuves de qualification comprennent les Exigences opérationnelles de l'outil (TOR), un Plan de qualification de l'outil, des enregistrements de tests démontrant que l'outil stocke et récupère correctement le contenu binaire exact, et un processus de rapport de problèmes pour l'outil lui-même. Les programmes découvrent cette exigence tardivement, après avoir déjà sélectionné et déployé leur serveur de contrôle de version, car l'exigence DO-178C est souvent interprétée comme s'appliquant uniquement aux compilateurs et générateurs de code. Lancer le Plan de qualification de l'outil pour l'outil SCM en même temps que le SCMP — lors de la planification logicielle — évite la course à la qualification de dernière minute qui retarde la certification.

Signalement de problèmes et contrôle des modifications. DO-178C Section 7.3 exige un processus documenté de signalement de problèmes pour toutes les données du cycle de vie logiciel sous contrôle CM. Chaque anomalie — pas seulement les défauts de code, mais aussi les erreurs dans les exigences, les procédures de test, les documents de conception et les rapports d'analyse — doit être saisie dans le système de signalement de problèmes et suivie jusqu'à clôture. Les données de rapport de problèmes alimentent le FCA (montrant les anomalies ouvertes et leur disposition) et le PCA (confirmant que la liste des anomalies connues dans le SVD est exacte et complète). L'intégration du système de signalement de problèmes avec le flux de travail ECP garantit que les problèmes nécessitant une modification du référentiel génèrent automatiquement une ECP, plutôt que de vivre dans un gestionnaire de défauts séparé que les auditeurs ne peuvent pas corréler au référentiel contrôlé.

Les programmes qui investissent dans cette intégration — un outil de gestion des exigences alimentant la traçabilité vers un outil de gestion des tests, qui alimente les résultats vers une CMDB liée au flux de travail ECP — ont des cycles FCA et PCA sensiblement plus courts et moins de constats post-audit que les programmes qui gèrent ces enregistrements dans des tableurs déconnectés. L'investissement est significatif, mais l'alternative — reconstituer des preuves d'audit sous la pression du temps pendant que des représentants gouvernementaux attendent — est plus coûteuse et plus dommageable pour les relations programmatiques.