Le Certificate of Networthiness (CoN) était une validation utilisée par l’armée américaine pour vérifier qu’un logiciel ou un système pouvait fonctionner sur ses réseaux dans des conditions de sécurité définies. Ce certificat de conformité réseau n’est pas une homologation universelle valable pour tous les pays et tous les secteurs : il appartient à un cadre institutionnel précis, dont les pratiques ont évolué vers une gestion continue des risques et des autorisations d’exploitation.
Pour une entreprise, comprendre le CoN aide à distinguer une certification historique d’un contrôle de sécurité réellement applicable à son projet. Nous allons examiner son rôle, les évaluations qu’il recouvrait, ses effets sur les déploiements et les limites d’un certificat face aux menaces qui changent. Un éditeur fictif, Atlas Santé, nous servira de fil conducteur : il prépare un logiciel de gestion de dossiers médicaux et veut répondre aux exigences d’un client public américain.
- Le CoN en bref : une validation liée à l’environnement réseau de l’armée américaine.
- Son intérêt : réduire les risques avant le déploiement et documenter les exigences de sécurité.
- Le point de vigilance : une approbation passée ne garantit pas la sécurité présente d’un produit.
Certificate of Networthiness : définition
Le Certificate of Networthiness, souvent abrégé en CoN, désignait une approbation attribuée à des produits technologiques évalués pour une utilisation sur certains réseaux de l’US Army. L’examen portait sur leur compatibilité avec les politiques et les contraintes de l’environnement concerné. Le terme « networthiness » renvoie ainsi à l’aptitude d’une solution à être intégrée à un réseau donné, plutôt qu’à une garantie absolue contre toute attaque.
Cette distinction compte pour les acheteurs. Un produit pouvait être considéré comme acceptable dans un contexte donné après examen de ses fonctions, de son architecture et de ses interactions avec le réseau. Cela ne signifiait pas automatiquement qu’il était approuvé pour tous les systèmes du Département de la Défense, ni qu’il répondait à toutes les réglementations civiles. Le CoN ne doit donc pas être présenté comme un label général de cybersécurité accessible ou nécessaire à chaque entreprise.
Une approbation liée au contexte
Imaginons qu’Atlas Santé propose sa plateforme à un organisme public hébergeant des données sensibles. L’équipe informatique ne se contente pas de demander si le logiciel dispose d’un antivirus ou d’un chiffrement. Elle doit savoir comment il s’authentifie, quels ports il utilise, comment il journalise les accès et s’il peut coexister avec les composants déjà présents. L’évaluation vise l’ensemble formé par le produit, sa configuration et le réseau cible.
Cette approche rappelle qu’un même outil peut présenter des profils de risque différents selon son déploiement. Une application installée sur un serveur isolé n’expose pas les mêmes chemins d’accès qu’un service connecté à plusieurs systèmes. Le CoN a matérialisé cette logique d’approbation préalable : avant l’intégration, on vérifie que la solution répond aux exigences opérationnelles et de sécurité de son environnement.
Le rôle du CoN en cybersécurité
Le certificat contribuait à encadrer la sécurité informatique avant qu’un système ne rejoigne un réseau militaire. Les évaluations pouvaient inclure l’analyse des vulnérabilités, l’examen des mécanismes d’authentification, la configuration des composants et la vérification des échanges réseau. Selon le produit et le contexte, des tests techniques permettaient de repérer des faiblesses susceptibles d’exposer des données ou de perturber des services.
Pour Atlas Santé, cette démarche pourrait révéler qu’un compte de test reste actif dans la version destinée au déploiement. Pris isolément, ce détail semble mineur ; sur un réseau sensible, il peut offrir une porte d’entrée évitable. Une revue préalable donne l’occasion de corriger le défaut, de documenter la configuration attendue et de préciser les responsabilités entre l’éditeur et l’organisation cliente.
Des exigences vérifiables
La valeur d’une évaluation tient à la traçabilité. Les équipes doivent pouvoir relier une exigence à une preuve : résultat de test, description d’architecture, procédure de mise à jour ou règle de configuration. La validation des logiciels ne repose donc pas uniquement sur une déclaration commerciale du fournisseur. Elle s’appuie sur des éléments contrôlables, examinés par les autorités ou les équipes compétentes.
Cette méthode soutient aussi l’interopérabilité réseau. Une solution peut être techniquement robuste tout en provoquant des conflits avec les mécanismes de journalisation, les règles d’accès ou les outils de supervision déjà en place. Vérifier ces interactions réduit les risques de panne et de contournement des contrôles. Le CoN associait donc sécurité et aptitude opérationnelle : un produit sûr en laboratoire doit aussi fonctionner correctement dans son environnement cible.
Obtenir une homologation des systèmes
Le processus d’approbation ne se résumait pas à remplir un formulaire puis à recevoir un document. Il demandait au fournisseur et à l’organisation utilisatrice de réunir des informations techniques, de définir le périmètre du système et de répondre aux exigences applicables. Un contrôle de sécurité pouvait couvrir les vulnérabilités connues, les comptes privilégiés, les flux de données, les correctifs et les mesures de surveillance.
Dans le cas d’Atlas Santé, l’éditeur devrait fournir une description des composants, les dépendances logicielles, les résultats de tests et un plan de traitement des failles identifiées. L’organisme client examinerait ensuite la manière dont la plateforme s’intègre à ses propres protections. L’homologation des systèmes dépend de cette vision complète : un logiciel ne peut être évalué indépendamment de son usage, de ses connexions et des données qu’il traite.
Des étapes structurées
Les démarches actuelles de défense américaine s’inscrivent dans des cadres de gestion des risques, notamment le Risk Management Framework (RMF). Le RMF ne doit pas être confondu avec le CoN : il s’agit d’une approche plus large, qui organise l’identification des risques, la sélection des contrôles, leur évaluation et le suivi du système pendant son cycle de vie. Le modèle exact applicable dépend de l’autorité, du réseau et de la mission concernés.
- Définir le périmètre : préciser les composants, les utilisateurs, les données et les connexions du système.
- Évaluer les contrôles : vérifier les mesures techniques et organisationnelles, puis consigner les écarts.
- Traiter les risques : corriger les vulnérabilités ou faire examiner les risques résiduels par l’autorité compétente.
- Surveiller le système : suivre les changements, les correctifs et les nouvelles menaces après le déploiement.
Une autorisation obtenue à un moment donné ne dispense donc pas l’organisation de maintenir ses preuves et ses contrôles. Cette continuité est la différence entre une simple vérification ponctuelle et un dispositif de sécurité suivi.
Le CoN face aux exigences actuelles
Le nom CoN est associé à une pratique de l’US Army et ne constitue pas, à lui seul, une certification actuelle universellement requise. Les programmes d’approbation et les exigences évoluent ; les organisations doivent consulter l’autorité responsable du réseau ou du contrat concerné pour connaître la procédure en vigueur. En 2026, présenter un ancien certificat comme une preuve suffisante de conformité réglementaire serait trompeur : il faut vérifier son périmètre, sa date, son émetteur et les conditions auxquelles il s’appliquait.
Cette précision protège aussi les acheteurs contre les affirmations marketing floues. Un fournisseur peut avoir obtenu une approbation pour une version donnée, une configuration particulière ou un environnement déterminé. Si le produit a depuis changé, si ses dépendances ont été remplacées ou si de nouvelles vulnérabilités sont apparues, la preuve historique ne décrit plus nécessairement le niveau de protection actuel.
| Élément vérifié | Question à poser | Utilité pratique |
|---|---|---|
| Périmètre | Quel système et quel réseau étaient concernés ? | Éviter d’étendre la portée de l’approbation. |
| Version | La version évaluée correspond-elle à celle déployée ? | Repérer les écarts liés aux mises à jour. |
| Suivi | Les vulnérabilités et correctifs sont-ils surveillés ? | Maintenir la protection des systèmes d’information. |
| Autorité | Quelle entité valide aujourd’hui l’installation ? | Suivre le processus réellement applicable. |
Pour Atlas Santé, l’équipe commerciale ne devrait pas promettre une approbation militaire au seul motif qu’une ancienne version du produit a été évaluée. Elle peut plutôt fournir un dossier précis : périmètre de validation, pratiques de mise à jour, résultats d’audit disponibles et mesures de gestion des risques. Cette transparence renforce la crédibilité auprès des acheteurs spécialisés.
Les limites et le suivi continu
Aucune certification ne supprime le risque. Un système approuvé peut être affecté par une vulnérabilité découverte après son évaluation, une mauvaise configuration, un mot de passe compromis ou une erreur humaine. Le certificat renseigne sur un examen réalisé dans certaines conditions ; il ne remplace ni la supervision, ni la réponse aux incidents, ni la formation des utilisateurs.
Prenons un cas simple : après validation, Atlas Santé ajoute un module d’export de données. Cette évolution crée de nouveaux flux et peut modifier les droits d’accès. Si l’équipe ne met pas à jour la documentation et les contrôles, l’approbation initiale ne couvre pas nécessairement cette nouvelle configuration. Une gestion des changements rigoureuse permet de déterminer si une réévaluation est nécessaire.
Maintenir la confiance dans le temps
Nous conseillons de relier toute preuve de conformité à un programme opérationnel : inventaire des composants, calendrier de correctifs, surveillance des journaux, tests réguliers et procédures de signalement. À titre d’exemple, une organisation peut fixer un délai interne de 30 jours pour évaluer un correctif critique, puis documenter la décision de déploiement ou les raisons d’un report. Ce chiffre constitue une règle de gestion à adapter au risque, pas une exigence universelle du CoN.
Les équipes doivent aussi former les utilisateurs à reconnaître les tentatives d’hameçonnage et à protéger leurs identifiants. Une application correctement évaluée ne peut compenser des accès partagés ou une absence de sauvegarde. Le certificat apporte un cadre et une preuve ; la sécurité réelle dépend de la capacité de l’organisation à faire vivre ses protections au quotidien.
