Résumé

  • L’appel d’offres publié par ICANN le 5 août vise un service SaaS intégré couvrant politiques, risques d’entreprise et de tiers, audit interne, conformité, tableaux de bord et collecte automatisée de preuves. Les offres sont attendues le 11 septembre ; aucune attribution ni mise en œuvre n’est établie.
  • Un état logiciel ne doit pas effacer la différence entre propriétaire du risque, opérateur du contrôle, collecteur de preuve, testeur, responsable de correction et organe de surveillance. Une concordance portable entre autorité et preuve conserverait le rôle, le fondement, la provenance, la contestation et les rectifications derrière chaque statut.

Un tableau de bord peut présenter une information exacte. Il ne reçoit pas pour autant le pouvoir d’accepter le risque qu’il affiche.

C’est la frontière que met en jeu l’appel d’offres lancé par ICANN le 5 août pour une solution de gouvernance, de risque et de conformité. L’organisation souhaite réunir dans un service mondial hébergé la gestion des politiques, les registres de risques, l’évaluation des tiers, les travaux d’audit interne, les correspondances de conformité, les rapports et la collecte automatisée de pièces justificatives. Elle décrit aujourd’hui des processus décentralisés, largement manuels et répartis entre plusieurs dépôts documentaires, ce qui, selon elle, réduit l’efficacité, la visibilité et la cohérence et accroît les risques de version.

Le gain recherché est crédible. Une politique ne devrait pas avoir plusieurs versions « finales ». Une constatation d’audit ne devrait pas perdre son responsable en passant d’une équipe à l’autre. Un même contrôle ne devrait pas changer d’identité selon le fichier consulté. Le registre commun peut améliorer la discipline du dossier.

Mais la consolidation produit une tentation : prendre le statut le plus visible pour la décision elle-même. « Accepté », « efficace », « corrigé » ou « conforme à l’appétence » ne sont pas de simples valeurs administratives. Ce sont des conclusions prises par une personne ou un organe compétent, sur un périmètre et une période donnés, à partir d’éléments qui peuvent être incomplets ou contestés.

La plateforme peut tenir les livres. Elle ne peut pas devenir le mandant.

Un appel d’offres, pas encore un résultat

Le document public présente un périmètre large. Le cycle des politiques couvrirait rédaction, examen, approbation, publication et automatisation du circuit. La gestion des risques s’alignerait sur COSO et ISO 31000, avec des registres centralisés utilisés par des équipes décentralisées. Les risques de tiers feraient l’objet d’évaluations, d’un suivi et d’une documentation. L’audit interne disposerait d’outils pour planifier, exécuter, suivre les constats et les corrections, puis rendre compte. La conformité rapprocherait ISO/IEC 27001, SOC 2, SOC 3 et les exigences de protection des données.

Des intégrations pourraient, lorsque cela convient, suivre des contrôles en continu et collecter des preuves.

Les exigences de haut niveau mentionnent un SaaS mondial entièrement hébergé, un environnement certifié ISO 27001, la haute disponibilité, des droits d’accès fondés sur les rôles, des journaux d’audit, des API, l’implémentation, l’assistance et la formation. Les critères portent notamment sur les fonctions, l’automatisation, les rapports, l’usage, le support, la santé financière, les prix, les références et la maîtrise des conflits d’intérêts.

Rien de cela ne prouve qu’une solution fonctionne déjà. Les propositions doivent être déposées avant 23 h 59 UTC le 11 septembre. L’évaluation est prévue du 14 septembre au 13 novembre, puis la vérification, la négociation et une éventuelle attribution à partir du 16 novembre. ICANN peut modifier le calendrier, rejeter les réponses, retirer la procédure ou ne rien attribuer. Aucun fournisseur n’est nommé dans le dossier vérifié.

Le document public n’est en outre qu’une partie de l’appel d’offres. Des pièces complémentaires se trouvent dans l’outil SciQuest/Jaggaer. On peut donc demander comment seront traités la portabilité, la sortie, la propriété des données, la conservation, les incidents ou la traçabilité des preuves. On ne peut pas affirmer, à partir du seul aperçu, que ces protections sont absentes des pièces réservées aux candidats, de leurs offres ou du futur contrat.

L’autorité est déjà distribuée par fonction

Le futur système ne part pas d’une page blanche. La présentation d’octobre 2022 du cadre de gestion des risques d’ICANN indique que le président-directeur général détient la responsabilité globale et délègue la propriété fonctionnelle à l’exécutif concerné. La fonction Risk Management facilite le cadre sans devenir propriétaire des risques. Les fonctions conservent la responsabilité des expositions nées de leurs activités. Le comité de direction examine rapports et plans d’action ; le Conseil et son Risk Committee surveillent le cadre et le niveau de risque accepté.

Ce document de 2022 n’est pas une garantie que chaque modalité soit inchangée. La charte actuelle du Board Risk Committee, approuvée le 20 juillet 2026, confirme toutefois les surfaces principales : surveillance de l’identification, de l’évaluation, de la hiérarchisation et de l’atténuation des risques, ainsi que de l’appétence et des tolérances. Pour l’audit interne, le comité approuve le périmètre, les plans et le budget, contrôle l’indépendance des prestataires, reçoit les constatations et suit l’état des mesures correctives de la direction.

Le procès-verbal de février 2025 formulait déjà cette séparation sans ambiguïté pour la période considérée : le comité surveillait la planification, l’exécution et les résultats des audits ; la direction demeurait responsable des corrections.

Ces rôles ne sont pas des doublons à fusionner. Administrer le registre ne signifie pas posséder le risque. Tester un contrôle ne signifie pas l’exploiter. Surveiller une correction ne signifie pas l’exécuter. La centralisation devrait rendre ces différences inspectables.

Une preuve automatisée doit encore prouver quelque chose

La collecte automatique répond à de vraies faiblesses des captures d’écran et exports manuels : lenteur, irrégularité, période mal définie, perte du lien avec la source. Une intégration avec un annuaire d’identités, une billetterie ou une infrastructure peut mieux conserver horodatage et couverture.

La fréquence n’est pourtant pas la pertinence. Une liste de comptes désactivés peut appuyer une affirmation précise sur le retrait d’accès sans prouver que les privilèges restants ont été correctement approuvés. Une configuration peut montrer qu’un mécanisme existe sans couvrir les exceptions. Un ticket fermé prouve une activité, pas nécessairement l’efficacité de la correction. Un écran actualisé peut reposer sur une hypothèse ancienne.

Il faut donc connaître la proposition soutenue, la population, la période, la requête ou transformation, les exceptions et la personne qui a jugé l’élément suffisant. L’automatisation améliore la collecte ; elle ne crée ni la signification ni le jugement.

Relier chaque état à son acte d’autorité

La réponse n’est pas un registre public des vulnérabilités. Elle est une concordance protégée entre autorité et preuve.

Chaque risque important, contrôle, exception, constat d’audit ou action corrective devrait disposer d’un identifiant stable. Le dossier préciserait la fonction et le rôle responsables, puis la nature de l’acte : posséder, évaluer, approuver, accepter, tester, contester, surveiller ou corriger. Il pointerait vers la politique, la déclaration d’appétence, le plan d’audit ou la décision qui fonde cette compétence.

La même fiche indiquerait l’affirmation, son périmètre et sa période, puis la provenance des preuves : système source, collecteur ou requête, transformation, horodatage, version, couverture et examinateur. Les exceptions et éléments contradictoires resteraient attachés. Tout changement conserverait l’auteur, son rôle, la date, le motif, les contestations et les rectifications.

Le fournisseur doit aussi laisser une trace : accès privilégiés, modifications de configuration et transformations de preuves. Enfin, l’export doit préserver identifiants, relations, décisions et corrections dans un format qu’un autre système et un examinateur indépendant peuvent comprendre. Une pile de PDF n’est pas une sortie si les liens qui lui donnent son sens ont disparu.

Cette concordance est une proposition de Daniel Kade, pas une exigence annoncée par ICANN. Elle maintient l’outil dans un rôle mince : puissant pour la conservation et le circuit, incapable d’absorber l’autorité des organes qu’il sert.

Rendre publique la carte, pas le contenu sensible

La responsabilité publique n’exige pas la publication du registre des risques, des vulnérabilités, des dossiers de travail d’audit, des preuves brutes, des détails sur les tiers, des données personnelles ou des avis juridiques. Elle peut montrer autre chose : une carte d’autorité approuvée, la séparation entre propriétaires et administrateurs, l’indépendance de l’audit, la vérification de la provenance, l’existence d’un historique de correction et un essai réel de sortie.

Des indicateurs agrégés sur les corrections en retard ou sur la revue des accès privilégiés peuvent renforcer l’assurance sans dévoiler le risque lui-même. Le point public essentiel est qu’aucun état logiciel ne puisse remplacer silencieusement une décision responsable.

La centralisation est utile lorsqu’elle rapproche les faits. Elle devient dangereuse lorsqu’elle fusionne des fonctions volontairement séparées. Le test durable sera simple : après l’implémentation, ou après une sortie, peut-on encore établir qui avait compétence, ce qui a été décidé, sur quelle preuve et avec quel droit de contestation ? Si oui, le système sert la gouvernance. Si la réponse n’existe que dans l’écran du jour, le teneur de registre commence à écrire la constitution.

Sources

  1. ICANN — annonce de l’appel d’offres GRC, 5 août 2026
  2. ICANN — aperçu du projet pour l’appel d’offres Governance, Risk, and Compliance
  3. ICANN — présentation du cadre de gestion des risques, octobre 2022
  4. ICANN — charte du Board Risk Committee approuvée le 20 juillet 2026
  5. ICANN — résolution adoptant la charte révisée du Risk Committee, 20 juillet 2026
  6. ICANN — procès-verbal du Board Risk Committee, 10 février 2025