Certificate of Networthiness : Qu’est ce que le CoN ?

Le terme Certificate of Networthiness (souvent abrégé CoN) revient régulièrement dès qu’on parle de logiciels et de systèmes informatiques destinés à être déployés sur des réseaux militaires américains ou, plus largement, dans des environnements où la cybersécurité est considérée comme une condition d’accès au marché. Vu de loin, le CoN ressemble à un simple “tampon” administratif. En réalité, il s’inscrit dans une logique de conformité et de gestion du risque : prouver qu’un produit informatique peut être raccordé à un réseau critique sans dégrader sa sécurité, son interopérabilité ni sa capacité de maintien en conditions opérationnelles.

Le sujet est particulièrement intéressant parce qu’il se situe au croisement de la réglementation (exigences imposées par l’administration), du contractuel (conditions d’éligibilité à un appel d’offres, clauses de conformité) et de la responsabilité (risques opérationnels et réputationnels en cas de défaillance). Mais il faut aussi clarifier une idée essentielle : le CoN, en tant que processus formel de l’U.S. Army, a été remplacé à partir de 2018. Autrement dit, il demeure un concept et une référence historique, mais il ne faut pas le confondre avec le cadre aujourd’hui privilégié, centré sur le Risk Management Framework (RMF).

Définition : le CoN, à quoi correspondait-il concrètement ?

Le Certificate of Networthiness était une certification délivrée par le NETCOM (United States Army Network Enterprise Technology Command). Son objectif : évaluer et “certifier” qu’une application logicielle ou un système (commercial ou gouvernemental) pouvait être déployé sur des réseaux de l’armée américaine en respectant des standards élevés de sécurité, de compatibilité et de fiabilité.

L’idée n’était pas seulement de dire “ce logiciel n’est pas dangereux”. L’évaluation visait aussi à s’assurer qu’il s’intègre dans un environnement technique complexe, qu’il ne crée pas de dépendances ingérables, et qu’il ne deviendra pas un angle mort dans la défense du réseau. En pratique, le CoN matérialisait une exigence de maîtrise du risque : avant d’autoriser un composant à “toucher” un réseau sensible, il fallait démontrer qu’il répondait à un ensemble d’attentes techniques et organisationnelles.

Pourquoi ce certificat a-t-il longtemps été perçu comme un “sésame” ?

Dans l’univers des contrats publics et de la défense, l’accès au marché est rarement une question de prix ou de fonctionnalités uniquement. Il s’agit aussi de respecter des prérequis : exigences de sécurité, contrôles de conformité, procédures d’audit, traçabilité, et parfois contraintes très spécifiques selon l’autorité ou l’armée concernée.

Le CoN a été présenté comme une forme de “ticket d’entrée” : sans CoN, pas de déploiement sur certains réseaux militaires, et donc pas de projet. Cette logique est classique en conformité : une organisation définit un standard minimum (ici, sécurité / interopérabilité / supportabilité), puis conditionne l’accès au système d’information à la preuve du respect de ce standard.

Pour une entreprise, l’enjeu était majeur : le Département de la Défense (DoD) et l’écosystème de la défense représentent un client potentiel de grande ampleur. Mais la contrepartie est évidente : l’entreprise doit accepter un niveau d’exigence supérieur, documenter son produit, corriger des failles, et être capable d’expliquer (preuves à l’appui) comment elle gère la sécurité sur la durée.

CoN et enjeux juridiques : conformité, contrats et responsabilité

Du point de vue “droit / entreprise”, le CoN (et aujourd’hui ses équivalents dans le cadre RMF) illustre un mécanisme fréquent : la conformité devient une condition de contractualisation. On ne se contente pas de promettre : on doit démontrer, documenter, et accepter des audits ou des tests.

Dans la pratique, cela se traduit généralement par :

• Une exigence d’éligibilité : sans validation (hier CoN, aujourd’hui processus RMF/ATO), une solution ne peut pas être déployée, parfois même pas être considérée dans un scénario d’intégration.
• Des obligations contractuelles de sécurité : clauses imposant des standards, des procédures de correction, des délais de remédiation, et un reporting en cas d’incident.
• Une logique de responsabilité : déployer un composant non conforme peut créer un risque opérationnel (attaque, indisponibilité) et exposer les décideurs à des conséquences internes, voire disciplinaires, lorsque l’environnement est très encadré.

Ce point est important : même lorsqu’un “certificat” est remplacé par un nouveau cadre, l’esprit demeure. Les organisations ne renoncent pas à la sécurité ; elles la structurent différemment, parfois de manière plus standardisée, plus “continuelle”, et mieux articulée avec la gestion globale des risques.

Ce que le CoN cherchait à garantir : sécurité, interopérabilité, durabilité

Le CoN s’inscrivait dans une approche très concrète : empêcher qu’un logiciel devienne le maillon faible d’un réseau militaire. Les réseaux de défense traitent des informations sensibles et sont des cibles privilégiées. Un outil “pratique” mais mal sécurisé peut provoquer un effet domino : compromission, propagation, exfiltration, interruption d’opérations, perte de confiance et coûts de remédiation considérables.

Au-delà de la sécurité, le CoN visait aussi l’interopérabilité : un environnement militaire peut combiner des systèmes hétérogènes, parfois hérités, parfois récents. L’exigence n’est pas uniquement de “fonctionner sur son poste”, mais de ne pas perturber les échanges, ni la stabilité, ni les mécanismes de supervision et de contrôle. Enfin, la supportabilité (la capacité à maintenir le système, le patcher, le documenter, le faire évoluer) était un critère central : une administration ne peut pas dépendre d’un composant fragile ou non maintenable.

Comment se déroulait l’obtention d’un CoN

Le processus d’obtention d’un CoN était décrit comme structuré, exigeant et potentiellement long. Il combinait une lecture documentaire, des tests et un cycle de remédiation. On n’est pas sur une simple formalité : l’objectif était d’identifier les risques, d’exiger des corrections, puis de vérifier que les corrections n’avaient pas introduit de nouvelles vulnérabilités.

Sans entrer dans un mode opératoire technique (qui dépend toujours des exigences applicables au système), la logique était la suivante : évaluation par des experts, identification des failles, corrections par l’éditeur, puis réévaluation. Cette boucle est classique en cybersécurité : un produit “passe” rarement du premier coup lorsqu’il s’agit d’intégration dans des environnements très sensibles.

Validité et renouvellement : pourquoi ce n’était pas un acquis définitif

Le CoN n’était pas conçu comme une validation “à vie”. Les menaces évoluent, les dépendances logicielles évoluent, et les réseaux changent. Un certificat de conformité délivré à un instant donné peut devenir obsolète si le produit est mis à jour sans contrôle, ou si de nouvelles vulnérabilités apparaissent.

C’est pourquoi il était généralement question de validité limitée et de renouvellement (avec de nouveaux tests ou évaluations). En entreprise, cela renvoie à une idée essentielle : la conformité cybersécurité n’est pas un événement, c’est un processus. On ne “fait pas” la sécurité une fois ; on l’organise dans la durée, avec des preuves, des audits, des correctifs et une gouvernance.

Les conséquences d’une absence de CoN dans un environnement concerné

Lorsqu’un système était soumis à cette exigence, l’absence de CoN pouvait avoir des conséquences lourdes : blocage du déploiement, exposition accrue aux cyberattaques, risques de fuite de données, interruptions opérationnelles, pertes financières, et potentiellement conséquences internes pour les responsables si la non-conformité était détectée. Dans les environnements militaires ou assimilés, l’argument “on n’a pas eu le temps” pèse rarement face à un impératif de sécurité.

Transposé au monde de l’entreprise, ce point rappelle une mécanique bien connue : un défaut de conformité sur un système critique ne se limite pas à un risque technique ; il devient un risque de gouvernance, de continuité d’activité, et parfois de responsabilité (selon le contexte, les obligations contractuelles et les règles applicables).

Le rôle du NETCOM et l’idée d’un contrôle “institutionnel”

Le NETCOM jouait un rôle central : supervision, audits, contrôles de conformité, et approche systématique de l’évaluation. Cela illustre un principe de régulation interne : lorsqu’un réseau est considéré comme critique, l’autorité opératrice cherche à garder la maîtrise de ce qui y est connecté.

Pour les entreprises candidates, ce point est structurant : elles doivent être capables de dialoguer avec une autorité technique et de produire un niveau de documentation et de justification compatible avec des exigences institutionnelles. C’est souvent une marche plus élevée que dans un déploiement “standard” B2B, notamment parce que l’évaluation porte autant sur la sécurité que sur la capacité à soutenir le produit dans la durée.

Le tournant de 2018 : le CoN remplacé par le RMF

Un élément des sources mérite d’être mis au premier plan : le processus CoN a été abandonné / remplacé à partir de 2018. La raison mise en avant est simple : le CoN était considéré comme lourd, coûteux, et surtout peu harmonisé à l’échelle des agences fédérales américaines. Chaque entité pouvant avoir son propre schéma, les entreprises se retrouvaient face à des redondances et à une complexité administrative élevée.

Le cadre qui le remplace est présenté comme le Risk Management Framework (RMF), notamment dans une logique dite “Assess Only”. Le changement n’est pas seulement sémantique : on passe d’un certificat historiquement attaché à l’U.S. Army à une approche davantage standardisée, conçue pour être plus cohérente au niveau du DoD et, surtout, plus réutilisable (idée de “réciprocité” d’évaluations).

CoN, RMF et ATO : ne pas confondre les étages

Une confusion fréquente consiste à mélanger le certificat (CoN), le cadre de gestion du risque (RMF) et l’autorisation d’exploitation (souvent évoquée via l’Authority to Operate, ATO). Même sans entrer dans des détails propres au droit américain, la logique est importante :

Le CoN visait à “qualifier” un produit ou un composant dans une perspective de déploiement sur un réseau donné. L’ATO, elle, renvoie davantage au “feu vert” d’exploitation dans un contexte système précis. Et le RMF s’inscrit dans une démarche plus large : évaluer, gérer, suivre le risque dans le temps, plutôt que de considérer qu’un papier à un instant T résout durablement la question.

Pour une entreprise, cela change la stratégie : il ne s’agit plus de “chercher un CoN” mais de construire un dossier, des preuves, une gouvernance et une posture de sécurité compatibles avec les exigences RMF et avec l’obtention d’une autorisation d’exploitation dans le contexte du système ciblé.

Ce que les entreprises doivent retenir si elles ciblent le marché défense

Si votre entreprise vise un déploiement dans un environnement lié au DoD ou à des réseaux militaires, l’enseignement principal est simple : ne focalisez pas votre conformité sur un label historique. Le nom “CoN” reste très présent dans les discussions, mais la réalité opérationnelle s’est déplacée. Ce qui compte, c’est d’intégrer une culture de cybersécurité, de produire des preuves, et de pouvoir démontrer la maîtrise du risque dans la durée.

Autrement dit, le CoN peut être vu comme un repère : il matérialisait des exigences de sécurité, d’interopérabilité et de fiabilité. Même remplacé, il a laissé un héritage : la conformité cyber n’est pas une option, surtout lorsqu’on touche des infrastructures critiques.

Les bénéfices “business” d’une logique type CoN

On peut être tenté de voir le CoN uniquement comme une contrainte. Pourtant, les sources soulignent aussi une dimension “valeur” : posséder une validation de ce type renforçait la confiance, améliorait la réputation et pouvait faciliter l’accès à des déploiements plus larges. Cette logique reste vraie aujourd’hui sous des formes modernisées : une entreprise capable de prouver sa maturité cyber (processus, tests, remédiation, traçabilité) est souvent perçue comme plus crédible et plus “industrializable”.

Dans des secteurs régulés ou sensibles (défense, santé, infrastructures critiques), la cybersécurité est un facteur de différenciation. Une approche rigoureuse réduit les risques d’incident, mais elle réduit aussi les frictions commerciales : moins de questions bloquantes, moins d’incertitude, plus de capacité à franchir les étapes d’évaluation.

Les défis : pourquoi l’obtention (ou l’équivalent moderne) est rarement simple

Les sources mentionnent plusieurs difficultés : arbitrer entre exigences techniques et exigences administratives, gérer les délais, interpréter des normes qui peuvent varier selon les entités, et rester à jour lorsque les règles évoluent. Ce constat se retrouve dans beaucoup de programmes de conformité : la complexité ne vient pas uniquement de la technique, mais du fait qu’il faut aligner des exigences, des preuves, des cycles de release, des responsabilités internes et des calendriers d’audit.

Le point le plus délicat, souvent, est l’anticipation. Les failles identifiées tardivement coûtent plus cher, car elles forcent des refontes, des retests, et retardent l’accès au réseau ou au contrat. D’un point de vue “entreprise”, cela plaide pour une posture “security by design” : intégrer la conformité cyber dès la conception, plutôt que la traiter en fin de parcours.

À retenir sur le Certificate of Networthiness

• Le CoN était une certification associée au NETCOM visant à valider qu’un logiciel pouvait être déployé sur des réseaux militaires américains sans créer de risque indu.
• Il incarnait des exigences fortes : sécurité, interopérabilité et supportabilité, avec un processus d’évaluation, correction et réévaluation.
• Depuis 2018, le CoN a été remplacé par une logique centrée sur le RMF (gestion du risque plus standardisée et continue) : l’étiquette “CoN” est historique, mais l’exigence de fond demeure.

Conclusion

Le Certificate of Networthiness n’est pas qu’un terme technique : c’est le symbole d’un mode d’accès à des environnements critiques où la cybersécurité et la conformité déterminent la possibilité même de déployer une solution. Historiquement, le CoN a servi de barrière d’entrée sur certains réseaux de l’U.S. Army, en imposant une évaluation rigoureuse des risques et une preuve de compatibilité et de fiabilité.

Mais pour une entreprise, l’essentiel n’est pas de courir après un label qui a évolué : c’est de comprendre le mécanisme qu’il représentait. Aujourd’hui, la logique s’inscrit davantage dans le RMF et une gestion continue des risques, souvent articulée avec une autorisation d’exploitation dans un contexte système donné. En clair : le nom “CoN” est peut-être à ranger dans l’histoire récente, mais l’exigence de conformité, elle, est plus actuelle que jamais.