On déploie un logiciel sur un réseau militaire américain, le package technique est prêt, les tests de sécurité sont passés, et pourtant le déploiement est bloqué. Le problème n’est ni un bug ni une faille : il manque un Certificate of Networthiness (CoN). Cette attestation, longtemps incontournable pour toute solution destinée aux réseaux de l’US Army, conditionnait la mise en production de logiciels et matériels sur des infrastructures classifiées ou sensibles.
Pour les équipes IT qui travaillent avec des environnements de défense ou des marchés publics exigeants, comprendre ce mécanisme et ses évolutions reste un prérequis opérationnel.
A découvrir également : Optimiser la gestion de projets informatiques avec les bons outils
Certificate of Networthiness et chaîne d’approvisionnement logicielle : le vrai sujet en 2026
Le CoN historique fonctionnait comme un sas de validation ponctuel. On soumettait un dossier technique, on prouvait que le produit respectait les exigences de sécurité réseau, et on obtenait (ou non) le feu vert pour le déploiement. Le problème de cette approche : elle figeait la conformité à un instant T.
Les pratiques actuelles ont déplacé le curseur. La traçabilité de la chaîne d’approvisionnement logicielle remplace le dossier statique. Les équipes doivent désormais documenter qui contrôle la construction du logiciel, la signature, le packaging et la publication, avec des preuves vérifiables par propriétaire de contrôle.
Concrètement, cela signifie que le travail de conformité ne s’arrête plus à la livraison d’un formulaire. On maintient un registre continu des composants, des dépendances tierces et des personnes responsables à chaque étape du cycle de vie logiciel. Pour une équipe IT, cela change la charge de travail : on passe d’un effort concentré avant déploiement à une discipline permanente intégrée au pipeline.
Transition du CoN vers le Risk Management Framework (RMF)
Le Certificate of Networthiness n’est plus le mécanisme central de validation pour l’US Army. Depuis 2016, le processus a été absorbé par le Risk Management Framework, un cadre plus large qui couvre l’ensemble du cycle de vie des systèmes d’information.
La différence fondamentale tient à la philosophie. Le CoN validait un produit isolé avant son entrée sur le réseau. Le RMF évalue le risque global d’un système dans son contexte d’exploitation, en continu. On ne demande plus « ce logiciel est-il conforme ? », mais « quel niveau de risque ce système introduit-il dans notre environnement, et comment le gère-t-on ? »
Ce que le RMF change pour les éditeurs et intégrateurs
Les éditeurs qui ciblaient autrefois l’obtention d’un CoN doivent aujourd’hui s’aligner sur les exigences RMF, qui incluent la catégorisation du système, la sélection de contrôles de sécurité, leur implémentation et leur évaluation continue. Le cadre repose sur une logique d’Authorization to Operate (ATO), qui remplace la certification ponctuelle par une autorisation conditionnelle et renouvelable.
Pour les intégrateurs, le changement est aussi organisationnel. Les retours varient sur la complexité réelle du passage au RMF selon la taille de l’organisation, mais le consensus terrain pointe vers un besoin accru de documentation structurée et de collaboration entre équipes sécurité et équipes projet.
Gestion des certificats numériques : le risque opérationnel sous-estimé
Le terme « certificate » dans Certificate of Networthiness prête parfois à confusion avec les certificats numériques (TLS, signatures de code). Les deux sujets sont distincts, mais ils convergent sur un point : un certificat expiré ou mal géré provoque des interruptions de service et des failles de sécurité.
La littérature spécialisée en cybersécurité souligne que l’expiration inattendue de certificats numériques reste une cause fréquente d’incidents. Pannes de services, échecs d’authentification, non-conformité réglementaire : les conséquences touchent directement la continuité d’activité.
Bonnes pratiques de gouvernance des certificats pour les équipes IT
Quand on gère des environnements soumis à des exigences de type CoN ou RMF, la gouvernance du cycle de vie des certificats numériques fait partie du périmètre de conformité. Voici les points de contrôle à intégrer :
- Inventaire centralisé de tous les certificats actifs, avec dates d’expiration et responsables identifiés, pour éviter les renouvellements manqués
- Alertes automatisées déclenchées plusieurs semaines avant expiration, intégrées au système de ticketing de l’équipe
- Processus documenté de révocation et de remplacement en cas de compromission d’une clé privée
- Audit régulier des certificats auto-signés, souvent utilisés en environnement de test puis oubliés en production
Ces pratiques ne sont pas spécifiques au contexte militaire. Toute organisation qui manipule des données sensibles ou opère dans un cadre réglementaire strict a intérêt aux appliquer. Aligner conformité et gouvernance des certificats réduit les risques d’interruption non planifiée.
Aligner conformité CoN et cycle DevSecOps
Les équipes qui travaillent en DevSecOps se retrouvent face à une tension : la logique d’itération rapide du développement agile contre les exigences de documentation et de validation formelle héritées du CoN et du RMF. L’alignement passe par l’automatisation des preuves de conformité dans le pipeline CI/CD.
Sur un réseau militaire soumis à ces contraintes, la conformité doit suivre le rythme des livraisons. On intègre directement dans les étapes de build et de déploiement les mécanismes suivants :
- La génération automatique de rapports de conformité à partir des résultats de tests de sécurité (SAST, DAST, analyse de dépendances)
- La signature cryptographique des artefacts de build pour garantir l’intégrité de la chaîne de livraison
- Le rattachement de chaque release à un registre de contrôles de sécurité traçable et auditable
Cette approche transforme la conformité d’une corvée administrative en un sous-produit naturel du processus de développement. On ne prépare plus un dossier CoN ou RMF en fin de projet : chaque commit alimente la documentation de conformité.
Secure software attestation : la suite logique
Les contenus les plus récents sur le sujet parlent désormais de secure software attestation plutôt que de certification ponctuelle. Le principe : l’éditeur atteste formellement que son logiciel a été développé selon des pratiques de sécurité définies, avec des preuves vérifiables à chaque étape. Ce mécanisme prolonge la logique du CoN tout en l’adaptant aux réalités du cloud et des mises à jour continues.
Le Certificate of Networthiness reste un repère utile pour comprendre comment les environnements de défense abordent la validation de sécurité réseau. Sa logique n’a pas disparu : elle s’est diffusée dans des cadres plus larges comme le RMF et les exigences de traçabilité logicielle. Pour une équipe IT, la leçon pratique tient en une phrase : la conformité se construit dans le pipeline, pas dans un dossier de dernière minute.
