← Méthodologie

Méthodologie de vérification

Comment nous attribuons un statut à chaque cellule de la matrice, comment nous enrichissons mois après mois, comment nous conservons les preuves sans qu'elles ne soient manipulables. La transparence méthodologique est l'angle de défense principal d'un comparateur indépendant — voici la nôtre.

1 · Les quatre niveaux de preuve

Chaque évaluation est cotée selon un niveau de preuve, du plus fiable (L1) au plus faible (L4). Le niveau de preuve est repris sur les fiches acteur, à côté de chaque statut. Les niveaux sont définis comme suit.

L1

Source officielle indépendante

La donnée provient d'un registre officiel public qui ne dépend pas de l'acteur évalué et qui engage la responsabilité d'une institution publique ou d'un organisme tiers accrédité.

  • ANSesante.gouv.fr/hds (liste officielle des hébergeurs HDS certifiés).
  • ANSSIcyber.gouv.fr (catalogue SecNumCloud actif et en cours).
  • Pappers · Infogreffe · BODACC — structure juridique, actionnariat, dirigeants.
  • RIPE NCC — propriété des préfixes IPv4/IPv6 européens.
  • PeeringDB — registre public des AS et de leur présence dans les IX.
  • AFNOR Certification · Bureau Veritas · LSTI · BSI — certificats publiés par les organismes accrédités (ISO 27001, 27017, 27018, etc.).
  • cybermalveillance.gouv.fr — label ExpertCyber.
  • JOUE · Légifrance — textes réglementaires (NIS2, DORA, AI Act).

Fiabilité : maximale. Une donnée L1 reste valide tant que la source officielle n'a pas changé. Vérification croisée recommandée à chaque mise à jour trimestrielle.

L2

Source officielle de l'acteur (verbatim)

La donnée provient du site officiel de l'acteur lui-même, sous forme de citation verbatim extraite, avec URL exacte, extrait et date de fetch. Vérifiable indépendamment par n'importe qui qui fetche la même URL à la même date.

  • Page de conformité, mentions légales, page "À propos".
  • Communiqué de presse hébergé sur le site officiel.
  • Documentation technique publique (livre blanc, fiche produit).
  • Rapport annuel ou rapport de transparence publié sur le site officiel.

Fiabilité : élevée. Une donnée L2 reste valide tant que l'acteur n'a pas modifié sa page. Les snapshots Wayback Machine sont systématiquement archivés en complément lors de l'extraction (cf. processus d'enrichissement).

L3

Source presse ou rapport tiers

La donnée provient d'une publication tierce qui rapporte ou commente une information sur l'acteur — sans que l'acteur en soit lui-même l'auteur direct.

  • Article de presse (journal, média spécialisé).
  • Étude marché (Markess, Gartner, IDC, etc.).
  • Communiqué de presse repris par un média tiers (sans contrôle éditorial de l'acteur).
  • Mention dans un rapport public (ARCEP, ANS, cour des comptes, OCDE).

Fiabilité : moyenne. Une donnée L3 peut être imprécise (rapporteur tiers ayant pu mal interpréter). Croisement avec L1 ou L2 recommandé.

L4

Savoir interne — banni pour tous

La donnée provient d'une connaissance opérationnelle interne — relation commerciale, échange client, déclaration informelle d'un cadre, savoir de marché non publiable. Ce niveau de preuve est banni pour tous les acteurs, y compris Guardis.fr (hébergeur du même groupe que l'éditeur).

Cette règle a été instaurée en v1.8 (mai 2026) pour garantir l'méthodologie d'évaluation publique. Si Guardis disposait de son propre savoir interne, nous interdire de l'utiliser garantit que toutes les évaluations reposent sur des sources publiquement vérifiables par n'importe quel lecteur — y compris par les acteurs concurrents qui peuvent contester nos évaluations. Voir la note d'méthodologie d'évaluation publique.

Fiabilité : non admise dans le comparateur public. Les éventuelles informations de niveau L4 relatives à Guardis.fr ou aux entités du même groupe ne sont pas répercutées dans la matrice publique.

2 · Les sept états factuels

Sept états couvrent toutes les situations rencontrées sur les 14 948 cellules de la matrice (404 acteurs × 37 critères). La distinction entre "Non documenté" et "Non — preuve d'absence" est centrale : nous ne déclarons jamais "Non" par défaut. L'absence d'information est explicite et n'implique pas l'absence du service.

3 · Règles d'arbitrage

Trois principes guident l'attribution d'un statut à une cellule. Ils sont appliqués uniformément à tous les acteurs, y compris Guardis.

  1. Doute → "Non documenté", jamais "Non". Une information non trouvée sur les sources publiques consultées est consignée comme "Non documenté" (—), pas comme "Non" (✗). Le "Non" exige une preuve documentée d'absence — par exemple un site officiel qui revendique explicitement "nous n'opérons pas d'AS BGP en propre".
  2. Sources publiques uniquement. Aucune information confidentielle, NDA-bound, ou issue d'une relation commerciale ne peut servir d'évidence pour le statut public. Cf. règle L4.
  3. Verbatim daté. Pour chaque cellule "Vérifié" ou "Revendiqué", nous conservons en interne la citation verbatim de la source, son URL et la date de fetch. Le verbatim est exposé en tooltip sur la fiche publique de chaque acteur.

4 · Cohérence critère ↔ scope HDS

Un acteur ne peut être "bonifié" sur un critère que si l'activité HDS correspondante est dans son scope certifié ANS (cf. les 6 activités HDS). Sinon, le critère est marqué "hors scope HDS" (⚠) ou "non concerné" selon le cas.

Exemples :

  • "Sauvegarde immuable" exige activité HDS 6. Un acteur certifié 1+2 seulement qui revendique "Sauvegarde immuable" est marqué ⚠ avec mention "service revendiqué hors scope HDS certifié".
  • "MSSP/SOC managé" exige activité HDS 5.
  • "PCA/PRA managé" exige activités HDS 5+6 combinées.
  • "Datacenter France exclusivement" exige activité HDS 1. Un acteur sans activité 1 peut revendiquer DC France via un partenaire HDS certifié activité 1 — la mention sera "datacenters HDS-certifiés activité 1, opérés par partenaires".

5 · Processus d'enrichissement trimestriel

La matrice évolue à chaque cycle trimestriel selon le processus suivant :

  1. Re-fetch des registres officiels (ANS, ANSSI, Pappers, RIPE, PeeringDB) — automatisé.
  2. Re-fetch des sites officiels des acteurs (Playwright + extraction texte) — automatisé.
  3. Diff vs version précédente — détection automatique des changements de scope, certificats, sites web.
  4. Validation humaine éditoriale sur les diffs significatifs.
  5. Mise à jour des matrices et des fiches.
  6. Publication du changelog sur /changelog/.
  7. Notification aux acteurs en cas de modification structurelle de leur fiche (e-mail au point de contact public).

Voir le détail dans le processus d'enrichissement et le pipeline Git public.

6 · Conservation des preuves (chaîne de garde)

Pour qu'une évaluation ne puisse pas être manipulée a posteriori, chaque cellule "Vérifié" ou "Revendiqué" est accompagnée d'une preuve archivée par trois mécanismes indépendants :

  1. Hash SHA-256 du verbatim + date ISO 8601, journalisé dans data/sources/<slug>.json (commit Git public). Toute modification ultérieure du verbatim modifie le hash, traçable dans l'historique Git.
  2. Archive Wayback Machine : l'URL source est systématiquement snappée sur web.archive.org au moment de l'extraction. Le lien Wayback est conservé à côté du verbatim. Vérifiable par n'importe qui.
  3. Historique Git public — l'ensemble du repository (404 matrices, 404 fiches, 37 fiches critères, 37 fiches profils) est versionné. Chaque cycle trimestriel = un commit nominal. Les diffs sont publiquement consultables sur GitHub.

Si nous modifions un verbatim, ces trois mécanismes le révèlent immédiatement. Si un acteur conteste une évaluation, nous pouvons produire la preuve datée et signée du verbatim original.

7 · Souveraineté technologique — méthodologie spécifique

Le bloc « Souveraineté technologique » (visible sur la fiche acteur et sur la matrice cross-check dédiée) repose sur 8 critères structurants pour la conformité DORA et NIS2. Chacun est vérifié sur une source publique indépendante (niveau L1).

  1. Opérateur télécom déclaré ARCEP — statut L33-1 / L34-1 vérifiable sur arcep.fr. Source : registre public ARCEP. Niveau de preuve : L1.
  2. AS BGP propre — système autonome opéré par l'acteur (et non chez un fournisseur). Vérification croisée sur RIPE whois (holder de l'AS) et bgp.he.net (ORG name, préfixes annoncés). Voir notre méthodologie AS BGP détaillée. Niveau : L1.
  3. IPv6 natif — résolution AAAA active sur le site officiel ET préfixe IPv6 originé sous l'AS de l'acteur. Vérification automatique via DNS + bgp.tools. Niveau : L1.
  4. RPKI signé et valide — *Resource Public Key Infrastructure* : signature cryptographique des préfixes IPv4/IPv6 annoncés en BGP. Vérification sur rpki-validator.ripe.net et bgpview.io. La couverture RPKI ≥ 80% est considérée « valide » dans notre matrice ; ≥ 99% sans invalid = niveau de maturité réseau maximal. Niveau : L1.
  5. Anti-DDoS opérateur — mitigation au niveau du backbone (BGP blackhole community chez l'upstream, ACL upstream, capacités scrubbing). Documenté sur le site de l'opérateur ou via communiqués techniques. Niveau : L2-L3 selon publication.
  6. Collecte fibre propre — opérateur fibre licencié dans le groupe de l'acteur (pas de sous-traitance externe). Vérifié via le registre ARCEP et croisé avec le SIREN groupe (Pappers). Niveau : L1.
  7. Collecte mobile propre — opérateur mobile / M2M licencié dans le groupe. Idem : ARCEP + Pappers. Niveau : L1.
  8. Peering policy open — déclaration publique sur PeeringDB du champ policy_general = open. Niveau : L1.

Données enrichies

Pour chaque acteur, nous collectons les éléments suivants quand ils sont disponibles publiquement : ASN, nom et RIR, date d'allocation, AS-SET IRR, préfixes IPv4 et IPv6 originés, transit upstreams (et leur tier), peering policy, datacenters PeeringDB. Le pipeline est piloté par le script scripts/collect-bgp-data.py (versionné en Git public). Sources : BGPView, PeeringDB, RIPE WHOIS. Le fichier canonique est src-data/sovereignty-tech.json.

Limites connues

  • Un acteur HDS peut avoir son infrastructure HDS souveraine sans que cela transparaisse sur la connectivité de son site corporate public. Le bloc Souveraineté technologique mesure la maîtrise réseau publique observable, pas la qualité de l'infrastructure HDS sous-jacente.
  • La policy de peering sur PeeringDB est déclarative, pas vérifiable au sens strict. Un acteur peut annoncer « open » et refuser certains peers en pratique.
  • Les datacenters PeeringDB reflètent où l'AS est présent réseau-ment, pas nécessairement où les données client sont stockées (qui peut être un autre site, sous-traité ou partenaire HDS).

8 · Signaler une erreur

Si vous identifiez une erreur factuelle sur une fiche acteur ou un statut de cellule, signalez-la via la page contact ou notre bug bounty méthodologique. Toute correction validée est consignée dans le changelog.