Le Certificate of Networthiness (CoN) intrigue souvent ceux qui côtoient les marchés publics IT, la défense ou les grands réseaux d’entreprise. Derrière ce label se cache un dispositif d’assurance qualité pensé pour réduire les risques opérationnels, fluidifier les déploiements et instaurer une hygiène numérique durable. L’objectif de ce guide : expliquer la logique du CoN, sa valeur concrète pour les décideurs et les éditeurs, et ce qui a changé avec les référentiels modernes.
Définition opérationnelle et périmètre du CoN
Historiquement, le CoN est une attestation délivrée au sein de l’US Army par l’entité technique réseau, avec un rôle de filtre avant tout déploiement logiciel sur l’infrastructure. L’idée : s’assurer qu’une application répond à des critères de robustesse, de sécurité et de compatibilité avec l’écosystème existant, afin d’éviter de transformer un projet en incident majeur.
Sur le terrain, le CoN examine plusieurs familles d’exigences : durcissement système, gestion des correctifs, intégration aux annuaires et journaux, performance sous charge, mais aussi capacité de support dans la durée. Il s’agit autant de maîtrise de la cybersécurité que d’ingénierie de production.
Ce que l’attestation couvre réellement, sans folklore
Le rôle de l’US Army Network Enterprise Technology Command, plus connu sous l’acronyme NETCOM, a longtemps consisté à éprouver la réalité technique des logiciels candidats. Le référentiel met l’accent sur l’interopérabilité, la conformité et la maintenabilité : pas seulement “est-ce que ça marche ?”, mais “est-ce que ça cohabite, se met à jour, et reste stable en conditions dégradées ?”.
Pour un décideur achat, cela se traduit par une réduction des imprévus : déploiements plus prévisibles, moins de coûts cachés, meilleure visibilité sur les dépendances, et un alignement documenté avec les pratiques d’ingénierie système de l’écosystème défense.
Pourquoi les directions financières et IT y voient un levier de maîtrise du risque
Le CoN, ou les dispositifs qui l’ont supplanté, sécurisent la transformation numérique : moins de régressions en production, meilleure traçabilité, et arbitrages budgétaires plus rationnels. On parle de trajectoires de mise en service plus courtes, d’un MCO (maintien en conditions opérationnelles) anticipé, et d’une couverture de risque cyber mieux objectivée vis-à-vis des assureurs et des auditeurs.
Lorsqu’un portefeuille applicatif s’approche des critères d’un CoN, l’entreprise gagne une lisibilité qui simplifie les arbitrages entre dette technique et valeur métier.
Procédure d’évaluation : la méthode qui évite les angles morts
1) Cadrage et documentation initiale
Constituer le dossier technique, l’architecture cible, l’inventaire logiciel et les dépendances. Établir une matrice d’expositions, l’intégration aux annuaires, la politique de logs, la segmentation réseau et les exigences de chiffrement. Cette phase évite les surprises lorsqu’arrivent les tests de charge et de sécurité.
2) Tests techniques et sécurité
Campagnes de scans, validation des configurations, essais d’exploitabilité, revues de code sur composants sensibles, et analyses de conformité avec les guides de durcissement, type DISA STIGs. Les capacités d’observabilité et de rollback sont évaluées pour limiter l’impact en cas d’incident.
3) Corrections et validation
Élaboration d’un plan de remédiation priorisé : corrections immédiates, mesures compensatoires, feuille de route de patching. Les résultats sont rejoués pour confirmer la réduction du risque et documenter l’écart résiduel acceptable.
Durée, maintien et renouvellement : penser “cycle de vie”
Un label n’a de sens que s’il vit avec le produit. Les processus inspirés du CoN imposent des revues périodiques : nouvelles versions, nouvelles menaces, nouvelles dépendances. Les contrôles continus (“continuous monitoring”) prennent le relais de l’audit ponctuel, au plus près des pipelines CI/CD.
La discipline opérationnelle compte autant que la photographie de départ : patchs réguliers, gestion des configurations, politique d’obsolescence, et capacité à isoler rapidement un composant défaillant sans interrompre l’ensemble du service.
État de l’art 2025 : CoN, RMF et ATO, comment s’y retrouver ?
Dans la sphère américaine, le CoN a cédé la place à des référentiels plus intégrés, centrés sur l’Authority to Operate (ATO) et le Risk Management Framework (RMF) pilotés sur la base de contrôles NIST. Le terme “CoN” circule encore dans les échanges, mais la décision structurante est désormais l’ATO, délivrée pour un périmètre, une version et un environnement précis.
Concrètement, l’ATO agrège des contrôles issus de NIST SP 800-53, applique des profils de sécurité contextualisés et s’appuie sur des preuves techniques vivantes. La logique reste la même : prouver la maîtrise du risque à un instant T, puis la maintenir dans la durée.
| Référentiel | Statut en 2025 | Focalisation | Décision | Preuves clés |
|---|---|---|---|---|
| CoN (US Army) | Héritage / employé de façon résiduelle | Compatibilité réseau et hygiène de base | Feu vert de déploiement sur réseau Army | Rapports de tests, durcissement, intégration |
| RMF / ATO | Référentiel actif | Gestion du risque cyber continue | Autorisation d’opérer ciblée | Contrôles NIST, preuves d’audit, monitoring |
Le rôle des acteurs : qui décide, qui opère, qui audite ?
Au sein des organisations défense, la fonction réseau/IT assure le contrôle technique, tandis que la gouvernance cybersécurité formalise les exigences et arbitre le risque. Les équipes produit sont responsables de l’exécution et de la preuve. Cette séparation des rôles évite les biais et favorise les arbitrages argumentés.
La logique rappelle d’autres dispositifs de confiance numérique, comme la validité juridique des signatures électroniques : un socle de règles publiques, des preuves techniques, et une autorité qui statue sur la capacité à opérer en environnement réel.
Limites, coûts cachés et erreurs fréquentes
Le piège le plus courant : aborder l’évaluation trop tard, quand l’architecture est figée. On se retrouve à “patcher” en urgence, à décaler un lot, ou à rogner une fonctionnalité clé. Autre écueil : négliger la gestion des vulnérabilités dans la durée, au profit d’un sprint d’accréditation unique qui vieillit dès la première mise à jour.
Enfin, sous-estimer la documentation de la chaîne d’approvisionnement logicielle (SBOM) expose à des immobilisations coûteuses lors d’alertes critiques. Plus l’éditeur maîtrise ses dépendances, plus le retour à la normale est rapide et crédible face aux auditeurs.
Encadré terrain : ce que j’ai appris en accompagnant un éditeur B2B
J’ai assisté une plateforme SaaS visant des contrats parapublics. Au départ, l’équipe redoutait un “millefeuille d’exigences”. En posant tôt une matrice de risques, des profils de durcissement et une stratégie d’observabilité, le projet a décroché son autorisation en conservant ses objectifs produit.
“Le vrai déclic est venu quand nous avons traité la conformité comme une fonctionnalité. Dès lors, le monitoring, les tests sécurité et la traçabilité sont devenus des atouts commerciaux, pas seulement des coûts.”
Le bénéfice inattendu : une réduction du coût total de possession (TCO) sur 18 mois, grâce à une dette technique mieux contenue et moins d’incidents en exploitation.
CoN et innovation : frein ou accélérateur ?
Bien mené, l’exercice structure l’ingénierie : architecture modulaire, secrets managés, segmentation propre, scripts de reprise. Les équipes livrent plus vite parce que le pipeline intègre la preuve de qualité. Loin d’un carcan, c’est un langage commun qui sécurise les arbitrages et crédibilise la trajectoire produit auprès des acheteurs exigeants.
Du point de vue commercial, afficher une trajectoire crédible vers une ATO ou un “CoN-like” rassure les grands comptes. Le cycle de vente se raccourcit, les pilotes se transforment plus souvent, et la roadmap évite les refontes brutales.
Checklist de préparation pour un logiciel “CoN-ready”
- Cartographier les flux, données sensibles et dépendances critiques.
- Aligner l’architecture sur les gabarits de durcissement : pare-feu, secrets, chiffrement, journaux.
- Automatiser les tests sécurité et la revue des dépendances open source.
- Documenter l’interopérabilité avec les annuaires, proxy, SIEM et sauvegardes.
- Maintenir une SBOM exploitable et à jour de la chaîne d’approvisionnement logicielle.
- Prévoir la capacité de rollback et des playbooks incident.
- Définir une politique de patching et une gestion des configurations cohérentes.
- Établir un calendrier de revues périodiques post-déploiement.
Comparatif décisionnel : à quel moment viser une ATO plutôt qu’un CoN ?
Si votre cible est un environnement défense américain, la démarche RMF vers une ATO est le passage obligé. Le “réflexe CoN” demeure utile comme grille de lecture : compatibilité réseau, supervision, capacité à opérer sous contraintes. Pour un grand groupe civil, emprunter ces standards élève durablement la qualité de service.
La cohérence documentaire compte : contrôles NIST SP 800-53, guides DISA STIGs, et preuves de gestion des vulnérabilités. Plus la chaîne outillée est solide, plus l’audit ressemble à une revue de preuves plutôt qu’à une chasse au trésor.
Point de repère réglementaire
Les organisations actives dans les médias ou le numérique connaissent la logique des autorités sectorielles. À titre d’analogie, les prérogatives d’une autorité de régulation du numérique structurent un écosystème, comme le font les référentiels sécurité pour les réseaux sensibles. Dans les deux cas, la crédibilité passe par des preuves vérifiables.
Conseils pratiques pour éditeurs et acheteurs
Pour les éditeurs
- Intégrer tôt le référentiel sécurité au backlog : pas d’“après-coup”.
- Industrialiser l’inventaire logiciel et les mises à jour automatiques.
- Planifier un plan de remédiation récurrent, avec métriques de délai de correction.
Pour les acheteurs
- Exiger la visibilité sur la pipeline CI/CD et les preuves associées.
- Contrôler la couverture des contrôles RMF, les écarts résiduels et les mesures compensatoires.
- Évaluer la trajectoire vers l’Authority to Operate (ATO) quand le périmètre l’exige.
À retenir et prochaine étape
Le CoN, dans son esprit, n’est pas un tampon administratif : c’est une méthode pour construire des systèmes qui tiennent la charge, la durée et la menace. Les organisations qui s’en inspirent alignent leurs choix techniques, leurs budgets et leurs obligations de résultat. Pour approfondir la logique des preuves en environnement numérique et la confiance qu’elles instaurent, relire la perspective sur la validité juridique des signatures électroniques offre un parallèle éclairant.
