NCC observe l'état avant et après un changement réseau selon un même plan fixé, l'évalue par des règles déterministes et délivre un certificat NCC par changement — signé, adossé à une heure de confiance et à une preuve de transparence. Le destinataire le vérifie sans s'inscrire.
Le domaine est authentifié ; conditions avant/après, fenêtre d'observation et critères sont liés à la demande.
Sous un job signé, DNS, TCP, TLS et HTTP sont observés strictement dans le périmètre approuvé.
Des règles à version figée rendent PASS, FAIL ou INCONCLUSIVE. Seul PASS mène à l'émission.
Le certificat est signé et lié à un horodatage vérifié et à un enregistrement de transparence.
Chacun contrôle altération et authenticité via l'URL publique ou le paquet hors ligne.
Points d'entrée : Portal, API, OAuth et MCP — mêmes autorisations et limites partout. L'heure de confiance est fournie par PP-TSA, de la même série.
À la place de « changement effectué » et de captures d'écran, vous remettez un certificat NCC vérifiable.
La réussite se décide uniquement par le plan et les règles fixés d'avance. L'IA se limite à expliquer et ne participe pas au verdict.
Le destinataire vérifie signature, heure et transparence sur une URL publique, sans compte NCC.
Les rapports d'achèvement reposent sur les journaux et captures de l'opérateur. Le destinataire n'a aucun moyen de confirmer que la vérification a bien eu lieu, à cette heure, dans ces conditions.
Journaux et captures peuvent être retouchés après coup par leur auteur. Clients et auditeurs veulent une confirmation indépendante de l'opérateur.
« Nous avons vérifié que ça répond » ne dit ni quand, ni depuis où, ni quoi, ni selon quels critères.
Un rapport invérifiable ramène la confiance à la personne qui l'a rédigé.
Chaque ligne énonce une affirmation et sa limite. Cliquez pour ouvrir le détail.
Le domaine cible est authentifié par un défi HTTPS. Le certificat se lie à la cible authentifiée et aux conditions, fenêtre et critères figés à la demande.
Émettre au sujet du domaine d'autrui, et les litiges ultérieurs sur la cible réellement contrôlée.
Un certificat NCC montre que l'observation a porté sur une cible et des conditions approuvées, que l'évaluation a suivi des règles fixes et que l'émission est infalsifiable. Il ne garantit pas automatiquement la pertinence du changement, la disponibilité future ni la conformité à des référentiels d'audit. INCONCLUSIVE n'est jamais traité comme PASS.
Inscrivez-vous avec une adresse e-mail : l'environnement de votre organisation est créé aussitôt.
Selon le volume de certificats émis. Modifiable ensuite.
Authentifiez le domaine par défi HTTPS, figez conditions et critères avant/après, puis soumettez.
Si observation et évaluation donnent PASS, le certificat est émis. Remettez-le en URL publique ou paquet hors ligne.
Demandez et émettez depuis le Portal, ou via API, OAuth et MCP. Chaque entrée applique les mêmes autorisations et limites, avec clés d'API, journaux d'audit et fonctions de gestion.
Avec le seul identifiant public, un navigateur vérifie signature, clé, heure, transparence et révocation. Un paquet hors ligne permet la vérification sans réseau.
Pas une archive interne : il s'agit de remettre de la certitude à l'autre partie.
Livrez l'achèvement au client sous forme de certificat vérifiable et mettez fin aux échanges sur l'authenticité des rapports.
Émettez pour vous-même et gérez invitations, volumes, offres et facturation de vos clients au même endroit.
Recevez l'achèvement des changements sous-traités comme observation indépendante et verdict par règles, non comme le rapport du prestataire.
Présentez la trace de gestion des changements — quand, quoi, selon quels critères — sous une forme vérifiable par des tiers.
La confiance accordée au certificat dépend du périmètre observé et de la façon de rendre le verdict. Les deux sont acotés dès l'origine.
L'observation ne vise que des cibles authentifiées, dans ce que le job signé permet. Aucune exploration au-delà.
La réussite se décide de façon déterministe par des règles à version figée. L'IA se limite à l'explication.
PASS, FAIL et INCONCLUSIVE sont rendus comme issues distinctes. Un contrôle non concluant ne vaut jamais réussite.
Portal, API, OAuth et MCP appliquent les mêmes autorisations et limites, avec double authentification, gestion des clés d'API et journaux d'audit.